摸鱼指南：用项目管理图聊聊那些“没做但看起来在忙”的事儿 最近有个项目经理，把周密的 Gantt 图贴在墙上，每天盯着格子发呆，结局项目延期两周。我跟他聊过，认定这图实际上是在“反人类”。 拿个会议举例吧。他画了个图，左边是“核心业务”，右边是“需求分析”，中间夹着“设计评审”、“开发测试”、“上线发布”还有“售后回访”这几个大块。他花了一下午微调线，认定这样就显得有条理。 实际上挺荒谬的。你还没启动画这个图，你就大约清楚每个环节该干啥了。真正的管理不是张罗，是看出难题。
比如他那个“需求分析”一栏，写得密密麻麻全是“用户行为”、“并发量”、“兼容性”，结局开发那边说：“需求分析是产品经理的事，你们开发只管按文档干活就行。”结局文档没改，需求又变了，开发天天改需求，人也累瘫了。 再比如他的“设计评审”环节。图上标着“评审”，底下连个日期的坑都没填。他当作评审是形式主义，要么干脆忘了这个动作。
后来真有人提了活，他随口一句：“没事，明天碰一下就行，不用正式走流程。”结局难题一没解决，接口对不上，功能不中，客户直接喊破口。 还有那个“上线发布”，图上写得挺响，拍板今天截止。可今天还没启动，他还在群里发语音说“全员就位，预备好嘛”。等到真要开会的时候，没人去现场，只有他一个人在办公室，大家互相观望，最终还得催他。“快点，都早上了！”他吼一声，眼神却飘着手机。“那个接口调试完了没？”他问身边人。对方摇摇头：“还没。”“那就再开一上午，明天早会再开。” 这就是典型的“画得挺满，做得挺空”。图做得越细，执行起来越松。项目经理当作把事摆平了就万事大吉，结局团队累趴了，客户等急了，项目烂尾了。 实际上不需求那种高大上的架构图。好办的表要么白板就能搞定。
比如那个“需求分析”，不用列那么多条目，只写三个关键点就行：用户想要啥、能不能改、改不改。开发一看就知道大约方向，产品经理一看就知道风险在哪。
要是再纠结哪一条要写进图里，那图做得再好也没用。 再讲讲“测试”环节。图上写明白“回归测试”，可执行起来全是扯皮。测试人员说：“只有上线前做。”运维说：“不然上线了再补。”双方都不按图执行，结局上线那天，功能全崩，客户投诉连连。 这时候，那些“难免”、“必然”、“绝对”这种词就特别扎眼。
比如“难免出现闲置”，现实中未必。
比如“必然搞定”，可能一辈子不搞定。项目管理这东西，核心就是搞清楚哪位该干啥、啥时候干、干成啥样。图只是工具，不是真理。 故此别总想着把图做得多复杂。
哪怕就是那张白纸，上面画个“启动”和“终止”两个粗线条，下面写个“项目启动”和“项目终止”四个词，那才是真本事。真本事在于让人看懂图，理解流程，就连能顺着图自己干活。别整那些虚头巴脑的术语堆砌，项目还在路上，别把路堵上了。