周日晚上十点，一位项目经理接到领导电话，让他第二天赶去客户现场“顶包”。要求只有一个：在客户结账截止前，把系统里的账调明白。
这个项目五个人，做了两个多月，周报一路全绿，上线也踩着计划节点。所有人都觉得成了。
第一个账期结账，期初库存和客户的实际账对不上，而客户的结账窗口不能拖。原项目经理辞职，系统经理辞职，临时接手的项目经理也撂了挑子。
最后两个人从下午对到凌晨五点，才发现系统的对账逻辑跟客户从来不是一套。知乎
两个多月，五个人，没人发现。不是技术有多难，是没人去对齐“两边到底按什么规则对账”。
周报全绿，只说明汇报体系在运转，证明不了项目健康。小红书知乎
绿通常是这样长出来的。
研发按代码行数或模块框架估进度，填个“完成90%”。可前80%的代码往往只花40%的精力，联调、异常边界、缺陷修复才是黑洞。90%常常意味着硬仗刚开始。知乎
前置接口晚了三天，开发想着后面加班补回来，不上报。任务之间有依赖，一个节点的浮动会顺着关键路径往下滚。周报仍是绿的，关键路径已经被压扁。
客户一句“顺手改个小字段”，半天变三天。变更不走评估，排期表纹丝不动。
再往下，是报忧的成本。坏消息晚一周报，传到决策层就成了毒药；报早了，可能先被追问“为什么没做好”。于是问题被留在各自手里，直到藏不住。
PMO如果只收周报，就只能收到这种经过美化的二手现实。
要把绿色拆开看，得换三样东西。
进度别再用百分比。接口设计完成，以接口文档通过评审为准；模块开发完成，以单元测试通过并完成代码合并为准；系统提测，以冒烟用例全部通过为准。
没有交付物支撑的“推进”，一律不算完成。知乎
盯领先指标，而不是完成时间。
缺陷新增远高于关闭，说明测试节点要延期；核心角色负载长期超过100%，瓶颈一定会爆；一个预估16小时的模块已经投了30小时还没提测，这就是异常，不用等下个月。
给坏消息一条比好消息更快的路。
风险从发生到上报超过三天就升级，不管报的人是谁。谁第一个报出重大隐患，谁就该被奖励，而不是被质问。例会也别逐条听流水账，只过标红的异常和没闭环的风险。小红书
那位项目经理后来写道：项目里最贵的成本，从来不是写代码，是“你以为对得上、其实从头就没对上”的假设。
周报可以绿，但PMO得知道，绿色下面有没有东西在烂。
