信息系统项目管理师教程（第4版）笔记——第 9 章 项目范围管理

第 9 章 项目范围管理项目范围管理就像给项目 “画边界”核心是确保项目 “做且只做所需的全部工作”—— 既不遗漏必要任务也不额外增加无关工作避免 “范围蔓延”没批准的工作乱加或 “范围遗漏”该做的没做最终顺利交付符合要求的产品 / 服务 / 成果。9.1 管理基础9.1.1 产品范围和项目范围“范围” 在项目中有两个核心含义两者是 “目标” 和 “路径” 的关系产品范围指产品 / 服务 / 成果的特征和功能“做什么”比如 “一款能查询订单、支付的 APP”衡量标准是产品需求是否满足项目范围指为交付上述产品所需完成的全部工作“怎么做”比如 APP 的需求分析、设计、开发、测试衡量标准是项目管理计划是否完成。简单说产品范围是 “最终要交的东西有啥用”项目范围是 “为了交这个东西要做哪些事”。9.1.2 管理新实践随着项目环境变复杂范围管理更注重 “专业分工 伙伴合作”核心合作项目经理 商业分析师两者是伙伴关系商业分析师职责确定业务需求、收集 / 管理需求、推荐解决方案、推动产品成功应用项目经理职责确保需求管理活动纳入计划、在预算和时间内完成创造价值。简单理解商业分析师 “管需求”项目经理 “管落地”分工明确才能少走弯路。9.2 项目范围管理过程9.2.1 过程概述项目范围管理包含 6 个核心过程环环相扣覆盖 “从定规则到验收” 的全流程规划范围管理制定 “范围管理操作手册”明确如何定义、确认、控制范围收集需求搞清楚干系人想要什么为范围定基础定义范围细化项目和产品的详细描述划清边界创建 WBS把大工作分解成小模块方便管理确认范围让干系人正式验收已完成的可交付成果控制范围监控范围状态管理范围基准的变更。9.2.2 裁剪考虑因素每个项目的范围管理方法要 “量身定制”需考虑 5 点知识和需求管理组织是否有需求复用体系、需建立哪些指南确认和控制组织是否有正式的范围确认 / 控制政策开发方法是预测型需求明确、敏捷 / 迭代型需求多变还是混合型需求稳定性需求是否不稳定是否需要用敏捷技术处理治理组织是否有审计和治理规范。9.2.3 敏捷与适应方法适合需求多变、风险高的项目核心特点是 “边做边明确范围”早期不纠结详细范围把时间留给后期细化迭代中重复开展 3 个过程收集需求→定义范围→创建 WBS干系人持续参与每次迭代后反馈调整产品未完成项需求清单范围基准不是固定的而是通过迭代中的需求优先级调整。对比预测型预测型是 “先定好全部范围再做”敏捷是 “边做边定范围”。9.3 规划范围管理规划范围管理是制定 “范围管理的游戏规则”仅开展一次或预定义时点开展确保后续范围工作有章可循。9.3.1 输入项目章程提供高层级需求和项目概述比如 “交付一款电商 APP”项目管理计划参考质量管理计划、项目生命周期描述、开发方法比如预测型还是敏捷事业环境因素组织文化、基础设施、市场条件等比如组织是否鼓励灵活调整范围组织过程资产历史项目的范围管理经验、模板等。9.3.2 工具与技术专家判断找有类似项目经验的人提建议比如 “之前做电商 APP 的范围管理怎么规划的”数据分析备选方案分析比如 “是先收集所有需求再定义范围还是迭代收集”会议召集项目经理、发起人、团队成员等一起制定范围管理计划。9.3.3 输出范围管理计划明确 “怎么定义、确认、控制范围”比如 “范围变更需提交 CCB 审批”需求管理计划明确 “怎么收集、分析、记录、跟踪需求”比如 “需求优先级按业务价值排序”。简单说这两个计划就是 “范围和需求管理的操作手册”。9.4 收集需求收集需求是 “摸清干系人到底想要啥”为范围定义打基础仅开展一次或预定义时点开展需求收集不准是项目失败的重要原因。9.4.1 输入立项管理文件商业论证比如 “项目要解决用户购物不便的问题”项目章程高层级需求比如 “APP 要支持扫码支付”项目管理计划范围管理计划、需求管理计划、干系人参与计划项目文件假设日志比如 “假设用户会基本手机操作”、干系人登记册谁能提供需求、经验教训登记册协议外部项目的合同比如客户要求 “APP 要兼容 iOS 和 Android”事业环境因素和组织过程资产组织文化、历史需求收集经验等。9.4.2 工具与技术工具很多按需选择通俗解释如下专家判断找业务专家、技术专家帮着梳理需求比如 “电商行业的核心需求有哪些”数据收集头脑风暴大家一起发散思维收集创意比如 “APP 还能加哪些便民功能”访谈一对一深入沟通比如和客户高管聊 “APP 的核心业务目标”焦点小组由主持人引导干系人互动讨论比如找 10 个目标用户聊 “注册流程怎么设计才方便”问卷调查设计问卷快速收集大量反馈比如面向全国用户调查 “是否需要夜间模式”标杆对照和行业优秀案例对比比如 “参考淘宝的下单流程设计我们的”数据分析文件分析比如分析客户的业务流程文档找需求决策投票大家投票选优先级比如 “先做支付功能还是搜索功能”独裁型决策一个人拍板比如紧急项目由项目经理决定多标准决策分析用矩阵打分比如按 “业务价值、技术难度” 给需求打分排序数据表现亲和图把零散创意分组比如把 “扫码支付、指纹支付” 归为 “支付方式” 组思维导图把创意整合可视化比如中心是 “APP 功能”分支是 “注册、登录、购物、支付”人际关系与团队技能名义小组技术结构化头脑风暴先写想法→记录→讨论→投票观察和交谈现场看用户工作比如看超市收银员怎么操作找 “收银 APP” 的需求引导组织研讨会协调干系人达成共识比如协调市场和技术部门对需求的分歧系统交互图画图表展示系统和人的交互比如 “用户→APP→支付系统” 的交互流程原型法做个简易模型让用户体验比如画 APP 界面草图让用户试 “点击哪个按钮能下单”适合需求不明确的情况。9.4.3 输出需求文件详细记录所有需求按类别划分每个需求要明确、可测量业务需求组织高层目标比如 “提升用户购物转化率”干系人需求干系人的具体期望比如 “运营人员要能导出销售报表”解决方案需求产品必须具备的能力分两类功能需求产品要做的动作比如 “查询历史订单”“修改收货地址”非功能需求产品的质量要求比如 “查询响应时间≤1 秒”“系统稳定性 99.9%”过渡和就绪需求临时需求比如 “用户数据从旧系统迁移到新 APP”项目需求项目本身的要求比如 “3 个月内上线”质量需求验收标准比如 “订单支付成功率≥99.5%”需求跟踪矩阵一张表格追踪每个需求从 “来源” 到 “交付” 的全过程比如 “需求扫码支付→来源客户→可交付成果支付模块→测试案例扫码支付测试”避免需求遗漏或失控。9.5 定义范围定义范围是 “把收集到的需求整理成详细的项目边界”明确 “做什么、不做什么”整个项目期间可能多次开展。9.5.1 输入项目章程高层级描述和产品特征项目管理计划范围管理计划项目文件假设日志、需求文件收集需求的输出、风险登记册比如某风险可能导致范围调整事业环境因素和组织过程资产组织文化、历史范围定义模板等。9.5.2 工具与技术专家判断找有类似项目经验的人帮着细化范围数据分析备选方案分析比如 “实现支付功能是自研还是对接第三方支付”决策多标准决策分析按 “成本、时间、风险” 给方案打分人际关系与团队技能引导协调干系人对范围的共识产品分析把高层需求细化为具体特征比如把 “用户友好” 细化为 “注册流程≤3 步”“有操作引导提示”常用方法有产品分解、需求分析、系统工程等。9.5.3 输出项目范围说明书详细描述项目边界核心内容包括产品范围描述产品的特征和功能比如 “电商 APP 支持商品浏览、下单、支付、售后查询”可交付成果项目要产出的东西比如 “APP 安装包、用户手册、测试报告”验收标准可交付成果通过的条件比如 “APP 无致命 bug、核心功能 100% 可用”除外责任明确不包含的工作比如 “本项目不包含 APP 上线后的运维服务”避免范围蔓延项目文件更新假设日志新增范围相关的假设比如 “假设第三方支付接口能按时对接”、需求文件调整需求细节、需求跟踪矩阵同步更新、干系人登记册补充干系人对范围的新意见。简单说项目范围说明书就是 “项目的边界协议”让所有干系人清楚 “项目到底管什么、不管什么”。9.6 创建 WBS创建 WBS工作分解结构是 “把大项目拆成小模块”像把一块大蛋糕切成方便吃的小块仅开展一次或预定义时点开展核心是 “化整为零、便于管理”。9.6.1 输入项目管理计划范围管理计划项目文件需求文件、项目范围说明书事业环境因素行业 WBS 标准比如建筑行业的 WBS 模板组织过程资产历史项目的 WBS 模板、经验教训。9.6.2 工具与技术专家判断找有类似项目经验的人指导分解分解核心技术把项目可交付成果逐层拆分为更小的组件直到工作包WBS 最低层步骤如下识别可交付成果和相关工作比如 “电商 APP 项目” 的可交付成果有 “需求分析报告、设计稿、APP 开发、测试”确定 WBS 结构按阶段或可交付成果按阶段拆分比如 “需求分析阶段→设计阶段→开发阶段→测试阶段”按可交付成果拆分比如 “APP 功能模块→用户手册→测试报告”自上而下逐层细化比如 “开发阶段→前端开发→后端开发→接口开发→前端开发→商品模块、支付模块”分配标识编码比如 “1.0 开发阶段→1.1 前端开发→1.1.1 商品模块”核实分解程度是否能估算成本和进度。分解的 8 个注意事项关键面向可交付成果所有工作都是为了产出可交付成果比如 “测试工作” 是为了产出 “测试报告”符合项目范围下一层所有工作之和 上一层工作100% 原则比如 “前端开发” 的工作包加起来刚好是 “前端开发” 的全部内容底层支持计划和控制工作包能估算成本、进度方便管理每个元素有人负责独立责任原则避免 “没人管的工作”控制在 4-6 层太多层不好管理大项目可拆成子项目再做 WBS包含项目管理工作和分包工作比如 “项目管理” 要拆成 “计划制定、进度跟踪、风险管控”干系人参与让客户、团队、发起人一起讨论避免遗漏可修改不是一成不变范围变更后要同步调整 WBS。9.6.3 输出范围基准经过批准的范围说明书 WBSWBS 词典是控制范围的依据不能随意变更WBS层级分解的工作结构比如示例中的 “价值管理系统项目” 拆分为需求评估、标准制定等工作包WBS 最低层可独立管理比如 “商品模块前端开发”规划包介于控制账户和工作包之间工作内容已知但进度活动未知比如 “后端开发” 暂时拆到 “数据库设计”具体开发步骤后续细化WBS 词典详细描述每个 WBS 组件的信息比如工作包的负责人、成本估算、验收标准、所需资源项目文件更新假设日志新增分解相关的假设、需求文件调整需求对应的工作分解。简单说范围基准是 “项目范围的正式蓝图”后续工作都要对照这个基准来。9.7 确认范围确认范围是 “让干系人正式验收已完成的可交付成果”比如客户验收 “APP 的支付功能”核心是 “正式认可”整个项目期间定期开展。9.7.1 输入项目管理计划范围管理计划、需求管理计划、范围基准项目文件需求文件、需求跟踪矩阵、质量报告控制质量的输出证明成果质量合格、经验教训登记册工作绩效数据比如 “已完成的可交付成果数量”核实的可交付成果经过控制质量检查合格的成果比如 “测试通过的支付模块”。9.7.2 工具与技术检查也叫审查、巡检比如客户亲自操作 APP 的支付功能验证是否符合要求决策投票比如多个干系人投票是否验收通过。9.7.3 输出验收的可交付成果经过干系人正式签字批准的成果比如 “客户签字确认支付模块验收通过”将提交给结束项目或阶段过程变更请求未通过验收的成果比如 “支付模块偶尔卡顿”需要提出缺陷补救请求工作绩效信息记录验收结果比如 “3 个可交付成果中 2 个通过验收1 个未通过”项目文件更新需求文件记录验收结果、需求跟踪矩阵同步验收状态、经验教训登记册记录验收中的问题比如 “下次验收前要提前给干系人做操作培训”。确认范围 vs 控制质量关键区别确认范围关注 “成果是否被接受”干系人认可控制质量关注 “成果是否合格”符合质量标准顺序通常控制质量先做先查质量对不对再做确认范围再查是否接受也可同时进行。干系人关注点不同管理层关注范围对进度、资金、资源的影响比如 “验收延迟会不会超预算”客户关注产品范围成果是否满足使用需求比如 “APP 能不能解决购物不便的问题”项目经理关注制约因素时间、资金、资源是否足够风险是否可控团队成员关注自己负责的工作比如 “我负责的模块是否通过验收时间是否够”。9.8 控制范围控制范围是 “监控范围状态管理范围基准的变更”核心是 “防止范围跑偏”整个项目期间持续开展。9.8.1 输入项目管理计划范围管理计划、需求管理计划、变更管理计划、配置管理计划、范围基准、绩效测量基准项目文件需求文件、需求跟踪矩阵、经验教训登记册工作绩效数据比如 “收到的变更请求数量、已完成的可交付成果数量”组织过程资产范围控制相关的政策、模板等。9.8.2 工具与技术数据分析偏差分析对比范围基准和实际结果比如 “计划开发 3 个模块实际只开发了 2 个偏差原因是什么”趋势分析看范围绩效变化趋势比如 “最近 2 个月变更请求越来越多是否有风险”。9.8.3 输出工作绩效信息范围绩效的详细情况比如 “变更请求中 80% 是合理的20% 是无关的”“范围偏差在可接受范围内”变更请求针对范围偏差提出的纠正措施比如 “补充未完成的模块开发”或基准变更比如 “新增一个必要的功能模块调整范围基准”项目管理计划更新范围管理计划、范围基准、进度基准范围变更可能影响进度、成本基准范围变更可能影响成本、绩效测量基准项目文件更新需求文件、需求跟踪矩阵、经验教训登记册记录范围控制的有效方法比如 “变更请求要先评估影响再审批”。关键提醒范围基准变更必须走正式的变更控制流程比如提交 CCB 审批不能随意调整。