前言
1. 网易杭研项目管理的前世今生
（无）
2. 互联网产品项目管理之我见
无论是新手还是老人，谈及互联网产品项目管理，有几个痛点必然是共通的。
一是讲究快。互联网的交付速度是以周、天甚至小时来计算的，而大小需求又交错其中，因此，我们不仅需要以短迭代快速交付，更需要有快速应变的研发能力
二是弱矩阵。大多数互联网企业的项目经理，都生活在弱矩阵结构下，背负责任但却手中无权，需要通过“软实力”构建自身的影响力，继而影响团队达成交付和改进。
三是阶段和角色多样。与传统IT项目管理相比较，互联网产品项目管理同样需要从研发项目管理切入，对项目的成功交付负责。无论是瀑布还是敏捷的方式，项目经理都需要关注范围、时间、质量这几个核心要素。但前后的延展同样需要，向上游的产品端延伸，向下游的运营、销售、客服延伸，最终形成完整的产品项目管理闭环，从而真正有效地取得产品成功和团队改进。不仅如此，不同阶段的互联网产品所需的项目管理方式也各不相同，孵化期、发展期、稳定期的特性各异，产品的生命阶段和团队成熟度阶段交织在一起，项目管理更需要随需应变。
因此，比较强硬的、统一的、完善的项目管理流程和度量，在互联网公司中几乎是不可能实现的（好，我应该去掉“几乎”这个词）。要不要学PMBOK？要，因为那是基本的项目管理框架；要不要学敏捷？要，因为那是非常符合互联网特色的研发方式和精神。但是，真正的高手，不在乎招式，无所谓门派。
3. 从今夜起
我们将这些内容分为四大部分：
• 第1章 我是项目经理 介绍了项目经理们日常基础工作的一些做法和感受。我们既讨论了基础的估算、计划、站会、白板、报告、回顾、风险、沟通等该怎么做，也提出了新手在初任项目经理阶段所需要注意的问题及修炼之路。从本章中你会对项目经理的基本工作有个基本的认识，了解这些看似简单的工作怎样才能真正做好。 • 第2章 高度延伸 在前一章节的基础上，对项目经理们的日常工作做了进一步深挖，从有效管理和提升的角度，思考了各个阶段项目经理们实操工作背后的深层原则和思路，针对一些复杂问题进行了更系统的整理。在这部分末尾，你会对项目管理工作及其价值有更深的认识，也可以对若干个典型问题有更完整的解题思路。
• 第3章 宽度扩展 探讨了若干个项目管理和与业务结合的实战过程中的实际问题以及我们的实践方式。这章集结了数据分析、跨项目沟通、项目管理工具等实践，读完这一章你便能清楚地知道该如何掌握项目的方方面面，它们覆盖整个产品面的管理业务。有了这些工具与武器，你便能在项目中如鱼得水，做深做透。深入产品，帮产品赢！
• 第4章 深度修炼 当项目经理经历了多年项目日常工作淬炼后，升华到另一个境界——自我修练与管理能力提升，此时该如何管理好一个团队？该如何持续提升自己的核心竞争力？当遇到困境时该如何突破自己、更上一层楼？本章借着小鱼儿的故事，把项目经理成长的历程，真实又逗趣地呈现在你面前。
第1章 我是项目经理
1.1 给项目经理新手的五个建议
1.2 项目管理境界之一二三
1.3 估算那些事儿
1.4 工作时间打扑克？——扑克估算之我见
1.5 走一步，看三步——怎么做好进度计划
1.6 我们是如何开每日站会的
1.7 我的站会感悟
1.8 白板的艺术
1.9 不简单的周会周报
1.10 让你的报告会说话——如何有效、有料地进行工作汇报
1.11 项目管理≠烦琐的会议
1.12 高效回顾，引导团队从优秀到卓越
1.13 项目管理从零开始
1.14 悬崖边的舞蹈——小议风险管理及在互联网项目中的应用
1.15 心的修炼——项目沟通的四个原则
1.1 给项目经理新手的五个建议
建议一 多想想项目到底需要什么
“我们应该每天都开个站会沟通一下情况，另外这个工具也要换一个，××比这个好用多了。” 有的项目经理拿到一个项目，上来就开始左突右攻，恨不得把十八般武艺都套上，结果很可能惹来不必要的麻烦，且收效甚微。接手项目之前，与项目中的重要干系人加强沟通，理解前因后果，多想想项目到底需要什么，对于项目的成功推进至关重要。
建议二 不要凡事恨不得事必躬亲
影响他人去驱动一件事情，要难得多。简单来讲，成功地施加影响有三个要素：获知（Awareness）、动力（Desire）、能力（Ability）。事实证明，停留在浅层次的信息传达，比如单方面的工作交代，并不足以让人产生动力从而促成有效的行动。获取理解及认同，激发动力是项目经理努力的关键。最后，还要确保他有相应的能力来做好这件事情，例如初期提供一定的辅助、必要的培训等，能推动事情真正付诸执行。
建议三 不要追在别人屁股后面做监工
“好，我不亲力亲为，活儿都分出去了，我监督大家把事情做好吧。我先跑去问A，这个做好没有，A反馈说这事你得找B和C，于是跑去问B和C，一天下来各处跑遍了事情还是没个说法，反倒讨了一身没趣。我该怎么办？” 其实，项目经理最该做的，是跟大家一起把事情从头到尾各个环节捋顺了，建立一套对应的流程规则，明确各个角色在过程中的职责，并获得大家的认同，让这个机制自行运转起来。记住应该是规则在约束大家的行为，而不应该是项目经理。当成熟的秩序在团队中形成之后，解放出来的项目经理，就可以更进一步，致力于目标激励、团队建设等更高层面的工作，变“赶”为“引”。
建议四 言必信，行必果
“刚进入一个项目，人微言轻，发给大家确认的邮件没人回，组织开会人叫不过来，多次提醒某人均被无视，提的建议没人在意，一个没有任何授权的项目经理菜鸟如何建立属于自己的领导力及影响力？” 无权力下的领导力（Leadership without Authority）是弱矩阵结构下的项目经理必修的一堂课。适当的时候，懂得巧借力，会帮助你争取支持与重视，但 要记住的是讨巧的东西必不会长久。要想建立属于自己的领导力，核心在于真正赢得团队对你的信任，建立自己的可信度，打造个人品牌。而信任的获取，靠的是一件件事情中一点一滴的积累，没有捷径可走。 首先，在专业上做足功课，要求别人做的事情，自己要做得更专业，起到表率作用；再者，言必信，行必果。学会为每次会议、每次发布、每个跟进事项做收尾，发出去的邮件、自己说过的话，哪怕没人记得，也要有始有终，自己给自己一个响应，给大家一个交代。
建议五 不一定要强势，但一定要内心足够强大
一个专业的项目经理会尽可能让自己客观、公正。但无论多么客观，你都会遇到形形色色的人，持有形形色色的世界观和人生观，一定会有一些麻烦，最终归结于“人”的问题。哪怕你已经尽全力尝试，依然无法改变某些人认同你的观点，有些思维方式根深蒂固，怎么办？ 这个问题一度让我受挫，但经历了几次类似事件之后，我渐渐明白，我无法改变他人，我甚至不应该试图那么去做！真正应该和可以改变的只有我自己！于是，我学会了允许和接受这种差异的存在，并与之共处；我学会了求同存异，找出一致的地方并努力放大。一个好的项目经理，不一定强势，在一些事情上可以让步、可以妥协，但内心一定有自己的坚持。
1.2 项目管理境界之一二三
本文从三重境界说明项目管理循序渐进之道：做项目，懂业务，懂人。做项目是让项目进行下去，懂业务是知其然知其所以然，懂人是能够在利益相关人满意的基础上交付项目。
境界一 做项目
记得我自己在第一个项目交付过程中，还不知道什么是项目管理铁三角、不知道敏捷，只是根据以前的耳濡目染和对相关领域的了解，拉上几个人，分工、计划、绘制甘特图、跟踪进度、加班、项目交付、完事儿，一系列工作做下来发现也能保质保量地交付项目了。当时就想项目管理不怎么难嘛，只要跟着计划走，把既定的事情搞定就可以交付项目了。难道项目管理真的这么简单吗？
对于一个定义非常清楚、一次性的项目这么做应该没有什么问题，这也是项目管理的最起码的要求，概括而言，就是在项目管理的铁三角的相互制约下交付项目，如图1-1所示。这一境界的项目管理能够满足基本要求，但往往很多时候基本相同的项目团队成员在做完一个项目后还需要继续做后续的项目， 甚至还是相同的项目发起人，那么在这种情境下需要步入后续的境界二、境界三，而不仅仅是境界一的“一锤子买卖”了。
境界二 懂业务
在这层境界中，项目管理的介入时间点需要前移，参与项目立项前的讨论。理解业务，能够成为业务部门可以依赖的左膀右臂，而不仅仅是被动地接受项目安排，根据设定好的铁三角约束条件交付项目。你需要从业务的角度出发，去引导和参与规划、定义项目，提炼出项目，化被动为主动，清楚地知道为什么立项这个项目，它所带来的业务价值是什么，是通过衡量哪些不同方案和利弊后才做出这样的选择的，外部环境有什么样的制约。项目的最大风险是公司内部风险还是外部市场／政策风险。只有自我认同项目的价值，才能在后续项目执行、讨论过程中遇到问题时能够说服其他项目成员，也能够获得其他人对项目目标的认同。
虽然说互联网领域瞬息万变、唯快不破，但仍然可以引导业务部门做出一段时期内的规划图（roadmap）（如1个月到3个月的规划），促使业务部门、从业务发展的角度去思考未来一段时间该领域最重要的事情是什么、项目做成后将有什么样的收益。项目经理在这期间应该参与讨论，并发挥引导作用，引导建立该业务领域的重点事项规划图，然后根据具体情况设定不同优先级的项目，并进行相应的项目管理和交付。
在这一层级的项目管理范畴中，需要在境界一的基础上加入对“业务部门的持续发展”的理解。项目经理能够想业务之所想，从业务角度出发去做项目，也能够权衡项目对业务部门的重要性，概括出如图1-3所示的项目管理约束条件集。
懂业务不仅是指对业务领域熟悉，还包括对实现其业务需求的产品方案的了解，知道使用哪些技术来实现，以及对技术实现过程中的难点和重点需要有 清晰的把握。例如，要想熟悉仓储物流业务，就需要去仓库参加定期盘点、打包、理货、上架、入库审核等一系列的操作，才能真正对业务有深刻的理解。
境界三 懂人
同一业务领域中前后不同项目参与的人员基本相同，但人员的诉求各不相同，如果能在项目的交付中结合个人的诉求，既能交付项目，同时也能满足项目成员的个人发展要求，将是大家乐于参与的项目。例如，测试同事希望通过参与API接口测试的相关自动化测试开发工作，来提升自己未来的市场竞争力，项目经理可以考虑在时间要求不是那么严格的项目中安排相关的自动化测试工作。
另外，需要带着同理心去交付项目，“士为知己者死”。例如，一起和项目团队共同加班，对产品方案一起沟通讨论。又如，在强制要求996工作制的部门中就不要再想方设法去压榨项目时间了，因为大家已经处于一种比较高压的状态中，此时应该想想如何为项目减压，建立“防火墙”机制，如通过项目优先级的调整、人力聚焦于重点项目来使非重点项目的节奏稍稍缓和一点，让人员轮番参加重点项目，将马拉松变成一站一站接力赛。
总结起来，项目经理要活儿好、让人满意、及时进行“上下左右”不同对 象的汇报沟通，从做项目到关注业务的发展、再到对人的关注。因此对这一境界的项目交付结果的衡量还需加上利益相关人的满意度，拥有一种平衡组织中不同人诉求的能力（见图1-4）。
从做项目、懂业务到懂人虽然是一个递进的过程，但对于不同的环境仍然需要灵活应变，在不同的组织环境中需要将重点放到不同的境界。
1.3 估算那些事儿
说在最开始
对于估算，团队常常会有这样的困惑：花了大把时间来估算，最后却发现与实际还是有不小的偏差，到底有没有必要做估算？怎样来做估算？
回想一下，会不会有这样一种经历：打扫卫生，让房子从凌乱到整洁只需要20%的努力，要让房子从整洁到一尘不染却要花费80%的努力。那么我们就要审视一下，在精力有限的情况下，从整洁到一尘不染有没有必要？
回过头来看我们在项目中的估算是不是也可以类比，从无估算到有估算其实花的是比较有限的精力，但是从有估算到追求“准确”估算却是个漫长的过程，并且有数据显示，我们花一些时间得到的估算数据与花费大量时间而得到的结果不会差很多。《敏捷估计与规划》这本书中提到，估计的准确度和投入的工作量之间存在图1-5的关系。
因此我们认为估算还是需要做的，有了估算，在团队协作中，各角色才知道自己大概要在什么时间安排什么工作。但是在估算的时候不必花费大量的精力强求精确，更何况我们也无法做到精准。估算只是估算，只要做到尽量合理、尽量贴近真实值即可。
估算单位的选择
1. 理想人日
理想人日是指成员在不受干扰的情况下，全部时间都用于开发需求所需的天数。理想人日的劣势在于：小组成员对技术和项目的熟悉程度、个人的经验和能力不同，会导致基于理想人日的估算值有一定差异。例如，你问一个擅长C语言的成员某个需用Java开发的功能的理想人日，他也许会告诉你是5天。 但是你问一个擅长Java的成员同样的问题，他的回答也许就是1天。这样的差异会导致我们对任务规模认识的偏差，很难衡量项目的实际“大小”。而它的优势则在于：对于团队外部的人来说，理想人日更容易被理解，无须解释。对于团队而言，它使估算更容易开始。
2. 理想人时
理想人时 理想人时是对应理想人日而存在的，只不过它的粒度更小。在熟悉需求的情况下，用理想人时的估算会更准确些。
理想人时的估算优势就在于：在充分理解需求的情况下，能帮助团队做到更靠近真实值的估算。而缺点是：对于一些大的需求无法做到如此细的粒度。
3. 故事点
故事点来自敏捷的概念，是对任务规模的估计，它是一种相对概念。例如，需求X为4个故事点，需求Y为8个故事点，则表示Y的规模是X的两倍，但并不表示开发Y比开发X要多一倍的时间，因为这还取决于由什么样技术熟练度的人员开发。故事点的优势在于：一方面，基于故事点的估算更纯粹，不会因为开发人员的变更、时间的推移而改变。换句话说，项目半途有成员离职，加入新的成员，此时我们不需要对每个任务都重新估计，只需要重新评估一下是否需要调整插入到当前迭代的故事点数。另一方面，由于人们往往更擅长于相对估算，所以故事点会让估算更迅速。想象一下，让你估算一杯水是另一杯水的几倍，是不是比让你估算两杯水各是多少毫升来得更容易呢？劣势在于：一方面，由于编程语言不同或者业务分块，大家很难找到一个共同熟悉的需求作为基准，那么用故事点作为估算单位的方式就很难开展了。另一方面，故事点相对于其他估算单位更难被理解，这也使估算难以开始。
估算的几种常用方式
1．自下而上的估算
由每个开发人员估算自己的任务时间，然后将所有的任务汇总，并考虑过任务间的依赖关系后，就排出了计划。该方式适用于具有以下特点的团队：成员间业务独立性强，相互之间的业务熟悉度不高且熟悉成本较大，较难进行共同估算；各成员的经验相对丰富，对自己的任务能进行较准的评估。在这样的团队应用该估算方式有以下优势： • 估算效率较高，各自任务的估算可以并行进行。 • 准确度也会较高，因为大家对自己的任务和能力都比较熟悉。
2．专家判断
由一个或多个专家根据相应开发的情况给出任务的估算值，但前提是你能找到这样一个熟悉整个项目所有业务和整个项目团队成员的专家或专家组。笔者所在的团队一般会由开发领导者来充当这样的角色。它的好处显而易见： • 通常不需要太多的时间。一个人估算就不存在太多的交流成本。 • 准确度有一定的保障。有证据说这种估算方法比其他分析性方法更准确
3．扑克估算
该方法是以扑克牌的形式进行估算。估算开始前，每个估计者会分到一叠扑克牌，每张上有一个数值，如0, 1, 2, 3, 5, 8。然后由负责人对某个需要进行估算的需求或者任务进行讲解，讲解完之后，所有人可以向该负责人提问关于该条需求或任务的问题，直至足够了解，然后所有成员各自挑选一张扑克牌代表自己对该条目的估算。例如A给出8，而B只给了2，这样就需要A和B各自说明自己估算的理由。这样一轮下来，大家对该条目又加深了了解，然后进行第二轮估算，如果相差还是很大，则继续下一轮。大多数情况下至多经过两轮，大家的估算值已经非常接近了，就可以取平均值作为对该条目最终的估算。扑克估算的好处在于： • 集合了所有团队成员的意见，比一个人估算少了很多主观成分。 • 在估算过程中，强化和深化了大家对需求和任务的理解，将任务考虑得更加细致，降低了不确定性给计划带来的冲击。 • 这种形式使相对严肃的计划和估算变得更加有趣，但是不得不承认，这需要比前两种方式更多的时间成本。 如果你们团队对于这种估算方式的接受度较高，能够找到一个故事作为基准，大家的编程语言一致，有能力评估同一个需求，就可以通过这种方式把需求的理解做到位。另外，这种方式也可以演化一下，当团队成员间对某个需求的工作量有较大分歧的时候，就可以让团队采用这种方式来达成一致。
实际应用中的估算实例
1．故事点＋扑克估算
Datastream 团队稳定合作近2年，尝试敏捷1年多，开发语言统一，长期服务于一个产品，成员间对相互的业务也都比较熟悉。 估算单位和估算方法：由于很容易找到大家熟悉的一个用户故事作为基准，团队选择基于故事点的扑克估算。团队在经过几次迭代之后，基本上确定了团队的开发速率（每个迭代能完成的故事点数）。在接下来的迭代中，团队通过扑克估算确定了每个用户故事的故事点，再根据用户故事的优先级一个个插入迭代开发计划中。扑克估算促使大家把对需求理解的不一致提前暴露出来，能在很大程度上减少交付成果和需求不一致的情况。
2．理想人日＋专家判断
网易云硬盘 组成：9人团队 现状：团队组建不到3个月，开发语言不统一，成员比较年轻，对系统的熟悉程度也不高。 估算单位和估算方法：一方面，由于成员之间的业务熟悉度不高且开发语 言不统一，团队无法轻易找到一个合适的基准用户故事，所以团队的估算都是基于理想人天开展的。另一方面，由于开发人员数量较多且一部分成员经验比较欠缺，无法很好地进行团队估算，所以团队选择采用专家判断（开发领导者给出估算）为主的方式进行计划。
3．理想人时＋自下而上
网易用户中心产品 组成：20人团队 现状：团队组建约3个月，产品模块较多，不同模块有不同的负责人，成员对自己模块的业务逻辑比较清楚，但是对其他模块的业务了解甚少，且一人会同时服务于几个项目。 估算单位和估算方法：由于成员间业务熟悉度不高且开发语言不统一，团队无法找到合适的基准故事点，而且一个成员并行任务较多，成员自己都很难判断自己的安排是否合理，所以需要更精细化的估算单位，团队因而选择理想人时作为估算单位。另外，也由于模块较多，开发领导者不能熟知各业务逻辑，所以团队采用了自下而上的估算方式，由成员各自估算各自的任务，进而给出开发计划。
各种估算单位和估算方式本身并没有好坏之分，只有合适不合适之说。每个团队都需要根据成员和项目的现状来进行选择。随着项目阶段的变化，以及人员的调整，估算的方式都要随之变化。以上所述也只是在一些项目的某个阶段、某种状态下的例子。如果生搬硬套只会弄巧成拙，得不偿失。
关于估算，我们需要注意的点
（1）估算仅仅是一个预测，当对外（或者对老板）承诺项目完成时间的时候，最好提供一个日期范围，让听者知道你的估算只是预测。 （2）不管用什么估算方法，将任务分成更细粒度总是有利于估算的。 （3）团队需要练习估算方式并且收集反馈。每次估算对应的开发结束后，大家需要回过头看看我们当初做的估算是否合理，如果不合理，那么就要分析原因，并且在下一次尝试中做调整。 （4）估算需要反复进行，当项目进行到一半时，发现估算过于乐观了，就需要对剩下的工作进行重新估算。 （5）当发现团队成员经常过于乐观或者过于悲观的时候，我们需要采取相应的措施。例如，有的团队经常比较乐观，那么我们在整体规划的时候就需要给出更多的预留。而当有的团队过于悲观的时候，我们的计划又要适当做得更激进一些。
1.4 工作时间打扑克？——扑克估算之我见
为什么要做估算
估算本身很困难，而花在估算活动本身上的时间，又并不能够对产品本身产生直接的价值，那么为什么我们要花时间做估算呢？为什么气象中心还是坚持不懈地发布自己的预报呢？ 首先，用户需要一个预期，甚至承诺，这个功能什么时候都需要提供。 其次，管理层需要可预测性，某些决策需要基于估算而做出，即便这个估算还不那么准确，但总是聊胜于无。 最后，团队需要了解如何相互协作，在哪个时间点能够拿到所需要的接口或素材，据此相应地规划并安排自己的工作。 总之，估算可以帮助我们找到一个合理的计划，给用户、管理层以及团队自己一个稳定的预期。
为什么选择相对估算
传统的估算方法，通常是基于人天／小时的绝对估算。而敏捷中所推荐的扑克估算方法，则是基于故事点的相对估算。这种估算一开始容易让人找不着北，大家会习惯性地问：“那这个故事点到底代表什么？单位是什么？做完了相对估算是不是还要再转化为人天？与人天的对应关系又是什么？”
首先，相对估算更符合人的本能认知。电脑区别于人脑的一大特点，就是电脑更擅长计算与处理绝对信息，而人脑则对相对印象更有感觉。我们可能永远搞不清楚手上的核桃和苹果的真实重量，但却能很直观地判断出苹果更重，重量嘛，大概相当于“6个核桃”。瞧，这就是人类的本能认知。 其次，正是因为相对估算更符合人的本能认知，因此掌握之后，它能让估算过程变得更快、更简单。因为我们不再需要纠结于这个任务到底需要5天还是4.5天，我们只需要为手头的工作定义一个参照物（1个核桃）作为基准，然后拿其他的工作与之相比较，工作量是更大还是更小、复杂度是更高还是更低，然后给出一个大约的倍数值就可以了。
相对估算需要转化为人天吗
在实施Scrum的项目团队中，最后得出的故事点的数值，不需要再转化成人天，这是由Scrum的特性所决定的。 在Scrum项目中，我们会以迭代（sprint）为周期来做增量交付，这直接改变了做计划的方式。传统项目中，我们需要根据基于人天的估算来确定各节点及最终发布的日期到底是几号，而在Scrum项目中，周期是事先约定好的。每个迭代的计划不需要确定日期，而只需要估算下一个迭代我们能完成多少工作。由于迭代固定周期性的特点，在几个迭代之后，我们就会得出一组相对数据（如35个故事点），来衡量团队的生产效率。根据这个生产效率，我们可以很容易地快速进行相对估算，不需要转化为具体人天就能得出结论。 当然，如果这是你的第一个迭代，没有经验数据，可以尝试转化为人天找找感觉，或直接根据团队的直觉来做出判断。 如果你是在传统项目中做扑克估算，那么我的建议是可以直接用人天来进行估算，虽然不如相对估算那么便利，但至少可以获得各种好处。
扑克估算有什么好处
1．团队一起做估算，估算更全面细致
在传统的项目管理中我们也会做估算，WBS分解后完成任务分配，然后 每个人估算自己的。如果每个人只对自己的那块比较熟悉的话，估算结果往往会有欠考虑，特别是相关性较强的模块，会出现较大误差，从而为项目后期埋下潜在风险。 在用扑克估算法时，一开始我们特意不进行任务分配。对于每个故事，都会由全员出牌，包括各个模块的开发及测试，每个人从自己角度出发想问题，互相补充。比如在扑克估算时，测试的成本会被自然地考虑进去，作为一个整体来衡量。对于测试成本高的故事，大家会一同来考虑进行哪个层级的测试更为合适，单元测试、API测试，还是UI测试？这样涵盖了各方成本估算的结果自然会更全面、更细致。
2．团队一起做估算，需求探索更深入
实践中我们会发现，真正到了让你给出预估的时候，就会有各种各样的问题冒出来。这个需求到底要不要做，是否要满足哪个条件，等等。扑克估算让这个需求探索的过程公开化，通过公开讨论，在早期进一步挖掘和明确需求，帮助我们将需求探索进行得更为深入。
3．团队一起做估算，有助于优化解决方案
大家一起亮牌，经常会有不一致的情况出现，比如一个人出5，另一个人出40，这个时候往往是团队成员间交流解决方案的好时机。问问你的团队，为什么相差这么远，这样的讨论能够帮助大家找出最优的解决方案，并在团队中迅速共享。
如何进行扑克估算
（无）
后记
（无）
1.5 走一步，看三步——怎么做好进度计划
没有战争是根据计划而胜利的，但是没有计划，战争也无法胜利。 ——艾森豪威尔 请思考一下这句话的逻辑。 首先，我们承认战争的胜负受很多计划外因素的影响，计划不是万能的。其次，战争胜利离不开计划，计划是至关重要的。 正如同“钱不是万能的，但没有钱，却是万万不能的”。在项目管理中，进度计划也同样拥有举足轻重的作用。
别怕做计划
计划的本质，是团队对何时完成任务的承诺。从心理学层面来分析，排斥做计划的真正原因，在于人们不愿轻易做出承诺。人人都有一种言行一致的愿望，一旦做出承诺，来自内心和外部的压力会迫使我们按照承诺去做。但也正是由于这种下意识的一致性倾向，才让进度计划真正有效。 或许你会说：“我们并不是没有做计划，但计划的执行往往是有问题的，做了也没用啊。” 因为计划的执行有问题，就不去做计划，这种逻辑无异于因噎废食。
计划要趁早
做计划时经常会听到有人说，等策划案定了再说吧，现在也不知道具体做什么，计划做了也是白做。 的确，任何人都很难在早期估计一个项目所需要的时间。说实话，刚刚接触项目管理时，我也是这么想的，后来几次实践下来，渐渐领悟到“越有太多不确定，越应该给出计划”。在混乱不清的状况下，你根据仅有的少量信息给出了期望值，就好比挖了个坑，人们自然会来填满它。马上就会有人跳出来指出哪个时间点肯定不行，哪里不靠谱，渐渐地计划变得越来越充实，越来越准确。更有意思的是，经历了这个指手画脚的过程之后，你会发现人们开始下意识地按照计划做事，那个最初不靠谱的计划竟一步步变成了现实！ 项目经理应该做头一个挖坑的人，引导团队拨开重重迷雾，将所有不确定一一落地。否则，模糊的概念永远停留在高层或某个人的脑袋里，不会对团队产生任何实质的影响。 做项目如同下棋，高明的棋手，走一步看三步。好的计划必须领先于项目实际，要有一定预见性。
调整计划要谨慎
计划绝不是固定不变的，相反，计划是调整的基础与依据。在整个项目周期中，为应对随时可能出现的变更，计划永远是个反复修正、渐进明细的过程。另外，在项目进程中，随着信息越来越详细，估算会越来越准确。因此，计划需要持续地改进与调整。 但计划的调整绝对需要谨慎，一个天天调整的计划会渐渐失去公信力。重要的是，要确保项目中每个人知道当前的计划是什么，调整计划需要怎样的决策过程，需要谁参与决策。在我们的项目中，与进度计划有关的任何变更，都会提交至项目经理，由对应功能小组成员（该功能模块涉及的策划、设计、开发、测试）及其他相关方共同讨论，明确各方影响，最终做出决策，并公告所有项目组成员。
计划诞生记
1．项目立项前
这时的计划比较粗略，可将目标按照功能体系分割成几个重大里程碑，并给出里程碑完成的时间点预期。根据项目周期长短，时间可以估算到季度或月。此时的重点要给出立项的时间表，如图1-7所示，何时完成初期调研及评估，何时做好立项准备、启动项目。立项时间表使得项目各资源方有了明确的预期，以便提前做好资源调配。
2．项目立项后
各项人力资源逐步就位，根据对团队生产力的经验估计，结合启动过程中对里程碑的大致预期，进一步推导出需求确认、设计确认、功能完成等中间节点，如图1-8所示。
3．需求确认后
由设计、开发、测试一起做WBS，将工作细化分解。根据分解后各部分工作量的详细估算，项目各方人员共同讨论，对计划进行细化调整。此时需进一步明确以下时间点：设计确认、功能完成、零缺陷（Zero Bug）、发布前代码冻结（Code Freeze），以及里程碑完结日期，如图1-9所示。 至此，一个里程碑的计划已经基本成型，在接下来的执行过程中，需要不断监控计划的执行情况，识别并应对风险及各种变更，适当调整计划中各时间节点，并确保相关人员及时获知计划变更情况。
别忘了完成标准
进度计划中的任何重要时间节点，都应该有一组完成标准。完成标准越早定义，计划按照期望完成的概率就越大。 以里程碑中最关键的几个时间节点为例，完成标准如下： • 需求／设计确认。执行所需的需求稿／设计稿已经完成（有时，并不一定需要全部完成，可以完成可接受的比例或核心部分完成，具体标准需要准确定义），团队已准备好要编写产品代码。 • 功能完成。所有定义的功能都已经完成（已通过冒烟测试，但允许有质量差距或Bug存在），团队已经准备好将焦点转移到质量保证上，所有剩余问题都将作为Bug来跟踪。 • 里程碑完成。质量已达到适当水平（如不存在高优先级的Bug等），可以上线发布，或可以开始下个里程碑。
克服估算焦虑
做计划就离不开估算，很多人有估算焦虑征，这很正常。我们承认估算是 困难的，所有估算都是一种概率事件。越早做估算，准确度越低。但只有进行粗略估算才能拥有一个起点，以做更好的估算。 大多数人利用直觉的本能反应来进行估算，通常是小团队短周期的项目，这种估算可以起到很好的效果。除直觉之外，有些方法可以帮助我们更好地估算，比如昨日天气法（Yesterday’s Weather），通过分析团队的历史数据，得出生产率的估计。如果是一个新的团队，没有历史数据积累下来，可参考类似条件下的其他团队。 以零缺陷时间点的估算为例，我们就可以参考这个团队在之前的工作中，开发每天平均修多少个Bug，测试每天平均新发现多少个Bug，使用公式“当前有效Bug数＋测试新报速率×X天＝开发修复速率×X天”，通过简单的计算就可得出天数X的值。去除节假日，并根据项目人员的投入情况留出一定的缓冲，零缺陷时间点就算出来了。 估算是一项能力，通过反复练习，估算的准确率能够得到有效提高
怎样做好计划
首先，好的计划一定是团队共同参与才能制订出来的。 在很多项目中，我们注意到计划往往是某个领导自己拍脑袋就确定了，其他人只有执行的份儿。这样的计划在执行过程中，会面临很大的风险与挑战。计划的本质是承诺，心理学告诉我们，要想让承诺更加有效，它必须得是当事人积极的、公开的、且经过一番努力后自由选择的。计划最终是要整个团队来共同执行的，那么制订计划就必须是项集体活动，参与所带来的责任感能带来持久有效的承诺。千万别低估这一点。虽然共同参与会带来一定的成本，但实践表明，让相关人员公开参与计划的制订过程，对于提高计划的接受度、保障计划的顺利实施有极大的促进作用。 其次，善于规划的人，会把里程碑分割成一个个小的阶段，分而治之。 例如，持续一两个月的功能开发期，一般会拆分成多次迭代来进行管理。那么计划要做到什么粒度呢？这里的原则是，方向越容易改变，变更越频繁，迭代的长度就要越短，反之亦然。每个迭代都需要制订单独的计划及完成标准。 优秀的项目管理，要把握项目的节奏，张弛有道。 最后，好的计划必须跟进。 最怕计划做了就不再看了，那不是计划，而是一张废纸。做了计划就必须跟进！
1.6 我们是如何开每日站会的
质疑的原因有很多，首当其冲的是抱怨没劲，这种情况下的站会被当作例行公事的汇报会，听不到什么实际内容的讨论，枯燥无味；在另一些团队中，站会又显得冗长而低效，讨论漫无边际，“有这个开会的时间，我活儿早干完了”
每日站会 != 汇报会
每日站会绝不是汇报会，而是团队沟通交流的平台，用以分享信息、做出承诺及提出路障（遇到什么困难，需要哪些帮助），解决的是团队协同的问题
Scrum推崇自组织的理念，提倡团队自我管理，而每日站会就是团队自主进行状态同步、风险管理及制定各项决策的非常重要的实践形式。团队通过站 会来了解整体状态，并对暴露出来的风险和问题做出集体决策。一个组织良好的站会，是出于团队的自组织需要，而不是领导者的监控需求。
为什么需要真实的白板
自从团队前面竖起了一面白板，你会发现很多事情自然而然地发生了。我们每天站在白板前，一边跟团队交流，一边在板上移动标记着自己颜色的便笺，碰到新问题，就立马重写一张，然后把自己的颜色标签贴上去。抛弃了冰冷的计算机，大家总算真正面对面了，互动和交流都变得生动和开放起来。
为什么要站着讨论
（无）
”三张牌“式站会法
伴随着白板的应用，每日站会上的沟通越来越活跃，大家的话题越来越发散，渐渐地我们的站会开始变得冗长而低效。我们渐渐意识到，把一个站会开好，需要一个主持人来把握会议的节奏。有人来控制节奏是不错，可在我们的团队里，为了强化大家的主人翁意识，每个人都是团队的主人，所以我们的主持人是大家轮换担任的。 那么如何让每个主持人都能把站会开好呢？我们需要一套有效的机制。经过长期的实践摸索，团队逐渐发展出来一套自创的“三张牌”式站会法。 站会开始时，主持人将红、黄、绿三张牌发放至所有与会人员。在整个站会的过程中，任何人都可随时举牌来行使自己的权力。 • 举“黄牌”，进行相关提问，向发言者了解协同及依赖的信息。 • 举“红牌”，用来打断谈话，避免过度的讨论和无结果的时间浪费，提高站会效率，如图1-11所示。 • “绿牌”则代表着每个人的发言权，将此牌归还给主持人表示陈述完毕。 当所有的“绿牌”都已归到主持人手中，且无更多疑问时，则宣告站会结束。 正是靠着这样简单的游戏规则，一方面帮助主持人找到感觉来把握节奏，另一方面又把会议控制的权力和责任交给了与会的每个人，任何人都可以对过度的讨论随时喊停，从而让站会在“有用”的同时又能保持“高效”。
确保持续改进
比如站会时间，很多敏捷书籍上都推荐把站会作为一天的开始。经过反复尝试和适应，团队决定把站会的时间放在午饭前的11:30开始，一方面大家可以有相对完整不被打扰的一整个上午的工作时间，另外，吃饭的动力会让大家加速起来，保障站会的高效，如果有某些争议性的话题还可以转到午饭时继续讨论。
1.7 我的站会感悟
站会起作用有其内在的原理，了解这些深层次的内容便于你更好地使用这个工具。
感悟1 一种仪式
我们的站会一般放在早上上班一到公司就举行，这个对团队来说有一种仪式感
同样，早上的项目组站会，通过固定的时间，项目组人员站在一起同步项目的情况，会像一种仪式一样，给大家一种心理的暗示，暗示自己要更加专注、认真地对待自己手头的工作。让团队快速地进入工作状态，帮助团队调节情绪，从放松的家庭环境过渡到专注的工作环境。
感悟2 核心习惯
习惯是行为的自动驾驶系统，如果能让团队耳濡目染，久而久之形成好的习惯，可以加速完成任务。那什么叫核心习惯？
那为什么说站会是团队的核心习惯呢？在站会进行的过程中，我们会固定地同步任务的状态是否按计划进行、当前有什么风险和问题、确认需求变更。久而久之，站会这个框架，帮助团队提升了时间管理的习惯，提高了风险管理的意识，加强了需求变更管理的习惯，驱动着团队逐步完善。
感悟3 高效的会议模式
这种会高效的原因，一个原因是，固定安排时间，减少召集会议所花费的时间，避免了和每个与会者确认时间并达成一致的时间花费，另外，早上是凑齐相应人员一起开会最容易的时段，特别是涉及并行任务比较多的关键角色，这些人在其他时段经常会有各种时间冲突。另一个原因是，由于是站着开会，一旦有人跑题或者长篇大论，与会上的其他人员就会出现明显的肢体动作，于是话题更容易重回重点。
1.8 白板的艺术
白板上除了任务状态、燃尽图，还可以添加项目目标、信心指数、上线倒计时等模块，帮助团队统一方向，聚焦核心工作，发现潜在问题，集中力量解决问题。 白板上的便笺纸也可以有不同的设计，通过颜色和形状变化来标识不同的任务类型，以获得更好的互动效果。
说到白板，大家可能都有所耳闻，很多时候白板是用来配合站会的。其实白板也可以有两种选择：电子白板和物理白板。我们当时对比了JIRA中的电子白板和普通的物理白板的效果，最终选择了物理白板。原因有以下几点： （1）物理白板可任意定制。可以添加／删除栏，添加各种新的标识，写下迭代目标、发布标准，贴上燃尽图（后面将做具体介绍）、贴上进度计划等。这种改变在白板上实施，所有人都能在一分钟内迅速学会，这一点应该是其他电子广告牌所无法做到的。 （2）物理白板需要团队的协作。由于我们没有可触摸的电子屏，所以电子广告牌大家只是用投影仪投在墙上，往往由主持人在上面做一些操作，这样缺少互动。而物理白板允许每个人从墙上拿下便笺，挪动位置，甚至在上面写下一些文字。它使会议形式更加有趣生动，团队的互动也会更好。
白板概览
我们将白板分为5行4列，5行代表5种任务：运维上线相关任务（日常 更新、线上缺陷）、开发（普通开发任务，含前端、测试等）、测试（独立的测试任务，如测试用例完善、测试代码完善等）、前端（独立的前端任务，如页面优化）、分享（内部技术分享等）。4列分别为：还未开始的任务（Open），进行中的任务（In progress），开发完成待验证的任务（Resolved），验证完毕的任务（Closed），如图1-12所示。
纸条颜色的讲究
图1-12白板中的纸条花花绿绿，你可能会疑惑为什么用不同颜色的纸条呢？下面我就来解释一下。 上面提到的5种任务中： （1）运维上线相关的任务会用红色方形纸条，尤其是线上Bug。因为线上相关的问题都是优先级最高、大家最关注的事情，所以用红色醒目地标识出来。图1-13就是一个线上Bug。 （2）一般的开发任务、独立的测试和前端任务、分享都以淡黄色方形纸条标记。其中开发任务如果需要相应的前端任务配合，则在该纸条上方贴上一长 方形蓝色纸条标记；如果有对应的测试任务，则在纸条下方贴上红色的长方形纸条。图1-14所示是一个既有前端又有测试工作的任务。 （3）有设计文档、API文档测试用例的任务，会分别用绿色笑脸、黄色笑脸、红色笑脸来标识。原因是团队正在做这方面的改进。设计文档和测试用例强调回顾（review），曾经因为这方面做得不到位，出现过一些线上问题。而API文档是开发提供给测试人员用于设计的用例，这个涉及成员间的沟通和互助，所以也重点标识。此处大家也不难发现白板的便捷之处，就如本文开头所讲的，在应对一些非常规的规则时它非常灵活方便。当大家对设计文档、API文档、测试用例的规则牢记于心的时候，我们就会去掉这些笑脸用于其他的跟进。图1-15是我们在白板上对笑脸的说明，图1-14是一个既有API文档更新又有方案设计工作的任务。 （4）新增任务、迭代计划外加入的任务会用蓝色纸条跟进。迭代总结时会对新增任务的工作量进行统计，用以指导后续的计划。图1-16就是一个新增任务。
纸条内容的组成
纸条内容由以下几部分组成： （1）任务概要：简要描述任务内容。 （2）估算工作量：以人天为单位。 （3）负责人：姓名拼音首字母。 （4）实际工作量：当任务完成后由相应开发人员回忆实际的工作量，数字外围画个圈，以区别于估算工作量。在做迭代总结的时候，实际工作量和估算工作量的偏差，可以说明我们的计划是否做得合理。 白板上就只放这些小纸条吗？只是用来跟进各任务的进度吗？在我们的实践中，根据项目所处的阶段，我们会有选择地增加一些内容，如燃尽图、倒计时和目标、信心指数、计划等。
燃尽图
燃尽图可以帮助我们直观地了解项目进度的风险。 燃尽图往往用来呈现实际情况与理想情况的偏差，可以提示我们风险的存在。比如燃尽图一直很平坦，下降的趋势不明显，这样团队就需要回过头看一下哪里出现了问题。是测试吗？如果是，开发能不能帮忙协助一下。是外部依赖吗？如果是，项目经理能不能出面协调。是技术难点吗？如果是，技术领导能不能出面寻求技术专家指导等。燃尽图就是以这种方式帮助团队发现问题的。不过从我们的实践来看，这里有一个陷阱，那就是，在迭代初期（前1/3，甚至前1/2），燃尽图会处于比较平坦的状态，但是不一定真的是风险很大，因为前期，团队正在做着一些准备工作，很少去关掉任务，等到这些工作全部到位后，后面关闭任务的速度会大大加快。针对这个问题，我们团队也正在探索更合适的方式来展现。图1-17是我们上个迭代的燃尽图。
目标
在白板上放置目标能帮助团队往同一个方向努力。 在很多组织中，管理人员都以为项目成员清楚他们的目标。可事实却表明，在被问到目标是什么时，每个人都会有自己不同的答案。在过去很长一段时间里，我们的团队成员只是被分配到一个个任务，每个人只负责完成这些任务，却不知道这些任务孰轻孰重以及它们的来龙去脉。有的时候自己在完成某个任务时遇到困难，会花大把的时间去解决，而不是先看看这个任务是不是影响我们的目标达成，或者等负责人来拍板是不是要继续这个任务。团队更多的只是在完成任务，对产品的全局没有清晰的认识。现在我们会有一个中长期的目标计划和每个迭代的目标，让大家看到自己所做事情在全局中处于什么样的位置，看到团队未来的方向在哪里。当被某个任务阻塞的时候，大家可以根据目标来自己判断是不是影响该目标的达成，如果不，那么这个任务可以稍缓；如果是，那么就要赶紧提出风险，大家一起来想办法解决。而这样的目标，我们通常会放在白板上，让大家看得见摸得着，并且在迭代总结会的时候来回顾是 否完成了这个目标。例如上一个迭代的目标为：发布至联调环境。那么开发人员自己也会判断，我自己的几个任务哪个比较重要，即那些阻碍发布至联调环境的任务。虽然定目标的时候有时候会比较困难，但明确的目标有助于项目所有人员保持同步，明白对于下一个迭代而言什么最重要。
信心指数
白板上的信心指数显示了目前团队对于成功的交付所持有的信心，这一指数往往能帮助团队发现一些潜在的问题，及时地进行调整。 在确保了大家对目标的认知是一致的之后，就可以做一些检查。比如在站会的时候，每个人对完成目标的可能性来投票。每个人写下一个数字：5=绝对能，4=有可能，3=有点悬，2=不太可能，1=拉倒吧。只要投票结果中有2和1的话，可能就提示我们需要重新评估目标，并讨论需要做什么改变来提升信心。常用的方法有：消除障碍，帮助解决瓶颈问题，缩小范围，调整目标，更加努力地工作。信心值低的同志会得到来自项目团队其他同志的协助。团队中曾有这样的情况，其他成员给的是4，而有一位成员给的是2。我们会问这位成员是什么原因导致他信心值不够，他告诉我们，接下来他要做的工作不是他擅长的，现在还不知道怎么开展。于是技术领导就指派了另一位比较资深的成员来协助他完成这部分工作。试想，如果没有这个过程，有可能到最后这位成员才会说完不成这部分工作。
倒计时
在白板醒目的位置，以红色字体标识出来，是为了提醒我们离终点还有多少时间，必要的时候通过时间和剩余工作量的对比来发现问题。例如倒计时已经是10天了，而某个开发的剩余工作量是11人天，很明显这里应该是有一些问题了。这就使大家的视线聚焦于这一点，集中力量来解决这里的问题
对于白板上放什么内容，团队可以根据自身的条件和项目所处的环境进行选择。我上面提到的这些点也不必全部放上去。例如，信心指数，我们往往会在项目临近发布时用来提示有可能存在的问题。如果项目中不存在文档回顾的 问题就不需要有用于标记设计文档，测试用例和API文档的笑脸。当然除了我说的这些，还可以加入更多的内容，如日历、每个人的剩余工作量、阻碍我们的问题列表，这些都是要根据团队和项目的需要进行调整的，我们团队正在考虑用一种标记来标识需要上线的任务。
关于白板我们必须明白
（1）对于物理白板，在迭代结束后，纸条就会都被揭下来，贴上新的纸条，这样就没有历史记录了。对于一些长期的项目，也许还需要回去查历史数据，就可能还需要在电子白板上留一份数据。我们团队当前的情况就是这样，物理白板用来沟通问题、同步进度，而电子白板用来留档。团队可以根据自己的情况来决定如何使用物理白板和电子白板。 （2）对于办公区域不在一个楼层甚至不在同一个地区的团队，物理白板可能就不合适了。 （3）白板虽然可以定制各种内容，但是建议不要一次增加太多规则，最好一次增加一种规则，等到这种规则成为大家的工作习惯后，再退出，让位给新的规则。 （4）不要增加太复杂的规则。太复杂的规则需要一些学习成本，而且实践也证明，太复杂的规则往往不容易被遵循。 （5）项目类型的不同也会影响对白板的设计，如本文没有提到策划、交互、视觉等角色的工作在白板上的体现，是因为本文描述的项目中这些角色都是与其他项目组共用的，我们会直接把他们当作项目的输入，没有监控前期的状态。当然如果你们的项目中这些角色参与度较高，也可以将他们的工作纳入白板中。 白板是一种强大的工具，如何使用白板不是一篇文章能够说清道明的，本文提到的只是它在笔者所在团队的应用，希望能给大家一些借鉴。所有团队都可以根据情况定制属于自己的白板。
1.9 不简单的周会周报
周会周报是我们项目管理沟通中非常重要的两个环节。本文从周会的分类、开好周会的要点以及做好周报的细节点等方面进行剖析，给大家提供一些思路，希望读者通过做好这两个环节来一窥项目全貌
周会
目前项目经理们所处的项目中，毫无例外地拥有各自的周会，但开法略有不同，主要分为三类： （1）全体类：项目全体人员共同参与，这根据项目大小的不同又有差异。技术研发类项目，本身以研发人员为主体，周会以所有人员的状态和项目信息同步为主；也会有部分产品类项目，虽然角色和人数众多，但依然会有全体参与的周会。时间控制在半小时内，以产品和团队的动向同步为主。 （2）组长类：这也是目前占比最高的周会形式，更多地存在于产品类项目中。各组同步状态，同时了解产品最新情况以及讨论重要的产品事宜。 （3）三方类：主要是产品、运营、市场三方周会，也存在于产品类项目中。因为这三方是产品动向的主要来源，且日常沟通合作中需要协调配合的事项很多，所以也需要定期讨论决策。
首先，要想清楚为什么开周会。要同步状态、汇总各团队信息吗？如果仅仅如此，每个团队罗列自己的事项，互发邮件是不是就行了？显然不够。我们需要通过周会来： （1）面对面地感受项目当前的整体状态、重要问题、接下去的目标以及所需的调整。 （2）借此来对项目当前重要问题有一致的认识，进行小幅度的讨论，并形成下一步工作事项。
这里有一些开好周会的要点：
（1）控制规模和时间。人数为10～15人，时长不超过1.5小时。
（2）要不要轮流汇报？事无巨细的罗列，既乏味又无效。大部分项目整体情况可以通过项目经理事先的收集来直接做整体概述，对于部分方向性或者商务性小组，可以简单汇报主要工作和主要问题。
（3）如何识别周会该讨论什么？先说哪些不该在周会讨论：急事不适合周会讨论，要第一时间当下拍板！非跨团队的问题不适合周会讨论！纯执行细节问题不适合周会讨论！大方向决策问题不适合周会讨论！……这样我们就更容易得出哪些适合周会讨论了。那些跨团队的、涉及整体计划性或者协同配合型的问题、或者中期改进型问题，适合放在周会上。项目经理一方面可以在收集整体状态的过程中识别此类问题，另一方面也需在周会过程中随机应变发起对“火花”型问题点的快速讨论。这样的讨论，不需要在周会时明确所有的细节，但大家要有共识，并有行动方向、落实人员。
（4）确定状态同步的维度。大部分情况下，不需要完全按照职能团队来同步，目的不是汇报贡献，而应该按照产品内子项目线的维度来跟进进展，挖掘问题。当然，整体研发情况是一个必有的维度。
（5）控制说话比例。如果一个周会从头到尾是项目经理或者主管在唱独角戏，那就应该反省一下周会的形式和内容了。合适的比例是1:1:1。第一个1指的是会议主持人，往往是项目经理或主管，向大家更新整体状态，并且主 持整个讨论；第二个1指的是部分需要汇报的与会者发言；第三个1更为重要，是所有与会者参与讨论发言。达到了这样的比例，容易让参会者从信息获取度、决策参与度和专注度上都保持较高的水平。
（6）固定时间地点。周会的时间地点需要尽可能固定，这样会让大家有预期性和节奏感，也能够提高到会率和准时率。
（7）如果我们已经有每日站会了呢？这个问题更多地来自技术研发型项目（产品类项目通常有必须高频率同步的业务需求），研发日常已经每日同步了，那自然不需要再依靠周会来同步状态。这种情况下，视项目变动情况、团队管理的需求，变周会为主要针对项目概况和团队管理的会议，开会频率降低，时间上也可以作进一步压缩。如无此需求，也可以省略周会。
周报
那么写好周报又有些什么细节呢？总结起来是“三要，三不要”
1. 三要
（1）周报要包括什么？要包括整体进展、整体风险、各子线状态、各子线风险。周报应该让大家清楚重要的进展、目标达成情况、风险状态以及应对措施。总之，看完周报，大家应该对项目现状有清晰的整体认知。
（2）要进行换位思考。要多从报告接收者的角度进行思考和准备相关材料，有条件的话提前沟通确认内容和形式。别假设看报告的人跟你有一样的理解背景和上下文在心中，要给出连贯的表达说明。
（3）要有提炼自数据的关键信息。需要提供相应的信息而不仅仅是数据，信息和结论来源于数据分析，通过数据分析出相应的有价值的信息是每位项目经理、其他管理人员的核心竞争力之一，数据可能是客观存在、无序而杂乱的，而信息是用来衡量现状和指引我们下一步行动的基础。产品数据一定是敏感数据，并不适合实时向所有人公开，因此，并不需要在周报里列清所有数据，要把控好周报的分发范围。
2. 三不要
（1）篇幅不要过长，控制写周报的时间和复杂度，适当图形化。对于进展和问题，都只写要点，不要事无巨细都写。
（2）不要有令人惊讶的内容。状态报告仅仅是工作的状态总结呈现，更多的沟通工作和问题处理应该在汇报之外处理。发现问题，要及时分析和解决，而不是等待报告项目状态的时间来临再寻求帮助。
（3）不要直接拷贝粘贴你下属的报告。想想我们存在的价值就知道这其中的含义了。
1.10 让你的报告会说话——如何有效、有料地进行工作汇报
掌握良好的汇报工具和方法能够让你在职场中更胜一筹。好的报告不仅是好的色彩搭配和炫酷的字体组合，而是针对不同受众整理出恰当内容并运用适当的图表以简洁的方式传递信息。本文对不同报告（日报、周报、月报）的内容格式进行详细说明和举例，希望你不再把写报告当作工作中的累赘。
写报告经常遇到一些问题
这些问题是： （1）这一周（或者这一段时间）做了什么呢？好像这周／这段时间没什么可写的？ （2）啊，就这点干巴巴的内容？ （3）项目状态到底该如何评价？风险可控吗？
工作汇报的目的
笔者认为一份好的状态汇报至少可以达到以下三个目的：
（1）将状态、问题、风险知会相关干系人，这是任何状态汇报都需要满足的最起码要求。至于什么样的信息需要让谁知道，需要大家在做状态汇报前与各相关人员达成一致，以避免辛辛苦苦写出来的东西不是其他人所需要的。建议可以通过类似小迭代、不断改进的过程来探知和摸索出适合相关人员的状态汇报，例如可以先按照自己的理解书写第一版状态汇报，然后在会议上或者邮件中询问大家是否还需要补充或调整相关内容，如果有的话就在下次的汇报中进行调整。 这其中也需要考虑以何种方式、频率发送状态汇报。一般来讲，一周一次的状态汇报就够了，但是对于处于紧急状况下的项目或者公司领导重点关注的项目就需要区别对待了。
（2）寻求帮助。工作中遇到问题并不可怕，最可怕的是在问题初期不去积极主动地寻求帮助，而到了“火烧眉毛”时，即使有上级领导介入也需要花费数倍的成本来解决，有时甚至一不小心把自己的职业前程给搭进去了。 这里只是说状态汇报是一个非常好的寻求大家帮助的机会，而并不是说所有的问题需要积聚到进行状态汇报时才披露出来进行处理。在工作中平时可以及时地就遇到的问题进行沟通，同时在状态汇报时再次正式提出来，也许这样会得到相关人员的更加关注和重视。
（3）自我审视。古人云：“吾日三省吾身。”作为现代人的我们平时大家都忙于推进各项工作或被各项工作任务推着前进，是否有时间停下来审视一下自己？状态汇报的书写过程就是我们的自我审视过程，也许无法做到“吾日三省”，那么也至少需要“一周一省”吧。
个人工作周报
仔细看看这样的周报我们就可以发现，它们的共同点就是仅仅记录了过去做过什么。
如果能借助一些简单的任务管理工具的话，这样的流水账很容易得到，这样的个人周报是没有什么附加值的。
表1-2是笔者推荐的一种个人工作周报内容与格式。
• 本周工作完成程度。 不仅需要描述做了什么，还要知道它的结果如何，例如是否已经上线、客户的投诉率是否已经下降等。
• 下周工作计划。 除了描述要做的事项外，还需要对主要的任务的预期结果进行说明，也就是我们在敏捷领域经常听到的Definition of Done，即 需要对“完成”有一致的理解。
• 工作中遇到的问题及建议。 发现部门、团队、项目中的一些问题及其对应的相关建议，例如持续集成的使用、代码评审的更好实践等。
• 个人感言。 团队管理、合作，个人发展等方面的感想可以写出来与上司、同事进行分享，不要把与上司的沟通仅局限于每个季度一次的考评沟通会议。
团队工作周报
身为团队领导，需要发出本工作团队的周报给上级领导、相关部门，与前述个人工作周报不同的是团队周报更应该聚焦在结果和计划上，而非个人微观层面的事件总结。计划的时间跨度根据团队规模大小不同可以从1个月到3个月不等，如表1-3所示。
项目状态报告
在日常项目或者执行中经常需要这样三类汇报：项目日报、项目周报和项目月报，一般周报是最常用的一种项目状态汇报形式。
1．项目日报
项目日报适用于项目中紧急情况下的某个问题／项目报告，如重点项目、线上问题、重大客户投诉问题等。在处理问题的过程中发日报是为了让更多项目干系人了解情况，寻求他们的帮助。 一个典型的项目日报格式如表1-4所示。
2．项目周报
适用于常规项目状态报告，默认情况下选择周报的形式和频率，一般需要包含项目的主要度量指标等信息（进度状态、问题、风险、质量指标等）。 一个典型的项目周报如图1-18所示。 对于繁忙的领导们而言，看到项目天气就可以基本了解项目目前的总体状态，其中项目天气的各种天气情况定义如图1-19所示。
3．项目集周报
单个项目周报的格式和内容主要运用于对单个项目的汇报和沟通，如果是同一项目经理负责范围内的多个项目，为了方便报告接收者阅读和对比所有相关项目信息，建议以一个总体表格的形式进行汇报。表1-5是一个项目集周报的内容和形式的例子。
4．项目月报
适用于向高层领导、客户报告项目状态，高层次、概括性地介绍项目相关信息。一般而言，参与月度汇报、阅读月报的受众为公司、部门的领导，他们平时都非常忙碌，因此报告需要覆盖他们感兴趣的领域，重要的是会议前需要与相关的会议参与者对会议内容达成一致性
项目状况：
•总体进度
°目前P0级别bug都已经修改并在测试服务器上回归通过，12/15进行上线评估；
°……
项目细节
• 开发测试
°Done °Ongoing，部署所有bug-fix到测试环境。
°Coming，12/6进行代码merge到主线版本，12/7—12/10进行回归测试。
•交互设计 目前开发进度安排如下：
图1-20是一个典型的月度项目汇报包含的内容，其中左边的总体状态中包含费用预算消耗情况、项目质量、产品发布截止时间、项目移交进展情况、需求变更情况、风险状态、IT设备等主要内容。用绿色表示该项的目前状态正 常，黄色表示有些风险需要关注，红色表示需要重点关注和决定的事项。每一栏状态右边的感叹号图标是一个超链接，可链接到更详细的具体页面中。
1.11 项目管理≠烦琐的会议
项目管理的流程会给团队带来一些会议，这些会议的目的是解决问题、做出决策、建立起彼此之间的信任。把握好会议管理的技巧，会让整个团队更加高效。
会议导致团队效率低下
一个负责人发现自从旁边一个项目组引入项目管理后，同一层的会议室预订变得多了起来。他的疑问是一旦引入了项目管理之后，是不是会导致会议繁多，效率低下？
即使再加上会议前后的准备时间，基本上会议负荷度不会超过5%（会议负荷度＝所有会议时间÷理论工作时间，即8.5小时/（40工作日×8小时）=2.65%）。
试想一下，如果在某个项目中没有任何这些会议，那么我们项目的效率将会提升5%吗？答案应该是“不一定”，因为没有这些面对面的沟通会议，项目团队可能会是另一场景：项目POPO群会不断弹出消息，策划需求同事疲于回答各种问题，进度沟通均是简单的“OK”回复，如果同时有3个人在POPO中同时输入，则上下文理解就变得愈加困难了……POPO新消息的闪动也会打断大家的工作思路。相信大家都有过类似这样的经历：看到POPO的新消息提示后好奇地点开查看，发现和自己没有什么关系。笔者统计了一个20人规模的项目POPO群记录（这个项目每日站会同步项目状态），发现基本上每天的聊天记录在30条左右，大多为站会上的跟踪事项的结果通知。
在会议室里召开面对面会议的另一个显著的好处就是可以通过在白板上写和画，来表达清楚大家的想法和意见。
那既然这些会议的时间成本不高（<5%），也有这么多显而易见的好处，为何还是有很多同事一提起开会就唯恐躲闪不及呢？
为什么要开会
在开会之前，首先你要想清楚你想在会上达到什么目标、解决什么问题。 然后，你要弄清楚需要得到哪些人的帮助。一旦你确定了“达到什么目标”、“解决什么问题”和“需要得到哪些人的帮助”之后，其余问题（什么时间、在哪里开会）就显得相对容易多了。
一般情况下，开会需要有充分的理由，比如当你： （1）需要团队就某一个问题提出他们的想法和建议时。 （2）需要团队参与决策或解决问题时。 （3）需要团队来解决一个仅通过一对一的交流方式无法解决的问题时。 （4）需要和整个团队一起共享信息、分享成功或排忧解难时，或是想要每个团队成员都意识到这是一个特殊时刻时。 （5）需要来自不同团队的那些有着各不相同的观点的团队成员集思广益来解决一个问题时。 （6）需要明确由谁来对所出现的问题、所造成的麻烦或者所涉及的领域负责时。 （7）发现团队成员觉得非常有必要开会时。
但当下列情况出现时，就没有必要开会： （1）要讨论的是私人问题，比较适合采用一对一的方式解决。 （2）你没有足够的时间去准备会议。 （3）其他的沟通方式能收到与会议相同的效果，或者比会议更好的效果，如通过E-mail、POPO群讨论，或者打电话的方式等。 （4）会议的议题不值得浪费所有与会者的时间。 （5）团队之间的关系一团糟，还不能通过会议达成一致、做出决策时。
应该邀请谁
那些能够帮助你实现会议目标并能为会议的议题提供各种观点的人，他们是： （1）对于所要讨论的问题有关键决策权的人。 （2）对于所要讨论的问题有相关知识和信息的人。 （3）一心一意要解决问题的人和与所要解决的问题休戚相关并有重要作用的人。 （4）有必要知道你所要传达的信息并有利于他们进一步开展工作的人。 （5）需要执行决策的人。
如何制定会议议程表
议程表一般应该包含以下几个方面的内容： （1）明确的会议目的。 （2）会议欲实现的目标或产生的结果。 （3）给哪个小组开会或者与会者都有谁。 （4）开会的日期、时间和地点。 （5）会议将持续多长时间。 （6）会议是由谁组织召开的。 （7）每个与会者在这个会议中分别承担什么任务。 （8）会议所要讨论的每个议题（每个议题都要具体制定负责人，而且要规定讨论的时间）。 （9）筹备阶段所需的背景资料。
如何主持会议
在会议一开始就要进入主持状态，清晰地陈述会议的目的、会议所有讨论的问题，以及会议的步骤。
严格按照议程表主持会议。一旦会议开始，就不要谈论与会议议程无关的话题了，尽量按照会议的议程表来主持会议。在讨论议程中，你要密切注意所讨论的议题和所用的时间，或者专门指定一个人负责把握时间。
如何按时结束会议
你可以使用以下技巧来保证会议按时完成： （1）让一个团队成员来做计时员。 （2）每隔一段时间提醒大家一下还剩下多少时间，还有几个议题没有讨论。 （3）如果时间不够了，就优先或者推迟讨论某些议题。 （4）如果需要延长会议时间，应先征得大家的同意，或者也可以另行安排一次会议来处理剩下那些没有解决的问题。
如何对会议收尾
对会议进行总结。对会议总结时就意味着会议要结束了，总结的人可以是领导，也可以是与会者。无论是谁总结，都要重申： （1）所讨论的关键问题。 （2）所做出的决策。 （3）下一步计划如何实施。 （4）每个任务分别由谁来负责执行。 这一环节可以帮助大家理清他们不太明白的地方，同时也是和大家就会议达成的结果再次进行确认。 把会议上涉及的重点内容记录下来。一定要让会议的记录员把所有重要的内容都记录下来，如关键的议题、所讨论的主要观点、所做出的决策、会后大家各自应该承担的责任，包括由谁来承担这些责任，他们需要用多长时间来完成他们各自的任务。
如何做好会后的跟进工作
若要会议取得真正意义上的成功，最重要的一件事就是积极做好会后跟进工作。因为毕竟问题的关键并不在于会议本身，而是经过会上讨论所要进一步采取的行动。
如何能够保证会后的跟进工作成功呢？关键是会议上形成的沟通和行动计划，应该包括三方面的因素，即什么事、谁、什么时候完成。 （1）会上做出了哪些具体决策，产生了什么结果，以及会后应该完成什么样的任务？ （2）由谁来负责执行这些任务？ （3）什么时候完成这些任务？让与会者对于承担的任务制订一个较为合理的工作计划。 最后将沟通和行动计划以会议纪要形式发给所有与会者和相关人员，让没有出席会议的人看了这份材料之后知道会上都发生了什么。
1.12 高效回顾，引导团队从优秀到卓越
定期回顾，对个人而言，非常重要；对团队而言，亦是如此。例如，戴明环PDCA里，每次行动后的“检查”环节；Scrum敏捷模式中，每个迭代末尾的回顾会，均是让团队及时回顾，发现过程中的浪费（特别是协作中的障碍），分析根源，落地实施，引导团队持续改进。
常见的回顾会形式
定期反思和调整。 常见回顾会的组织形式有： （1）与会人员用便笺纸（见图1-23）写下项目过程中做得好／不好的5个点，按照分类贴在白板上，确保大家的意见能够充分自由表达。 （2）在白板前逐条看大家的意见，共同发现问题，并有针对性地展开讨论。 （3）对大家总结出的好／不好的点，进行集体投票。 （4）由项目经理整理投票结果，好的方面总结成最佳实践予以推广，不好的方面加以讨论。 （5）得出流程改进方案。
回顾会的典型过程是发现问题—分析问题—解决问题，核心在于根源分析以及决定改进措施。根源分析可以采用多问几个“为什么”的方式，而改进措施必须由团队自己给出，可能讨论过程中有冲突争执，但必须在会议上得出达成共识的团队决策以及具体措施。 一个版本开发结束了，回头看看来时路，总结一下优缺点，回顾会就是个很好的方式。但几个版本的回顾会下来，是不是发现，问题还是那些问题？项目的关键问题似乎一直没有被有效地改进。
回顾会，如何高效聚焦、形成结论
1．如何选择合适的主题
回顾会的主题一般针对完成的迭代过程，但有时我们也可以穿插主题性的回顾会，比如，我们一直在做团队持续集成和自动化测试方面的改进，那么可以选取这个主题做回顾。建议在各个迭代中，主题性回顾可以和“正常”回顾 会穿插进行。这样，既有主题性的回顾会，引导团队实施长期主线改进；也有“正常”回顾会，定期检查团队状态，及时发现潜伏的问题或风险。
2．回顾会该有多长
当回顾会超过2小时，人们就会变得很疲惫和缺乏耐心了。对于固定节奏为两周的迭代来说，我们推荐会议时间为1.5小时以内；对于更长周期的迭代，建议会议时间不超过2小时。另外，如果能买些水果零食，那么回顾会的气氛就会更活泼，不让人觉得那么冗长了。
3．怎样发现问题
需要限制发现问题的时间，不超过会议时间的1/3是合适的。
可以提前做团队意见收集的工作，也可以通过画项目时间线的方式一起回顾项目历程，从而列出问题列表。我们不可能三头六臂同时改进多个问题，那么就从列表中选取1～2个重要问题，作为下一步分析和改进的目标。有时，某个迭代的问题暴露非常明显，比如迭代交付失败或者严重延期，那么不需要收集信息，直接展开分析就可以了。
4．如何调节会议的基调
因此，回顾会开始前，建议先私下里了解每位成员即将与会的感受，这些信息非常重要。当你将与会者的感受映射到“问题解决者”、“学习者”、“游客”、“囚徒”等不同角色上时
另一方面，会议基调也是每位与会者会议理念的叠加。在初期的回顾会上， 大家常常认为，解决的问题越多越好，然而很多时候却只是“补丁式”地缓解了一下问题，并未去根治。如果要让团队真正碰触到问题的根源，深入细致地探讨出解决方案，则需要有充足的“时间”和“耐性”。这时候，需要会议的主持人向大家灌输正确的理念——“复杂的世界里，一个就够了”。面对众多问题，能够完美地解决一个，也就够了。要帮助大家聚焦。聚焦之后，团队讨论过程中更容易有实际的、正向的进展，这是对团队最好的激励。
回顾会的结果如何有效落地
（1）团队长期共享一份持续改善的检查表。表中包含正在改进中的问题和事项，也包含后续待改善的问题。
（2）回顾会开始时，检查进展。在回顾会开始时用几分钟时间检验一下上个回顾会改进的效果。时间控制严格、改进措施明确的回顾会，是团队持续改进的加油站，它既是上一迭代的完满句号，又是新迭代希望的开始。
（3）回顾会结束时，为每个行动事项指定一位负责人，更新检查表。重要的行动事项，甚至可以直接当作一个项目来推进。某些行动计划，可能需要学习新的技能，此时，可以与技术经理一起，为成员提供相互学习的氛围和机会。
1.13 项目管理从零开始
互联网公司中很少有公司级别的强流程，几乎没有需要统一遵守的检查点和文档规范，“百花齐放、争奇斗艳”，一派繁荣，每个部门、每个产品都是一个小自由王国。在此基础上项目经理如何开展工作？如何引入恰当的、不被人反感的相关流程来做到从混沌到适度有序？从访谈了解问题入手、确定试点项目、评估产品部门的痛点是否被解决，再到定期的规划图制定、项目落地的保障——“三步评审法”等一系列方法手段的应用，将网易四个不同部门的项目管理水平提升到一个新的台阶。
项目管理简单吗？非常简单！因为只要你掌握了基本的思路和方法，就能一通百通，达到“一切皆项目”的境界。那么项目管理复杂吗？当然复杂！因为项目管理不仅要根据相应的方法论依葫芦画瓢，更重要和更具有挑战性的工作是在项目执行过程中人员间的协调、沟通、冲突处理、加强团队凝聚力等与人密切相关的部分，只有相互信任的团队才能到达项目顺利交付的彼岸。
通过访谈了解问题
项目经理要做好随时被空降到不同部门、不同项目的准备，项目经理往往是业务部门领导心目中的那个可以信赖的人：组织者、协调者、促进者。
项目经理被寄予厚望，信心满满地走马上任了。那么如何开始呢？
不论一个项目经理拥有多么丰富的理论知识、多么牛的实战经验，如果对项目背景、团队成员不了解的话，也是举步维艰的，更别说按时交付项目了。所以不论你接手的项目多么紧急、多么重要，作为项目经理的你需要开展一些一对一的或者一对多的访谈，带着同理心去聆听大家的反馈，并适时地引导大家朝正确的方向前进。
面谈的问题列表主要包含以下内容： （1）部门的愿景是什么（或者项目的目标是是什么）？ （2）目前项目或部门中的主要风险／问题有哪些？ （3）目前的工作方式／流程是怎么样的？团队成员的分工是怎么样的？ （4）目前质量衡量指标有哪些？ （5）影响项目成功的关键因素是什么？如何界定项目的成功？ （6）对项目管理的期望是什么？
笔者在初入一个业务部门时通过与所有团队主管（8名）和部分同事（6名）进行一对一访谈后，得到的主要反馈有：
（1）项目立项较随意。 • 缺少市场调研分析，对该项目／功能所带来的改变／收益没有详细地研究。 • 无法说服相关参与者真正参与到项目中，下游开发测试团队感觉都是为上游的网站策划团队打工。
（2）需求变更频繁、更无流程，变更原因不清，变更后通知不及时。 • 需求讨论和分解不充分。 • 没有召集所有可能受影响的团队成员参与讨论（如经常忘记让测试、客服人员参加），或者需求讨论只在会议上进行，没有预留时间让大家提前了解需求。 • 需求文档和相关的交互、视觉文档没有基线化，大部分需求变更都是通过在文档系统上追加备注进行更新的，而下载的文档内容并不是最新的内容。 • 需求变更经常在IM通信群里进行讨论，需求文档却没有及时同步更新，并且有些相关人员没有及时通知到（如测试人员）。 • 无变更管理流程（什么样的需求变更需要谁在什么时候做决定）。
（3）各项目的计划不清楚，项目状态不透明。 • 无项目交付节点或者对里程碑的交付物定义不清楚。 • 相关项目参与人员很少有定期的面对面会议进行状态同步，大多数沟通是通过IM工具来完成的。
（4）产品策划人员没有得到充分授权进行项目的执行，或不知道如何进行进度监控和风险规避，部分策划人员没有动力去进行项目的计划、跟踪和了解交付过程，认为策划出的功能后续团队就能自动交付。
（5）相互推诿，对于延迟的项目／任务，基本上都认为问题出在其他团队身上［如技术人员认为UED（User Experience Design，用户体验设计）是瓶颈，UED认为策划是瓶颈等］。
（6）会议效率较低。 • 没有留出时间让会议参与人员进行准备。 • 很少有会后跟踪措施，没有做到问题的闭环跟踪。
（7）很少有人在乎计划的交付日期。 • 产品部门无中、长期的计划，以及如何达成这些目标计划不可视，建议通过季度部门会议从业务优先级上使大家达成一致。 • 无部门管理团队定期的面对面周会，周报大多流于形式，各组间的依赖、风险、问题没有进一步的跟踪和解决措施。
（8）临时性任务多，经常打断正在做的项目／任务。每个小组都认为问题出在其他相关小组上，不认为是由于本小组导致项目／任务延迟的，无相关历史数据供参考。
总体来说，大家对项目管理的期望是： （1）项目计划清楚、可视、可控。 （2）给出一个项目启动评审的决策流程，能够帮助大家识别项目的价值和优先级。 （3）加强各部门在项目中的合作，使相互的协作更加流畅。 （4）项目需求更加清楚合理，考虑更全面。 （5）需求变更有据可依，有据可查。 （6）提高项目参与人员的主人翁意识和责任感。 （7）尽快做1～2个标杆性的项目，通过此项目向大家传播专业的项目管理方法。
改变从试点项目开始
1. 试点项目的选取
（无）
2．试点项目的执行、数据收集与分析
试点项目的目的要明确，需要针对性地收集数据。数据为下一步改进提高提供决策的基础，没有数据支持的决策基本上都是凭感觉和拍脑袋的，正所谓“无量化，不管理”。针对前面访谈所暴露出的主要问题，在试点项目中重点收集的数据有项目人力支出、项目规模变化、线上缺陷数量、及时交付率。
3．项目人力支出
怀疑其产品定位和质疑我们的价值、我们的ROI在哪儿。统计项目人力支出并不是想通过投入的人力来判断一个产品／项目的好坏，而是希望让部门总监知道不同项目的人力投入，以及项目所带来的收益是否值得，后续如果有类似的项目是否还会投入这些人力，抑或减少／加大人力投入，甚至需要考虑类似的项目是否可以直接从市场采购。
4．项目规模变化
在不同部门的初期访谈过程中，研发团队反复提到的一个希望是能够控制需求变更，减少变更。为了能够衡量项目开发过程中的需求变化情况，在试点项目中从项目规模维度进行了量化和记录。
这里使用大家最容易理解的人天来进行估算，图1-25所示的项目在初始阶段时规模是112.5人天，中途增加了需求导致规模上升到145.5人天，同时 实际花费的人力也是145.5人天，最后得出规模变化率为29%，其计算公式是：（实际花费人天－项目初始估算人天）／项目初始估算人天。
得出项目规模变化率的目的并不是想控制需求变化、减少需求变化，而是通过3个试点项目的统计数据发现，在A部门中的项目规模变化率中位值是25%，通过回顾分析发现，这些变化的需求大部分来源于两个方面：一是由于产品策划考虑不充分，例如一些异常情况的处理；二是技术实现上的难度比估算时更大。因此在A部门的后续其他项目中基本上预留额外的20%项目规模作为缓冲时间。
5．线上Bug
在加入K部门后要求QA部门对线上Bug进行统计分析（见表1-7），并发出月度线上Bug总结邮件，P0级线上Bug指已影响到用户使用的情况，不论影响了多少用户（如支付环节中支付不成功问题）。P1级线上Bug指不影响用户使用的功能（
深入分析这些数据后还发现一个有趣的现象，即约有1/3的线上Bug是由于修改前一个线上Bug导致的，或者由于测试场景不充分、仓促上线导致的。基本上每天都在上线（当然如果CI做得好、自动化测试足够的团队每天上线也许没有什么问题），合代码并进行手动回归测试基本上只有1天的时间。为了减少线上Bug的发生和做到有计划、有节奏地上线，特别制定了固定上线节奏（在K部门是每周二、周五两次）。
6．及时交付率
16个项目中按计划日期上线的有8个（部门中的项目及时交付率为50%），这和访谈中大家谈到的项目延迟严重比较吻合。8个延迟项目中，延迟率从2%到60%不等
通过图1-26的数据可以看出，超出1个月的项目延迟风险比1个月内的项目延迟风险要大得多，其中延迟57%、60%的两个项目主要原因是中途方案调整较大。
建立基本的项目管理流程和度量体系
1. 项目集路线图机制
为什么每天都在救火？每个事情是真正值得做的事情吗？
而仓库间货物转移早在2个月前就已经开始了。是什么导致了如此重要的功能一直没有被提上产品开发日程呢？第二天项目经理和业务部门CTO就此事进行了讨论，得到的结论是平时大家都忙于应付紧急的事情，这些重要的事情往往被一而再、再而三地延后了。
这类情况在其他部门也经常见到，因此对应的一个解决方法是设立部门重点项目集管理，通过每两周一次的产品路线图会议来对项目集中的每个项目状态在核心主管团队中进行回顾，以评估当前的重点项目是否有风险／问题，以及是否有新的项目需要纳入重点项目集中。
图1-27是在K部门所使用的项目集甘特图，其中1～6（浅绿色背景的项目）为部门重点项目。
为了保障重点项目能够有足够的人力投入，与CTO及各位主管达成的协定是：一旦重点项目立项，那么需要保障人力来交付项目，如果其他项目或事情需要挤占重点项目的人力并且影响重点项目交付的话，就需要部门CTO批准了。
2. 三步评审法
在和业务部门领导及团队主管同事讨论后，我们提炼出里程碑规划＋迭代的项目管理基本思路，从项目启动到项目上线，其间辅以3次主要评审活动，取名为“三步评审法”，这些评审活动的目的是使项目团队在“做正确的事”方面更有保障。
三步评审法包含的内容是图1-28中框内的内容，包括策划需求评审、交互／视觉评审和上线评审。
3. 3个评审会议内容结构
表1-8是三种评审会议基本内容。
表1-8中的3个评审会时长限制在1小时，是希望会议组织者、参与者能够在会议前准备好，在会议上重点讨论有分歧的问题，避免冗长而低效的会议。
4. 形成每周固定上线节奏
结合前述访谈的反馈和试点项目的反馈，在业务部门中实施了每周二、周五两次固定上线节奏，上线窗口之外的上线均需要部门CTO批准，做项目计划时将上线时间匹配入对应的上线时间窗口。这样的安排所带来的最直接的一个好处是使研发部门（开发、测试团队）的计划性更强了，工作也更从容了。
5. 最小度量数据集+闭环跟踪指标
通过在试点项目中形成的数据统计，与业务部门领导在项目的最小度量数据集及闭环跟踪指标上达成了共识，其中最小度量数据集主要包含的内容是：人力支出、及时交付率、规模变化率、线上漏洞。
（1）人力支出：在每次项目站会上收集项目成员投入本项目的人力占比，单位为人天，用于衡量项目的基本人力投入。
（2）及时交付率：用于统计项目延迟／及时交付的情况，计算公式是：（项目实际上线日期－项目计划上线日期）／项目计划时长，日期对应的单位为工作日。
（3）项目规模变化率：可以使用人天或者故事点来衡量项目规模，规模变化率是指项目实际所花费的人天或故事点除以计划的人天或故事点，用于衡量产品方案的完备程度。获得较多数据后将可以用于项目缓冲时间的基准。
（4）线上Bug：用来衡量项目质量的一个主要指标，记录线上Bug数量和严重程度。
• 故障等级P0：重要性高的服务功能不可用或功能异常，且大面积影响用户使用。 • 故障等级P1：重要性高的服务功能不可用或功能异常，但影响的用户有限；或者，重要性中等的服务功能不可用或功能异常，且故障持续大面积影响用户体验。 • 故障等级P2：重要性中等的服务功能不可用或功能异常，轻微影响用户体验。
其中闭环跟踪指标主要是在上线的1～3个月内对线上表现情况进行跟踪分析，记录的数据主要是营收和新用户数两大类指标（PV、UV），以及复购率作为辅助指标。
6. 全员培训
一个流程的确定和实施需要广而告之，让部门所有同事知其然、知其所以然，需要讲解为什么选取这样的流程、记录这些数据等内容。对部门全体同事进行培训，是开展后续全面项目管理必不可少的一个环节。全员培训的内容主要是以下四个方面。
（1）流程和项目最小数据集：三步评审法的内容、输入、输出以及需要参与的人员介绍。解释为什么要进行项目的最小数据集度量，每个历史数据将如何使用（这些基本的数据不能用以团队成员的季度考评，主要用来衡量一个部门的整体的项目健康度情况）。 （2）成员职责说明：除了团队成员的各自角色介绍外，其中项目经理和产品经理的职责需要重点介绍，这是一般人比较容易混淆的两个角色。项目经理的主要工作职责是组织和协调项目中各项活动，提高团队效率；项目计划跟踪执行，识别风险和解决团队所遇到的问题；服务于产品，使项目顺利交付。产品经理的主要工作职责是理解用户需求，定义产品形态，形成需求列表，决定功能优先级。 （3）不同项目类型的定义：为了简单起见，将项目分为重点项目、非重点项目两大类别。特别需要对重点项目的评选机制、变更流程进行重点说明，并且让大家清楚地知道当前有哪些项目是重点项目。
对项目管理的反馈
以下是其中一个部门在项目经理介入6个月后的 一些团队反馈，主要结果如下： （1）100%受访者认为项目管理介入后项目管理及时交付率有了提升（数据显示，在项目经理介入的半年中项目及时交付率从20%上升至68%）。 （2）78%受访者对项目管理工作是满意或者非常满意的。 （3）75%受访者认为项目管理介入后项目的透明性、质量方面有提升。 （4）50%受访者认为三步评审法适合目前业务部门的现状，38%受访者认为比较占时间或没什么感觉，12%受访者认为没有必要。
除了上述量化的反馈外，在工作中的项目管理对项目风险的管理、减少外界对团队的干扰、为项目保驾护航等方面带来的好处而赢得团队成员的称赞是无法用量化数字能体现的。
项目管理的下一步
项目管理在一个部门中得到初步的认可了，基本的项目管理流程也已建立了，及时交付率得到了一定的提升，后续项目管理在业务部门中该如何发展呢？ 及时交付项目是对项目管理的基本要求，持续优化项目管理相关流程是项目管理的本职工作。三步评审法只是一个起点，后续要结合项目的实际情况使这些评审中的相关工作更好地落实，并且在效果和会议时间上取得更合理的平衡。 项目中硬性的东西（如流程规范、度量指标、工具使用等）相对而言是比较容易建立的，而团队中软性的东西（如团队文化、激情和士气、认同感等）是需要长时间的引入改变的。后续在保持和维护基本的硬性要求外，将在这些偏软性方面提供更多的项目管理增值服务，如打造相互信任的自组织文化、减少浪费、闭环反馈、教练机制。
1. 打造相互信任的自组织文化
特性团队指承担端到端交付任务的、长期的、跨职能成员合作的一种团队形式，例如一个典型的互联网项目的特性团队包括策划、交互视觉、开发、测试、运营成员。相比目前大多数组织所采用的功能团队（Function Team），特性团队的好处是可以承担完整的、端到端的交付任务，能为结果负责，而不是众多环节中的一个螺丝钉，无须在功能团队间进行任务传递，整个特性团队对项目的成败负责。
大家几乎都建议是把业务部门目前的功能团队组织架构改成类似图1-29中的特性团队。
2. 减少浪费
笔者曾经经历的一个真实而典型的项目是这样的：一个2013年的Win 8 Metro风格客户端项目花费的研发人力成本是24人月，但是2014整个上半年贡献的销售额不足1万元。
应用精益创业中最简产品（MVP）概念来验证需求，将会使这样的“大”失败更少一些，为公司节省资源和费用。
3. 闭环反馈
闭环反馈是为产品、市场、运营活动提供结果跟踪、意见反馈的跟踪手段。
只能说客服反馈意见的时候大家都觉得有道理，但是后续没有相应的措施来保证客服意见被接受和修改到产品、活动中去。久而久之，客服就有点儿麻木了，不再想反馈意见了。我们在后续的过程改进中让客服参与到产品定义、需求讨论中来，使客服（客户意见的代表）的意见真正被重视和被落实。项目上线一个月后的数据分析会上邀请全体项目组同事进行线上数据分析（销售额、PV/UV、新用户数、复购率等指标），让大家能够切切实实地感受所交付的项目带来的价值是什么。如果没有达到目标需要业务负责人给出原因分析和后续改进措施。
4. 教练机制
教练是一个集多种角色于一身的人，但他的主要职责是挑战和激发团队成员的潜力，做团队中那个看不见皇帝“新衣”的小孩，把团队中的问题真实地反映出来，然后促使大家意识到该问题的存在，并通过引导建立相关的团队文化、工具、流程。这些工作不是一朝一夕能够立竿见影的，需要比较长的时间才能看到团队的变化。 笔者一直认为在弱矩阵下的项目经理是一个成本中心而非利润来源，项目经理的价值是通过提高团队的效率、提高项目成功交付率而体现的。项目管理是为业务部门解决问题、提高效率的，而不是单纯地推广流程、文档。 只有成功的产品才有成功的项目，项目管理需要和业务紧密结合才能体现价值，项目管理需要为业务发展提供支持和保障，它没有职责边界限制，它取决于所在的环境需要什么样的项目管理服务。
1.14 悬崖边的舞蹈——小议风险管理及在互联网项目中的应用
风险管理要求我们只能够相信那些真正靠谱的，逐一甄别所有的质疑和信心动摇点。致命风险超出了项目经理的责权范围，除了转交上级，我们还是可以在日常风险管理中加以监测，以便及时提示致命风险转化的可能性。风险需要被持续监测，风险的具体影响需要被明确体现。常见风险列表可以辅助风险排查。
信仰的伦理学
管理的核心是“信仰的伦理学”——风险管理要求我们对于项目推进的每个信念都必须接受伦理的拷问，只能够相信那些真正靠谱的，而将所有的质疑和信心动摇点逐一甄别出来。
风险，并不是带着“坏人”的印记出现的，并不总是件坏事。没有真正意义上的风险，项目注定是失败的。因为，在全无风险的同时，它们也几乎全无收益。 大部分项目经理都会在项目中进行风险管理，但我们往往会看到，或者致命而深刻的风险未被发现，或者风险的初期识别和后期监控脱节，或者虽然控制了部分风险却全然不知对产品和项目的作用何在。
致命风险
典型的致命风险包括但不限于：投资方撤资、大老板改主意了、竞争对手率先发布同类产品、行业市场状况急转直下等。致命风险超出了项目经理的责权范围，只有用“项目假定”才能管理它们。应该对这些风险负责的不是项目团队本身，而是让这个项目诞生的人。所以，识别它们，说明它们，向项目发起人转交它们。
虽然致命风险被作为项目假定转交给上级了，但部分致命风险还是可以在日常风险管理中加以监测，以便及时提示致命风险转化的可能性。 比如，互联网行业的很多领域先发者制胜，如果你的团队正在一片蓝海中探索，那么你一定要紧盯市场上潜在竞争者的动作和状态，有时仅仅提前一周发布就能帮助产品取得先发制人的优势。 又比如，在产品的基本定位上，产品负责人和高层重要干系人的意见不一。那么，你就需要去了解不同思路背后的原因，及时构建各种沟通讨论的桥梁，并根据各种日常项目信号来判断定位差异的变化情况和严重程度，适当时也可以从中施加影响力，促成各方的意见趋于一致。
转化监控
在日常的风险管理中，我们往往在识别和采取了一些措施之后，就自认为已经远离这些风险了。而事实上，对于大部分风险我们所采取的措施并非远离规避，而是缓解或者包容。对这些风险依然可能转化，需要长期监控。
风险的体现
我们有没有这样的体验：虽然我们识别出了以前被掩盖的风险，并且进行 了管理，但除了那一页风险管理文档之外，我们没有看到项目有任何不同，我们并不知道识别出来的这些风险究竟对项目来说意味着什么？
真正的里程碑目标，应该是一张风险图，包括了最早交付日期、最可能交付日期以及最晚交付日期。最可能交付日期应该成为我们真正意义上的计划；而最早交付日期，可以作为团队的奋斗目标。目标只是用于激励员工拿出最高的工作效率；与此同时，在向顾客和管理层做出承诺时，你还需要一个与目标迥然不同的估算计划——真正的计划、最有可能的计划。
比风险图更简单的，我们可以使用风险倍数来体现项目有关的风险（见表 1-9）。风险倍数包括常见的风险，例如人事变动、需求改变、工作上的障碍之类，这些风险倍数让你更准确地估计完成日期和需要多少故事点数（Story Points）。
互联网项目中的常见风险
因此，我们总结并列出了互联网项目的常见风险列表（见表1-10～表1-12），你只需在项目初期逐一对照，就能够形成很有效的初始风险清单。当然，没有任何两个风险是完全一致的，这一列表的作用是辅助头脑风暴或者进行风险排查。真正最重要的风险，往往不是通过走查发现的，而是对日常项目状态把脉洞察，这样那些核心风险就会跃然纸上。
1.15 心的修炼——项目沟通的四个原则
沟通自始至终贯穿了项目从0到1的完整生命路线。本文介绍的沟通四原则，其实核心是内在的心态修炼。然而兵无常势，水无常形，不局限于形式，有强大而又积极的心态才是取胜之道。
原则一 主动尽早
第一条原则就是要敢于尽早暴露问题。只有把问题摆出来了，才可能调动大家的力量来尽早解决问题。 对重要干系人的沟通也是如此。虽然他们非常希望听到产品能顺利交付的好消息，但尽早了解可能存在的问题，一方面可以避免他们向客户传递潜在有误的信息，另一方面可以为团队争取到最及时有力的帮助来解决问题。而这，也一定好过发布前一天才得知一切落空吧！
有人总结说：“项目经理，就是要悲观面对项目，乐观面对团队。”话虽不尽然，但项目经理的确就是项目背后的那一双眼，要纵观全局，发现潜在问题；项目经理也是项目身后那一张嘴，不时提醒大家需要注意的问题或者需要做出的调整。一路报喜，只能粉饰太平；只有对问题的主动和及早沟通协调，才能真正收获最后的喜报！
原则二 抓住本质
生活工作中，有无数类似的场景，讨论由具体的某个“需要”开始。如果纠结于“需要”，沟通就容易陷于泥沼；而如果聚焦“需求”，那就容易达成求同存异。 产品经理和开发者争执于某一个临近发布时提出的需求变更，如果着眼于为什么那么晚才提变更或者进度太紧张，那么结果无论如何总会有人内心郁闷不堪。但如果先一起来看看为什么要做这个变更，对产品、对用户的作用如何，也许结果就变成我们如何去做的讨论了，而不是做和不做或者分清责任的问题了。 只有透过现象看本质，才能在沟通中真正求同存异。
原则三 共情引导
当然，仅仅共情，还是不够的。沟通，尤其是项目沟通，大都希望达成一定的目标，如果仅做了倾诉，是无法解决问题的。因此，以共情为基调，需要在陪伴的情绪中洞察问题根源和解决突破口，并适时加以引导。
原则四 完整解决
和普通的个人沟通不同，项目沟通往往是为了解决项目问题。所以，往往不是一次性的沟通或者和单人沟通就能解决问题的。项目沟通需要在时间维度和沟通对象维度有计划地做拓展，来为解决问题服务。
完整解决，并不是具体的沟通技巧，而是如何完整地安排沟通以及使用不 同的沟通方式来解决问题。项目中，很少有仅凭一人之力就可以解决的问题，尤其是策略性、方向性的问题。需要我们有目标、有计划、有耐心，以积极的心态去面对整个沟通和推进过程。 要做到完整解决，首先要有强大的愿力和强大的内心。愿力，是根本驱动力，是对目标的期待强度。完整解决的过程往往漫长，坚定的决心可以陪伴我们坚持到底。强大的内心，是耐心，是韧性。过程中一定有挫折，一定有起伏，强大的内心可以给我们积极的心态和越挫越勇的精神。
完整解决，已经不仅仅是沟通的问题了，而是项目过程中持续改进的典型实例。有愿景、有策略、有坚持、有反馈，成为真正的闭环，这样才能使项目和团队在改进中成长。
结束语
沟通的过程，技巧其次，关键在沟通的心态和心境。无论是主动尽早、抓住本质、共情引导、完整解决，真正起作用的都是沟通者的内在修炼和积极心态。 我们经常说换位思考。确实，沟通本是为了解决问题，关键就在于走出小我，从对方从全局来思考问题。当我们“忘我”时，就不会再害怕、再遮掩，也不会纠缠于表面利益是非，这时才可以和对方同探讨、共进退，进而完整圆满地解决项目问题。 沟通，可以修炼吗？不，因为它不仅仅是技巧。沟通，可以修炼吗？可以，因为它正是我们人生修炼的过程！
