课程：软件项目管理（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 章，软件项目启动。 上节课我们建立起了整门课的"地图"：什么是项目、什么是软件项目、生命周期、五大过程组、十大知识领域、八大绩效域。从今天起，我们沿着这张地图往前走，走到项目生命周期的第一步：启动。 这一章其实只回答四个问题：这个项目该不该干？谁来干？凭什么授权他干？开工之前，大家有没有把话说清楚、把共识立起来？ 我们还会跟着一个案例走到底——某大型连锁超市的智能库存管理系统。它在启动阶段踩了哪些坑，后面又是怎么一步步"还债"的，今天全部讲透。 请把这句话记在笔记本第一行：项目启动是项目的"第一粒扣子"，第一粒扣错了，后面九成的日子都不好过。 今天的节奏是：先看案例，再依次讲启动概述、项目立项、项目准备工作、识别干系人、制定项目章程、项目启动大会。
板书：第 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 项目立项 ｜ 一问：该不该干？｜ 四阶段：申请 → 初研 → 详研 → 评估决策 ｜ 定位：项目的地基
提问：立项做扎实了，对后面哪些工作有直接影响？请至少说出三样。
预设回答：
过渡：下一页，我们把立项管理的四个阶段完整展开，还有一个"小项目可以合并、但详研不能省"的重要例外。
口播：项目立项是项目启动前的关键环节，它决定了项目是否能够正式进入实施阶段，也为后续的项目章程制定、团队组建、资源分配等环节提供基础。这句话里有两个信息：一是"前置"，二是"打基础"。 立项管理分四个阶段，请按顺序记牢： ① 项目建议与立项申请——把想法写成文件，正式提出"我想干这件事"； ② 初步可行性研究——先粗筛一遍，看看值不值得花更多的钱和时间去做深入研究； ③ 详细可行性研究——全面深入论证技术方案、市场、投资、风险，为项目决策提供详实依据； ④ 项目评估与决策——由第三方评估，拍板定案。 这里有一个非常重要的例外：小型项目可以合并初步可行性研究和详细可行性研究阶段，但详细可行性研究不可或缺。为什么？因为详研是决策的唯一依据，省掉详研，评估和决策就成了无源之水。 生活化类比：这四步很像买房。先在脑子里种草（建议申请），再上网看看这个小区大概什么价位、有没有明显硬伤（初研），然后实地看房、查产权、算月供、问学区、看物业（详研），最后请评估机构估价、自己签字成交（评估决策）。前两步花的是时间和心思，第三步花的是真金白银——所以顺序上一定是先初研、再详研，不能一上来就请评估机构。 软件行业实例：一家银行要上线"智能客服"，先写立项申请；初研阶段发现现有语料严重不足，果断暂停，只损失了两周调研时间；另一个项目初研顺利，详研阶段测出高峰期并发撑不住，于是调整了技术方案和采购预算——花在可研上的时间，都是在替开发阶段省钱。 回扣案例：超市项目"高层迅速决策并批准启动"——快是好事，但如果技术可行性这一步没有做扎实，快就等于把风险往后推。今天省下的两周调研，后面要用几个月的返工来还，还要搭上团队士气和客户信任。
板书：立项四阶段：① 建议申请 ② 初研（粗筛）③ 详研（全面论证）④ 评估决策 ｜ 例外：小项目可合并初/详研，但详研不可省 ｜ 类比：种草 → 网上看 → 实地看 → 请评估定价 ｜ 口诀：可合并，不可省
提问：既然小型项目可以合并两个可研阶段，那"合并"的正确做法是什么？
预设回答：
易错点 / 考点：判断题高频考点——"小型项目可以不做详细可行性研究"是错的。口诀："可合并，不可省"。另外注意四阶段的排序题，评估决策一定在详细可行性研究之后。
过渡：四个阶段里，第一阶段要产出的核心文件，就是项目建议书。下一页我们专门讲它。
口播：项目建议书是项目建设单位向上级主管部门提交的关键文件。 它依据什么来写？课件列得很清楚：国民经济趋势、国家及地方规划、产业政策、市场需求、项目所在地条件，以及本单位的战略。请注意，这些依据都不是"我们内部想不想"，而是外部大势＋自身战略的结合——立项不能脱离大环境。 它的核心内容有四块，请大家记牢： ① 项目背景和必要性——项目为什么开展，要解决什么问题； ② 市场分析与预测——市场现状是什么，未来趋势怎么走； ③ 预期成果与市场定位——产出什么东西，面向哪一类市场群体； ④ 实施所需必要条件——需要哪些资源、技术、资金。 我把这四块压缩成一句口诀：为什么做（背景与必要性）、做给谁（市场与定位）、做什么（预期成果）、靠什么做（必要条件）。 特别要强调它的定位：建议书是"申请"，语气是"我建议做这件事"，它不等于批准。批准的依据，是接下来的可行性研究。很多同学写建议书时写成"我们已经决定要做"，这是越权——建议书没有决策权，只有建议权。 生活化类比：项目建议书就像求职时的自荐信——你说"我适合这个岗位、我能带来什么"，但录不录用，得看后面的笔试面试（可研）和 HR 评审（评估决策）。自荐信写得再漂亮，也不能自己给自己发 offer。 软件行业实例：一家公司要给政务客户做"一网通办"平台，建议书里必须写清政策依据、市场与客户需求、预期交付成果，以及必需的资质与数据条件——少写"资质条件"这一条，后面投标就会被卡住。 回扣案例：超市项目的建议书按流程编制了，但从案例后面暴露的问题看，它对"实施所需必要条件"里的技术条件写得太轻——智能预测算法的准确性要求、数据集成的难度，都只停留在设想，没有作为"必要条件"被认真评估。这就提醒我们：建议书的第四块不是凑数的，它是后面可行性研究的靶子。
板书：项目建议书 ｜ 依据：大势（国民经济 · 国家及地方规划 · 产业政策）＋ 市场 ＋ 项目所在地条件 ＋ 本单位战略 ｜ 四块：背景必要性 · 市场分析预测 · 预期成果与定位 · 实施必要条件 ｜ 定位：申请 ≠ 批准
提问：如果让你为"校园二手交易平台"写一份项目建议书，第①块"背景和必要性"你会怎么写？请一位同学说 30 秒。
预设回答：
易错点 / 考点：简答题"项目建议书的编制依据与核心内容"。依据容易背漏，记四类：大势（国民经济与规划、产业政策）、市场、项目所在地条件、本单位战略。判断题常考"项目建议书经批准即立项"——错，真正批准的是可行性研究与评估决策的结果。
过渡：建议书提出的是"我想做"，接下来就要论证"我能不能做成"——这就进入可行性研究。
口播：可行性研究要回答的不是"想不想干"，而是"能不能干成"。它从五个维度展开，请大家对照屏幕上的表格，一条一条看：
维度 核心要点 技术可行性 现有技术能否支持项目目标，并在规定时间内完成。例：当前技术水平下开发特定功能的可能性 经济可行性 成本效益核算：项目支出、收益、投资回报期、敏感性分析 社会效益可行性 对组织内部（品牌形象、竞争力）与社会（就业、环保）的影响 运行环境可行性 用户管理体制、人员素质、数据资源等运行环境是否适配。例：员工操作能力能否满足新系统要求 其他可行性 法律可行性（是否合法合规）、政策可行性（是否契合政策导向） 五个维度，我给大家一个记忆抓手——"能不能、划不划算、顺不顺、合不合法、还有没有别的"：技术＝能不能做得出来；经济＝划不划算；社会效益＝对组织内外有没有正面影响；运行环境＝用起来顺不顺（人、制度、数据跟不跟得上）；其他（法律与政策）＝合不合规。 判断方法上要有一个"顺序感"：技术可行性是入场券——技术上做不到，后面算得再漂亮都是零；法律可行性是一票否决——不合规，利润再高也不能干；经济可行性是决策核心——老板最终看的是划不划算；运行环境可行性最容易被忽视——系统再好，员工不会用、数据喂不进去，一样白搭。 生活化类比：这五问跟你买车几乎一模一样——这车在我这边的路况能不能开（技术）、养得起养不起（经济）、家人坐着舒不舒服、开出去有没有面子（社会效益）、我媳妇会不会开、车位够不够（运行环境）、能不能上牌、限不限行（法律与政策）。少问一条，都可能买回来一辆"停不了的神车"。 软件行业实例：一个团队做"人脸识别门禁"，技术上成熟、经济上也便宜，但它涉及个人信息采集——法律与政策可行性直接决定了这件事能不能落地；如果部署在学校，还要考虑宿管人员会不会操作、闸机数据能不能接入现有系统，这就是运行环境可行性。 回到案例：超市项目倒在哪儿？技术可行性——智能预测算法的准确性要求、数据集成的难度、自动化补货的实现方案，都没有深入论证。请记住这句话：一份"看起来齐全"的可行性报告，如果关键维度是空心的，它就是一张通行证，而不是一张保险单。
【思政落点 2】 做可行性研究，最忌讳"为了通过而论证"。数据挑好看的用、风险一句带过、测算只算乐观情形——报告是漂亮了，但坑的是团队、是公司，最后是用户。实事求是、数据说话、不回避风险，这是专业精神，也是职业诚信。 请记住：可研报告上的每一个数字，将来都要有人为它负责。
课堂练习（1 分钟）：请快速判断，下面哪一项属于经济可行性？ A．新系统上线后员工能否熟练操作 B．投资回报期是否可接受 C．是否符合《数据安全法》 D．现有技术能否实现毫秒级响应 答案：B。 A 属运行环境可行性，C 属法律可行性（归入"其他"），D 属技术可行性。做错的同学，请把五个维度再默念一遍。
板书：可研五维度：技术（能不能）· 经济（划不划算）· 社会效益（内外影响）· 运行环境（顺不顺）· 其他（法律 / 政策）｜ 顺序感：技术＝入场券，法律＝一票否决，经济＝决策核心，运行环境＝最易漏
提问：案例中的超市项目，如果要补一份技术可行性分析，你会要求团队先回答哪三个问题？
预设回答：
易错点 / 考点：选择题必考维度归属——"员工能否上手"＝运行环境可行性（最容易被错答成技术可行性）；"是否符合法律法规"＝法律可行性（归入"其他"）；"投资回报期"＝经济可行性。口诀："技术入场、法律否决、经济定案、运行落地、社会加分"。
过渡：五个维度知道了，那么可行性研究具体分几步做、报告又要写哪些内容？下一页讲两个阶段与报告结构。
口播：可行性研究分两个阶段，请大家分清它们的"分工"。 ① 初步可行性研究：初步评估项目的必要性、周期、资源等，核心目的是——判断这个项目值不值得投入更多资源去做深入研究。说白了，它是"粗筛"，防止你在一个明显不靠谱的想法上继续砸钱。 ② 详细可行性研究：全面深入分析技术方案、市场、投资、风险等，为项目决策提供详实依据。它是"细算"，是决策的直接来源。 两者的关系很像招聘：初研是简历筛选，详研是面试＋背景调查。简历阶段发现不对口，就不用浪费面试官的时间；但真正决定录不录用的，是面试和背调。 再看详细可行性研究报告的结构（表 2-2），请对照屏幕，把几个关键块记下来：
目录项 主要内容 项目背景 项目名称、承担单位、主管部门、客户、可行性研究依据等 可行性研究结论 项目目标、规模、技术方案、进度计划、投资估算、财务评价等 技术背景 / 发展现状 国家、地区、行业规划与客户需求；国内外技术历史、现状与趋势 市场调查分析 产品用途、市场调研、开发环境、市场预测等 客户现行系统情况 客户资源、现行系统功能与需求调查 项目总体目标 项目目标、技术方案、核心问题分析等 实施进度计划 阶段划分、进度安排、项目里程碑等 投资估算 总投资、资金筹措方案、投资使用计划等 项目组人员组成 组织方式、人员构成、培训计划等 项目风险 关键技术风险、需求不确定性、其他风险 经济效益 / 社会效益 经济效益预测；社会效益分析与评价 结论 / 附件 可行性研究结论与立项建议；相关文件、图表、调查数据 怎么用这张表？ 它就是一份"可研报告目录模板"。将来你写可研，照这个目录一项一项填，就不会漏项。特别注意两块——项目风险和社会效益：它们是同学们写可研时最容易漏的，而恰恰是评审专家最爱问的。 记忆抓手：把这张表想成一条线——从哪来（项目背景与技术现状）→ 给谁用（市场与客户现状）→ 做多大（目标与进度）→ 花多少（投资估算）→ 谁来做（人员组成）→ 有啥险（项目风险）→ 值不值（经济与社会效益）→ 结论附件。八步顺着走，报告的骨架就立起来了。 回扣案例：如果当年超市项目按这张表认认真真填过一遍，"项目风险"那一栏里就会写下"智能预测算法的准确性尚未验证""与现有收银和仓储系统的集成难度未知"。决策层在批准的时候，就会多问一句。表格不是形式，它是把"没想到"变成"写下来"的强制动作。
板书：初研＝粗筛（判定值不值得深研）｜ 详研＝细算（决策的直接依据）｜ 表 2-2 八步：背景与技术 → 市场与客户 → 目标与进度 → 投资 → 人员 → 风险 → 经济与社会效益 → 结论附件 ｜ 板书红圈：项目风险 · 社会效益
提问：请判断——"初步可行性研究的结论认为项目可行"，是否意味着可以直接立项了？
预设回答：
易错点 / 考点：简答题常考"初步可行性研究与详细可行性研究的区别"，答题落在两点上：目的不同（要不要继续投入 vs 为决策提供依据）、深度不同（定性粗筛 vs 全面深入）。另一个考点是可研报告结构，尤其"项目风险""社会效益"两栏，答漏了就丢分。
过渡：可研报告写完，谁来审、谁来拍板？这就是下一页的"项目评估与决策"。（如果时间紧张，表 2-2 的细节可以布置为课后阅读——请同学们课后按这个目录，为小组项目列一份可研提纲。）
口播：可行性研究做完了，谁说了算？三个要点。 第一，项目评估：由第三方依据国家政策、法规、行业标准等，从国民经济、社会影响、组织业务三个角度全面评估项目的可行性，最终输出《项目评估报告》。 第二，报告内容包括三块：项目概况——基本情况加上综合评估结论，比如是否批准项目、是否建议贷款这样明确的意见；详细评估意见——对技术可行性、经济可行性、市场需求等做细致的分析阐述；总结与建议——点明重大问题和潜在风险，提出针对性的改进措施。 第三，决策：基于评估结果，决定项目是否立项。 这一页的关键词只有三个字——"第三方"。为什么必须第三方？因为申报方和评估方不能是同一方，否则就是"自己给自己打分"。你既当运动员又当裁判，这场比赛还有意义吗？ 生活化类比：贷款买房的时候，银行不会只听你说"我这房子值五百万"，它会派自己的评估师上门估值，也可能请第三方评估机构出具报告——这就是为了防范"报高价、多贷款"的道德风险。项目评估引入独立第三方，起的是同一个作用。 软件行业实例：政府信息化项目在立项前，通常要经过专家评审或第三方咨询机构评估，从合规性、技术路线、投资合理性等角度出具意见。这也解释了为什么有的项目"申报材料很厚，但被评审专家问三句就露馅"——因为评估看的不是你的排版，看的是你的论证。 回到案例：超市项目"高层领导迅速决策并批准启动"，看上去效率很高。但如果评估环节只是"内部过一下"，技术上的空洞就没有人替决策层把关。评估与决策的价值不在快，而在于"有人替你把不该批的项目挡下来"。
【思政落点 3】 这一页的思政点非常硬核：依法合规、客观公正、独立评审。国家政策、法规、行业标准是评估的依据，这意味着立项不是"领导拍脑袋"，而是在制度和法律框架内做决策。将来你们走上工作岗位，可能会遇到"先把项目立了、手续后补"的诱惑。请记住今天这句话：程序合规是底线，科学决策是能力，独立客观是品格——既当运动员又当裁判，赢的是一时，输的是整个职业信誉。
板书：评估＝第三方（依据：国家政策 · 法规 · 行业标准）→ 评估报告（项目概况 · 详细评估意见 · 总结与建议）→ 决策 ｜ 三句话：运动员 ≠ 裁判 ｜ 独立 → 客观 → 可信
提问：如果公司内部评审会上，业务部门说"我们自己最懂，不需要外部评估"，你会怎么回应？
预设回答：
易错点 / 考点：简答题"项目评估由谁做、依据什么、评估什么"——三个采分点是第三方、国家政策法规与行业标准、国民经济／社会影响／组织业务三个角度。选择题常考"项目评估由项目申报单位自行完成"——错。
过渡：项目批了，接下来两件事最关键——选对人、搭对架子。我们进入第三块：项目准备工作。
口播：第三块：03 项目准备工作。 项目批准了，接下来两件事最关键：选对人、搭对架子。"选对人"就是指派项目经理；"搭对架子"就是选择组织结构——职能型、项目型，还是矩阵型。 为什么这两件事属于"准备"而不属于"执行"？因为它们决定了项目的权力结构：谁能拍板、谁向谁汇报、资源怎么调。这些定不下来，项目一开工就会在"到底听谁的"上面消耗时间。 提醒一句：这两件事都属于"任命与授权"的范畴，一旦宣布就很难悄悄改回来——准备阶段多花一天，执行阶段少吵一周。 案例里的第一个大坑——派了一位只有网站开发经验的项目经理，就出在这一块。
板书：03 项目准备工作 ｜ 选对人（指派项目经理）＋ 搭对架子（组织结构：职能 / 项目 / 矩阵）｜ 本质：定权力结构 ｜ 准备阶段多花一天，执行阶段少吵一周
提问：为什么"选对人、搭对架子"必须在开工之前完成，而不是边干边定？
预设回答：
过渡：我们先把"选对人"讲透——项目经理的来源、能力、职责和权力，这四项是必考点。
口播：项目经理是"派"出来的还是"选"出来的？我们先看来源，它一共两条道。 一是内部选拔——具体方式有部门推荐、PMO 指派、高层指定、人才计划选拔。它的优势是：熟悉组织文化与流程，有内部工作经验，知道谁能配合、哪道手续该找谁。 二是外部招聘——方式有公开招聘、猎头服务、合同聘用、伙伴推荐。它适用于需要特定领域经验或高技术要求的项目，比如公司第一次做人工智能项目，内部没人干过，就只能到外部去找。 生活化类比：内部选拔像球队从青训队提拔，懂战术、磨合快；外部招聘像转会引进外援，能力强、但需要一段适应期。两种都不是万能药，关键看项目的需要。 第二，项目经理的能力，四项：① 项目管理技能；② 战略与商务技能；③ 领导力；④ 技术能力。 请注意这个顺序——技术能力排在最后。这说明一个很重要的判断：项目经理不是"技术最强的人"，而是"最能带成事的人"。 技术最强的人去做项目经理，常常忍不住自己上手写代码，反而耽误了协调、决策和争取资源。 第三，项目经理的职责，七项：项目规划与目标设定、团队建设与管理、进度／资源／预算管理、沟通与协调、风险与质量管理、问题解决与决策支持、项目交付与收尾。从"定目标"到"交付收尾"，一头一尾，全生命周期都得管。 第四，项目经理的权力类型，有两种分法：按管理职责分——决策权、组织权、指挥权、人事权、经济权；按来源和作用分——职位权力、奖赏权力、惩罚权力、专家权力、参照权力。 这里有一个特别值得记的点：职位权力、奖赏权力、惩罚权力是"组织给的"；而专家权力（你的专业让人服气）和参照权力（你的人格魅力让人愿意跟）是"自己挣的"。 一个好的项目经理，靠后两种的时候更多——因为前者只能让人"服从"，后者才能让人"跟随"。 软件行业实例：互联网公司常设"技术负责人＋项目经理"双岗，讲的就是这个道理——技术负责人负责"做得对"，项目经理负责"做得成、按时交、大家还愿意跟着干"。 回扣案例：超市项目派了一位"网站开发经验丰富"的经理，去管一个"跨领域技术整合＋多部门协作"的项目——这是典型的"人岗不匹配"。启示很明确：选项目经理，要先看项目特征（跨领域吗？多部门吗？高风险吗？），再看人的能力组合，不能只看他过去做得多好。
板书：项目经理 ｜ 来源：内部（部门推荐 · PMO 指派 · 高层指定 · 人才计划选拔）／ 外部（公开招聘 · 猎头服务 · 合同聘用 · 伙伴推荐）｜ 能力：项目管理技能 → 战略与商务技能 → 领导力 → 技术能力（技术排最后）｜ 职责：规划 · 团队 · 进度资源预算 · 沟通 · 风险质量 · 决策 · 交付收尾 ｜ 权力：按职责分（决策 / 组织 / 指挥 / 人事 / 经济）· 按来源分（职位 / 奖赏 / 惩罚 / 专家 / 参照）｜ 红圈：专家权力 · 参照权力 = 自己挣的
提问：五种权力里，哪一种不需要职位也能有影响力？请举例说明。
预设回答：
易错点 / 考点：选择题高频——职能型组织结构中项目经理权力最小，项目型最大，矩阵型居中（下一页展开）；项目经理的能力顺序是项目管理技能在前、技术能力在后，考试常把顺序颠倒来迷惑你。简答题"项目经理的权力来源"要能同时答出两种分法，别只答一半。
过渡：选好了人，还要给他一个合适的"架子"——这就是接下来要讲的三类组织结构：职能型、项目型、矩阵型，我们下一页正式开始比较。
口播：我们先给职能型组织结构下一个定义——它是按照专业职能来划分部门的组织：财务部、人力资源部、市场部、技术部，各管一摊，每个部门负责自己领域的业务。 这种结构最像什么？最像一所大学：教务处、学工处、财务处、各个二级学院，各管一段；也像一家医院，内科、外科、放射科、检验科，各有各的专业领地。放到软件公司里，就是技术部、测试部、实施部、运维部这么排。 那么项目来了怎么办？通常是从技术部抽三个开发、测试部抽一个测试，临时拼一个项目组，项目经理往往由某个部门的经理兼任。注意了，这就是职能型的要害——项目经理是"借人干活"，人还是部门的。 它的优点有三条。第一，人员配置灵活，技术专家可以同时为多个项目提供支持——同一位数据库专家，上午帮 A 项目，下午帮 B 项目，人力不浪费。第二，部门内都是同行，交流方便，技术问题容易解决——前端和后端坐在一起，喊一声就能问。第三，技术连续性好，员工有清晰的晋升路径——从初级工程师到技术专家，这条路是看得见的。 但它的缺点同样致命。第一，项目支持不足、责任分散。为什么？因为部门经理关心的是本部门的活儿，项目只是"顺手帮个忙"，一旦部门自己的任务紧张，项目就排到后面去了。第二，跨部门沟通困难，容易忽视项目整体目标——各部门守着自己的考核指标，没有人对"这个项目能不能按期交付"负总责。第三，项目人员积极性较低、缺乏归属感，因为他的考核、加薪、晋升都在部门手里，不在项目手里。 那什么时候适合用职能型？给大家一个判断：业务稳定、项目小、以技术分工为主的组织。比如一家 20 人的小软件公司，常年做同一类外包项目，谁擅长什么一目了然，由一位部门经理带着就干完了，没必要给每个项目单独搭班子、单独核算。 但要特别注意：职能型最容易出事的时刻，就是跨部门协作变多的时候。 一个项目一旦牵涉三个以上部门、还要对外承诺交付日期，职能型就开始"推不动"，这时候就该考虑换结构了。 用一句话记住它：职能型，部门说了算；项目经理权力最小，通常只挂一个协调员或联络员的头衔——只能"沟通"，不能"命令"。
板书：职能型＝按专业分工（财务/人力/市场/技术）→ 部门说了算 → PM＝协调员/联络员（权力最小） ｜｜ 优：专家复用 · 同行交流 · 技术连续 ｜｜ 劣：支持不足 · 跨部门难 · 归属感低 （画"部门竖排、项目横穿"的简图）
提问：在职能型组织里，项目经理发现测试人手不够，要求测试部经理马上加派两个人，测试部经理说"我这边有别的活"，项目经理有权命令他吗？请说理由。
预设回答：
易错点 / 考点：选择题高频考点是"哪类组织结构中项目经理权力最小"——答案是职能型（项目型最大、矩阵型居中）。第二个易错点是把"人力可以复用"当成缺点：恰恰相反，人力复用是职能型的优点，"资源独占、项目间不能共享"才是项目型的缺点。记忆口诀：部门说了算，专家随便借；借来不听话，责任没人担。
过渡：职能型解决不了"集中力量打硬仗"的问题。那好，我们把人和权全部交给项目经理试试——这就是下一页的项目型组织结构。
口播：再看另一个极端：项目型组织结构。定义是——以项目为核心，项目经理全权负责项目，拥有调动资源的权力。它不再是"借人干活"，而是"连人带资源一起划给项目"。 生活里的类比是剧组：拍一部电影，导演、摄影、灯光、服化道全部为这部戏服务，戏拍完，剧组解散，人各回各家。装修队也一样，从进场到交钥匙，整队人都听工长的。 软件行业的实例：某公司要集中 80 人攻关一个为期两年的核心系统，怎么做？成立独立的项目部，开发、测试、需求、实施，甚至财务和采购的支持人员都进项目组，项目经理有自己的人事权、预算权和考核权，直接向公司高层汇报。这就是典型的项目型。 优点两条，都很硬。第一，项目经理能快速决策，项目组聚焦单一目标，进度、成本和质量能灵活控制——因为不用层层请示，也不用跟别的部门抢人。第二，每个成员只有一个领导，避免多重领导带来的冲突，沟通顺畅、责任清楚。 缺点也是两条。第一，项目组独占资源，项目之间共享不足。一个项目养一批人，项目结束前这批人不能被别的项目用；公司同时开三个项目，就要养三套测试班子，成本高，闲时浪费。第二，项目经理与成员之间的依赖性强，跨部门沟通困难；项目一旦结束，成员很难回到原来的部门，归属感受影响，职业发展路径也容易断。 再回扣一下我们的案例：如果超市的智能库存系统当初就成立一个独立项目部，由项目经理全权负责，开发、测试、业务分析、实施人员全部进组，直接向高层汇报——那么"技术方案研究不足""多部门协作扯皮"这两个坑，至少有一个会被提前暴露出来，因为没有人能再把责任推给"那不是我们部门的事"。 当然反过来看，如果只是日常的小修小补也用项目型，那就等于大炮打蚊子：人配齐了、架子搭起来了，活却只有那么一点，成本全浪费在等待和沉没上。 一句话记住：项目型，经理说了算；PM 权力最大，人、钱、事一把抓。
板书：项目型＝以项目为核心 → 经理说了算 → 人·钱·事一把抓（PM 权力最大） ｜｜ 优：决策快 · 目标单一 · 一个领导 ｜｜ 劣：资源独占 · 跨部门难 · 项目结束归属感低 （画"项目竖排、职能虚线"的简图）
提问：公司同时有三个大项目，都需要同一位安全专家。如果采用项目型结构，会发生什么？这个代价你愿意付吗？
预设回答：
易错点 / 考点：职能型与项目型的对比是必考题。记两句话：PM 权力，职能型最小 → 矩阵型居中 → 项目型最大；人力复用能力恰好相反，职能型最强 → 矩阵型居中 → 项目型最差。 另一个考点：项目型的适用场景是"大型工程或复杂研发项目"，不是"常年重复的小活"。
过渡：两个极端各有各的痛——职能型权力太小，项目型浪费太大。那能不能既要专家复用，又要项目经理说话管用？能，这就是第三种：矩阵型。
口播：第三种是矩阵型组织结构。定义是——它把职能型和项目型的特点结合起来：员工同时隶属职能部门和项目团队，项目经理与职能经理共享管理权，资源调度更高效，也促进了跨部门合作。 生活类比：大学生既是某个班的学生，又是校篮球队的队员——辅导员管你的学业，教练管你的训练，两边都是你的领导。工作里也一样：你的人坐在技术部，但你同时在为 A 项目干活，可能还要支持 B 项目。 软件行业实例：一家高科技企业同时推进 6 个客户项目，就需要复用各部门的算法专家——每位专家横向上参加一到两个项目，纵向上仍然归算法部管理。这就是矩阵型。 优点三条：充分利用各部门的技术、人才和设备；促进成员学习与知识交流；提升对客户需求的关注。 这里我要重点讲它的管理难点，也是本章的难点之一：两个领导、责权必须划清。 一个员工的绩效考核、请假、培训归职能经理；任务优先级、交付节点归项目经理。两人一冲突，员工就"两头挨骂"。所以矩阵型要真正跑起来，必须先把三件事写清楚：谁定优先级、谁考核、争议由谁裁决。这三件事不清，矩阵型就会从"高效复用"变成"互相甩锅"。 互动：三个场景，请判断更适合哪种组织结构。① 一家 20 人的小软件公司，常年做同一类外包项目；② 某公司要集中 80 人攻关一个为期两年的核心系统；③ 一家高科技企业同时推进 6 个客户项目，需要复用各部门的算法专家。 参考答案：① 职能型——项目小、业务稳定，靠部门分工最省成本；② 项目型——要集中力量打硬仗，PM 必须有权；③ 矩阵型——多项目并行，又要复用专家。 这里再补一句实务体会：矩阵型是三种结构里对管理成熟度要求最高的一种。它要求公司有清晰的考核制度、有能拍板的上级、有畅通的争议裁决通道。很多公司学矩阵型，只学到了"两套汇报线"，没学到"责权先划清"，结果就是员工双倍汇报、项目双倍扯皮。 回到案例：超市项目之所以在启动阶段就出现"沟通不畅、决策滞后"，本质上就是没有一个明确规则来回答"这件事谁说了算"。组织结构选对了，还得把规则立起来。 一句话记住：矩阵型，两个领导说了算；资源用得最省，但责权划不清就会乱。
板书：矩阵型＝职能＋项目双线并行 → 两个领导（职能经理 / 项目经理）→ 先划清三件事：优先级 · 考核 · 争议裁决 （画矩阵网格：纵轴部门、横轴项目、交叉点写人员名字）
提问：矩阵型里，职能经理要求小王这周四参加部门技术分享，项目经理要求小王这周四交出接口文档，小王该听谁的？作为项目经理，你事先该做什么？
预设回答：
易错点 / 考点：考点两句——"多项目并行且专家稀缺，宜选矩阵型"（对）；"矩阵型的主要缺点是多头领导、责权不清、多项目间进度费用质量难平衡"（对）。判断题法三步：① 项目大不大？② 项目多不多？③ 专家要不要复用？ 小且稳定→职能型；单一大攻关→项目型；多项目并行复用专家→矩阵型。口诀：小项目看职能、大攻关看项目型、多项目并行看矩阵。
过渡：组织结构这支"架子"搭好了，人也就位了。但还有一个动作没做——把"人"认全。这就是下一页要讲的识别干系人。
口播：第三个板块讲完了，我们把目光从"结构"转到"人"。项目启动阶段有一门功课，看起来最不技术，却最容易让项目翻车——识别干系人。 什么叫干系人？一句话：所有能影响项目、或者会被项目影响的组织和个人。请注意这句话有两个方向：一是"他能影响项目"——客户、领导、监管机构；二是"项目会影响他"——门店店长、收银员、供应商的送货司机。 为什么单独给它一页？因为这是启动阶段唯一一项"人"的功课，也是最容易漏项的功课：漏掉一个关键干系人，后面要多付十倍的沟通成本。 下一页我们把干系人分成内部 5 类、外部 5 类，逐类看清楚。 说得再直白一点：这一页不是在教你填表格，而是在教你做事之前先想明白——这件事会动到谁的奶酪，谁又会来动你的进度。
板书：干系人 ＝ 能影响项目 ∪ 被项目影响（两个方向都要看，缺一不可）
提问：一个人从没参加过项目会议，但系统上线后他每天都要用这套系统，他算不算干系人？
预设回答：
过渡：那到底有哪些干系人？我们看下一页这张内 5 类、外 5 类的表。
口播：先把定义钉死：项目干系人，是所有能影响项目、或受项目影响的组织和个人——内部外部都算，主动参与的算，被动关联的也算。 请看这张表，左半是内部 5 类，右半是外部 5 类。我们逐类过一遍，每一类都问三个问题：他是谁？他关心什么？漏掉他会怎样？ 内部第一类，发起人——通常是 CEO 或分管副总这样的高层领导，项目的发起者和出钱人；他关心项目值不值得做、跟公司战略合不合；漏掉他，你连资源都批不下来，出了事也没人替你说话。 第二类，项目经理——项目的整体管理者与推进者；关心目标、进度、成本、风险；这一条不用多说，漏掉他项目就没人为结果负责。 第三类，团队成员——真正写代码、做测试、写文档的人；关心自己干什么、标准是什么、有没有成长；漏掉他，任务落到谁头上都说不清，进度只能靠猜。 第四类，职能经理——在职能型和矩阵型组织里掌握人力与资源的人；关心本部门的负荷和人员发展；漏掉他，你借不到人，借到了也可能随时被抽走。 第五类，PMO——项目管理办公室，提供支持、规范流程；关心项目的合规性和报告口径；漏掉它，你在流程、模板上会反复返工。 外部第一类，客户——提出需求、验收成果的一方；关心功能能不能用、值不值这个价；漏掉他，验收时一句"这不是我要的"就能让你返工重做。 第二类，最终用户——每天真正使用系统的人，往往就是门店店长、收银员、库管员；关心好不好用、会不会增加工作量；漏掉他们，系统做得再漂亮也没人用。 第三类，供应商——提供硬件、软件、技术或服务的一方；关心合同、付款和自己的交付节奏；漏掉他，设备到不了位，你的进度表就是一张废纸。 第四类，监管机构——负责合规审查的部门；关心数据安全、隐私和行业规范；漏掉他，验收阶段可能被一票否决。 第五类，股东——项目的投资方；关心投入产出和风险敞口，他要的是"这笔钱花得值不值"。 现在把这张表回扣到我们的超市案例：业务部门、门店运营这些人，就属于最终用户（在集团口径下也可视为内部业务方）。他们恰恰没有被充分识别和参与，结果开发团队"对超市实际运营场景和库存管理需求理解不一致"，到集成测试阶段才暴露问题，直接造成返工和项目延误。漏掉一个关键干系人，后面要多付十倍的沟通成本——这句话不是修辞。 课堂练习：校园二手交易平台项目里，"学校信息安全主管部门"属于哪类干系人？核心诉求是什么？参考：属于监管类干系人（校内则为内部监管）；诉求是合规与数据安全。这类干系人的特点是——平时不出现，验收时一票否决，必须提前纳入。
| 类别 | 关键角色 | 他是谁 | 他关心什么 | 漏掉他会怎样 |
|---|---|---|---|---|
| 内部 | 发起人 | 高层领导（如 CEO），项目发起者 | 值不值得做、是否契合战略 | 资源批不下来，出问题无人背书 |
| 项目经理 | 项目整体管理者 | 目标、进度、成本、风险 | 项目无人对结果负责 | |
| 团队成员 | 直接执行核心任务的人 | 任务、标准、成长 | 分工说不清，进度靠猜 | |
| 职能经理 | 资源分配与管理（职能/矩阵型组织） | 部门负荷、人员发展 | 借不到人，或人被中途抽走 | |
| PMO | 提供支持、规范流程 | 合规性、报告口径 | 流程与模板反复返工 | |
| 外部 | 客户 | 提出需求、验收成果 | 功能可用、价格合理 | 验收被判"不是我要的" |
| 最终用户 | 使用项目成果的人 | 好不好用、是否加负担 | 系统上线没人用 | |
| 供应商 | 提供资源/技术/服务 | 合同、付款、交付节奏 | 资源不到位，进度落空 | |
| 监管机构 | 确保合规 | 数据安全、隐私、规范 | 验收一票否决 | |
| 股东 | 项目投资方 | 投入产出、风险敞口 | 后续投资与支持中断 |
板书：干系人＝影响项目 ∪ 被项目影响 → 内部 5：发起人 · PM · 成员 · 职能经理 · PMO → 外部 5：客户 · 最终用户 · 供应商 · 监管机构 · 股东 （每类旁注"他关心什么"）
提问：在一个"给学校做二手交易平台"的项目里，谁最可能被漏掉？漏掉之后，最坏的结果是什么？
预设回答：
易错点 / 考点：选择题常考"下列哪项不属于干系人"或"某角色属于内部还是外部干系人"。判断核心只有一句：能影响项目，或被项目影响——满足其一即为干系人。 两个易错：① 只把甲乙方当干系人，忘了监管、供应商、最终用户；② 以为"没有正式参与的就不算干系人"。口诀：出钱的、干活的、用的、管的、供的——五路都要认。
过渡：人认全了，接下来要做启动阶段最正式的一件事——把这些共识变成一份签了字、算数的文件，也就是项目章程。
口播：干系人认全了，接下来是启动阶段最正式的一件事：制定项目章程。 前面所有的活——建议书、可行性研究、评估与决策、选项目经理、定组织结构、识别干系人——都还是在"准备"；而章程，是把这些准备的成果写成一份有约束力的正式文件，报批、签署、生效。 有一句话请先记住：项目章程一旦被批准，就标志着项目的正式启动。 它回答的是四个问题：凭什么是这个项目？凭什么由你来管？你有多大权？什么时候算干完？下一页先讲它的定义和四大作用。 这里还要把两个概念分开：章程和合同不是一回事。 对内部项目，章程相当于公司给自己发的"开工令"；对外部客户项目，章程是在合同框架内制定的，二者不能打架。
板书：章程 ＝ 启动阶段最正式的文件 → 批准即正式启动 （旁边写四个问号：凭什么做？谁来管？多大权？何时完？）
提问：项目还没批准、章程还没签，能不能先让项目经理"先干起来"，反正效率高一点？
预设回答：
过渡：那这份章程到底长什么样、能起什么作用？看下一页。
口播：先给定义，请大家跟着我抠关键词。项目章程是项目启动阶段的一份正式文档，它全面记录三样东西——商业需求、项目论证、以及对顾客需求的理解；它明确新产品、服务或成果的交付目标；它的目的是确保干系人在三件事上达成共识：主要可交付成果、关键里程碑、项目参与者的角色与职责。 拆开看三层：第一，它是"正式文档"，不是会议纪要，更不是口头承诺；第二，它记录的是"为什么做"（商业需求、项目论证）和"顾客要什么"，而不是"具体怎么做"；第三，它管的是共识——可交付成果、里程碑、角色职责。 生活化类比：章程有点像聘书加驾照。聘书告诉你：你被任命为这个项目的负责人，你有这些权限；驾照告诉你：你能开哪一类车、上路的边界在哪里。没有这两样就上路，那叫无证驾驶。 软件行业实例：在智能库存系统项目里，章程会写明——项目目的（降低库存资金占用与商品过期损耗）、可测量的目标、总体里程碑进度计划（具体日期以签署文本为准）、项目经理及其职权、预先批准的财务资源，以及谁有权批准。写清楚了，后面跟门店、采购、IT 各部门打交道，都是"照章办事"。 四大作用，请记牢：① 任命项目经理并明确其权责；② 赋予项目合法地位——让这个项目在公司里有"名分"，别人必须配合；③ 设定项目的总体目标；④ 明确项目与组织战略目标之间的直接关联——说白了，就是让所有人知道"我们干这件事，是为了公司的那件大事"。 为什么"批准即启动"这四个字这么重要？因为从这一刻起，项目花的每一分钱、占用的每一份人力，才算有了正式出处；后面的范围、进度、成本、风险计划，才有立足点。反过来说，章程迟迟不批就大干快上，那叫无授权施工——做得越多，风险越大。 再补一个同学常问的问题：章程批了以后还能改吗？答案是——重大变更需要经过发起人或批准人同意，并走变更流程；章程本身不做日常修改。 日常调整写进项目管理计划，不要动不动就去改章程。 再用一句话收口：章程既是"授权书"——给你调人调钱的权力；也是"责任书"——目标、边界、里程碑、审批要求都白纸黑字写在那里，干不成是要交代的。
板书：章程 ＝ 正式文档（商业需求 · 项目论证 · 顾客需求理解）→ 共识三件：可交付成果 · 关键里程碑 · 角色职责 ｜｜ 四大作用：任命 PM／赋予合法地位／设定总体目标／关联组织战略 → 授权书 ＋ 责任书
提问：项目章程和"需求说明书"是一回事吗？如果只能写一页，你先写哪个？
预设回答：
易错点 / 考点：必考两处——① "项目章程批准＝项目正式启动"；② 章程的四大作用（简答题高频）。辨析题常考"章程≠需求说明书"：章程管授权与边界、高层级；需求管细节、可追溯。 还有一个易错点：项目经理在章程这件事里是"被任命、被授权"的一方，不是自己写自己批——批准人是发起人或更高层。
过渡：章程不是凭空写出来的作文。它依据什么材料写、由谁来写、产生哪些成果？接下来三页，我们分别讲依据、方法和结果。
口播：制定章程不是拍脑袋写作文，它有四类依据，缺一样都会写歪。我们一类一类看。 第一类，立项管理文件。 它包含商业需求、成本效益分析等内容，是前面立项、可行性研究、评估决策留下的成果，为决策提供依据。这里有个考点请注意：项目经理无权直接修改立项管理文件，但可以提出调整建议。 为什么？因为它是上级或评审机构批准过的文件，改它就等于改决策依据，必须走流程、留痕迹。 第二类，合同。 如果项目是替外部客户做的，合同就是法律框架：目标、范围、交付要求、付款条款都在里面。章程的很多内容，其实就是把合同语言翻译成项目语言。还要注意一条——章程不能与合同冲突，合同优先。 第三类，事业环境因素。 分内外两部分：内部包括组织文化、组织结构、设施、IT 工具、资源可用性、员工能力；外部包括市场、法律法规、行业标准、财务环境。举我们案例里的例子：门店网络条件差、收银员对电脑操作不熟练，这些都属于内部环境因素，会直接影响界面设计和培训方案——你在章程里写目标的时候，就得把它们考虑进去。 第四类，组织过程资产。 包括标准化政策、流程、程序，监督与报告机制，模板（比如公司统一的项目章程模板），以及历史数据与经验教训库。这类东西的最大价值是四个字：别重新发明轮子。上一轮项目踩过的坑，已经写成经验教训了，你照着改、照着避就行。 讲完四类依据，有两个提醒必须说。第一，项目章程是连接项目执行与需求的纽带，它要确保项目既符合组织战略目标，又能和日常运营衔接。第二，应尽早任命项目经理，最好在制定章程的时候就确认——因为章程批准之后，项目经理才获得调配资源的正式权力。太晚任命，等于开局就慢半拍。 最后呼应一下上节课：第三、第四类依据，就是第 1 章讲过的"事业环境因素"和"组织过程资产"——同一个概念，到启动阶段就要真正用起来，而不是停在名词解释上。 再补一句总结：这四类依据里，前两类管"该做什么"，后两类管"能怎么做"，一条一条对齐，章程才不会写成空中楼阁。
| 依据 | 具体内容 | 怎么用（举例） |
|---|---|---|
| 立项管理文件 | 含商业需求、成本效益分析等，为决策提供依据（项目经理无权直接修改，可提调整建议） | 章程的"项目目的"直接取自这里；发现不合理，只能提建议、走流程 |
| 合同 | 外部客户项目的法律框架，明确目标、范围、交付要求、付款条款等 | 把合同条款翻译成项目目标、里程碑与验收标准；不得与合同冲突 |
| 事业环境因素 | 内部：组织文化、结构、设施、IT 工具、资源可用性、员工能力；外部：市场、法律法规、行业标准、财务环境 | 门店网络与人员素质决定目标是否现实；外部法规决定合规底线 |
| 组织过程资产 | 标准化政策/流程/程序；监督与报告机制；模板；历史数据与经验教训库 | 直接用公司章程模板；先查经验教训库，避免重复踩坑 |
板书：章程四依据 ＝ 立项管理文件（不可直接改）· 合同（法律框架）· 事业环境因素（内＋外）· 组织过程资产（模板＋经验教训） → 两个提醒：章程是"执行与需求之间的纽带"；尽早任命 PM
提问：制定章程时，项目经理发现立项管理文件里写的效益目标明显偏高、根本达不到，他应该怎么办？
预设回答：
易错点 / 考点：简答与选择常考"制定章程的依据有哪些"，四类必须写全。三个易错点：① 把"合同"和"立项管理文件"混为一谈；② 忘记"事业环境因素"要分内部和外部；③ 误以为项目经理可以改立项文件。口诀：文件、合同、环境、资产——四路进货，一样不能少。
过渡：依据清楚了，那具体用什么方法把这些材料组织成一份章程？下一页讲五种方法与工具。
口播：有了依据，接下来用什么方法把章程写出来？五种，请先记口诀：专家、脑暴、焦点、访谈、人际技能。 ① 专家判断：请具备领域专业知识、经验和技能的个人或小组，基于对项目的深入理解给出判断。举个例子：智能库存系统里"预测算法的准确率目标定到多少才合理"，就该去问做过零售预测的专家，而不是坐在会议室里拍脑袋。 ② 头脑风暴：团队协作的创意生成方法，集思广益，短时间内产生大量想法和解决方案。它的规矩是——先求量、不批判，把话都说出来。 ③ 焦点小组：结构化讨论，由有相关背景的人组成，围绕目标、需求、风险、成功标准收集深度意见。放到案例里，就是把总部采购、门店店长、IT 运维请到一张桌上，专门谈"这个项目做成什么样才算成功"。 ④ 访谈：与干系人或专家一对一沟通，收集高层级需求、假设条件、制约因素、审批标准等关键信息。一对一的好处是：有些话，人在大会上不会说，在办公室里才会说。 ⑤ 人际关系与团队技能：通过冲突管理、引导等技巧，确保章程实际可行、各方需求都被考虑。举个具体冲突：门店希望"操作越简单越好"，IT 希望"数据实时同步"，两个诉求天然打架，这时候就需要有人把双方拉回到一个可执行的平衡点上。 生活化类比：这五种方法很像装修前的准备——找老师傅看房屋结构（专家判断）、一家人随口说想要什么（头脑风暴）、拉上设计师坐下来定风格（焦点小组）、单独问问老人用起来方不方便（访谈）、最后靠嘴皮子把争执拉回一个方案（人际技能）。 给一个判断抓手，方便你考试时对号入座：问"经验"用专家判断，问"数量"用头脑风暴，问"深度共识"用焦点小组，问"敏感信息"用访谈，问"矛盾"用冲突管理与引导技巧。 最后提示一句：这五种方法在后面范围、进度、风险各章还会反复出现，它们是项目管理的"通用工具箱"，今天先混个脸熟。
板书：方法五件套 ＝ 专家判断 · 头脑风暴 · 焦点小组 · 访谈 · 人际关系与团队技能 （下方对号：经验→专家／数量→脑暴／共识→焦点／敏感→访谈／矛盾→人际技能）
提问：要摸清"门店店长对新系统最大的顾虑是什么"，五种方法里，你优先选哪一种？为什么？
预设回答：
易错点 / 考点：选择题常问"收集高层级需求、假设条件、制约因素、审批标准，宜采用哪种方法"——答案是访谈；"短时间内获得大量想法"——头脑风暴；"邀请相关背景人员就目标、风险、成功标准进行结构化讨论"——焦点小组。易错点是把头脑风暴和焦点小组混为一谈：脑暴重"量"、重发散；焦点小组重"深"、重结构。
过渡：方法有了，依据有了，最后制出来的成果到底长什么样？下一页是本章最需要你记住的一页——11 项核心内容。
口播：制定章程的结果有两样东西：一份项目章程，和一本假设日志。 先说章程的 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 项；案例分析题常给一段文字让你判断"哪些应写进章程"。判断法则：章程写"高层级、总体、授权、边界"；细化计划、技术选型、具体任务日期不写章程。 另一个易错点是把假设日志忘掉——章程的产出是"两样"，不是"一样"。
过渡：到这儿，章程有了、经理任命了、干系人认全了。可是这些成果还锁在文档里，怎么让整个团队和所有相关方都知道、都认账？答案就在启动阶段最后一步——开好项目启动大会。
口播：最后一块内容：项目启动大会。前面所有工作都是"先把事想清楚"，启动大会是把这些成果从文件里搬出来，当着所有人的面讲清楚、认下来。 项目启动会议是项目生命周期中的关键环节，它标志着项目正式步入实施阶段，由项目经理主导，目的是确保各方干系人对项目目标、范围、需求、背景以及各自的职责有清晰认识。 一句话记住它的分量：启动大会不是"宣布开工"的仪式，而是"对齐共识"的现场。 还有一点要提醒：启动大会不是"领导讲话会"，主角是项目经理和团队——领导到场是表态支持，真正的信息传递和分工确认，必须由项目经理来完成。 下一页我们讲三件事：请哪些人、走哪几步、要拿到什么结论。
板书：启动大会 ＝ 由 PM 主导的关键环节 → 标志项目正式步入实施阶段 → 不是仪式，是对齐
提问：如果启动大会只是念一遍项目目标，团队成员各看各的手机，这会开成功了吗？
预设回答：
过渡：那启动大会具体怎么开？请看下一页——人员、流程、结论。
口播：项目启动会议是项目生命周期中的关键环节，标志着项目正式步入实施阶段，由项目经理主导，确保各方干系人对项目目标、范围、需求、背景及各自职责有清晰认识。我们讲三块。 第一块，参会人员。 内部包括：项目经理、团队成员、公司领导、PMO 代表、变更控制委员会即 CCB 成员、相关职能部门负责人。外部包括：客户代表、供应商代表等关键干系人。这里有一个细节要划重点——参会名单由项目经理审核。为什么强调这一点？因为名单就是"谁被正式纳入了项目"的证据；名单漏了谁，后面争论"这事该谁配合"时你就没有依据。 第二块，会议流程，分三段。 ① 会前筹备：确认汇报材料、议程、人员名单，完成通知与签到。别小看签到，它是"信息已传达"的书面痕迹。② 核心环节：项目经理介绍项目——目标、里程碑、分工、风险等，然后是答疑澄清，最后请公司领导做动员。③ 会后输出：生成会议纪要，记录主题、结论、待办等，作为后续跟踪的依据。 第三块，要拿到的关键结论，四条。 第一，团队对项目基本信息、目标和计划有全面了解；第二，明确项目风险识别清单及初步应对措施；第三，确定项目总体分工及下阶段工作任务；第四，增强项目团队成员的凝聚力和士气——这一条看着"软"，其实最硬，因为项目后期靠的就是这股劲。 现在回扣我们的案例：超市项目"启动了，但没启动透"——启动会上团队对整体目标只有初步理解，具体实施步骤、任务分配、风险挑战的认知仍然比较薄弱。这就是典型的"形式启动了、实质没启动"。判断一次启动会成不成功，就看三件事：目标是否对齐、分工是否清楚、风险是否上桌。
板书：启动大会三块 → 人员：内部（PM·成员·领导·PMO·CCB·职能部门）＋外部（客户·供应商），名单由 PM 审核 → 流程：会前筹备 → 核心环节（介绍→答疑→领导动员）→ 会后纪要 → 结论四条（目标计划·风险清单·分工任务·凝聚力） （右侧标注判据：目标齐 · 分工清 · 风险上桌）
提问：启动会开得很热闹，领导讲了话、大家鼓了掌，但散会后没人说得清自己的任务和交付时间。问题出在流程的哪一段？
预设回答：
易错点 / 考点：选择、判断题常考三处——① 启动会由项目经理主导（不是领导主导、不是 PMO 主导）；② 参会名单由项目经理审核；③ 会议结论包含"增强凝聚力与士气"。易错点：把启动会和项目例会混为一谈——启动会是一次性、标志性的；例会是有周期的、跟踪性的。 另一个易错点：以为启动会等于"宣布开工"，其实它的核心是对齐目标、明确分工、把风险摆上桌。
过渡：会开完了还不算结束。启动大会真正的"落地件"，是会后那份纪要，以及纪要背后的待办清单——下一页专门讲。
口播：启动大会的最后一块，是待办事项。课件里给了两条：第一，根据会议内容编制《项目启动会议纪要》，确保所有相关责任人都收到；第二，相关责任人按纪要要求开展各自工作，确保项目顺利推进。 请看表 2-4，这是项目启动会议纪要模板，我们逐行过一遍。表头部分：会议名称（项目启动会）、会议主题/时间/地点、记录人/审核人、参会人员。正文部分三块：会议内容——记录讨论事项，并分项罗列具体讨论的问题；会议结论——记录讨论结果，并针对具体问题得出讨论结论；待办事项——记录待解决的问题和待跟进的事项。 这张表最容易被当成"填空题"，我要特别强调一句：纪要不是"会议流水账"，而是"责任清单＋跟踪依据"。 什么叫流水账？就是"某年某月某日开会，领导讲话，大家讨论热烈"——这种纪要写完就进抽屉。什么叫责任清单？就是每一条待办都能回答三个问题：谁负责？什么时候完成？完成的标志是什么？ 给大家一个可以直接用的写法：待办事项不要写"尽快完成需求调研"，而要多写几个字——写成"由某某（责任人）在某个时点前（期限）提交需求调研提纲（交付物），并抄送项目经理"。多写这一句，纪要就从"记录"变成了"管理工具"。 另一个细节：模板里为什么要有"记录人/审核人"？因为纪要也需要审核确认——记录人负责如实记录，审核人负责认定结论，这样纪要在后续追责和变更时才有公信力。 最后强调一句：纪要在会后及时发出，并确保所有相关责任人都收到。没收到，等于没写；没写，等于白开。 我再补一个很实用的动作：纪要发出之后，下一次例会的第一件事就是对着待办清单逐条过——完成的项目销项，没完成的当场说明原因、给出补救计划和时间点。这样纪要才不只是"发出去了"，而是真的在推动项目往前走。 反过来提醒一句：如果待办清单写完就没人再看，这个项目很快就会进入"开会—忘记—再开会"的循环，这也正是很多项目"会开了不少、进度却没动"的原因。
| 项目 | 填写要求 |
|---|---|
| 会议名称 | 项目启动会 |
| 会议主题 / 时间 / 地点 | 写明主题与召开的时间地点 |
| 记录人 / 审核人 | 记录人如实记录，审核人确认结论 |
| 参会人员 | 按已审核名单如实登记（含签到） |
| 会议内容 | ① 记录会议所讨论的事项；② 分项罗列具体讨论的问题 |
| 会议结论 | ① 记录会议讨论的结果；② 针对具体问题得出讨论结论 |
| 待办事项 | ① 记录待解决的问题；② 待跟进的事项（每条必须有责任人和期限） |
板书：纪要 ≠ 流水账，＝ 责任清单 ＋ 跟踪依据 → 待办三要素：谁负责 · 何时完成 · 交付什么标志 → 会后动作：编制纪要 → 发到每位责任人 → 按纪要开工
提问：一份纪要里写着"待办：尽快完成门店需求调研"——这句话缺了什么？请你把它改写成可跟踪的一条。
预设回答：
易错点 / 考点：考点集中在"会议纪要的作用"和"待办事项的要素"。判断/简答常问：纪要是后续跟踪的依据，不是会议流水账；每一项待办必须有责任人和期限。易错点：把"会议内容"和"会议结论"混在一起——内容记"讨论了什么"，结论记"定下来什么"，考试给例子让你归类时要分清。
过渡：到这里，第 2 章的全部内容就讲完了。最后我们用一张全景图，把今天这条线从头到尾串一遍。
口播：今天我们用一张全景图收口，请大家跟着我一起走一遍这条知识线。 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 对策：补可研＋干系人分析＋沟通计划＋风险清单＋启动会做深做实 |