《格鲁夫给经理人的第一课》读书笔记
背景
在职场，越往上走，越觉得管理是门学问。很好奇我的开发经理(Dev Manager)是如何工作的，他们每年给我们这些 “一线开发” 制定KPI，那他们的KPI是如何定义的，他们的产出在哪里？平时他们除了开会，就是回复邮件，这些真的能带来产出么？带着这些疑问，我淘到了一本英特尔前CEO格鲁夫写的一本 《High Output Management》, 里面详细介绍了如何衡量一个经理人的产出以及如何提升其产出的方法，令我感触颇多。这本书也帮助我理解了公司和团队日常开不同会议的目的和作用，以及经理人在其中的角色。
概括
这本书主要聚焦于企业中的中层经理人，教导他们如何提升自己的产出，管理好自己的团队。首先 中层经理并不是一个具体的title，他可以是一名工程师，或是会计师，无论怎样，他都是一个组织的骨干。
这本书的中心是围绕 产出导向 这四个字展开的。企业需要产出和利润，在这个目标的驱动下，企业中的每个人都需要产生对应的产出，这里面中层经理人的贡献是不可忽视的，他们就如同一支润滑剂，无缝衔接着决策层和工程师团队。产出导向主要涵盖以下三个方面:
- 经理人产出定义和优化
- 生产法则
- 团队意识 + 个人意识
虽说英特尔是个制造业公司，但格鲁夫提出的这些概念其实在互联网公司也得到了很广泛的应用。只不过互联网公司架构更加扁平，也有业内约定俗成的一套方式方法，例如各种Agile的实践，ceremonies等。但万变不离其宗，都是为了解决公司内部流程的问题，从而提高整个公司的产出。
核心
下面我们从三个维度(why, what and how)来展开 产出导向 这个核心概念。
Why
为什么我们强调产出? 结论应该是显而易见的: 往低说是保住饭碗; 往高说是获得更多晋升的机会，帮助公司创造更多的价值; 往远说更是帮助自己提升职场的竞争力。
格鲁夫在写这本书的时候说:
今天，处在人生中场的中年中层干部，失业的可能性大约是十年前的两倍。我观察身边的EMBA朋友们的职场动态，状况还可能越来越糟。其实我们不是任何“老 板”的员工，我们每个人都是自己职业生涯的员工。没人欠我们一个饭碗，你必须自己当家。认清只有你自己(不是你的“老板”)才是自己的主人。为打赢越来越 激烈的“保职战”，我们得好好提升自己的“产能”，增加自己的附加价值与生产力，不能有丝毫懈怠。一天24小时我们都该竭尽全力追求进步。
这段话在今天(2020)也显得格外应景和睿智。在Covid-19疫情下, 无数企业忙着裁员和重组，大量人员失业。在新西兰，甚至空姐都得去超市做货架员。在这种极端情况下，我们不得不去思考我们自己的定位，我们自己的产出是什么，我们的核心竞争力又在那里？
What
经理人的产出
那产出导向是什么呢? 如何定义一个人的产出? 下面我们就来用格鲁夫的公式来解释一个经理人的产出, 同样，也适用于我们自己。
经理人的产出=组织产出加总=a×A+b×B+c×C+...(a、b、c......代表管理杠杆率，A、B、C......代表各种管理活动.)
经理人产出是由两部分构成的: 直接管辖和间接影响力所及的组织产出加总.
先来解释下名词:
杠杆率: 各单项管理活动所带来的产出, 可以理解为单位产出.
管理活动: 可以理解为管理总量.
这个公式很好理解，每个经理人手下不止一个团队，每个团队也不止一个管理活动。当然，这些管理活动的定义是视情况而定的。举例来说，我们team现在的Delivery Manager直接管理着两个团队: 一个产品团队, 一个SDK团队. 产品团队对SDK团队有依赖; 由于我们的后台服务依赖Core Platform, 所以我们的经理还得经常和Core Platform的经理开会。除此之外，前台产生的数据最终需要数据/AI团队整理并生成报告送给客户, 所以我们也得经常和AI团队交流，确保数据的完整和准确。所以我们经理的产出总和就是直接管理的俩团队的产出总和加上间接影响到的Core Platform以及AI团队的产出。至于每个管理活动的杠杆率和管理活动总量我们无需纠结，只要知道他们代表什么就够了，因为在软件行业我们不这么定义产出，而是使用Agile的方式方法定义，例如scrum，我们有team velocity和spring goal，以及一系列的Agile ceremonies确保团队产出的稳定。
生产法则
在这点上，制造业和软件开发相似性很高。格鲁夫是这样定义生产的:
按预定的时间、可接受的品质以及可能的最低成本，依据顾客的需求制造及运送产品。
流程和限制步骤
完全和我们交付产品给公司或是客户的要求一模一样！英特尔的生产步骤可以总结如下:
- **制造: **营销和研发人员将一大堆的产品资料化为业务人员理解的销售策略，这个将资料转化成策略的过程便是制造.
- **组装: **将各种销售策略组合成完美的销售计划。在新产品上市的会议上，营销人员将最合适的策略和必要的市场资料(如竞争商品的价格和存货状况)结合产品说明、宣传册及活动挂图向业务人员报告。
- **测试: **在真正上市之前应先有一场虚拟的上市发布会。在此会议上，被挑选出来的业务代表要对策略及销售工具等等作出反应。如果反映不佳，亦即测试结果不良，整个策略就必须修改或重新制定，以符合原定的营销及销售目标.
软件开发也有流程，就是我们熟悉的SDLC:
1.计划: 明确需求, 设定交付时间线.
2.分析: 调研, 定义目标，例如项目目标以及产品的功能和操作.
3.设计: 流程图，架构图，UI设计，伪代码，文档，商业逻辑等.
4.实现: 功能实现.
5.测试以及集成: 单元测试，回归测试，烟雾测试等，集成系统，部署.
6.维护: 发布后线上监控, 修复问题等.
在生产法则中，格鲁夫强调了一个很重要的概念: 限制步骤。 流程中其他的步骤都是围绕这个限制步骤展开的，可以将限制步骤理解为最耗时，成本最大的一个步骤。那软件开发中限制步骤是什么呢？个人认为是实现阶段，即开始写代码的阶段。大多数情况下，在软件开发过程中，人工都是最贵的，一旦项目开始，就很难走回头路了。所以围绕实现前的3个步骤一定要仔细调研，给出清晰地需求和设计，而且要先做MVP(Minimum Viable Product); 在开发团队实现MVP的过程中，PO(Product Owner), BA(Business Analyst)要开始准备下一阶段的需求会议以及设计，这就是实现了时间互偿。
指标
这其实就是我们在平时工作中的 “Spint Goal”。一个Sprint一般是两周，也就是说在两周中，team要完成定量的工作，如果没有完成，即是没有达标。在Scrum中，每个team都有其 “Velocity”，例如每个Sprint是58，即两周时间，这个team可以完成58个story point。PO就可以根据team的速率来决定下一个Sprint要commit多少个point。
有了指标才好评判一个team是否有稳定的产出，也容易帮助经理发现和解决问题，从而提高他们管理活动的杠杆率。
杠杆率
一个活动如果有比较高的杠杆率，即表示同样的投入之下，这项活动会比杠杆率较低者有更高的产出。
这个反应在我们日常的工作中就是事物的优先级(Priority)。优先级高的，自然是对公司重要的，势必要给公司带来更大的产出，或者减少极大的成本开支。在日常的生产，或是开发过程中，经理人要发力在那些能给自己带来最大产出的工作上，这也符合公司的宏观目标。比方说：公司P有两个项目A和B，当A项目第一阶段告落得时候，公司要决定是继续投钱在A项目还是把重心移到客户更需要的B项目。结论显而易见，公司选择了B项目，那么经理人就需要把他的时间更多的放在B项目上，A项目每周查看几次就可以了，确保不会出现大问题即可。
团队意识 + 个人意识
“单丝不成线，孤木不成林”。经理人要想 “成事” 离开团队是绝对不行的，而且经理人产出的公式已经很好地反映出了这一点：产出都是团队合作的结果。
说到团队合作，我相信一线的工程师们肯定有很多想吐槽和质疑的点，甚至会有人觉得团队合作就是笑话，还不如自己一个人效率高等等。这种想法其实就是把自己限制在了工程师这个角色中，而不是跳脱出来站在一个更高的高度上看问题。人类世界，大部分生产活动都需要团队合作才能成功。我们开发产品，也要时刻记着我们的目的：按预定的时间、可接受的品质以及可能的最低成本，依据顾客的需求制造及运送产品, 而不是完成每一个特定的功能. 单兵作战能力再强，也敌不过对手聚而攻之。如果发现团队里有成员带不动，或者合作有问题的时候，我们是需要去解决他们个人的问题，而不是否定团队合作。
所以，除了团队合作外，个人意识也很重要。每个团队成员都需要各司其职，各尽所能, 才能保证团队有最高的产能。格鲁夫举了这样一个例子：
不管教练再怎么强，仍然得看队员们的努力，就像在球场上运球、上篮还是得靠球员的表现。
格鲁夫认为：如果一个人没有做好他的事，只有两种原因可以解释，要么是不为，要么就是不能。前者是态度有问题，缺乏诱因；后者则是无能为力。对于后者，大部分情况团队内的成员们会互相帮助，共同克服困难。如果真是因为能力不济，那么就要反思招聘和培训流程的问题。至于第一种情况，若是缺乏诱因，那么可以对症下药，找到激励员工的方法；如果员工就是 “老油条”，那么就要考虑绩效评估，多劳多得，保证一碗水端平。
只有做到 “点对点” 的沟通，经理人才能更好地了解团队的情况，针对不同成员制定不同的策略，最终保证的是整个团队的高产出。这也是为什么国外互联网公司经常有员工和经理(或者组长) “一对一” 的会议，就是确保沟通顺畅，及时解决问题。
How
我们已经知道了产出导向的含义，那如何提升它们呢？我们先前已经知道经理人产出的公式：
经理人的产出=组织产出加总=a×A+b×B+c×C+...(a、b、c......代表管理杠杆率，A、B、C......代表各种管理活动.)
那具体方法也很明确：
- 安排好管理活动的优先级，剔除低杠杆率的管理活动，代之以高杠杆率的活动
- 提升每一项管理活动的杠杆率
经理人每天要从事很多活动，需要区分清楚哪些能带来产出，哪些不能；并根据公司的目标，将高产出的管理活动放在优先级较高的位置上，确保团队优先执行。例如：每个sprint的planning，和refinement是必须放在高优先级的位置上的，因为这两个会议决定了当前这个sprint要产出和能产出什么。除了给管理活动排序，经理人也要知道如何提升高优先级管理活动的杠杆率，例如提升sprint planning和refinement的效率。
经理人要在开这两个会前做好充足的准备，或者让负责会议的product owner做好充足的准备，不要在会议中还在补充backlog中的task；经理人也要在会议前及时解决或者反馈团队遇到的阻碍，这样方便团队合理安排capacity(每个人每个sprint的时间)。经理人也要及时决策，不要犹豫不决，这样有可能会影响团队士气，导致效率低下。总之还有很多提升管理活动杠杆率的方法，核心就在于要和团队及时沟通，及时解决各种问题，这样每个管理活动的效率才能令人满意。
让流程的每个环节可控
软件开发有计划，分析，设计，实现，测试和维护几个步骤. 每个步骤都应该严格控制完成时间，以确保限制步骤有充足的时间去执行，不能无休止的去计划和设计。举个亲身经历的案例：我们公司要做一款 “Server-Driven”的移动端产品, 我们称之为 “white label app”, 意思就是任何一个客户接入时，我们不需要大量修改我们的代码库，只需要修改针对不同客户的配置文件就能自动生成专属于该客户的移动端产品。理念任何人都能理解，但是架构设计却没有一个人能够(愿意)去拍板决定，所以我们当时的经理带着我们连续和不同高层开了一个月的会，把“white label”的概念讲了一遍又一遍，最终还是我们自己做了决定。这样下来前前后后浪费了一个月的开发时间，也让一线开发们参加了很多不必要的会议。
这就是典型的没有把控好软件开发流程的一个例子，做了很多杠杆率不高的事情，导致产品推迟了发布。其实每个步骤都可以建立指标，例如产品设计我们要在两周之内完成，出多少张原型图，这些都是可以量化的。像英特尔有 先行指标，线性指标，趋势指标等等， 软件开发流程也可以借鉴，避免做重复无用功。
管理的必经之路: 开会
格鲁夫将开会分为两大类: 任务导向型会议和过程导向型会议.
会议是从事管理工作必经的媒介,你绝对无法避免开会，但你能让会议更有效率.
任务导向型会议通常是产生决策的会议，这类会议杠杆率很高，例如Sprint Planning，在这种会议上，团队要制定下个Sprint要完成的任务，决定产出；过程导向型会议通常是一些知识分享，注重与会者过程中学到什么，例如我们经常举办的 “lunch and learn”，分享一个话题，大家一起讨论，分享。这类会议有时也可以显著提升团队或者个人的产出效率，例如一些团队内部知识分享，能有效打破知识壁垒，也利于内部成员了解一些架构设计，避免日后返工。
以上是针对团队的会议，那针对个人呢？其实产出最终都会落到每个人的头上，经理人也需要市场关注团队内每个个体员工的日常工作情况。所以 “一对一” 会议就应运而生了。
一对一会议经常由经理或者是你的team lead来主持，大概每两周或者每个月举行一次。内容基本上就是询问你的近况，有没什么问题和担忧；如果临近绩效考核，还会和你谈谈绩效的问题。总之作为经理人，你要在一对一会议上想办法让部属把觉得心烦的事情说出来，这样才能帮助他们去解决，从而提升工作效率。要做好一个倾听者，集学生和教练的角色于一身，做好笔记，让部属觉得你很重视他们的反馈，这样才能提升一对一会议的效率，你也做了存档，避免忘记。
一对一会议的杠杆率是巨大的，试想你和部属每个两周开一次一对一会议，30分钟，就会影响他接下来两周，也就是80个小时的工作成果；如果在一对一会议中你们能建立和加强你们之间的信任关系，那对产出的提升是事半功倍的。同时，你也能了解部属的工作，建立共同的信息基础。
培训与激励(绩效)
相信这是大部分一线开发都经历过的事情：入职培训和绩效考核。入职培训个人感觉杠杆率不高，基本是走个过场；但技术培训则不同，杠杆率极高。比方说我入职F公司，进去第二天就接受了当时项目架构的培训，对我之后的工作的确是起了事半功倍的效果，阅读代码也能更快的理解含义，最终出活儿的速度和质量都得到了显著提升。
很明显，培训员工具有极高的管理杠杆率。举个例子，如果你必须为你的部门上4堂课，假设每堂1小时的课你要花3小时准备，那么你花在这次培训上的时间是16小时。你的部门如果有10个人，第二年他们在公司的工作时间将大约在2万小时左右。如果你的培训能将部属的绩效提高1个百分点，对公司而言便是多了200小时——而这只是你花了16小时的结果。没有受到良好培训的员工就算再怎么努力，结果仍然会是缺乏效率、成本增加、客户不满，有时甚至还会使公司陷入危机。
所以一个公司有完善的培训流程是很重要的，尤其是大公司，否则对新人来说是种折磨；对公司来说则可能造成极大的损失。
至于激励，我们的目的是用激励产生效能，也就意味着我们的激励要符合部署的内心。简单来说，有些人要钱，有些人要权，不只是权力，也有话语权。格鲁夫有句话讲的很好：激励是用来提高绩效的，而不是改变一个人的情绪或者态度。或许他的态度变积极，但是最终我们要看到新的产能出现。
就像治病救人一样，激励也是要对症下药。上图是著名的马斯洛需求理论。大部分员工是为了赚钱来工作的，那么公司就要满足最底层的需求，给员工至少每年和通胀差不多的工资涨幅；再高一层就是安全感，公司针对这部分员工可能需要提供保险补贴。我身边就有一个极好的例子，他选择的公司都是本地大企业(银行)，提供保险补贴，贷款优惠等，因为他有3个孩子，两位老人需要照顾，就职于这样的公司，隐性的福利大于工资的可能涨幅了；中间这层则是人类情感的需求，人们需要别人的认同，希望和志同道合的人在一起工作，也希望做的产品有价值甚至有趣；
至于剩下的两种需求，格鲁夫认为它们才是真正激励我们在工作上追求更卓越表现的原因。追求地位意味着你想在公司承担更多的责任和有更大的话语权，这点对于高级开发是极其重要的。高级做到一定年限后，你的下一个目标很可能就是带团队，做一个lead，这样可以让你跨越一个台阶，也会让你发现另一个不一样的世界。不过在现实生活中，升到一定阶段无法再升，或者达到了你升职的目标后，你的动力又会下降，会感觉没了前进的动力，这时候你就需要最顶层的 自我实现，只有它才能让你的工作动力不再受限，才能激励你不断向上突破。
格鲁夫具体介绍了两种内在动力：精益求精型和成就导向型. 我身边这两类朋友不在少数，第一种是iOS开发大神，自己做产品，给Apple亚洲区Unicode做贡献，不断向下钻研，人生理想是写出自己的编译器；第二种是不断的设定目标和达成任务，不断地在挑战自己的极限，完成一个又一个看似不可能的任务。
对于公司和经理人来说，个人觉得能做好前三点就很不错了，后两点个体差异太大，便不再多做讨论。经理人应该多了解部属，给予公平公正的奖惩，认证核实员工KPI，不要让员工寒心。
总结
刚工作的时候很不理解自我的价值在哪里，为什么我能拿这份钱，有市场行情的因素，但是我的产出又在那里？公司一线开发都是每天做着相同的工作，那绩效为何有高有低? 读完格鲁夫的书，我对这些疑问也大致有了答案，知道了我每个sprint出的feature和最终客户的销售业绩的联系，知道了自己的价值所在，为公司和客户赚了多少钱，知道了这些，我明白了我的产出，也明白了公司和经理安排这些考评流程和会议的意义所在，也知道了我自己时间的价值和我下一步的追求。总的来说有种拨开云雾，见到光明的感觉，很通透，很敞亮。也希望这篇文章能够帮助到你，对自己的产出有个大致认识和了解。