那会儿做 PMS 的时候，我最见不得就是那个投影仪讲完 PPT，老板在台下转得比转悠得动螺丝还快。 说实话，刚启动我也认定项目就是写个需求文档，给开发一点技术细节，外包商把需求挑出来，咱们再把坑填上，大约三个月就能上线。
那时候我自信得像个刚毕业拿过奖学金的学生，认定自己是项目里的定海神针，直到那个深夜的 jam（阻塞）报告出来，我才明白，那根本不是好办的填坑。 真正的痛点在于，我们当作自己在管理进度，实际上是在管理推不动的墙。记得有一次个模块被卡死，我当作是出于测试环境配置不对，结局经过查日志才发现是上游接口协议版本不兼容，咱们文档里明明写了“接口适配”，但那个文档是关于“未来三年架构演进”的，根本就没写清楚当前版本到底用啥协议。我就如此站在进度表上，看着开发团队在屏幕上敲得满头大汗，心里直骂：“这都啥时候的事儿啊？”后来那个模块的延期，大抵也就那几天吧。 这种“看不见的难题”，往往比显性的延期更让人肝火。我们一直盯着燃尽图看，盯着任务列表里的进度条，却唯独对需求本身充满了质疑。我也见过如此个案例，需求经理说“这个功能务必对接”,研发说“接口没定”,测试说“测不了”。结局就是需求经理被骂，研发被怼。
这时候再想找人背锅，才发现是流程黑洞。我们习惯把责任推给“沟通不到位”，但难题出在：哪位负责写接口文档？哪位负责定协议标准？哪位负责在代码通过前锁定状态？要是没有人半步负责，依赖关系就彻底成了摆设。 那时候我就启动琢磨，到底该如何把项目从“推着走”变成“自己走”。我不光要盯着燃尽图，还得盯着需求文档。有个兄弟团队，他们做得了得，就是有个不成文的规定：需求文档务必包含“接口契约”和“验收标准”两局部。需求经理写完文档，哪怕只有一张 AQL 要么接口文档，也要发给 PO 确认，PO 务必签字。
要是签字，再看能不能用。
这个细节听起来不起眼，但每次代码提交黄了，我都能顺着这个文档找到根因。
哪怕只是版本号不对，要么字段命名不规范，只要文档里写明白，就有迹可循。 我也试过用甘特图强制管住节奏，结局发现项目越来越像机械流水线。上游进度好，下游自然好；上游慢，下游立马崩。
这种时候，我才会想起一个老话：项目不是加法，是乘法。上游进度快，项目进度就是快；上游进度慢，哪怕下游再努力，整个项目也慢得像坐针毡。
那会儿我认定跨部门沟通挺费事，目前才懂，那实际上是信息不对称的恶性循环。上游说不准，下游不敢动，结局哪位也别动。 后来我意识到，要解决这个难题，唯一的办法就是让文档真正成为契约。
不止是写需求，得把界面、接口、数据字典、上线标准，统统写进文档里。
不管哪位要改，都得先按文档来。
哪怕文档写得慢，只要规则定了，大家心里就都有数，也不用再猜来猜去。
那时候我总认定，那些繁琐的表格和会议，实际上都是在维护这份契约的严肃性。 不过，我也没那么天真。法律法规和行业标准是硬约束，代码实现是硬门槛，流程合规是底线。
这些条条框框，务必得记着，不能下意识地去踩。但真正能转变项目命运的，是把软性的“沟通”变成硬性的“契约”。 目前的趋势，实际上是大家越来越意识到，PM 的价值不在于你一天能拉出一个多长的燃尽图，而在于你能不能让项目少走弯路，别让文档成为摆设，别让依赖关系成为黑洞。
要是只要文档写得完美，流程就通顺，项目就能跑得稳，那确实值得追求。 但我更清楚，大局部时候还是得靠经验去扎破这些气泡。
有时候拼的不是文档的深度，而是哪位愿意去啃那块难啃的骨头，哪位愿意在文档里多花两分钟把接口标准把这个坑填上。
要么别做 PM，要么做能填坑的 PM。 最终总结，项目管理的核心，实际上就是把不确定性转化为确定性。把不清楚的需求变成清楚的协议，把松散的协作变成严密的契约。
只要这根锚还在，船就不会散。 故此，别总指望别人帮你填坑。
要是你手里没有文档，就别指望别人能帮你填坑。文档不是纸，是帮你规避风险的盾。
只要盾在手里，项目就保险；要是你把盾扔了，再多的努力，也可能是一场空。