程序员管理探秘：如何从带10个人到带100个人？_如何管理100人团队

如何处理冲突

在技术团队管理的过程中，冲突是我们永远无法回避的话题。是否具备处理冲突的能力，往往被当作评判一个管理者是否合格的标准之一。冲突也一直是重要的团队协作变量，所以团队间冲突与绩效的关系也是人们一直在探讨的话题，然而人们很少探讨冲突管理行为，这就导致大家忽视了在冲突中潜在的积极意义，所以让我们一起来正视冲突，选择策略并做好冲突管理吧！

了解产生冲突的原因

一般来说，产生冲突的原因有如下几种。

1）目标理解不统一

我们将这种冲突称为目标冲突，产生的原因往往是团队对目标理解不一致，制定了非协助性KPI，大家在实施过程中为了完成各自的KPI而出现相互干扰的情况。面对此类冲突，只需通过深入沟通、仔细分析达到对目标理解的一致性就可以解决。

2）多种技术方案选型

在大型技术团队中，团队成员的经历不同、对问题的解读不同，在技术方案决策上往往出现此类冲突，但是这种技术上的冲突往往具有积极的意义，可以帮助大家开阔视野。作为管理者，我们只需做好正确的疏导和决策就能化腐朽为神奇。

3）多项目并行引起资源冲突

由于项目紧急或排期不当，一个团队往往会出现同时承接多个项目的情况，这会导致团队非常疲倦，且因为不能专注于某个具体的项目，导致结果与预期背道而驰。此类冲突出现的主要原因是项目计划不当和应用资源不当，因此解决方案顺理成章地就是对项目进行更合理的规划，需要跟项目的提出方不断进行更深入的沟通，对项目做出更合理的优先级排序，以便充分利用有限的资源，让项目更有序地进行。

4）项目进度冲突

在实际的项目实施过程中，需求调整、方案变更时有发生，但项目完成时间又是事先敲定的，或因为类似“双十一”的特殊促销活动不能随意修改时间，就会经常出现研发人员工作时间与项目进度之间的冲突。大量的加班和不断变更的方案会让研发人员身心俱疲，因此需求提出方一定要对项目的核心目标进行认真、仔细的思考，并把每一步的逻辑和细节进行充分拆解。同时，项目的承接团队在需求评审时也一定要结合技术方案和业务需求进行更仔细的思考，以免在实施过程中出现较大的需求和方案变更。

5）团队成员的情感因素

团队成员间因情感因素发生冲突主要有如下原因。

◎ 个性不同：大家的沟通方式、方法差异导致沟通不愉快而发生冲突。

◎ 团员间的偏见：表现为对他人的观点不赞同，甚至一言一行都看不惯，这样势必发生冲突。

◎ 价值观不一致：表现为因经历不同、背景不同、观念差异而产生冲突。

此类冲突处理起来最为棘手，要求团队管理者具备一定的心理学及人力资源管理经验，能够在出现此类冲突时正确化解，以及对人员组成进行及时调整。

正确看待冲突

在大多时候，大家都认为冲突只会产生不好的结果，但是世间事都有两面性，冲突同样有积极的意义。例如，上述“多种技术方案选型冲突”就可以通过技术讨论拓宽视野，弥补冲突各方的认知盲区。

我们将冲突产生的积极意义归纳如下。

◎ 暴露问题，及时熔断。

◎ 促进了解，加快团队磨合。◎ 弥补不足，拓宽视野。

◎ 产生竞争，培养主动思考能力。

◎ 信息流动，引导创新。

◎ 团队涅槃，完善管理。

依据我们的经验，在各种技术会议上最恐怖的不是大家的激烈争执和讨论，而是死亡般的沉默，大家之所以不提问题往往不是因为技术方案完美无缺，而是因为完全不思考或根本没有听懂，所以技术管理者适当地发起讨论，引导并激发大家狼性竞争，也是管理行为艺术的表现。

消极面可能是大家想到或遇到最多的冲突表现，凡是影响团队存亡、技术发展、目标达成和团队团结的冲突，都需要加以干预和控制。这里还是以“多种技术方案选型冲突”为例，当双方对这种冲突僵持不下时，就会威胁到项目的进度，这就是冲突的消极表现。此时管理者需要及时介入并控制，以确保项目顺利完成。

处理冲突

管理者处理各种冲突的基本原则就是客观和公正，如果丢失了这两个原则，那么所有的策略基本无效，甚至会让事态变得更加剧烈和不可控。

1）强调目标和项目的意义，建立共赢意识

让冲突中的每个人都认识到大家是在一起完成一件有意义的事情，特别是在发生“情感冲突”和“项目进度冲突”时，明确冲突对目标的影响，唤醒大家的共赢意识，把冲突的各方从不理智的漩涡中拉出来。

2）搁置冲突，冷处理管理者应该对冲突的大小和影响范围有清晰的判断，如果只是很小的冲突且不会对团队及目标有任何影响，则可以采用不予理睬的冷处理方式，让冲突自行淡化并消失。

3）管理协调，双方妥协

当发生“项目并行人力资源冲突”，特别是需求双方属于不同业务线时，管理者需要将双方组织在一起，对项目时序进行合理调整，如果双方项目都必须同时进行，就需要对共有资源进行重新分配，而这种分配可能会造成交付时间延期。在这种情况下双方可能需要在项目交付时间或项目时序上做出让步。

4）建立制度，法治管理。

在冲突处理中，人治管理的最大问题在于管理者自身的情感控制和对事态严重程度的判断，这些稍有闪失就会对团队及目标产生消极的影响，所以最好完善制度，给团队划底线——让所有人都清晰地认识到底线在哪里，以及触碰底线的后果。

5）职务介入，强制执行

当事态已经发展到风险预警阶段时，管理者就需要快速做出决策。比如在上面提到的多种技术方案选型冲突中，如果双方仍然各持己见无法让步，管理者就需要快速做出决策和命令，确保项目顺利进行下去。

引导员工主动工作

相信没有任何一家企业希望自己的员工对工作敷衍了事，像木偶一样需要不停拉动才能工作。特别是在当前竞争如此激烈的市场环境下，企业更需要能主动工作和主动思考的员工，那些员工如木偶般工作于企业来说是一种极大的风险。

很多时候，我们的管理者把员工被动工作的原因归结为个人因素，例如员工情绪、工作动机、态度甚至个人素质等，这种被动状态下的工作效果可想而知，企业也不会对这样的员工有任何奖励。

殊不知员工的行为其实是环境的产物，除了需要员工自己努力，营造适当的工作环境也尤为重要，所以雇佣双方都应该积极想办法把工作从被动变为主动。

定义正确的角色及职权范围，是保障企业自我优化和成长的关键。笔者和很多企业管理者都有过沟通，在沟通过程中，几乎每位管理者都有相同的状态——疲惫。这种疲惫源于团队缺乏主动工作的思想，很多工作的决策、优化的思考都会落到管理者身上，其他人永远都在自己的“盒子”里工作，所以大家不难发现“盒子”成了阻碍大家主动工作的“牢狱”。

那企业里的“盒子”又是什么呢？在企业实际运行的过程中设置了很多部门和职位，比如总监、经理、主管、普通员工等，在日常工作里，每个上级的职位都被赋予了“家长”的角色，当这个“家长”迫切追求结果而越俎代庖时，就会让员工身处自己职位的“盒子”中，丧失了主动工作和思考的能力。

所以正确的方式是企业定义好员工的角色，让员工清晰地认识到自己应该承担的责任和能决策的范围，而不是把自己放在职位这个“盒子”里。例如，在一个技术团队里有主管、前端工程师、Java工程师这几种角色，那么主管的角色应该被定义为企业的路由器，肩负起拆解企业目标、团队发展、组织战术会议及团队间沟通的责任，而不是关心前端工程师或 Java 工程师的代码怎么写才能更好地实现目标，或者怎么优化这些代码才能更满足用户的体验。前端工程师和Java 工程师的角色就应该被定义成目标的落地者，所以这个角色的职责应该不停地思考怎样才能更好、更快地实现目标，考虑自己的工作对其他角色的影响，以及其他角色的工作对自己的影响等，而不仅仅是完成既定的代码工作。

我们可以通过以上方式把每位员工都放在一个被定义好且被赋予了明确职权范围的角色上，让其能自主工作而不是进行家长式的管理。布赖恩·罗伯逊在其《重新定义管理》一书中提到的“合弄制（Holacracy）”就是一种让员工能够自主工作的很好方式。合弄制有时也被称为全体共治，顾名思义，就是由角色来承担工作的管理系统。一项工作被看作一个“角色”，同一个人可以选择承担不同的角色，和其他人配合完成工作，按照角色分配权力。合弄制被认为是一种无领导管理方式，它将公司组织架构去中心化，将由人定义工作角色转变为围绕工作来定义，并且经常更新。

举个例子，我们的身体组织和运行方式，就是某种意义上的“合弄制”。人体的功能运转并非按照自上而下的指挥模式进行，而是一种分散系统：各部分独立运行，整体形成一个有机网络，每一个部分如细胞、器官及器官系统都能够自主接收、处理和输出信息。因此，当身体某个部位的白细胞发现了一种炎症时，它就无须把这个信息送到大脑，再等待指示，因为这样会延误抵御疾病的最好时机。实际上，白细胞就是“合弄制”中承担了抵御炎症这个“工作”的“角色”，它可以自主决定在发现炎症的时候产生抗体而无须等待大脑的指示。这样的运作模式，也保证了我们身体的正常运转，也正是当今企业的运转方式。

赋予员工做事的意义和目标，是打造高产出团队的基础，让员工有机会参与到宏伟的事业中，并且设置可实现的目标让员工报以希望地工作。虽然如此，在企业管理过程中，员工的个人需求和企业的需求往往没有办法完全达到一致。管理者要充分理解和尊重员工的个人需求，知道员工能承受的极限在哪里，而不是一味地采用压制的管理方式，把员工变成俯首帖耳的工作机器，很难想象这种环境下的员工怎能产生工作主动性和创造性。

因此，企业各阶层管理者需要在工作开始前跟员工进行充分沟通，让员工充分理解所做事情对于企业的意义。和员工一起制定合理的绩效目标，让双方在目标及需求上达到一致，才能营造一个让员工自主工作的环境。

在员工完成目标的时候，企业管理者应该对此做出及时的反馈，需要让员工更清晰地认识到自己对于企业的价值，我们将这种管理的方法称为“价值管理”。正如前面提到的，要营造适合主动工作的环境，一定需要跟员工一起制定合理的绩效目标。在制定目标时可以把目标从易到难地拆解成几个小的阶段，让员工能在阶段性的完成中收获到成功所带来的喜悦。因此，在员工完成每个目标的时候应该都及时地给予反馈，例如对好的赞许、对不足的鼓励及对困难的帮助，给予员工更大程度的积极暗示。通过跟员工分享结果数据，让员工能直观地看到自己工作方式的改变给企业带来的价值，并在潜移默化中让员工成为一个能主动工作的人。

如何从带10个人到带100个人

拿破仑之所以成就了“千古一帝”的伟大传奇，是因为他非常聪明地发现了利用文化的强大力量去推动战略实现的秘密。

当年，在巴黎的一个房间里，拿破仑和所有将领坐在一起，讨论如何攻打俄国，拿破仑说：“我们现在讨论的进攻计划就是战略，但是，让 100 万大军心甘情愿地向莫斯科进军的是文化！”那么，拿破仑是如何在军队中建立强大的文化来帮助他实现战略目标的呢？这就要提到拿破仑从一条绶带发现的秘密。“我有一个世上最奇妙的发现”，拿破仑曾说，“我发现人为了获得绶带愿意冒生命的危险，甚至宁死不惜。实际上，给我一条绶带，我会给你一支军队；给我足够的勋章，我能征服整个世界！”这里，拿破仑正是利用了军队的团队文化，将英勇善战和一个外化的团队形象标识“功勋绶带”连接在了一起。

对于技术团队的管理者而言，当其管理的团队人数从10个人转变为100个人的时候，在经历了初期的“权力更大”的欣喜之后，可能更多地面对困惑和迷茫。如果说管理 10个人的团队，可以用管理1.0方法的话；那么，管理100个人的团队，就必须升级到管理2.0。那么，管理10个人和管理100个人，有哪些主要区别？在管理上有哪些挑战？

如何升级到管理2.0？接下来一一详解。

在管理上面对的挑战

对于 10 个人的团队，团队管理者可以非常容易地叫出团队每个成员的名字，谁是什么性格，在能力和技能上的优势，在做什么事情，等等，都清清楚楚。在这个规模的团队中，技术团队管理者的核心要务就是完成关注点从“事”到“人”的转变，我们可以称这个阶段为技术管理1.0。这一阶段的特点就是：拍拍肩膀（即建设性反馈）比严肃批评更管用，吃饭、聊天（即工作之外的谈话）比绩效面谈更管用。

在阿里巴巴创业初期，每当有人做得不错时，马云就给予其口头奖励“加寿”，比如“这件事做得不错，奖励加寿 200 岁”。有个能力超群的员工，最后居然成了“九千岁”，至今被阿里人传为佳话。

这些，都是管理1.0的实例。当团队规模扩大到100个人的时候，作为管理者，你会发现已经开始没有办法对每个人都叫得出名字了。这时，只采用管理1.0的方法和工具显然不足以应对。总结起来，从带10个人到带100个人所带来的管理挑战主要包括如下内容。

挑战1：如何让团队统一目标和前进方向

所谓众口难调，当团队有 10 个人的时候，还比较容易协调大家的目标和前进方向；当团队人数扩大到100个人以后，每个人都会有自己的视角和利益，因而协调所有人保持一致的目标就变得尤为重要，也充满挑战。这也是拿破仑说出“让100万大军心甘情愿地向莫斯科进军的是文化”的原因。在巴黎那个房间里讨论进攻计划的将军们，就好比 10个人的团队，他们很容易对战略和方向达成一致；然而，100万大军，就好比这里所讲的100个人的团队，如何统一认知并执行战略，就是一个非常大的挑战。

挑战2：如何让团队高效地交付产出

在通常的组织中，随着团队人数的增长，组织层级越来越复杂。在10个人的团队中，在大多数情况下，层级为2：团队管理者和团队成员；在100个人的团队中，自然而然就会成立很多不同的部门，以及更多的层级，在这些不同的部门和层级产生之后，随之而来的是所谓的“部门墙”和“人浮于事”等问题。管理大师埃德加·沙因（Edgar H.Schein）教授就描述过一个有趣的部门墙的故事。

汽巴-嘉基（Ciba-Geigy）公司是一个位于瑞士巴塞尔的大型化学制药跨国公司，公司邀请埃德加作为顾问帮助公司建立一种变革的氛围，从而让公司以更灵活的方式应对周边不断变化的商业环境。

和其他大型公司类似，汽巴-嘉基公司也由大量边界清晰的业务部门、区域部门和职能部门组成。令人欣喜的是，随着对这些部门、组织了解的深入，埃德加发现在组织中某些非常具有创新性的想法和事情正在发生。作为建立变革氛围的一部分，埃德加将他认为好的想法记录下来并交给了公司联络人，并恳请联络人将其分发给其他也会从这些好的想法中受益的业务部门经理。

然而，几个月之后，埃德加失望地发现，汽巴-嘉基的联络人压根就没有把那些好的想法分享给其他经理，而似乎不同部门的经理也没有太大兴趣相互分享和传递新的想法。造成这一切的原因，其实是因为在汽巴—嘉基公司的文化中，大家都有一个共同的假设：即每个经理所分管的领域，都是边界清晰的“私人地盘”，未经允许，大家都心照不宣地互不侵犯。因此，这就可以理解为什么联络人没有把那些好想法分享给其他经理，而且不同部门的经理人似乎也对跨部门的沟通兴趣不大。汽巴—嘉基的文化让这些行为像未经邀请擅自闯入别人家里一样粗鲁。

除此以外，在软件开发团队中，还有一个特有的问题，那就是功能团队（Feature team）和模块团队（Component team）之争。例如，对于一个开发电商App的100人大团队来说，如何划分内部小团队的职能？

一种方法是模块团队的思路：10人小团队A负责前段，20人小团队B负责后端，10人小团队 C负责测试，10人小团队D负责持续集成。这样的好处是每个人团队看起来都职责分明，而且能够专注做一件事情，并且把这件事情做到最好。另一种思路就是功能团队：将电商 App 划分为 A、B、C、D 四个端到端功能（例如搜索、商品组织、订单处理、内容发布管理等），然后每个团队负责一个端到端功能。这样优势在于每个团队都可以减少对其他团队的依赖，能够独立地交付可以供客户使用的软件。

然而，一直以来，这两种团队组织模式都在软件开发组织当中不断被争论，也有组织不断从一种模式转换到另一种模式。其背后的核心，都是希望解决一个问题：如何打破部门墙，加强部门协同合作，从而一起更高效地交付产出。

挑战3：如何处理团队中的冲突和沟通问题

俗话说，“有人的地方就有江湖”，100人团队的内部冲突一定比10人团队的要多。因此，如何处理100人团队内部形形色色的冲突，是100人团队管理者需要升级管理“程序”的地方。

同时，正如专门跟踪全球软件项目是否成功的Standish Group在2013年发布的数据显示，在 2012 年，仅仅有 39%的软件开发项目取得了成功。对于大多数失败的软件项目，问题的根源都在于团队缺乏透明和有效的沟通。当团队人数从10人增长到100人的时候，作为一个技术团队的管理者，你会更迫切地希望寻找到提升团队沟通效果的良方。因为此时，团队沟通的问题也成为你的高效管理心头之痛！

从管理1.0到管理2.0

针对上面从 10 人团队到 100 人团队的三个管理挑战，这里有针对性地提供了从管理1.0到管理2.0的两种方法。

1.通过“文化和价值观大讨论”充分发挥文化的指南针作用

“企业文化、愿景、使命以及价值观，看起来这些东西似乎都是专门为那些做不出或者卖不出好产品的企业和团队准备的，花费精力在这些 MBA课堂上学到的东西只会影响到我们的正常工作，如果有时间的话，我们还不如好好执行我们的战略。”这段话听起来很熟悉吧？这是《科学企业管理：成为成功创业公司的 24 个步骤》一书的作者比尔·奥莱特在其成立第一家名为Cambridge Decision Dynamic的公司时的想法。不出意外，比尔·奥莱特的第一家公司创业失败了。

在后来的总结中，比尔·奥莱特说道：“这家公司之所以失败，不是因为我们没有好的技术和产品，也不是因为我们没有客户，而是因为它不能成为一家可持续、可扩展的组织——我们没有任何有意义的目标，无法形成团队凝聚力，难以度过困难时期。总结一下，我们没有一种强大的企业文化。”管理大师彼得·德鲁克曾经用非常有意思的一段话总结了这一点：“对于文化来说，战略是早餐，技术是午餐，产品是晚餐。文化会吃掉后面的其他东西。”

企业文化是企业价值观的体现，可以引导员工做出正确的技术和商业决策，可以让员工知道如何与他人相处和互动，也可以让员工在关键时刻（moment of truth）做出最佳的判断。优秀的企业文化可以在员工之间营造出一种凝聚力。

因此，作为一个管理100人团队的管理者，充分利用文化和价值观的作用，就能帮助完成从“团伙”到“团队”的升级。

具体怎么做？为了打造切实可操作的企业和团队文化，先让我们从企业文化的定义入手。企业文化，是一个组织由其价值观、信念、仪式、符号、处事方式等组成的特有的文化形象。因此，可以以这种特有的文化形象作为切入口，让团队成员通过充分的讨论形成一致的理解，从而让企业文化在团队中发挥如下作用。

◎ 胶水作用：让团队从一盘散沙变成有凝聚力和执行力的利益共同体。

◎ 地基作用：统一的文化是团队的“压舱石”，无论是在一路高歌猛进，还是在面临挑战和危机，都能让团队有稳定和坚实的成长基础。

◎ 标尺作用：共同的目标、一致认可的处事方式，都是在成长中团队成员衡量自己和他人工作的标尺。

◎ 罗盘作用：价值观指导了团队成员在工作中做出最优的决策，有了统一的价值观，无论环境如何变化，整个团队都能经由各个独立团队成员的决策整体朝正确的方向前进，就好似整个团队拥有一个共同的“罗盘”一样。有了这个共同的罗盘，“人心齐，泰山移”就能得以实现。

具体来说，经过验证，下面的方法和步骤能够帮助管理者在100人团队中打造统一的文化和价值观。

第1步：团队名称和形象标识讨论

为什么团队文化打造要从团队名称和形象标识开始呢？原因有两方面：首先，团队名称和形象标识讨论起来相对轻松，同时是团队文化中重要的组成部分，从这个领域开始讨论，能够让团队成员在轻松愉悦的氛围中进行想法的碰撞和磨合，为接下来的其他领域的讨论打下基础；然后，讨论团队名称和形象标识，能够帮助团队打造相互间的亲和感。正如西奥迪尼博士在《影响力》书中揭示的，人们都喜欢和自己有着共同特征的人，而讨论团队名称和团队形象标识的过程，就是团队寻找和确定共同特征的过程。

团队形象标识既可以包括团队 Logo、吉祥物、口号等大家共同珍视的东西，也可以包括团队故事，只要这些形象标识能够直接和明确地提醒和传递团队文化的核心部分即可。

第2步：团队价值观“内涵”和“外延”讨论

价值观是打造团队文化非常重要的一个环节。由于大多数企业都会有组织层面的价值观，因此在这一步实际上要做的就是如何让组织的价值观接上团队的地气，并且让团队对其“内涵”和“外延”都有统一的认知。在实践讨论中，一种推荐的讨论方式是利用如图8.3所示的价值观“内涵”和“外延”四宫格组织团队讨论。

图8.3

对于每一个企业，我们都可以准备一张大的白板纸，按照如图8.3所示划分为4个区域，同时给每一位参加讨论的团队成员发放若干张黄色便利贴。在讨论中，团队成员依次在便利贴上写上如下3个问题的答案。

◎ 问题1：我如何理解这个价值观。

◎ 问题2：哪些实际工作中的行为践行了这个价值观。

◎ 问题3：哪些实际工作中的行为违背了这个价值观。

在每一位团队成员都把便利贴粘贴到相应的区域之后，主持人邀请每一位团队成员把自己所写的内容分享给团队的其他成员。接下来，团队将利用类似“点投票”这样的“发散—收敛”工具，为每个人分配固定的点数，让每个人将点数投给自己最为认可的讨论内容，从而实现对白板上的所有便利贴进行分类合并和收敛，最后利用共识式决策的方式，留下所有团队成员都认可的部分。通过这几步，就完成了团队对这个价值观“内涵”和“外延”的私人订制。

第3步：团队处事方式讨论在企业文化的定义中我们看到，团队的处事方式同样是团队文化

中非常重要的一部分。然而，与团队名称、价值观等受重视程度不一样，团队处事方式往往会被团队领导者忽略。实际上，当我们对团队内部的低效决策或者不必要的内耗进行分析时，没有协同一致的团队处事方式常常就是造成问题的原因。

例如，对于软件开发团队，一个问题是：当我调用另一位同事开发的接口（API）进行编程时，我是否可以信赖他对接口的健壮性（Robustness）进行的设计和测试，这样我无须再进行额外的保护性编程。因为，冗余的保护性编程是一个典型的内部浪费。如果团队没有协调一致的处事方式，那将对团队的效率产生消极影响。

因此，我们可以在完成了对价值观的讨论之后，列举出工作中的一系列典型场景，让团队成员一起来回答：“基于我们认同的价值观，我们在这个场景中应该如何行事？”例如，常见的场景包括：

◎ 如何面对失败；

◎ 如何处理工作中的冲突；

◎ 如何给其他人提供建设性反馈；

◎ 如何管理风险；

◎ 如何在创新和本职工作间达到平衡；

◎ 团队是如何庆祝“胜利”的；

◎ 团队共同的假设和期望是什么；

在使用了上述三步之后，我们的团队将有如下收获。

◎ 团队名称和形象标识；◎ 对企业价值观的“私人订制”，即对企业价值观在团队中的“内涵”（是什么？）和“外延”（意味着什么？）的统一理解；

◎ 基于团队认可的价值观，团队协同一致的处事方式。

团队名称和形象标识能够大大增强团队成员与团队之间的连接，而针对团队特点“私人订制”的价值观，会成为团队中个人行为和决策的指南，而团队协同一致的处事方式，会成为价值观在实际工作中落地的最佳体现。有了这些助力，团队在打造高绩效团队上便又迈进出了坚实的一步。

2.巧用OKR

上面的管理2.0工具，主要关注通过团队愿景、文化和价值观这些思想层面的东西统一团队的认识。那么接下来，为了应对从管理 10人团队到管理 100 人团队的管理挑战之二——“如何打破部门墙，让团队整体有高绩效产出”，我们就需要有一个针对“事”的管理2.0工具了。

一说到“事”，大家往往会立刻想到“定目标，抓考核，严奖惩”，同时，浮现在脑海的一定有KPI这个工具。

但是就靠KPI，能否实现“定目标，抓考核，严奖惩”的目标呢？

在《谁说人是理性的》一书中描述了一个关于KPI的故事。

为了对授课教师进行评估，MIT专门开发了一套非常复杂的计算“教学点数”办法。虽然这套复杂的“教学点数”的发明初衷是希望从多个不同方面去衡量和评估教师的绩效，但是很快就发现，这套评价系统本身却成为目标，而非手段。正如作者提到的，“虽然我从课堂教学中获得了很多乐趣，但是我却发现我越来越少地把时间花费在和学生们在一起，因为花费同样的时间，我可以找到其他事情获得更高的‘教学点数’。我开始计算花费时间所产生的‘教学点数’回报，并开始选择那些回报高的事情，而非我应该做的事情，例如和学生在一起。这么做，并非努力去获得更多的快乐，我也并不认为那些得到‘教学点数’高的事情会让我的教学更加高效，我只是被动地迎合学校这个衡量工具的评价，因此我能做的只是在这套游戏规则中做得最好（实际上，我承认我的确获得了很高的‘教学点数’）……”

类似的情况一定也在我们的工作中出现过！正如托马斯·乔纳森（H.Thomas Johnson）和安德鲁·布鲁明（Anders Broms）指出的：在大多数情况下，如果不是所有的话，在工作中你衡量什么，就会得到什么，也只会得到这些。对于那些没有或者无法被衡量的部分，很遗憾，你无法得到什么。”

对于一个100人的团队，其目标和绩效一定是需要被衡量的，这样才能让团队成员朝着一个方向交付高绩效。但是，如何充分发挥KPI的作用，而避免陷入上面“唯KPI论”的陷阱中呢？这里要介绍一个有效的管理2.0工具：OKR（Objective and Key Results，目标和关键成果法）。

OKR 由英特尔公司最先发明和使用，但是被越来越多的人认识，更多地是在近年来被硅谷的互联网公司如谷歌、Uber、Twitter等大量使用之后。甚至有人认为OKR可以替代KPI对组织、团队和员工进行目标设定。实际上，我们认为OKR更多地应该和KPI一同使用，才能组成一个闭环的Smart KPI。为什么这么说呢？让我们先从OKR的定义说起。

OKR的含义是“目标和关键成果”，简单地说，目标确定了前进的方向，而关键成果能告诉我们需要取得什么样的结果，才能确保达到了预定的目标。另一方面，KPI能够对结果提供精确和定量的评估。因此，结合 OKR 和 KPI，就能够完整地涵盖目标、关键成果，以及结果评估这三个相辅相成的重要方面，从而形成一个目标设定、评估和持续提升的闭环结构。

具体来说，结合OKR和KPI，可以按照如下步骤实施。

第1步：根据目标和验收标准制订OKR（目标和关键成果）

在之前讲解技术领导力 4D框架时，介绍了制定目标和确定验收标准，接下来就可以根据制定的目标设定OKR中的目标部分，再根据验收标准确定OKR中的关键成果部分。例如，对于一个客户服务团队，假设在 2018 年设定的目标是提升客户的满意度，在相应的验收标准中包含一条“在 2018 年由第三方进行的本行业客户满意度调查中得分进入行业前三”，就可以据此制订相应的OKR，如下所示。

目标：提升“客户满意度”。

关键成果：

（1）降低对客户投或咨询的平均响应时间至30分钟以内。

（2）提升客户投诉或咨询的满意度到85%以上。

（3）在年度由第三方进行的本行业客户满意度调查中得分进入行业前三。

由此可以看到，在制订“关键成果”时，需要同时考虑过程和最终结果两个维度。

第2步：为OKR中的关键成果制订KPI

为“关键成果”制订KPI，才能够确保其得到精确和及时评估。因为“你衡量什么，就会得到什么”，同时，由于在制订关键成果时已经考虑到了兼顾过程和最终结果，因此相应制订的KPI自然也包括了先导性指标和滞后性指标。同样回到上面客户服务团队的例子，我们可以为关键成果制订如下KPI。

（1）关键成果1：降低对客户投诉或咨询的平均响应时间至30分钟以内。

KPI：先导性指标——对客户投诉或咨询的平均响应时间。

（2）关键成果2：提升客户投诉或咨询的满意度到85%以上。KPI：先导性指标——客户投诉或咨询的满意度。

（3）关键成果 3：在由第三方进行的本行业年度客户满意度调查中得分进入行业前三。

KPI：滞后性指标——第三方行业客户满意度评测得分。

第3步：在监测先导性指标过程中巧妙利用OKR进行纠偏

监测先导性指标，可以快速和及时地对目标达成情况进行反馈。

如果监测到先导性指标出现偏差，则可以再一次制订子 OKR 快速进行纠偏。同样，在上面的例子中，如果先导性指标“对客户投诉或咨询的平均响应时间”在某个时间段的监测中超过了40分钟（目标是30分钟），则可以立即制订一个子OKR。

目标：提升客户投诉/咨询响应速度。

关键成果：将对客户投诉或咨询的平均响应时间从40分钟减少到28分钟。

基于这个子 OKR，团队可以再做出更为详细的行动计划并及时采取行动，直到取得关键成果且相应的先导性指标恢复到目标范围内。

当团队管理者综合使用上述关于团队愿景，以及 OKR 的管理 2.0工具时，将会得到的结果是：根据团队的讨论达成一致的愿景或目标，以及相应的验收标准制订的OKR（目标和关键成果）。

OKR 中的关键成果能够同时覆盖过程和最终结果两个维度，同时每一个关键成果都有相应的 KPI。由于在关键成果制订时考虑了过程和最终结果两个维度，因此相应的 KPI既包括先导性指标，也包括滞后性指标。

并且，当KPI监测出现偏差时，也能够针对出现的偏差再次制订子OKR快速进行纠偏，从而形成“OKR 目标设定→KPI 监控→子OKR 纠偏→目标达成”的闭环。

如何对上管理

张强（化名）是一家电商公司的项目主管，最近因为项目延期万分苦恼。某个周末的下午，张强约了曾经带过他的项目经理小宇（化名）并向小宇请教。因为工作出色，小宇现在已经是公司的技术总监，在项目管理方面颇有经验。

在短暂的寒暄之后，张强就开始描述自己最近的困扰：张强最近在负责公司的一个核心项目，但是老板在项目实施过程中修改了项目方案，在这之后的一个月里，为了追上项目工期，张强组织项目组的同事们夜以继日地工作，但因为方案过于复杂，项目还是延期了。而张强也因为没有及时将风险上报给老板而受到了严厉处理，同事们也因为没有正向输出不停责备张强。

听完张强的描述以后，小宇与张强进行了如下对话。

小宇：老板提出修改方案的时候，你是否真正理解到他的意思？

若没有理解，你是否追问他直到得到一个清晰的答案？

张强：没有……

小宇：那你觉得老板当时提出的方案有问题吗？

张强：没有细想……

小宇：你在实施过程中发现风险发生时，有没有及时向老板汇报？或者向老板申请增加工时，或商讨替换方案？

张强：没有，我害怕受到责备！

……

不难想到，在上面这个案例中，小宇听完张强的回答以后一定面露难色。原因很简单：作为管理中的佼佼者，小宇非常清楚在张强的惨状就是典型的“对上预期管理不当”。造成这种惨状的主要原因如下：

◎ 对需求理解不透彻，没有做出正确的判断；

◎ 当风险发生时没有及时沟通。

那么，作为管理者，我们应该以什么样的方式做好对上管理呢？

下面一起来探讨这个问题。

做好对上的预期管理

要做好对上的预期管理，我们通常需要在如下两方面下力气。

1.彻底理解需求

所谓“知之为知之，不知为不知，是知也”，很多人在跟老板沟通时，为了保持在老板心目中的聪慧形象而放弃提问。然而，因为认知、信息来源和立场不同，老板在需求描述时给出的信息，不一定是所有人都能完全理解的，所以要敢于提问，理解、确认直至彻底理解需求，千万别带着疑问上路。

2.学会站在老板的角度理解KPI，求同存异

很多人面对老板提出的要求，会一味顺应。但老板不是神，很多时候也不能把问题完全想清楚。我们要做的，是站在老板的角度理解KPI，若发现老板的方案有问题，则请及时把他从神坛拉回，这就是求同存异。在KPI上和老板保持统一，但是带着脑子去听方案，你的老板需要的也是一个能理解清楚KPI及提出自己见解的人，而不是一个只会“拍手掌”的人。

及时汇报工作

汇报往往被视为工作能力的体现，甚至超越对员工工作能力的评估，很多人因为害怕出错或对领导存有个人意见而放弃汇报，让团队及自身变得非常糟糕。

要把工作汇报作为一个正常交流的过程，沟通双方就需要放下心中芥蒂，平等、客观、简单地交换信息，员工准确表达自己对工作的理解，让领导拥有做决策的依据。领导也希望员工能及时汇报，以更多地掌握关键信息作为决策依据。一言以蔽之：及时汇报传递信息、发现工作中的问题不光是为了减少公司损失，也是为了让领导更了解你，因为领导通常会思考如下问题。

（1）你的价值在哪里？研发工作者很难直接跟公司业务指标（例如营收，利润等）产生联系，所以其价值往往很难被定义，因此应当不停地思考且经常就思考结果与领导进行沟通，及时发现问题和风险并提出解决方案，通过这种工作上的沟通和最终的落地去展现自己的能力，用行动去做自我价值画像，逐渐回答领导心中的问题。

（2）在团队中的角色定位是否清晰？因为团队也背负着自己的KPI，所以在工作中遇到重大决策时，不要轻易、盲目地执行。毕竟你也只是负责团队中的一部分工作，很难了解到你的决策对全局的影响。所以，作为团队的一部分，我们需要及时将问题及自己的想法与领导进行沟通，让其掌握充分的信息，最终才能做出正确的决策。

刚才讲到及时汇报的重要性，这里再说说如何做好汇报。

（1）认真聆听。因为汇报也是一个沟通的过程，所以一定要认仔细聆听且理解领导的意思。

（2）简单扼要地表达。尽量用简洁的语言将自己需要汇报的内容表达出来，这样有利于领导获取信息，所以建议在汇报前罗列好汇报清单，而不是在汇报中组织汇报清单。

（3）客观描述，不要避重就轻。很多时候，大家往往会因为害怕

责备而放弃客观描述，但问题永远是客观存在的，迟早会爆发出来，甚至以一种糟糕的方式爆发，等到那时就百口莫辩了，而且很难挽回领导对你的正向认知。

有了上面这些知识“武装自己”，你就会发现对上管理也并非难事。只要不断提醒自己，清晰地了解目标，做好预期管理，学会更高格局地思考并且及时沟通，你就能在对上管理方面收获更好的结果。