<!-- 分片 A3：2.14–2.21（项目经理 · 组织结构 · 干系人 · 章程）：由成品讲稿反向同步（以成品为准），勿单改分片 -->
口播：项目经理是"派"出来的还是"选"出来的？我们先看来源，它一共两条道。 一是内部选拔——具体方式有部门推荐、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 原句，容易只答章程）。辨析题常考"章程≠需求说明书"：章程管授权与边界、高层级；需求管细节、可追溯。 还有一个易错点：项目经理在章程这件事里是"被任命、被授权"的一方，不是自己写自己批——批准人是发起人或更高层，教材要求章程里写明"发起人或其他批准项目章程的人员的姓名和职权"。
过渡：章程不是凭空写出来的作文。它依据什么材料写、由谁来写、产生哪些成果？接下来三页，我们分别讲依据、方法和结果。