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