一个技术人的知行笔记
去年七月，我接手了一个智能仓储系统的交付项目，团队15人，涉及硬件安装、软件联调、客户验收三条线。头两周，我收到的周报就像超市购物小票——“周二改了两个BUG”“周三和供应商确认了货架位置”“周四下午开了个会”。项目经理老张甚至用加粗字体写了“本周加班3天”。我问他：“加班解决了什么问题？”他愣了一下：“……嗯，就是干活。”
那一刻我意识到：周报如果不敲掉“我在干活”这层壳，它就和废纸没区别。
去年Q2，我接手一个政府信息化升级项目，预算580万，周期10个月。项目进行到第4个月时，我犯了一个至今想起来都后背发凉的错误——我允许技术负责人把核心数据库从Oracle迁移到MySQL，理由是他“之前在某大厂用过，性能更好”。我甚至没让他写正式的迁移方案评审文档，只在周会上口头问了一句“风险可控吗？”他说“没问题”，我就点了点头。
一个月后，数据迁移引发了连锁故障。接口响应超时、历史数据缺失、报表全乱。客户CIO直接打电话给分管副总，说“你们这是拿我的系统做实验”。那一刻，我坐在会议室里，盯着被退回的验收单，手心全是汗。最让我懊恼的不是技术问题，而是我明明学过PMP风险管理，却在实际决策中把“专家判断”简化成了“他说行就行”。
那个项目最终延期了6周，我自掏腰包请技术团队连续加班两个周末，才算把数据一致性修回来。但真正的转折发生在那之后的复盘会上——我强迫自己做了一件之前从来没做过的事。
去年我接手了一个新能源充电桩的部署项目，团队里有三个刚通过PMP认证的年轻人。有一次迭代复盘，小王说“风险管理我背得很熟，书上说识别、定性、定量、规划应对、监控，我能倒着背。”我问他具体怎么操作，他愣了三秒，然后说“就……开会讨论吧，大家把风险列出来贴墙上。”会议室里其他人都笑了，说这不就是头脑风暴吗。可问题是，他连“风险登记册长什么样”都没见过——不只是格式，是那种在真实项目里，你写了一条风险，两个月后翻回来发现完全没人跟进的那种登记册。
这件事让我意识到一个残酷的事实：很多考过PMP的人，都卡在“理论懂但实操废”的坑里。更麻烦的是，他们自己分不清自己到底是“理论没学透”还是“实操没练过”。这两个问题需要的解法完全不同，弄反了就是白费力气。
去年秋天，我接手了一个智能仓储系统的交付项目。项目启动第三周，负责接口集成的开发组长突然请假两周，我翻遍团队文件，发现他手里那份《API对接规范》是他自己记在本地Markdown里的，连版本号都没有。等我找人重新梳理时，发现一个关键字段的映射规则写错了——那个错误导致我们和客户方WMS系统的联调多花了整整5天。
那天晚上我盯着墙上的进度看板，突然意识到：我不是缺一个能写文档的人，我是缺一套能让任何接手的人都能快速上手的操作标准。从那以后，我开始认真建自己的项目管理SOP库。这个过程挺有挫败感的——前三个月几乎全部推翻重写。但到今年年初，这个库已经帮我处理了3个紧急项目交接，每次接手新人都能把上手时间从2周压缩到3天。
去年三季度我接手了一个车联网平台的二期项目。项目预算砍了30%，工期压到四个月，但业务方要的功能从36个变成了42个——因为竞争对手刚上线了实时路况预警功能。我翻着那份《资源加载表》时，头顶的灯管开始闪，会议室空调坏了，汗顺着领口往下淌。当时项目组一共12个人，包括我在内，4个开发，3个测试，2个前端，1个UX，外加2个刚从其他项目借调过来的新人，连Git分支都不太会用。
这种情况下，每个PM的第一反应是“我要加人”。但加人是最偷懒的解法，也是效率最低的解法——布鲁克斯法则说过，对已延误的项目加人只会让它更延误。于是我做了一个决定：把所有需求卡片从Jira里倒出来，打印成一面墙。然后我拿了一管红色马克笔，当着业务方和开发组长的面，把所有“好看但不必要”的功能全部划掉。
2019年三季度，我接手了一个政府智慧城市项目的二期工程。项目金额八千万，工期18个月，甲方是某省会城市的大数据局。一期做得磕磕绊绊，二期换了我上去救火。头一个月我干了一件事——把一期所有合同、会议纪要、验收报告翻了个底朝天。翻到第三周，后背出了一层冷汗：一期的技术方案里明确写着“所有数据须在本地政务云部署”，但我们二期采购清单里赫然列着“公有云弹性计算资源”这个大项，预算六百万。原因很简单，一期项目经理觉得政务云性能不够，私下和供应商商量换了方案，但这事儿既没走变更流程，也没向甲方报备，更没人去核查这事合规性意味着什么。
2019年深秋，我走进深圳一家跨境电商公司的会议室，桌上摊着刚上线的ERP系统验收报告，甲方CIO老张翻着报告，脸上没有半点喜色。这个项目花了700多万，历时14个月，团队加班超过2000小时，系统功能实现率100%，Bug率低于行业标准——但上线两周，仓库实际发货效率反而下降了18%。
老张把平板推到我面前：“销售部说新系统让拣货员每天多走3000步，仓储部抱怨流程太复杂，最要命的是，财务发现日均订单处理量比旧系统还少200单。”他苦笑着补了一句：“你们交付了一个完美的系统，但没有交付商业价值。”
那是我职业生涯里最沉重的一课。我花了整整三个月复盘，才真正搞明白：项目收尾和商业价值产生之间，隔着一道绝大多数项目经理看不见的鸿沟。
2019年6月，我负责的某商业银行“智能风控平台”项目正式通过验收。庆功宴上，业务方总监举着酒杯对我说：“这项目做得漂亮，比预期提前两周上线。”我笑着碰杯，心里却压着一块石头。
那块石头，来自三个月前的一次复盘会上的尴尬。当时我向分管副总汇报项目进度，PPT翻到最后一页“预期收益”时，他打断了我的话：“这些收益指标，你打算什么时候开始验证？项目结束就没人管了吗？”
会议室安静了五秒钟。我支吾着说“后续会有运维团队跟踪”，但自己都知道这是个敷衍的答案。那晚我盯着项目章程里的收益实现计划——那页纸写得漂亮，什么“上线后6个月内不良贷款识别率提升15%”，可是谁来测？用什么基准对比？业务数据权限在谁手里？这些细节，当初写计划时我一个都没落实。
那次之后，我做了一件事：在项目进入UAT阶段时，提前拉了一个“收益追踪联席会”。参会人包括业务方数据组负责人、IT运维主管、还有风控部的模型验证员。我开门见山：“项目交付那天不是终点，你们3个月、6个月后要看的数据，今天就得把取数口径和基准定下来。”
具体怎么做的？我要求业务方提供一个“基线数据快照”——就是项目上线前系统运行的原始指标，比如当时人工审批的误判率是多少、平均审批时长是几天。这个快照必须是能在数据库里跑出SQL查证的，不能是“我记得大概怎么怎么样”。然后，我在项目管理工具Jira里单独建了一个“收益跟踪”Epic，给每个收益指标设了三个检查点：上线后1个月、3个月、6个月。每个检查点都绑定了一个具体的执行人，不是“相关部门”，而是“风控部张姐负责取数”、“IT运维李工负责导出日志”。