写给程序员的管理入门课

超、凢脫俗 2022-08-23 04:59 190阅读 0赞

![640_wx_fmt_jpeg_tp_webp_wxfrom_5][]

今天这篇是唐巧的投稿。很早就认识了唐巧，那时他还是一个初入江湖的「小球」，高高瘦瘦，正在网易有道做云笔记的开发。短短几年之内，唐巧获得了飞速的成长，他不仅成为一个优秀的开发者，而且成长为了一个技术领导。

为什么他成长这么快，我觉得主要得益于阅读、思考、总结和实践。最近他读完了《格鲁夫给经理人的第一课》，写了一篇长长的读书笔记。他自己有公众号（isoDevTips），不过觉得这一篇发到 MacTalk 更合适，我看了，非常有价值，就是太长了，于是我动手改了一个精简版（主要是第二部分），文末会提供原始链接，建议大家阅读全文并收藏，仔细阅读。同时推荐这本书：《格鲁夫给经理人的第一课》，微信读书上就有。

以下是精简版

--------------------

《格鲁夫给经理人的第一课》 最早出版于 2007 年，书原名为《High Output Management》。本书的作者格鲁夫是 Intel 的前 CEO，领导了 Intel 从一家濒临倒闭的存储器公司，转型为微处理器公司，并且在个人 PC 开始流行时，成功和微软缔结 Wintel 联盟，主宰了整个 PC 电脑时代。格鲁夫是一个技术出身的管理者，在本书中，我们甚至看到他多次用编译器来举例，所以这本书也非常适合有技术背景的读者。

本书主要分为四大部分：

第一部分「早餐店的生产线」：用早餐店的经营故事，来类比企业的经营管理，介绍了一些数据分析、产品预测、产品检验的办法，提出了管理杠杆率以及关注于产出的管理原则。  
第二部分「打好团体战」：展开论述管理杠杆率，并且讨论了开会、决策和规划。  
第三部分「推动组织的巧手」：从企业组织架构入手，谈混合型组织，双重报告，CUA 模型，以及文化价值观。  
第四部分「谋事在人」：讲人员管理。涉及激励、工作成熟度、绩效评估、招人与留人、报酬与培训。

第一部分包括：生产包含什么？从早餐店的库存谈起。这部分建议读者去阅读原文，唐巧用了大量的文字和图标进行阐述，我们直接进入第二部分：打好团体战，这部分我觉得技术转管理的童靴非常有价值。

## 打好团体战 ##

管理意味着你有了一个团队，你的工作成果不再是纯粹的提交代码了，那么管理者的产出应该是什么呢？

> 经理人的产出 = 他直接管辖部门的产出 + 他间接影响所及部门的产出

格鲁夫介绍了他一天的工作，能够看出来工作内容非常杂乱，也非常多，而且做不完。他说：

> 我的一天通常结束在我觉得累而决定回家休息的时候，而不是事情做完了。  
> 像家庭主妇一样，经理人永远有忙不完的事情。

那管理者的职责到底是什么呢？

#### 管理者的职责 ####

因为事情永远做不完，所以我们更需要关注于工作的产出，把最高优先级的事情找出来优先安排和执行。关于管理者的职责，格鲁夫是这么分的：

*  信息收集类。看邮件、看报告、开会、和同事聊天、看用户反馈、看产品数据、试用公司产品等。
 *  传递信息。培训或者分享观点。
 *  决策。通过、制定或者否决一些方案。
 *  给予提示。传递一些观点。
 *  为人表率。提供行为示范。

前四类是相对具体的工作，比如决策，又分为两类，「未雨绸缪型」和「亡羊补牢型」，前者是在规划未来，后者是在补救当前问题。关于给提示，作者认为它与决策的主要差别在于，给予提示很多时候你也没有明确的方案，只是希望让对方通过自己的提示来做一些调整，而调整的具体的细节需要对方思考。

除了这些，为人表率也很重要，如果整个团队都在加班赶工并努力尝试解决方案，你拍拍屁股说，没我的事，去撸个串。可能你后半生只能自己撸串了。

#### 关于授权 ####

授权是管理环节最重要的一环，关于授权，我曾经在文章中写过：好的领导者，不是大包大揽，也不是让下属去完成领导部署的任务，而是让他们做自己真正想做的工作。好的领导者不应该总是去试图领导别人，他们要及时反思，修正自己的思路和决策，听取别人的意见，并把一些决策权交给他人。

格鲁夫则有更深入的认识，他是这么说的：

> 没有完备监督计划的授权等于渎职。你绝对不能完全地抽身，即使你已经授权，你还是得负成败责任。  
> 全程监督整个被授权的案子是确保结果尽如人意的唯一方法。监督不是干涉，而是通过不时的检查，来确定活动的进行一如预期。  
> 因为监督你熟悉的工作比较容易，所以如果有机会，你应该把自己熟悉的工作授权给他人。但切记先前举的例子 —— 理智叫你松手，但情感上你可能老大不愿意。

关于这部分内容的理解，唐巧是这么说的：

> 关于这方面的知识，我在指导 iOS 开发新人的时候体会很深。通常指导新人的常用办法，就是将自己熟悉的工作交给新人完成。因为这些工作非常好通过监督（Code Review + 定期讨论）来保证质量，所以风险可控，而我自己也会从中学习到指导别人的各种技巧和经验。
> 
> 最重要地，我需要打破我的舒适区，因为我需要放弃自己非常熟悉的工作内容，转而做一些新的陌生的事情。而新人的代码质量和编写速度往往是比我自己直接写要慢得多的，我需要有耐心地等待他们犯错，然后通过 Code Review 和讨论来让他们学习到相应的编程知识。

#### 关于效率 ####

工作中提高效率是我们提升业绩和能力的最佳途径，格鲁夫提出了一系列提高效率的办法：

*  找出限制步骤：重要的、紧急的事情优先安排。这样的情况下有空余，再安排别的事情。
 *  类似的工作放在一起做。例如将邮件处理，QQ 信息回复的事情稍做积累再统一回复。
 *  安排好日程表。对一些事情说不，给日程表上重要的事留出余地。
 *  建立指标。尽量估计自己在每件事情上的耗时，尽管这件事情很难，也可能不太准，但是总会有所帮助的，建立了经验之后，估计时间会越来越准。
 *  存货法。留一些重要不紧急的事情，自己不太忙的时候，就可以做这些事。比如对于我来说，学习产品知识，试用各种 App 的功能，分析各种 UI 设计就是一个「存货」。
 *  标准化。对一些经常做的事情，制定标准化的流程就可以提高效率。这就类似我们制定的产品评审流程，上线流程一样。标准化了之后，就不用每次想应该怎么做了，按步就班地开展即可。

老被人打断怎么办？作者认为「躲起来让人找不出」或者「叫别人不要在某些时段打扰」的办法都不太好，他介绍了很多有用的办法，包括：

*  标准化。把一些常见的问题归类总结。如果一类问题有归类总结了，也就意味着它能够被授权给员工来处理了，也很容易被进一步用于员工指导别人。
 *  类似的工作放在一起做。每天固定时间处理员工的问题，或者固定在一对一沟通中处理相关问题。
 *  运用指标。有指标就可以改进流程。看看自己花费在解决临时问题上的时间以及常见问题，然后就可以看看能够优化这些时间。

#### 有效开会 ####

开会是管理的必经之路，如果你是个领导者，一定会爱上或者恨上开会的。格鲁夫将会议分为两类：过程导向会议和任务导向会议。

过程导向会议又可分为以下三类：一对一会议、部门会议，以及运营总结会议。过程导向会议要尽量规律化。

关于部门会议，作者的经验是经理人要注意大家讨论的主题和效率，事先讨论的主题需要明确，最好大家在开会前能做好准备。经理人要尽量让讨论是自由的，避免成为自己主宰的「一言堂」。部门会议的议题应该尽量让部属来负责，经理人的责任只是保证讨论不要偏题即可。

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1][]

运营总结会议是让那些通常没有机会开部门会议的同事提供互动的机会，让他们有机会彼此学习及分享经验。

任务导向会议一般没有固定的开会时间和频率，会议结束后一般也需要产出一份会议的讨论结果用于后续执行。这种需要决策的会议通常需要控制人数，如果超过 8 个人，很可能比较难以推动达成意见的一致。

--------------------

文章后面的内容愈加丰富，我就不在「精简」了，大家可以通过以下链接访问全文。

\[http://blog.devtang.com/2016/06/06/high-output-management-summary/\]

唐巧写在结尾的话：我整理这份笔记花费了好几周，我从本书中收获巨大，希望你也能从这篇总结中有所收获。感谢唐巧！

题图：攀登，from Zoommy

[640_wx_fmt_jpeg_tp_webp_wxfrom_5]: /images/20220721/109f2612e4804c0d8cfca8e964a0e6b8.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1]: /images/20220721/f538805c0e324c6bb984ae8f6ce3d408.png