监控：进展“巧”汇报 ，学会⽤数据说话
我们在做计划的时候 ，明明已经想得⾮常周全了 ，可是 ，真正开⼯之后才发现 ，很多事情并没有那么简 单。
我曾经就经历过这样⼀个项⽬ 。某个课程系统要对其购物⻋功能进⾏扩展改造 ，最初评估时 ，研发认为功能 并不复杂 ，三天就够了。但是 ，开⼯之后却发现 ，这个“坑”改动起来牵涉⾯太⼤ ，⽼的订单系统盘根错节 ，不好下⼿ ，现在看来⾄少也得两个礼拜才能完成。
可问题是 ，这个任务正好在关键路径上 ，如果它延期了 ，所有都得跟着延。更重要的是 ，⽼板特意交待过， 这次上线关系到年底最重要的KPI ，⼀定不能延期……万分紧急之下 ，如果你是项⽬经理 ，你该怎么办？
⾸先 ，必须要冷静！泰⼭崩于前⽽⾊不变 ，这是作为⼀个项⽬经理必须要修炼的⼼态。在项⽬的监控过程 中 ，你会遇到各种各样的情况 ，甚⾄是突发的紧急状况 ，这个时候 ，有效的沟通汇报是必不可少的。那么， 如何更好地进⾏项⽬汇报呢？你可以从以下三个⽅⾯来展开。
紧急汇报：直⾯问题有章法
在程序员看来 ，我只管安⼼⼲活就好 ，特别不希望有⼈打扰 ，问东问西。假设执⾏中遇到困难 ，往往也更习 惯于⾃⼰琢磨 ，拼命地想要把进度赶回来 ，不到最后⼀刻绝不把问题暴露出来。结果 ，等到被发现的时候 ， 往往已经是很⼤的进度偏差了。
承认⾃⼰遇到了问题需要帮助 ，其实是件⾮常困难的事情。毕竟 ，很多⼈都有“特别想要把事情做好 ，让⽼ 板有个好印象” 的⼼态。但是 ，作为项⽬管理⼈员 ，当事情已经超出了你的可控范围时 ，你⾸先要做的 ，就 是第⼀时间直⾯问题 ，如实地呈现和反馈遇到的困难。对于整个项⽬⽽⾔ ，你的真实和坦诚反⽽是最重要的。
但是 ，很多程序员其实并不擅⻓汇报 ，更别说这种特别困难的场景了。那么 ，接下来 ，我就给你介绍⼀种紧 急问题的汇报⽅法。
紧急报告 ，是指在项⽬发⽣突发事件 ，或者提⽰重要⻛险状态变化时的实时报告 ，
⽐如遇到⾼⻛险延期、线 上重⼤问题、或者重要客⼾投诉等 ，⽬的是向全组或者主要⼲系⼈通报项⽬的重要变化 ，以及时协调应对⼯ 作 ，或者第⼀时间寻求外部⽀援。
由于事发突然 ，紧急报告⼀般不需要拘泥于具体的形式 ，关键在于⾔简意赅地传递信息 ，并组织后续的跟进 动作。⼀般来说 ，紧急报告会包含5个基本元素：
1. 事件描述；
2. 影响后果；
3. 跟进分析；
4. 响应措施：包含负责⼈及时间表；
5. 所需⽀持。
我们来结合实际案例看⼀下紧急报告要怎么写。 以开头的那个项⽬为例 ，我们来看看那位项⽬经理当时的紧 急报告：
1. 事件描述：购物⻋改造功能⾼延期⻛险；
2. 影响后果： 由于此功能在项⽬的关键路径上 ，很有可能会造成项⽬整体延期两周；
3. 跟进分析： 本期购物⻋改造功能 ，有部分调整涉及到底层订单系统 ，⾥⾯有⼤量遗留代码 ，已经很久没 有⼈维护了。之前对此⻛险的评估不够充分 ，改动⻛险很⾼ ，可能会影响全站订单系统的稳定性 ，具体 影响仍需要详细分析；
4. 响应措施： 主程全⼒以赴做好技术评估 ，本周内给出详细任务评估时间表；与此同时 ，产品⼈员介⼊， 调研规避⽼系统⼜能满⾜需求的可⾏性 ，本周内给出调研结论；
5. 所需⽀持： 熟悉⽼系统的资深技术⼈员 ，以及红⽜⼀箱。
这份紧急报告提交以后 ，发起⼈第⼀时间就会关注到 ，项⽬组正⾯临着⾮常棘⼿的问题 ，以及可能造成的影 响和后果。 同时 ，他也了解到 ，团队正在试图解决这个问题 ，⽬前的解决⽅案是什么 ，还需要什么样的⽀持 和帮助。 当然 ，如果你能够第⼀时间跟发起⼈当⾯沟通 ，效果会更好。关于沟通的具体内容 ，你同样可以参 考我刚刚给你分享的这个模版。
回到刚刚的案例 ，最后 ，产品⼈员跟开发⼀起修改了产品逻辑 ，尽可能地规避了⼀切上线后的⾼⻛险项。这 次紧急情况的汇报 ，让他们及时调整了后续灰度发布的时间安排 ，以及上线后的运营⽅案 ，避免了⽤⼾侧更 ⼤的影响和损失 ，同时也把对KPI的影响降到了最低。
总之 ，执⾏过程中突发的紧急情况 ，⾮常考验项⽬经理的专业素养。⾸先 ，你必须要直⾯问题 ，在紧急时刻 勇于站出来承担责任 ，不仅不会让⽼板对你的印象减分 ，还能让决策者在第⼀时间选择更好的应对⽅式。另 外 ，你要尽可能简洁地描述清楚可能的影响和后果 ，⽬前的建议⽅案和所需⽀持 ，最⼤程度地争取各个相关 环节的协同配合 ，共同应对问题。
常规汇报：项⽬周报回答的三个问题
讲完了紧急情况下的汇报 ，我们再来看看常规汇报该如何做。我看到过很多程序员的项⽬周报（如下图）， 虽然周报⾥清楚地罗列着上周做了什么 ，下周要做什么 ，但是看完之后 ，我经常⼀头雾⽔。
这是因为 ，周报⾥只有⼀堆任务流⽔账式的罗列 ，但是 ，项⽬的整体进展状态到底如何？ ⻛险可控吗？ ⽬标 达成有没有问题？ 周报⾥都没有提到。
实际上 ，⼀份好的项⽬周报 ，最重要的就是回答好这三个问题。 为了更直观地描述项⽬的状态 ，我们可以使 ⽤天⽓图标 ，把项⽬分成以下六个等级：
有了天⽓图标和⻛险等级提⽰ ，项⽬汇报就清晰多了 ，如下图所⽰：
实际上 ，项⽬周报是向项⽬团队和⼲系⼈沟通项⽬状态的常⽤⼿段 ，你需要⽤简要的⽅式呈现项⽬全貌 ，客 观地展⽰项⽬问题 ，推进问题解决。我给你分享⼀份周报模板 ，你可以根据⾃⼰项⽬组的需要 ，选择合适的 内容模块。
在这份项⽬周报模版中 ，最必不可少的就是整体项⽬状态评估、⻛险列表、项⽬概况及计划变更情况。好的 周报 ，应该让⼤家对项⽬现状的三个问题形成统⼀ 、清晰的整体认知。这份整体认知 ，可以让平时扎在细节 ⼯作中的⼈ ，从全局视⻆来了解和看待整体 ，从⽽更好地完成⾃⼰的⼯作。
需要你注意的是 ，⼀份周报的阅读时间不应超过5分钟。 因此 ，在写到进展和问题时 ，切忌事⽆巨细 ，只写 要点就够了。周报不是为了表现⼯作量 ，更不是为了刷存在感 ，只说重点就够了。
数据汇报：善⽤ “透明”的⼒量
我在第1讲中提到过 ，作为新⼿项⽬经理的我 ，经常觉得哪⼉哪⼉都是问题 ，今天催这个 ，明天推那个 ，可 就是什么事都推不动 ，谁都不配合。后来 ，我发现 ，与其每天挨个去盯梢 ，不如多花点功夫 ，把这些状况全 部“透明” 出来！
说⼲就⼲！ 我开始研究Jira中的各种图表。俗话说 ，⼀图胜千⾔ 。拿线上事故的改进措施为例 ，每次都说要 建⽴完善的保障体系 ，可是经常⼀个⽉过去了 ，也没什么进展。 于是 ，我就把事故数据拉出来 ，根据原因定 位 ，分⻔别类地做成直观的数据图表。后来 ，我发现 ，只要我坚持在项⽬组⼤群⾥发上三天 ，表格上的数据 就会悄⽆声息地发⽣变化 ，改进项清零的速度也加快好多。
那是我第⼀次体会到“透明” 的⼒量。在这以后 ，在项⽬汇报和⽇常跟进中 ，能够⽤图表和数据的 ，我就不 会⽤⽂字。作为项⽬管理⼈员 ，你⼿中不⻅得有多少权⼒ ，但有⼀种强⼤的⼒量 ，你⼀定可以⽆限获取 ，那 就是“透明”。
我给你介绍⼏种常⻅的项⽬仪表盘 ，这些图表 ，你都可以快速地在JIRA中绘制出来。其中 ，倒计时图是个⾮ 常醒⽬的标志 ，可以帮助⼤家建⽴清晰的时间意识 ，⽽⼯作任务的状态分布和剩余⼯作量分布 ，可以清晰地 展现出每位成员的⼯作排布情况 ，帮你快速发现和定位执⾏过程⼈员⼯作量的瓶颈。
这⾥我想要特别介绍下燃尽图（Burn Down Chart） ，这是敏捷开发⽅式中⽤于表⽰任务完成趋势的⼯作图 表 ，横轴表⽰时间 ，纵轴表⽰⼯作量。如果你在做好规划之后 ，把任务和⼯作量录⼊JIRA ，设定好迭代的预 期完成时间 ，就可以⾃动⽣成这样的图表。
这种图表可以直观地进⾏过程预测和⻛险预警 ，其中 ，灰⾊线是计划完成情况的基线 ，红⾊线代表实际完成 情况。在进展顺利的情况下 ，红⾊实际线会紧贴着灰⾊计划线 ，⼀路往下 ，直到“燃烧殆尽”。每天开站会 时 ，更新完任务状态之后 ，团队可以⼀起看下燃尽图的变化。如果红⾊线连续多天居⾼不下 ，⼀直停留在灰 ⾊线上⽅ ，这就说明进展持续低于预期 ，你就要多加关注了 ，具体分析到底是哪个环节拖了后腿 ，然后有针 对性地发起改善。
JIRA上有丰富的插件去获取各类图表和数据。不过 ，⽐⼯具更为重要的是 ，你要结合项⽬组中当前需要重点 推进或改进的事项 ，选择合适的数据和图表去做“透明”。
总结
今天我给你介绍了在监控过程中 ，进⾏项⽬进展汇报的⼏种⽅法 ，包括紧急汇报的五个元素 ，常规项⽬周报 要包含的重要内容 ，以及如何运⽤透明的⼒量 ，通过数据汇报推动问题的解决。
有同学留⾔说 ，⾃⼰的项⽬前期拖沓 ，需求稿、设计稿经常给得很晚 ，开发承受着很⼤的压⼒ ，只好拼命加 班。我曾经也遇到过类似的情况 ，为了促发改变 ，我尝试客观记录了策划、设计、开发、测试等各个环节的 时⻓分布 ，以及可能带来的后期⻛险。这份数据在项⽬汇报中展⽰以后 ，引发了管理层的⾼度关注 ，在下⼀ 个版本中 ，问题很快就得到了改善。
可以说 ，项⽬进展汇报是项⽬经理⾯向所有⼲系⼈ 、⾮常重要的⼀个沟通和发声的平台 ，运⽤得好的话 ，可 以成为项⽬经理有⼒的杠杆⼒量。有效运⽤这个杠杆的秘诀就是：想要改善什么 ，你就去透明什么 ，越直观 越好！
