概述
上一篇给大家讲解了启动，规划，执行的项目中重要的3个过程，下面给大家介绍监控，收尾过程。
监控：进展“巧”汇报，学会用数据说话
我曾经就经历过这样一个项目。某个课程系统要对其购物车功能进行扩展改造，最初评估时，研发认为功能并不复杂，三天就够了。但是，开工之后却发现，这个“坑”改动起来牵涉面太大，老的订单系统盘根错节，不好下手，现在看来至少也得两个礼拜才能完成。可问题是，这个任务正好在关键路径上，如果它延期了，所有都得跟着延。更重要的是，老板特意交待过，这次上线关系到年底最重要的 KPI，一定不能延期……万分紧急之下，如果你是项目经理，你该怎么办？首先，必须要冷静！泰山崩于前而色不变，这是作为一个项目经理必须要修炼的心态。在项目的监控过程中，你会遇到各种各样的情况，甚至是突发的紧急状况，这个时候，有效的沟通汇报是必不可少的。那么，如何更好地进行项目汇报呢？你可以从以下三个方面来展开。
紧急汇报：直面问题有章法
在程序员看来，我只管安心干活就好，特别不希望有人打扰，问东问西。假设执行中遇到困难，往往也更习惯于自己琢磨，拼命地想要把进度赶回来，不到最后一刻绝不把问题暴露出来。结果，等到被发现的时候，往往已经是很大的进度偏差了。承认自己遇到了问题需要帮助，其实是件非常困难的事情。毕竟，很多人都有“特别想要把事情做好，让老板有个好印象”的心态。但是，作为项目管理人员，当事情已经超出了你的可控范围时，你首先要做的，就是第一时间直面问题，如实地呈现和反馈遇到的困难。对于整个项目而言，你的真实和坦诚反而是最重要的。但是，很多程序员其实并不擅长汇报，更别说这种特别困难的场景了。那么，接下来，我就给你介绍一种紧急问题的汇报方法。
紧急报告，是指在项目发生突发事件，或者提示重要风险状态变化时的实时报告，比如遇到高风险延期、线上重大问题、或者重要客户投诉等，目的是向全组或者主要干系人通报项目的重要变化，以及时协调应对工作，或者第一时间寻求外部支援。由于事发突然，紧急报告一般不需要拘泥于具体的形式，关键在于言简意赅地传递信息，并组织后续的跟进动作。一般来说，紧急报告会包含 5 个基本元素：
我们来结合实际案例看一下紧急报告要怎么写。以开头的那个项目为例，我们来看看那位项目经理当时的紧急报告：
事件描述：购物车改造功能高延期风险；影响后果：由于此功能在项目的关键路径上，很有可能会造成项目整体延期两周；
跟进分析：本期购物车改造功能，有部分调整涉及到底层订单系统，里面有大量遗留代码，已经很久没有人维护了。之前对此风险的评估不够充分，改动风险很高，可能会影响全站订单系统的稳定性，具体影响仍需要详细分析；
响应措施：主程全力以赴做好技术评估，本周内给出详细任务评估时间表；与此同时，产品人员介入，调研规避老系统又能满足需求的可行性，本周内给出调研结论；
所需支持：熟悉老系统的资深技术人员，以及红牛一箱。
总之，执行过程中突发的紧急情况，非常考验项目经理的专业素养。首先，你必须要直面问题，在紧急时刻勇于站出来承担责任，不仅不会让老板对你的印象减分，还能让决策者在第一时间选择更好的应对方式。另外，你要尽可能简洁地描述清楚可能的影响和后果，目前的建议方案和所需支持，最大程度地争取各个相关环节的协同配合，共同应对问题。
常规汇报：项目周报回答的三个问题
讲完了紧急情况下的汇报，我们再来看看常规汇报该如何做。我看到过很多程序员的项目周报，虽然周报里清楚地罗列着上周做了什么，下周要做什么，但是看完之后，我经常一头雾水。
这是因为，周报里只有一堆任务流水账式的罗列，但是，项目的整体进展状态到底如何？风险可控吗？目标达成有没有问题？周报里都没有提到。实际上，一份好的项目周报，最重要的就是回答好这三个问题。为了更直观地描述项目的状态，我们可以使用天气图标，把项目分成以下六个等级：
实际上，项目周报是向项目团队和干系人沟通项目状态的常用手段，你需要用简要的方式呈现项目全貌，客观地展示项目问题，推进问题解决。我给你分享一份周报模板图，你可以根据自己项目组的需要，选择合适的内容模块。
在这份项目周报模板中，最必不可少的就是整体项目状态评估、风险列表、项目概况及计划变更情况。好的周报，应该让大家对项目现状的三个问题形成统一、清晰的整体认知。这份整体认知，可以让平时扎在细节工作中的人，从全局视角来了解和看待整体，从而更好地完成自己的工作。需要你注意的是，一份周报的阅读时间不应超过 5 分钟。因此，在写到进展和问题时，切忌事无巨细，只写要点就够了。周报不是为了表现工作量，更不是为了刷存在感，只说重点就够了。
数据汇报：善用“透明”的力量
作为新手项目经理的我，经常觉得哪儿哪儿都是问题，今天催这个，明天推那个，可就是什么事都推不动，谁都不配合。后来，我发现，与其每天挨个去盯梢，不如多花点功夫，把这些状况全部“透明”出来！说干就干！我开始研究 Jira 中的各种图表。俗话说，一图胜千言。拿线上事故的改进措施为例，每次都说要建立完善的保障体系，可是经常一个月过去了，也没什么进展。于是，我就把事故数据拉出来，根据原因定位，分门别类地做成直观的数据图表。后来，我发现，只要我坚持在项目组大群里发上三天，表格上的数据就会悄无声息地发生变化，改进项清零的速度也加快好多。那是我第一次体会到“透明”的力量。在这以后，在项目汇报和日常跟进中，能够用图表和数据的，我就不会用文字。作为项目管理人员，你手中不见得有多少权力，但有一种强大的力量，你一定可以无限获取，那就是“透明”。我给你介绍几种常见的项目仪表盘，这些图表，你都可以快速地在 JIRA 中绘制出来。其中，倒计时图是个非常醒目的标志，可以帮助大家建立清晰的时间意识，而工作任务的状态分布和剩余工作量分布，可以清晰地展现出每位成员的工作排布情况，帮你快速发现和定位执行过程人员工作量的瓶颈。
这里我想要特别介绍下燃尽图（Burn Down Chart），这是敏捷开发方式中用于表示任务完成趋势的工作图表，横轴表示时间，纵轴表示工作量。如果你在做好规划之后，把任务和工作量录入 JIRA，设定好迭代的预期完成时间，就可以自动生成这样的图表。这种图表可以直观地进行过程预测和风险预警，其中，灰色线是计划完成情况的基线，红色线代表实际完成情况。在进展顺利的情况下，红色实际线会紧贴着灰色计划线，一路往下，直到“燃烧殆尽”。每天开站会时，更新完任务状态之后，团队可以一起看下燃尽图的变化。如果红色线连续多天居高不下，一直停留在灰色线上方，这就说明进展持续低于预期，你就要多加关注了，具体分析到底是哪个环节拖了后腿，然后有针对性地发起改善。JIRA 上有丰富的插件去获取各类图表和数据。不过，比工具更为重要的是，你要结合项目组中当前需要重点推进或改进的事项，选择合适的数据和图表去做“透明”。
收尾：项目复盘，小团队也要持续改进
复盘原本是围棋术语，是指每次博弈结束之后，双方棋手把刚才的对局复演一遍，分析对局当中得失的关键，是提升自己棋力的好方法。其实，复盘是对思维的训练。通过复盘，当类似的局面再次出现在你面前的时候，你就能够快速地预测接下来的动态和走向，并且更好地应对。而项目复盘会，可以说是项目团队有意识地向过去的行为经验学习的过程。在项目或里程碑完结之后，项目经理会组织召集项目成员，一起回顾一下，在项目的整个历程中，团队做对了哪些事，做错了哪些事，再来一次，如何做得更好，借此把项目行进过程中产生的集体智慧沉淀下来。但是，现实情况经常是，项目一个接一个地做，忙上线、忙变更、忙返工，哪有时间坐下来复盘？又有多少复盘会，是为了复盘而复盘，逐渐地流于形式，成为了可有可无的摆设？除此之外，还有很多复盘会，成为了追责者的工具，除了锻炼出花样百出的各种甩锅技能之外，留下的只有“一地鸡毛”。由此可见，要想做好项目复盘，并不是一件容易的事情。今天，我就带你来看一看，如何做好项目复盘，以及如何通过复盘去培养团队的持续改进能力。
复盘会的基调设定
我们都知道复盘很重要，但实际上，在复盘会之前，想清楚我们复盘的目的，设定好复盘的基调，其实更为重要。我曾组织过一个复盘，叫作“坑爹功能”大搜罗。参与复盘的十多位团队 Leader，在现场写了 20 多页纸，满满当当地罗列着我们曾经做的、却没什么人用的功能。实际上，只有当大家真正摊开不太愿意面对的真相，去认真思考背后的深层原因时，我们才能共同进入真正的集体反思区。这样坦诚地直面问题的复盘，才能促发有意识的集体学习。要想让参与者真正进入集体反思区，会前就要设定好开放的复盘基调。其实，我们每个人都可以在自己所处的环境中，看到各种各样的问题。如果复盘是出于追责，那么在会议刚开始时，大家就可以迅速地感受到，这样一来，每个人都会小心地避开自己的问题，转而去说别人的问题，这样的复盘就失去了意义。那么，如何设定开放的基调呢？
首先，我们自己要先进入反思区。其实，在那次复盘会之前，我跟这个部门的负责人，就部门中反复出现的各种问题，进行过多次深度沟通。一开始，这位负责人觉得团队里到处都是问题。但当我们把问题一层层地剖开来看时，我们发现了很多问题背后的深层原因。除此之外，在会议刚开场，就要展示出自己的开放与坦诚，给复盘会奠定基调：这次复盘不是来挑问题的，而是为了找到问题的根源并改进的。在那次复盘会上，这位负责人特意讲了自己这一年来的深刻反思，这就带动大家敞开心扉，直面问题。那次会上，大家自发地找到了在各个环节有效避免无用功能的方法。会议结束以后，这个部门还发起了一项“整风运动”，从增强用户意识的讲座，到用户调研方法的培训，再到激励与考核制度的挂钩，让复盘会反思的成果，逐渐渗透到了每个人的日常工作中。
复盘会的会前准备
除了设定基调，你还需要充分的会前准备。在复盘会之前，你要去梳理整个版本的历程，包括项目或里程碑的各项数据和信息、目标和达成结果、进度计划、需求变更、质量状况等，这些是客观数据的总结。同时，你还可以提前收集这个版本期间，团队满意度的问卷调查，为复盘会引入更多主观的输入。除此之外，视频也是非常好的回顾材料。曾经，在某次重要版本的复盘会前，我熬夜加班，为团队准备了一段回顾视频。这个团队刚刚完成了一件几乎不可能完成的任务。因为客户的需求非常迫切，往常要做一个半月的大版本，直接压缩到三周内完成，团队非常非常辛苦。虽然视频的制作手法很粗糙，但那些加班到深夜开迭代演示会的照片，还是让现场的很多人感动不已，瞬间为这个疲惫的团队注入了能量。其实，复盘会的基调设定，以及会前的准备工作，在开会之前，就很大程度地决定了复盘会的效果，你一定要特别留意。了解了这些之后，我们就来看看复盘会的流程。
复盘会的简易流程
复盘会的流程，其实并不复杂。在实战中，我总结出了一套最为高效的复盘流程。
现场回顾总结项目 / 里程碑的整体概况，包括目标达成情况、进度计划及变更情况、需求变更情况、质量报告等项目历程记录。
与会人员用便签纸写下项目过程中做得好的以及做得不好的 3 个点，按照项目的各个环节分类，分别贴在白板上，确保大家的意见能够充分、自由地表达。
在白板前逐条 review 大家的意见，共同发现问题，并有针对性地展开讨论。对大家总结出的好和不好的点，进行集体投票。
由项目经理整理投票结果，对于做得好的环节，总结经验；对于做得不好的环节，当场讨论出改进方案。
无法促发行动的复盘，说得再好都是空谈！一开始开复盘会，大家会期待，解决的问题越多越好，但焦点增多之后，哪个都是蜻蜓点水地过一遍，哪个都没改彻底。下次再开会的时候，大家发现之前反馈的问题依然还在，那谁还有动力继续提问题呢？所以，改进措施一定要落地，重点行动不要太多，一个就够了！如果每次复盘聚焦于改进项中的 Top 1，确保改进措施真正落地，长期坚持下去，就会促进持续的能力提升。同时，复盘的次数也不要太多，你并不需要每个版本、每个迭代都例行公事地去做一遍，确保每个季度有一到两次里程碑复盘，可以完整地对项目做系统化的梳理，达到真正的落地效果，才是更重要的。
打造团队持续改进能力
其实，项目复盘不只是一次会议，它更应该成为团队持续改进的推动力。那么，怎样才能让一次成功的复盘发展成为复盘文化，激发团队自主地持续精进呢？实际上，想要让团队进入自发改进的正向循环，你需要更好地激发团队的主人翁意识，让团队成为复盘的主角，而不是你。最重要的是，你不仅要关注事，还要关注人。我曾经为某部门组织过一次复盘会，取名叫作“研发代表大会”。当时，我们把部门中所有资深的程序员召集在一起，让他们给平台越来越严重的技术债问题出谋划策。这次复盘我采用了“批奏章”的玩法，各位代表把自己的意见写在纸上，然后围成一个圈，依次传递给左边的同学，每个人把手上的“奏章”批阅完成后，继续往左传。这样一圈转下来，+1 数最多的那份“奏章”，就会被选出成为年度力荐。最后，这份“奏章”得到了最多的关注和资源，这项建议迅速得到了落实。同时，这样的复盘方式，也让更多的研发同学享受到了“批奏章”的愉悦感，一旦他们发现，自己选出的“奏章”会得到采纳和落地，那么这个“研发代表大会”也就可以真正地自行运转起来，更多人愿意主动参与进来，通过这个平台，发表自己的见解，为整体能力的提升贡献一份力量。另外，越是困难时期，越是塑造团队能力的大好机会。在团队遇到重大困难时，你也可以及时组织一场复盘会，深度关注和调整个人的状态。我就曾经试过让每个人画出自己进入这个项目组以后的状态变化曲线，跟大家分享自己的“高光时刻”和“至暗时刻”。在业务低落期，这样的复盘会会成为一个重要的转折点，让团队的力量得到深度聚合。这些对人的关注，都会让复盘会超越问题解决的层面，在推进事的同时，促使团队自发地推进问题的解决，并把经验内化下来，从而不断提升团队的持续精进能力。
好了，让我们对复盘做个小结。其实，当人们在说复盘时，往往会把焦点放在复盘会本身。但我却认为，决定复盘成功与否的关键，不在会议本身，而在于复盘会的一前一后两个环节。复盘会前，复盘基调的设定是否开放，复盘会前的各项准备是否充分，对于复盘会的效果非常关键。组织一个复盘会本身并不难，难的是在复盘会后，持续跟进这些反思，落地为切实的改进措施，让团队真正看到效果，从而打开团队持续改进的正向循环。最后，我建议你认真地做好一次复盘，每次复盘后聚焦一个改进点。再提醒你一句：聚焦点别太多，一个就够了！
总结
以后关于数据中台系列的总结大部分来自Geek Time的课件，大家可以自行关键字搜索。