> 口播：同学们好，欢迎大家来到《软件项目管理》的课堂。先做个自我介绍，我是这门课的老师，周宇文，我的电话和微信是 13580390715——课程上有任何问题，随时找我，不用客气。 > 我们这门课的课程代码是 154431006，32 学时、2 学分，配套教材是宋莹莹老师等编写的《软件项目管理与实践》第 3 版，清华大学出版社 2025 年版。 > 今天这一节课，我不急着让大家背定义。我先给大家讲一个真实的项目故事——一家中国企业被"卡脖子"之后，用五年时间，把一个操作系统从"追赶"做到了"超越"。听完这个故事，你就明白一件事：写代码只是开始，能不能在有限的时间、有限的人和有限的钱里把它交出来，靠的是"管理"。 > 大家可以先看一眼屏幕上的这张封面图。今天这门课要回答的，就是封面底下这句话的问题：当芯片与系统被"卡脖子"，一个操作系统如何在五年里完成从追赶到超越？——这就是一个真实的软件项目，而它，需要被"管理"。

> 口播：大家看屏幕上这张目录，今天 90 分钟，我们只做四件事，我把顺序念一遍，你心里就有谱了。 > 第一件，案例导入：华为鸿蒙 OS。我们先用一个真实的大项目开场，你带着"它是怎么被管住的"这个问题去听，然后再学管理术语。顺序不能颠倒——先见真事，再学名词。 > 第二件，1.1 项目与软件项目。我们要搞清楚三个问题：什么是"项目"？项目有哪五大特征？软件项目又比一般项目特殊在哪里？学完这一节，你自己就能判断"这件事到底算不算项目"。 > 第三件，1.2 软件项目管理。这一节的三个问题特别扎心：为什么有那么多项目会失败？失败通常栽在哪九个坑里？反过来，说一个项目"成功"，到底看哪五个维度？还有两个每年都考、也最容易考糊的概念——组织过程资产和事业环境因素。 > 第四件，1.3 价值驱动的软件项目管理知识体系。这一节是整个学期的"地图"：生命周期、五大过程组、十大知识领域、八大绩效域。今天你把这四个词的位置记对了，后面十五章你就不会迷路。 > 屏幕上还有一行学习目标，我念一遍：能说出项目和软件项目的特征；能解释成败维度与环境；能读懂"生命周期—过程组—知识域—绩效域"这个框架；认识 PMP 和软考。就这四条，今天下课你要能自己复述出来。 > 可能有同学会问：老师，这四件事跟"写代码"有什么关系？我打个比方——盖一栋楼，工人砌砖的手艺固然重要，但决定这栋楼能不能按期交房、会不会超预算、住进去会不会漏水的，是图纸、工期和监理。软件项目也一样：编码能力决定你能做出东西，而项目管理的四件事——判断做什么、盯住成败、看清环境、按框架推进——决定你做出来的东西能不能被别人用上、被组织认可。所以这门课不是"技术课的附属品"，它是把技术变成成果的那道工序。

> 口播：先把"游戏规则"讲清楚，这样大家才知道劲儿该往哪儿使。我按屏幕这张表一条一条讲。 > 第一，学时学分。总共 32 学时、2 学分，全部是理论学时，多媒体讲授，没有单独的实验课时。排课是 16 周，每周一次课、每次 2 学时。期末考试安排在第 18 周，全校统一，120 分钟，闭卷。 > 第二，考核办法，这个大家一定要记准：平时成绩占 30%，其中作业占 20%、课堂讨论和练习占 10%；期末闭卷占 70%。题型是选择、填空、判断、简答和案例分析。 > 我要特别提醒一句：案例分析和计算题是拿分的大头，也是真正拉开差距的地方。选择填空靠背能对付，案例分析靠的是你会不会用概念去分析一个真实情境——所以今天讲鸿蒙这个案例，不是在讲故事，那是在给你示范"案例分析该怎么答"。 > 第三，课程地图。我们这门课一共 11 章：第 1 章概述，也就是今天；第 2 章讲项目启动；然后是采购、范围、进度、成本、质量、资源、干系人与沟通、风险；第 16 周做整合串讲加综合案例复习。大家可以发现，第 3 到第 10 章，基本上是"一个知识领域一章"。 > 那么这门课的逻辑，我用一句话给大家收口：先学会"想清楚"——范围、进度、成本；再学会"管住它"——质量、资源、风险、沟通。"想清楚"是把事情定义对，"管住它"是把事情做到底，这两件事缺一不可。 > 另外还有一件事：教材里配了 8 个单元实验，是课外自主实践、选做、不计学时学分；我们还有一个课外综合小组项目，3 到 6 人一组，也是选做。综合项目分三个阶段：第 2 到 3 周交 M1——项目章程和干系人登记册；第 9 到 13 周交 M2——计划；第 15 到 16 周交 M3——收尾与价值确认。本周课后请大家先确认分组和选题意向。

> 口播：先不看书，也不要去翻定义，完全凭你的直觉判断。屏幕上有四件事，请你判断：哪些是"项目"？ > A．为双 11 大促开发一个"临时优惠系统"，11 月 12 日下线。 > B．学校机房的日常运维与值班。 > C．开发并上线一套"超市智能库存管理系统"。 > D．部门每周例会。 > 注意，这是一道多选题，可以有多个答案。给大家 30 秒，同座位之间可以先小声商量一下，然后我请两三位同学来说，并且要说出你的理由——光说 A 是项目不算回答，你得告诉我"凭什么"。 > 我先把话说在前面：今天这一页我不公布答案。为什么？因为等我讲完 1.13 页"项目的五大特征"，你自己就能判了。我要的不是你猜对，而是你拥有一把"尺子"。到那时候我们再回到这一页，你会发现判断标准清清楚楚。 > 这里顺便说一句学这门课的方法：先有直觉，再被纠正，最后形成标准。你们现在凭直觉作答，我一会儿讲特征的时候，会有人突然"啊，我答错了"——这个"啊"的瞬间，才是真正记住的时候。所以不要怕答错，怕的是不动脑。请大家现在就把自己的答案写在笔记本上，三十分钟后我们对答案，看谁猜对了。

> 口播：现在进入今天的案例部分。请大家把书翻到第 1 章开篇案例，也看一下屏幕上的这一页——"先看一个真实的大项目，再学管理术语"，这十个字就是我们接下来 12 分钟的方法。 > 案例的主角是华为鸿蒙 OS。背景我一句话交代：2019 年，华为被列入实体清单，安卓系统的授权受限。一家年出货量以亿计的终端厂商，突然被"断了一条腿"。问题来了：华为是怎么把一个操作系统项目做成功的？ > 我要提醒大家：这个案例不是虚构的推演故事，它是教材第 1 章的开篇案例，案例背景、三阶段推进、投入数据和市场结果都出自教材原文，我们引用时如实讲。所以待会儿我讲的每一个数字、每一个决策，你都可以当成一个真实的"管理动作"来学。 > 带着这个问题，我们开始今天的学习。

> 口播：我们先看风暴是怎么来的。2019 年，美国将华为列入实体清单，限制其使用安卓系统。请注意"实体清单"这三个字——它不是一次技术故障，也不是一次商业竞争，它是外部监管环境的一次突变的政策变化。华为的智能设备业务因此遭遇巨大冲击，海外市场一度被迫"按暂停键"。 > 再看华为当时的处境。作为全球领先的智能终端厂商，它的年出货量以亿计——这是个什么概念？大家可以想象一下：一辆正在高速公路上以一百二十码飞驰的车，突然被告知"你的方向盘不给你用了"。安卓授权受限，用案例页的原话说，就是"如同断了一条腿"。 > 那华为是怎么回应的？它没有屈服，也没有停在原地抱怨，而是迅速启动鸿蒙 OS 研发项目。请注意这里的目标设定——目标不止"活下去"，而是自主可控。这两个层级差别极大："活下去"是防守，"自主可控"是进攻；"活下去"是保命，"自主可控"是要把命脉握在自己手里。 > 案例页把这个项目的性质总结成三条：第一，立项动因——研发自主可控的操作系统，解决"卡脖子"问题；第二，更高目标——不止是替代安卓，而是构建覆盖多终端全场景的智慧生态；第三，战略性质——它是"技术突破×战略转型"，说白了，这不只是"写代码"，这是"建生态"。 > 最后看结果：据教材案例数据，鸿蒙 OS 在中国智能移动设备市场的份额已经超越 iOS，成为第二大移动操作系统。

> 口播：一个大项目最怕什么？最怕"一口吃成胖子"。你想想，如果 2019 年华为宣布"我们要在两年内做出一个全面超越安卓的全场景操作系统"，这个目标本身就会压垮整个团队——因为它没法排期、没法分配人手、没法验收。 > 华为的做法是把它切成三个阶段，我们一个一个看： > 第一阶段，优先适配现有硬件，确保业务连续性——说白了就是"先活下来、稳市场"。先把系统跑在现有设备上，让用户和业务不中断，先守住基本盘。这一步的战略意义是：不追求一步到位，先解决"有没有"的问题。 > 第二阶段，拓展到智能家居与工业应用——这是"生态向外扩"。手机只是第一个战场，智能家居、工业设备是更大的战场。这一步解决的是"广不广"的问题。 > 第三阶段，实现跨设备无缝连接，打造全场景生态——这一步才是终极形态，解决的是"好不好、通不通"的问题。 > 大家注意这三个阶段的排序逻辑：不是按技术难度排的，而是按"风险从大到小、收益从近到远"排的。先做最稳妥、最能救命的事，再做最有想象力的事。 > 我再补一个关键的观察：三个阶段之间是有"承接关系"的，不是三件事并排放。第一阶段把系统跑在现有硬件上，才积累了用户和开发者；有了用户和开发者，第二阶段往智能家居、工业应用扩才有底气；等设备足够多、场景足够广，第三阶段做"跨设备无缝连接"才有意义。如果跳着做，就像还没学会走路就想跑——技术上也许能做出来，但市场上没人陪你玩。 > 案例页给出的管理启示是：分步推进＝在有限时间内高效完成任务，同时降低技术与市场风险。这句话请大家划下来，它其实就是我们后面要学的"渐进明细"和"滚动式规划"的雏形。"渐进明细"是说：计划不是一次做完的，是随着信息增加逐步细化的；"滚动式规划"是说：近期的事排详细计划，远期的事只排粗线条，等走近了再细化。华为的三阶段，就是这个思路的一次真实演练。

> 口播：面对"技术复杂＋时间紧迫"的双重挑战，案例里总结了四大策略，我们逐条看，而且每一条我都告诉大家它对应管理上的哪个道理。 > 策略一，技术路线多样化，加快速迭代，不押注单一方案。这条最值得学。大家可以这样理解：如果你只有一条技术路线，而这条路走不通，那整个项目就归零了；但如果你同时准备两条路线，任何一条通了，项目就活了。这不是浪费，这是用一点冗余换掉"全盘归零"的风险。生活里也一样——高考填志愿，你不会只填一个学校，你会冲一冲、稳一稳、保一保，这就是"路线多样化"。 > 策略二，微内核架构加开源技术，降低开发难度。微内核的好处是核心小而稳定，其他功能以模块方式加上去，改一块不容易动全身；开源则是"站在前人的肩膀上"，不用什么都从零写。这是一个很务实的取舍：时间不够的时候，能用现成的就不重复造轮子。 > 策略三，分阶段交付核心功能，实现快速上线。这一条和上一页的三阶段是配套的：不追求一次交付一个完美版本，而是先交付一个能用的版本，让用户先用起来、先有反馈。 > 策略四，联合软硬件厂商与开发者，提供工具、资金、技术指导，降低生态门槛。这一条是在解决"生态从哪来"的问题。你想让别人给你的系统写应用，光喊口号不行，你得给工具、给钱、给技术支持，把别人进来的成本降下来。用今天的话说，这叫干系人整合——把外部伙伴变成项目的一部分。 > 再看投入的底数，屏幕上写了：数万名研发工程师、数千亿元资金、上万家合作伙伴，还有百名开发者生态协作。组织保障是：公司资源整合、高效跨部门协作、高层战略支持。 > 我要请大家都记住最后这六个字——"高层战略支持"。为什么？因为等到我们讲"失败九大原因"的时候，你会发现"缺乏高层支持"赫然在列。一个项目有没有最高层的资源、决策和关注度，往往是生死的分水岭。

> 口播：好，案例的事实部分讲完了。现在我们做两个思考题，请大家同桌两人一组，讨论 1 分钟，然后我请一位同学来回答。请注意，回答的时候尽量用刚才我们讲过的词——"分阶段""技术路线""生态""高层支持"，这样你的答案才是"管理语言"，而不是"读后感"。 > Q1：面对技术变化和市场风险，华为采用了哪些有效的项目管理策略，确保了鸿蒙 OS 项目的成功？ > Q2：在软件项目管理中，如何有效确保项目按计划推进并达到既定目标？ > 这两问有区别：Q1 是"看别人做对了什么"，是总结；Q2 是"如果换成你，你要怎么做"，是方法。 > （讨论 1 分钟，请 1 位同学回答，教师归纳。） > 参考答案要点是这样的。Q1 一共五条：① 三阶段分步推进，加"分阶段交付核心功能"——这是为了降低风险；② 技术路线多样化，加快速迭代；③ 微内核架构加开源技术，降低开发难度；④ 生态联合，给工具、给资金、给技术指导，也就是干系人整合；⑤ 高投入，加高层支持。 > Q2 的要点是四个动作，请大家记牢：计划 → 执行监控 → 变更控制 → 绩效度量。这四步就是我们这门课要学的整个知识体系的主干——你看，一个真实案例，已经把全书的目录给我们演示了一遍。 > 我们把这四步简单翻译一下，你就知道后面十几周在学什么了："计划"，就是把目标拆成里程碑、排出谁在什么时候做什么，对应第 4 到第 6 章的范围、进度、成本；"执行监控"，就是边干边对照计划看有没有跑偏，对应过程组里的执行与监控；"变更控制"，就是有人要改需求、改方案的时候，不是拍脑袋就改，而是走一个评估—批准—记录—通知的流程，对应整合管理；"绩效度量"，就是用数据回答"我们到底做得怎么样"，而不是靠感觉，对应质量、度量绩效域。 > 我想强调最后一个词：绩效度量。很多项目不是突然失败的，是一直感觉"还好"、直到最后才发现来不及。度量就是那盏仪表盘上的灯——它不会替你把车开好，但没有它，你连油快没了都不知道。

> 口播：项目管理不到位，再大的公司也会翻车。屏幕上是三个教科书级别的失败案例，我们一个一个拆，而且我要讲透它们错在哪一个管理动作上。 > 第一个，IBM 的 OS/360。这是 1960 年代的一个操作系统项目。它的教训是：规模被严重低估——进度拖期、预算超支。这个项目最有价值的产出，不是那个操作系统，而是总工程师布鲁克斯写的一本书，叫《人月神话》。书里有一句被引用了几十年的话："向进度落后的项目加人，只会更落后。"大家注意这句话背后的道理：一个已经延期的项目，你往里加人，新人要熟悉代码、要沟通、要开会，沟通成本按人数平方增长，结果反而更慢。所以"加人＝加速"是一个直觉陷阱。 > 第二个，微软的 Windows Vista。它曾被称作"史上最大软件项目之一"。问题出在哪？Longhorn 计划中途废弃——也就是技术方案推到一半推倒重来；再加上功能蔓延（需求不断加，越做越大）和安全架构大改造，最终造成约 5 年延期；发布之后兼容性差、口碑崩盘。这个案例的教训是：需求不受控地膨胀，会把一个"能成"的项目拖成"难产"——这正是我们后面范围管理要解决的问题。 > 第三个，苹果的 Newton 和 Lisa。Newton 押注手写识别太早，当时的识别率和体验撑不住，用户用两次就放弃了；Lisa 定位超前，但定价接近一万美元，卖不动。两个项目都是商业失败。一句话总结：技术先进 ≠ 市场买单。一个项目的价值，最终要由市场和用户来确认，而不是由内部的"技术领先"来确认。 > 现在把这些失败案例和鸿蒙对照一下。鸿蒙赢在哪？案例页给了四个对照点：分阶段交付、技术路线多样化、生态联合、高层支持。你会发现，这四条恰好就是前面那些失败案例踩过的坑——IBM 踩了"进度失控"，Vista 踩了"需求失控"，苹果踩了"市场判断与用户体验"，而鸿蒙用管理动作把这些坑一个一个绕过去了。这就是项目管理方法的价值：它不是让你更聪明，它是让你不犯那些已知的错。

> 口播：我们进入第一部分的正式内容——1.1 项目与软件项目。这一节我们走三步：第一步，先给"项目"下一个定义，然后抠出它的五大特征；第二步，看软件项目比一般项目特殊在哪里；第三步，我们回头把开头那道破冰题判掉，那时候你就有一把尺子了。 > 请大家把书翻到 1.1 节，今天这一节是全书的起点——因为如果你连"什么是项目"都定义不清楚，后面的范围、进度、成本，全都无从谈起。 > 我再多说一句：这一节看似最"软"、最像语文课，其实它决定你后面所有的判断力。比如你以后带团队，老板问"这个需求我们要不要接"，你要能说清楚"它是不是一个项目、它有没有终点、它要占用多少资源"；这些判断的底层，就是这一节的两个定义和八条特征。所以不要因为它是名词解释就轻看它。

> 口播：我们先给"项目"下一个定义，请大家把它记在笔记本上——项目，是为创造独特的产品、服务或成果而进行的临时性工作。 > 这句话只有二十几个字，但里面藏了三个关键词，我们一个一个抠。 > 第一个词是"独特"。独特的意思是：这件事以前没做过，或者做的做法和以前不一样。你每天中午去食堂吃饭，这件事独特吗？不独特，因为它天天一样。但如果学校让你开发一个"食堂排队预测系统"，这就独特了——因为以前没有。 > 第二个词是"临时"。临时意味着有明确的开始，也有明确的结束。它不是常年都在干的活。项目一定会"结束"，哪怕结束的方式是失败、是取消，它也是"结束"。 > 第三个词是"工作"，而且要投入资源——人、时间、钱。空想不叫项目，落到实处的投入才叫项目。 > 那什么不是项目？ 日常运营。屏幕上这张表把两者并排放在一起，我们一起读：从目标看，项目是"创造独特成果，完成后解散"，运营是"维持业务运转，持续重复"；从时间看，项目"有明确开始与结束"，运营是"持续进行"；从例子看，项目是"开发鸿蒙 OS、上线库存系统"，运营是"机房运维、每周例会"。用一句话区分：运营是"让机器继续转"，项目是"把机器换一台新的"。 > 举个身边的例子：机房每天有人值班、每周巡检——这是运营；而把机房整体搬迁、顺带做一次系统升级——这是项目。再比如：超市每天开门营业是运营；开发一套智能库存系统，是项目。 > 大家注意，这个区分不是文字游戏。运营用"流程和标准"管，项目用"计划和控制"管——因为项目有终点、有不确定性，所以必须有人专门盯着目标、进度和风险。这也是为什么会有"项目管理"这门学问。

> 口播：项目有五个显著特点，请大家边听边在书上标出来。屏幕上这张表我给大家逐行讲，而且每一行我都配了一个正面例子和一个反面例子——反面例子最重要，因为它告诉你"缺了这一条会怎样"。 > ① 目的性。项目有一个明确的目标或成果，所有活动围绕它展开。正面例子：鸿蒙 OS，目标很明确——一个自主可控的全场景操作系统。反面例子：漫无目的的"探索性开发"，说不清要交付什么成果。没有目标的团队，干得再辛苦也验收不了。 > ② 独特性。每个项目都是独一无二的：目标、需求、资源、环境各不相同。正面例子：为某家银行定制结算系统，方案仅此一份。反面例子：套同一个模板批量做同质网站，没有独特成果——那更像流水线作业。 > ③ 临时性。有明确的开始与结束，目标完成即结束。正面例子：双十一促销系统，按时上线、11 月 12 日按计划下线。反面例子：机房日常运维，长期持续、没有终点。请特别注意：临时性说的是"有终点"，不是说"时间短"。一个三年的项目，只要有终点，它就有临时性。 > ④ 资源约束性。项目是在预算、人力、时间等限制下运行的。正面例子：5 个人、3 个月、50 万预算，交付一套库存管理系统。反面例子："不设预算、不限工期慢慢做"——那更像兴趣，不像项目。 > ⑤ 不确定性。技术、需求、外部环境都会带来风险。正面例子：新算法的效果未知，所以先做原型验证、再分阶段交付。反面例子：需求完全明确、技术完全成熟、过程中毫无变化——那就不需要风险管理了。反过来说，正因为项目有不确定性，项目管理才有存在的必要。 > 现在给大家一个记忆钩子，屏幕上也写了：目 · 独 · 临 · 约 · 不——「目的独特、临时有约、充满不确定」。判断口诀是：有没有明确目标？是不是一次性的独特成果？有没有资源限制和风险？这三问全是"是"，它才像个项目。 > 好，现在我们回到开头那道破冰题。A、为双十一开发临时优惠系统，限时上线、限时下线——有终点、有独特成果、有资源约束，是项目。B、机房日常运维与值班——持续重复、没有终点，是运营。C、开发并上线超市智能库存管理系统——目标明确、一次性完成，是项目。D、部门每周例会——例行重复，是运营。所以答案是：A 和 C 是项目；B 和 D 是运营。判断线索，就是我们刚刚讲的这五条特征。

> 口播：刚才讲了五大特征，我们马上做一道速判题，检验你的"尺子"利不利。题目是：下列哪一项不属于项目的特征？选项我念一遍——A．独特性；B．临时性；C．可重复性；D．目的性。 > 这是一个抢答题，我念完选项之后，给大家 10 秒，然后举手，不要喊。注意，这道题考的不是记性，考的是你有没有真正理解"项目"和"运营"的分界。 > （10 秒后点人回答。） > 好，答案是 C，可重复性。为什么？因为我们刚才讲得很清楚：项目是一次性、独特的，而"可重复"恰恰是日常运营的特征——机房每天巡检、例会每周都开，这才是可重复的。所以 C 不是项目的特征，它是运营的特征。 > 我再补两句很重要的辨析。第一句：要区分"项目的特征"和"项目管理的特征"。比如说"项目需要编制计划""项目需要控制风险"，这些是管理动作，不是项目本身的特征，考试很容易把这两类词混在一起当干扰项。第二句：要区分"临时性"和"周期长"。临时性说的是"有明确的终点"，不是"时间短"。一个为期三年的政务平台建设项目，哪怕周期很长，只要它有明确的开始和结束，它就有临时性。所以看到"周期长"不要本能地以为它就不是项目。

> 口播：先给软件项目下定义，请大家记下来：软件项目是为了开发、交付和维护符合特定需求与质量标准的软件产品或服务而进行的临时性工作。 > 请注意这个定义里有几个限定词："特定需求与质量标准"——意思是客户的验收标准写在前面；"开发、交付和维护"——说明它不是做完就走，还包括交付和维护；"临时性工作"——说明它继承了项目的全部性格。 > 也就是说，软件项目首先要满足我们刚讲的五大特征，在此之外，它还有三个"自己的特点"，屏幕上这张表逐行给大家讲。 > ① 渐进明晰性。含义是：需求和目标逐步明确，会随着用户反馈、技术发展和市场变化不断细化调整。正面例子：教务系统先按初步需求开发，试运行之后根据老师的反馈不断增加字段、调整流程。反面例子：把需求当成"一次说清、永不改变"——用户中途提一句"还要加个导出报表"，双方就起冲突，项目陷入扯皮。这一点非常重要：软件需求天然是"越做越清楚"的，所以管理方式必须留有余地。 > ② 学科复杂性。含义是：它涉及计算机科学、数学、工程学等多个学科，需要跨学科的知识整合。正面例子：银行结算系统＝软件工程师＋数据库和安全专家＋懂银行业务的人一起协作。反面例子：全组只会写业务代码，没人懂数据库、没人懂安全，上线之后并发崩溃、合规问题接连暴露。 > ③ 智力密集型。含义是：它主要依赖团队成员的智力和创意——分析、架构、编码、解决问题。正面例子：架构师针对"全校抢课系统"提出分布式缓存方案，靠的是分析权衡来解决高并发。反面例子：以为这行像流水线拧螺丝、谁都能顶岗；结果核心逻辑写错，测试怎么补都补不干净。 > 屏幕最下面那句话是本页的落点，我念一遍：特点决定了管理方式——需求会变，所以要管范围；专业杂，所以要组队；靠人脑，所以要激励与质量。一句话小结：软件项目的特殊性在于——需求会变、技术很杂、靠脑子吃饭。

> 口播：我们进入第二部分——1.2 软件项目管理。屏幕上是这一节的分区页，写了三个小标题：1.2.1 成败、1.2.2 项目内外部运行环境、1.2.3 职业证书认证。 > 也就是说，这一节回答三个问题：第一，项目管理管得好不好，怎么衡量？——看成功，也看失败。第二，项目是被什么环境包围的？——这就是那两个每年都考、最容易混的概念：组织过程资产和事业环境因素。第三，这个职业有没有"证书"这条路？——PMP 和软考。 > 三个问题，一个比一个实用：第一个建立"成败观"，第二个建立"环境观"，第三个建立"职业观"。请大家跟着这个顺序听。 > 为什么要把"成败"排在第一位？因为一个人对"什么算成功"的理解，会直接决定他后面所有的管理动作。如果你以为"按时交付就是成功"，你就会为了赶工期砍测试；如果你知道"价值实现才是最终指标"，你就会在项目一开始先问一句"这件事到底为谁创造什么价值"。所以顺序不能反，先立成败观，再学方法与工具。

> 口播：先给"软件项目管理"下定义，请大家记下来：软件项目管理，是确保软件项目在预定的成本、进度与质量要求内顺利完成，对整个软件开发过程进行规划、组织、协调和控制的管理活动。 > 这个定义里有两组关键词，屏幕上用两块卡片并排画出来了。 > 第一组是三条约束：成本——在预算内完成；进度——按时交付、不延误关键节点；质量——满足需求与标准，这是合格线。大家可以发现，这三条正是后面成本管理、进度管理、质量管理的三章内容，也是传统上说的"铁三角"。 > 第二组是四个动作：规划——定目标、排计划；组织——分任务、配资源；协调——同步信息、解决问题；控制——对照计划、发现并纠正偏差。这四个动作请大家特别记住"控制"："控制"不是"管人"，而是"对照计划找偏差"——先有计划，才有偏差，才有控制。 > 再看它的覆盖范围，从可行性分析、立项、需求管理、开发、测试、交付一直到维护——整条链子都在管理范围内，不是只管到上线为止。 > 我给一个身边的例子，就是你们的小组课程设计。进度＝截止日期；成本＝小组投入的精力；质量＝功能是否满足要求、体验是否达标；规划＝排计划；组织＝分工；协调＝例会同步；控制＝对照计划纠偏。你看，一个课程设计，其实把这套东西全跑了一遍。 > 本课程的主线也在这页：第 2 章讲"如何启动"，第 3 到第 10 章逐个展开各知识域，第 16 周整合与复习——顺着"三条约束＋四个动作"这条主线走，全书的结构就清楚了。 > 最后我要强调定义里最关键的一个词："确保"。软件项目管理不是"参与一下""帮个忙"，而是对结果负责——成本、进度、质量这三条线，得有人签字认领。这也是为什么项目管理岗位在招聘市场上一直被看重：技术岗位解决"能不能做出来"，项目管理岗位解决"能不能交出去"，而组织最终为后者付钱。

> 口播：屏幕上这个红色框里的数字，请大家看一眼。据课件引用的项目管理工具供应商 TeamStage 报告数据：全球 70% 的项目以失败告终，大中型跨部门项目的失败率更高。 > 70% 是什么概念？你掷一枚硬币，反面朝上是 50%；而项目失败的概率比掷硬币还高。这个数字听起来极端，但如果你做过小组项目，可能就不会太意外。 > 那"失败"具体长什么样子？屏幕列了三种典型表现：第一，错过截止日期、预算超支——就是又慢又贵；第二，可交付成果未达预期、客户不满意——就是东西交出来了，但不好用；第三，交付之后维护困难——就是上线只是灾难的开始，后面天天救火。 > 请注意第三种，它在学校里最容易被忽略。很多同学觉得"能跑起来就算完成"，但企业里恰恰相反——上线才是成本的大头，一个没人能维护的系统，等于给公司埋了一颗雷。 > 那么最关键的一句话来了，请大家一定记在心上：项目失败的原因，绝大多数不是技术不行，而是管理没做好。技术决定你能不能做出来，管理决定你能不能按时、按质、按预算交出来。这两句话，是整门课存在的理由。 > 我也给大家留一个小问题，屏幕上写着：你身边的课程项目、团队作业，有多少是"延期＋改需求＋凑合交付"？——如果有，那正好，这门课就是来解决它的。 > 顺便说一句：70% 这个数字不是用来吓人的，是用来提醒你"项目管理不是可选项"。很多人以为"管理"是项目经理一个人的事，但你们组队做课程设计的时候，如果没人排计划、没人盯进度、没人处理需求变更，那就是全班一起掉进那 70% 里。所以从这个角度看，这门课不是给未来的项目经理上的，是给每一个要交付成果的人上的。

> 口播：导致项目失败的深层次原因，教材归纳为九条。我们一条一条看，而且每一条我都配一个你们熟悉的场景。大家同时回想刚才那个问题——"你带的项目最怕哪三件事"，我们边讲边对照。 > ① 整合管理不足——目标、资源与进度无法衔接。说白了，就是"各干各的、拼不成一个整体"。比如前端在改接口，后端没收到通知，测试还在按老接口写用例。 > ② 目标和需求管理不当——目标模糊、范围混乱、需求频繁变更。这是最常见的死因：一开始说不清要做什么，做着做着又不断加需求。 > ③ 客户协作障碍——客户决策多变、协作不畅。注意"客户"不一定是外人，你们小组的"指导教师"、业务部门，都是客户。客户今天说要 A，明天说要 B，你如果不做变更管理，就是灾难。 > ④ 时间和成本不可控——计划过于乐观、工期延误、预算超支。典型症状是"每次都说明天就好"。 > ⑤ 沟通不畅与团队低效——分工不明、士气低迷。人多的组反而更慢，往往就是栽在这一条。 > ⑥ 资源和人员管理不足——规划分配不当、核心成员流失。核心架构师在项目中期离职，是很多项目的转折点。 > ⑦ 技术和质量把控不足——技术选型不当、测试不足。这是九条里唯一一条跟"技术"沾边的。 > ⑧ 风险和外部依赖管理不足——风险应对差、外包或供应商延期。你的项目依赖第三方接口、依赖其他组的模块，都可能被拖死。 > ⑨ 缺乏高层支持——资源、决策、关注度不够。回到鸿蒙案例：华为是"公司战略级项目、最高层直接推动"，正因为它把这一条做到了极致。 > 好，现在请大家做一件事：数一数。九条里面，只有第⑦条是技术问题，其余八条全是管理问题。这就是这门课存在的理由——不是技术不重要，而是技术之外还有八件事，件件能要命。 > （点名 2 人，快速回应）刚才让大家想的"最怕的三件事"，对照这九条，你怕的落在哪几条？

> 口播：反过来问一个问题：项目成功，是不是"按时交付"就算成功？答案是：不够。教材给了五个衡量维度，我们一个一个看。 > ① 时间——按时完成，不延误关键节点与交付期限。这是最直观的一条。 > ② 成本——在预算内完成，资源分配合理，投入产出比高。注意最后五个字"投入产出比"：花钱少不等于成功，花得值才算成功。 > ③ 质量——符合功能、性能、安全要求，稳定可维护。"稳定可维护"这四个字很重要，它意味着质量不只是"这次跑通了"，而是"以后还跑得动"。 > ④ 客户满意度——交付让客户满意甚至超出预期，协作过程得到认可。注意"协作过程得到认可"这一句：客户满意的对象不只包括产品，也包括和你合作的过程。 > ⑤ 价值实现——项目有效推动业务目标，为客户与组织创造实际价值。屏幕上引用教材的强调："价值实现是衡量项目成功的最终指标。" > 所以这五条不是并列的，而是有层次的：时间、成本、质量是"做完没做好"的底线；客户满意是"别人认不认"；价值实现是"到底有没有用"的最终审判。 > 屏幕上还有一个红色的警告框，请大家读一遍："按时按预算交付了，但没人用、没创造价值"，这叫"伪成功"。这句话在实务里非常有用——很多系统上线验收合格、剪彩合影，然后一年之后没人登录，统计报表里它是"成功项目"，但业务上它等于零。 > 最后提一句：传统的"铁三角"是范围、时间、成本；现代项目管理更强调价值与干系人满意。这一点在第 16 周的综合案例里会反复用到。 > 给大家一个可以随身带的记忆结构：底线三条（时间、成本、质量）＋认可一条（客户满意度）＋终审一条（价值实现）。期末案例分析题如果问"这个项目成功吗"，你就按这五条逐条对照着答，一个都不漏，分数自然就上去了。

> 口播：现在回看鸿蒙这个案例，我们把它和失败九因做一个"反向映射"——别问华为做对了什么，先问：如果换成你，这九个坑你会掉进哪几个？华为又是怎么绕开的？屏幕上是逐条对照的表格，我带着大家读一遍。 > 第④条，时间与成本不可控——鸿蒙的应对是三阶段推进＋分阶段交付核心功能，把节奏控制在可交付的颗粒度上。这就是"逐条拆弹"的第一颗。 > 第⑦条，技术与质量把控不足——鸿蒙的应对是技术路线多样化＋微内核架构＋开源技术。请注意"多样化"这三个字：它不是为了炫技，而是故意用冗余来摊薄技术风险——一条路走不通，还有另一条。 > 第②条需求管理、第③条客户协作——鸿蒙的应对是联合厂商与开发者，给工具、给资金、给技术指导。说白了，它把外部的合作伙伴变成了"共创方"，而不是"提要求的人"。这一点在软件项目里特别关键：客户协作障碍的本质，往往是双方没有共同的利益和共同的节奏。 > 第⑧条，风险和外部依赖管理不足——鸿蒙的应对很有意思："自主可控"这个目标本身，就是对"依赖安卓"这个最大外部风险的一次性化解。换句话说，它不是在项目中途去补救外部依赖，而是在目标设定阶段就把最大的外部依赖砍掉了。这是风险管理里最彻底的一招。 > 第⑥条资源与人员、第⑨条缺乏高层支持——鸿蒙的应对是数万名工程师、数千亿元投入、跨部门高效协作、最高层战略支持。资源和高层支持这两条，很多时候是绑在一起的：高层支持到位，资源才到位。 > 最后我们回头答一下案例思考的 Q1，答案就是这一列：分阶段推进降低风险＋技术路线多样化＋快速迭代＋生态联合＋高投入与高层支持。 > 大家注意，这就是我们今天做的第一个"闭环"：案例给感觉，理论给标尺，两边互为注解。以后每学一个知识点，你都可以试着找一个案例来对照——这是学这门课最有效的方法。

> 口播：项目不是活在真空里。屏幕上这两个概念，是本章每年都爱考、也最容易混的一对，请大家注意力集中。 > 先说组织过程资产。它是组织可积累、可复用的"家底"——包括模板、流程、历史数据、专家经验等等，作用是帮助项目做得更高效。举几个身边的例子：学院给的项目章程模板、上学期某个系统的进度数据、上一次项目踩坑之后写的经验教训记录——这些统统是组织过程资产。关键词是两个："可积累""可复用"。 > 再说事业环境因素。它是项目给定的内外条件——组织文化、设施、市场、法规等等。屏幕上的说法是：项目只能适应与利用，一般改不了。再举身边的例子：学校的培养方案和排课规则、实验室机房的设备条件、行业监管规定、市场上同类产品的价格——这些都是事业环境因素。 > 请注意屏幕上那个引用框：这些因素可能对项目的规划、执行与价值交付产生有利、不利或者中性的影响。也就是说，"环境因素"不等于"坏因素"，它只是"给定的条件"——条件可能帮你，也可能卡你。 > 给大家一句口诀，屏幕上用红框标出来了：资产＝能积累复用（自家的工具箱），环境＝给定约束（外面的天气）。你出门不能改天气，只能带伞、穿外套、看预报；但你自家的工具箱，可以随手拿、可以传给别人，还可以往里添东西。 > 还要提醒一句：这两个概念都分"组织内、组织外"两个方向，考试最爱考的就是这个"内外"的层次，下一页我们细看分类。 > 再补一个很实用的判断顺序，请大家跟着我念一遍：第一步问"它能不能被下一个项目拿去复用"——能，就是组织过程资产；第二步问"它是不是项目要适应的、改不动的条件"——是，就是事业环境因素；两步都套不上，再看它是不是项目自身的管理安排。这三步走完，本章的选择题基本不会错。

> 口播：组织过程资产包含五大类，我们一类一类看，每类我都给大家配一个身边的例子。 > ① 过程资产。包括工具、方法论、模板、框架、模式，以及 PMO（项目管理办公室）提供的资源。例子：学校或公司沉淀的"项目文档模板""需求说明书模板"。 > ② 治理文件。包括政策、流程文件、指南与标准。例子：公司的立项审批流程、代码提交规范、变更审批制度。它的作用是告诉项目"什么能做、按什么程序做"。 > ③ 数据资产。包括以往项目积累的数据库、文件库、度量指标、历史数据。例子：历史项目的实际工期数据、缺陷率统计。这一类特别值钱——因为它是你做估算的依据，没有历史数据，你的工期就只能靠拍脑袋。 > ④ 知识资产。包括团队成员和专家积累的隐性知识与经验。请注意"隐性知识"这四个字：它是装在人的脑子里的、写不成文档的那部分经验。例子：老工程师知道"这个模块一改就容易出并发问题"。所以知识资产的管理，一半靠文档，一半靠留人、靠传帮带。 > ⑤ 信息安全与合规管理。包括访问控制、数据保护、保密制度等程序与实践。例子：代码仓库的权限分级、客户数据的脱敏规定。 > 屏幕下方有一句话，是本页的落点：新项目开工，先翻家底。这句话非常实用——很多团队一上来就从零开始写模板、从零开始摸流程，其实组织里早就有现成的东西，会用组织过程资产，等于站在别人的肩膀上。 > 顺便提醒：PMO 属于组织过程资产里的"过程资产"，因为它提供方法、模板和资源。这个结论几乎每次都会考。

> 口播：事业环境因素是项目"给定的条件"，教材把它分成组织内部 6 项和组织外部 8 项。我们一项一项过，每一项我都用一句话解释，然后回到鸿蒙案例对号入座。 > 先看组织内部 6 项，这一组回答的是"组织支持项目的能力"： > ① 组织文化、结构与治理——包括愿景、价值观、领导风格、职权关系。说白了就是"这家单位是怎么做决定的"。 > ② 设施与资源配置——办公场地、设备、资源的物理分布。 > ③ 基础设施——设备、IT 硬件这些底子。 > ④ 信息技术软件——进度管理软件、配置管理工具、协作工具。你们用的 Git、项目管理看板，属于这一项。 > ⑤ 资源可用性——注意这一项的关键词是"合同与采购制约、供应商"。也就是说，"我能拿到什么资源"受合同和供应商限制。请特别记住这一项，它马上要在练习里考你。 > ⑥ 员工能力——团队的技能水平、经验储备。 > 再看组织外部 8 项：①市场环境 ②社会与文化因素 ③监管环境（法规）④市场研究数据库 ⑤学术研究 ⑥行业标准 ⑦财务环境（汇率、利率、通胀、税）⑧物理环境。外部这八项的共同特点是——项目几乎完全改不动，只能预判、适应、利用。 > 现在把鸿蒙对号入座，屏幕上给了三组："实体清单"属于外部监管环境和市场环境——这是触发立项的外部因素；"华为的研发文化、IT 设施、工程师队伍"属于组织内部条件——这是它能够接住这一击的底气；"过去 OS 研发积累的数据"属于组织过程资产——这是它可以复用的家底。 > 所以你看，一页纸上的三个概念，在同一个案例里同时出现了：外部环境给了压力，内部条件给了能力，过程资产给了效率。这就是 1.2.2 这一节想要建立的"环境观"。

> 口播：现在做第一道题，请大家看屏幕。题目是：关于事业环境因素，正确的描述是？选项我念一遍——A．由组织内部资源构成；B．包括团队制定的标准化流程；C．项目结束后形成的资产；D．可能来自组织内部或外部，对项目有影响。 > 给大家 1 分钟，同桌之间讨论一下，然后我们举手作答。注意答题纪律：不光要说选哪个，还要说出每一个错误选项错在哪里。 > （1 分钟后请同学回答。） > 好，答案是 D。我们现在逐项拆解，这个方法大家要学会，考场上遇到概念题就靠它。 > 为什么 A 不对？A 说"由组织内部资源构成"——它只说了内部，漏掉了组织外部。我们刚讲过，事业环境因素既有组织内部的 6 项（文化、设施、基础设施、IT 软件、资源可用性、员工能力），也有组织外部的 8 项（市场、社会文化、监管、数据库、学术、标准、财务、物理）。所以 A 的毛病是"以偏概全"。 > 为什么 B 不对？B 说"包括团队制定的标准化流程"——这就把组织过程资产（治理文件、流程）错当成事业环境因素了。流程是组织沉淀下来、可以复用的资产，不是给定的环境条件。 > 为什么 C 不对？C 说"项目结束后形成的资产"——这句话的毛病在于描述反了。事业环境因素是项目开始之前就已经存在、项目要适应的给定条件；而"项目结束后形成的资产"恰恰是组织过程资产得以积累的方式。一句话：环境是"进项目门之前就在那里的"，资产是"出项目门时沉淀下来的"。 > D 为什么对？因为它同时抓住了两个要点：来源上"可能来自组织内部或外部"，作用上"对项目有影响"。这两句话，就是事业环境因素最本质的两个特征。 > 屏幕下方的小抄我再念一遍，请大家抄在书上：事业环境因素＝项目给定的内外条件（文化、设施、市场、法规……），一般改不了；组织过程资产＝组织可积累复用的"家底"。

> 口播：第二道题，方向反过来问。题目是：下列哪一项不属于组织过程资产？选项——A．资源可用性；B．治理文件；C．过程资产；D．安保与安全。 > 同样，1 分钟同桌讨论，然后举手。这题比上一题更"阴"，因为它把正确项夹在错误项中间，你一看"治理文件""过程资产"都觉得耳熟，就容易慌。 > （1 分钟后请同学回答。） > 好，答案是 A．资源可用性。为什么？因为组织过程资产的五类是——①过程资产 ②治理文件 ③数据资产 ④知识资产 ⑤信息安全与合规管理。而"资源可用性"我们刚才在事业环境因素里专门强调过，它属于事业环境因素（组织内部）那一组，关键词是"合同与采购制约、供应商"。所以 B、C、D 都是组织过程资产，只有 A 不是。 > 这里有一个同学容易疑惑的点，我说清楚：D 选项写的是"安保与安全"，它对应的其实是组织过程资产第五类"信息安全与合规管理"（访问控制、数据保护、保密制度等）。所以在这个选项设置里，D 是要归类为过程资产的。 > 屏幕下面还有一个追问，我们现场揭晓：PMO 属于哪一类？——答案是：PMO 属于组织过程资产里的"过程资产"，因为 PMO 提供的是方法、模板和资源。这一条请大家一定要记住，它考过很多次。 > 最后我把这一节最核心的辨析再收一遍口：判断的关键不在"是不是文件"，也不在"在不在组织内部"，而在两把尺子上——第一把，它是不是"组织积累下来、可复用的资产"？第二把，它是不是"给定的、改不动的条件"？前一把指向组织过程资产，后一把指向事业环境因素。把这两把尺子拿稳，这一节的题你就不会丢分了。

> 口播：同学们，休息前的最后一段，我们来讲一个跟你们找工作直接相关的话题——职业认证。第一个，PMP。 > PMP 的全称是 Project Management Professional，中文一般叫"项目管理专业人士资格认证"。它由美国项目管理协会，也就是 PMI 颁发，1984 年首次开考，到今天已经有四十多年历史，是全球公认的项目管理权威认证。大家注意，它不是"IT 认证"，它是通用的项目管理认证——建筑、制造、医药、金融、IT，所有行业都认。对我们在座的同学来说，这意味着你将来不一定只做"程序员"，你还可以走"项目管理者"这条路，而 PMP 就是这条路上最通用的一块敲门砖。 > 那它在中国有多热？据课件数据：截至 2023 年底，中国参加 PMP 考试的人数接近 120 万，有效持证人数超过 60 万，大约占全球持证人数的 35.5%；光 2023 一年，报考就有 24.33 万人次。更值得你们注意的是结构——报考者里面，IT 行业占了 47.81%，接近一半，制造业占 18.94%。也就是说，考 PMP 的人里面，一半是我们的同行。这不是一个"跟我无关"的证书。 > 考它有什么好处？课件给了五条，我给大家串一下：第一，提升国际化项目管理能力——你会系统掌握一套全球通用的管理语言；第二，增强职场竞争力——同样两个人竞聘项目经理，有证的先被看见；第三，拓展职业发展机会——很多跨国企业、外企的项目岗直接把它写进任职要求；第四，提升全球职业认可度——这本证在全球多数国家都被承认；第五，增强企业资质与市场竞争力——很多国际招标明确要求团队里有若干名 PMP 持证人，这是企业投标的"硬资质"。 > 最后提醒一句报考门槛，这也是考试爱考的：PMP 对项目管理时数有要求，不是想报就能报。所以对你们来说，更现实的路线是——先工作积累项目经历，再考 PMP。那有没有一张证，是我们现在就能开始规划的？有。下一页，软考。

> 口播：第二张证，是我们国家自己的——软考，全称"计算机技术与软件专业技术资格（水平）考试"。它的组织方是两个部委：中国人力资源和社会保障部跟工业和信息化部，联合组织，国家级权威认证考试。 > 软考最特别的地方，请大家记住这句话：它既是一本"职业资格证书"，又是一本"职称资格证书"。什么意思？就是考过之后，你不只是拿到一张能力证明，你还可以直接作为职称评定的依据——这在体制内、国企、事业单位，含金量完全不一样。这也是为什么它是国内 IT 领域含金量最高的认证之一。 > 软考分初级、中级、高级三个级别。跟我们这门课最直接相关的，是里面的项目管理类方向：中级叫"系统集成项目管理工程师"，高级叫"信息系统项目管理师"。这两条线，跟我们这学期学的知识体系几乎是一一对应的——今天讲的生命周期、过程组、十大知识领域，将来就是这两门考试的主干内容。 > 规模上也不小：据课件数据，2024 年全国报名 107.22 万人。而且它对个人还有实打实的政策好处——广州、杭州等地，高级证书可以享受人才分类认定或引进补贴。 > 考它的好处，课件也给了五条：① 培养复合型人才——技术＋管理两条腿走路；② 助力职称评定——很多城市还关联积分落户和补贴；③ 提升职场竞争力；④ 促进岗位晋升——不少单位里，中级、高级职称直接对应岗级和工资；⑤ 增强招投标资质——企业投标时，持证人员数量是硬指标，这一点在做政府和企业项目的时候非常实际。 > 最后说报考门槛，这里有个很实用的对比：软考没有学历限制，可以逐级报考——也就是说，你们在大学阶段就可以开始考中级。这是一件"投入产出比"很高的事。

> 口播：这张表，建议你们直接拍下来。我们按五个维度一条一条看，看完你就知道该先考哪张。 > 第一个维度，定位：PMP 是国际权威认证；软考是国家级职业资格，并且带职称效力。一个偏"行业认可"，一个偏"国家认定"。 > 第二个维度，体系：PMP 背后是 PMBOK，也就是美系的项目管理知识体系；软考背后是国内的项目管理标准，加上技术与知识管理的内容。所以软考的卷子里，除了管理，还会考技术、法规、标准，面更宽。 > 第三个维度，项目管理类科目：PMP 就一个，就是 PMP 本身；软考是两个方向——中级是系统集成项目管理工程师，高级是信息系统项目管理师。 > 第四个维度，价值：PMP 的价值在于国际化，外企、跨国项目最认它；软考的价值在于职称评定、积分落户、招投标资质——这些是国内体制内和企业投标场景里的"硬通货"。 > 第五个维度，也是决定你们"现在能不能考"的——报考门槛：PMP 有项目管理时数要求；软考没有学历限制，可以逐级报考。 > 好，那怎么规划？我给一个参考路线，注意这是建议不是规定：本科阶段先拿软考中级打底——因为你没有工作经历，PMP 报不了，软考中级是唯一能现在就启动的；工作以后，再让 PMP 和软考高级并行。两张证不冲突，考的东西有大量重叠，先考一张，另一张会轻松很多。 > 再用一个生活化的比方记住这两张证的分工：PMP 像"国际驾照"——你拿着它，在很多国家的路上都能开；软考像"国内的职称证书"——它在国内的岗位、薪酬、落户、投标这些具体场景里，能直接兑现成待遇和资格。你在国内开车，靠的是后者的效力；你要去海外接项目，前者更被认。两者不冲突，先拿能拿的，再补想拿的。 > 软件行业的实例也很典型：一家做政务信息化的公司去投标，标书里会写"本项目投入高级信息系统项目管理师 2 名"——这是软考的用处；同一家公司接了一个跨国零售集团的订单，对方要求"团队内至少 1 名 PMP 持证"——这是 PMP 的用处。同一支团队，两张证各有各的战场。 > 现在请大家想一个具体问题，写在纸角上：大学四年，你会把哪张证书列进你的规划里？ 是这学期就开始了解中级报名，还是等大三实习后再看？想清楚这件事，你今天的收获就多了一条。

> 口播：同学们，回到座位，我们把最后这一段拿下来。前半节我们讲了"什么是项目、什么是软件项目、管理得怎么样、环境怎么看、证怎么考"——这些都是零件。接下来这四十分钟，我要给你们一个把这些零件装成一台机器的框架。 > 这个框架就叫"价值驱动的软件项目管理知识体系"。请注意标题里最关键的四个字：价值驱动。它跟传统讲法的最大区别是——不是"我把范围、进度、成本三个圈画好就完了"，而是始终追问一句：这个项目到底创造了什么价值？ 交付了没人用的系统，不算成功。 > 这一部分分三小节：1.3.1 项目生命周期——项目分几个阶段、每种阶段长什么样；1.3.2 项目管理知识框架——五大过程组乘十大知识领域，这是全书的地图；1.3.3 项目绩效域——八个领域，回答"项目干得怎么样"。 > 还有一个提醒：这一部分的名词密度是全章最高的。听不懂没关系，先把名字记住、把位置记住，后面十章会一个一个展开。现在看屏幕——这张图，是我们这学期所有内容的"总目录"。

> 口播：请大家看这张图，我们按位置来记。图的正中间，金色的那个框，是"价值交付系统"，下面写着一行小字——"以价值为核心，贯穿始终"。所以它不是五个要素里普通的一个，它是中心。 > 围绕中心，图上标了四条关系线，这就是五要素之间的关系： > 上面是"项目生命周期"——标注写着"阶段骨架"，里面写着四个阶段：启动、准备、执行、结束。它回答的是"项目从生到死，要走几步"。 > 左边是"项目绩效域"——标注是"成败标准"，八个领域，回答的是"这个项目干得怎么样、算不算成功"。 > 右边是"过程组 × 知识领域"——标注是"活动方法"，五个过程组、十个知识领域，回答的是"具体用什么方法、管哪些对象"。 > 下面是"十大知识领域"——标注是"专业对象"，写着"管什么：范围、进度、成本、质量……"。 > 底下还有一行总结：五要素协同，共同回答一个问题——项目如何持续创造并交付价值？ > 我把这四个角色翻译成一句更好记的话：绩效域＝成败标准，生命周期＝骨架，过程组与知识领域＝方法，价值交付系统＝主线。 这四个标签请直接抄在书上，考试考"五要素及其定位"，你就能一条不落地写出来。 > 打个生活化的比方：假设你要办一桌宴席。生命周期是"备菜—下厨—上菜—收桌"的流程骨架；过程组和知识领域是你手里的刀工、火候、菜谱，是方法；绩效域是客人的评价——菜够不够、上得顺不顺、有没有人等太久；而价值交付系统是那句最要紧的判断：这桌席到底是为了给谁吃、办这场宴席值不值。没有最后这一问，前面做得再漂亮，也可能是一场空忙。 > 软件行业里也一样。我举个大家熟悉的例子：一个团队给学校开发"选课系统"。生命周期告诉他们现在在"需求分析"还是"开发"；过程组与知识领域告诉他们这周该管"进度"——排期和关键路径；绩效域帮他们判断"学生选课堵不堵、教务处满不满意"；而价值交付系统逼他们一开始就回答："做这个系统，是为了让学生不再凌晨蹲点抢课，还是为了让教务统计数据更准？"——价值不同，优先级就不同，功能取舍就不同。 > 所以五要素不是五个并列的模块，而是一个紧密相连的整体框架。这句话，课件原文就是这么说的。

> 口播：这一页是一张"对号入座表"，还是拿"校园选课系统"举例。这张表五行的逻辑，请大家一定跟着我的节奏走，因为它就是这学期你读任何一章时的"定位雷达"。 > 第一行，价值交付系统，它回答的问题是：项目为什么做？为谁创造什么价值？ 例子是——为谁做？学生和教务处；价值是什么？选课不拥堵、数据更准确。注意，这是第一个要回答的问题，不是最后一个。 > 第二行，项目生命周期，它回答：现在走到哪一步？下一步是什么？ 例子是——需求分析已完成，刚进入设计阶段，下一步排开发计划。它给的是一根时间轴上的坐标。 > 第三行，项目绩效域，它回答：项目干得怎么样？ 例子是——进度正常、干系人（教务和学生）反馈良好、风险在控。它给的是体检报告的读数。 > 第四行，过程组，它回答：当前在做什么类型的活动？ 例子是——正在"执行"：按计划编码测试；发现偏差转入"监控"纠偏。它给的是动作的类型：启动、规划、执行、监控、收尾。 > 第五行，知识领域，它回答：管的是哪个专业对象？ 例子是——这周管"进度"：排期与关键路径；下周管"成本"：预算。它给的是管理对象的分类。 > 表下面还有一句核心目标，请一起划下来：平衡项目目标与组织需求，最大化价值创造，为项目、组织与干系人带来多重效益。注意"平衡"这两个字——项目目标（按时按质交出来）和组织需求（战略、合规、长远收益）经常是冲突的，管理就是在这两者之间找那个最优解。 > 我给大家一个自测动作：以后你每读一章、每做一个项目，都问自己这五个问题——为什么做？走到哪了？干得怎么样？在做什么类型的活动？管的是哪个对象？ 五句话能答出来，说明你的项目思路是清楚的；有哪一句答不上来，那一块就是你的管理盲区。这就是"知识体系"真正的用法——它不是拿来背的，是拿来提问的。

> 口播：项目生命周期，指项目从启动到完成所经历的一系列阶段。 大项目小项目都一样，通常走四段。请大家一边听，一边把每一步的"核心成果"记下来，因为这条成果链就是第 2 章到第 11 章的主线。 > 第一阶段：启动。 干三件事——明确目标、范围和必要性；识别关键干系人；获得正式批准。核心成果是：项目章程＋干系人登记册。 一句话理解：这个阶段解决的是"这个项目该不该做、由谁拍板"。项目章程就是那张"准生证"。 > 第二阶段：组织与准备。 制订详细计划、分配资源、组建团队。核心成果是：项目管理计划。 它解决的是"怎么做、谁来干、什么时候干完、花多少钱"。 > 第三阶段：执行（含监控）。 按计划实施、交付成果、监控进展、应对变化。核心成果是：验收的可交付成果。 注意括号里那三个字"含监控"——监控不是单独一个阶段，它是贯穿执行的。 > 第四阶段：结束。 验收移交、总结经验教训、归档、释放资源、解散团队。核心成果是：最终产品、服务或成果。 很多团队把这一步做得很潦草，其实经验教训不总结，下一个项目会再踩一遍同样的坑。 > 四步连起来，就有了课件底部那条成果链：项目章程 → 项目管理计划 → 验收的可交付成果 → 最终成果。请把它写在笔记本上，因为它非常有用：以后你判断"这个项目现在走到哪一阶段了"，不用问日期，只要问一句——"现在手里最新的那份正式文件是什么？"是章程，就在启动；是管理计划，就在准备；是验收的可交付成果，就在执行；已经交付并归档，就是收尾。 > 两点补充提醒。第一，每个阶段都要有明确的交付物和决策点（里程碑）——没有交付物的阶段等于没有阶段的结束线。第二，阶段之间可能重叠，不一定严格串行——比如设计还没全部完成，一部分编码可能已经开始，这叫"快速跟进"。为什么要专门提这一点？因为它跟下一页要讲的"过程组"完全是两回事，也是本章最容易考糊的地方。 > 打个生活化的比方：装修房子。启动＝跟家人商量要不要装、定预算、谁拍板；准备＝出设计图、定材料清单、找施工队；执行＝水电木瓦油漆一路干活、你在旁边盯着别跑偏；结束＝验收、结算、拿保修单、把钥匙交给家人。你有没有发现——如果你在"准备"阶段没把设计图定下来，后面每一道工序都要返工？这就是下一页要讲的规律。

> 口播：这一页是本讲的难点，请大家把笔放下，眼睛看屏幕，跟我一起把三条曲线在脑子里画出来。为什么说它是难点？因为三条曲线里有两条方向相反，很多同学一背就串。 > 规律一：投入先低后高再回落。 成本与人力投入的曲线长什么样？启动期低——就几个人在写章程；执行期达到峰值——几十上百人一起编码、测试；收尾迅速回落——人陆续撤走，只剩少数人做验收归档。一句话：中间高、两头低，像一座山。 > 规律二：风险与不确定性前高后低。 项目刚开始的时候，什么都还没定：需求不确定、技术不确定、市场不确定，所以风险最高——就在启动阶段最高。随着关键决策一个个做出来、成果一批批验收，未知越来越少，风险逐步降低。 > 规律三：改错的成本，越晚越贵。 请注意，这条跟前一条方向相反：变更与纠正错误的成本，随项目推进显著增加，接近结束时最高。 > 这三条一起看，就能得出一个非常重要的推论，请大家跟我读一遍：风险最高的时候，改错最便宜；风险最低的时候，改错最贵。 这是一个"错位"！换句话说——老天爷其实对我们挺仁慈的：项目前期虽然最不确定，但那时候你想改什么，成本都很低；等到后期一切都清楚了，你想改，就要付出成倍的代价。可惜大多数人恰恰是前面不认真想、后面被迫大改。 > 那"代价成倍放大"是怎么发生的？我拆给你们看，一共四层：第一层，返工。 需求改了，已经写完的代码要重写。第二层，涟漪。 你改的是需求，但设计要跟着改、数据库要跟着改、接口要跟着改、测试用例要跟着改——一处改动，牵动一片。第三层，连锁。 后面已经在排队的任务全部延后，进度一滑，可能连带违约金。第四层，不可逆。 到了收尾阶段，系统已经交付、用户已经在用、数据已经迁移、文档已经归档——这时候再改，你不仅要改代码，还要改流程、培训用户、重新验收。所以"接近结束时最高"不是夸张，是量级上的差异。 > 我用两个比方帮大家记住。装修的比方：砌墙之前你说"这里改开个窗"，一句话的事；墙砌完再说，要砸墙、要清运、要重新抹灰；等家具都进场、墙纸都贴好了再说，你得搬空整个屋子。软件行业的比方：写代码的时候，让程序员改一段逻辑，可能就是十分钟；等测试做完、系统上线、几万用户已经在用了，你再说要改，那就是一次上线变更——要评估、要回滚方案、要选窗口期、要通知全部干系人。 > 那有没有"反例"？有同学可能会问：现在不是有自动化测试、有 CI/CD 持续集成持续交付、有灰度发布吗？是不是改错就不贵了？这个想法对了一半。现代工具确实能把"改一行代码、发一个版本"的成本压得很低，但它改变不了四件事：范围大的改动、架构级的改动、已经迁移的数据、已经形成的用户习惯和合同承诺——这些照样贵。所以规律的正确表述是："改错的成本随项目推进总体显著上升，接近结束时最高"，它讲的是总体趋势，不是每一处细节。这个"总体趋势"的表述，答题时写出来最稳。 > 三条规律的管理启示，就一句话：风险要早识别、需求要早确认、问题要早暴露。 这也正是我们把"启动"和"范围"放在全书最前面的原因——越早做对，越省成本。 > 【思政点缀】 我们中国有句老话："凡事预则立，不预则废。"这三条曲线，其实就是这句古训的数学版本。真正的高手，是把问题解决在它还没发生的时候。 学习也是一样——今天听懂的十分钟，胜过期末通宵的十小时。

> 口播：先分清两个词，很多同学的困惑就是从这儿开始的。项目生命周期，讲的是"项目分几个阶段"——启动、准备、执行、结束，这是管理的骨架。开发生命周期，讲的是"产品从概念到交付，用什么方式开发"——这是干活的姿势。一个是"什么时候做什么"，一个是"用哪种方法做"。 > 软件的开发生命周期，按管理模式的差异分五种。我们一条一条看，看的时候请重点记"什么情况下用"，不要只记名字。 > ① 预测型，也叫瀑布型、计划驱动型。特点是：先做详尽计划，阶段按序只执行一次。适用：需求清晰、技术成熟、变更少。典型场景：银行的结算系统、航班订座系统——需求比较确定，合规要求严格，一次做对。 > ② 迭代型。特点是：重复"规划—开发—测试"的循环，逐步逼近目标。适用：需求不完全明确，但总目标清晰。注意关键词是"循环"——同一批需求反复打磨。 > ③ 增量型。特点是：分功能模块逐步交付，可以包含 MVP，也就是最小可用产品。适用：需要快速交付核心功能。关键词是"切块"——先给一个能用的部分，再一块块加。 > ④ 适应型，也就是敏捷型。特点是：高层计划＋小步快跑、持续反馈，先做一个高层次计划，再按每个规划周期逐步细化需求。适用：需求高度不确定、变更频繁。典型场景：创业公司的 App、市场还没验证的新产品。 > ⑤ 混合型。特点是：预测型与适应型按阶段或按部分组合。适用：既有稳定又有不确定的复杂项目。课件给的例子是"平台基座走瀑布，功能模块走敏捷迭代"。 > 这一页还有一个关键辨析，课件专门用一句话点出来，请划下来：迭代＝重复循环活动逐步逼近；增量＝渐进增加功能模块。 这两个词后面还要专门用一页讲清楚。 > 生活化的比方：预测型像照着一份反复核对过的菜谱，一次性把一桌菜做完再上桌；迭代型像一边做一边尝，尝一口调一次味，反复几轮把汤调到最好；增量型像分道上菜——先上凉菜让你有得吃，再上热菜，最后上汤；适应型像边吃边问"咸淡怎么样"，随时改菜单；混合型就是"主菜照菜谱、配菜看心情"。 > 回到软件：教务系统先按初步需求开发、试运行后根据老师反馈调整字段——这是迭代；库存系统先上线"入库出库"核心模块，再逐个加"盘点、预警、报表"——这是增量；面向大学生的二手交易 App，用户爱不爱用都不知道，两周发一版——这是适应型。请大家记住这句总结：别死记名字，记"什么情况下用"。

> 口播：这是本讲的第二个难点，也是每年考试都会设陷阱的地方。我用"三个动作＋一个口诀＋两个反例"，帮你一次记住。 > 先说三个动作。 > 迭代型，关键词是"循环"。 同一批需求反复打磨：规划 → 设计 → 开发 → 测试 → 改进，一圈一圈转，每一轮都让整体更完整、更精细。注意，它改变的是质量的深度。 > 增量型，关键词是"切块"。 把功能切成若干块，逐批交付：第一个增量先上线核心功能，第二个增量加盘点，第三个增量加报表……直到最后一个增量交付完，整体才完整。注意，它改变的是功能的广度。 > 适应型，关键词是"变"。它用 Scrum、Kanban 这类方法，先做高层次计划，再按每个规划周期逐步细化需求，快速交付价值、持续反馈。它改变的是对变化的响应方式。 > 还有一个混合型：需求明确的部分用预测，不确定的部分用适应。课件给的例子是"平台基座走瀑布，功能模块走敏捷迭代"。 > 那怎么快速分辨？我给你一个一句话判断法：看每一轮交付之后，是"整体更好了"，还是"功能更多了"。 如果每一轮都在让同一批东西变得更精细、更完善——那是迭代；如果每一轮都多了新东西、多了新功能——那是增量。而适应型看的是"谁在决定下一轮做什么"——如果是根据反馈动态决定、需求随每个周期逐步细化，那就是适应型。 > 这个判断法用生活例子验证一下。迭代就像反复打磨一幅画：第一遍起稿，第二遍上色，第三遍修光影——画布上始终是同一幅画，但一次比一次好。增量就像拼装一台机器：今天装上发动机，明天装上传动，后天装上外壳——每次多一个能用的部件，最后组装成整机。适应型（敏捷）就像边聊边改地装修：你一进门就说"这里要改个柜子"，师傅根据你的反馈马上调整，拥抱变化。 > 再验证两个反例，这两个反例考试特别爱出。 > 反例一：敏捷不是"没有计划"。 有同学一听"适应型"就以为"不用计划、随时改"。错了。适应型仍然是先做高层次计划，再按每个规划周期逐步细化需求——它只是把"一次性做一份大计划"换成了"短周期、多轮次、持续更新的计划"。用一句更直白的话：敏捷不是不要计划，而是换了一种计划节奏。 这个点在第 5 章"开发方法和生命周期绩效域"里还会展开。 > 反例二：增量不等于迭代。 有的团队把一张大饼切成八块，每两个月交一块——这是增量，但如果每一块只是"加上去"而从没回头打磨过，那它就不是迭代。反过来，一个团队把同一套功能反复重构、性能一版比一版好，但功能数量一直没增加——那是迭代，不是增量。 > 最后强调一句最重要的话：迭代和增量经常一起用。 现实中的主流做法是"每一轮迭代交付一个增量"——既循环打磨，又逐步加功能。而敏捷（适应型）是"迭代＋增量＋快速反馈＋自组织团队"的综合体。三层关系理清了，这一页就不会再错。

> 口播：请大家翻到表 1-1，这张表我们逐行读，一共五行，每行都是一个小考点。 > 第一行，需求处理。 预测型：明确，而且开发前就要确定；迭代型与增量型：逐步细化；适应型：动态变化。这一行是最根本的区别——需求什么时候定下来，决定了你后面所有选择。 > 第二行，交付方式。 预测型：一次性交付最终成果；迭代型与增量型：分次交付子集；适应型：频繁交付子集。注意"分次"和"频繁"的区别——迭代增量大概几个月一个子集，敏捷可能两周就有一次可交付的增量。 > 第三行，变更管理。 预测型：尽量限制变更；迭代型与增量型：定期引入变更；适应型：动态实时应对。这里有个反直觉的点：预测型不是"不许改"，是"变更要走严格流程、尽量限制"；适应型也不是"随便改"，而是"变更被纳入常规节奏、实时应对"。 > 第四行，干系人参与。 预测型：在特定里程碑点参与——比如评审会、验收会；迭代型与增量型：定期参与；适应型：持续性深度参与——比如每天站会、每个迭代评审。这一行说明：你选的生命周期，决定了客户要花多少时间陪你。 > 第五行，风险与成本。 预测型：前期详细计划、全局控制；迭代型与增量型：逐步细化、阶段性控制；适应型：动态调整、随变随控。 > 五行读完，我给你们一个"三问选型法"，就印在这张表下面：一问需求何时定？二问一次交还是分次交？三问变更能不能被限制？ 三个问题答完，模型基本就出来了。 > 三问怎么用？我带大家走一遍。问一：需求开发前就能定死吗？ 能定死 → 往预测型走；只能逐步细化 → 往迭代增量走；会动态变化 → 往适应型走。问二：能一次性交付吗？ 能，而且必须一次交付才安全（比如核心结算）→ 预测型；可以分批 → 迭代增量或适应型。问三：变更是被限制还是被欢迎？ 严格限制 → 预测型；定期引入 → 迭代增量；实时应对 → 适应型。 > 最后，这张表最要紧的结论，请一定背下来：没有最好的生命周期，只有最合适的。 千万别把"敏捷"当成政治正确的答案——在一个监管严格、需求明确、改错代价极高的核心结算系统上硬套敏捷，那叫冒险，不叫先进。这个判断力，是这门课想给你们的最重要的能力之一。

> 口播：现在是互动时间。屏幕上有两个场景，外加一个思考题。规则是这样：每个场景我念完题目，给你们 30 秒和同桌讨论，然后我随机点人回答。 回答的时候，请务必说清楚你用了三问选型法的哪一问——只给答案不给依据，不算过关。 > 先念场景 A：教务处的成绩管理系统——需求明确、流程固定、每年同款。你会选哪型？ > （停顿 30 秒，观察讨论情况，点名 1–2 人） > 参考建议是：倾向预测型。理由是——需求明确、变更少，适合一次性交付（瀑布式）。用三问来验：需求开发前能不能定死？能。能不能一次交付？能。变更能不能被限制？能。三问全部指向预测型。 > 接着念场景 B：面向全校的新产品孵化 App——用户爱不爱用不知道，每周要改。你会选哪型？ > （停顿 30 秒，点名 1–2 人） > 参考建议是：倾向适应型或增量型。理由是——需求不确定、要频繁修改，需要小步快跑、分模块交付。三问验一遍：需求能不能提前定死？不能。能不能一次交付？不能，得先上线核心。变更能不能被限制？不能，而且变更本身就是产品迭代的养分。 > 然后是我们今天最想让大家想一想的思考题：鸿蒙 OS 属于哪一型？ > （给 20 秒思考，不急着公布） > 参考思路是这样的：平台基座部分偏预测或迭代——内核、驱动这些东西必须稳，改动要极其慎重；应用生态部分偏适应——小步快跑、持续反馈、开发者反复迭代；所以整体更接近混合型。请注意，这一题没有标准答案，关键是你能不能说出"按确定性裁剪"这五个字——确定的部分用确定的方法管，不确定的部分用不确定的方法管。 > 现在我来点评几个可能的错误答案，因为这些错误在考试里同样会犯。 > 错误一：选"适应型（敏捷）"，理由写"敏捷最先进"。 这是最普遍的心态问题。敏捷不是"更高级"，它是"适用于高不确定性"的一种取舍。在需求明确、流程固定、每年同款的成绩管理系统上套敏捷，你会付出更多沟通和协调成本，却拿不到任何好处。判断依据永远是项目特征，不是个人偏好。 > 错误二：选"预测型"，理由写"保险、稳妥"。 在孵化 App 上也一样错——需求都不确定，你把计划做详尽，等于把不确定性往后推，最后集中爆发，返工代价最大。这正是我们用 1.34 三条规律要防的事情。 > 错误三：选"增量型"，理由写"分批交付就能减少风险"。 部分正确但要小心——增量解决的是"交付节奏"，解决不了"需求会不会变"。如果需求本身在变，光靠增量还不够，还得叠上迭代或适应的机制。 > 好，最后我留一个判断动作给大家：以后遇到任何项目，第一件事不是问"用什么方法"，而是问"它的确定性有多高"。 确定性高，用确定的方法；确定性低，用能容纳变化的方法。这就是这一页的全部。

> 口播：这一页解决两个问题：这套框架是谁定的，以及它由哪两个构件组成。 > 先说出处。课件写得很明确，这套知识框架的依据是两份权威文件：一份是 PMI 的《项目管理标准》与 PMBOK 第 7 版；另一份是我们国内的《信息系统项目管理师教程（第 4 版）》，由软考办组织编写。请注意后面这句关键的话——两者一致提出了"十大知识领域"与"五大过程组"。什么概念？就是我们国家的软考体系和美国的 PMI 体系，在这个框架上是对齐的。这个对齐对你们很有用：你今天学的这一套，两边考试都认，工作也用得上。 > 再说两大构件，这是本页的核心。 > 第一个构件是十大知识领域。它的划分依据是"管什么"——也就是按专业范畴来切。课件上列的顺序是：整合、采购、范围、进度、成本、质量、资源、干系人、沟通、风险。每一个领域，都包含相关的过程、实践、输入输出，以及工具与技术。用大白话讲，它回答的是"这件事属于哪一类专业工作"。 > 第二个构件是五大过程组。它的划分依据是"做什么类型的管理活动"——注意，是逻辑划分，不是时间划分，这一点下一节要专门讲。五个是：启动、规划、执行、监控、收尾。它回答的是"你正在做的是哪一类动作"。 > 那这两大构件怎么合到一起？两维相乘，就得到了表 1-2 的知识框架矩阵——横着是过程组，竖着是知识领域。这张矩阵对应着生命周期的四个阶段，覆盖项目全程。也就是说：生命周期回答"走到哪"，过程组回答"做什么动作"，知识领域回答"管哪个对象"，三者一交叉，就是一个完整的坐标系。 > 还有一个信息请大家注意：这一页课件里"十大知识领域"的排列顺序，跟我们前面 1.32、后面 1.44 的常见背法不完全一样。这不矛盾——不同的教材、不同的考试大纲，排列顺序可能有差别，但十个领域本身一个不少。考试的时候，按你教材和课件给的顺序答最稳；如果只考"有哪些"，那只要十个都写全就给分。这个细节我先给大家打个预防针，避免你们看到顺序不同就慌。 > 下面我们先把"过程组"这一维讲透——五大过程组，各管什么事？

> 口播：五大过程组，我们给每个组配一句话职责，再加一个"关键产物"。记住这条命令链，你就记住了项目管理的一天是怎么过的。 > ① 启动——定义新项目或新阶段，并取得正式授权。 关键产物是：项目章程、识别干系人。请特别注意这两个词，后面填空题经常考。"授权"这两个字很关键：没有授权，你后面所有的计划都是"私活"，没人给你资源，也没人认你的成果。 > ② 规划——制订实现目标的行动计划。 规划的范围很广：范围、进度、成本、质量、资源、沟通、风险……全部要在这一步落下来。一句话：规划就是画路线图，把"要干成什么"翻译成"谁在什么时候干什么、花多少钱"。 > ③ 执行——把计划付诸实践。 具体包括管理项目工作、管理质量、管理沟通、管理干系人参与。执行就是干活、出交付物。 > ④ 监控——跟踪审查、比较实际与计划、纠正偏差、评估变更。 关键词是四个动作：跟踪、比较、纠偏、评估变更。注意，"监控"不是"站在旁边看"，它是主动的比对和干预。 > ⑤ 收尾——正式结束项目或阶段：确认交付、总结经验教训、释放资源。 关键词是"正式"——不是"人散了就算结束"，是要有正式的验收和归档。 > 好，现在给口诀：启、规、执、监、收。 五个字，考试填空写这个就行。 > 那这五组是什么关系？有三句话必须讲清楚。 > 第一，它们循环而不是线性。 一个项目在每一个阶段、每一个子任务里，都可能再走一遍这五个过程。比如你负责"设计数据库"这个子任务，你也要先明确目标（启动）、做个小方案（规划）、动手建表（执行）、检查是否符合规范（监控）、交付评审（收尾）。 > 第二，监控是"横跨"的，不是中间的某一站。 很多人以为流程是"启动→规划→执行→监控→收尾"，一路往下走。其实监控跟规划、执行是并行的，从规划开始就一直在比、一直在纠。你在执行的时候只要发现偏了，随时切回规划修订计划。所以在过程组的示意图里，监控和执行往往是并列且相互缠绕的两条线。 > 第三，规划不是"一次做完就锁死"。 计划是可以被修订的，这就叫"滚动式规划"——远期的粗一点，近期的细一点；每走一段回头看，再更新一次。但请注意，修订计划要走变更流程，不能谁想改就改，否则计划就失去基准的意义了。 > 打个生活化的比方：规划过程组就像出门旅行前的做攻略——订票、订房、定路线、查天气；执行就像真的出发；监控就像路上看导航、看时间、发现堵车就绕路；收尾就像回家写游记、报销、把照片归档。而启动，就是你决定"今年暑假一定要去一趟"并把这个决定告诉家人、要到预算的那个瞬间。你看，少了"启动"这一步，后面所有安排都是没授权的空想。

> 口播：注意了，这是本章最高频的易错点，也是必考点。请把这一页的四个词写在笔记本最上面：过程组是"逻辑分类"，项目阶段是"时间分段"。 > 我们分开说。 > 项目阶段，也就是生命周期的阶段——启动、组织与准备、执行、结束。它是什么？是按时间推进的分段，而且以"可交付成果的完成"为标志。它有先后顺序、有里程碑：章程做完，启动阶段结束；管理计划批准，准备阶段结束；验收的可交付成果移交，执行阶段结束。它在时间轴上是一个格子，走过就不会回头（虽然可以重叠）。 > 过程组——启动、规划、执行、监控、收尾。它是什么？是管理活动的逻辑分类，是"你正在做哪一类动作"。它不是时间上的先后，而是可以反复出现的。课件原文写得很清楚：在项目的每一个阶段，过程组都可能反复执行，直到该阶段达到完工标准。 > 我用课件那个例子给大家走一遍：在"第 3 阶段执行"里面，团队仍然可能启动一个子任务、为它重新规划、监控它的进展、完成后收尾它。也就是说——每一个阶段内部，都内含五过程组的循环。 > 现在给你一个"阶段—过程组"的对照判断法，就三步： > 第一步，问它在时间轴上有没有位置。 能回答"这是项目的第几段、上一步是什么、下一步是什么"——那是阶段。比如"刚进入设计阶段"。 > 第二步，问它在做什么类型的动作。 能回答"我在规划 / 我在监控 / 我在收尾"——那是过程组。比如"正在评估一个变更请求"。 > 第三步，看它会不会重复。 一个项目里，"启动阶段"只会出现一次（同一个层级上）；但"启动过程组"会出现很多次——每一个子任务、每一个阶段开头都可能有一次。 > 再给三个反例，帮你校准。 > 反例一：有同学说"启动阶段之后就是规划阶段"。错。项目生命周期里没有"规划阶段"这个阶段，规划是过程组。生命周期的四段是：启动、组织与准备、执行、结束。名字很像，所以特别容易串。 > 反例二：有同学说"监控阶段"。错。没有"监控阶段"这个东西，监控是贯穿性的一组活动。听到"监控阶段"三个字，你就该警觉。 > 反例三：有同学说"一个项目就是按启动→规划→执行→监控→收尾走一遍，走完项目就结束了"。错。这是把过程组当成了时间轴。真实情况是：外面一层是生命周期四阶段（时间轴），里面每一格都嵌着一遍五过程组的循环。 > 一句话收口，请跟我读：阶段是"时间轴上的格子"，过程组是"每个格子里都要做的五类动作"。 这个考点想拿满分，你只要在答题时把"逻辑分类 ≠ 时间顺序、可反复执行"这几个字写进去就够了。

> 口播：请大家看这张表，我要说一句很重的话：这张表是全书的地图。 这学期我们学十章内容，本质上就是把这张表一行一行展开。你如果今天把这张表的骨架记下来，后面每一章你都会有一种"我知道我在学什么位置"的踏实感。 > 先说怎么摆。横着看，是五大过程组：启动、规划、执行、监控、收尾。竖着看，是十大知识领域：整合、采购、范围、进度、成本、质量、资源、干系人、沟通、风险。行列交叉的格子里，写的就是这个领域在这个过程组里的具体过程。 > 现在我把这十行给大家念一遍，你们跟着在书上划。请注意听"哪一行在哪几列出没出现"。 > 第一行，整合管理——启动列有"制定项目章程"；规划列有"制订项目管理计划"；执行列有"指导与管理项目工作、管理项目知识"；监控列有"监控项目工作、实施整体变更控制"；收尾列有"结束项目或阶段"。五行全满，是唯一贯穿全部五个过程组的知识领域。请大家记住这个事实，下一节小结要用它。 > 第二行，采购管理——规划列"规划采购管理"；执行列"实施采购"；监控列"控制采购"；启动和收尾两列是"—"。 > 第三行，范围管理——规划列四个过程："规划范围管理、收集需求、定义范围、创建 WBS"；监控列两个："确认范围、控制范围"；启动、执行、收尾三列是"—"。 > 第四行，进度管理——规划列五个："规划进度管理、定义活动、排列活动顺序、估算活动持续时间、制订进度计划"；监控列"控制进度"。 > 第五行，成本管理——规划列三个："规划成本管理、估算成本、制订预算"；监控列"控制成本"。 > 第六行，质量管理——规划列"规划质量管理"；执行列"管理质量"；监控列"控制质量"。注意它有执行列。 > 第七行，资源管理——规划列"规划资源管理、估算活动资源"；执行列"获取资源、建设团队、管理团队"；监控列"控制资源"。它也有执行列，而且是执行列内容最多的一行。 > 第八行，干系人管理——启动列"识别干系人"；规划列"规划干系人参与"；执行列"管理干系人参与"；监控列"监督干系人参与"。它在启动列有内容，这是除整合之外唯一在启动列出现的一行，请大家特别标记。 > 第九行，沟通管理——规划列"规划沟通管理"；执行列"管理沟通"；监控列"监督沟通"。 > 第十行，风险管理——规划列"规划风险管理、识别风险、定性风险分析、定量风险分析"；执行列"实施风险应对"；监控列"监督风险"。 > 念完了，我们横向比一比，你会发现三个很有意思的规律。 > 规律一：规划和监控两列最"挤"。 十个领域几乎都在规划和监控有过程——这说明什么？项目管理的工作量，主要花在"想清楚"和"盯住偏差"上，而不是花在"闷头干"上。这跟我们前面讲的三条规律是一致的：越早做对，越省成本。 > 规律二：只有四个领域有"执行列"内容——整合、采购、质量、资源、干系人、沟通、风险（细数有七个）。而范围、进度、成本这三个领域只有规划和监控。为什么？因为范围、进度、成本主要靠"先计划、后纠偏"来管，具体的生产活动属于"项目工作"，归在整合管理的执行列里。这是一个很值得琢磨的设计。 > 规律三："—"不代表不重要。 很多同学一看"—"就以为"这个领域不做这件事"。请注意："—"只表示这个知识领域不包含该过程组的具体过程管理活动，不等于这项工作不存在。比如成本管理在"执行列"是"—"，但执行阶段当然要花钱——只是"花钱"这件事的过程管理，归到"控制成本"（监控列）里去了。 > 最后给大家一个口诀，把十行记住："整采范进成，质资干沟风"——整合、采购、范围、进度、成本、质量、资源、干系人、沟通、风险。五个字加五个字，念两遍就有节奏了。 > 这一页信息量大，我不要求你们现在就背下每个格子的过程名——那是第 3 章到第 11 章的任务。今天只要做到三件事：记住十行五列的结构、记住整合行是满的、记住范围和进度成本只有规划和监控。

> 口播：刚才我说"一行就是一章"，可能还有同学没感觉。这一页，我们拿"整合管理"这一行，从左边走到右边，走一遍完整旅程。 > 第一站，启动列：制定项目章程。 干什么？让项目"合法开工"。产出物是项目章程，它授权项目经理、明确高层目标。这一站就是第 2 章的核心内容。 > 第二站，规划列：制订项目管理计划。 干什么？定好路线图。把所有子计划（范围、进度、成本、质量、资源、沟通、风险、采购、干系人）整合成一份总的项目管理计划。这一站牵动第 3 章到第 6 章的全部方法。 > 第三站，执行列：指导与管理项目工作＋管理项目知识。 干什么？开始干活，同时沉淀经验。注意后面那半句"管理项目知识"——它不是"顺手记个笔记"，而是有意识地让项目过程中的知识被创造、被存储、被复用。很多团队干活很猛、经验全散，这一站就是治这个病的。 > 第四站，监控列：监控项目工作＋实施整体变更控制。 干什么？盯偏差、管变更。这里有一个特别要紧的细节：变更控制前面为什么有两个字——"整体"？因为任何一个变更都不会只影响一个领域。客户说"加一个报表"，它同时动到范围（多了功能）、进度（要延期）、成本（要加人）、质量（测试用例要补）、沟通（要通知干系人）。所以必须有一个"整体"的视角来统一评估和决策，不能让每个部门各自答应客户。 > 第五站，收尾列：结束项目或阶段。 干什么？验收、归档、释放资源。注意是"项目或阶段"——也就是说不光项目整体结束要做，每个阶段结束也要做一次小收尾。这个概念很实用：阶段小收尾做得好，最后的大收尾就不会变成一场灾难。 > 五站走完，你会发现——这一行，就是"整合管理"这一章的全部骨架。以后你打开第 11 章，看到的内容一定就是这五站展开后的细节。 > 为了让大家更会读，我再给一个对比：范围管理这一行，路径是"规划范围管理 → 收集需求 → 定义范围 → 创建 WBS → 确认范围 → 控制范围"。你看它的特点——全部集中在"规划"和"监控"两列，前四个过程是在规划阶段把"做什么、不做什么"定义清楚，后两个过程是在监控阶段确认和守护这个边界。范围这一行，本质上就是"先定义边界，再守住边界"。 > 那这张表到底怎么用？我给你们一个学法三步，也是这门课的学习方法： > 第一步，学每章之前，先回到表 1-2，找到这一行。 比如下周学第 2 章"启动"，你就先看"整合"行和"干系人"行的启动列——制定项目章程、识别干系人。你会立刻知道这章要学什么。 > 第二步，学完这一章，回来把这一行的格子填满。 每个格子里写过程名，再写它的一句话作用。 > 第三步，做案例题的时候，从"行"和"列"两个方向交叉定位。 题目说"项目组发现进度落后，调整了关键路径"——列表是"控制进度"（监控列），行是"进度管理"。定位到了，答题就有了框架。 > 最后一句话总结这一页："一行读完，就是这一章的全部骨架；一列读完，就是一类动作的全部做法。" 你把这张表当目录用，这门课就不会散。

> 口播：这一页，我们给十个领域各配一句话。要求很简单：听完这一页，你合上书能把这十句话说出来。 > ① 整合管理——统筹协调各过程，保证整体一致（含变更控制）。注意它不只是"汇总"，它要在各领域之间做权衡：范围加一点，进度就要让一点，成本就要涨一点，谁来做这个取舍？整合。所以它在十大领域里排第一。 > ② 采购管理——规划、执行、控制采购，保证资源及时获得。哪些东西自己做、哪些买、怎么买、买来之后怎么管。 > ③ 范围管理——只做且做完所需工作。课件特别加了一句括号："防止多干少干"。这四个字很值钱——多干也是错，因为多干的部分没人付钱、还占用了本该做别的资源。 > ④ 进度管理——按时完成交付。排期、定活动、排顺序、估工期、盯进度。 > ⑤ 成本管理——预算内完成。它的链条是"估算 → 预算 → 控制"。 > ⑥ 质量管理——把质量政策落到规划、管理、控制。三层：先定标准（规划质量），再按标准把质量做出来（管理质量），最后检验合不合格（控制质量）。 > ⑦ 资源管理——人力和物力资源的识别、获取与管理。包括组队、建设团队、管理团队。 > ⑧ 干系人管理——识别并引导那些受影响或能影响项目的人。注意定义里有两个方向："受影响"和"能影响"，别只记前者。 > ⑨ 沟通管理——让信息高效地生成、传递、反馈。三个动词连起来才是完整闭环，只"发通知"不叫沟通。 > ⑩ 风险管理——把不确定性的坏影响降到最低。注意"坏影响"——风险不只是威胁，也包括机会，但教材在这里的口径是强调降低负面影响。 > 好，口诀来了，请跟我念两遍："整采范进成，质资干沟风"——整合、采购、范围、进度、成本，质量、资源、干系人、沟通、风险。先五字，再五字，读起来是"整采范进成／质资干沟风"，有节奏，两遍就能记住。 > 有个细节我要专门提醒，因为它会坑人。你们在网上、在别的教材里，会看到"整范进成质，资沟风采干"这种背法——就是把"采购"放到后面。两种背法内容完全一样，只是顺序不同，因为不同教材对领域的排列顺序不一样。考试的时候，如果你不确定按哪种，就先把十个都写出来，只要一个不少、名称准确，通常就能拿到分数；只有在明确要求"按顺序"的时候，才需要按我们课件的顺序来。这个提醒，就是怕你们看到顺序不同就慌，甚至怀疑自己记错了。 > 软件行业的实例，我用一个"外卖订单系统"跑一遍：范围＝只做"下单、支付、配送、评价"四个模块，不做好评返现；进度＝六周上线；成本＝预算 30 万；质量＝支付成功率、并发响应时间达标；资源＝2 个后端＋1 个前端＋1 个测试；沟通＝每周例会＋群内日报；风险＝第三方支付接口延期；采购＝直接买短信服务和地图 SDK，不自己造；干系人＝商家、骑手、用户、平台运营；整合＝这九个领域互相冲突时，由项目经理来拍板。你看，十个领域其实就是十个提问角度——你把它们当问题清单，项目管理就不会漏项。

> 口播：最后一个知识块。先给定义，请大家记准确：绩效域是一组对有效交付项目成果至关重要的活动和关注领域。 关键词是"一组活动"，不是"一个部门"，也不是"一个文件"。它们相互联系、在生命周期中同时运行，构成一个整合的管理体系。 > 八个绩效域，我一个一个念，每个配一句话： > ① 干系人绩效域——识别、分析并满足其需求与期望。注意是"识别、分析、满足"三步，不是"发个问卷就完事"。 > ② 团队绩效域——组建、协作、发展，让团队高效工作。这一域关心的是"人怎么拧成一股绳"。 > ③ 开发方法和生命周期绩效域——选对开发模式与节奏。这正是我们前面 1.3.1 讲的生命周期，第 5 章会专门讲。 > ④ 规划绩效域——做出全面而灵活的计划。注意这里有两个词：全面＋灵活——既要覆盖到位，又要能改。这正好回应了"敏捷不是不要计划"。 > ⑤ 项目工作绩效域——落实和协调各项工作，按计划推进。这是最"日常"的一域，项目管理的大部分时间花在这里。 > ⑥ 交付成果绩效域——验证并交付符合质量与期望的成果。注意"验证"两个字在前——不是"我做完了就交"，而是"确认它符合质量与期望"再交。 > ⑦ 度量绩效域——用数据监控、评估，持续优化。这一域治的是"凭感觉管项目"的毛病。 > ⑧ 不确定性绩效域——识别并应对风险与机会，增强韧性。注意这里同时提了风险与机会，比风险的表述更完整。 > 好，现在讲最关键的一个问题：绩效域和知识领域到底有什么不同？ 这是考试最爱考的地方。 > 课件原文给了一句话：知识领域回答"管什么"，绩效域回答"要出什么结果"。我把它拆开讲： > 知识领域是"按专业内容"分的——范围、进度、成本、质量……它像医院里的科室：内科、外科、检验科。你问"这件事该找哪个科"，就是在问知识领域。 > 绩效域是"按关注的结果区域"分的——干系人满不满意、团队能不能打、交付的东西对不对、有没有度量、不确定性控没控住。它像医院里的体检指标：血压、血糖、心率、体重。你问"这个人整体健康吗"，看的是指标，而不是某一个科室。 > 用一句话记住区别：知识领域是"科目表"，绩效域是"体检表"。 科目表告诉你有哪些专业分工，体检表告诉你整体状态好不好。而且课件说得很明确：绩效域更强调整体协同与价值交付——它天生就是"跨科目"的视角。 > 最后给大家一个提问练习：八个绩效域里，哪一个专门讲风险与机会？ 大家先想，别急着翻页。 > （等 5 秒） > 答案：不确定性绩效域——它在第 10 章有专章。你答对了吗？答对的同学，说明你已经抓到"绩效域＝关注什么结果"这条思路了。

> 口播：这一页是一张"索引表"，左边八个绩效域，右边是它们在本书里展开的位置。我一条一条念，你们照着在目录上标记。 > 干系人绩效域——第 2 章初步识别，第 9 章设专章。为什么启动就要识别干系人？因为你连"谁关心这件事"都不知道，后面没法排优先级。 > 团队绩效域——第 8 章专章。团队怎么组建、怎么激励、怎么解决冲突。 > 开发方法和生命周期绩效域——第 5 章专章。这一域正是我们 1.3.1 讲过内容的延续——今天讲了五种模型，第 5 章会讲怎么选、怎么裁剪。 > 规划绩效域——第 3 章到第 6 章讲方法，第 11 章做整合。它不专属于某一章，而是"贯穿范围、进度、成本"这些计划类章节的一条线。 > 项目工作绩效域——第 11 章整合收束。这是最日常的一域，到最后收口。 > 交付成果绩效域——第 4 章＋第 7 章质量保障。范围管理管"做什么"，质量管理管"做得好不好"，两者合起来才能"验证并交付合格成果"。 > 度量绩效域——第 6 章挣值＋第 7 章质量度量。"挣值"这个词大家可能第一次听，它是用数据判断"钱花得值不值、进度偏没偏"的一套方法，第 6 章会详讲。 > 不确定性绩效域——第 10 章专章。风险与机会的管理，整整一章。 > 好，现在请抬头看这一页的右下角，那里有个提问：猜一猜，哪个绩效域专门讲风险与机会？ 刚才我们已经答过了——不确定性绩效域。这里再问一次，是要你们把它跟章节对应起来：第 10 章。 > 那这张表到底给我们什么好处？课件给了一句非常精炼的话："知识领域是竖着切，绩效域是横着切，两条线索交叉，你就不会漏掉重点。" > 这个"交叉"是什么意思？我举个例子。假设你学完第 4 章"范围管理"，你可能觉得"范围就是收集需求、画 WBS"。但如果你再用绩效域这把横刀切一下，你会问：范围做得好，交付成果绩效域就健康吗？ 不一定——范围边界清楚了，但如果质量不达标，交付成果绩效域照样亮红灯。一次交叉，你就发现了一个盲区。 > 再举一个：你学第 8 章"团队管理"，竖着切你会答"组建、建设、管理团队"。横着切你会问：团队绩效域好了，项目就成功了吗？ 也未必——团队很能打，但需求天天变，交付成果照样出问题。所以两条线索必须同时看。 > 给大家一个记忆抓手："竖切管对象，横切管结果；两条线一交叉，重点就跑不掉。"

> 口播：最后一页概念，把绩效域的价值讲清楚。 > 课件给了三个具体的好处，我们一条一条看。 > 第一条，优化资源——避免资源浪费与目标偏离，提高整体协调性。绩效域是一个"同时看八个方向"的框架。只盯一个方向的团队会怎样？比如只盯"按时交付"，就可能牺牲质量；只盯质量，就可能拖垮进度。八个方向一起看，资源才不会被某个局部过度消耗。 > 第二条，提高响应——在复杂动态环境中快速响应变化、抓住机遇。注意这里有"抓住机遇"四个字。项目管理不只是防坏事，也包括抓好事——比如某个技术突然成熟了、某个政策突然利好了，你能不能第一时间把资源挪过去？这就是"响应"。 > 第三条，创造价值——高效协作＋精准规划＋优质交付 → 为干系人创造最大价值。你看课件这个公式，三个加号项拼起来才叫价值：协作（团队＋干系人）、规划（规划域）、交付（交付成果域）。少了任何一项，价值都出不来。 > 然后是最关键的一句，请大家划下来："绩效域不是孤立的：它们同时运行、彼此关联，为项目提供系统性视角——既能独立评估某一领域，又能综合看领域间关系。" > 这句话我拆两层。"独立评估"是指：当项目出问题时，你可以一个一个域去体检——干系人是不是没参与？团队是不是散了？规划是不是太死？度量是不是没数据？"综合看关系"是指：你还得看它们之间的传导——团队一散，交付质量就掉；度量缺失，不确定性就控不住；干系人不参与，规划就会失真。 > 这就引出了本页的收束：绩效域的价值在于"整合"。课件说得很直接——项目不是一个部门一个部门地"各干各的"，而是要在干系人、团队、计划、交付、度量、风险之间动态平衡。请注意"动态平衡"四个字——不是一次调平就完了，而是随着项目推进不断重新调平。 > 也正因为如此，"整合管理"才能在十大知识领域里排第一。你们看，两条线索在这里合上了：绩效域讲横向整合，整合管理讲纵向统筹，它们说的是同一件事——项目管理不是把零件摞在一起，而是让零件互相配合、共同指向价值。 > 打个生活化的比方：办一场婚礼。婚庆、酒店、摄影、司仪、双方家长、宾客——每个环节单独看都可以做得不错，但如果你只把每一块做好、不整合，就很容易出现"仪式开始了摄影还在路上""宾客到了酒店没接到人"。婚礼办得好不好，从来不看单块做得多漂亮，而看整体的节奏和衔接。 项目也一样。

> 口播：进入练习环节。三道题，第一道是选择题，这道题直接对应教材本章习题的第 (4) 题。请大家合上教材，看屏幕。 > 我先念题干："先基于初始需求制订高层计划，再逐步细化以适应每个规划周期——这是哪种生命周期？" > 选项：A．预测型　B．迭代型　C．增量型　D．适应型。 > 现在开始计时，给你们 40 秒，把答案写在纸上。写的时候请一并写下你的判断依据——用我们表 1-1 的三问选型法。开始。 > （计时 40 秒，巡视一圈，观察有没有人在犹豫） > 好，时间到。先不要喊答案，我请一位同学说说他的依据。 > （点名 1 人） > 正确答案是 D．适应型。 > 现在我来点评。这道题的答案，其实就藏在题干里的一句话里——"先基于初始需求制订高层计划，再逐步细化"。这几乎就是适应型（敏捷型）的原文定义。大家回忆一下，我们在 1.36 那一页讲过一句反例提醒：敏捷不是没有计划，它是"先做高层次计划，再按每个规划周期逐步细化需求"。题干说的就是这个。所以这道题不是考你"感觉哪个更先进"，而是考你有没有记住定义里的关键短语。 > 那我们顺便把三个错误选项为什么错讲清楚，这才是这道题的价值。 > A．预测型，错在哪？ 预测型是"先做详尽计划，阶段按序只执行一次"。题干说的是"高层计划"然后再细化——"高层"和"详尽"是反义词，"逐步细化"和"只执行一次"也是矛盾的。所以 A 不能选。你如果选了 A，说明你把"先有计划"这件事直接等同于预测型了，这是最典型的误判。 > B．迭代型，错在哪？ 迭代型的关键词是"循环"——同一批需求反复打磨，一轮一轮让整体更精细。题干强调的是"按每个规划周期逐步细化需求"，重点在需求被动态细化，而不是"同一批需求被反复打磨"。两者的差别很微妙，但考试就爱在这里设陷阱。判断口诀：循环打磨是迭代，动态定需求是适应。 > C．增量型，错在哪？ 增量型的关键词是"切块"——功能模块逐批交付。题干里完全没提"分模块交付"，提的是"计划怎么定、需求怎么细化"。所以 C 是"答非所问"型干扰项。你如果选了 C，说明你抓住了"分批"的感觉，但没分清"分批交付"和"分批定需求"是两件事。 > 最后给大家一句点评话术，也是这道题的答题模板："该题描述的是适应型（敏捷型）生命周期——它先基于初始需求制订高层计划，再按每个规划周期逐步细化需求。因此依据题干中的'高层计划＋逐步细化'即可判定，对应教材表 1-1 中'适应型：需求动态变化、频繁交付子集、变更实时应对'。" > 这道题只值 2 分，但它的判断方法值 20 分——因为案例题里选错生命周期，后面全盘皆错。

> 口播：第二题，对应教材本章习题第 (5) 题。这道题是"送分题"，但每年都有人送掉，因为方向容易背反。 > 题干："软件项目生命周期中，变更与纠错成本最高的是哪一阶段？" > 选项：A．启动　B．组织与准备　C．执行　D．结束。 > 计时 30 秒，写答案，再写一句依据。开始。 > （计时 30 秒） > 好，正确答案是 D．结束。 > 我知道有同学会犹豫——"老师不是说风险在启动阶段最高吗？那成本最高不也应该是启动？"这个疑问非常好，它恰恰说明你已经记住了规律二，但把规律二和规律三搞反了。请大家跟我一起把 1.34 那三条规律再念一遍： > 规律一，成本与人力投入：中间高、两头低。 > 规律二，风险与不确定性：前期最高、随进展下降。 > 规律三，变更与纠错成本：前期最低、随项目推进显著增加、接近结束时最高。 > 请特别注意：规律二和规律三方向相反。 风险最高的是启动；改错最贵的是结束。这两个答案永远不要写反，因为考试就是专门利用这个"错位"来设陷阱的。 > 那为什么"结束"最贵？我再把 1.34 讲的四层代价压缩成一句话，方便你们答题时展开：一是返工（已完成的代码和文档要重做）；二是涟漪（设计、接口、数据库、测试用例连锁修改）；三是连锁（后续任务延后，可能触发违约）；四是不可逆（系统已交付、用户已在用、数据已迁移、培训已完成）。 > 还有一点很重要，这也是这道题的深层考点：题干问的是"软件项目生命周期中"，四个选项正是生命周期的四个阶段——启动、组织与准备、执行、结束。所以这道题实际上同时考了你两件事：一是三条规律，二是生命周期的四阶段名称。有同学把 B 写成"规划阶段"，那就同时错了两处——因为生命周期里的第二个阶段叫"组织与准备"，"规划"是过程组。这个坑，我们 1.41 专门讲过。 > 点评话术，供大家参考："变更与纠正错误的成本随项目推进显著增加，接近结束时最高（教材图 1-5 口径）。因此选 D 结束阶段。这一规律与'风险前高后低'方向相反，答题时务必区分：风险最高在早期，改错最贵在后期。" > 这道题我们班必须全对。它不难，但它是最能检验"你有没有真的理解三条规律"的一道题。

> 口播：最后一组练习，三道填空题，对应教材本章习题的填空题。规则：我把题念完，每道题给 20 秒，大家先自己写，不许翻书、不许问同桌。三题写完我们一起对答案。开始。 > 第一题：五大过程组 ＝ 启动、＿＿、执行、＿＿、收尾。 > （等 20 秒） > 答案：规划过程组、监控过程组。这道题考的是过程组的名称和顺序——启规执监收。请注意答题规范：写"规划过程组、监控过程组"。如果你只写"规划""监控"，一般也能得分，但写全更稳。这里再提醒一次："监控"夹在"执行"和"收尾"之间，是顺序考点，别把监控写到收尾后面去。 > 第二题：八大绩效域中缺哪一项？——干系人 · 团队 · 开发方法和生命周期 · 规划 · 项目工作 · ＿＿ · 度量 · 不确定性。 > （等 20 秒） > 答案：交付成果绩效域。这道题是"挖空题"，考你八个绩效域是否一个不漏。我给大家一个记忆顺序，把八域编成四组两两配对： > 第一组，"人和队伍"——干系人、团队； > 第二组，"方法和计划"——开发方法和生命周期、规划； > 第三组，"干活和交付"——项目工作、交付成果； > 第四组，"看数和看风险"——度量、不确定性。 > 你按这个分组背，挖空任何一项你都能补上。这四组的逻辑是：先认人、再定法和计划、然后干活交付、最后看数据控风险——一条完整的项目管理思维链。 > 第三题：启动过程组包含制定项目章程和＿＿两个过程。 > （等 20 秒） > 答案：识别干系人。 > 这道题我要多讲两句，因为它是本讲最有"含金量"的一道小题。为什么启动过程组只有两个过程，偏偏是这两个？因为它们回答了项目开工最根本的两个问题：第一，"这件事谁批准、我能调动什么资源？"——这是项目章程。第二，"这件事跟谁有关、谁会影响它、它会影响到谁？"——这是识别干系人。 一个解决授权，一个解决关系。授权不清，你干活没人认；干系人不明，你干活没人配合。很多项目从第一天就埋下失败的种子，就是因为这两个问题没回答清楚。 > 也给一个易错提醒：有同学会把"制订项目管理计划"填进这个空。错——制订项目管理计划属于规划过程组（整合管理这一行的规划列）。启动过程组的两个过程，在表 1-2 里分别落在"整合"行和"干系人"行的启动列，请大家回去在表上把这两个格子圈出来，考前一眼就能想起来。 > 三题讲完，做个总评：这三道题覆盖了过程组名称、绩效域枚举、启动过程组产物三个高频考点。做全对的同学，说明今天的骨架你已经拿到了；错了一题的同学，回去把表 1-2 和八大绩效域各默写一遍——默写一遍，胜过反复朗读十遍。

> 口播：请大家抬头看这张图，从上往下，就是我们今天走过的整条路。我按图的顺序念一遍，你们对照着自己的笔记补漏。 > 最上面第一个方框：项目。 下面写着五个词——目的、独特、临时、约束、不确定。这就是项目的五大特征，口诀"目独临约不"。 > 箭头往下，写着"＋软件项目 3 大特点"——渐进明晰、学科复杂、智力密集。三者合起来就是一句话：需求会变、技术很杂、靠脑子吃饭。 > 第二个方框：软件项目。 > 箭头往下："用管理约束——成本 × 进度 × 质量"，动作是"规划 · 组织 · 协调 · 控制"。这四加三，就是软件项目管理的定义骨架。 > 第三个方框：软件项目管理。 下面一行小字："成败 5 维 · 受内外部环境影响"，这就是它两侧那两个方框。 > 左边：成功 5 维——时间、成本、质量、客户满意，最后一个是价值实现（最终指标）。请大家记住括注里那两个字"最终"——按时按预算交付了但没人用，那是伪成功。 > 右边：内外部环境——组织过程资产（自家的工具箱：过程资产、治理文件、数据资产、知识资产、信息安全与合规管理）与事业环境因素（外面的天气：组织内部 6 项＋组织外部 8 项）。口诀还是那句：资产能积累复用，环境是给定约束。 > 再往下："以价值为核心 → 纳入知识体系"，进入底部那个大框——价值驱动的软件项目管理知识体系（五要素）：项目生命周期（4 阶段）、过程组 × 知识领域（5 × 10）、八大绩效域（8 个）、价值交付系统（贯穿始终）。 > 最下面两行是这张图的落点："第 2–11 章 ＝ 这张地图的逐块放大"，以及整门课的路线：启动 → 采购 · 范围 · 进度 · 成本 · 质量 · 资源 · 干系人与沟通 · 风险 → 整合串讲（第 16 周）。 > 好，现在我把今天的收获压成五句话，请你们抄在笔记最后： > 一个案例——华为鸿蒙 OS：自主可控、三阶段推进、生态建设，赢在分阶段交付、技术路线多样化、生态联合、高层支持。 > 两个定义——项目是"为创造独特的产品、服务或成果而进行的临时性工作"；软件项目额外有渐进明晰、学科复杂、智力密集三个特点。 > 两组概念——组织过程资产（自家工具箱）与事业环境因素（外面的天气）；生命周期阶段（时间轴上的格子）与过程组（每个格子里都要做的五类动作）。 > 一个框架——价值驱动：生命周期 × 五大过程组 × 十大知识领域 × 八大绩效域，中心是价值交付系统。 > 一条底线——风险要早识别、需求要早确认、问题要早暴露，因为风险高的时候改错最便宜，风险低的时候改错最贵。 > 最后，本讲金句，请大家一起念一遍："技术决定你能不能做出来，管理决定你能不能按时、按质、按预算交出来。" > 这句话，就是我们这门课存在的理由。

> 口播：同学们，我们把作业逐题讲清楚，讲完你就可以直接动手了。 > 第一项，学习通"考试题库"作业——必做。 覆盖选择、填空、判断等题型，里面包含了今天课堂上做的全部练习题。为什么要布置这一项？ 因为它对应的是本讲所有识记型考点——项目五大特征、组织过程资产与事业环境因素的归类、五大过程组、八大绩效域。这些东西没有理解门槛，但不练就会混，尤其是"过程组与阶段"这类易错点，只在脑子里过一遍是不够的。期望你做到什么程度：完成率 100%，并且错题要回看解析——不是为了刷对率，是为了知道自己错在哪一类（是记不住，还是分不清）。 > 第二项，开放题（学习通简答题）——必做，二选一。 > 选项 ①：用一句话向非专业人士解释"什么是软件项目管理"，并注明你用了本章的哪些概念。 这道题考的是"你能不能把话说人话"。项目管理最大的沟通成本，就是向内行说行话、向外行也说行话。期望程度：一句话不超过 60 字，能让完全不懂软件的人听懂，并在后面列出你用到的概念（比如"三条约束""四个动作""价值实现"）。评分看两点：话是不是人话，概念用得对不对。 > 选项 ②：以你感兴趣的软件项目为例，画一张"生命周期 4 阶段 × 各阶段核心产物"的一行表。 这道题考的是 1.33 那条成果链——章程、项目管理计划、验收的可交付成果、最终成果。期望程度：四个阶段一个不落，每个阶段至少写一个核心产物，产物名称要用术语（不能写"做个方案"这种模糊说法）。这道题还有一个伏笔——它就是你课外综合小组项目 M1（章程）、M2（计划）、M3（验收）的预演，认真做，后面能直接复用。 > 第三项，课外选做（不评分）： 浏览教材实验 1 的题目和课外实践方案，想一想你们小组要选什么题。为什么要现在想？ 因为第 2 章讲"项目章程"的时候，我们会直接拿你们的选题来练"目标怎么写、干系人怎么识别"。带着选题来听课，你的收获会翻倍。 > 顺便把交作业的两条纪律说在前面：独立完成，不许抄袭；按时提交，作业计入平时成绩的 20%。这两条不是形式，是职业底线——将来你在项目里伪造进度数据、抄别人的方案，代价远不止一次扣分。 > 最后，下节课预告。 第 2 周，我们进入第 2 章 软件项目启动。案例是一个大家很熟悉的场景：某大型连锁超市的智能库存管理系统。要讲的内容包括：项目建议书、可行性研究、项目经理与组织结构、干系人识别、项目章程、启动会议。请预习教材 2.2 到 2.5。 > 提前留一个问题给大家想：一个新项目要上马，先干什么？谁说了算？ 今天我们已经埋了一个答案——启动过程组只有两个过程：制定项目章程、识别干系人。 下节课，我们就把这两件事彻底讲透。 > 好，今天的内容就到这里。谢谢大家，下课！

## 四、板书设计（建议）

黑板分三块，随讲课逐步生成（不要一次写完）：

`` ┌────────────────────┬─────────────────────┬──────────────────────────┐ │ ① 概念区（左） │ ② 对比区（中） │ ③ 框架区（右） │ │ │ │ │ │ 项目：为创造独特的 │ 项目 ∣ 运营 │ 生命周期（时间格子） │ │ 产品/服务/成果而进行 │ 独特 ∣ 重复 │ × │ │ 的临时性工作 │ 临时 ∣ 持续 │ 5 过程组（启规执监收） │ │ │ 实现变化 ∣ 维持现状 │ × │ │ 口诀：目独临约不 │ │ 10 知识领域（整范进成质， │ │ │ 软件项目 3 特点： │ 资沟风采干） │ │ 资产 ∣ 环境 │ 渐进明细 / 学科复杂 / │ × │ │ 自家工具箱∣外面的天气│ 智力密集 │ 8 绩效域 │ │ │ │ │ │ 成败：失败9因（8条是 │ ★过程组≠项目阶段 │ 金句：技术决定能不能做出来，│ │ 管理）∣成功5维 │ （时间格子 vs 动作） │ 管理决定能不能按时按质交出来│ └────────────────────┴─────────────────────┴──────────────────────────┘ ``

## 五、常见学生疑问与应答

> 口播：同学们好，我们开始上课。今天进入《软件项目管理》的第二讲——第 2 章，软件项目启动。 > 上节课我们建立起了整门课的"地图"：什么是项目、什么是软件项目、生命周期、五大过程组、十大知识领域、八大绩效域。从今天起，我们沿着这张地图往前走，走到项目生命周期的第一步：启动。 > 这一章其实只回答四个问题：这个项目该不该干？谁来干？凭什么授权他干？开工之前，大家有没有把话说清楚、把共识立起来？ > 我们还会跟着一个案例走到底——某大型连锁超市的智能库存管理系统。它在启动阶段踩了哪些坑，后面又是怎么一步步"还债"的，今天全部讲透。 > 请把这句话记在笔记本第一行：项目启动是项目的"第一粒扣子"，第一粒扣错了，后面九成的日子都不好过。 > 今天的节奏是：先看案例，再依次讲启动概述、项目立项、项目准备工作、识别干系人、制定项目章程、项目启动大会。

> 口播：今天的课，六块内容排成一条线。 > 01 软件项目启动概述——启动到底包含哪些动作； > 02 项目立项——要不要干？项目建议书、可行性研究、评估与决策； > 03 项目准备工作——谁来当项目经理、用哪种组织结构； > 04 识别干系人——谁影响项目、谁被项目影响； > 05 制定项目章程——启动阶段最正式的一份文档； > 06 项目启动大会——把项目"官宣"给全体相关方。 > 学习目标是四句话：能说明项目启动的全流程；能写出项目建议书与可行性研究的要点；能比较三类组织结构；能识别干系人并制定项目章程。这四条，也正是本章期末要考的四类题。 > 上课之前先回顾 30 秒：项目的五大特征是什么？（停顿）对——目、独、临、约、不：有目标、独特性、临时性、受制约、不确定性。今天我们会反复用到"临时性、独特性、不确定性"这三把尺子。 > 另外提醒一句：今天讲的所有流程都不是纸面文章。启动阶段每少做一步，后面就要多还一次债——案例里我们马上会看到这笔债是怎么还的，而且利息很高。

> 口播：案例背景是这样一家企业：某大型连锁超市。连锁超市的生意，说白了就是"货进得来、卖得掉、别压库、别过期"。 > 它当时头疼三件事，请把这三个痛点记住：第一，库存管理效率低——盘点靠人工、补货靠经验；第二，库存成本上升——钱压在了仓库里，周转不起来；第三，商品过期损耗严重——尤其是生鲜和短保商品，卖不掉就只能报损。 > 这三个痛点其实是一体三面：库存不准，所以补货不准；补货不准，所以不是缺货就是积压；积压久了，就是损耗。要治根，就得让库存算得准、补得快。 > 于是公司决定：全面升级库存管理系统，引入智能预测算法和自动化补货机制，实现库存的精准管理和优化。请注意这两个技术词——智能预测算法、自动化补货机制。今天它们会变成这家公司最大的坑，我们后面会回来算这笔账。 > 接着看它的启动过程。做对的部分：项目团队按标准流程编制了《项目建议书》和《可行性分析报告》，论证了系统的经济效益与社会效益；高层领导迅速决策并批准启动项目。听起来很规范，对不对？流程走了、文件写了、领导批了。 > 但埋下隐患的部分在这里：启动时未充分考虑技术可行性——智能预测算法的准确性要求、数据集成的技术难度、自动化补货机制的技术实现方案，这三样都缺乏深入的分析和调研。 > 我给大家一个生活化类比，帮你们记住这个坑：这就像装修房子，预算做了、风格定了、家里人也点头了，唯独没有确认"承重墙能不能敲、下水改不改得动"。前面的账算得再漂亮，一动锤子就全乱。 > 软件行业里同样的事天天发生：某团队立项做"智能推荐"，商业价值论证了三页纸，却没确认自家推荐算法的冷启动数据够不够，上线后推荐不准，用户反而流失得更快。 > 再补一层背景，帮大家理解为什么"库存"是连锁超市的命脉。连锁超市是典型的薄利多销行业：单件商品毛利不高，靠的是周转速度；而库存恰恰是周转的闸门——压得多，资金就沉淀在仓库里；压得少，又容易缺货、丢单、伤客。所以对这个行业来说，库存管理系统不是"锦上添花的信息化项目"，而是直接影响现金流和客户体验的核心系统。 > 也正因为它重要，公司上下都盼着它快点上、快点见效——而这种"求快"的氛围，恰恰是启动阶段最容易出问题的地方：越是重要的项目，越容易在论证上偷工减料。 > 那么请大家再想一层：公司真正想要的，到底是一套"系统"，还是"库存降下来、损耗降下来"？显然是后者。项目只是手段，业务结果才是目的——这句话在写项目建议书和可行性研究时会反复用到：所有论证都要指向"业务上得到了什么"，而不是"我们上了什么技术"。 > 所以这个案例的第一问就是：可行性报告都写了，为什么还会埋下隐患？ 大家先把这个问号带着，等会儿讲"可行性研究五个维度"时，我们一起把它拆开。

> 口播：项目批准了，接着看后面的发展。先看风险暴露。 > 第一件事，派谁当项目经理：这位项目经理具备网站开发的丰富经验。网站开发是好事，但这家超市的项目涉及跨领域技术整合与多部门协作——智能预测算法、库存数据集成、门店与总部流程改造，这些已经超出了传统网站开发的范畴。结果是：管理风险未充分识别，启动阶段就出现了沟通不畅、决策滞后。 > 第二件事，开发阶段的表现：团队与业务部门沟通出现偏差，对超市实际运营场景与库存管理需求理解不一致；智能预测算法、自动化补货的技术方案研究不足；到了集成测试阶段，遇到较多技术难题与性能瓶颈，项目出现延误。 > 我把这条因果链写在黑板上，请大家顺着看：技术可行性没做深 → 方案带着大量未知进入开发 → 与业务部门需求没对齐 → 集成测试集中爆发 → 工期延误。这不是运气不好，这是启动阶段欠下的账，在中后期一次性偿还。 > 生活化类比：这就像一场接力赛，第一棒交棒时没对准手，后面每一棒都在追着棒跑，越跑越乱。启动阶段没对齐的东西不会自动消失，它只会以"返工"的形式回来。 > 这里我再补一个细节，请大家体会"沟通偏差"到底是怎么产生的。业务部门说的是"这个商品经常缺货，顾客天天抱怨"，这是业务语言；开发团队听到的可能是"需要一个缺货预警功能"，这是功能语言；算法团队心里想的又是"要有足够的历史销量数据才能预测"，这是数据语言。三种语言之间如果没有"翻译"，需求就一定会走样。 > 再打个生活化的比方：这就像点菜——顾客说"来点清淡的"，厨师理解成"少放盐"，端上来一盘水煮青菜；可顾客心里想的是"不要放辣"。谁都没有说谎，结果就是不对。需求对齐的本质，是把不同角色的语言翻译成同一份可验证的描述。 > 课堂互动：现在给大家 3 分钟。四人一组讨论两道思考题，2 分钟后我请一组代表发言。 > Q1：这个项目的启动存在哪些具体问题？ > Q2：针对上述问题，如何有效解决？ > 好，我们一起来归纳。请大家对照黑板右侧的"案例诊断"区。 > 问题有五个：① 技术可行性论证不足——算法准确性、数据集成难度的调研都没做透；② 干系人识别不充分——业务部门的需求没有被对齐；③ 沟通规划缺失——启动时"沟通不畅、决策滞后"就是症状；④ 风险识别缺位——用一个不熟悉该领域的项目经理，又没有识别跨领域整合的风险；⑤ 启动大会"开了但没开透"——团队对目标的理解只停留在表面，实施步骤、任务分配、风险认知都不足。 > 对策对应五条：立项阶段补足技术可行性研究、认真做干系人分析、编制沟通计划、列出风险清单、把启动会做深做实。 > 这五条，就是今天这节课六块内容的主线——我们后面每一块，都是在补这五个坑。

> 口播：好，我们进入第一块：01 软件项目启动概述。 > 这一块只解决一个问题：启动阶段到底要做哪些事，顺序是什么。 这里特别提示一句：启动不是一个"动作"，而是一串有先后的动作——先论证、再决策、再授权、最后对齐。顺序错了，后面全乱。 > 案例里那五个坑，有四个就出在这一块：建议书走了形式、可行性研究空心、决策太快、基础工作没做够。所以这一块是今天的重头戏。 > 再补一句它的"地位"：这一块像整章的总纲——后面五块内容，其实都是这五个环节中的某一步被放大来讲。这一页听懂了，后面听的都是细节；这一页糊了，后面会越听越乱。 > 也请大家记住"概述"这两个字的分量：它不讲细节，只讲顺序和依赖。在项目管理里，顺序本身就是一种专业能力——同样五件事，顺序错了，成本能差出好几倍。

> 口播：软件项目启动是项目生命周期中的第一步，它主要通过一系列活动，为项目的成功执行打下基础。这五个关键环节，请务必背下来，考试必考。 > 第一，项目建议书的编写：明确项目的背景、目标和预期成果，为立项提供依据。它的语气是"我建议做这件事"。 > 第二，可行性研究：分初步和详细两个阶段，评估项目的技术、经济、资源可行性，确保项目具备实施条件。它回答的是"这件事能不能干成"。 > 第三，项目评估与决策：基于可行性研究结果对项目进行全面评估，最终决定是否立项。它回答"干不干、批不批"。 > 第四，立项后基础工作：制定项目章程、指派项目经理、识别干系人——明确项目目标、范围和资源分配。它回答"谁来干、怎么干、凭什么叫得动人"。 > 第五，启动大会收尾：与团队和干系人就目标、需求、时间安排达成一致，为项目推进奠定基础。它回答"大家认不认"。 > 一句话记忆：建议书（想干什么）→ 可研（能不能干）→ 决策（干不干）→ 基础工作（谁来干、怎么干）→ 启动会（大家一起认）。 我把这五个环节再压缩成五个动词：提 → 证 → 批 → 备 → 认。 > 为什么顺序不能颠倒？因为每一步都在给下一步提供依据。跳过可研直接决策，决策就没有依据；跳过基础工作直接开工，团队就没有授权、没有边界。这也正是案例里"高层迅速批准"的问题所在——快不是错，"没有依据的快"才是错。 > 生活化类比：这五步就像去医院看病。先挂号说症状（建议书），再抽血拍片（可研），医生看报告下结论（评估决策），然后定主治医生、安排床位（基础工作），最后把病情、治疗方案和注意事项跟家属讲清楚（启动会）。跳过拍片直接开刀，谁都不敢。 > 软件行业实例：一家公司要做"双十一大促临时优惠系统"，同样是先写立项说明，再做技术可行性确认（现有优惠引擎能不能撑住峰值），然后评审决策，再指派项目经理、识别运营与财务干系人，最后开启动会把上线窗口和回滚方案讲清楚。 > 回到案例：超市项目的五个环节表面都走了——建议书写了、可研报告编了、高层批了、人也派了、会也开了。但它踩的坑是：第二个环节"可研"空心，第四个环节"基础工作"里派了一位跨领域的项目经理，第五个环节"启动会"没开透。 请记住这个结论：启动流程"走完"不等于"走实"。 > 最后再给一个实务提醒：这五个环节之间是输入输出的关系——建议书是初步可行性研究的输入，可研报告是评估决策的输入，立项文件是制定章程的输入，章程又是启动会的依据。你只要顺着这条"文件流"去记，整条链子就不会乱。

> 【思政落点 1】 这里我要特别强调"程序"二字。为什么启动要一步一步走流程、留文档、做评估？不是为了增加手续，而是因为程序是最可靠的"防错机制"。现实中很多项目出问题，追根溯源就是"该走的程序没走、该论证的没论证、该签字的人没签字"。对将来做软件的你们来说，依法合规、按程序办事，既是保护项目，也是保护自己——合规不是束缚，是护栏。

> 口播：第二块：02 项目立项。 > 立项回答一个问题：这个项目到底该不该干？ 它包含四个阶段：立项申请、初步可行性研究、详细可行性研究、评估与决策。 > 请特别注意它的定位：立项是项目启动前的关键环节，它决定项目能不能正式进入实施阶段，也直接决定后面的章程怎么定、团队怎么建、资源怎么分。换句话说，立项是整个项目的地基。 > 案例里"高层迅速决策并批准启动"，就是这一步走得太快。下面我们一层层把它拆开看，先看四个阶段。 > 顺便说一句：立项做得好，还有一个容易被忽视的好处——它让"不干"这个决定变得容易。敢于在立项阶段否掉一个不靠谱的项目，本身就是项目管理能力的体现，因为在这一步停下来的成本最低。

> 口播：项目立项是项目启动前的关键环节，它决定了项目是否能够正式进入实施阶段，也为后续的项目章程制定、团队组建、资源分配等环节提供基础。这句话里有两个信息：一是"前置"，二是"打基础"。 > 立项管理分四个阶段，请按顺序记牢： > ① 项目建议与立项申请——把想法写成文件，正式提出"我想干这件事"； > ② 初步可行性研究——先粗筛一遍，看看值不值得花更多的钱和时间去做深入研究； > ③ 详细可行性研究——全面深入论证技术方案、市场、投资、风险，为项目决策提供详实依据； > ④ 项目评估与决策——由第三方评估，拍板定案。 > 这里有一个非常重要的例外：小型项目可以合并初步可行性研究和详细可行性研究阶段，但详细可行性研究不可或缺。为什么？因为详研是决策的唯一依据，省掉详研，评估和决策就成了无源之水。 > 生活化类比：这四步很像买房。先在脑子里种草（建议申请），再上网看看这个小区大概什么价位、有没有明显硬伤（初研），然后实地看房、查产权、算月供、问学区、看物业（详研），最后请评估机构估价、自己签字成交（评估决策）。前两步花的是时间和心思，第三步花的是真金白银——所以顺序上一定是先初研、再详研，不能一上来就请评估机构。 > 软件行业实例：一家银行要上线"智能客服"，先写立项申请；初研阶段发现现有语料严重不足，果断暂停，只损失了两周调研时间；另一个项目初研顺利，详研阶段测出高峰期并发撑不住，于是调整了技术方案和采购预算——花在可研上的时间，都是在替开发阶段省钱。 > 回扣案例：超市项目"高层迅速决策并批准启动"——快是好事，但如果技术可行性这一步没有做扎实，快就等于把风险往后推。今天省下的两周调研，后面要用几个月的返工来还，还要搭上团队士气和客户信任。

> 口播：项目建议书是项目建设单位向上级主管部门提交的关键文件。 它依据什么来写？课件列得很清楚：国民经济趋势、国家及地方规划、产业政策、市场需求、项目所在地条件，以及本单位的战略。请注意，这些依据都不是"我们内部想不想"，而是外部大势＋自身战略的结合——立项不能脱离大环境。 > 它的核心内容有四块，请大家记牢： > ① 项目背景和必要性——项目为什么开展，要解决什么问题； > ② 市场分析与预测——市场现状是什么，未来趋势怎么走； > ③ 预期成果与市场定位——产出什么东西，面向哪一类市场群体； > ④ 实施所需必要条件——需要哪些资源、技术、资金。 > 我把这四块压缩成一句口诀：为什么做（背景与必要性）、做给谁（市场与定位）、做什么（预期成果）、靠什么做（必要条件）。 > 特别要强调它的定位：建议书是"申请"，语气是"我建议做这件事"，它不等于批准。批准的依据，是接下来的可行性研究。很多同学写建议书时写成"我们已经决定要做"，这是越权——建议书没有决策权，只有建议权。 > 生活化类比：项目建议书就像求职时的自荐信——你说"我适合这个岗位、我能带来什么"，但录不录用，得看后面的笔试面试（可研）和 HR 评审（评估决策）。自荐信写得再漂亮，也不能自己给自己发 offer。 > 软件行业实例：一家公司要给政务客户做"一网通办"平台，建议书里必须写清政策依据、市场与客户需求、预期交付成果，以及必需的资质与数据条件——少写"资质条件"这一条，后面投标就会被卡住。 > 回扣案例：超市项目的建议书按流程编制了，但从案例后面暴露的问题看，它对"实施所需必要条件"里的技术条件写得太轻——智能预测算法的准确性要求、数据集成的难度，都只停留在设想，没有作为"必要条件"被认真评估。这就提醒我们：建议书的第四块不是凑数的，它是后面可行性研究的靶子。

> 口播：可行性研究要回答的不是"想不想干"，而是"能不能干成"。它从五个维度展开，请大家对照屏幕上的表格，一条一条看： > > | 维度 | 核心要点 | > |---|---| > | 技术可行性 | 现有技术能否支持项目目标，并在规定时间内完成。例：当前技术水平下开发特定功能的可能性 | > | 经济可行性 | 成本效益核算：项目支出、收益、投资回报期、敏感性分析 | > | 社会效益可行性 | 对组织内部（品牌形象、竞争力）与社会（就业、环保）的影响 | > | 运行环境可行性 | 用户管理体制、人员素质、数据资源等运行环境是否适配。例：员工操作能力能否满足新系统要求 | > | 其他可行性 | 法律可行性（是否合法合规）、政策可行性（是否契合政策导向） | > > 五个维度，我给大家一个记忆抓手——"能不能、划不划算、顺不顺、合不合法、还有没有别的"：技术＝能不能做得出来；经济＝划不划算；社会效益＝对组织内外有没有正面影响；运行环境＝用起来顺不顺（人、制度、数据跟不跟得上）；其他（法律与政策）＝合不合规。 > 判断方法上要有一个"顺序感"：技术可行性是入场券——技术上做不到，后面算得再漂亮都是零；法律可行性是一票否决——不合规，利润再高也不能干；经济可行性是决策核心——老板最终看的是划不划算；运行环境可行性最容易被忽视——系统再好，员工不会用、数据喂不进去，一样白搭。 > 生活化类比：这五问跟你买车几乎一模一样——这车在我这边的路况能不能开（技术）、养得起养不起（经济）、家人坐着舒不舒服、开出去有没有面子（社会效益）、我媳妇会不会开、车位够不够（运行环境）、能不能上牌、限不限行（法律与政策）。少问一条，都可能买回来一辆"停不了的神车"。 > 软件行业实例：一个团队做"人脸识别门禁"，技术上成熟、经济上也便宜，但它涉及个人信息采集——法律与政策可行性直接决定了这件事能不能落地；如果部署在学校，还要考虑宿管人员会不会操作、闸机数据能不能接入现有系统，这就是运行环境可行性。 > 回到案例：超市项目倒在哪儿？技术可行性——智能预测算法的准确性要求、数据集成的难度、自动化补货的实现方案，都没有深入论证。请记住这句话：一份"看起来齐全"的可行性报告，如果关键维度是空心的，它就是一张通行证，而不是一张保险单。 > > 【思政落点 2】 做可行性研究，最忌讳"为了通过而论证"。数据挑好看的用、风险一句带过、测算只算乐观情形——报告是漂亮了，但坑的是团队、是公司，最后是用户。实事求是、数据说话、不回避风险，这是专业精神，也是职业诚信。 请记住：可研报告上的每一个数字，将来都要有人为它负责。 > > 课堂练习（1 分钟）：请快速判断，下面哪一项属于经济可行性？ > A．新系统上线后员工能否熟练操作　B．投资回报期是否可接受　C．是否符合《数据安全法》　D．现有技术能否实现毫秒级响应 > 答案：B。 A 属运行环境可行性，C 属法律可行性（归入"其他"），D 属技术可行性。做错的同学，请把五个维度再默念一遍。

> 口播：可行性研究分两个阶段，请大家分清它们的"分工"。 > ① 初步可行性研究：初步评估项目的必要性、周期、资源等，核心目的是——判断这个项目值不值得投入更多资源去做深入研究。说白了，它是"粗筛"，防止你在一个明显不靠谱的想法上继续砸钱。 > ② 详细可行性研究：全面深入分析技术方案、市场、投资、风险等，为项目决策提供详实依据。它是"细算"，是决策的直接来源。 > 两者的关系很像招聘：初研是简历筛选，详研是面试＋背景调查。简历阶段发现不对口，就不用浪费面试官的时间；但真正决定录不录用的，是面试和背调。 > 再看详细可行性研究报告的结构（表 2-2），请对照屏幕，把几个关键块记下来： > > | 目录项 | 主要内容 | > |---|---| > | 项目背景 | 项目名称、承担单位、主管部门、客户、可行性研究依据等 | > | 可行性研究结论 | 项目目标、规模、技术方案、进度计划、投资估算、财务评价等 | > | 技术背景 / 发展现状 | 国家、地区、行业规划与客户需求；国内外技术历史、现状与趋势 | > | 市场调查分析 | 产品用途、市场调研、开发环境、市场预测等 | > | 客户现行系统情况 | 客户资源、现行系统功能与需求调查 | > | 项目总体目标 | 项目目标、技术方案、核心问题分析等 | > | 实施进度计划 | 阶段划分、进度安排、项目里程碑等 | > | 投资估算 | 总投资、资金筹措方案、投资使用计划等 | > | 项目组人员组成 | 组织方式、人员构成、培训计划等 | > | 项目风险 | 关键技术风险、需求不确定性、其他风险 | > | 经济效益 / 社会效益 | 经济效益预测；社会效益分析与评价 | > | 结论 / 附件 | 可行性研究结论与立项建议；相关文件、图表、调查数据 | > > 怎么用这张表？ 它就是一份"可研报告目录模板"。将来你写可研，照这个目录一项一项填，就不会漏项。特别注意两块——项目风险和社会效益：它们是同学们写可研时最容易漏的，而恰恰是评审专家最爱问的。 > 记忆抓手：把这张表想成一条线——从哪来（项目背景与技术现状）→ 给谁用（市场与客户现状）→ 做多大（目标与进度）→ 花多少（投资估算）→ 谁来做（人员组成）→ 有啥险（项目风险）→ 值不值（经济与社会效益）→ 结论附件。八步顺着走，报告的骨架就立起来了。 > 回扣案例：如果当年超市项目按这张表认认真真填过一遍，"项目风险"那一栏里就会写下"智能预测算法的准确性尚未验证""与现有收银和仓储系统的集成难度未知"。决策层在批准的时候，就会多问一句。表格不是形式，它是把"没想到"变成"写下来"的强制动作。

> 口播：可行性研究做完了，谁说了算？三个要点。 > 第一，项目评估：由第三方依据国家政策、法规、行业标准等，从国民经济、社会影响、组织业务三个角度全面评估项目的可行性，最终输出《项目评估报告》。 > 第二，报告内容包括三块：项目概况——基本情况加上综合评估结论，比如是否批准项目、是否建议贷款这样明确的意见；详细评估意见——对技术可行性、经济可行性、市场需求等做细致的分析阐述；总结与建议——点明重大问题和潜在风险，提出针对性的改进措施。 > 第三，决策：基于评估结果，决定项目是否立项。 > 这一页的关键词只有三个字——"第三方"。为什么必须第三方？因为申报方和评估方不能是同一方，否则就是"自己给自己打分"。你既当运动员又当裁判，这场比赛还有意义吗？ > 生活化类比：贷款买房的时候，银行不会只听你说"我这房子值五百万"，它会派自己的评估师上门估值，也可能请第三方评估机构出具报告——这就是为了防范"报高价、多贷款"的道德风险。项目评估引入独立第三方，起的是同一个作用。 > 软件行业实例：政府信息化项目在立项前，通常要经过专家评审或第三方咨询机构评估，从合规性、技术路线、投资合理性等角度出具意见。这也解释了为什么有的项目"申报材料很厚，但被评审专家问三句就露馅"——因为评估看的不是你的排版，看的是你的论证。 > 回到案例：超市项目"高层领导迅速决策并批准启动"，看上去效率很高。但如果评估环节只是"内部过一下"，技术上的空洞就没有人替决策层把关。评估与决策的价值不在快，而在于"有人替你把不该批的项目挡下来"。 > > 【思政落点 3】 这一页的思政点非常硬核：依法合规、客观公正、独立评审。国家政策、法规、行业标准是评估的依据，这意味着立项不是"领导拍脑袋"，而是在制度和法律框架内做决策。将来你们走上工作岗位，可能会遇到"先把项目立了、手续后补"的诱惑。请记住今天这句话：程序合规是底线，科学决策是能力，独立客观是品格——既当运动员又当裁判，赢的是一时，输的是整个职业信誉。

> 口播：第三块：03 项目准备工作。 > 项目批准了，接下来两件事最关键：选对人、搭对架子。"选对人"就是指派项目经理；"搭对架子"就是选择组织结构——职能型、项目型，还是矩阵型。 > 为什么这两件事属于"准备"而不属于"执行"？因为它们决定了项目的权力结构：谁能拍板、谁向谁汇报、资源怎么调。这些定不下来，项目一开工就会在"到底听谁的"上面消耗时间。 > 提醒一句：这两件事都属于"任命与授权"的范畴，一旦宣布就很难悄悄改回来——准备阶段多花一天，执行阶段少吵一周。 > 案例里的第一个大坑——派了一位只有网站开发经验的项目经理，就出在这一块。

> 口播：项目经理是"派"出来的还是"选"出来的？我们先看来源，它一共两条道。 > 一是内部选拔——具体方式有部门推荐、PMO 指派、高层指定、人才计划选拔。它的优势是：熟悉组织文化与流程，有内部工作经验，知道谁能配合、哪道手续该找谁。 > 二是外部招聘——方式有公开招聘、猎头服务、合同聘用、伙伴推荐。它适用于需要特定领域经验或高技术要求的项目，比如公司第一次做人工智能项目，内部没人干过，就只能到外部去找。 > 生活化类比：内部选拔像球队从青训队提拔，懂战术、磨合快；外部招聘像转会引进外援，能力强、但需要一段适应期。两种都不是万能药，关键看项目的需要。 > 第二，项目经理的能力，四项：① 项目管理技能；② 战略与商务技能；③ 领导力；④ 技术能力。 请注意这个顺序——技术能力排在最后。这说明一个很重要的判断：项目经理不是"技术最强的人"，而是"最能带成事的人"。 技术最强的人去做项目经理，常常忍不住自己上手写代码，反而耽误了协调、决策和争取资源。 > 第三，项目经理的职责，七项：项目规划与目标设定、团队建设与管理、进度／资源／预算管理、沟通与协调、风险与质量管理、问题解决与决策支持、项目交付与收尾。从"定目标"到"交付收尾"，一头一尾，全生命周期都得管。 > 第四，项目经理的权力类型，有两种分法：按管理职责分——决策权、组织权、指挥权、人事权、经济权；按来源和作用分——职位权力、奖赏权力、惩罚权力、专家权力、参照权力。 > 这里有一个特别值得记的点：职位权力、奖赏权力、惩罚权力是"组织给的"；而专家权力（你的专业让人服气）和参照权力（你的人格魅力让人愿意跟）是"自己挣的"。 一个好的项目经理，靠后两种的时候更多——因为前者只能让人"服从"，后者才能让人"跟随"。 > 软件行业实例：互联网公司常设"技术负责人＋项目经理"双岗，讲的就是这个道理——技术负责人负责"做得对"，项目经理负责"做得成、按时交、大家还愿意跟着干"。 > 回扣案例：超市项目派了一位"网站开发经验丰富"的经理，去管一个"跨领域技术整合＋多部门协作"的项目——这是典型的"人岗不匹配"。启示很明确：选项目经理，要先看项目特征（跨领域吗？多部门吗？高风险吗？），再看人的能力组合，不能只看他过去做得多好。

> 口播：我们先给职能型组织结构下一个定义——它是按照专业职能来划分部门的组织：财务部、人力资源部、市场部、技术部，各管一摊，每个部门负责自己领域的业务。 > 这种结构最像什么？最像一所大学：教务处、学工处、财务处、各个二级学院，各管一段；也像一家医院，内科、外科、放射科、检验科，各有各的专业领地。放到软件公司里，就是技术部、测试部、实施部、运维部这么排。 > 那么项目来了怎么办？通常是从技术部抽三个开发、测试部抽一个测试，临时拼一个项目组，项目经理往往由某个部门的经理兼任。注意了，这就是职能型的要害——项目经理是"借人干活"，人还是部门的。 > 它的优点有三条。第一，人员配置灵活，技术专家可以同时为多个项目提供支持——同一位数据库专家，上午帮 A 项目，下午帮 B 项目，人力不浪费。第二，部门内都是同行，交流方便，技术问题容易解决——前端和后端坐在一起，喊一声就能问。第三，技术连续性好，员工有清晰的晋升路径——从初级工程师到技术专家，这条路是看得见的。 > 但它的缺点同样致命。第一，项目支持不足、责任分散。为什么？因为部门经理关心的是本部门的活儿，项目只是"顺手帮个忙"，一旦部门自己的任务紧张，项目就排到后面去了。第二，跨部门沟通困难，容易忽视项目整体目标——各部门守着自己的考核指标，没有人对"这个项目能不能按期交付"负总责。第三，项目人员积极性较低、缺乏归属感，因为他的考核、加薪、晋升都在部门手里，不在项目手里。 > 那什么时候适合用职能型？给大家一个判断：业务稳定、项目小、以技术分工为主的组织。比如一家 20 人的小软件公司，常年做同一类外包项目，谁擅长什么一目了然，由一位部门经理带着就干完了，没必要给每个项目单独搭班子、单独核算。 > 但要特别注意：职能型最容易出事的时刻，就是跨部门协作变多的时候。 一个项目一旦牵涉三个以上部门、还要对外承诺交付日期，职能型就开始"推不动"，这时候就该考虑换结构了。 > 用一句话记住它：职能型，部门说了算；项目经理权力最小，通常只挂一个协调员或联络员的头衔——只能"沟通"，不能"命令"。

> 口播：再看另一个极端：项目型组织结构。定义是——以项目为核心，项目经理全权负责项目，拥有调动资源的权力。它不再是"借人干活"，而是"连人带资源一起划给项目"。 > 生活里的类比是剧组：拍一部电影，导演、摄影、灯光、服化道全部为这部戏服务，戏拍完，剧组解散，人各回各家。装修队也一样，从进场到交钥匙，整队人都听工长的。 > 软件行业的实例：某公司要集中 80 人攻关一个为期两年的核心系统，怎么做？成立独立的项目部，开发、测试、需求、实施，甚至财务和采购的支持人员都进项目组，项目经理有自己的人事权、预算权和考核权，直接向公司高层汇报。这就是典型的项目型。 > 优点两条，都很硬。第一，项目经理能快速决策，项目组聚焦单一目标，进度、成本和质量能灵活控制——因为不用层层请示，也不用跟别的部门抢人。第二，每个成员只有一个领导，避免多重领导带来的冲突，沟通顺畅、责任清楚。 > 缺点也是两条。第一，项目组独占资源，项目之间共享不足。一个项目养一批人，项目结束前这批人不能被别的项目用；公司同时开三个项目，就要养三套测试班子，成本高，闲时浪费。第二，项目经理与成员之间的依赖性强，跨部门沟通困难；项目一旦结束，成员很难回到原来的部门，归属感受影响，职业发展路径也容易断。 > 再回扣一下我们的案例：如果超市的智能库存系统当初就成立一个独立项目部，由项目经理全权负责，开发、测试、业务分析、实施人员全部进组，直接向高层汇报——那么"技术方案研究不足""多部门协作扯皮"这两个坑，至少有一个会被提前暴露出来，因为没有人能再把责任推给"那不是我们部门的事"。 > 当然反过来看，如果只是日常的小修小补也用项目型，那就等于大炮打蚊子：人配齐了、架子搭起来了，活却只有那么一点，成本全浪费在等待和沉没上。 > 一句话记住：项目型，经理说了算；PM 权力最大，人、钱、事一把抓。

> 口播：第三种是矩阵型组织结构。定义是——它把职能型和项目型的特点结合起来：员工同时隶属职能部门和项目团队，项目经理与职能经理共享管理权，资源调度更高效，也促进了跨部门合作。 > 生活类比：大学生既是某个班的学生，又是校篮球队的队员——辅导员管你的学业，教练管你的训练，两边都是你的领导。工作里也一样：你的人坐在技术部，但你同时在为 A 项目干活，可能还要支持 B 项目。 > 软件行业实例：一家高科技企业同时推进 6 个客户项目，就需要复用各部门的算法专家——每位专家横向上参加一到两个项目，纵向上仍然归算法部管理。这就是矩阵型。 > 优点三条：充分利用各部门的技术、人才和设备；促进成员学习与知识交流；提升对客户需求的关注。 > 这里我要重点讲它的管理难点，也是本章的难点之一：两个领导、责权必须划清。 一个员工的绩效考核、请假、培训归职能经理；任务优先级、交付节点归项目经理。两人一冲突，员工就"两头挨骂"。所以矩阵型要真正跑起来，必须先把三件事写清楚：谁定优先级、谁考核、争议由谁裁决。这三件事不清，矩阵型就会从"高效复用"变成"互相甩锅"。 > 互动：三个场景，请判断更适合哪种组织结构。① 一家 20 人的小软件公司，常年做同一类外包项目；② 某公司要集中 80 人攻关一个为期两年的核心系统；③ 一家高科技企业同时推进 6 个客户项目，需要复用各部门的算法专家。 > 参考答案：① 职能型——项目小、业务稳定，靠部门分工最省成本；② 项目型——要集中力量打硬仗，PM 必须有权；③ 矩阵型——多项目并行，又要复用专家。 > 这里再补一句实务体会：矩阵型是三种结构里对管理成熟度要求最高的一种。它要求公司有清晰的考核制度、有能拍板的上级、有畅通的争议裁决通道。很多公司学矩阵型，只学到了"两套汇报线"，没学到"责权先划清"，结果就是员工双倍汇报、项目双倍扯皮。 > 回到案例：超市项目之所以在启动阶段就出现"沟通不畅、决策滞后"，本质上就是没有一个明确规则来回答"这件事谁说了算"。组织结构选对了，还得把规则立起来。 > 一句话记住：矩阵型，两个领导说了算；资源用得最省，但责权划不清就会乱。

> 口播：第三个板块讲完了，我们把目光从"结构"转到"人"。项目启动阶段有一门功课，看起来最不技术，却最容易让项目翻车——识别干系人。 > 什么叫干系人？一句话：所有能影响项目、或者会被项目影响的组织和个人。请注意这句话有两个方向：一是"他能影响项目"——客户、领导、监管机构；二是"项目会影响他"——门店店长、收银员、供应商的送货司机。 > 为什么单独给它一页？因为这是启动阶段唯一一项"人"的功课，也是最容易漏项的功课：漏掉一个关键干系人，后面要多付十倍的沟通成本。 > 下一页我们把干系人分成内部 5 类、外部 5 类，逐类看清楚。 > 说得再直白一点：这一页不是在教你填表格，而是在教你做事之前先想明白——这件事会动到谁的奶酪，谁又会来动你的进度。

> 口播：先把定义钉死：项目干系人，是所有能影响项目、或受项目影响的组织和个人——内部外部都算，主动参与的算，被动关联的也算。 > 请看这张表，左半是内部 5 类，右半是外部 5 类。我们逐类过一遍，每一类都问三个问题：他是谁？他关心什么？漏掉他会怎样？ > 内部第一类，发起人——通常是 CEO 或分管副总这样的高层领导，项目的发起者和出钱人；他关心项目值不值得做、跟公司战略合不合；漏掉他，你连资源都批不下来，出了事也没人替你说话。 > 第二类，项目经理——项目的整体管理者与推进者；关心目标、进度、成本、风险；这一条不用多说，漏掉他项目就没人为结果负责。 > 第三类，团队成员——真正写代码、做测试、写文档的人；关心自己干什么、标准是什么、有没有成长；漏掉他，任务落到谁头上都说不清，进度只能靠猜。 > 第四类，职能经理——在职能型和矩阵型组织里掌握人力与资源的人；关心本部门的负荷和人员发展；漏掉他，你借不到人，借到了也可能随时被抽走。 > 第五类，PMO——项目管理办公室，提供支持、规范流程；关心项目的合规性和报告口径；漏掉它，你在流程、模板上会反复返工。 > 外部第一类，客户——提出需求、验收成果的一方；关心功能能不能用、值不值这个价；漏掉他，验收时一句"这不是我要的"就能让你返工重做。 > 第二类，最终用户——每天真正使用系统的人，往往就是门店店长、收银员、库管员；关心好不好用、会不会增加工作量；漏掉他们，系统做得再漂亮也没人用。 > 第三类，供应商——提供硬件、软件、技术或服务的一方；关心合同、付款和自己的交付节奏；漏掉他，设备到不了位，你的进度表就是一张废纸。 > 第四类，监管机构——负责合规审查的部门；关心数据安全、隐私和行业规范；漏掉他，验收阶段可能被一票否决。 > 第五类，股东——项目的投资方；关心投入产出和风险敞口，他要的是"这笔钱花得值不值"。 > 现在把这张表回扣到我们的超市案例：业务部门、门店运营这些人，就属于最终用户（在集团口径下也可视为内部业务方）。他们恰恰没有被充分识别和参与，结果开发团队"对超市实际运营场景和库存管理需求理解不一致"，到集成测试阶段才暴露问题，直接造成返工和项目延误。漏掉一个关键干系人，后面要多付十倍的沟通成本——这句话不是修辞。 > 课堂练习：校园二手交易平台项目里，"学校信息安全主管部门"属于哪类干系人？核心诉求是什么？参考：属于监管类干系人（校内则为内部监管）；诉求是合规与数据安全。这类干系人的特点是——平时不出现，验收时一票否决，必须提前纳入。

> 口播：干系人认全了，接下来是启动阶段最正式的一件事：制定项目章程。 > 前面所有的活——建议书、可行性研究、评估与决策、选项目经理、定组织结构、识别干系人——都还是在"准备"；而章程，是把这些准备的成果写成一份有约束力的正式文件，报批、签署、生效。 > 有一句话请先记住：项目章程一旦被批准，就标志着项目的正式启动。 > 它回答的是四个问题：凭什么是这个项目？凭什么由你来管？你有多大权？什么时候算干完？下一页先讲它的定义和四大作用。 > 这里还要把两个概念分开：章程和合同不是一回事。 对内部项目，章程相当于公司给自己发的"开工令"；对外部客户项目，章程是在合同框架内制定的，二者不能打架。

> 口播：先给定义，请大家跟着我抠关键词。项目章程是项目启动阶段的一份正式文档，它全面记录三样东西——商业需求、项目论证、以及对顾客需求的理解；它明确新产品、服务或成果的交付目标；它的目的是确保干系人在三件事上达成共识：主要可交付成果、关键里程碑、项目参与者的角色与职责。 > 拆开看三层：第一，它是"正式文档"，不是会议纪要，更不是口头承诺；第二，它记录的是"为什么做"（商业需求、项目论证）和"顾客要什么"，而不是"具体怎么做"；第三，它管的是共识——可交付成果、里程碑、角色职责。 > 生活化类比：章程有点像聘书加驾照。聘书告诉你：你被任命为这个项目的负责人，你有这些权限；驾照告诉你：你能开哪一类车、上路的边界在哪里。没有这两样就上路，那叫无证驾驶。 > 软件行业实例：在智能库存系统项目里，章程会写明——项目目的（降低库存资金占用与商品过期损耗）、可测量的目标、总体里程碑进度计划（具体日期以签署文本为准）、项目经理及其职权、预先批准的财务资源，以及谁有权批准。写清楚了，后面跟门店、采购、IT 各部门打交道，都是"照章办事"。 > 四大作用，请记牢：① 任命项目经理并明确其权责；② 赋予项目合法地位——让这个项目在公司里有"名分"，别人必须配合；③ 设定项目的总体目标；④ 明确项目与组织战略目标之间的直接关联——说白了，就是让所有人知道"我们干这件事，是为了公司的那件大事"。 > 为什么"批准即启动"这四个字这么重要？因为从这一刻起，项目花的每一分钱、占用的每一份人力，才算有了正式出处；后面的范围、进度、成本、风险计划，才有立足点。反过来说，章程迟迟不批就大干快上，那叫无授权施工——做得越多，风险越大。 > 再补一个同学常问的问题：章程批了以后还能改吗？答案是——重大变更需要经过发起人或批准人同意，并走变更流程；章程本身不做日常修改。 日常调整写进项目管理计划，不要动不动就去改章程。 > 再用一句话收口：章程既是"授权书"——给你调人调钱的权力；也是"责任书"——目标、边界、里程碑、审批要求都白纸黑字写在那里，干不成是要交代的。

> 口播：制定章程不是拍脑袋写作文，它有四类依据，缺一样都会写歪。我们一类一类看。 > 第一类，立项管理文件。 它包含商业需求、成本效益分析等内容，是前面立项、可行性研究、评估决策留下的成果，为决策提供依据。这里有个考点请注意：项目经理无权直接修改立项管理文件，但可以提出调整建议。 为什么？因为它是上级或评审机构批准过的文件，改它就等于改决策依据，必须走流程、留痕迹。 > 第二类，合同。 如果项目是替外部客户做的，合同就是法律框架：目标、范围、交付要求、付款条款都在里面。章程的很多内容，其实就是把合同语言翻译成项目语言。还要注意一条——章程不能与合同冲突，合同优先。 > 第三类，事业环境因素。 分内外两部分：内部包括组织文化、组织结构、设施、IT 工具、资源可用性、员工能力；外部包括市场、法律法规、行业标准、财务环境。举我们案例里的例子：门店网络条件差、收银员对电脑操作不熟练，这些都属于内部环境因素，会直接影响界面设计和培训方案——你在章程里写目标的时候，就得把它们考虑进去。 > 第四类，组织过程资产。 包括标准化政策、流程、程序，监督与报告机制，模板（比如公司统一的项目章程模板），以及历史数据与经验教训库。这类东西的最大价值是四个字：别重新发明轮子。上一轮项目踩过的坑，已经写成经验教训了，你照着改、照着避就行。 > 讲完四类依据，有两个提醒必须说。第一，项目章程是连接项目执行与需求的纽带，它要确保项目既符合组织战略目标，又能和日常运营衔接。第二，应尽早任命项目经理，最好在制定章程的时候就确认——因为章程批准之后，项目经理才获得调配资源的正式权力。太晚任命，等于开局就慢半拍。 > 最后呼应一下上节课：第三、第四类依据，就是第 1 章讲过的"事业环境因素"和"组织过程资产"——同一个概念，到启动阶段就要真正用起来，而不是停在名词解释上。 > 再补一句总结：这四类依据里，前两类管"该做什么"，后两类管"能怎么做"，一条一条对齐，章程才不会写成空中楼阁。

> 口播：有了依据，接下来用什么方法把章程写出来？五种，请先记口诀：专家、脑暴、焦点、访谈、人际技能。 > ① 专家判断：请具备领域专业知识、经验和技能的个人或小组，基于对项目的深入理解给出判断。举个例子：智能库存系统里"预测算法的准确率目标定到多少才合理"，就该去问做过零售预测的专家，而不是坐在会议室里拍脑袋。 > ② 头脑风暴：团队协作的创意生成方法，集思广益，短时间内产生大量想法和解决方案。它的规矩是——先求量、不批判，把话都说出来。 > ③ 焦点小组：结构化讨论，由有相关背景的人组成，围绕目标、需求、风险、成功标准收集深度意见。放到案例里，就是把总部采购、门店店长、IT 运维请到一张桌上，专门谈"这个项目做成什么样才算成功"。 > ④ 访谈：与干系人或专家一对一沟通，收集高层级需求、假设条件、制约因素、审批标准等关键信息。一对一的好处是：有些话，人在大会上不会说，在办公室里才会说。 > ⑤ 人际关系与团队技能：通过冲突管理、引导等技巧，确保章程实际可行、各方需求都被考虑。举个具体冲突：门店希望"操作越简单越好"，IT 希望"数据实时同步"，两个诉求天然打架，这时候就需要有人把双方拉回到一个可执行的平衡点上。 > 生活化类比：这五种方法很像装修前的准备——找老师傅看房屋结构（专家判断）、一家人随口说想要什么（头脑风暴）、拉上设计师坐下来定风格（焦点小组）、单独问问老人用起来方不方便（访谈）、最后靠嘴皮子把争执拉回一个方案（人际技能）。 > 给一个判断抓手，方便你考试时对号入座：问"经验"用专家判断，问"数量"用头脑风暴，问"深度共识"用焦点小组，问"敏感信息"用访谈，问"矛盾"用冲突管理与引导技巧。 > 最后提示一句：这五种方法在后面范围、进度、风险各章还会反复出现，它们是项目管理的"通用工具箱"，今天先混个脸熟。

> 口播：制定章程的结果有两样东西：一份项目章程，和一本假设日志。 > 先说章程的 11 项核心内容。我按"为什么做、做成什么样、有什么风险、花多少钱、谁来管"这条主线把它串起来，你不用死记顺序，但要能一条一条数出来。 > 先说"为什么做"：① 项目目的；③ 高层级需求与描述。再说"做成什么样"：② 可测量的项目目标和成功标准；⑤ 总体里程碑进度计划；⑨ 项目退出标准。接着说"有什么风险、要满足什么条件"：④ 整体项目风险；⑧ 项目审批要求。最后是"花多少钱、谁来管"：⑥ 预先批准的财务资源；⑦ 关键项目干系人名单；⑩ 项目经理及其职责和职权；⑪ 发起人或其他批准人员信息。 > 我们数一遍：一二三四五六七八九十、十一——11 条，一条不少。 > 请注意这里的关键词："高层级"和"总体"。章程只写"总体里程碑进度计划"，不写"第 3 周完成数据库详细设计"；只写"预先批准的财务资源"，不写每一项采购的报价。章程要高层级，不写细活。 > 第二样产出是假设日志，用来记录项目生命周期中的假设条件和制约因素——比如"预算上限是多少""交付周期不能超过多久""假设门店网络改造后能支持数据实时同步"。为什么要单独记一本？因为假设一旦不成立，计划就得重做，它是最早、最便宜的风险识别机会。 > 顺带说一句：章程的这些内容，不是给项目经理一个人看的——发起人看的是目的和目标，团队成员看的是里程碑和职责，财务看的是预先批准的预算。同一份文件，不同的人各取所需，这就是它必须写清楚的原因。 > 章程写完怎么自检？我给大家准备了自检五问，请跟我一起念一遍：目的清不清？目标能不能量？风险列没列？里程碑有没有？谁批谁管写没写？ 这五问全答得上来，章程基本就站得住。 > 课堂练习：请判断下列内容是否属于项目章程。A．"本项目须在 2027 年 6 月 30 日前上线"；B．"第 3 周完成数据库详细设计"；C．"项目经理有权调配 5 人以内开发资源"；D．"采用 Vue 3 ＋ Spring Boot 技术栈"。 > 答案：A 属于——它是总体里程碑进度计划；C 属于——它是项目经理及其职责和职权；B 不属于——它是详细的进度计划，属于后续的项目管理计划；D 不属于——它是技术方案，通常写在技术文档或项目管理计划里。请记住这句话：章程管授权和边界，不写细活。

> 口播：最后一块内容：项目启动大会。前面所有工作都是"先把事想清楚"，启动大会是把这些成果从文件里搬出来，当着所有人的面讲清楚、认下来。 > 项目启动会议是项目生命周期中的关键环节，它标志着项目正式步入实施阶段，由项目经理主导，目的是确保各方干系人对项目目标、范围、需求、背景以及各自的职责有清晰认识。 > 一句话记住它的分量：启动大会不是"宣布开工"的仪式，而是"对齐共识"的现场。 > 还有一点要提醒：启动大会不是"领导讲话会"，主角是项目经理和团队——领导到场是表态支持，真正的信息传递和分工确认，必须由项目经理来完成。 > 下一页我们讲三件事：请哪些人、走哪几步、要拿到什么结论。

> 口播：项目启动会议是项目生命周期中的关键环节，标志着项目正式步入实施阶段，由项目经理主导，确保各方干系人对项目目标、范围、需求、背景及各自职责有清晰认识。我们讲三块。 > 第一块，参会人员。 内部包括：项目经理、团队成员、公司领导、PMO 代表、变更控制委员会即 CCB 成员、相关职能部门负责人。外部包括：客户代表、供应商代表等关键干系人。这里有一个细节要划重点——参会名单由项目经理审核。为什么强调这一点？因为名单就是"谁被正式纳入了项目"的证据；名单漏了谁，后面争论"这事该谁配合"时你就没有依据。 > 第二块，会议流程，分三段。 ① 会前筹备：确认汇报材料、议程、人员名单，完成通知与签到。别小看签到，它是"信息已传达"的书面痕迹。② 核心环节：项目经理介绍项目——目标、里程碑、分工、风险等，然后是答疑澄清，最后请公司领导做动员。③ 会后输出：生成会议纪要，记录主题、结论、待办等，作为后续跟踪的依据。 > 第三块，要拿到的关键结论，四条。 第一，团队对项目基本信息、目标和计划有全面了解；第二，明确项目风险识别清单及初步应对措施；第三，确定项目总体分工及下阶段工作任务；第四，增强项目团队成员的凝聚力和士气——这一条看着"软"，其实最硬，因为项目后期靠的就是这股劲。 > 现在回扣我们的案例：超市项目"启动了，但没启动透"——启动会上团队对整体目标只有初步理解，具体实施步骤、任务分配、风险挑战的认知仍然比较薄弱。这就是典型的"形式启动了、实质没启动"。判断一次启动会成不成功，就看三件事：目标是否对齐、分工是否清楚、风险是否上桌。

> 口播：启动大会的最后一块，是待办事项。课件里给了两条：第一，根据会议内容编制《项目启动会议纪要》，确保所有相关责任人都收到；第二，相关责任人按纪要要求开展各自工作，确保项目顺利推进。 > 请看表 2-4，这是项目启动会议纪要模板，我们逐行过一遍。表头部分：会议名称（项目启动会）、会议主题/时间/地点、记录人/审核人、参会人员。正文部分三块：会议内容——记录讨论事项，并分项罗列具体讨论的问题；会议结论——记录讨论结果，并针对具体问题得出讨论结论；待办事项——记录待解决的问题和待跟进的事项。 > 这张表最容易被当成"填空题"，我要特别强调一句：纪要不是"会议流水账"，而是"责任清单＋跟踪依据"。 什么叫流水账？就是"某年某月某日开会，领导讲话，大家讨论热烈"——这种纪要写完就进抽屉。什么叫责任清单？就是每一条待办都能回答三个问题：谁负责？什么时候完成？完成的标志是什么？ > 给大家一个可以直接用的写法：待办事项不要写"尽快完成需求调研"，而要多写几个字——写成"由某某（责任人）在某个时点前（期限）提交需求调研提纲（交付物），并抄送项目经理"。多写这一句，纪要就从"记录"变成了"管理工具"。 > 另一个细节：模板里为什么要有"记录人/审核人"？因为纪要也需要审核确认——记录人负责如实记录，审核人负责认定结论，这样纪要在后续追责和变更时才有公信力。 > 最后强调一句：纪要在会后及时发出，并确保所有相关责任人都收到。没收到，等于没写；没写，等于白开。 > 我再补一个很实用的动作：纪要发出之后，下一次例会的第一件事就是对着待办清单逐条过——完成的项目销项，没完成的当场说明原因、给出补救计划和时间点。这样纪要才不只是"发出去了"，而是真的在推动项目往前走。 > 反过来提醒一句：如果待办清单写完就没人再看，这个项目很快就会进入"开会—忘记—再开会"的循环，这也正是很多项目"会开了不少、进度却没动"的原因。

> 口播：今天我们用一张全景图收口，请大家跟着我一起走一遍这条知识线。 > 01 启动概述：五个环节——建议书、可行性研究、评估与决策、章程／经理／干系人、启动大会。一句话就是：立项决定"干不干"，章程决定"谁来干、怎么干"，启动会决定"大家认不认"。 > 02 项目立项：四阶段流程；小型项目可合并初步与详细可研，但详细可行性研究不可或缺；五个维度是技术、经济、社会效益、运行环境、其他（法律与政策）；评估必须由第三方独立完成，再据以决策。 > 03 项目准备工作：选对人——项目经理的来源、四种能力、七项职责与五类权力；搭对架子——职能型部门说了算、PM 权力最小，项目型经理说了算、PM 权力最大，矩阵型两个领导共享管理权、资源最省但责权必须划清。口诀：小项目看职能、大攻关看项目型、多项目并行看矩阵。 > 04 到 06 是三件事：识别干系人（内 5 类＋外 5 类，漏掉关键干系人就要多付十倍沟通成本）；制定章程（四类依据、五种方法、11 项核心内容＋假设日志，自检五问）；开好启动大会（人员、流程、四条结论，会后的纪要是责任清单＋跟踪依据）。 > 【思政落点 4】（1 分钟） > 今天有一条线贯穿始终，我要郑重地说一遍：依法合规、实事求是、客观公正。立项与招投标要遵纪守法、程序合规，因为程序是最可靠的防错机制；可行性研究要实事求是、科学严谨，不能"为了通过而论证"，数据不能凑、效益不能吹；第三方评估要独立客观，不能既当运动员又当裁判。同学们将来一定会遇到"先把项目立了、手续后补"这类诱惑，请记住：把项目做对，先要把人做正。 > 作业布置（计入平时成绩，学习通提交）：① 项目建议书的作用是什么？② 项目可行性研究内容有哪些？③ 项目可行性研究阶段包括哪些？④ 项目经理需要哪些能力？⑤ 对于给定的软件项目案例，分析其在项目启动过程中出现的问题。⑥ （思政思考题） 结合政府采购或企业招标中的一个真实案例，分析"围标串标""最低价中标忽视质量"等现象对项目的影响，谈谈坚守诚信底线、依法合规的重要性，300 字以内。 > 下节课预告：第 3 章软件项目采购管理——东西怎么买、招投标怎么组织、评分表怎么编、合同怎么签怎么管。提前想一想：如果一个项目必须外包，你最担心什么？ > 今天就到这里，下课，同学们再见！

## 四、板书设计（建议）

黑板分三块，随讲课逐步生成：

`` ┌────────────────────┬─────────────────────┬──────────────────────────┐ │ ① 流程区（左） │ ② 对照区（中） │ ③ 案例诊断区（右，全程保留）│ │ │ │ │ │ 启动五环节： │ 组织结构三选： │ 超市智能库存系统踩的五个坑：│ │ 建议书 → 可研 → │ 职能型=部门说了算 │ ① 技术可研空心 │ │ 决策 → 基础工作 → │ 项目型=经理说了算 │ （算法/集成/补货方案） │ │ 启动会 │ 矩阵型=共享管理权 │ ② 干系人漏识别（业务部门）│ │ │ （两个领导·责权要清） │ ③ 沟通无规划 │ │ 可研五维度： │ │ ④ 风险未识别（跨领域） │ │ 技术·经济·社会· │ 干系人：内5（发起人/ │ ⑤ 启动会没开透 │ │ 运行环境·其他 │ 经理/团队/职能经理/ │ │ │ （法律·政策） │ PMO）外5（客户/用户/ │ 对策：补技术可研＋干系人 │ │ │ 供应商/监管/股东） │ ＋沟通计划＋风险清单＋ │ │ 章程＝授权书＋责任书 │ │ 启动会做深做实 │ │ 自检5问：目的清不清· │ 判断口诀：小项目看职能│ │ │ 目标可量否·风险列没列│ 大攻关看项目型· │ 金句：把项目做对， │ │ 里程碑有没·谁批谁管 │ 多项目并行看矩阵 │ 先要把人做正 │ └────────────────────┴─────────────────────┴──────────────────────────┘ ``

## 五、常见学生疑问与应答