# 《软件项目管理》第 2 章 讲稿（第 2 周 · 90 分钟）· v2 完整版

> 课程：软件项目管理（154431006）｜ 广东金融学院 计算机学院
> 章节：第 2 章 软件项目启动 —— 某大型连锁超市智能库存管理系统案例
> 学时：2 学时（90 分钟）｜ 教材：宋莹莹等《软件项目管理与实践》（第 3 版），清华大学出版社 2025
> 配套课件：`lecture2/2.1.html` ~ `2.28.html`（28 页）｜ 在线：http://111.231.0.226:1234/lecture2/index.html
> 本讲重点：干系人分析、项目可行性研究的内容与方法、制定项目章程的关键要素
> 本讲难点：实际场景中如何系统开展项目可行性分析；项目章程的拟定与各方权责的界定
> **本讲稿为可照读完整版**：每页含【口播（可直接朗读）】【板书】【提问＋预设回答】【易错点/考点】【过渡】；带 ★ 的页为时间紧张时可压缩页。

---

## 一、教学目标

| 维度 | 目标（课后可检验） |
|---|---|
| **知识** | ① 能说出软件项目启动的五个关键环节；② 能写出项目建议书的四项核心内容与可行性研究的五个维度；③ 能说出项目立项管理的四个阶段及"详细可研不可或缺"的原因；④ 能比较职能型/项目型/矩阵型三类组织结构的优缺点与适用场景；⑤ 能列出项目干系人的内 5 类＋外 5 类；⑥ 能背出项目章程的 11 项核心内容并说明假设日志的作用；⑦ 能说出启动大会的人员、流程与四条关键结论 |
| **能力** | ① 能对给定项目列出干系人清单并说明其诉求；② 能按表 2-2 目录为一个小项目拟出可研报告提纲；③ 能起草一份项目章程的前 5 项内容；④ 能用"目标—分工—风险"三问判断一次启动会是否开透 |
| **素质（思政）** | ① 理解"程序是防错机制"——依法合规、按程序办事既是保护项目也是保护自己；② 做可行性研究要实事求是、数据说话，反对"为通过而论证"；③ 第三方评估要独立客观，"不能既当运动员又当裁判"；④ 收口：把项目做对，先要把人做正 |

**本讲要建立的一个总印象**：项目启动是项目的"第一粒扣子"——立项严不严谨、章程清不清楚，决定了项目后面 90% 的日子好不好过。

---

## 二、时间分配总表

> **配速提示**：本讲稿口播合计约 **17,100 字**（≈71 分钟纯朗读，按 240 字/分钟），与 90 分钟课堂容量基本匹配（余下约 19 分钟用于小组讨论、练习与答疑）。
> 取用建议：**重点页全文慢讲**：2.6、2.8、2.10、2.12、2.17、2.19、2.21、2.24；**常规页**只讲口播第一、二段＋板书＋1 个提问；★2.11、★2.23、★2.27 可布置为课后阅读。
> 备课台（http://192.168.31.76:8910/备课台/）每页显示"口播约 N 字 ≈ M 分钟"，可据此精确控时。

| 时段 | 页码 | 内容 | 分钟 | 备注 |
|---|---|---|---|---|
| 第 1 节 | 2.1–2.2 | 封面、目录、上节回顾 | 3 | 回顾"项目五大特征" |
| 第 1 节 | 2.3–2.4 | 案例导入：智能库存管理系统（含思考题） | 10 | 小组讨论 2 分钟 |
| 第 1 节 | 2.5–2.6 | 01 启动概述 · 全流程五环节 | 8 | 2.6 是本节骨架，必背 |
| 第 1 节 | 2.7–2.9 | 02 项目立项 · 四阶段 · 建议书 | 14 | 2.8 有重要例外条款 |
| 第 1 节 | 2.10–2.11 | 可行性研究：五维度 · 两阶段与报告结构 | 10 | 2.10 练习；★2.11 可压缩 |
| —— | —— | **课间休息 10 分钟** | —— | —— |
| 第 2 节 | 2.12 | 项目评估与决策（第三方·依法合规） | 4 | 思政重点页 |
| 第 2 节 | 2.13–2.17 | 03 项目准备工作：项目经理 · 三类组织结构 | 16 | 2.17 含场景练习 |
| 第 2 节 | 2.18–2.19 | 04 识别干系人（内 5 类＋外 5 类） | 7 | 回扣案例 |
| 第 2 节 | 2.20–2.24 | 05 制定项目章程：定义·依据·方法·结果 | 12 | 2.24 自检五问＋练习 |
| 第 2 节 | 2.25–2.28 | 06 启动大会 · 纪要 · 小结与作业 | 6 | ★2.27 可布置为课后 |

> **压缩优先级（时间不够时按序）**：★2.11（报告结构表改为课后按目录自拟提纲，课上只讲两阶段）→ ★2.23（章程方法压成一句话列举）→ ★2.27（纪要模板布置为课后作业）。**2.6、2.8、2.10、2.12、2.17、2.19、2.21、2.24 是考点密集页，不要压缩。**

---

## 三、逐页讲稿

> 使用说明：每页第一段是**可直接朗读的口播**（照读即可，也可按自己语速增删）；其后是板书、提问与预设回答、易错点/考点、过渡语。**案例线贯穿全章**：每讲到关键节点，请回扣"某大型连锁超市智能库存管理系统"案例对照讲解。

### 【2.1】封面（0.5 分钟）

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

**板书**：第 2 章 软件项目启动 ｜ 四问：该不该干 → 谁来干 → 凭何授权 → 共识立没立 ｜ 一行大字："第一粒扣子"

**提问**：上节课我们讲过项目的五大特征。请说出其中两个——它们决定了"启动"这个阶段为什么必须存在？

**预设回答**：
- 答"临时性、独特性"：✅ 答对了。追问："临时性意味着项目有终点，可不可干这件事为什么必须在起点就定下来？"把答案引到"先想清楚、先授权，再动手"。
- 只答"不确定性"：⚠️ 半对。不确定性说明风险高，所以启动阶段要识别风险、列风险清单；但真正决定"启动必须存在"的是临时性和独特性。提醒别把"特征"和"依据"混为一谈。
- 答不上来：提示他回看第 1 章板书"目、独、临、约、不"，挑一个再解释一遍。

**易错点 / 考点**：本章是期末"简答＋案例分析"的主产区。先记住本章定位——**第 1 章讲"什么是项目"，第 2 章讲"项目怎么被批准、被授权、被认可"**，它是后面采购管理、范围管理的上游。

**过渡**：先看今天的学习地图，我们把六块内容排个队。

---

### 【2.2】今天学什么（目录）（2.5 分钟）

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

**板书**：01 概述 → 02 立项 → 03 准备 → 04 干系人 → 05 章程 → 06 启动会 ｜ 旁注学习目标：全流程 · 建议书与可研 · 三类组织结构 · 干系人与章程

**提问**：这六块里，哪一块决定"要不要干"，哪一块决定"能不能干"，哪一块决定"怎么干"？

**预设回答**：
- 答"立项决定要不要干、章程决定怎么干"：✅ 追问一句："那'能不能干'由谁回答？"把他引到可行性研究。
- 把章程和可行性研究混为一谈：❌ 这是典型错误。点评：可研是"论证能不能干成"，章程是"批准之后，授权谁来干、干到什么程度"——一个是判断题，一个是授权书。
- 答"六块都重要"：☑️ 态度对，但没有区分度。请他逐块用一个动词概括：立项＝批，可研＝证，准备＝选，干系人＝找，章程＝授，启动会＝认。

**易错点 / 考点**：选择题常考"下列哪项不属于项目启动阶段的工作"，判断标准是看它属不属于**启动过程组**（制定项目章程、识别干系人）及其前置的立项工作。口诀记"**批—证—选—找—授—认**"。

**过渡**：地图看完了，我们先不急着讲流程，先看一家超市——案例是理解启动最快的入口。

---

### 【2.3】案例背景：某大型连锁超市智能库存管理系统（5 分钟）

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

**板书**：案例：某大型连锁超市 · 智能库存管理系统 ｜ 三痛点：效率低 → 成本升 → 过期损耗 ｜ 做对：建议书 ✓ 可研报告 ✓ 高层快批 ✓ ｜ 隐患：技术可行性 ✗（算法准确性 · 数据集成 · 自动补货方案）｜ 类比：装修没看承重墙

**提问**：如果你在立项评审会上，只有十分钟看这份可行性报告，你会先追问哪个问题？为什么？

**预设回答**：
- 答"先问技术方案能不能实现"：✅ 好答案，与案例的坑完全一致。追问："具体问哪一点？"引到"算法准确率凭什么是这个数、历史数据够不够、有没有做过小范围验证"。
- 答"先问要花多少钱、多久回本"：✔️ 合理，经济可行性确实是评审重点。但要提醒：钱算得再准，技术做不到，投资回报就是空头数字。
- 答"先问领导同不同意"：❌ 把"决策"当成了"依据"。点评：领导同意是决策结果，评审要审的是**论证过程扎不扎实**——"领导批了"不能代替"论证过了"。

**易错点 / 考点**：案例题高频考点——**该案例的问题不在"没走流程"，而在"流程走了、关键维度空心"**。答题时一定要写出"编制了建议书与可行性报告≠论证充分"，这是明确的得分点。

**过渡**：批准之后，项目并没有一帆风顺。下一页，我们看它接下来发生了什么。

---

### 【2.4】案例描述（续）与思考（5 分钟）

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

**板书**：诊断区：① 技术可研空心 ② 干系人漏识别 ③ 沟通无规划 ④ 风险未识别 ⑤ 启动会没开透 ｜ 对策区（与①—⑤一一对齐）：补可研 · 做干系人分析 · 编沟通计划 · 列风险清单 · 启动会做深做实 ｜ 因果链：可研空心 → 未知进开发 → 需求没对齐 → 集成测试爆发 → 工期延误

**提问**：这五个问题里，哪一个最像"病根"，其余四个更像它引起的"症状"？

**预设回答**：
- 答"技术可行性论证不足"：✅ 与案例文本一致。追问："技术没论证透，为什么会连带出沟通问题和工期延误？"引导他讲出那条因果链。
- 答"启动会没开透"：✔️ 有道理，它是症状的集中体现。但提醒：启动会开不透，往往是因为前面该论证的没论证、该识别的没识别，会上自然说不出细节。
- 答"项目经理选错了"：☑️ 观察到了"人岗不匹配"，值得肯定。补充：这一条属于"风险识别缺位"的具体表现，选人本身就是一次风险管理决策。

**易错点 / 考点**：案例题答题模板——**先点问题（分条）→ 再给对策（一一对应）→ 最后落到"启动阶段欠账、后期还债"**。注意不要把"项目经理经验不足"写成唯一原因，那是外行答法；得分点在于多因素的结构化归因。

**过渡**：带着这五个坑，我们正式进入第一块——启动到底该做哪些事，流程是什么。

---

### 【2.5】分区页：01 软件项目启动概述（0.5 分钟）

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

**板书**：01 软件项目启动概述 ｜ 启动＝一串动作，不是一次拍板 ｜ 顺序：论证 → 决策 → 授权 → 对齐

**提问**：如果公司领导说"这个项目定了，下周开工"，你接手的第一件事该做什么？

**预设回答**：
- 答"先做可行性研究"：✅ 好。同时提醒实务中确实常见"先定后论证"，这时正确的应对是补齐论证材料、把未知项列成风险与假设，而不是硬顶领导。
- 答"先组队、先排计划"：❌ 顺序错了。点评：没有论证和授权就排计划，等于在流沙上盖楼；后面一变更，计划全部作废。
- 答"先问预算多少"：✔️ 这属于"预先批准的财务资源"，是章程里要写的内容，但顺序上仍在论证之后。

**过渡**：下一页，我们把这条链子完整摆出来——五个关键环节。

---

### 【2.6】软件项目启动：关键环节全流程（7.5 分钟）

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

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

**板书**：五环节：① 建议书（想干什么）② 可研·初/详（能不能干）③ 评估决策（干不干）④ 章程＋经理＋干系人（谁来干 · 怎么干）⑤ 启动会（大家认）｜ 压缩口诀：提 → 证 → 批 → 备 → 认

**提问**：五个环节里，哪一步是"可以合并、但绝不能省"的？为什么？

**预设回答**：
- 答"可行性研究"：✅ 尤其是详细可行性研究。追问："小型项目可以合并初研和详研，但为什么详研不能省？"——因为详研是决策的唯一依据，省掉它，决策就成了拍脑袋。
- 答"启动大会"：⚠️ 启动会可以简化，小项目开个短会也行，但它承担的是"共识"功能；共识缺失的代价，通常在开发中期才显现出来。
- 答"项目建议书"：✔️ 建议书是入口，重要性不低；但它是"申请"而不是"批准"，真正决定成败的是可研与决策环节。

**易错点 / 考点**：高频简答题"项目启动包括哪些关键环节"，答题口诀"**提—证—批—备—认**"。案例题里如果问"启动阶段有什么问题"，要能区分**流程缺失**（根本没做）和**流程空心**（做了但没做透）——本案例属于后者，这是拉分点。

**过渡**：五个环节里，第二、第三步——可研与决策——全都属于"项目立项"这块内容。下一块我们就专门讲它。

---

### 【2.7】分区页：02 项目立项（0.5 分钟）

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

**板书**：02 项目立项 ｜ 一问：该不该干？｜ 四阶段：申请 → 初研 → 详研 → 评估决策 ｜ 定位：项目的地基

**提问**：立项做扎实了，对后面哪些工作有直接影响？请至少说出三样。

**预设回答**：
- 答"章程、团队、资源分配"：✅ 与课件表述一致。追问："为什么章程要看立项文件？"引到"立项管理文件是制定章程的第一类依据"。
- 只答"决定项目能不能上"：✔️ 方向对但不完整，提示他从"文件—人—钱—进度"四个角度补齐。
- 答"没什么影响，反正后面都要改"：❌ 典型的轻视立项。点评：立项结论是后续所有计划的基准，基准一改，全部重做——这就是变更成本的来源。

**过渡**：下一页，我们把立项管理的四个阶段完整展开，还有一个"小项目可以合并、但详研不能省"的重要例外。

---

### 【2.8】项目立项管理四个阶段（3 分钟）

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

**板书**：立项四阶段：① 建议申请 ② 初研（粗筛）③ 详研（全面论证）④ 评估决策 ｜ 例外：小项目可合并初/详研，但**详研不可省** ｜ 类比：种草 → 网上看 → 实地看 → 请评估定价 ｜ 口诀：可合并，不可省

**提问**：既然小型项目可以合并两个可研阶段，那"合并"的正确做法是什么？

**预设回答**：
- 答"一次做完，但详研该有的内容一条都不能少"：✅ 正确。强调：合并的是**流程环节**，不是**论证深度**。
- 答"小项目就不用做详研了"：❌ 这是最常见的错误，与课件表述正好相反。追问："那决策依据从哪里来？"让他自己推出结论。
- 答"看领导要求"：⚠️ 提示他：是否合并取决于项目规模与风险特征，不取决于领导心情；即便合并，投资估算、风险分析这些内容也必须写清楚。

**易错点 / 考点**：判断题高频考点——"小型项目可以不做详细可行性研究"是**错的**。口诀："**可合并，不可省**"。另外注意四阶段的排序题，评估决策一定在详细可行性研究之后。

**过渡**：四个阶段里，第一阶段要产出的核心文件，就是项目建议书。下一页我们专门讲它。

---

### 【2.9】项目建议书（立项申请）（3.5 分钟）

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

**板书**：项目建议书 ｜ 依据：大势（国民经济 · 国家及地方规划 · 产业政策）＋ 市场 ＋ 项目所在地条件 ＋ 本单位战略 ｜ 四块：背景必要性 · 市场分析预测 · 预期成果与定位 · 实施必要条件 ｜ 定位：申请 ≠ 批准

**提问**：如果让你为"校园二手交易平台"写一份项目建议书，第①块"背景和必要性"你会怎么写？请一位同学说 30 秒。

**预设回答**：
- 答"同学们买卖二手书不方便，每到毕业就成堆扔书"：✅ 抓到了痛点。追问："这属于效率问题还是成本问题？受益面有多大？"把他引到"痛点＋受益面＋必要性"的三段结构。
- 答"因为我想做个项目练手"：❌ 把自己的学习需求当成了项目的必要性。点评：建议书的"必要性"要站在**委托方和使用者**的立场上说，个人动机不是立项理由。
- 答"因为别的学校都有了"：⚠️ 这是"跟风式理由"，属于弱依据。可以借用，但必须补上本单位的真实需求与条件——依据要落在"大势＋市场＋条件＋战略"上。

**易错点 / 考点**：简答题"项目建议书的编制依据与核心内容"。依据容易背漏，记四类：**大势（国民经济与规划、产业政策）、市场、项目所在地条件、本单位战略**。判断题常考"项目建议书经批准即立项"——**错**，真正批准的是可行性研究与评估决策的结果。

**过渡**：建议书提出的是"我想做"，接下来就要论证"我能不能做成"——这就进入可行性研究。

---

### 【2.10】项目可行性研究：五个维度（4.5 分钟）

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

**板书**：可研五维度：技术（能不能）· 经济（划不划算）· 社会效益（内外影响）· 运行环境（顺不顺）· 其他（法律 / 政策）｜ 顺序感：技术＝入场券，法律＝一票否决，经济＝决策核心，运行环境＝最易漏

**提问**：案例中的超市项目，如果要补一份技术可行性分析，你会要求团队先回答哪三个问题？

**预设回答**：
- 答"算法准确率能到多少、历史数据够不够、补货建议出错谁来兜底"：✅ 非常到位。追问："准确率凭什么保证？"引到"要靠历史数据的回溯验证和小范围试点，而不是厂商的口头承诺"。
- 答"我们买哪家的算法产品"：⚠️ 这是方案选择，不是可行性论证。提醒他：先回答"能不能做到"，再回答"买谁的"。
- 答"技术可行性就是看市面上有没有现成产品"：❌ 太窄。点评：技术可行性还包括集成难度、性能指标、能否在工期内完成——现成产品是有的，但不一定接得上你的老系统。

**易错点 / 考点**：选择题必考维度归属——**"员工能否上手"＝运行环境可行性**（最容易被错答成技术可行性）；**"是否符合法律法规"＝法律可行性**（归入"其他"）；**"投资回报期"＝经济可行性**。口诀："**技术入场、法律否决、经济定案、运行落地、社会加分**"。

**过渡**：五个维度知道了，那么可行性研究具体分几步做、报告又要写哪些内容？下一页讲两个阶段与报告结构。

---

### 【2.11】项目可行性研究：两个阶段与报告结构（5 分钟）

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

**板书**：初研＝粗筛（判定值不值得深研）｜ 详研＝细算（决策的直接依据）｜ 表 2-2 八步：背景与技术 → 市场与客户 → 目标与进度 → 投资 → 人员 → 风险 → 经济与社会效益 → 结论附件 ｜ 板书红圈：**项目风险 · 社会效益**

**提问**：请判断——"初步可行性研究的结论认为项目可行"，是否意味着可以直接立项了？

**预设回答**：
- 答"不可以，还要做详研和评估决策"：✅ 完全正确。追问："为什么不能直接立？"——因为初研只是决定"要不要继续投入研究"，结论偏定性、信息不全。
- 答"可以，初步可行就是可行"：❌ 混淆了"阶段结论"和"决策结论"。点评：初研说"值得再看"，好比体检初筛提示"某项指标异常，去专科复查"，那不叫确诊。
- 答"看项目大小"：⚠️ 部分正确。小项目可合并初研与详研，但**详研的内容不能省**，同理评估决策环节也不能省。

**易错点 / 考点**：简答题常考"初步可行性研究与详细可行性研究的区别"，答题落在两点上：**目的不同**（要不要继续投入 vs 为决策提供依据）、**深度不同**（定性粗筛 vs 全面深入）。另一个考点是**可研报告结构**，尤其"项目风险""社会效益"两栏，答漏了就丢分。

**过渡**：可研报告写完，谁来审、谁来拍板？这就是下一页的"项目评估与决策"。（如果时间紧张，表 2-2 的细节可以布置为课后阅读——请同学们课后按这个目录，为小组项目列一份可研提纲。）

---

### 【2.12】项目评估与决策（4 分钟）

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

**板书**：评估＝第三方（依据：国家政策 · 法规 · 行业标准）→ 评估报告（项目概况 · 详细评估意见 · 总结与建议）→ 决策 ｜ 三句话：运动员 ≠ 裁判 ｜ 独立 → 客观 → 可信

**提问**：如果公司内部评审会上，业务部门说"我们自己最懂，不需要外部评估"，你会怎么回应？

**预设回答**：
- 答"内部是运动员，不能同时当裁判；重大或合规敏感项目必须引入第三方"：✅ 答到点子上了。再补一句：引入第三方不是不信任谁，而是**让结论可以被外部采信**。
- 答"外部评估太慢、太贵"：⚠️ 成本上的顾虑可以理解，但要算总账——省下的评估费，可能换来一次失败立项的十倍损失。
- 答"领导定了就行"：❌ 这正是案例里的隐患路径。点评：决策需要依据，而评估报告是最难被替代的那份依据。

**易错点 / 考点**：简答题"项目评估由谁做、依据什么、评估什么"——三个采分点是**第三方、国家政策法规与行业标准、国民经济／社会影响／组织业务三个角度**。选择题常考"项目评估由项目申报单位自行完成"——**错**。

**过渡**：项目批了，接下来两件事最关键——**选对人、搭对架子**。我们进入第三块：项目准备工作。

---

### 【2.13】分区页：03 项目准备工作（0.5 分钟）

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

**板书**：03 项目准备工作 ｜ 选对人（指派项目经理）＋ 搭对架子（组织结构：职能 / 项目 / 矩阵）｜ 本质：定权力结构 ｜ 准备阶段多花一天，执行阶段少吵一周

**提问**：为什么"选对人、搭对架子"必须在开工之前完成，而不是边干边定？

**预设回答**：
- 答"权力结构定不下来，一开工就互相扯皮"：✅ 到位。补充：人事和结构一变，重新建立信任与汇报关系要花很长时间。
- 答"因为课件这么写"：⚠️ 提醒他别只背结论不背理由——案例题恰恰要问"为什么"。
- 答"反正随时可以换人换结构"：❌ 现实里换项目经理的代价极高：进度要重排、干系人关系要重建、团队士气会受一次打击。

**过渡**：我们先把"选对人"讲透——项目经理的来源、能力、职责和权力，这四项是必考点。

---

### 【2.14】项目经理指派：来源 · 能力 · 职责 · 权力（5 分钟）

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

**板书**：项目经理 ｜ 来源：内部（部门推荐 · PMO 指派 · 高层指定 · 人才计划选拔）／ 外部（公开招聘 · 猎头服务 · 合同聘用 · 伙伴推荐）｜ 能力：项目管理技能 → 战略与商务技能 → 领导力 → 技术能力（**技术排最后**）｜ 职责：规划 · 团队 · 进度资源预算 · 沟通 · 风险质量 · 决策 · 交付收尾 ｜ 权力：按职责分（决策 / 组织 / 指挥 / 人事 / 经济）· 按来源分（职位 / 奖赏 / 惩罚 / 专家 / 参照）｜ 红圈：**专家权力 · 参照权力 = 自己挣的**

**提问**：五种权力里，哪一种**不需要职位**也能有影响力？请举例说明。

**预设回答**：
- 答"专家权力与参照权力"：✅ 正确。追问"请举一个你身边的例子"——比如某位学长技术很强，大家写代码遇到问题都去找他，他没有任何行政职务，但说话有人听，这就是专家权力。
- 答"奖赏权力"：❌ 混淆了。奖赏（加薪、评优、分好任务）通常依赖职位和制度授权，没有职位就很难兑现。
- 答"惩罚权力"：❌ 更依赖职位。点评：惩罚权力过度使用会伤害团队氛围，还会反过来消耗项目经理自己的参照权力。

**易错点 / 考点**：选择题高频——**职能型组织结构中项目经理权力最小，项目型最大，矩阵型居中**（下一页展开）；**项目经理的能力顺序**是项目管理技能在前、技术能力在后，考试常把顺序颠倒来迷惑你。简答题"项目经理的权力来源"要能同时答出两种分法，别只答一半。

**过渡**：选好了人，还要给他一个合适的"架子"——这就是接下来要讲的三类组织结构：职能型、项目型、矩阵型，我们下一页正式开始比较。

---

### 【2.15】组织结构选择 1｜职能型组织结构（3 分钟）

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

**板书**：职能型＝按专业分工（财务/人力/市场/技术）→ 部门说了算 → PM＝协调员/联络员（权力最小）　｜｜　优：专家复用 · 同行交流 · 技术连续　｜｜　劣：支持不足 · 跨部门难 · 归属感低　（画"部门竖排、项目横穿"的简图）

**提问**：在职能型组织里，项目经理发现测试人手不够，要求测试部经理马上加派两个人，测试部经理说"我这边有别的活"，项目经理有权命令他吗？请说理由。

**预设回答**：
- 答"有权，他是项目经理"：❌ 把"项目经理"当成了一种官职。追问："他的权力从哪里来？如果预算、考核、晋升都在部门手里，他说的话对部门经理有约束力吗？"
- 答"没权，只能协调"：✅ 抓住要害。补充：这正是职能型下项目经理权力最小、常设"协调员/联络员"角色的原因，事情成不成，靠人情，也靠上级拍板。
- 答"看公司规定"：部分正确。提醒：公司规定可以微调，但一般规律是职能型下 PM 权力最小，最终要靠部门经理或高层出面。

**易错点 / 考点**：选择题高频考点是"哪类组织结构中项目经理权力最小"——答案是职能型（项目型最大、矩阵型居中）。第二个易错点是把"人力可以复用"当成缺点：恰恰相反，**人力复用是职能型的优点，"资源独占、项目间不能共享"才是项目型的缺点**。记忆口诀：**部门说了算，专家随便借；借来不听话，责任没人担。**

**过渡**：职能型解决不了"集中力量打硬仗"的问题。那好，我们把人和权全部交给项目经理试试——这就是下一页的项目型组织结构。

---

### 【2.16】组织结构选择 2｜项目型组织结构（3 分钟）

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

**板书**：项目型＝以项目为核心 → 经理说了算 → 人·钱·事一把抓（PM 权力最大）　｜｜　优：决策快 · 目标单一 · 一个领导　｜｜　劣：资源独占 · 跨部门难 · 项目结束归属感低　（画"项目竖排、职能虚线"的简图）

**提问**：公司同时有三个大项目，都需要同一位安全专家。如果采用项目型结构，会发生什么？这个代价你愿意付吗？

**预设回答**：
- 答"专家可以被三个项目共用"：❌ 与项目型的前提矛盾。引导：项目型是"独占资源"，专家被编进 A 项目组，另两个项目就借不到，除非公司再招两个人。
- 答"要养三个安全专家，成本高"：✅ 正确，这就是"资源独占"的代价。追问："什么情况下这个代价是值得的？"（项目足够大、足够关键、进度压力足够大时。）
- 答"项目型更先进，所以选它"：❌ 这是"结构崇拜"。提醒：三种结构没有绝对优劣，**只有适配不适配**。

**易错点 / 考点**：职能型与项目型的对比是必考题。记两句话：**PM 权力，职能型最小 → 矩阵型居中 → 项目型最大；人力复用能力恰好相反，职能型最强 → 矩阵型居中 → 项目型最差。** 另一个考点：项目型的适用场景是"**大型工程或复杂研发项目**"，不是"常年重复的小活"。

**过渡**：两个极端各有各的痛——职能型权力太小，项目型浪费太大。那能不能既要专家复用，又要项目经理说话管用？能，这就是第三种：矩阵型。

---

### 【2.17】组织结构选择 3｜矩阵型组织结构（4 分钟）

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

**板书**：矩阵型＝职能＋项目双线并行 → 两个领导（职能经理 / 项目经理）→ 先划清三件事：优先级 · 考核 · 争议裁决　（画矩阵网格：纵轴部门、横轴项目、交叉点写人员名字）

**提问**：矩阵型里，职能经理要求小王这周四参加部门技术分享，项目经理要求小王这周四交出接口文档，小王该听谁的？作为项目经理，你事先该做什么？

**预设回答**：
- 答"听项目经理的，项目优先"：❌ 想当然。追问："部门技术分享是职能经理的考核内容，你说不听就不听，小王年底绩效谁打分？"
- 答"听职能经理的"：同样片面。指出：这就是"多重领导"的典型困境，靠员工自己选边是管理失职。
- 答"事先约定优先级规则，冲突时由上级或 PMO 裁决"：✅ 正是要点。补充：矩阵型必须在开工前把"优先级规则＋考核权重＋裁决通道"落成文字，这也正是它"责权划分不清就会执行混乱"这一缺点的解药。

**易错点 / 考点**：考点两句——"**多项目并行且专家稀缺，宜选矩阵型**"（对）；"矩阵型的主要缺点是多头领导、责权不清、多项目间进度费用质量难平衡"（对）。判断题法三步：**① 项目大不大？② 项目多不多？③ 专家要不要复用？** 小且稳定→职能型；单一大攻关→项目型；多项目并行复用专家→矩阵型。口诀：**小项目看职能、大攻关看项目型、多项目并行看矩阵。**

**过渡**：组织结构这支"架子"搭好了，人也就位了。但还有一个动作没做——把"人"认全。这就是下一页要讲的识别干系人。

---

### 【2.18】分区页：04 识别干系人（0.5 分钟）

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

**板书**：干系人 ＝ 能影响项目 ∪ 被项目影响（两个方向都要看，缺一不可）

**提问**：一个人从没参加过项目会议，但系统上线后他每天都要用这套系统，他算不算干系人？

**预设回答**：
- 答"不算，他没参与项目"：❌ 只看了一个方向。追问："系统上线后他的工作被改变了，他会不会反过来影响项目？"（培训、试用、验收、口碑全靠他。）
- 答"算，属于最终用户"：✅ 正是外部干系人中的一类。追问："他的诉求你们一般在什么时候才想起来问？"（往往是上线前，太晚了。）
- 答"算，但不重要"：纠正——验收权在他手上，属于"权力不高、利益极高"，策略上要"随时告知、重点满足"。

**过渡**：那到底有哪些干系人？我们看下一页这张内 5 类、外 5 类的表。

---

### 【2.19】识别项目干系人：分类与关键角色（6.5 分钟）

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

| 类别 | 关键角色 | 他是谁 | 他关心什么 | 漏掉他会怎样 |
|---|---|---|---|---|
| **内部** | 发起人 | 高层领导（如 CEO），项目发起者 | 值不值得做、是否契合战略 | 资源批不下来，出问题无人背书 |
| | 项目经理 | 项目整体管理者 | 目标、进度、成本、风险 | 项目无人对结果负责 |
| | 团队成员 | 直接执行核心任务的人 | 任务、标准、成长 | 分工说不清，进度靠猜 |
| | 职能经理 | 资源分配与管理（职能/矩阵型组织） | 部门负荷、人员发展 | 借不到人，或人被中途抽走 |
| | PMO | 提供支持、规范流程 | 合规性、报告口径 | 流程与模板反复返工 |
| **外部** | 客户 | 提出需求、验收成果 | 功能可用、价格合理 | 验收被判"不是我要的" |
| | 最终用户 | 使用项目成果的人 | 好不好用、是否加负担 | 系统上线没人用 |
| | 供应商 | 提供资源/技术/服务 | 合同、付款、交付节奏 | 资源不到位，进度落空 |
| | 监管机构 | 确保合规 | 数据安全、隐私、规范 | 验收一票否决 |
| | 股东 | 项目投资方 | 投入产出、风险敞口 | 后续投资与支持中断 |

**板书**：干系人＝影响项目 ∪ 被项目影响　→　内部 5：发起人 · PM · 成员 · 职能经理 · PMO　→　外部 5：客户 · 最终用户 · 供应商 · 监管机构 · 股东　（每类旁注"他关心什么"）

**提问**：在一个"给学校做二手交易平台"的项目里，谁最可能被漏掉？漏掉之后，最坏的结果是什么？

**预设回答**：
- 答"学校信息中心/信息安全部门"：✅ 高价值答案。点评：这类干系人"平时不出现、验收时一票否决"，必须提前纳入并明确其合规诉求。
- 答"普通学生用户"：也成立。追问："你打算用什么方式让他们参与？"（原型试用、问卷、焦点小组、种子用户群。）提醒"被动关联者也是干系人"。
- 答"就甲方和乙方两方"：❌ 典型漏项思维。引导：按岗位逐类过一遍——谁出钱、谁使用、谁审批、谁供货、谁考核，一个都不许省。

**易错点 / 考点**：选择题常考"下列哪项不属于干系人"或"某角色属于内部还是外部干系人"。判断核心只有一句：**能影响项目，或被项目影响——满足其一即为干系人。** 两个易错：① 只把甲乙方当干系人，忘了监管、供应商、最终用户；② 以为"没有正式参与的就不算干系人"。口诀：**出钱的、干活的、用的、管的、供的——五路都要认。**

**过渡**：人认全了，接下来要做启动阶段最正式的一件事——把这些共识变成一份签了字、算数的文件，也就是项目章程。

---

### 【2.20】分区页：05 制定项目章程（0.5 分钟）

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

**板书**：章程 ＝ 启动阶段最正式的文件 → **批准即正式启动**　（旁边写四个问号：凭什么做？谁来管？多大权？何时完？）

**提问**：项目还没批准、章程还没签，能不能先让项目经理"先干起来"，反正效率高一点？

**预设回答**：
- 答"能，先干起来效率高"：❌ 追问："他调人、花钱、对外承诺的依据是什么？"没有授权，他的指令对别的部门无效，出了问题谁担责。
- 答"不能，要等章程批准"：✅ 补充实务口径：可以做少量前期准备和调研，但**正式授权、资源调配、对外承诺都要等章程批准**，这就是程序合规的底线。
- 答"看老板怎么说"：提醒——老板口头说"你放手干"不能替代书面授权，本章后半段会讲清楚为什么书面这么重要。

**过渡**：那这份章程到底长什么样、能起什么作用？看下一页。

---

### 【2.21】项目章程：定义与作用（3 分钟）

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

**板书**：章程 ＝ 正式文档（商业需求 · 项目论证 · 顾客需求理解）→ 共识三件：可交付成果 · 关键里程碑 · 角色职责　｜｜　四大作用：任命 PM／赋予合法地位／设定总体目标／关联组织战略　→ 授权书 ＋ 责任书

**提问**：项目章程和"需求说明书"是一回事吗？如果只能写一页，你先写哪个？

**预设回答**：
- 答"一回事，都是项目文件"：❌ 混淆点。引导：章程管"授权与边界"，一页成文；需求说明书管"细节"，几十上百页。**先有章程，才有资格去细化需求。**
- 答"不是一回事，先写章程"：✅ 正确。追问："没有章程就直接写需求，可能出什么问题？"（需求做了没人认账、范围无边界、做完了没人签字验收。）
- 答"小项目就省了章程吧"：提醒：形式上可以简化，但"**授权＋目标＋责任人**"这三件事必须有，否则后期扯皮无据可依。

**易错点 / 考点**：必考两处——① "**项目章程批准＝项目正式启动**"；② 章程的四大作用（简答题高频）。辨析题常考"章程≠需求说明书"：**章程管授权与边界、高层级；需求管细节、可追溯。** 还有一个易错点：项目经理在章程这件事里是"**被任命、被授权**"的一方，不是自己写自己批——批准人是发起人或更高层。

**过渡**：章程不是凭空写出来的作文。它依据什么材料写、由谁来写、产生哪些成果？接下来三页，我们分别讲依据、方法和结果。

### 【2.22】制定项目章程的依据（3 分钟）

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

| 依据 | 具体内容 | 怎么用（举例） |
|---|---|---|
| **立项管理文件** | 含商业需求、成本效益分析等，为决策提供依据（项目经理无权直接修改，可提调整建议） | 章程的"项目目的"直接取自这里；发现不合理，只能提建议、走流程 |
| **合同** | 外部客户项目的法律框架，明确目标、范围、交付要求、付款条款等 | 把合同条款翻译成项目目标、里程碑与验收标准；不得与合同冲突 |
| **事业环境因素** | 内部：组织文化、结构、设施、IT 工具、资源可用性、员工能力；外部：市场、法律法规、行业标准、财务环境 | 门店网络与人员素质决定目标是否现实；外部法规决定合规底线 |
| **组织过程资产** | 标准化政策/流程/程序；监督与报告机制；模板；历史数据与经验教训库 | 直接用公司章程模板；先查经验教训库，避免重复踩坑 |

**板书**：章程四依据 ＝ 立项管理文件（不可直接改）· 合同（法律框架）· 事业环境因素（内＋外）· 组织过程资产（模板＋经验教训）　→　两个提醒：章程是"执行与需求之间的纽带"；**尽早任命 PM**

**提问**：制定章程时，项目经理发现立项管理文件里写的效益目标明显偏高、根本达不到，他应该怎么办？

**预设回答**：
- 答"直接在章程里改成合理数字"：❌ 越权。追问："改这个数字，等于改了谁的决策？"（批准单位和评审机构的结论。）提醒：他无权直接修改，只能提调整建议。
- 答"提出书面调整建议，走变更或复核流程"：✅ 正确。补充：这既是程序问题，也是保护自己——将来真达不到目标，你有书面依据。
- 答"不管它，照着抄"：❌ 明知有坑还照抄，属于把风险留给团队。指出：专业态度是"发现问题—书面提出—留痕"，采不采纳由批准人决定。

**易错点 / 考点**：简答与选择常考"制定章程的依据有哪些"，四类必须写全。三个易错点：① 把"合同"和"立项管理文件"混为一谈；② 忘记"事业环境因素"要分内部和外部；③ 误以为项目经理可以改立项文件。口诀：**文件、合同、环境、资产——四路进货，一样不能少。**

**过渡**：依据清楚了，那具体用什么方法把这些材料组织成一份章程？下一页讲五种方法与工具。

---

### 【2.23】制定项目章程的方法（2.5 分钟）

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

**板书**：方法五件套 ＝ 专家判断 · 头脑风暴 · 焦点小组 · 访谈 · 人际关系与团队技能　（下方对号：经验→专家／数量→脑暴／共识→焦点／敏感→访谈／矛盾→人际技能）

**提问**：要摸清"门店店长对新系统最大的顾虑是什么"，五种方法里，你优先选哪一种？为什么？

**预设回答**：
- 答"访谈"：✅ 优先推荐。理由：涉及个人顾虑，一对一更容易说真话。追问："访谈的局限是什么？"（样本少、主观性强，需要与其他方法交叉验证。）
- 答"头脑风暴"：部分可用，但指出它适合产生想法，不适合挖个人顾虑——一堆人在一起，店长未必肯说"我怕学了不会用"。
- 答"焦点小组"：也合理。补充区别：焦点小组要的是**结构化讨论形成共识**，访谈要的是**个体真实想法**，两者互补，最好结合使用。

**易错点 / 考点**：选择题常问"收集高层级需求、假设条件、制约因素、审批标准，宜采用哪种方法"——答案是**访谈**；"短时间内获得大量想法"——**头脑风暴**；"邀请相关背景人员就目标、风险、成功标准进行结构化讨论"——**焦点小组**。易错点是把头脑风暴和焦点小组混为一谈：**脑暴重"量"、重发散；焦点小组重"深"、重结构。**

**过渡**：方法有了，依据有了，最后制出来的成果到底长什么样？下一页是本章最需要你记住的一页——11 项核心内容。

---

### 【2.24】制定项目章程的结果（3.5 分钟）

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

| 分组 | 项目章程 11 项核心内容 |
|---|---|
| 为什么做 | ① 项目目的；③ 高层级需求与描述 |
| 做成什么样 | ② 可测量的项目目标和成功标准；⑤ 总体里程碑进度计划；⑨ 项目退出标准 |
| 风险与审批 | ④ 整体项目风险；⑧ 项目审批要求 |
| 钱与人 | ⑥ 预先批准的财务资源；⑦ 关键项目干系人名单；⑩ 项目经理及其职责和职权；⑪ 发起人或其他批准人员信息 |
| 另一项产出 | **假设日志**：记录项目生命周期中的假设条件与制约因素（如预算上限、交付周期限制等） |

**板书**：章程 11 项（按四组串记）＋ **假设日志**　→　自检五问：目的清 · 目标量 · 风险列 · 里程碑有 · 谁批谁管写　（右侧写辨析：A 里程碑 ✔／C 职权 ✔／B 详细计划 ✘／D 技术方案 ✘）

**提问**：假设日志里写"假设门店网络改造后能支持实时同步"——如果这个假设后来不成立，会引发什么后果？这个风险该记在哪？

**预设回答**：
- 答"同步做不了，可能影响方案"：✅ 追问："那它算不算项目风险？"（算。）指出：**假设条件是风险的来源之一**，所以章程里既要有"整体项目风险"，也要有假设日志。
- 答"改个方案就行，不用记"：❌ 追问："改了方案，工期和成本变不变？谁来批？"不记录，就等于把变更成本悄悄转嫁给项目组。
- 答"记在会议纪要里就够了"：提醒：会议纪要是过程记录，假设日志是**持续维护的正式台账**，两者管理级别不同。

**易错点 / 考点**：简答题常考"项目章程包括哪些内容"，尽量按四组写全 11 项；案例分析题常给一段文字让你判断"哪些应写进章程"。判断法则：**章程写"高层级、总体、授权、边界"；细化计划、技术选型、具体任务日期不写章程。** 另一个易错点是把**假设日志**忘掉——章程的产出是"两样"，不是"一样"。

**过渡**：到这儿，章程有了、经理任命了、干系人认全了。可是这些成果还锁在文档里，怎么让整个团队和所有相关方都知道、都认账？答案就在启动阶段最后一步——开好项目启动大会。

---

### 【2.25】分区页：06 项目启动大会（0.5 分钟）

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

**板书**：启动大会 ＝ 由 **PM 主导**的关键环节 → 标志项目正式步入实施阶段 → **不是仪式，是对齐**

**提问**：如果启动大会只是念一遍项目目标，团队成员各看各的手机，这会开成功了吗？

**预设回答**：
- 答"开完了就算成功"：❌ 追问："散会以后，谁能说清自己下周干什么、向谁汇报？"说不清，会就等于没开。
- 答"不算，得看目标、分工、风险有没有讲透"：✅ 抓住了要点。补充：判断标准就是三件事——**目标是否对齐、分工是否清楚、风险是否上桌**。
- 答"开会没用，发个文档就行"：❌ 提醒：文档解决"知道"，会议解决"认同"和"当面承诺"，两者不能互相替代。

**过渡**：那启动大会具体怎么开？请看下一页——人员、流程、结论。

---

### 【2.26】项目启动大会：人员 · 流程 · 结论（3 分钟）

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

**板书**：启动大会三块　→　人员：内部（PM·成员·领导·PMO·CCB·职能部门）＋外部（客户·供应商），**名单由 PM 审核**　→　流程：会前筹备 → 核心环节（介绍→答疑→领导动员）→ 会后纪要　→　结论四条（目标计划·风险清单·分工任务·凝聚力）　（右侧标注判据：目标齐 · 分工清 · 风险上桌）

**提问**：启动会开得很热闹，领导讲了话、大家鼓了掌，但散会后没人说得清自己的任务和交付时间。问题出在流程的哪一段？

**预设回答**：
- 答"出在核心环节，项目经理没讲清分工"：✅ 追问："那怎么补救？"（会后纪要里把分工、责任人、期限一条条落成待办。）指出：**热闹不等于对齐**。
- 答"出在会后输出，没写纪要"：也成立。补充：纪要缺失，等于会议没有留下可跟踪的凭据，后面只能反复开会。
- 答"出在公司领导动员太久"：可以作为时间管理问题点评，但要引导学生看到根本原因——**流程缺少"确认与落地"环节**，而不是谁讲话长短。

**易错点 / 考点**：选择、判断题常考三处——① 启动会由**项目经理主导**（不是领导主导、不是 PMO 主导）；② 参会名单**由项目经理审核**；③ 会议结论包含"增强凝聚力与士气"。易错点：把启动会和项目例会混为一谈——**启动会是一次性、标志性的；例会是有周期的、跟踪性的。** 另一个易错点：以为启动会等于"宣布开工"，其实它的核心是**对齐目标、明确分工、把风险摆上桌**。

**过渡**：会开完了还不算结束。启动大会真正的"落地件"，是会后那份纪要，以及纪要背后的待办清单——下一页专门讲。

---

### 【2.27】启动大会：待办事项与会议纪要（2 分钟）

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

| 项目 | 填写要求 |
|---|---|
| 会议名称 | 项目启动会 |
| 会议主题 / 时间 / 地点 | 写明主题与召开的时间地点 |
| 记录人 / 审核人 | 记录人如实记录，审核人确认结论 |
| 参会人员 | 按已审核名单如实登记（含签到） |
| 会议内容 | ① 记录会议所讨论的事项；② 分项罗列具体讨论的问题 |
| 会议结论 | ① 记录会议讨论的结果；② 针对具体问题得出讨论结论 |
| 待办事项 | ① 记录待解决的问题；② 待跟进的事项（**每条必须有责任人和期限**） |

**板书**：纪要 ≠ 流水账，＝ **责任清单 ＋ 跟踪依据**　→　待办三要素：谁负责 · 何时完成 · 交付什么标志　→　会后动作：编制纪要 → 发到每位责任人 → 按纪要开工

**提问**：一份纪要里写着"待办：尽快完成门店需求调研"——这句话缺了什么？请你把它改写成可跟踪的一条。

**预设回答**：
- 答"缺责任人和时间"：✅ 正确。请学生现场改写："由某某负责，在某时点前提交门店需求调研提纲，抄送项目经理。"点评：改写后这条待办**可以被检查、可以被追责**。
- 答"缺交付物"：也正确，补充进去更完整——**责任人＋期限＋交付物**，三样齐全才叫可跟踪。
- 答"这样写挺好啊，大家都懂"：❌ 追问："下周谁来检查？检查什么？完不成算谁的？"三个问题答不上来，说明这条待办等于没有。

**易错点 / 考点**：考点集中在"会议纪要的作用"和"待办事项的要素"。判断/简答常问：**纪要是后续跟踪的依据**，不是会议流水账；**每一项待办必须有责任人和期限**。易错点：把"会议内容"和"会议结论"混在一起——**内容记"讨论了什么"，结论记"定下来什么"**，考试给例子让你归类时要分清。

**过渡**：到这里，第 2 章的全部内容就讲完了。最后我们用一张全景图，把今天这条线从头到尾串一遍。

---

### 【2.28】本章小结：软件项目启动全景图（4 分钟）

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

**板书**：全景图 → ① 启动概述：建议书→可研→评估决策→章程/PM/干系人→启动会　② 立项：四阶段 · 五维度 · 第三方评估　③ 准备：PM 四能力/两权 · 职能/项目/矩阵　④ 干系人：内 5＋外 5　⑤ 章程：四依据·五方法·11 项＋假设日志　⑥ 启动会：人员·流程·结论·纪要　（右侧写思政主线：依法合规 · 实事求是 · 客观公正）

**提问**：回顾超市智能库存管理系统这个案例——它在立项、干系人、沟通、风险这四个环节各踩了什么坑？如果让你重新启动这个项目，你先做哪一件事？

**预设回答**：
- 答"先补技术可行性论证"：✅ 直指案例最核心的坑（算法准确性、数据集成难度、自动化补货实现方案论证不足）。追问："论证完了，接着做什么？"
- 答"先把门店和业务部门拉进来"：✅ 正是干系人识别的落地。补充：还要配套做沟通计划，把"理解不一致"消灭在开发之前。
- 答"先换个懂跨领域整合的项目经理"：也可成立——这正是"人岗匹配"的教训：项目经理的网站开发经验无法覆盖跨领域技术整合与多部门协作。
- 完整答案应四条都覆盖：**技术可研补足 → 干系人识别与参与 → 沟通规划 → 风险清单与启动会做深做实。**

**易错点 / 考点**：期末本章常见题型——选择题（可行性维度归属、组织结构类型与 PM 权力大小、干系人内外部归类、章程要素辨析）、简答/案例分析（补全章程要素、列干系人清单、指出案例中的启动问题）。最容易失分的三处：**① 三类组织结构的 PM 权力与人力复用方向记反；② 章程与需求说明书混淆；③ 只列甲乙方、漏掉监管与最终用户。**

**过渡**：启动阶段到这里就结束了。下一章我们进入"项目要买的东西怎么买"——软件项目采购管理，那里有招投标、评分表和合同在等着我们。

---

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

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

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

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

| 学生可能问 | 应答要点（可直接用） |
|---|---|
| 小项目也要写章程吗？ | 形式上可简化，但"**授权＋目标＋责任人**"三件事必须有，否则后期扯皮无据可依。可以问：如果没写谁负责，延期了算谁的？ |
| 可行性研究谁来做？ | 一般由申报单位组织编制；**评估环节须第三方独立完成**；重大项目可委托有资质机构。申报与评估不能是同一方 |
| 初研和详研能不能合并？ | 小型项目可以合并，但**详细可行性研究不可或缺**——因为它是决策的唯一依据；合并的是"阶段"，不是"内容" |
| 矩阵型"两个领导"不会冲突吗？ | 会，这是它的主要缺点。所以必须**明确责权边界与优先级规则**（谁定"做什么"、谁定"谁来做"） |
| 启动大会和项目例会有什么区别？ | 启动会是**一次性、标志性**的（宣布立项、对齐目标、明确分工与风险）；例会是**周期性**的（跟踪进展、解决问题） |
| 章程批准了还能改吗？ | 重大变更需经**发起人或批准人**同意并走变更流程；章程不做日常修改，日常调整体现在项目管理计划里 |
| 干系人这么多，都要管吗？ | 都要**识别**，但不都同等对待：按权力—利益（或影响—参与）分类，重点管理高权力高利益者，持续告知、监督其余 |
| 项目经理技术不如组员怎么办？ | 正常。项目经理的核心是**项目管理技能＋战略商务＋领导力**，技术能力排第四；靠专家权力与参照权力赢得追随 |

## 六、时间控制预案

| 情形 | 处置 |
|---|---|
| 落后 5 分钟 | 压 ★2.11（只讲"初研判断要不要深入、详研给决策依据"，报告结构表课后自拟）；★2.27 改为课后阅读 |
| 落后 10 分钟 | 再压 ★2.23（五种方法一句话列举，不展开）；2.3–2.4 的小组讨论由 2 分钟压到 1 分钟 |
| 落后 15 分钟 | 课堂练习只保留 2.10（经济可行性）与 2.24（章程判断），其余留作业；2.26 用板书四句话收束 |
| 提前 5–10 分钟 | 加练：给出"校园二手交易平台"背景，各组现场列**干系人清单（≥8 类）**并写**章程前 5 项内容**，抽一组分享 |

## 七、思政落点小结（逐处，便于写课程思政记录）

| 页码 | 落点 | 展开要点 |
|---|---|---|
| 2.6 | 程序是防错机制 | 该走的程序没走、该论证的没论证、该签字的没签字——很多项目出问题都源于此；合规不是束缚，是护栏 |
| 2.10 | 实事求是做可研 | 反对"为通过而论证"；写虚了坑的是团队、公司，最后是用户；数据说话、不回避风险 |
| 2.12 | 第三方独立客观 | 申报方与评估方不能是同一方，"不能既当运动员又当裁判"；依法合规是底线、科学决策是能力、独立客观是品格 |
| 2.19 | 干系人责任 | 漏掉一个关键干系人（如业务部门）要多付十倍沟通成本；尊重每一类相关方的合理诉求 |
| 2.26 | 团队与担当 | 启动会的价值在于"目标对齐、分工清楚、风险上桌"；纪要即责任清单，写上就要做到 |
| 2.28 | 本讲收口 | 把项目做对，先要把人做正——遵纪守法、诚信守约、实事求是是软件从业者的职业底线 |

## 八、本讲速查卡（可印给学生）

| 记忆点 | 内容 |
|---|---|
| 启动五环节 | **建议书（想干什么）→ 可研（能不能干）→ 决策（干不干）→ 基础工作（谁来干、怎么干）→ 启动会（大家一起认）** |
| 立项四阶段 | 项目建议与立项申请 · 初步可行性研究 · 详细可行性研究 · 项目评估与决策（小型项目可合并前两阶段，**详研不可或缺**） |
| 项目建议书四内容 | 背景与必要性 · 市场分析与预测 · 预期成果与市场定位 · 实施必要条件 |
| 可研五维度 | 技术 · 经济 · 社会效益 · 运行环境 · 其他（法律/政策） |
| 可研两阶段 | 初步（判断是否值得深入）· 详细（为决策提供详实依据） |
| 项目经理四能力 | 项目管理技能 · 战略与商务技能 · 领导力 · 技术能力 |
| 五类权力 | 职位 · 奖赏 · 惩罚 · 专家 · 参照（按管理职责另有决策/组织/指挥/人事/经济权） |
| 组织结构三型 | 职能型（部门说了算）· 项目型（经理说了算）· 矩阵型（共享管理权，责权要清） |
| 干系人 | 内部 5：发起人 · 项目经理 · 团队成员 · 职能经理 · PMO；外部 5：客户 · 最终用户 · 供应商 · 监管机构 · 股东 |
| 章程 11 项 | 目的 · 可测量目标与成功标准 · 高层级需求 · 整体风险 · 总体里程碑 · 预先批准财务资源 · 关键干系人名单 · 审批要求 · 退出标准 · 项目经理及职权 · 发起人信息（＋假设日志） |
| 章程自检五问 | 目的清不清？目标能不能量？风险列没列？里程碑有没有？谁批谁管写没写？ |
| 启动会三环节 | 会前筹备 → 核心环节（介绍·答疑·动员）→ 会后输出（纪要） |
| 本讲金句 | **把项目做对，先要把人做正。** |

## 附：课堂练习参考答案速查

| 页码 | 练习 | 答案与要点 |
|---|---|---|
| 2.10 | 属经济可行性的是 | B（投资回报期）；A 属运行环境、C 属法律可行性、D 属技术可行性 |
| 2.17 | 三种场景的组织结构 | ① 小公司常年同类外包 → 职能型；② 80 人攻关 2 年核心系统 → 项目型；③ 高科技企业同时跑 6 个客户项目、复用算法专家 → 矩阵型 |
| 2.19 | 校园平台"信息安全主管部门" | 监管类干系人，核心诉求＝合规与数据安全；此类干系人"平时不出现、验收时一票否决"，必须提前纳入 |
| 2.24 | 哪些属于项目章程 | A（总体里程碑）属于、C（经理职权）属于；B（第 3 周完成数据库设计）属详细进度计划、D（技术栈选型）属技术方案，均不属于章程 |
| 2.4 | 案例思考题 | Q1 问题：技术可研不足 / 干系人漏识别 / 沟通无规划 / 风险未识别 / 启动会没开透；Q2 对策：补可研＋干系人分析＋沟通计划＋风险清单＋启动会做深做实 |