<!-- 第2章 讲稿分片 A ｜ 覆盖课件 2.1–2.7 ｜ 依据：_扩写规范.md、_v1要点版、课件 _build2.py SLIDES 1–7、教案第02章 -->
### 【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 项目立项 ｜ 一问：该不该干？｜ 四阶段：申请 → 初研 → 详研 → 评估决策 ｜ 定位：项目的地基

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

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

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

---
