一个技术人的知行笔记
三年前，我接手了一个跨国ERP实施项目，客户在德国，团队在上海和班加罗尔。项目启动会上，我用PMP那套铁三角——范围、时间、成本——给客户做了个漂亮甘特图，每个里程碑精确到天。德国项目经理Albrecht看完后没说话，第二天发来一封邮件，抄送了双方VP。邮件里他圈出六个关键节点，问：“如果第8周需求的第三版变更来了，你准备怎么用变更控制流程同步三个时区？”
我当时自信满满地回复了他PMP官方教材第4章的内容。三个月后，我们项目延期了6周。不是因为变更控制没用，而是因为我把那套东西背得滚瓜烂熟，但根本没“长”在身上。
去年七月，我接手了一个智能仓储系统的交付项目，团队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里倒出来，打印成一面墙。然后我拿了一管红色马克笔，当着业务方和开发组长的面，把所有“好看但不必要”的功能全部划掉。