在武大做软件项目管理，实际上跟在学校里学《管理学原理》要么《软件工程》课时彻底不一样。
那会儿老师讲得云山雾罩，你听完只认定“理论忒抽象，彻底用不上”。但真正到了实战，特别是像那些牛人，他们早就把这套理论揉碎了，塞进了具体的业务场景里。 你常听人说写需求文档时要“思维导图”，他们肯定都懂，但这跟画一张图有啥区别？我见过一个做电商系统的测试经理，为了落实测试范围，直接在产品需求里画了一堆箭头和圆圈。结局产品经理嫌他画得乱七八糟，根本没法干。他实际上是把需求中的各个功能点串成了一条逻辑链，但没给产品经理一个明确的“验收标准”。
那一堆箭头和圆圈，在客户眼里可能看不出重点，但在测试人员眼里，这才是最清楚的验收路径。
有时候，产品经理画流程图，实际上就是画“逻辑”，他可能连“输入啥”、“如何判断”都没想清楚，直接甩给测试。测试经理得自己多花点工夫，把输入输出、判断逻辑一个个拆解清楚，就连能画出略微好办点的真图，这时候测试人员就能安心干活了。 还有那种“里程碑”的概念，听起来高大上，做起来全是坑。别以為到了项目汇报会就能直接甩出几个大名词，比如“项目启动”、“里程碑”、“阶段评审”。
这些词在 PPT 上看着顺眼，实际业务流程里是啥样子？大量时候，一个大项目从头到尾就没有清楚的分界点。你可能刚开完启动会，三个月后没难题；到了半年，进度拖了三个月也没人管；这时候你再找客户谈，客户也说不清形成了啥。
这时候所谓的“里程碑”就失效了，出于根本没东西可衡量。 实际上，武大学的那些管理理论，大量时候都是为了解决那些“如何跟老板解释为啥延期”的烂摊子。
比如项目中期评估，老板问你如何看，你不能只说“进度滞后”，得说“核心功能开发受阻，严重影响了功能定义与接口设计的协调”。
这时候，你需求回顾之前的文档，看看是出于需求变更忒频繁，还是出于技术团队没跟上。
要是是出于需求变了，那目前的进度落后就是必然的；要是是出于技术没跟上，那就要反思之前的盘算是不是忒理想化。 我曾经带过两个项目，一个是传统的金融系统改造，另一个是纯业务的互联网小程序。结局彻底是两码事。金融系统改造，客户那边简直不配合，需求文档改了又改，接口文档也是重写。
这时候项目经理最头疼的往往不是技术难点，而是如何跟客户反复要解释。而那个互联网小程序，别看前期沟通也费劲，但一旦核心功能定下来，配合度就高多了。项目执行阶段，大家就知道该低头干活了，这时候哪位还在纠结“为啥延期”，哪位还在纠结“需求为啥改”，哪位就不会认定“原来需求管理如此快就变如此难了”。 关于进度管理，也别总想着做甘特图。项目延期了，甘特图再漂亮也没用。大量项目经理喜爱每天盯着进度条看，认定一发现没按盘算就是黄了。
实际上，进度就是由一系列瓶颈事件串联起来的。
比如需求不准、接口不匹配、技术选型跑偏，这些一个个卡住，项目就会往后推。 记得我做过一个项目，客户贼主观，啥“务必上线”、“务必下周”都没提。结局一个月那会儿了，进度表上全是“开发中”、“测试中”，连个“阻塞”都没有。
这时候项目经理只能去问客户：“您到底想要啥？
是不是在等一个标准？还是说您认定所有功能都能够先砍一半上线？”客户说：“不是，务必全有。”结局呢？接口不匹配，需求确认反复涂改，测试人员想测也测不出来。
这时候，项目进度表上的“阻塞”项就出来了，但没人管。
这时候项目经理得想办法，要么拆分任务，要么转变盘算，要么接纳客户不可控的现实。 换个角度想，项目管理的本质，实际上是下降不确定性。客户的不确定性、业务的不确定性、技术的不确定性，这些都挺难彻底消除。但我们能够通过流程、文档、沟通把这些不确定性降下来。
比如每次需求变更，都有个正式的签字确认流程；技术上线前，有个代码审查和联调的环节。
这些流程别看繁琐，但能避免后面出现“出了故障才发现是设计难题”这种尴尬。 实际上，武大教的大量管理理论，核心往往不是那些复杂的模型，而是“沟通”和“文档”。文档不是为了好看而写，是为了让不同岗位的人能理解彼此的意图。一份好的需求文档，是给开发看，还是给老板看？要是为了老板看，那就写成话术，技术要求直接砍掉；要是为了开发看，那就写得详细，接口要写清楚。
这种灵活度，大量传统的管理方式都做不到。 还有那个“小步快跑”的概念。目前大量公司喜爱拼大项目，Big Bang，结局最终堆出来的东西全是半成品。
实际上，技术能够迭代的，但需求不能。还不如在一个大项目里死磕一个复杂的功能，不如拆分成几个小功能，每个功能都做到极致，然后再迭代。
这样就算某个功能不好，也只会影响一个模块，不至于让整个系统瘫痪。 有时候，项目延期是出于团队内部的协作难题。
比如开发认定测试工作量不够，测试认定开发进度慢了。
这时候项目经理得去调停，不能只说“大家多沟通”，得具体到“开发这边能不能把接口文档提前发出来”要么“测试这边能不能并行一些非关键代码的测试”。 最终，别总想着把难题解决得完美无缺。项目管理是为了交付价值，不是为了证明你是一个完美的管理机器。
有时候，接纳“需求没改完”、“技术有瓶颈”、“客户想额外加功能”，本身就是一种智慧。能接纳这些，说明你心里有数，知道边界在哪。 故此，回归武大管理的核心，就是别忒迷信那些高大上的模型，多关切具体的业务场景，多想想如何把不清楚的需求变清楚，如何把复杂的技术变可控，如何跟客户和团队沟通得更顺畅。
只要流程跑通了，文档写到位了，哪怕项目延期，只要核心功能能上线，这就叫成功。