⋐ 13-1 ⋑ 软考高项 | 第18章：项目绩效域 [ 上 ]

绩效域	定义与关注点	通俗解释
1. 干系人 (Stakeholders)	涉及与项目干系人进行有效互动，建立积极关系。关注干系人的参与、满意度和沟通。	让相关的人都满意，别让人在背后"捅刀子"。
2. 团队 (Team)	关注打造高效的项目团队文化、领导力和环境。涉及团队建设、技能提升、领导力行为和团队氛围。	让团队有战斗力，状态在线，不"躺平"。
3. 开发方法和生命周期 (Development Approach and Life Cycle)	确定最适合项目的开发方法（如预测型、敏捷型或混合型）和项目生命周期。关注方法的选择、阶段划分和交付节奏。	想清楚活儿怎么干（是像盖楼一步步来，还是像创业试错着来）。
4. 规划 (Planning)	组织、协调和优化项目工作，规划是渐进明细且持续进行的。关注计划的制定、调整、沟通和执行。	有靠谱的计划，而且计划要随时更新，不是做完就扔墙上的。
5. 项目工作 (Project Work)	建立流程和管理实物资源，使团队能高效、有效地开展工作。关注工作流程、资源管理、采购和过程改进。	让日常工作顺畅，资源到位，不卡壳。
6. 交付 (Delivery)	聚焦于满足需求、范围和质量，最终实现项目预期的商业价值。关注质量、范围、时间、成本和客户满意度。	按时交出好东西，真的解决客户问题。
7. 度量 (Performance)	评估项目绩效并采取适当行动，以确保持续与目标保持一致。关注指标设定、数据收集、分析和决策。	随时知道项目到底干得咋样，别稀里糊涂的。
8. 不确定性 (Uncertainty)	识别和分析不确定性（风险与模糊性），建立项目的适应性和韧性。关注风险识别、应对策略、模糊性管理和适应性。	应付各种突发状况，别一有风吹草动就崩盘。

1.1 干系人绩效域

| 绩效域 | 定义与关注点 | 通俗解释 |

1. 干系人 (Stakeholders)	涉及与项目干系人进行有效互动，建立积极关系。关注干系人的参与、满意度和沟通。	让相关的人都满意，别让人在背后"捅刀子"。

1.1.1 绩效要点

识别：把和项目有关的所有干系人都找出来
理解和分析 ：搞懂这些人想要什么、态度怎么样、有多大影响
优先级排序 ：按重要程度给这些人排个先后
参与：让关键的人参与到项目里来
监督：一直盯着这些人的情况和变化

可以用干系人满意度来判断这个绩效域做得好不好。

1.1.2 与其他绩效域的相互作用

帮项目团队明确++项目需求和范围++ ，并定好++优先级排序++
让干系人一起参与++制订项目规划++
确定项目成果和可交付物的++验收标准、质量要求++
客户、高管、项目管理办公室、项目集经理这类干系人，重点盯着项目和可交付成果的绩效测量。

1.1.3 本域的预期目标和检查方法

1.2 团队绩效域

| 绩效域 | 定义与关注点 | 通俗解释 |

2. 团队 (Team)	关注打造高效的项目团队文化、领导力和环境。涉及团队建设、技能提升、领导力行为和团队氛围。	让团队有战斗力，状态在线，不"躺平"。

1.2.1 绩效要点

项目团队文化： 体现的是团队成员怎么工作、怎么互相配合 。

形成方式有两种：有意识主动形成 、非正式自然形成。
高绩效项目团队： 项目经理和团队靠这些打造高绩效团队：开诚布公沟通、达成共识、共担责任、彼此信任、协同合作、灵活适应、韧性、赋能、认可鼓励。
领导力技能：

（1）建立和维护愿景： ①用简洁有力的话 概括项目；②描述能实现的最好成果 ；③在团队心里形成共同、清晰的目标画面 ；④激发大家做好项目的热情 。

（2）批判性思维

（3）激励

（4）人际关系技能 ：情商、决策、冲突管理

**解决冲突的方法：**①尊重且坦诚沟通；②只聚焦问题本身；③关注现在和未来；④一起寻找其他方案。

1.2.2 本域的预期目标和检查方法

1.3 开发方法和生命周期绩效域

| 绩效域 | 定义与关注点 | 通俗解释 |

3. 开发方法和生命周期 (Development Approach and Life Cycle)	确定最适合项目的开发方法（如预测型、敏捷型或混合型）和项目生命周期。关注方法的选择、阶段划分和交付节奏。	想清楚活儿怎么干（是像盖楼一步步来，还是像创业试错着来）。

1.3.1 绩效要点

1.3.1.1 交付节奏

交付节奏	通俗解释	核心特点 / 常见场景
一次性交付	就像攒钱一次性买个大家电，等攒够了钱、选好了型号，最后才把东西搬回家。项目从头做到尾，中间啥都不给客户看，直到全部完工才一次性交付所有成果。	特点：项目周期长，客户中途看不到进展，风险较高，如果最后发现方向错了，返工代价大。常见场景：需求非常明确、几乎不会变更的项目，比如传统工程建设或一次性软件外包。
多次交付	好比装修房子，先做水电，验收完再做泥瓦，再做木工......每完成一个重要部分，就让业主来看一下、确认一下。项目被拆成几个组件，每完成一块就交付一次。	特点：分批交付，客户能及早看到部分成果，及时反馈调整，减少后期返工。常见场景：模块化较清晰的项目，比如开发一个系统，先交付登录模块，再交付业务模块。
定期交付	就像订杂志，每个月固定收到一期，不管内容多少，反正每月都有一本。项目按固定的时间节奏（如每两周、每月）向客户交付一些已完成的功能或成果。	特点：节奏稳定，便于双方计划，客户能定期看到进展，但交付内容可能不是完整的功能块。常见场景：长期运维服务、数据报告类项目，或迭代周期固定的敏捷开发。
持续交付	像手机App的"自动更新"，开发团队不断优化、增加小功能，用户随时都能获得新版本，不用等一年一次的大版本。项目通过自动化流程，将每一个小改动都快速、安全地交付给客户，让价值持续产生。	特点：小步快跑，响应变化快，需要高度自动化和稳定的团队，客户能持续感受到价值。常见场景：互联网产品的敏捷开发、SaaS服务，团队和客户长期合作，不断迭代优化。

1.3.1.2 开发方法

项目开发方法主要三类：预测型方法、适应型方法、混合型方法。

1.预测型方法（瀑布型方法）

核心特点 ：整个开发流程相对固定，项目的范围、进度、成本、资源、风险 ，在项目刚开始就能明确界定 清楚；项目早期就能排除大部分不确定因素，前期把规划工作做足，后期基本不会随意变更，还能套用以往类似项目的现成模板。

适用场景 ：项目一开始就能梳理、分析清楚所有需求；适合大额投资、高风险项目，这类项目需要频繁审查、严控变更，且开发阶段之间需要重新规划。

2.适应型方法

核心特点 ：项目初期先定好清晰的大方向（愿景） ，后续推进过程中，结合用户反馈、环境变化、突发情况 ，在原有需求基础上持续优化 、调整、修改甚至替换内容；敏捷方法就属于适应型方法。

适用场景 ：项目需求不确定、易变动，整个开发周期里需求会不停调整。

3.混合型方法

核心特点 ：是预测型+适应型的结合体，同时包含两种方法的特性；灵活性比预测型强，但比纯适应型弱，常用迭代、增量的方式推进。

适用场景：需求存在不确定性或风险、交付成果能拆分成模块、或是不同团队分工开发不同交付物的项目。

迭代型方法和增量型方法的区别：

迭代型方法 ：适合梳理模糊需求、摸索多种方案，在最后一轮迭代前，就能做出符合要求的完整功能。（每一次交付的都是可用的成果）
增量型方法 ：分多轮迭代产出成果，每轮迭代在固定时间内（时间盒）新增一部分功能，直到最后一轮迭代后，才算完成完整的交付成果。（每一次交付的都是局部新增的功能）

敏捷包含迭代和增量，但迭代和增量不一定就是敏捷（可能缺乏敏捷的沟通和自管理原则）。 在高项考试中，敏捷 = "迭代+增量" +以人为本的管理哲学。

1.3.1.3 如何选择开发方法（影响选择的因素）

1.产品、服务或成果

维度	预测型生命周期	适应型生命周期
创新程度	充分了解范围和需求，创新程度低	创新程度高，团队往往没有做过类似项目
需求确定性	需求易于定义，在开始前就能明确并固定	需求不确定，可能在项目过程中逐步清晰或频繁变化。
范围稳定性	范围稳定，变更很少，严格按照计划执行	范围有许多变更，通过迭代不断调整和优化
变更的难易程度	变更较为困难，通常需要经过严格的变更控制流程，成本较高。	容易适应变更，通过短期迭代和持续反馈快速响应。
交付物的性质	交付完整的最终产品、服务或成果，通常是大型项目，一次性交付。	交付可工作的组件或增量，以小步快跑的方式持续交付价值。
风险	高风险产品（如涉及关键安全需求），需在前期进行充分的风险分析和应对规划。	同样需要满足严格安全需求，但通过迭代持续识别和应对风险，将风险分散。
法规	适用于重大监管监督的环境，需严格遵循合规要求，通常需要大量文档和审批。	也需遵守法规，但可通过自动化工具和持续合规检查来适应监管环境。

2.项目

维度	预测型生命周期	适应型生命周期
干系人参与度	干系人主要在关键节点（如需求确认、阶段评审、验收）参与，不需要持续大量参加。	需要干系人大量且持续参加，如每个迭代的评审会、计划会，以便及时反馈和调整方向。
进度制约因素	进度通常有严格的时间节点，项目团队按照计划推进，按时交付。	以尽早交付价值为核心，通过将项目分解为多个小迭代，在项目早期就能交付核心功能，快速获得收益。
资金可用情况	适用于资金确定的环境，通常在项目启动前已获得批准，按阶段或里程碑拨付。	适用于资金不确定的环境，可能采用滚动拨款方式，根据项目进展和价值持续评估是否值得继续投资。

3.组织

维度	预测型生命周期	适应型生命周期
文化	具有指导文化的组织，强调按指令和计划执行，员工习惯等待上级安排，注重流程遵守。	项目团队自管理的组织，强调自主决策、跨职能协作，鼓励员工主动承担责任并持续改进。
组织结构	多层级、严格汇报结构，官僚作风明显，决策流程长，信息传递易失真。	扁平式结构，管理层级少，决策权下放到团队，沟通高效，快速响应变化。
组织能力	需要专业分工明确、流程化、计划性强，员工深耕单一领域，按部就班完成任务。	需要快速学习、拥抱变化、跨领域协作，团队成员通常具备多项技能，能灵活应对新需求。
项目团队规模与位置	通常为大型团队，成员可能分布在各地（虚拟团队），依赖文档和正式沟通。	偏好小规模团队（一般5-9人），尽量集中办公（同一物理空间），便于面对面实时沟通。
高层管理者思维模式	管理者关注计划执行、过程控制、资源分配，通过报告和指标监控项目。	管理者需要转变为服务型领导，授权团队、信任团队，关注价值交付和持续改进，支持团队自主决策。

1.3.1.4 协调交付节奏和开发方法

以社区中心项目为例：

注：自适应的开发方法： 是一种通过短周期迭代、客户持续反馈、团队自组织管理 来应对模糊需求和高变化 的项目管理方式。在高项中，它通常作为敏捷开发的同义词出现，与传统的"瀑布型"（预测型）相对应。

1.3.2 本域的预期目标和检测方法

1.4 规划绩效域

| 绩效域 | 定义与关注点 | 通俗解释 |

4. 规划 (Planning)	组织、协调和优化项目工作，规划是渐进明细且持续进行的。关注计划的制定、调整、沟通和执行。	有靠谱的计划，而且计划要随时更新，不是做完就扔墙上的。

1.4.1 绩效要点

**规划的影响因素：**做计划前先想清楚：项目受什么限制？比如：时间、钱、风险、客户要求、公司制度，这些都会影响你怎么规划。
项目估算： 大概要花多少钱、多少时间、多少人，心里先算一本账，别做到一半才发现超支、超时。
项目团队组成和结构规划： 这个项目需要哪些人、谁负责什么、怎么分工，是一个小组还是分几块，谁管谁，提前定好。
沟通规划： 项目里谁和谁说、说什么、多久说一次、用什么方式说，避免信息乱、没人知、互相甩锅。
实物资源规划： 项目要用到的设备、材料、场地、工具够不够？什么时候要？从哪来？别干到一半缺东西。
采购规划： 哪些东西自己做不了，必须外面买 / 外包，找谁买、怎么买、多少钱、多久到货，提前规划。
变更规划： 项目过程中需求改了、范围变了怎么办？走什么流程、谁批准、怎么控制，别越改越乱。
度量指标和一致性： 用什么标准判断项目好不好，比如进度、成本、质量指标，大家用同一把尺子，别各说各的。

1.4.1.1 规划的影响因素

（1）选用哪种开发方法（规划是不一样的）

**预测型（瀑布那种）**项目一开始就把计划做得差不多，后面边做边慢慢细化。
**适应型（敏捷那种）**先做一点粗略计划，每一轮迭代开始前，再细化做下一步计划。
**原型法：**先做个大概规划 → 做出个简单原型给大家看 → 再根据原型做详细计划。

（2）项目可交付物：最后要交出什么成果、做成什么东西，提前想清楚。

**（3）组织需求：**公司 / 单位有什么要求：比如制度、流程、资源、权限、标准。

（4）市场条件：外面环境怎么样：行情、竞争、客户需求、市场变化。

（5）法律或法规限制：必须遵守的法律、政策、行业规定，不能碰红线。

1.4.1.2 项目估算的影响因素

1.估算的影响因素

（1）区间：项目越往后做，估算范围越窄。刚开始：大概10～100万，后面：大概 80～90 万。

（2）准确度： 估算准不准。准确度越低，区间越大；项目越往后，估算越准。

（3）精确度： 估算细不细。"2 天" 很精确，"这周内" 不精确。≠ 准不准，只看细不细。

（4）信心： 对这个估算有多大把握。越有把握，信心越高。

2.项目估算方法

（1）确定性估算 & 概率估算

确定性估算（点估算）： 只给一个确定数字，比如：工期 36 个月、成本 100 万。简单直接，但没说准不准、风险多大。
概率估算： 给一个范围 + 可能性 。比如：成本 90～110 万，有 80% 把握。怎么来的：① 多种情况算加权平均 ② 用模拟工具算概率

（2）绝对估算 & 相对估算

绝对估算： 直接给具体、实打实的数字，比如：10 万、5 天。用真实数据估。
相对估算： 不直接给数，跟别人比。比如：A 任务是 B 任务的 2 倍大，先定 B，再推 A。

（3）基于工作流的估算

看流程速度来估：

周期：一件事从头到尾做完要多久。
产量：单位时间能做完多少件。用**"速度"** 来算整体工期 / 工作量。

（4）对不确定性的调整估算

项目都有不确定、有风险 。做法：在估算上加一笔应急储备 ，调整交付时间或成本，防止意外翻车。

**一句话：**估算要么给一个数，要么给范围概率；要么直接给数，要么对比着估；还能按流程速度估，最后加余量防风险。

1.4.1.3 度量指标和一致性

1.度量指标

就是项目里用来衡量做得好不好的尺子。

要定清楚：看什么指标、标准是多少、差到多少就必须管。
还要定好：怎么检查、怎么评估。
原则：只测重要的，别啥都测。

2.一致性

就是规划和实际要对得上，不打架。

做出来的成果要跟需求一致。
材料、配送计划要跟交付要求一致。
测试计划要跟质量、交付要求一致。从头到尾都要统一、不乱。