2014 年 Business Insider 有一篇针对 Google 创始人 Larry Page 的长篇报导《The Untold Story》，里面让我印象非常深刻的是：在 2001 年 7 月，Larry Page 决定解雇公司内所有的项目经理，理由非常简单：工程师不该被这群既不懂技术，又好像不输出任何实际工作内容的人领导。然而，事情并没有像 Larry Page 预想的一样，没有了项目经理的 Google 并没有变得更好，恰恰相反，重要的项目得不到应有的资源，公司里变得人浮于事，工程师们也得不到应有的反馈，对自己的工作感到迷茫而没有目标。
我曾经也一度不解，为什么项目经理这么重要呢？或者说，项目管理的必要性到底是什么？这些问题，只有在我自己工作了几年后，有了各种实战经验，才渐渐有了更深的感触。一般来说，很多人都遇到过这些类似的问题：
- 项目时间不合理：老板提出了一个宏伟的战略，一拍脑瓜下个月就要看到结果。然而团队加班加点，还是没法按时完成和交付，到时间点后老板觉得团队不给力，团队觉得老板压榨员工，再加上辛苦这么久也没有能够实际交付的产物，更加士气低落。
- 各种推诿和扯皮：由于项目往往是不同部门、不同职能的人组成的平行团队，许多时候会产生大量的推诿和扯皮。运营抱怨研发的运营后台做得难用，研发说是产品策划的不合理，产品说是交互设计师经验不够……团队很容易陷入一种负面的情绪当中，互相不信任。
- 团队理解不一致：例如，针对客户满意度下降的问题，公司临时组建了专项小组来做提升改善。客服部门反复优化了接听流程与话术，希望能让投诉的用户感受更好，结果，运营部门决定减少客诉的最佳方法，就是尽可能少地露出客服投诉渠道。
这些问题都是项目管理中最常见的一些情况，而其实这些问题，通过一些项目管理的手段都能够加以改善和解决。今天我们就来介绍一个简单的小游戏——打牌，一起来看看它是如何帮助项目更好地预估时间，以及帮助团队达成项目共识的。
打牌游戏是什么
打牌游戏其实是敏捷项目管理中用来评估项目规模的一个方法，完整的名字是计划扑克（Planning Poker），这个游戏规则是这样的：项目成员事先列出一张清单，罗列出项目中所有的具体事项，然后大家坐在一起，针对每一个具体事项，每个人打出一张扑克牌。这张扑克牌上的数字，代表了你对这个事项的规模评估。数字越小，代表这件事越简单，规模越小，所需要的时间越少；反之，数字越大，代表这件事越复杂，需要的时间多。这样，通过每个人的出牌，就能形成对项目中每一件事项的规模评估。
这个游戏最早起源于 2002 年，由 James Grenning 设计了最初的方式，随后在《敏捷软件开发实践》一书中被发扬光大。不过，它的核心思想的起源要更早，可以追溯到上世纪四五十年代的「德尔菲法」，也称之为专家调查法。这种方法的核心，是针对某个议题向多位专家单独发放问卷调查，回收后综合各位专家的意见，再次单独征询他们的看法，多轮后形成较为统一的调查意见。这里面有两点非常关键：
- 独立性：即专家或成员之间，给出看法时是相互独立的，彼此之间不会被对方的意见和想法所左右和影响。
- 多轮：通过收集 - 反馈 - 再收集这样的多轮反复，最终不断收敛，形成较为统一可靠的意见。
在对打牌游戏有了一个简单的认知后，接下来我们就具体介绍整个实践过程，你也会更加深刻地感受到这两点，以及认知到它是如何帮助预估项目时间，并帮助成员们达成共识的。
打牌游戏的具体实践
打牌游戏的具体实践主要可以分为三个步骤：1. 充分讨论；2. 同时亮牌；3. 不一致情况的处理。我们就以一个具体的案例，来依次介绍下这三个环节。
例如，你作为微信的产品经理，借 iOS 13 发布之际，希望为微信新增暗色模式。针对这个项目，该如何评估它的项目规模？
1. 充分讨论
在扑克游戏前，需要事先把项目拆解到更小的事项，然后针对每一个事项，依次进行讨论。例如，针对暗色模式这个项目，可以进一步拆解细分为这些事项：
| 事项 | 得分 |
|---|---|
| 重新定义微信 UI 的明/暗色规范 | |
| 使用 iOS 13 的 SDK 进行开发 | |
| 处理暗色模式下图片与视频的展示 | |
| 提供切换明/暗模式的设置选项 |
在打牌游戏的第一个阶段，其实和牌面完全无关。在这个过程当中，最重要的是使团队间充分讨论，理解这个要评估事项的细节，如果还有模糊不清的地方，不断补充完善细节，使之更加清晰。例如，针对「提供切换明/暗模式的设置选项」，团队成员可以充分讨论：该设置是否提供自动的时间段切换，还是完全跟随系统全局情况？除了在设置选项外，是否需要有快捷操作入口让用户一键切换？……通过这一系列追问与探讨，大家会对事情的执行细节和边界，有更清晰的认识。
2. 同时亮牌
在经过充分的讨论之后，游戏主持人可以组织大家亮牌。
在亮牌环节，非常重要的一个原则是，不同成员应该同时亮牌，彼此之间不应该有先后顺序。这和我们前面提到的独立性原则是相关的，只有大家同时亮牌，才能确保彼此不会互相影响，每个人都能够给出独立的判断。
3. 不一致情况的处理
亮牌之后，大家可以看到彼此的数字大小。这时候，难免会出现分歧。例如，针对「使用 iOS 13 的 SDK 进行开发」这个事项，有的人给出的牌面是 3，有的人给出的牌面是 13，整整相差了数倍，这时候该怎么办？
特别需要注意的是，打牌游戏不应该只进行简单的取众数，甚至是取平均数的作法。打牌游戏的精髓，正在于发现不同个体间的差异后，通过多轮的再次讨论和修正，最终达成共识。
这时候应该从最小和最大出牌人开始，让他们给出自己的出牌理由。只有在这个过程当中，你才会发现，哪怕有再多的事前讨论，在许多时候，我们对于一个事物的理解和考虑，仍然有着非常大的差异。
- 出牌 3 的人发言：我看 WWDC 上苹果已经给出了整套的适配方案，既然有了系统级的支持，这个开发下应该很快；
- 出牌 13 的人发言：WWDC 上提供的那套系统默认适配方案，在微信里几乎没法用，我们需要自己重新定义所有的界面色彩。另外，还需要考虑到安装升级 XCode 13 的时间，我们现在都还没有升级到最新的开发环境。
你会发现，经过这一轮发言，又增添了更多信息。在这个案例中，显然出牌 3 的人过于简单化的考虑了，而 13 的人则考虑得更加充分周全，显然更具有参考性。在听完新一轮发言和讨论后，全体可以再出一次牌，这时候的最终结果，应该会更加统一了。这个过程一般经历一到两轮，团队成员之间的出牌，应该就不会有过于悬殊的差异了。
因此，从中你也发现了，打牌游戏的重点，并不是在于统计大家的数字大小，而是通过这个过程和数字的差异，大家不断提供新的见解和看法，修正和拉近彼此认知间的鸿沟，促进团队成员之间达成共识。
最终，对项目的所有事项完成打牌后，就能得到一个得分汇总表，并根据项目投入的人力资源和工作效率，得到大致的项目时间预估了。
| 事项 | 得分 |
|---|---|
| 重新定义微信 UI 的明/暗色规范 | 5 |
| 使用 iOS 13 的 SDK 进行开发 | 13 |
| 处理暗色模式下图片与视频的展示 | 5 |
| 提供切换明/暗模式的设置选项 | 3 |
| 总得分 | 26 |
| 项目的人*天效率 | 4 |
| 预估项目周期（天） | 6.5 |
注：
- 预估项目周期（天）=总得分/（项目的人*天效率）
- 「项目的人*天效率」指项目投入的人员，每个人员每天能完成的点数，比如两个人，每个人的工作效率每天是两个点数，那就是 4。
打牌游戏的细节探讨
到这里，你应该可以实践打牌游戏了。不过，在实践的过程中，你可能还会遇见这些细节问题，我们也在这里一并探讨一番。
用实体卡牌还是虚拟卡牌？
打牌游戏自然要有牌，最常见的当然是实体牌了，大家面对面坐在一起，出实体牌也会更有气氛。你甚至可以找几张硬纸卡板，自己裁剪制作一套简易卡牌。不过，如果想要更加精美的卡牌，直接在淘宝上搜索「敏捷扑克」购买也是一个不错的选择。
但是，如果你所在的团队采用远程协作的方式办公，那么虚拟卡牌就会更加方便。我个人感觉最好用的是微信小程序中的「Scrum敏捷估算」，在同类工具中做得相对较好，不但可以邀请微信好友在线出牌，还可以统计每一轮次的结果。这一点其实非常重要，保留了这些历史数据，在实际项目执行时，就可以比照当时的估算结果，从而在项目复盘时回顾当时缺少考虑了哪些因素。
值得注意的是，你可能发现了这个小程序中提供的「计算方法」中，包含了「算术平均数、中位数」等等选项，这和我们刚刚在上一节提到的，打牌不应该使用平均数或众数并不冲突。小程序里提供的这个计算方法，并不是让你将其作为最终的打牌结果，其实际的作用，是方便让你比较不同成员打牌分数的偏离程度，从而可以从偏离程度较大的成员开始优先发言。
当然了，虚拟卡牌肯定没有面对面打牌的气氛感。我个人更偏向于使用微信小程序的虚拟卡牌，不仅仅是因为它提供了更实用的统计数据，还有一个非常重要的实战因素：当你使用实体卡牌一段时间后，你会发现每次进行打牌游戏，时间总会浪费在找卡牌在哪，或者发现漏掉了几个牌面不见了，从而浪费了时间。而用虚拟卡牌，则显然不会有这些烦恼。
卡牌上究竟应该放哪些数字？
当你准备购买或者制作卡牌时，会发现事情没这么简单。因为不同的卡牌，他们的牌面数字好像不尽相同。最常见的，是这两种牌面数字选择：
- 第一种：0，1/2，1，2，3，5，8，13，20，40，100，无穷，？，咖啡；
- 第二种：1，2，3，5，8，13，21；
细心的你可能发现了，它们的共同点，是都有 1，2，3，5，13 这几个数字。这几个数其实是一个斐波那契数列，即一个数是前两个数之和，例如 1+2=3，2+3=5，3+5=8……依次类推。
那么，为什么打牌游戏使用了斐波那契数列呢？其实这和任务估计的精度有关，越小的数字，代表的任务越简单，这时候的估计相应更准。反之，越复杂的任务，12 和 13 的差别就不大了。这就像如果你要去附近一家店，这家店离你是 100 米，1 千米，或者 10 千米，对你的交通方式选择差异很大。但如果你的出程计划安排的是从北京飞往上海，那么这两个城市是相距 1000 千米还是 1100 千米，其差异对你选择何种交通方式出行，就几乎没有影响了。
至于像下面这种卡牌中「无穷」、「？」、「咖啡」这样的功能牌，则显得有些无聊。「无穷」和「？」表示你认为无法估计，「咖啡」表示你累了想休息一会儿。
在实际的应用中，我个人认为功能牌几乎没太大作用，其实真正需要的牌面，有 1、2、3、5、8、13 这几个就够了。再大于 13 的牌面，则这个被估算的事项还是太宏大了，应该被进一步地拆分再来出牌。
卡牌上的数字到底代表了什么？
当你准备好卡牌，试图组织卡牌游戏并向大家介绍时，往往会被问到这样一个问题：卡牌上的数字，到底代表了什么？会不会出现，我认为 1 的工作量，和另一个人认为是 10 的工作量是一样的？的确，在进行游戏前，应该先统一度量单位，让大家明确每个数字到底对应了多少工作量。
打牌游戏并没有强制规定出这些数字的真实意义，不过，一个较为常见的作法，是认为数字 1 代表了一个工作日下一个人能完成的工作量。换言之，数字 10 是十个工作日一个人能完成的工作量，或五个工作日两个人的工作量。当然，这只是最常见的一种做法，因为打牌游戏起源的敏捷项目管理，其针对的产品研发周期，往往是以天为计算的。如果是更偏运营类的工作，你也可以把数字对应到小时的单位。总而言之，只要在游戏前团队内部能够达成一个统一的共识就行。
打牌游戏只能适用于敏捷项目管理吗？
虽然打牌游戏最早是在敏捷项目管理中提出的，更偏向于软件开发类的项目。但是除了软件开发类的项目管理外，它的适用范围其实挺广的。运营类的项目也完全可以使用打牌游戏来估计工作量规模，促进团队达成共识。从这个角度上来说，打牌游戏对团队管理的帮助也很大，如果你是团队的 Leader，在团队管理的过程中，有两个老大难的问题：一方面，团队成员之间的工作量分配不均衡，从而也会导致团队成员之间彼此心生不满。另一方面，团队成员之间彼此不了解互相在做的事情，无法产生协同效应。
现在利用打牌游戏，你可以试试：先不分配工作到人，而是把工作拆解后，一起来进行打牌游戏。这样就提供了一个机会，每个团队成员都可以了解整个团队所有在进行的工作，不会仅仅局限在自己的工作上。同时，事先进行打牌估算出每个工作的规模后，再根据规模去分配给团队成员，可以做到使不同团队成员的工作总规模大致是相同的。
写在最后
项目管理本身是一个很大的话题，打牌游戏只是敏捷项目管理中一个非常实用的方法。在本文的最后，我想回到文章开头 Google 开除所有项目经理的往事，谈一谈项目管理的必要性到底是什么？
其实，任何公司的运作本身就是一个项目，随着公司规模的扩大，这个项目也变得越来越庞大。这期间，项目管理所处的地位，也在不变更迭着。在公司还只是一个车库内的雏形时，没有人需要项目管理。这时候，项目的目标是如此的清晰，例如，对于最早的 Google 而言，就是用一种更好的算法，更高效而又准确地索引互联网 Web 内容。公司的每一个人，都对这些项目目标如此清晰，以至于不需要多余的管理流程，就可以实施项目。或者反过来说，如果你在这时候就需要被项目管理，那你不应该出现在那间车库里。
当项目规模扩大时，当项目目标逐渐升级为公司愿景，从一个更高效的算法，变成「组织全世界的信息，使人们能够随时随地地使用信息」，你必须承认，越来越多的人，是没有办法对「全世界的信息」这类概括的字眼，形成一个统一的共识的。
而很多人也经历过 Larry Page 的心态。在内心深处，他们是如此渴望一切保留最早时期的高效与自发，以至于排斥任何形式的工程师需要先向项目经理汇报。这是一个艰难的转折点，你必须深刻地认识到，随着规模的扩大，人员的增多，你不能指望每个团队成员都是你自身的复制，像你一般如此清晰而又深刻地理解目标的指向。
这是一个成年的过程，任何项目不可避免都会显得平庸了一些，引入了更多的流程管理、制度规范和绩效考评等项目管理措施，你开始看到那个好像什么都不懂的项目经理，天天来你的座位上催问进度，而他明明一行代码都看不懂。
可是，如果暂时放下这样的偏见，等到回过头来看的时候，似乎没有哪个成功的项目，可以独善其身，完全不引入任何手段来做项目管理。你应该不曾见过哪家公司，仅仅雇佣程序员来敲打代码，最终创造出了伟大的产品吧？项目管理之所以被需要，在本质上是为了解决规模问题。由于项目规模的扩大，不得不引入更多的团队成员，而人员规模的扩张，将引导一系列的连锁反应。
最核心的困难就是由于信息不对称引发的项目目标的模糊。「有目标的才叫团队，没有目标的一群人，只是团伙」，这个说法非常常见，而随着规模的扩张，一千个人眼中，就有一千个哈姆雷特。这对于艺术欣赏可能是一件好事，但是，在项目执行中，这可就是一个大问题了。本质上，这就相当于每个人拿着各自略有偏差的指南针，埋头朝着各自认为正确的方向出发了，直到抬起头来，发现只剩下了你一个人。
项目管理的各种方法论和工具，归根结底其实是希望能做到一件事：把形形色色、各不相同的团队成员，通过项目管理变成一个行动高效的一体。
希望未来有机会和大家交流分享更多关于项目管理的实战和心得。