项目管理 on 方糖猫Blog

《人月神话》笔记：Brooks 用 OS/360 的学费换来的软件工程第一性原理

Tue, 08 Aug 2023 10:40:00 +0800

《人月神话》笔记：Brooks 用 OS/360 的学费换来的软件工程第一性原理

目标读者：带过项目、估过排期、经历过"老板说加人就能赶上"的工程师和工程管理者。参考书籍：Frederick P. Brooks Jr.《人月神话》（The Mythical Man-Month，1975 年初版，1995 年 20 周年纪念版），含 1986 年论文《没有银弹》（No Silver Bullet）。阅读目标：不是复述一本 50 年前的书，而是把 Brooks 用 IBM OS/360 项目的巨额学费换来的几条"软件工程第一性原理"蒸馏成今天还能直接用的判断准则。

一、焦油坑：这本书从哪里长出来的

书的第一章叫「焦油坑」（The Tar Pit），Brooks 用了一个古生物学意象：拉布雷亚沥青坑里，猛犸、剑齿虎、恐龙——越是强壮的野兽，挣扎得越猛烈，陷得越深。大型系统编程就是这样一个焦油坑：没有哪支队伍特别笨，但大家都在里面挣扎，而且越挣扎陷得越深。

这句话不是文学修辞，是作者的身份声明。Brooks 是 IBM System/360 大型机项目的经理，随后又是其操作系统 OS/360 的项目经理——这是 1960 年代人类历史上最大的软件项目之一，几千人年、超支数倍、进度失控、bug 成山。1964 年 IBM 老板小沃森问他项目为什么管成这样，他答不上来；几个月后他离开 IBM 去北卡大学建计算机系，把这次失败翻来覆去想了十年，1975 年写出这本书。

所以读这本书的正确姿势是：这不是一个管理学教授在总结别人的案例，是一个搞砸过史上最大软件项目的人在写尸检报告。 书里每一条论断背后，都是 OS/360 真金白银的教训。这也是为什么这本书快 50 年了还不过时——硬件换了五代，语言换了几轮，但"人怎么组织起来写大软件"这个问题的底层结构，几乎没变。

全书论点可以用一句话串起来：

软件项目的失败，绝大多数不是技术失败，而是对"编程这项活动的本质"估计错误的失败——错估了沟通成本、错估了复杂度的来源、错估了设计与实现的相对价值。

二、人月神话：人月是不可互换的

书名即论点。人月（man-month）——用人乘以月来度量工作量——是一个神话，因为它暗含一个错误前提：人和月可以互换。 10 个人干 1 个月，和 1 个人干 10 个月，不是一回事。

Brooks 的论证是一个漂亮的分类学，按任务的可分解性拆开：

完全可分解、无需沟通的任务：比如收麦子、筛数据。这类任务人月确实可互换，人加倍时间减半。可惜软件里几乎没有这种任务。
可分解但需要沟通的任务：大部分编码工作属于此类。增加人手，沟通成本随之而来，收益开始打折。
可分解但需要复杂沟通与再培训的任务：沟通成本开始吞噬新增人手带来的产能。
完全不可分解、有严格次序依赖的任务：比如调试（本质上是顺序的），比如生孩子——九个月，几个母亲也压缩不了。软件里的系统设计和集成调试大量属于此类。

flowchart TD
    T["软件任务"] --> Q{"能否分解为<br/>无需沟通的子任务?"}
    Q -->|"能(极少: 收麦子型)"| A["人月近似可互换<br/>人加倍, 工期减半"]
    Q -->|"不能(绝大多数)"| Q2{"主要成本是什么?"}
    Q2 -->|"沟通与协调"| B["加人收益递减<br/>沟通路径数 = n乘n减1再除2"]
    Q2 -->|"严格次序依赖<br/>设计、调试、集成"| C["加人完全无效<br/>九个月生不出孩子"]
    style C fill:#ffcccc
    style A fill:#e8f5e9

沟通成本那条值得算一笔小账：n 个人两两沟通，路径数是 n(n-1)/2。3 个人是 3 条，7 个人是 21 条，10 个人是 45 条。人数翻倍，沟通路径数大约翻两番。 如果每次协作都要开会、对齐、等回复，人越多，每个人写代码的时间占比越低。这就是为什么 Brooks 说"用人月作为度量，等于默认了一个只在收麦子时成立的假设"。

这条原理的一个直接推论，常常被忽略：进度落后的项目，往往不是人太少，而是人太多——沟通结构已经把产能吃掉了，这时候减人反而可能提速。

三、Brooks 定律：向延期的项目加人，只会让它更晚

这是全书最出名的一句话，1975 年提出，后来被叫成 Brooks 定律（Brooks’s Law）：

Adding manpower to a late software project makes it later.（向一个已经延期的软件项目增加人手，只会让它更晚。）

为什么"加人赶工"这个管理者最直觉的动作是错的？Brooks 拆了三层成本：

培训成本：新人不能立刻干活。他们要先学项目的目标、架构、既有代码、开发流程——而教他们的人，正是团队里本来在干活的老手。老手的时间被培训占用，团队短期产能不升反降。
沟通成本：就是上一节的 n(n-1)/2。加人后，任务要重新划分、接口要重新对齐，原本两个人口头约定的事，现在要写文档、开会。
任务重划分成本：很多任务被打断重拆时，边界上的工作要重做；有些任务根本拆不动（次序依赖的部分），能拆出去的部分往往是最不需要人的部分。

flowchart LR
    subgraph 加人前
        A1["团队产能 100%<br/>全部用于推进项目"]
    end
    subgraph 加人后短期
        B1["老手产能下降<br/>抽时间培训新人"] --> B3["净产能低于加人前"]
        B2["新人产能为负<br/>提问、犯错、需要返工"] --> B3
        B4["沟通路径数平方增长<br/>对齐成本吞噬产出"] --> B3
    end
    subgraph 加人后长期
        C1["若项目不取消<br/>数月后产能才可能恢复<br/>但死线已过"]
    end
    A1 -.->|"管理者直觉: 产能应线性上升"| B1
    B3 --> C1
    style B3 fill:#ffcccc

书里还有一个配套观察，杀伤力同样大：项目是怎样延期一年的？一天一天延的。（How does a project get to be a year late? One day at a time.）大灾难不是突然降临的，是每天落后一点点、每次例会都"下周能追上"累积出来的。所以 Brooks 主张里程碑必须具体、锋利、公开——“编码完成 90%“不是里程碑，是遮羞布；“模块通过全部单元测试并合入主库"才是。

对今天的映射几乎不用翻译：每个 deadline 前两周"借调支援"的场景，都是 Brooks 定律的现场重演。正确的动作恰恰相反——砍掉 20% 的范围，比增加 20% 的人有效得多。

四、概念完整性与外科手术队伍

4.1 最重要的系统属性不是功能，是概念完整性

Brooks 认为，一个系统给用户呈现的东西里，概念完整性（conceptual integrity）是最重要的品质——系统各处必须体现同一套设计哲学，一致、连贯、正交。用户学透三个概念就能推测出三十个行为的系统，远好过每个功能都自说自话的系统。

但概念完整性有一个组织上的代价：它无法由委员会设计出来。 民主设计出来的系统，是每个聪明人都塞进了自己最爱的特性的系统——功能很多，灵魂没有。所以 Brooks 给了一个政治不正确但极其诚实的结论：

概念完整性要求设计出自一个人，或极少数同心同德的人。为了完整性，必须接受贵族专制（aristocracy），放弃民主。

这不等于独裁者包揽一切。Brooks 的关键区分是：体系结构（architecture）与实现（implementation）分离。架构师定义"系统对用户是什么样”——接口、语义、概念模型；大量实现者在架构约束下尽情发挥创造力。OS/360 的教训是：架构师也必须克制，架构文档里不该规定任何"实现细节”，否则就是把实现者的创造力抢走、把架构变成瓶颈。

Unix 是这条原则最著名的正面样本（Brooks 自己也拿它举例）：一切皆文件、程序是过滤器、文本流为接口——概念少到极致，组合力大到极致。

4.2 外科手术队伍：小团队怎么做大事

如果人少才有一致性，人少又怎么完成大项目？Brooks 的回答是全书我最喜欢的组织设计：外科手术队伍（surgical team）——不是"人人都是全才"的平等团队，而是像一台外科手术那样，一个主刀，其余所有人都是为了让主刀的每一分钟都高效而存在。

10 人编制大致是：

外科医生（首席程序员）：亲手定义功能与性能规格，亲手写核心代码，对系统负全责。
副手（copilot）：能替代外科医生做任何事，是他的讨论对象、保险丝和备份，但不抢方向盘。
管理员：处理钱、人、场地、设备这些非技术事务——外科医生不该为报销分心。
编辑/秘书：外科医生口述或手写，编辑负责把文档变成清晰、统一、可发布的正式文档。
程序职员：维护所有代码版本、运行记录、测试数据——机器时间时代的"版本与构建管家”。
工具师：为团队打造专用工具、脚本、测试设施。
测试员：根据规格写测试用例，并且从规格里找矛盾——他是架构师的第一批批评者。
语言专家：精通语言犄角旮旯的顾问，帮团队写出既优雅又高效的代码。

flowchart TD
    S["外科医生 首席程序员<br/>设计 + 核心代码 + 负全责"]
    C["副手<br/>讨论对象与备份"]
    AD["管理员<br/>钱、人、设备"]
    ED["编辑<br/>文档产出与统一"]
    CL["程序职员<br/>版本与运行记录"]
    TL["工具师<br/>内部工具与设施"]
    TE["测试员<br/>用例设计与规格挑刺"]
    LX["语言专家<br/>语言技艺顾问"]
    C --> S
    AD --> S
    ED --> S
    CL --> S
    TL --> S
    TE --> S
    LX --> S
    style S fill:#fff3cd

注意这个结构的颠覆点：其他人不是外科医生的下属执行者，而是他的支撑系统。 今天回头看，这是"10x 工程师团队"最早的严肃版本——结论不是"找 10 个 10x"，而是"让那个 10x 的人 100% 的时间都在做只有他能做的事"。大项目怎么办？分成若干段，每段一个外科手术队伍，段与段之间用架构对齐——又回到概念完整性。

五、第二系统效应：你最危险的作品是第二个

全书最精妙的心理学洞察之一：第二系统效应（second-system effect）。

一个人在设计他的第二个系统时，会把它做成最危险的系统——因为他会把第一个系统里没用上的所有想法，全都塞进去。

机制是这样的：设计第一个系统时，人是谨慎的、不自信的，处处收敛；那些"如果再来一次我一定要加"的念头，被一条条记在心里的清单上。设计第二个系统时，自信来了，约束松了，那张清单被整体倒出来——加上第一版遗留功能的修饰欲，结果是功能膨胀、概念混杂、复杂度失控。

Brooks 的自白是：OS/360 就是大量设计者的"第二系统"（多数人的第一系统是 1410、7090 系列），所以它的链接器、它的各种设施，都堆满了"这次终于可以做了"的东西。而他给架构师的建议只有一句：为每个功能问一句"它值它占用的那份复杂度预算吗"；并且始终意识到自己在设计第几个系统——第三个系统的设计师，往往才第一次有真正的克制能力。

工程映射：每个"重写 2.0"项目都是第二系统效应的高危现场。旧系统的痛点清单天然会被翻译成新系统的功能清单，而旧系统"为什么不支持 X"的答案（往往是成本，不是疏忽）在重写时被遗忘。重写立项评审时，把"砍掉的功能清单"和"新增的功能清单"摆在一起看，能救命。

六、计划抛弃原型：第一个版本注定要扔

原话极不客气：

Plan to throw one away; you will, anyhow.（计划抛弃一个吧；反正你一定会抛弃的。）

意思是：你做的第一个版本，无论多用心，都是"试验品"——只有做完它，你才真正理解需求、理解约束、理解用户真正要什么。管理层如果不"计划"抛弃它，它就会被当作产品硬撑下去，背着一个为学习而生的架构进入维护地狱。

这句话常被误读为"随便写一版就行"。Brooks 的本意严格得多：抛弃是计划内的，所以要为"抛弃"设计——原型和生产系统用不同的人力配比、不同的质量预期、不同的心态；原型的使命是最大化学习，不是最大化寿命。后来的演进还有一条：唯一比"计划抛弃"更贵的，是假装不用抛弃。

这条思想后来开枝散叶：快速原型、MVP、以及 Brooks 自己在《没有银弹》里提出的增量式构建（grow, not build）——软件不该是"建造"出来的，该是"生长"出来的：先让一个能跑的最小骨架活着，然后每加一个功能都保持系统可运行。1995 年纪念版里他承认，当年"抛弃一个"的说法被他自己修正为更平滑的增量演化，但内核没变：不要指望第一枪就命中，把迭代当成常态写进计划。

七、文档与工作手册：被遗忘的主角

这本书有个今天读来格外超前的观点：项目经理最重要的日常工作是文档，不是代码。 Brooks 花了整整一章讲「项目工作手册」（project workbook）：

它是什么：项目所有正式文档的集合——目标、规格、进度、接口定义、会议纪要、变更记录。它不是档案柜，是项目的活的中枢。
为什么必须有：第一，写作强制清晰——“写在纸上的决策，模糊性会自己暴露”，很多争吵在落成文字那一刻就解决了；第二，文档是沟通结构的载体，几百人的项目里，工作手册是唯一能让"每个人看到同一本事实"的装置。
怎么维护：所有变更都要进手册，手册必须人人可得、持续更新（OS/360 时代用缩微胶片分发，他特意讨论了每日更新机制——放今天就是 wiki/文档站）。

配套还有一条 OS/360 的组织创新：让文档成为规格的唯一权威形态。架构师写正式的外部规格说明，实现中出现歧义时，由架构师裁决并把裁决写回规格——规格永远是最新事实，不是"最初的美好愿望"。

今天的映射一目了然：ADR（架构决策记录）、design doc 评审、“接口以文档为准而非以聊天为准”，全是工作手册的现代转世。Brooks 在 1975 年就说清楚了我们 2020 年代还在学的事：异步的、成文的沟通，是大团队唯一可扩展的沟通。

八、没有银弹：本质复杂度与偶然复杂度

1986 年，Brooks 发表了那篇比书本身更著名的论文：「没有银弹——软件工程中本质与偶然的问题」（No Silver Bullet: Essence and Accidents of Software Engineering），1995 年纪念版收入书中。

核心论断：没有任何一项技术或管理进步，能在十年内让软件生产率提高一个数量级。 因为软件的困难要分两类：

本质复杂度（essential）：问题域本身固有的复杂度——概念结构必须精确、一致、完整；软件是"纯粹的思想制品"，它的复杂度不会因为换工具而消失。就像银弹能杀狼人，但软件工程里没有狼人——没有一个叫"技术"的妖怪一枪打死就天下太平。
偶然复杂度（accidental）：我们制造过程附带的复杂度——机器慢、语言啰嗦、工具难用、环境配置地狱。这部分是可以消灭的，而且历史上已经消灭了大部分：高级语言干掉了汇编的偶然复杂度，分时系统干掉了批处理的排队等待，统一硬件平台干掉了移植地狱。

Brooks 的关键预测逻辑是：到 1986 年，偶然复杂度已经被压缩到不是主要矛盾了——剩下的硬骨头几乎全是本质复杂度，而本质复杂度不响应任何"银弹"。

那怎么办？论文给出了四条"有希望的铜弹"，条条在后来兑现：

买，别造（buy vs. build）：能买现成软件就别自己写——自己写的那部分才承载本质复杂度。
需求精炼与快速原型：最难的本质问题是"搞清楚到底要造什么"，用原型和用户一起把需求逼出来。
增量式生长（grow, not build）：系统永远保持可运行，小步叠加。
培养伟大的设计师：软件生产率的最大方差来自人——顶尖设计师和普通设计师的差距是数量级的，把培养设计师当成组织的核心投资。

1986 年之后的四十年基本在给这篇论文做注脚：面向对象、组件化、开源生态、云、低代码，每一波都消灭了新的偶然复杂度，每一波之后项目照样的难——因为难的那部分从来不在工具里，在"我们要造的东西本身"里。

九、20 周年纪念版：Brooks 的自我检讨

1995 年纪念版最珍贵的部分，是 Brooks 回头看自己二十年前的论断，一条条打分：

仍然坚信的：概念完整性是系统最重要的品质；人月不可互换；加人让延期项目更晚；工作手册必不可少；第二系统效应真实存在。
修正的：「计划抛弃一个」太粗暴，更准确的表述是增量演化（grow）；结构化编程、面向对象属于消灭偶然复杂度，不是银弹——这点他赌对了。
认错的：他当年推崇"信息隐藏到团队之间也互相保密"的做法，后来承认过度了——Parnas 的信息隐藏原则适用于模块接口，不该用来隔离团队之间的知识。
被时代证明最对的：对"伟大设计师"的押注。20 年后他更确信：软件质量的天花板由少数顶尖设计者决定，组织的头等大事是发现他们、培养他们、别用流程磨平他们。

这种"作者亲自给旧书做 code review"的结构，本身就是对全书精神的践行：把二十年前的决策放到今天的光下重新评审，而不是假装当年的自己永远正确。

十、落地实践：我自己在用的四条

这本书不是读完就完的，我把其中几条固化成了自己带项目时的检查动作：

报排期时先分类任务。任何估算之前，先问"这块工作能不能无沟通地并行拆开"。拆不动的部分（联调、设计、疑难 bug），单独列出来按顺序排，并且明确告诉需求方：这部分加人不解决问题，加人只会更慢。把 Brooks 定律提前说出来，比延期之后再解释有效得多。
里程碑只写"可验证的事"。排期表里禁止出现"开发完成 80%“这类状态词，全部换成"接口联调通过"“性能压测达标"这种第三方可验证的硬节点。项目是一天一天延期的，锋利的里程碑是让"每天的小落后"无处藏身。
重写项目先审"砍掉清单”。任何重构、2.0 立项，评审材料里必须有两栏：新系统不做什么、为什么不做。没有砍掉清单的重写方案，默认是第二系统效应发作，打回。
护住团队里的"外科医生”。识别出那个承担核心设计的人，然后系统性地替他挡事：杂会替他推掉、文档有人帮他整理、工具不顺有人帮他修。他的每一分钟专注时间，就是整个团队的产能上限。

四条背后其实是同一个原则，也是这本书教我的最重要的一件事：软件工程里大多数"管理动作"的反面才是对的——加人不如减人，催进度不如砍范围，民主设计不如贵族专制，憋大招不如小步生长。 Brooks 在五十年前就把这些"反直觉"写成了定理，我们要做的只是别再交一遍学费。

十一、带走的清单

如果只能记住几件事，记这些：

人月不可互换。报工期前先问：这个任务属于"收麦子型"还是"生孩子型"？后者加人无用。
Brooks 定律：延期的项目加人只会更晚。赶工的正确动作是砍范围、保核心，不是借调支援。
里程碑要锋利：“完成 90%“不是进度，是幻觉；只有"可验证、不可含糊"的节点才是进度。
概念完整性＞功能数量。架构出自一人或极少数人；架构师管"系统是什么样”，实现者管"怎么造出来”。
警惕第二系统效应：重写立项时，先审"砍掉清单"，再审"新增清单"。
计划抛弃原型：第一版的使命是学习；要么计划抛弃它，要么被它拖死。
文档是项目的中枢：写下来，模糊会自己暴露；规格是唯一权威，裁决要写回规格。
没有银弹：工具的进步只消灭偶然复杂度；本质复杂度只能靠更好的需求（原型）、更好的生长方式（增量）、更好的人（设计师）来对付。
投资顶尖设计师：人员方差是软件生产率里最大的方差，这件事 1975 年成立，今天更成立。

参考资料

Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley, 1995（含《没有银弹》全文及作者 20 年回顾）。
Frederick P. Brooks Jr., “No Silver Bullet: Essence and Accidents of Software Engineering”, Computer, 1987（1986 年原始论文）。
Frederick P. Brooks Jr., The Design of Design, Addison-Wesley, 2010（Brooks 晚年对"设计"本身的系统思考，可视作本书续篇）。

PMP 入门与实战：从项目经理角色认知到沟通方法

Wed, 09 Aug 2017 10:00:00 +0800

PMP 入门与实战：从项目经理角色认知到沟通方法

我在华为电软核担任项目经理，这是我给新人培训材料的总结。项目管理不是把活派出去就完事，而是在有限的时间、预算、资源约束下，带领团队把事儿做成。这篇文章结合 PMP 体系与一线交付经验，帮你用最快的速度建立 PM 的角色认知和实战感。

一、PM 不是高级打杂，而是项目的总导演

很多新人第一次做 PM 时会有错觉：PM 就是催进度、拉会议、写周报的“高级打杂”。但真正的 PM 是项目的总导演——你对最终交付结果负责，而不是只负责传话。

1.1 项目经理的四个角色

结合 PM 角色认知模型，项目经理要同时承担四个责任：

flowchart TB
    PM([项目经理 PM])
    D[项目按要求交付责任者]
    T[团队建设责任者]
    O[组织能力建设责任者]
    B[项目经营责任者]

    PM --> D
    PM --> T
    PM --> O
    PM --> B

    D --> D1[启动 / 计划 / 执行 / 监控 / 验收 / 关闭]
    T --> T1[核心团队运作 / 人员能力提升 / 组织氛围]
    O --> O1[流程方法 / 工具建设 / 过程资产积累]
    B --> B1[收入管理 / 成本控制 / 业务拓展]

简单记忆：

角色	关键词	日常表现
交付责任者	按期、按质、按预算	盯进度、管风险、控变更、搞验收
团队建设者	人心、能力、氛围	布阵点兵、辅导下属、解决冲突
组织能力建设者	流程、方法、资产	沉淀模板、优化流程、分享经验
经营责任者	赚钱、省钱、控成本	成本评估、收入确认、变更报价

1.2 从个人贡献者到团队绩效达成者

PM 是一次“转身”：以前你关注“我干得怎么样”，现在你要关注“我们团队干得怎么样”。

flowchart LR
    A[独立贡献者<br/>个人绩效] -->|转身| B[项目经理<br/>团队绩效]
    B --> C[关注事]
    B --> D[关注人]
    C --> C1[计划 / 进度 / 质量 / 风险]
    D --> D1[沟通 / 激励 / 培养 / 冲突]

新人自检三问：

我是谁？（我在这个项目里的核心职责是什么）
我的优势劣势？（我擅长技术、沟通还是流程）
我的工作方式？（我习惯先发制人还是被动响应）

二、PMP 核心原理：五大过程组

PMP 把项目管理抽象成 49 个过程，归入 5 大过程组 和 10 大知识领域。新人不用背 49 个过程，先理解 5 大过程组的逻辑。

2.1 五大过程组循环

flowchart LR
    A[启动<br/>Initiating] --> B[规划<br/>Planning]
    B --> C[执行<br/>Executing]
    C --> D[监控<br/>Monitoring & Controlling]
    D --> E[收尾<br/>Closing]
    D --> B
    D --> C
    E --> A

    style A fill:#e0f2fe
    style B fill:#dcfce7
    style C fill:#fef9c3
    style D fill:#fee2e2
    style E fill:#f3e8ff

过程组	核心问题	关键输出
启动	为什么要做？值不值得做？	项目章程、干系人登记册
规划	怎么做？谁来做？什么时候做完？	项目管理计划、WBS、进度基准、成本基准
执行	按计划推进，协调资源与人	可交付成果、变更请求
监控	偏差多少？要不要纠偏？	工作绩效报告、变更请求、纠正措施
收尾	做完了吗？经验留下了吗？	验收报告、经验教训、项目关闭

注意：五大过程组不是严格的“阶段”，它们会重叠、反复、交叉。比如监控贯穿始终，规划也可能在执行中重新发生。

2.2 十大知识领域一句话版

flowchart TB
    subgraph KA[十大知识领域]
        direction LR
        A1[整合管理] --> A2[范围管理]
        A2 --> A3[进度管理]
        A3 --> A4[成本管理]
        A4 --> A5[质量管理]
        A5 --> A6[资源管理]
        A6 --> A7[沟通管理]
        A7 --> A8[风险管理]
        A8 --> A9[采购管理]
        A9 --> A10[干系人管理]
    end

知识领域	核心问题	新人重点
整合管理	怎么把零散的事串成整体？	写计划、做变更、开阶段评审
范围管理	到底做什么？不做什么？	WBS、需求澄清、范围变更控制
进度管理	什么时候做完？	里程碑、甘特图、关键路径
成本管理	要花多少钱？能不能省？	估算、预算、挣值分析
质量管理	做成什么样才算好？	验收标准、测试计划、质量回溯
资源管理	需要谁？怎么激励？	团队组建、责任分配矩阵 RAM
沟通管理	跟谁说什么？怎么说？	沟通计划、例会、周报、话术
风险管理	什么可能搞砸？怎么应对？	风险登记册、应急预案
采购管理	哪些东西要外购？	SOW、合同、供应商管理
干系人管理	谁在意这个项目？怎么管理期望？	干系人登记册、参与策略

三、项目铁三角与新六边形

3.1 传统铁三角

flowchart LR
    A[范围 Scope] --- B[进度 Schedule]
    B --- C[成本 Cost]
    C --- A

3.2 PMP 更完整的六边形制约

现代项目管理认为，项目受多个因素共同制约：

flowchart TB
    Q[质量 Quality]
    S[范围 Scope]
    C[成本 Cost]
    T[进度 Time/Schedule]
    R[风险 Risk]
    RE[资源 Resources]

    Q --- S
    S --- C
    C --- T
    T --- R
    R --- RE
    RE --- Q

新人最常踩的坑：客户说“加个小功能，不影响进度和成本”。你要意识到：范围变了，进度、成本、质量、风险几乎都会变，只是影响大小不同。PM 的职责是把这些影响量化出来，让决策者做知情选择。

四、项目规划：把大目标拆成可执行的小任务

规划阶段是 PM 最需要下功夫的阶段。规划不好，执行再努力也白搭。

4.1 计划分级：不同人看不同粒度

级别	名称	用途	读者
0 级	里程碑计划	只显示关键节点	公司管理层、项目集经理
1 级	职能领域计划	各职能主要工作	项目经理、核心团队
2 级	专项详细计划	开发/测试/采购等展开	模块负责人
3 级	个人执行计划	任务到天/人	项目成员

4.2 WBS：工作分解结构

WBS 是项目规划的骨架。核心原则：

100% 原则：所有项目工作都要被分解，不能遗漏。
4-6 层原则：一般 4 层左右，别超过 6 层。
80 工时原则：最底层任务一般不超过 80 小时（约 2 周）。
滚动式规划：近期详细，远期粗略。
干系人参与：让相关人一起拆，不要 PM 一个人拍脑袋。

flowchart TD
    A[OTT 平台交付项目] --> B[需求与设计]
    A --> C[平台部署]
    A --> D[终端开发]
    A --> E[内容对接]
    A --> F[测试验收]
    A --> G[项目关闭]

    B --> B1[需求澄清会]
    B --> B2[方案设计]
    B --> B3[SOW 确认]

    C --> C1[云资源开通]
    C --> C2[流媒体部署]
    C --> C3[CDN 配置]

    D --> D1[Android STB]
    D --> D2[iOS Mobile]
    D --> D3[SmartTV]
    D --> D4[PC Web]

    E --> E1[直播源接入]
    E --> E2[VOD 内容上传]
    E --> E3[DRM 对接]

    F --> F1[E2E 测试]
    F --> F2[客户验收]
    F --> F3[问题整改]

    G --> G1[交付件归档]
    G --> G2[转维培训]
    G --> G3[项目总结]

4.3 甘特图、里程碑、燃尽图

甘特图：横轴时间，纵轴任务，直观显示“谁什么时候做什么”。
里程碑：项目中的关键节点，通常零工期，用来标志阶段完成。
燃尽图：敏捷项目常用，显示剩余工作量随时间下降的趋势。

gantt
    title 示例：OTT 项目关键里程碑
    dateFormat  YYYY-MM-DD
    section 启动与规划
    项目启动会           :a1, 2015-08-01, 7d
    SOW 确认             :milestone, after a1, 0d
    详细计划基线         :milestone, 2015-08-15, 0d
    section 执行
    平台部署             :2015-08-16, 14d
    终端开发             :2015-08-20, 20d
    内容对接             :2015-09-01, 10d
    section 验收
    E2E 测试             :2015-09-11, 10d
    客户验收             :milestone, 2015-09-25, 0d
    项目关闭             :2015-09-26, 5d

五、项目执行与监控：PDCA 循环

执行与监控不是“盯人”，而是计划 → 实施 → 反馈 → 调整的循环。

flowchart TD
    P[Plan 计划] --> D[Do 执行]
    D --> C[Check 检查]
    C --> A[Act 调整]
    A --> P

    P -.->|基线| M[范围/进度/成本基准]
    C -.->|度量| D1[进度偏差<br/>成本偏差<br/>质量指标]
    A -.->|措施| D2[纠正 / 预防 / 缺陷补救]

监控阶段 PM 要回答的三个问题：

我们现在在哪？（实际进度、成本、质量）
我们离计划多远？（偏差）
我们要怎么做？（纠正措施、变更、上报）

六、沟通管理：PM 70% 时间都在沟通

PMP 认为沟通管理是项目成败的关键。PM 不是传声筒，而是信息的过滤器、翻译器和加速器。

6.1 沟通管理四步法

flowchart LR
    A[识别干系人] --> B[制定沟通计划]
    B --> C[执行沟通]
    C --> D[问题闭环]
    D --> A

6.2 干系人识别与分类

干系人就是对项目有影响或被项目影响的人。常见分类：

flowchart TB
    subgraph S[干系人四象限]
        direction LR
        A[高权力<br/>高利益] --- B[高权力<br/>低利益]
        C[低权力<br/>高利益] --- D[低权力<br/>低利益]
    end

    A --> A1[重点管理<br/>客户老板 / 项目发起人]
    B --> B1[令其满意<br/>职能部门领导]
    C --> C1[随时告知<br/>终端用户 / 运营人员]
    D --> D1[花最小精力监督<br/>外围支持人员]

6.3 沟通方式选择

场景	推荐方式	原因
复杂问题、有冲突	面对面 / 视频会议	能看到表情、即时反馈
需要留痕、正式确认	邮件 / 会议纪要	可追溯、可签字
日常进度同步	即时消息 / 日报	快速、轻量
跨部门协调	项目例会 / RACI 表	明确责任、统一节奏

6.4 高频沟通话术模板

场景 1：需求不明确，需要客户确认

“王总，关于 XX 功能，目前我们理解有两种实现方式：方案 A 是……，优点是……，缺点是……；方案 B 是……，优点是……，缺点是……。从项目范围和时间来看，我建议采用方案 A，您看是否可以确认？如果选 B，可能需要增加 3 天并调整后续测试计划。”

要点：给选项、讲影响、让客户做选择题而不是开放题。

场景 2：进度Delay，需要同步客户

“李经理，想和您同步一个情况：受第三方接口延迟影响，模块 X 预计比原计划晚 2 天。我们已经采取了以下措施：1. 协调对方优先级；2. 并行启动模块 Y 测试；3. 准备临时方案。目前整体里程碑仍可控，我们会每天同步进展。这是详细的影响评估，您看是否需要召开专项会议？”

要点：先说事实、再说影响、最后给措施和选项。

场景 3：客户提出范围变更

“张总，这个需求我们收到了。我先记录下来，明天下午 5 点前给您一份变更影响评估，包括：对进度、成本、质量、风险的影响，以及推荐方案。评估完成后我们再一起决策是否纳入本期交付。”

要点：不直接拒绝也不直接答应，用“评估 → 决策 → 实施”的流程争取时间。

场景 4：团队内部冲突

“你们两边的顾虑我都理解了：开发担心改动引发回归，测试希望尽早覆盖边界。我们的共同目标是按期高质量交付。这样，我们先用 15 分钟把边界场景列出来，评估改动范围，如果可控就本周内完成；如果范围大，就走变更流程。现在我们一起写一下场景清单。”

要点：点出共同目标、把冲突转化为任务、给明确截止时间。

场景 5：推动不愿配合的职能部门

“刘经理，这个任务在咱们项目计划里是模块 X 的前置依赖，目前距离截止时间还有 3 天。如果这边不能按期提供，会导致下游 5 个人停工，整体里程碑风险会上升到高。您看能否协调资源优先处理？如果需要我向上汇报协调，我也可以同步项目发起人。”

要点：讲清楚依赖关系、量化影响、给对方台阶也保留升级路径。

七、变更管理：拥抱变化，拒绝侥幸

变更是项目常态，但 PM 不能当“传话筒”，必须建立变更控制机制。

7.1 变更管理五步流程

flowchart TD
    A[变更识别] --> B[变更澄清]
    B --> C[变更分析]
    C --> D[变更决策]
    D --> E[变更实施与跟踪]
    E --> F[基线更新]

    A -->|任何人提出| A1[记录变更请求]
    B -->|聚焦价值| B1[明确变更内容和原因]
    C -->|四原则三标准| C1[范围/进度/成本/质量影响]
    D -->|CCB/客户| D1[批准/拒绝/暂缓]
    E -->|责任人| E1[执行并验证]

变更分析四原则：影响范围、进度、成本、质量都要评估。

变更决策三标准：必须做？值得做？现在做？

7.2 变更管理话术

阶段	话术
识别	“收到，我先记录为变更请求 CR-001，稍后统一评估。”
澄清	“为了准确评估，能否确认一下：这个功能的使用场景是什么？必须在哪个版本上线？”
分析	“这个变更会影响 3 个模块，预计增加 5 人天，测试周期延长 2 天，风险等级为中。”
决策	“基于影响评估，建议本期不做，放到二期；如果必须做，需要追加预算并调整验收时间。”
实施	“变更已批准，这是更新后的计划和责任人，请大家按新基线执行。”

八、风险管理：提前把坏事想清楚

风险不是等问题发生了再处理，而是提前识别、评估、应对、监控。

8.1 风险管理四步法

flowchart LR
    A[风险识别] --> B[风险评估]
    B --> C[风险应对]
    C --> D[风险监控]
    D --> A

    A -.->|工具| A1[头脑风暴 / 检查表 / 经验教训]
    B -.->|维度| B1[概率 × 影响]<br/>高/中/低
    C -.->|策略| C1[规避 / 转移 / 减轻 / 接受]
    D -.->|动作| D1[跟踪 / 更新 / 触发应急]

8.2 风险应对策略

策略	含义	例子
规避	不做或换方式，彻底消除风险	不用未经验证的新技术
转移	把风险后果转给第三方	买保险、签固定总价合同
减轻	降低概率或影响	增加测试、提前采购关键设备
接受	不采取措施，准备应急储备	预留缓冲时间或预算

8.3 风险登记册模板

风险 ID	风险描述	概率	影响	等级	应对措施	责任人	状态
R01	第三方接口延迟	中	高	高	提前 2 周启动对接，准备 mock	张三	跟踪
R02	核心人员离职	低	高	中	建立备份机制，文档化	李四	跟踪
R03	客户需求频繁变更	高	中	高	固化 SOW，严格变更流程	PM	跟踪

8.4 风险沟通话术

“我们在风险评审中发现，第三方 DRM 对接存在延期可能。当前概率评估为中等，但一旦发生会影响整个验收。我们的应对措施是：本周内完成技术预研，并准备一套降级方案。责任人是我，下次周会同步进展。”

九、项目验收与关闭

项目不是上线就结束了，验收和关闭同样重要。

9.1 验收流程

flowchart TD
    A[完成全部交付件] --> B[配置审核]
    B --> C[入口条件审核]
    C --> D[提交验收申请]
    D --> E[客户组建验收组]
    E --> F[正式验收测试]
    F --> G{是否通过?}
    G -->|是| H[签署验收报告]
    G -->|否| I[问题整改]
    I --> F
    H --> J[项目关闭 / 转维]

9.2 验收前 PM 自检清单

合同 / SOW 约定的交付件是否全部完成？
测试报告、用户手册、运维文档是否归档？
已知缺陷是否有客户书面确认？
验收申请是否正式发出？
验收标准和测试用例是否与客户对齐？

9.3 项目关闭三件套

验收报告：客户签字，确认交付完成。
经验教训：好的坏的都记下来，下次不再踩坑。
转维交接：让运维/运营团队能接手。

十、案例复盘：为什么 A项目能成，Transvision项目不行

10.1 A项目：成功交付的关键

范围清晰：直播/DVR/catchup + 付费/预付费模式 + launcher/广告/getsapp。
计划可控：首期 3 个月 12 天，二期 3 个月，节奏稳定。
沟通及时：与客户保持良好及时的沟通。
风险质量进度都管住了：最终客户满意度高，用户增长迅速。

启示：项目成功 = 清晰范围 + 可控计划 + 有效沟通 + 风险管理。

10.2 Transvision项目：为什么不可交付

需求边界不清：全终端、双 DRM、多支付、广告、CP Dashboard、用户割接、时移、ABR……堆在一起。
成本无法核算：套餐定价与 XXX公司成本核算难以达成明确结论。
商业可行性存疑：POC 持续近一年，成本约 5000 美金，最终被拒。

启示：PM 要敢于在早期说“这个项目不可交付”——不是消极，而是对组织负责。项目经营责任者的角色要求 PM 评估商业可行性，而不仅是执行。

十一、给 PM 新人的三条成长建议

1. 先建立“流程感”，再追求“灵活性”

新人常犯的错误是觉得流程麻烦、想快速跳过。但流程是保护你的：变更流程保护你不被客户随意改需求，风险流程保护你不被突发问题打懵。先把流程跑熟，再谈灵活裁剪。

2. 把“人”当成项目最重要的风险

进度延期、需求变更、技术问题，归根到底都是人的问题。PM 70% 的时间要花在沟通上：对齐期望、解决冲突、激励团队、管理客户。

3. 练习“结构化表达”

PM 的话术不是油滑，而是结构化：

结论先行
给数据和事实
讲影响和选项
明确下一步和责任人

十二、总结：一张图看懂 PM 的核心工作

flowchart TB
    A[项目目标] --> B[范围管理]
    B --> C[WBS 分解]
    C --> D[进度/成本/质量计划]
    D --> E[执行 + 监控]
    E --> F[沟通 / 风险 / 变更]
    F --> G{验收通过?}
    G -->|是| H[项目关闭]
    G -->|否| I[整改 / 变更]
    I --> E

    style A fill:#e0f2fe
    style H fill:#dcfce7
    style I fill:#fee2e2

PM 的核心能力可以概括为三句话：

把事情做对：理解需求、拆清范围、管好进度成本质量。
把人对齐：识别干系人、制定沟通策略、化解冲突。
把风险控住：提前识别、量化影响、准备预案。

如果你刚转 PM，别急着背 49 个过程。先把这篇文章里的角色认知、五大过程组、WBS、沟通、变更、风险管理跑起来，你就已经比大多数新人走得更稳了。

参考：本文部分内容结合《XXX PM 角色认知》培训材料与 PMBOK 第七版/第六版项目管理知识体系整理，融入一线 OTT 项目交付经验。

项目管理 on 方糖猫Blog

《人月神话》笔记：Brooks 用 OS/360 的学费换来的软件工程第一性原理

《人月神话》笔记：Brooks 用 OS/360 的学费换来的软件工程第一性原理

一、焦油坑：这本书从哪里长出来的

二、人月神话：人月是不可互换的

三、Brooks 定律：向延期的项目加人，只会让它更晚

四、概念完整性与外科手术队伍

4.1 最重要的系统属性不是功能，是概念完整性

4.2 外科手术队伍：小团队怎么做大事

五、第二系统效应：你最危险的作品是第二个

六、计划抛弃原型：第一个版本注定要扔

七、文档与工作手册：被遗忘的主角

八、没有银弹：本质复杂度与偶然复杂度

九、20 周年纪念版：Brooks 的自我检讨

十、落地实践：我自己在用的四条

十一、带走的清单

参考资料

PMP 入门与实战：从项目经理角色认知到沟通方法

PMP 入门与实战：从项目经理角色认知到沟通方法

一、PM 不是高级打杂，而是项目的总导演

1.1 项目经理的四个角色

1.2 从个人贡献者到团队绩效达成者

二、PMP 核心原理：五大过程组

2.1 五大过程组循环

2.2 十大知识领域一句话版

三、项目铁三角与新六边形

3.1 传统铁三角

3.2 PMP 更完整的六边形制约

四、项目规划：把大目标拆成可执行的小任务

4.1 计划分级：不同人看不同粒度

4.2 WBS：工作分解结构

4.3 甘特图、里程碑、燃尽图

五、项目执行与监控：PDCA 循环

六、沟通管理：PM 70% 时间都在沟通

6.1 沟通管理四步法

6.2 干系人识别与分类

6.3 沟通方式选择

6.4 高频沟通话术模板

场景 1：需求不明确，需要客户确认

场景 2：进度Delay，需要同步客户

场景 3：客户提出范围变更

场景 4：团队内部冲突

场景 5：推动不愿配合的职能部门

七、变更管理：拥抱变化，拒绝侥幸

7.1 变更管理五步流程

7.2 变更管理话术

八、风险管理：提前把坏事想清楚

8.1 风险管理四步法

8.2 风险应对策略

8.3 风险登记册模板

8.4 风险沟通话术

九、项目验收与关闭

9.1 验收流程

9.2 验收前 PM 自检清单

9.3 项目关闭三件套

十、案例复盘：为什么 A项目 能成，Transvision项目 不行

10.1 A项目：成功交付的关键

10.2 Transvision项目：为什么不可交付

十一、给 PM 新人的三条成长建议

1. 先建立“流程感”，再追求“灵活性”

2. 把“人”当成项目最重要的风险

3. 练习“结构化表达”

十二、总结：一张图看懂 PM 的核心工作

十、案例复盘：为什么 A项目能成，Transvision项目不行