<!-- 第2章 讲稿分片 A ｜ 覆盖课件 2.1–2.7 ｜ 依据：_扩写规范.md、_v1要点版、课件 _build2.py SLIDES 1–7、教案第02章 -->
口播：同学们好，我们开始上课。今天进入《软件项目管理》的第二讲——第 2 章，软件项目启动。 上节课我们建立起了整门课的"地图"：什么是项目、什么是软件项目、生命周期、五大过程组、十大知识领域、八大绩效域。从今天起，我们沿着这张地图往前走，走到项目生命周期的第一步：启动。 这一章其实只回答四个问题：这个项目该不该干？谁来干？凭什么授权他干？开工之前，大家有没有把话说清楚、把共识立起来？ 我们还会跟着一个案例走到底——某大型连锁超市的智能库存管理系统。它在启动阶段踩了哪些坑，后面又是怎么一步步"还债"的，今天全部讲透。 请把这句话记在笔记本第一行：项目启动是项目的"第一粒扣子"，第一粒扣错了，后面九成的日子都不好过。 今天的节奏是：先看案例，再依次讲启动概述、项目立项、项目准备工作、识别干系人、制定项目章程、项目启动大会。
板书：第 2 章 软件项目启动 ｜ 四问：该不该干 → 谁来干 → 凭何授权 → 共识立没立 ｜ 一行大字："第一粒扣子"
提问：上节课我们讲过项目的五大特征。请说出其中两个——它们决定了"启动"这个阶段为什么必须存在？
预设回答：
易错点 / 考点：本章是期末"简答＋案例分析"的主产区。先记住本章定位——第 1 章讲"什么是项目"，第 2 章讲"项目怎么被批准、被授权、被认可"，它是后面采购管理、范围管理的上游。
过渡：先看今天的学习地图，我们把六块内容排个队。
口播：今天的课，六块内容排成一条线。 01 软件项目启动概述——启动到底包含哪些动作； 02 项目立项——要不要干？项目建议书、可行性研究、评估与决策； 03 项目准备工作——谁来当项目经理、用哪种组织结构； 04 识别干系人——谁影响项目、谁被项目影响； 05 制定项目章程——启动阶段最正式的一份文档； 06 项目启动大会——把项目"官宣"给全体相关方。 学习目标是四句话：能说明项目启动的全流程；能写出项目建议书与可行性研究的要点；能比较三类组织结构；能识别干系人并制定项目章程。这四条，也正是本章期末要考的四类题。 上课之前先回顾 30 秒：项目的五大特征是什么？（停顿）对——目、独、临、约、不：有目标、独特性、临时性、受制约、不确定性。今天我们会反复用到"临时性、独特性、不确定性"这三把尺子。 另外提醒一句：今天讲的所有流程都不是纸面文章。启动阶段每少做一步，后面就要多还一次债——案例里我们马上会看到这笔债是怎么还的，而且利息很高。
板书：01 概述 → 02 立项 → 03 准备 → 04 干系人 → 05 章程 → 06 启动会 ｜ 旁注学习目标：全流程 · 建议书与可研 · 三类组织结构 · 干系人与章程
提问：这六块里，哪一块决定"要不要干"，哪一块决定"能不能干"，哪一块决定"怎么干"？
预设回答：
易错点 / 考点：选择题常考"下列哪项不属于项目启动阶段的工作"，判断标准是看它属不属于启动过程组（制定项目章程、识别干系人）及其前置的立项工作。口诀记"批—证—选—找—授—认"。
过渡：地图看完了，我们先不急着讲流程，先看一家超市——案例是理解启动最快的入口。
口播：案例背景是这样一家企业：某大型连锁超市。连锁超市的生意，说白了就是"货进得来、卖得掉、别压库、别过期"。 它当时头疼三件事，请把这三个痛点记住：第一，库存管理效率低——盘点靠人工、补货靠经验；第二，库存成本上升——钱压在了仓库里，周转不起来；第三，商品过期损耗严重——尤其是生鲜和短保商品，卖不掉就只能报损。 这三个痛点其实是一体三面：库存不准，所以补货不准；补货不准，所以不是缺货就是积压；积压久了，就是损耗。要治根，就得让库存算得准、补得快。 于是公司决定：全面升级库存管理系统，引入智能预测算法和自动化补货机制，实现库存的精准管理和优化。请注意这两个技术词——智能预测算法、自动化补货机制。今天它们会变成这家公司最大的坑，我们后面会回来算这笔账。 接着看它的启动过程。做对的部分：项目团队按标准流程编制了《项目建议书》和《可行性分析报告》，论证了系统的经济效益与社会效益；高层领导迅速决策并批准启动项目。听起来很规范，对不对？流程走了、文件写了、领导批了。 但埋下隐患的部分在这里：启动时未充分考虑技术可行性——智能预测算法的准确性要求、数据集成的技术难度、自动化补货机制的技术实现方案，这三样都缺乏深入的分析和调研。 我给大家一个生活化类比，帮你们记住这个坑：这就像装修房子，预算做了、风格定了、家里人也点头了，唯独没有确认"承重墙能不能敲、下水改不改得动"。前面的账算得再漂亮，一动锤子就全乱。 软件行业里同样的事天天发生：某团队立项做"智能推荐"，商业价值论证了三页纸，却没确认自家推荐算法的冷启动数据够不够，上线后推荐不准，用户反而流失得更快。 再补一层背景，帮大家理解为什么"库存"是连锁超市的命脉。连锁超市是典型的薄利多销行业：单件商品毛利不高，靠的是周转速度；而库存恰恰是周转的闸门——压得多，资金就沉淀在仓库里；压得少，又容易缺货、丢单、伤客。所以对这个行业来说，库存管理系统不是"锦上添花的信息化项目"，而是直接影响现金流和客户体验的核心系统。 也正因为它重要，公司上下都盼着它快点上、快点见效——而这种"求快"的氛围，恰恰是启动阶段最容易出问题的地方：越是重要的项目，越容易在论证上偷工减料。 那么请大家再想一层：公司真正想要的，到底是一套"系统"，还是"库存降下来、损耗降下来"？显然是后者。项目只是手段，业务结果才是目的——这句话在写项目建议书和可行性研究时会反复用到：所有论证都要指向"业务上得到了什么"，而不是"我们上了什么技术"。 所以这个案例的第一问就是：可行性报告都写了，为什么还会埋下隐患？ 大家先把这个问号带着，等会儿讲"可行性研究五个维度"时，我们一起把它拆开。
板书：案例：某大型连锁超市 · 智能库存管理系统 ｜ 三痛点：效率低 → 成本升 → 过期损耗 ｜ 做对：建议书 ✓ 可研报告 ✓ 高层快批 ✓ ｜ 隐患：技术可行性 ✗（算法准确性 · 数据集成 · 自动补货方案）｜ 类比：装修没看承重墙
提问：如果你在立项评审会上，只有十分钟看这份可行性报告，你会先追问哪个问题？为什么？
预设回答：
易错点 / 考点：案例题高频考点——该案例的问题不在"没走流程"，而在"流程走了、关键维度空心"。答题时一定要写出"编制了建议书与可行性报告≠论证充分"，这是明确的得分点。
过渡：批准之后，项目并没有一帆风顺。下一页，我们看它接下来发生了什么。
口播：项目批准了，接着看后面的发展。先看风险暴露。 第一件事，派谁当项目经理：这位项目经理具备网站开发的丰富经验。网站开发是好事，但这家超市的项目涉及跨领域技术整合与多部门协作——智能预测算法、库存数据集成、门店与总部流程改造，这些已经超出了传统网站开发的范畴。结果是：管理风险未充分识别，启动阶段就出现了沟通不畅、决策滞后。 第二件事，开发阶段的表现：团队与业务部门沟通出现偏差，对超市实际运营场景与库存管理需求理解不一致；智能预测算法、自动化补货的技术方案研究不足；到了集成测试阶段，遇到较多技术难题与性能瓶颈，项目出现延误。 我把这条因果链写在黑板上，请大家顺着看：技术可行性没做深 → 方案带着大量未知进入开发 → 与业务部门需求没对齐 → 集成测试集中爆发 → 工期延误。这不是运气不好，这是启动阶段欠下的账，在中后期一次性偿还。 生活化类比：这就像一场接力赛，第一棒交棒时没对准手，后面每一棒都在追着棒跑，越跑越乱。启动阶段没对齐的东西不会自动消失，它只会以"返工"的形式回来。 这里我再补一个细节，请大家体会"沟通偏差"到底是怎么产生的。业务部门说的是"这个商品经常缺货，顾客天天抱怨"，这是业务语言；开发团队听到的可能是"需要一个缺货预警功能"，这是功能语言；算法团队心里想的又是"要有足够的历史销量数据才能预测"，这是数据语言。三种语言之间如果没有"翻译"，需求就一定会走样。 再打个生活化的比方：这就像点菜——顾客说"来点清淡的"，厨师理解成"少放盐"，端上来一盘水煮青菜；可顾客心里想的是"不要放辣"。谁都没有说谎，结果就是不对。需求对齐的本质，是把不同角色的语言翻译成同一份可验证的描述。 课堂互动：现在给大家 3 分钟。四人一组讨论两道思考题，2 分钟后我请一组代表发言。 Q1：这个项目的启动存在哪些具体问题？ Q2：针对上述问题，如何有效解决？ 好，我们一起来归纳。请大家对照黑板右侧的"案例诊断"区。 问题有五个：① 技术可行性论证不足——算法准确性、数据集成难度的调研都没做透；② 干系人识别不充分——业务部门的需求没有被对齐；③ 沟通规划缺失——启动时"沟通不畅、决策滞后"就是症状；④ 风险识别缺位——用一个不熟悉该领域的项目经理，又没有识别跨领域整合的风险；⑤ 启动大会"开了但没开透"——团队对目标的理解只停留在表面，实施步骤、任务分配、风险认知都不足。 对策对应五条：立项阶段补足技术可行性研究、认真做干系人分析、编制沟通计划、列出风险清单、把启动会做深做实。 这五条，就是今天这节课六块内容的主线——我们后面每一块，都是在补这五个坑。
板书：诊断区：① 技术可研空心 ② 干系人漏识别 ③ 沟通无规划 ④ 风险未识别 ⑤ 启动会没开透 ｜ 对策区（与①—⑤一一对齐）：补可研 · 做干系人分析 · 编沟通计划 · 列风险清单 · 启动会做深做实 ｜ 因果链：可研空心 → 未知进开发 → 需求没对齐 → 集成测试爆发 → 工期延误
提问：这五个问题里，哪一个最像"病根"，其余四个更像它引起的"症状"？
预设回答：
易错点 / 考点：案例题答题模板——先点问题（分条）→ 再给对策（一一对应）→ 最后落到"启动阶段欠账、后期还债"。注意不要把"项目经理经验不足"写成唯一原因，那是外行答法；得分点在于多因素的结构化归因。
过渡：带着这五个坑，我们正式进入第一块——启动到底该做哪些事，流程是什么。
口播：好，我们进入第一块：01 软件项目启动概述。 这一块只解决一个问题：启动阶段到底要做哪些事，顺序是什么。 这里特别提示一句：启动不是一个"动作"，而是一串有先后的动作——先论证、再决策、再授权、最后对齐。顺序错了，后面全乱。 案例里那五个坑，有四个就出在这一块：建议书走了形式、可行性研究空心、决策太快、基础工作没做够。所以这一块是今天的重头戏。 再补一句它的"地位"：这一块像整章的总纲——后面五块内容，其实都是这五个环节中的某一步被放大来讲。这一页听懂了，后面听的都是细节；这一页糊了，后面会越听越乱。 也请大家记住"概述"这两个字的分量：它不讲细节，只讲顺序和依赖。在项目管理里，顺序本身就是一种专业能力——同样五件事，顺序错了，成本能差出好几倍。
板书：01 软件项目启动概述 ｜ 启动＝一串动作，不是一次拍板 ｜ 顺序：论证 → 决策 → 授权 → 对齐
提问：如果公司领导说"这个项目定了，下周开工"，你接手的第一件事该做什么？
预设回答：
过渡：下一页，我们把这条链子完整摆出来——五个关键环节。
口播：软件项目启动是项目生命周期中的第一步，它主要通过一系列活动，为项目的成功执行打下基础。这五个关键环节，请务必背下来，考试必考。 第一，项目建议书的编写：明确项目的背景、目标和预期成果，为立项提供依据。它的语气是"我建议做这件事"。 第二，可行性研究：分初步和详细两个阶段，评估项目的技术、经济、资源可行性，确保项目具备实施条件。它回答的是"这件事能不能干成"。 第三，项目评估与决策：基于可行性研究结果对项目进行全面评估，最终决定是否立项。它回答"干不干、批不批"。 第四，立项后基础工作：制定项目章程、指派项目经理、识别干系人——明确项目目标、范围和资源分配。它回答"谁来干、怎么干、凭什么叫得动人"。 第五，启动大会收尾：与团队和干系人就目标、需求、时间安排达成一致，为项目推进奠定基础。它回答"大家认不认"。 一句话记忆：建议书（想干什么）→ 可研（能不能干）→ 决策（干不干）→ 基础工作（谁来干、怎么干）→ 启动会（大家一起认）。 我把这五个环节再压缩成五个动词：提 → 证 → 批 → 备 → 认。 为什么顺序不能颠倒？因为每一步都在给下一步提供依据。跳过可研直接决策，决策就没有依据；跳过基础工作直接开工，团队就没有授权、没有边界。这也正是案例里"高层迅速批准"的问题所在——快不是错，"没有依据的快"才是错。 生活化类比：这五步就像去医院看病。先挂号说症状（建议书），再抽血拍片（可研），医生看报告下结论（评估决策），然后定主治医生、安排床位（基础工作），最后把病情、治疗方案和注意事项跟家属讲清楚（启动会）。跳过拍片直接开刀，谁都不敢。 软件行业实例：一家公司要做"双十一大促临时优惠系统"，同样是先写立项说明，再做技术可行性确认（现有优惠引擎能不能撑住峰值），然后评审决策，再指派项目经理、识别运营与财务干系人，最后开启动会把上线窗口和回滚方案讲清楚。 回到案例：超市项目的五个环节表面都走了——建议书写了、可研报告编了、高层批了、人也派了、会也开了。但它踩的坑是：第二个环节"可研"空心，第四个环节"基础工作"里派了一位跨领域的项目经理，第五个环节"启动会"没开透。 请记住这个结论：启动流程"走完"不等于"走实"。 最后再给一个实务提醒：这五个环节之间是输入输出的关系——建议书是初步可行性研究的输入，可研报告是评估决策的输入，立项文件是制定章程的输入，章程又是启动会的依据。你只要顺着这条"文件流"去记，整条链子就不会乱。
【思政落点 1】 这里我要特别强调"程序"二字。为什么启动要一步一步走流程、留文档、做评估？不是为了增加手续，而是因为程序是最可靠的"防错机制"。现实中很多项目出问题，追根溯源就是"该走的程序没走、该论证的没论证、该签字的人没签字"。对将来做软件的你们来说，依法合规、按程序办事，既是保护项目，也是保护自己——合规不是束缚，是护栏。
板书：五环节：① 建议书（想干什么）② 可研·初/详（能不能干）③ 评估决策（干不干）④ 章程＋经理＋干系人（谁来干 · 怎么干）⑤ 启动会（大家认）｜ 压缩口诀：提 → 证 → 批 → 备 → 认
提问：五个环节里，哪一步是"可以合并、但绝不能省"的？为什么？
预设回答：
易错点 / 考点：高频简答题"项目启动包括哪些关键环节"，答题口诀"提—证—批—备—认"。案例题里如果问"启动阶段有什么问题"，要能区分流程缺失（根本没做）和流程空心（做了但没做透）——本案例属于后者，这是拉分点。
过渡：五个环节里，第二、第三步——可研与决策——全都属于"项目立项"这块内容。下一块我们就专门讲它。
口播：第二块：02 项目立项。 立项回答一个问题：这个项目到底该不该干？ 它包含四个阶段：立项申请、初步可行性研究、详细可行性研究、评估与决策。 请特别注意它的定位：立项是项目启动前的关键环节，它决定项目能不能正式进入实施阶段，也直接决定后面的章程怎么定、团队怎么建、资源怎么分。换句话说，立项是整个项目的地基。 案例里"高层迅速决策并批准启动"，就是这一步走得太快。下面我们一层层把它拆开看，先看四个阶段。 顺便说一句：立项做得好，还有一个容易被忽视的好处——它让"不干"这个决定变得容易。敢于在立项阶段否掉一个不靠谱的项目，本身就是项目管理能力的体现，因为在这一步停下来的成本最低。
板书：02 项目立项 ｜ 一问：该不该干？｜ 四阶段：申请 → 初研 → 详研 → 评估决策 ｜ 定位：项目的地基
提问：立项做扎实了，对后面哪些工作有直接影响？请至少说出三样。
预设回答：
过渡：下一页，我们把立项管理的四个阶段完整展开，还有一个"小项目可以合并、但详研不能省"的重要例外。