写给程序员的管理入门课程 -《格鲁夫给经理人的第一课》
写给程序员的管理入门课程 -《格鲁夫给经理人的第一课》
序
《格鲁夫给经理人的第一课》 最早出版于 2007 年，书原名为《High Output Management》。本书的作者格鲁夫是 Intel 的前 CEO，领导了 Intel 从一家濒临倒闭的存储器公司，转型为微处理器公司，并且在个人 PC 开始流行时，成功和微软缔结 Wintel 联盟，主宰了整个 PC 电脑时代。
格鲁夫是一个技术出身的管理者，在本书中，我们甚至看到他多次用编译器来举例，所以这本书也非常适合有技术背景的读者。
本书主要分为四大部分：
- 第一部分「早餐店的生产线」：用早餐店的经营故事，来类比企业的经营管理，介绍了一些数据分析、产品预测、产品检验的办法，提出了管理杠杆率以及关注于产出的管理原则。
- 第二部分「打好团体战」：展开论述管理杠杆率，并且讨论了开会、决策和规划。
- 第三部分「推动组织的巧手」：从企业组织架构入手，谈混合型组织，双重报告，CUA 模型，以及文化价值观。
- 第四部分「谋事在人」：讲人员管理。涉及激励、工作成熟度、绩效评估、招人与留人、报酬与培训。
第一部分：早餐店的生产线
本部分用早餐店的经营故事，来类比企业的经营管理。介绍了一些数据分析、产品预测、产品检验的办法。
第一章：“生产” 包含什么？
格鲁夫认为，一个早餐店的生产线，就包含了一个现代软件开发管理中的各种问题。一个合格的早餐店的生产线，可以在预定的时间内，用最低的成本，做出顾客需要的产品。而现代软件的开发流程，也是希望在一个预定的时间内，用最低的成本，开发出符合产品经理定义的、合格的应用或服务。
这个过程，涉及一些最基本的项目管理工作：找出限制步骤，然后优化流程，形成一个最佳的策略。
在经营早餐店的故事中，限制步骤可能是人员数量、一些机器的产能、或者库存量。通过分析这些限制步骤的成本和收益，你就可以找出一个最价收益的方案。
软件开发中的项目管理也是这样，你的限制步骤可能是人员数量、开发时间、产品功能点、测试时间、或者技术实现方案。找到限制步骤后，通过优化限制步骤就可以优化整个流程。
第二章：从早餐店的库存谈起
格鲁夫认为，我们应该确定和监控早餐店的核心指标，对于一个早餐店来说，核心指标包括：销售预测、原料库存、设备状况、人员情况、品牌评价（用户反馈），并且每天检视这些指标。
另外，作者提到，指标应该有相互的限制，这样避免过度反应。就像软件开发中的软件质量与开发时间一样，不能只追求质量而不管开发时间，也不能只追求时间还不管质量。
其实作者在这章强调的就是数据分析的重要性，在数据分析上，作者介绍了一些方法，包括：
- 先行指标，用于揭示未来信息的指标，例如 NPS，机器故障记录。
- 线性指标，用于分析进度的指标。
- 趋势指标，用于分析变化趋势的指标。
- 重复印证表，用于修正预测行为，提高预测准备性的指标。
作者接着提到了计划生产。这个事情是预期未来的销售额而提前生产（放到库存）的一种行为。这里面合理地预测未来是核心，否则要么就会造成没有商品可卖，要么就会造成库存过高。刚刚提到的「重复印证表」可以比较好地帮助我们做预测的调整。
作者接着提到了检验质量。检验质量应该在生产的每个环节都做，但是越早的环节，检验的成本越低。就像我们修复程序的 Bug 这件事情一样，如果我们刚刚写完代码就收到相应的 Bug 报告，那么修复的成本会小很多。但如果我们写完过了一周才收到 Bug 报告，那么我们就需要花精力先回顾当时的逻辑，才能进一步找到有问题的代码。
作者提到了一些检验质量的办法，用于节省检验本身的精力成本。
第一种检验办法是：海关与监视器。海关简单来说就是所有的东西都必须检查，监视器简单来说就是抽样检查。根据具体产品出问题的概率，以及出问题的危害程度，我们可以结合海关的检验方法和监视器的检验方法。
第二种检验办法是：随机检验。随机检验的量应该随着检验结果的好坏有所调整，使得检验有针对性。
本章的最后，作者提出了管理杠杆率的概念，并且用下面的漫画来做了解释。作者认为，通过定义管理的「产出」，我们可以专注于那些提高产出的管理活动，那些高投入产出比的管理活动被作者称作「管理杠杆率」高，进而应该被优先安排和执行。
第二部分：打好团体战
本部分介绍了管理的一些经验技巧，涉及管理杠杆率、开会、决策和规划。
第三章：管理杠杆率
作者首先在本章定义了经理人的产出：
经理人的产出 = 他直接管辖部门的产出 + 他间接影响所及部门的产出
格鲁夫介绍了他一天的工作，能够看出来工作内容非常杂乱，也非常多，而且做不完。他说：
我的一天通常结束在我觉得累而决定回家休息的时候，而不是事情做完了。
像家庭主妇一样，经理人永远有忙不完的事情。
因为事情永远做不完，所以我们更需要关注于工作的产出，把最高优先级的事情找出来优先安排和执行。
管理工作的分类
我们从格鲁夫一天工作的介绍中，能看出来他的工作分为几类：
- 信息收集类。看邮件、看报告、开会、和同事聊天、看用户反馈、看产品数据、试用公司产品等。
- 传递信息。培训或者分享观点。
- 决策。通过、制定或者否决一些方案。
- 给予提示。传递一些观点。
- 为人表率。提供行为示范。
在信息收集方面，作者鼓励在使用传统的邮件和口头直接沟通外，多增加一些非正式的沟通机会。比如多随意在公司里走走，找不同的人聊聊天等等。
在决策方面。作者认为决策分为两类：「未雨绸缪型」和「亡羊补牢型」，前者是在规划未来，后者是在补救当前问题。
关于给予提示，作者认为他与决策的差别在于，给予提示很多时候并没有明确的方案，他是希望让对方通过提示来做一些调整，而调整的具体的细节需要对方自己思考。
除了以上四类（信息收集、信息传递、决策、给予提示）工作，作者也提到，管理者的所有行为，同时也在以「榜样」的作用被员工效仿。例如管理者随意迟到，员工就会随意迟到。管理者做事情认真，员工也会有认真工作的压力。
管理杠杆率
在介绍完管理工作的分类后，格鲁夫给大家介绍了他的管理杠杆率公式：
经理人的产出
= 组织产出的总和
= 杠杆率 A 管理活动 A + 杠杆率 B 管理活动 B ......
与管理杠杆率相关的因素有很多，包括时效：一个员工有离职情绪时，及时沟通的时效就很重要。一个重要会议要开时，提前准备内容的时效就很重要。
另外，格鲁夫指出，也有很多管理活动的杠杆率是负的，例如：经理人情绪低下，影响员工士气。经理人越权干涉别人的工作，影响别人积极主动性。经理人做出错误决策，浪费人力物力。
格鲁夫指出，高杠杆率的事情包括：
- 当一个经理人可以同时影响多个人的事情
- 当经理人一个简单动作或简短谈话，会对别人产生长远影响的时候
- 当经理人的技术、知识或信息，对一群人造成影响的时候
作者也列出了一些具体的高杠杆率的事情：
- 关注用户的反馈，特别是抱怨。
- 绩效评估。
- 传授知识、技能或价值观给部署。
- 授权。
授权
关于授权，作者做了展开的介绍：
没有完备监督计划的授权等于渎职。你绝对不能完全地抽身，即使你已经授权，你还是得负成败责任。
全程监督整个被授权的案子是确保结果尽如人意的唯一方法。监督不是干涉，而是通过不时的检查，来确定活动的进行一如预期。
因为监督你熟悉的工作比较容易，所以如果有机会，你应该把自己熟悉的工作授权给他人。但切记先前举的例子—理智叫你松手，但情感上你可能老大不愿意。
监督的办法可以用上一部分提到的检验产品质量的原则：越早检验成本越小。例如对开发工作不熟悉的员工，让他们在写代码前就先给你讲讲他打算如何规划，就比让他写完你再检查要好得多。
监督的另外一个技巧也是检验产品质量的原则提到的：注意检验的频率。对于新人，要增加频率。对于信任的人，可以降低频率。另外，监督的方法要具有多样性，对不同的人采用不同的方法。
监督并不是说经理人一定需要替员工考虑好事情的方方面面，因为这毕竟需要付出大量的精力。对于某些事情，经理人只需要提出一些细节问题来测试员工的思考是否全面，则可以一定程度上评估出事情的靠谱程度。对于经理人不熟悉的领域，也可以用此办法。
关于这方面的知识，我在指导 iOS 开发新人的时候体会很深。通常指导新人的常用办法，就是将自己熟悉的工作交给新人完成。因为这些工作非常好通过监督（Code Review + 定期讨论）来保证质量，所以风险可控，而我自己也会从中学习到指导别人的各种技巧和经验。
最重要地，我需要打破我的舒适区，因为我需要放弃自己非常熟悉的工作内容，转而做一些新的陌生的事情。而新人的代码质量和编写速度往往是比我自己直接写要慢得多的，我需要有耐心地等待他们犯错，然后通过 Code Review 和讨论来让他们学习到相应的编程知识。
学会指导新人通常是一个有经验的程序员转向更高职位的第一个挑战，不管是他是转向偏管理的岗位还是继续在技术岗位上深挖，都需要先将手中的工作交出去，才能够承担更重要，更有挑战的事情。
提高效率
作者提出了一些提高效率的办法：
- 找出限制步骤：重要的、紧急的事情优先安排。这样的情况下有空余，再安排别的事情。
- 类似的工作放在一起做。例如将邮件处理，QQ 信息回复的事情稍做积累再统一回复。
- 安排好日程表。对一些事情说不，对日程表的事情留上 Buffer。
- 建立指标。尽量估计自己在每件事情上的花费，尽管这件事情很难，也可能不太准，但是总是会有所帮助，而且有经验了之后，估计时间会越来越准。
- 存货法。留一些重要不紧急的事情，使自己不太忙的时候，可以做这些事。比如对于我来说，学习产品知识，试用各种 App 的功能，分析各种 UI 设计就是一个「存货」。
- 标准化。对一些经常做的事情，制定标准化的流程就可以提高效率。这就类似我们制定的产品评审流程，上线流程一样。标准化了之后，就不用每次想应该怎么做了，按步就班地开展即可。
老被人打断怎么办？作者认为「躲起来让人找不出」或者「叫别人不要在某些时段打扰」的办法都不太好，他介绍了很多有用的办法，包括：
- 标准化。把一些常见的问题归类总结。如果一类问题有归类总结了，也就意味着它能够被授权给员工来处理了，也很容易被进一步用于员工指导别人。
- 类似的工作放在一起做。每天固定时间处理员工的问题，或者固定在一对一沟通中处理相关问题。
- 运用指标。有指标就可以改进流程。看看自己花费在解决临时问题上的时间以及常见问题，然后就可以看看能够优化这些时间。
第四章：管理必经之路：开会
格鲁夫将会议分为两类：过程导向会议和任务导向会议。
- 过程导向会议：关于知识技能和信息交流，通常是例行的。
- 任务导向会议：会产生决策的，通常不是例行的。
过程导向会议
过程导向会议又可分为以下三类：一对一会议、部门会议，以及运营总结会议。过程导向会议要尽量规律化。
关于一对一会议，我之前专门写过文章：《浅析一对一沟通》
关于部门会议，作者的经验是经理人要注意大家讨论的主题和效率，事先讨论的主题需要明确，最好大家在开会前能做好准备。经理人要尽量让讨论是自由的，避免成为自己主宰的「一言堂」。部门会议的议题应该尽量让部属来负责，经理人的责任只是保证讨论不要偏题即可。
运营总结会议是让那些通常没有机会开部门会议的同事提供互动的机会，让他们有机会彼此学习及分享经验。
任务导向会议
过程导向的会议一般有固定的开会时间和频率，其效果也多是交流信息为主。而任务导向会议一般没有固定的开会时间和频率，会议结束后一般也需要产出一份会议的讨论结果用于后续执行。
这种需要决策的会议通常需要控制人数，如果超过 8 个人，很可能比较难以推动达成意见的一致。
互联网公司实际的情况
就我的感受，互联网公司其实为了追求效率，还是希望尽量少开会，我参与的会议主要分几类：
- Scrum 相关的会议：包括计划会议、每日站会、评审会议和回顾会议。我们的技术和产品工作都用 Scrum 的方式来管理。
- 过稿会议：产品的过稿会议，UI 稿的过稿会议。
- 一些临时性的，需要讨论的会议，类似格鲁夫提到的任务导向会议。
如果把一对一沟通算作会议，那么这也是我常参与的。但是因为一对一沟通的场地经常是在非办公室的区域，所以我其实不觉得这是一种会议。
第五章 不挥舞权杖的决策
由于在互联网公司，科技类知识更新速度非常快，而相对于一线的技术人员，管理者并不能拥有更多决策所需要的专业知识，因此我们需要将具体的决策，下放到一线的员工手中。
格鲁夫在书中描述了一种理想的决策方式：
- 先是充分地讨论和表达意见
- 然后是在意见充分被表达之后的决策
- 最后是一旦最后决策产生，那些少数不同意的同事，都应该在之后执行过程中全力支持。
第六章 规划是为了明天
在你规划行动方案之前，一定记得先问自己：有什么事情我如果 “今天” 做了，可以让 “明天” 更好，或者至少让 “明天” 不会更糟。
在本章，格鲁夫首先介绍了 Intel 在流程规划上的一些方法，但是个人感觉比较偏制造业，因为讲的都是处理原材料，库存与订单之单的矛盾。
接着，格鲁夫介绍了目标管理，包括需要做到：1、有明确的目标。2、有向目标前进的具体方案。
当你将计划落实为白纸黑字时，看起来最抽象笼统的总结即为你的战略，而你用来实行战略的行动即为战术。
对于这章，我自己倒是有一些总结。就我在互联网公司的经验来说，我们做规划和目标管理主要是分为以下几类：产品规划、开发规划、运营规划、人员规划。
产品的规划
我们通常需要计划出未来至少 3 个版本的产品迭代计划。然后，对于这些产品计划，安排相应的产品 PRD 稿的撰写和评审、UI 稿的制作和评审、技术评审、开发测试及最后的上线。
开发的规划
开发的规划主要是通过 Scrum，将产品和美术稿已经 Ready 的待做事项以 backlogs 的方式放在 Scrum 的管理中。然后在每一个迭代冲刺（Sprint）中，我们从 backlog 里面选取部分工作到当个 Sprint 中。
每一个 Sprint 是包括完整的开发和测试工作，服务器端通常在 Sprint 快结束时，就需要完成上线操作。客户端由于版本发布过于频繁对于用户也有一些打扰，所以我们通常两周对外发布一次版本。
运营的规划
大型的运营活动如果需要产品和开发的介入，就也需要相应的规划。通常情况下，我们认为提前一个半月开始是相对充裕的方式。运营花大概两周做活动的策划，剩下的一个月用于技术的排期。
人员的规划
作为团队管理者，我们还需要在人员上做相应的规划。这包括：
- 人员的招聘。预估未来业务增长对于人力的需求，以便提前做好相应的招聘工作。
- 人员的培养。新人的培养、重要岗位人员的培养。
- 人员的激励或开除。对一些表现优秀的人员，给予更多的关注和沟通。对一些表现不佳的人员，除了需要明确地指出他们的问题外，也需要根据改进情况选择后续的处理方案。
第三部分：推动组织的巧手
本部分介绍一些实践经验，作者从早餐店的发展作为故事，引出企业管理中涉及的混合型组织架构，从这种架构带来的问题出发，提出了双重报告这种解决方案，由从双重报告需要的企业文化出发，介绍了影响人们行为的 CUA 模型，最后得出高 CUA 因素的工作，需要员工用文化价值观来指导行为。
比较可惜的是，对于如何增强大家的文化价值观，格鲁夫并没有展开讨论，只是说领导应该以身作则。
第七章 当早餐店开始繁衍
在实务中，这种有关管理上集权及分权的分歧到处可见，几已成为今日管理上最重要的课题之一。
本章只讲了一个故事，当早餐店做得越来越好时，分店越来越多，带来的管理上的复杂度也越来越大。不管是采购，还是人事，还是资产，我们都需要专门雇佣人员来负责。
但是除了这个故事外，本章并没有涉及任何解决方案的内容。
第八章 混血型组织
斯隆总结他在通用汽车数十年的经验时说：“好的经营管理，是中央集权和地方分权间的折中产品。
本章讨论了两种组织形式：「任务导向组织」和「功能导向组织」。
任务导向组织是以具体的完成某件事情为目标而形成的组织。功能导向组织是以完成某个细分功能而形成的组织。这两种组织各有优缺点，很多时候需要以混合的形式存在于一家公司，而具体如何混合，在不同的公司差异相当大。
拿互联网公司来举例，我所在的猿题库是更偏向「任务导向组织」的公司，我们公司旗下有三款产品：猿辅导、猿题库、小猿搜题。这三个产品下面，各种有着完整并且独立的运营、产品、开发、测试、UI 团队。而我之前工作的网易有道，就是一家更偏向「功能导向组织」的互联网公司，因为在网易有道，有着全公司统一的测试团队、UI 团队。还有一些公司，他们甚至将全公司的移动端开发都集中成一个移动开发团队。
两种组织方式各有优缺点，我们来看看作者格鲁夫的分析。
功能导向组织
「功能导向组织」的部门更像是内部的分包商，相比外部的外包商，内部的分包商因为同属于一家公司，所以提供的服务会更好，而且还有：
- 规模经济。以运维为例，全公司统一的运维部门，有利于在公司内部建一统一的运维规范和运维系统，节省运维成本。
- 根据需求，转移或分配企业资源。以测试为例，全公司统一的测试团队，在某些产品有更多临时测试需求时，更好地调配人员。
- 共享知识。全公司统一的测试团队、UI 团队有利于他们更加方便地交流相关的专业技术，测试团队可能在测试流程上更加优化，UI 团队可能在全公司范围内统一 UI 设计规范和准则。
但是，「功能导向组织」的缺点也很明显，包括：
-
不同部门之间会争抢「功能导向组织」的资源。比如测试团队如果是公共的话，每个部门都会为自己的产品争取尽量多的测试资源，但是谁能够证明自己的优先级肯定比别人的高呢？所以这其中会产生更多的沟通和决策成本。
-
责任心减弱。这一条并不是格鲁夫总结的，而是我自己感受到的。拿移动开发团队举例，如果移动开发团队是「功能导向组织」，那么某个移动开发者对于一个临时的开发工作很可能并不能做到付出 100% 的全力，因为他很可能只在这个项目做两个月。那么他很可能着眼于「把当前的工作做完」，而不是「整个产品本身的利益」来考虑问题。
举一个具体的例子，当一个产品设计对一种特殊情况考虑不完整时，一个「功能导向组织」的开发者很可能基于按时「把当前的工作做完」这个目标，而选择忽视这些未定义的产品细节，按照「怎么方便就怎么开发」的方式来做，因为产品没定义清楚本来是产品的责任，与他无关。如果他找产品讨论这些细节，很可能使得实现方案变得更加复杂，对于他「把当前的工作做完」这个目标产生冲突。
但是，如果是一个「任务导向组织」的开发者，因为他会长久地负责这个项目的开发，这个项目的好坏最终会决定大家的绩效，他当前没有处理好这个产品细节，以后很可能也会是他来再次重构相应的代码。那么他就有更大的可能去和产品沟通和协调，确定这些未定义的产品细节。
任务导向组织
「任务导向组织」的优点是什么呢？优点是需求更加明确，决策更加灵活，人员也更加有凝聚力。
「任务导向组织」也有缺点，主要是这种方式会使得大家在共享专业知识上更加困难。对此，我们公司增加了很多全公司范围内的技术分享会，通过这些分享活动，我们希望增加大家在技术上的交流。
那么，猿题库公司的具体混合型组织是什么样的呢？我们的「功能导向组织」仅包括：运维团队、算法研究团队、数据分析团队、财务和行政团队。而我们将产品、运营、测试、客户端开发、Web 前端开发、UI 设计人员都分拆放到了「任务导向组织」中，而我们按产品将「任务导向组织」分为了三个：猿辅导团队、猿题库团队、小猿搜题团队。
第九章 双重报告
格鲁夫在本章中，推荐用双重报告来解决混合型组织的管理问题。混合型组织中，一个人如果在一个「任务导向组织」，那么他很可能在专业技能上无法得到 Leader 的指导，格鲁夫希望通过让这个人在专业技能上报告给一个专业技能上的 Leader，使得这个人在专业技能上有所成长。
但是，格鲁夫也提到，这种双重报告很多时候是模糊不清的，「含混是解决问题之道」。所谓的含混，就是指专业技能的 Leader 在实际上并没有明确的权力。有些时候，双重报告的存在形式是一些「同级群体」或「同级委员会」，这些群体可能由于一些专业问题自发地形成，但是自主地决策解决一些 Leader 无法解决的问题。
我自己就亲自经过多次「同级群体」决策。例如，苹果规定 2016 年 6 月 1 日之后的应用必须支持 IPv6，这意味着我们可能需要升级全公司共用的网络库，于是我就在群里面发起了这个问题的讨论，一些人（主要是相关产品的 iOS 负责人）自发地参与了这个讨论，然后大家讨论出了一些方案和结论。
这种「同级群体」决策的成功，更大程度上不是某个规则的作用，因为我们很难明确出哪些事情需要跨部门讨论，也很难明确出这些讨论的负责人。所以，我们只能用一些企业文化或者做事方式影响大家。
所以，我感觉格鲁夫在本章其实并不是强调双重报告，而是强调在「任务导向组织」中，还应该有一只看不见的手，让大家在织织之间，产生协同、讨论和决策。
格鲁夫在本章中没有描述清楚这只看不见的手，他只把它称作「企业文化」，而这正是他在下一章将要展开阐述的内容。
第十章 每个人都听命于三个 “长官”
格鲁夫通过一个故事（故事中涉及买轮胎、遵守交通规则、主动帮助车祸的人）来说明一个人的行为，受三方面的影响：
- 自由市场因素：大家简单地以自己的利益作为行为指导，例如挑选商品时大多只会考虑价格和质量。
- 契约义务：通过事先达成的一致，然后履行契约义务。例如我们上班，就是和公司的一种契约义务。
- 文化价值观：一种为了组织利益，牺牲自我短期利益的行为，通常这种行为长远来看对个人也是有利的。
格鲁夫引入了 CUA 指标来帮助我们选择用以上哪方面的因素来指导人们的行为。CUA 分别指：工作环境的复杂性（Complexity）、不确定性（Uncertainty）、指令的模糊度（Ambiguity）。
程序员的工作就充满了复杂性，因为程序员需要不断地学习新知识，代码的逻辑和架构也可能很复杂。而市场的工作充满了不确定性，很多时候上司也无法帮你想出有新意的市场推广方案。
格鲁夫认为，如果一个工作的 CUA 因素高，而个人关注的是团体利益，那么就只能用文化价值观来作为行为的指导。但是如果个人关注的是自身利益，那么就会如下图显示的那样，情况变得「一筹莫展」。
格鲁夫举了一个例子，当海滩上发生灾难时，每个人都只顾及保全自己的性命，而救援工作需要极高的 CUA 因素，所以现场只会是一片混乱。
按这个理论思考，我们就能理解为什么要做火灾演习了，多次火灾演习可以极大地减少火灾发生的 CUA 因素，因为大家在演习中对于火灾已经有着明确的处理方案了，需要做的只是按之前演习中的契约行动就行了。
格鲁夫认为该理论对于指导新人也有意义：
让我们把这套理论套用在某个刚进公司的新人身上。由于初来乍到，他无疑比较关心自身的利益。因此，你应该给他明确的工作架构，降低复杂性及不确定性。
另外，该理论对于空降的高管也有意义：
对于空降的高管来说，就像起用任何新人一样，一开始他还是比较关心自身利益。但身为高级经理，他难免会被指派管理一个有问题的部门—毕竟这是我们从外面找人的原因。此时对这个经理人而言，他面临的不仅是烫手山芋，还有环境里很高的 CUA；同时，他也尚未建立起属于这个企业的价值观与行事准则。在此状况下，大家只能求老天保佑他能赶紧忘却私利，以大我为前提，并设法降低 CUA。如果他做不到这些，恐怕很快就会被撤掉。
文化价值观也不是银弹，在 CUA 因素低的时候，选择用自由市场因素或契约义务，都比文化价值观来得有效。所以，根据具体工作的 CUA 值，选择具体的控制模式，是经理人需要关注的。
不过话说回来，我仔细想了想互联网企业里面的各种职位，不管是产品、技术、还是运营，似乎都是高 CUA 因素的职位，所以文化价值观应该是互联网公司管理员工的基本方式。
很可惜，格鲁夫在本章中并没有详细介绍如何增强大家的文化价值观，他只是认为，管理者自己的行为示范，比把文化价值观挂在口头上有效。但是本书的第四部分，详细讨论了企业管理中人的问题。
第四部分：谋事在人
本部分涉及激励、工作成熟度、绩效评估、招人与留人、报酬与培训。
第十一章 激励部属参加比赛
格鲁夫将员工的问题分为不能和不为两类：
- 不能：能力不够。
- 不为：能力够，但是不够努力。
针对这两类问题，他提出了培训和激励两种解决方案。在本章作者并没有讲培训，主要详细讨论了激励相关的问题。
作者认为，激励应该和马斯洛的需求金字塔理论相符。
在「归属感与认同感」这一层，我们应该让同事们都喜欢当前的工作环境和同事关系，认同当前公司做的事情。同事之间的合作应该是愉快和融洽的，同事中还会有自己欣赏的牛人，有自己的好朋友可以一起吃饭、聊天。
只有产生了归属感与认同感，员工才会追求更高一层的「地位与尊重」。我们给那些表现优秀的员工更重要的事情，更高的职位，使得他能够在这一层上产生明确的目标。很多公司都会做职业发展的内部评级，其实就是给大家一个明确的地位与尊重的目标，让大家为此努力。
但是，「地位与尊重」的目标一旦达到，人们工作的动力又会下降。一些更牛的人，就会追求马斯洛需坟金字塔的顶端：「自我实现」。「自我实现」这一层的需求的差异性在于：
一旦某个人受激励的来源是自我实现，他工作的动力将不再受局限。这是自我实现有别于其他激励模式最重要的特点。其它的激励来源一旦在需求满足之后便不再生效，但是自我实现将不断激励个体向上突破。
有两种自我实现的动力可以促使个体将能力发挥到极致：精益求精型和成就导向型。
精益求精型的例子是音乐家、运动员，也包括程序员。拿程序员来说，一个程序员如果不断追求写出更牛逼的代码，那么他可以像阿里的多隆那样，成为合伙人级别的重要人物。
成就导向型的人常常怀有达成任务的决心，对于困难，他们喜欢挑战自我。其实做很多事情，刚开始都是需要面对失败的。成就导向型可以坦然地面对失败，然后再次挑战目标。
对于较高需求层次的人，失败的恐惧大多数是来自于内心而不是外界，如果不能克服自我内心的恐惧，那么这个人就会从自我实现的层次往下降。
一般而言，在较高的需求层次时，恐惧通常源自内在而非外在的威胁。人们经常因为过不了自己那一关而导致行动上的退却。但如果老是如此，这个人很快就会从自我实现的层次往下降落。
在具体实施激励时，格鲁夫认为，一个好的激励应该是目标明确的，并且这个目标应该是比较难以达到的，这样大家才会全力以付，发挥出尽量大的潜力。
如果我们想要让员工都能提升自我实现需求的层次，便必须先创造出一个讲求产出的环境。
另外，可以合理使用一些竞赛，让大家把竞技场上的争胜的心态应用到工作中。
工作的概念天生就不如竞技，我们干脆将运动场上的竞争精神融入工作。最好的方法便是先制定游戏规则，并让员工有衡量他们表现的尺度。
关于竞赛，我自己也有一些真实的感悟。我们公司很多人中午都会去游泳，之前大家都自己随便游，后来有一个同事说，我们分成两组，搞接力赛吧。虽然这是一个没有任何奖励的比赛，但是大家因为比赛，就会不自觉得更加努力游泳，连续多日下来，大家的体力都上升了很多。
关于激励，格鲁夫最后总结道：
经理人的角色在此便极为明显：他应当是个教练，身为教练，首先必须不居功，团队的成功来自于队员对教练指导的信赖；其次，他的训练必须严格。通过当一个铁面教头，他努力激发出队员的潜能，并刺激团队做出最佳表现。一个教练应该曾经是个好选手，因此他了解竞赛的规则以及选手在练习及比赛时可能面临的问题。
第十二章 工作成熟度
令人惊讶的是，即使较早建立起的管理理论多半靠直觉，后来的实证科学也并没有办法将它们推翻，或是证实某种管理风格确实较其他的更胜一筹。研究学者似乎必须下没有所谓最佳管理风格的定论。
格鲁夫首先通过英特尔在轮换经理人上的故事，引出了用「工作成熟度」（Task Relevant Maturity，TRM）来评估个人或部门。
根据工作成熟度的不同，格鲁夫建议用不同的办法来指导：
- 工作成熟度低时，指导应该是明确和具体的。包括做什么事情，何时完成，如何着手等。
- 工作成熟度中时，指导应该从具体的事情，转移到沟通、情绪上的支持与鼓励。
- 工作成熟度高时，指导只需要关注努力方向是否正确上。
格鲁夫说，我们在指导小孩的时候，也是符合这套理论的。刚孩子还小的时候，我们只会说做什么，不做什么；等他们长大一些之后，我们变成一些叮嘱和指导；等他们成人之后，我们基本上不再管教他们了。
指导的时候，我们应该注意建立共同的价值观。我们在猿题库也在这方面做了很多具体的尝试，比如我们强调：按时发布产品、代码质量、信息尽量共享、指导新人比日常开发工作更重要。这些都是在努力建立共同的价值观。
一旦员工了解了组织的营运价值观，又具有较高的工作成熟度时，主管便可以开始分权，进而提高自身的管理杠杆率。
格鲁夫在本章中也讨论了一个非常有意思的话题，管理者是否应该与员工建立友谊。他对此有两个观点：
- 我们不应该把友谊相关的社交活动与工作上的指导混为一谈。因为社交活动并不能直接在工作上产生帮助，当然，友谊对工作是有一些间接帮助的，因为它使得你们之间在沟通的时候会更加有效一些。
- 命令朋友其实是一件不愉快的事情。当你需要批评或直接命令朋友时，友谊可能会是一个阻碍。格鲁夫举了一个例子：当你需要给你的朋友打很低的绩效时，你是否感觉到非常难受？
对此我个人的感受是，适当的友谊还是非常有必要的，对于一些同事，经过一段时间的合作，我们其实是能够比较清楚地判断出来他们的潜力。如果我们认为他们的潜力是足够大的，在建立友谊的同时，在工作上也给予更多的指导，应该是一个更好的做法。
另外，建立共同的「就事论事」的价值观也是非常有必要的。大家是朋友，但是工作上应该批评就批评，如果大家有着对事不对人的共同价值观，批评就不是那么不可接受了。
第十三章 再难也得做：绩效评估
格鲁夫认为绩效评估是一个高杠杆率的工作，可以使得优秀的员工得到激励，从而更加努力。但是绩效评估又是一个非常难的事情，因为很容易产生冲突和争议。
绩效评估大致可以分成两部分：评估部属的绩效，以及将评估的结果告诉部属。作者认为，一个有效的评估报告应该包括：优点（需要有实例证明），缺点（需要有实例证明），如果在未来提高绩效。其实对于很多公司来说，绩效评估都是含混过去的。我现在所在的公司也没有详细到格鲁夫描述的那样的绩效评估报告。
不过，格鲁夫介绍了如何向一个完全不合格的员工传达绩效评估，我感觉很有价值。格鲁夫用解决问题的阶段来描述不合格员工的状态。
这些阶段具体解释如下：
- 忽视：表现不佳的员工最初会忽视问题。所以你需要找到具体的证据，让他无法抵赖。
- 否认：当员工开始否认问题时，事情其实已经有进展了，因为至少问题被提出来了。
- 责怪别人：责怪别人是一种很有效的防卫机制，因为员工可以以此为理由拒绝承担责任。所以这一步是关键，如果让他意识到不是别人的问题，那么就很容易进入到担起责任阶段。责怪别人到担起责任涉及的是克服心理障碍的问题，而从担起责任到寻找解决方案是能力问题，后者要简单得多。
- 担起责任：承认问题。
- 找出对策：双方一起找出问题的解决方案，并且实施。
格鲁夫把阶段分得很多，其实我倒觉得关键的阶段就是从否认责任到承担责任的过程，这个过程中，经理人需要收集到足够多的证据，尽量客观地沟通，另外强调就事论事的工作态度，才可能帮助员工克服心理障碍。
另外，即使到了最后的「找出对策」阶段，大家也可能无法达成一致，这个时候，格鲁夫建议不必在这阶段强求一致，只要员工承诺按经理的方案实施即可。我们不应该强求说服别人，因为这更多是一种心理上的需求。
你当然希望看到部属心悦诚服地同意你的看法，但如果他不是完全同意，只要他愿意采取改进行动，你就不该再在这上面伤脑筋。不要混淆了情绪问题和工作的需要。为了完成任务，你最需要的是部属愿意施行你决定的行动方案，至于他是否与你抱持同样的想法则是其次。期望别人凡事都和你想得一样其实并不是件好事，在工作上我们主要追求的是绩效，而并不是心里舒不舒服
我们在做绩效评估时，也应该把重点放在那些重要的员工身上，他们已经非常优秀了，所以找出他们的问题将会相对困难，但是他们在未来很可能承担更重要的工作，所以把心思花在他们身上是值得的。
格鲁夫在本章的最后建议，应该提前把评估报告发给员工阅读，之后再组织讨论，这样会使得员工对评价有所思考，之后的讨论更加有效率。
第十四章 招人与留人
关于招人，格鲁夫提到，仅仅靠一小时的面试，根本就不足以客观地评价面试者的水平。对此我是非常同意的。但是企业的成本有限，确实也没办法花费更多时间来考查面试者了，所以这是一件非常难，但是又不得不做的事情。
关于如何招人，其实无非就是建立一套方法论，然后希望以「较大概率」招到满意的员工。我听过很多别的公司的方法论，大家的面试方法都差别很大，但是我觉得都是做到了刚刚说的原则。我自己长久以来针对程序员、产品经理、产品实习生面试分别都有总结，在此就不展开介绍书中的办法了。
关于留人，书中提到最麻烦的就是重要的优秀员工想离开。对待想离职的优秀员工，第一步需要做到的是足够的倾听。
你应该马上放下手上的事情，请他到办公室坐下来谈，问他为什么要辞职。让他畅所欲言，千万不要和他起任何争执。相信我，你的爱将已经在不止一个失眠的夜里将这套词儿演练过千百遍。等到他讲完所有他要辞职的理由（没有一个会是好理由），你再多问他一些问题。先让他说个够，因为当他讲完了事先准备好的那一套词儿后，真正的理由也许才会显现。千万不要争辩，不要说教，也不要动气。
倾听之后，找到离职真正的原因，只能站在对方立场上考虑，如果是薪水问题，看看是否合理，该调整的话就调整。如果是工作内容，看看能否做一些公司内部的工作变动来帮助他找到更喜欢的工作。如果是当前公司的一些具体的问题，看看能不能做一些改进。但是，这些做法的前提都是：这是一个优秀的、重要的员工。如果是一个表现普通的员工提出的不合理要求，那么倾听之后可能也只能做一些形式上的挽留了，因为我们不能破坏公司的薪酬体系来挽留他。
第十五章 报酬的诱惑
大部分人的薪资都是结合他的工作表现+工作年限的综合评价，这其实是建立员工稳定期望和公平的一个方案。在我们公司，有一些优秀的应届生能够比一些老员工贡献更多的产出，但是我们确实无法一下子就给他老员工那样的薪水，大部分的时候，我们会给他超出同样工作年限的人的薪水。
以工作年限作为薪资的重要衡量手段，算不上特别公平，但是确实也没有特别好的办法。不过，当前互联网公司已经有一些创业公司开始打破这样的规则，他们给那些工作一两年的优秀员工非常高的薪水，因为事实上，这些员工的产出和那些工作五六年的员工差别不大，但是从性价比上讲，他们比那些工作五六年的员工要价少得多，所以多给一些也没关系。
在互联网公司抢人的时候，这种策略被大量的采用了。这造成了互联网人才薪资水平的差异被进一步缩小，大部分人的年薪都集中在某一个很小的范围区间。而那些工作多年的人，如果不能进一步提升自己的能力，就会陷入薪资基本停止不前的怪圈。
在本章，作者也提到，一般职务的提升都会面临工作内容的巨大变化，很多人处理不好，反倒会表现得很差劲，这便是著名的 彼得原理。
一名称职的教授被提升为大学校长后无法胜任；一个优秀的运动员被提升为主管体育的官员，导致无所作为。对一个组织而言，一旦相当部分人员被推到其不称职的级别，就会造成组织的人浮于事，效率低下，导致平庸者出人头地，发展停滞。
但是，对此我们又有什么办法呢？我们不提拔优秀的员工，难道提拔糟糕的员工吗？所以除了对提拔的员工悉心培养之外，也没什么好办法。
如果一个员工实在对新工作不感兴趣，作者建议还是让他回到以前表现优秀的岗位上。虽然刚开始有一些难堪，但总比他主动离职要好得多。
第十六章 别等火烧眉毛才培训
作者认为经理人应该是培训的责任人，不应该把培训交给外面的公司负责。因为经理人本身在公司内部具有权威性和可信度，他的培训内容更容易被理解，另外，每个公司的做事方式和文化都不太一样，自己参与培训才能够把正确的做事方式传递给大家。
设计培训课程花费的精力相当大，我当前就在设计产品实习生的培训课程，还好我之前有一些总结，否则第一次课可能都会耗费我大量时间。就算这样，我也不知道培训能够一直按计划进行下去。不管怎么样，只要开始了，总归是有产出的，而且我相信多做几次之后，我就可以建立起优秀的、系统的培训课程。
最后的问题列表
作者在最后留了一些很棒的问题，值得大家回答一翻。
如果你能从下列各项检验中拿到100分以上，以这本书的标准，你算是个杰出的经理人了。
★ 试着将你工作中的操作分为编制流程、组装及测试三个步骤。【10分】
★ 针对你手头开展的方案，找出限制步骤，并依此设计你的工作流程。【10分】
★ 找出你工作中最适合进行验货、线上检验与最终检验的地方。决定这些检验应该采用“海关”还是“监视器”的方式。然后考虑在什么时机下，你可以升格至“随机检验”。【10分】
★ 找出至少6项以上的新产出指标。这些指标应该要能衡量产出的质与量。【10分】
★ 将这些新的指标变成工作上的例行事项，并在部门会议中定期审视。【20分】
★ 你现在正寻找的最重要的战略（行动计划）是什么？描述你面临的环境需求以及计划进度。如果计划能成功地执行，是否能将你或你的公司带到理想中的境界？【20分】
★ 简化你最烦琐、最耗时的工作。至少让原有的步骤减少30%。【10分】
★ 找出什么是你真正的产出？你所管理的部门及影响力所及的部门的产出元素为何？按重要顺序排列。【10分】
★ 实际在公司中走动走动。然后，列出这次“出巡”中和你有关的事项。【10分】
★ 找一些借口让你一个月可以在公司内巡视一次。【10分】
★ 描述下一次你授权给部属时会如何督导。你将以什么为标准？怎么做？督导的频率是怎样的？【10分】
★ 列出你可以利用零碎时间进行的项目。【10分】
★ 列出和每一个部属“一对一会议”的时间表。（在会议之前向他们解释会议的目的，并要求他们作准备。）【20分】
★ 找出你上星期的日程表，将做的活动分为高、中、低杠杆率三类。设法多做一些高杠杆率的活动。（有哪些活动该减少或干脆不做？）【10分】
★ 预测下周有哪些事要瓜分你的时间。有多少时间要花在开会上？其中有多少是过程导向会议？多少是任务导向会议？如果后者占去的时间超过25%，你该如何设法删减？【10分】
★ 列出你的组织在未来三个月中最重要的三个目标，并一路验收成果。【20分】
★ 在与部属充分讨论过以上目标后，要他们也“依葫芦画瓢”—制定他们的目标并一路验收。【20分】
★ 写出“悬而未决”需作决策的事项。找出其中三项，试着运用决策制定过程的架构以及“六点问题”的方法。【10分】
★ 依据马斯洛的需求理论评估你自己的需求层次。并为部属找出他们所属的层次。【10分】
★ 给部属勾画他们的跑道，并找出每一个人的绩效指标。【20分】
★ 列出你给部属各种形式的工作所给予的相关回馈。他们是否能借着这些回馈来测量自己的进度？【10分】
★ 将你部属的工作成熟度分为低、中、高三类。并针对个人选出最适当的管理风格。并在你的管理风格及最适当的管理风格之间作比较。【10分】
★ 评估你上一次收到的或你对部属所作的绩效报告。这些报告对提高绩效有多大的影响？在上司告诉你报告内容或你告诉部属时，你们的沟通形式是怎样的？【20分】
★ 如果有哪一份报告不够理想，重做。【10分】
