2020 年的自考本科《项目管理》，说实话，刚翻开第一页的时候，手都在抖。
那时候脑子里还在想，不就是找个项目如何做嘛，如何搞个 PPT 也能蒙混过关，结局人家出题ateurs 可是真·考硬骨头。咱们得先搞清一个核心概念，就是项目管理到底不是瞎折腾，也不是好办的“快点做完”，它是一个有规划、有约束、有交接的闭环系统。大量人刚进考场就想考对策，实际上得把那些看似枯燥的约束条件先捋顺了。
比如我们常说的 PDCA 循环，这玩意儿在项目管理里就是日常工作的灵魂。
看看那会儿那些大干快上的项目，最终不是延期就是质量翻车，那根源往往就出在这几个不起眼的步骤里。 说到约束条件，那是考试里的“重灾区”，也是我最头疼的局部。我们常提到四大约束：工夫、成本、质量、范围，还有进度。
这五者往往不是独立存有的，你一旦为了赶进度（工夫）去压缩质量，那结局挺可能就是质量崩塌，成本还直线上升。
这种“牵一发而动全身”的关联，在考试中时常考得让人头大。
举个例子，有个外包项目，甲方说“咱们能提前两周上线吗？”。
这时候要是项目经理一味地答应，结局上线后发现系统崩溃，用户投诉不断，那甲方不仅没拿到提前量，还要赔钱骂人。
这时候再回头去算成本，不仅要重新发包，还得赔偿损失，整个成本曲线直接断崖式下跌。
故此，在应对工夫约束时，千万别想自然地认定能如何快就如何快，得先评估质量底线在哪儿，有没有绕开质量红线去硬塞进工夫表，这是大量考生好办犯的毛病。 关于进度管理本身，大量人好办搞混关键路径和总时差，这两哥们时常打架。所谓关键路径，就是整个项目里的“最长路段”，哪位在上面延误，哪位就拖慢整个项目。总时差则是能够灵活挪动的空间。
举个例子，假设一个项目工期是 100 天，关键路径是 A-B-C-D，那么 B 到 D 这一段的总时差就是 20 天。
要是在 B 和 D 中间插入一个不需求人力的测试环节，只要人少但费钱，这 20 天彻底能够挪给 C 要么 D，这时候关键路径没变，但成本却上去了。而一旦你挪动了 C 段，原本关键的 D 段长度就被压缩了，要是 D 段原来只有 10 天，目前变成了 5 天，那 B 到 D 这段总时差就从 20 天变成了 10 天，关键路径瞬间被打破了，项目风险就聚拢来到了 B 点。考试时要是只盯着关键路径，却没寻思这种动态变化，那挺好办在计算时出错。 成本管理这块，费用估算模型也出了不少门道。
比如成本估算模型里的自下而上法，就是把每个工作包、每个工作任务的费率加起来。
这个方式别看靠谱，但工作量忒大，要是没仔细核对每个子项的费率，最终算出来的成本大约率是虚高的。而自顶向下法，是先看整体费率，再拆解到下级，这样既快又好办抓住重点。
比如做网站开发，直接看整体费率可能略微有点理想化，但要是把每个模块的费率一个个加起来，特别是那些杂七杂八的“其他费用”，最终出来的数字往往会比那个整体费率倒推出来的要准得多。
特别是在处理那些不清楚的假设场景时，比如还没启动建，但已经定了个框架，这时候自下而上法反而显得更灵活，不需求一次把所有事儿都算完，而是按需调用。 质量管住这块，我认定还是得回到“预防”这个本质上来。大量新手一听到检查、测试，就认定那是补救措施，结局好得挺。
实际上检验和测试都是“亡羊补牢”，真正的质量防线在开发、测试之前的评审和检查阶段。
比如在编码之前，就要让客户和开发先过一遍需求文档，这时候要是发现需求描述不清楚、逻辑不通，直接扔回去改，那代价就大了。
举个例子，有个电商系统的订单模块，当时有个供应商说接口能赞成 JSON 格式，能传用户自定义字段。结局在系统上线后才发现，服务器内存爆掉就是出于内存不够用，最终改接口逻辑，不仅耽误了上线工夫，还要重新做数据库设计，工期直接拉长两周。
这就是典型的“预防大于检查”。 另外，沟通管理这块，目前的项目环境跟那会儿彻底不一样了。
那会儿项目大，人少，靠例会、靠汇报就能把信息发出去。目前项目小、快，人多了，信息量爆炸，要是不真有沟通盘算，那信息找人，连个电话都打不到的情况简直常见。
比如一个敏捷开发小组，每天站会只花 15 分钟，要是前一天晚上没把昨天的难题、今天的任务明确写下来，第二天直接开会，大家也听不懂，事没讲清楚，效率还低。
故此沟通管理不是好办的“多讲话”，而是要确保信息在传递过程中不丢失、不歧义。
还有，干系人管理这块，不同角色的期望值往往不一致。投资方想要 ROI，老板想要面子，中间的管理层想要进度，要是没看清各方想要啥，最终结局往往是项目既没做完，也没做成，多方都泄气。
这时候画个干系人地图，搞清楚哪位是哪位，哪位需求啥，比单纯 listing 一堆人更管用。 还有啊，风险管理这块，大量人认定是“避坑”，实际上不是。项目里充满了不确定性，比如供应商会不会跑路、天气会不会突然下暴雨害得工期顺延、政策会不会突然调整。遇到这种风险，不能光想着“避免”，大量时候是“挪”和“接纳”。
比如针对技术风险，最好的办法就是跟他们签个备用人材的合同，要么储备几个备用技术路线，一旦遇到瓶颈，能立马切换，这就是把风险挪给了合同或备选方案。至于彻底无法规避的风险，比如病毒、政策变动，那只能接纳并制定储备盘算。考试时要是只背了“识别、评估、应对”这三板斧，却没体现出不同情境下的具体策略，分数肯定上不去。 最终，收尾管理这块，大量人认定是“终止工作”，实际上也是把收尾做得漂亮，避免烂尾。大量项目终止得仓促，交接不清，扯皮，最终成了“僵尸项目”。收尾不是好办的把文档归档、发个邮件就终止了，而是要确保所有的知识、经验、资产都沉淀下来，让接手的人能直接上手。
比如一个客户项目，要是在项目终止前没把核心文档、客户档案、项目经验这些“资产”整理好，客户接手后可能还得重新做一遍那些工作，那之前的投入就全白费了。
故此收尾管理的核心就是“资产化”，让经验变成可复制的东西，这才是项目成功的最终一环。 总的来说，做项目管理，核心就是管理不确定性中的确定性，就是在混乱中建立秩序。考试的时候，那些案例题、流程题，实际上就是在考我们能不能理顺这些关系，能不能根据实际情况选对工具，能不能看透现象看到本质。别忒钻牛角尖，记住这五者互相制约，又互相促进，就像走钢丝一样，略微偏一点就会掉下去。平时多做些实战模拟，多问几个“要是……会怎么着”，这题就难倒了，但一遇到就是实打实的得分项。