<!-- 第2章 讲稿分片 C ｜ 覆盖课件 2.15–2.21 ｜ 依据：_扩写规范.md、_v1要点版、课件 _build2.py SLIDES 15–21、教案第02章 -->
口播：我们先给职能型组织结构下一个定义——它是按照专业职能来划分部门的组织：财务部、人力资源部、市场部、技术部，各管一摊，每个部门负责自己领域的业务。 这种结构最像什么？最像一所大学：教务处、学工处、财务处、各个二级学院，各管一段；也像一家医院，内科、外科、放射科、检验科，各有各的专业领地。放到软件公司里，就是技术部、测试部、实施部、运维部这么排。 那么项目来了怎么办？通常是从技术部抽三个开发、测试部抽一个测试，临时拼一个项目组，项目经理往往由某个部门的经理兼任。注意了，这就是职能型的要害——项目经理是"借人干活"，人还是部门的。 它的优点有三条。第一，人员配置灵活，技术专家可以同时为多个项目提供支持——同一位数据库专家，上午帮 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／赋予合法地位／设定总体目标／关联组织战略 → 授权书 ＋ 责任书
提问：项目章程和"需求说明书"是一回事吗？如果只能写一页，你先写哪个？
预设回答：
易错点 / 考点：必考两处——① "项目章程批准＝项目正式启动"；② 章程的四大作用（简答题高频）。辨析题常考"章程≠需求说明书"：章程管授权与边界、高层级；需求管细节、可追溯。 还有一个易错点：项目经理在章程这件事里是"被任命、被授权"的一方，不是自己写自己批——批准人是发起人或更高层。
过渡：章程不是凭空写出来的作文。它依据什么材料写、由谁来写、产生哪些成果？接下来三页，我们分别讲依据、方法和结果。