项目范围管理怎么做？4个步骤明确边界、分工与验收

项目范围管理，核心是把三件事说清楚：这次交付什么、明确不做什么、怎样才算交付完成。需求清单只是起点；如果没有边界、验收标准和变更规则，团队仍可能一边开发一边加功能，直到原定的时间和预算都不够用。

可以按四个步骤推进：制定范围管理计划，收集需求并确定边界，创建工作分解结构（WBS），最后按约定验收并处理变更。下面以一个计划六周交付的“售后退款进度改版”为例，说明每一步需要留下什么成果。团队讨论时，可以把需求、范围说明和任务拆解放在Boardmix博思白板的同一张画布上，减少不同成员各拿一份清单、理解却不一致的情况。

1. 制定项目范围管理计划：先约定谁决定、按什么决定

项目范围管理应从前期准备开始。和团队一起梳理项目的相关信息，通过头脑风暴确定相关干系人，再把讨论中的决定写下来。不过，范围管理计划不等于把所有需求列出来：它首先要说明需求怎样收集、范围由谁批准、成果由谁验收、变更怎样处理。

退款改版的起点不是“做一个完整售后系统”，而是“让用户能看见退款当前处于哪个环节，并知道下一步该做什么”。本期沿用既有单笔退款规则，不改变审批权限或支付处理方式。项目负责人应先邀请客服、产品、设计、研发和测试讨论这个目标。客服解释咨询问题，研发说明现有退款状态能否取得，产品负责人决定交付边界；不能只由提出需求的人决定，也不能把最后的取舍留给开发者。

这里要区分三份容易混用的材料：项目章程说明为什么启动项目、总体目标和授权；范围说明书写本次具体交付什么；范围管理计划规定这些内容如何确定、验收和变更。小项目可以放在同一份文档中，但三类问题都要有答案。

有关项目计划，还可以使用项目计划模板，列出各阶段要完成的主要工作。在 Boardmix 画布中，将“范围约定”和“任务进度”相邻摆放：讨论新增任务时，先对照范围，再决定是否调整时间，避免排期表不断加行，却没人重新确认交付目标。

可以从Boardmix模板中心查找项目计划模板；进入后先填项目目标和参与角色，再按实际阶段调整表格。

2. 收集项目需求：把诉求转成边界和验收标准

收集需求是一个发现过程。客户可能说不清完整的产品愿景，却能描述在哪个环节遇到了问题。团队可以通过研讨会、访谈和使用记录了解这些问题；记录时保留具体情境，而不是只记“体验不好”“操作要更方便”等笼统结论。

例如，客服转来的“退款太慢”至少可能指三种情况：实际到账耗时长、用户不知道处理进度、用户缺少材料却没收到提醒。三者需要的方案不同。若当前问题是进度不透明，增加状态解释和下一步指引才对应这次目标；直接增加自动退款规则，已经涉及另一类工作。

用户体验地图适合把这种差别展开。下面的小红书用户体验地图按阶段记录行为、情绪、评价、痛点和需求，其中售后环节出现“不知道找谁”的问题。借用这套观察顺序，退款改版可以依次梳理“提交申请—等待处理—补充材料—查看结果”，把每个阶段看不到的信息单独列出。

在小红书用户体验地图社区页可以查看这一结构。使用自己的项目材料时，替换为实际触点、用户原话和已确认的问题；没有访谈或工单支持的判断，先作为待确认问题记录。

收集需求后，还可以用原型让用户完成具体任务，例如“找到这笔退款的当前状态，并说出是否需要补充材料”。观察能否找到信息、怎样理解文案，比单问“你喜欢这个页面吗”更能帮助确定需求。行业案例可用于拓宽方案，但不能替代对本项目用户问题的确认。

用一张范围表决定做什么、不做什么

有了一系列功能、业务目标和限制后，就可以定义范围。不是所有收集到的元素都要进入本期。下面这张表把退款改版的边界落到可讨论的事项上；六周是这个项目的交付约束，不是所有同类项目的通用工期。

“页面体验良好”不能直接用于验收。把它改成“用户能看见当前状态，需补充材料时能找到入口，异常时有明确提示”，讨论才有落点。涉及到账时间等对外承诺的文案，应由实际负责该业务规则的人确认，不能由项目组自行填写。

更完整的项目范围说明书还应写明交付物、假设和约束。重点不在文档篇幅，而在于遇到一个新要求时，团队能判断它是否改变已经约定的成果。

3. 创建工作分解结构（WBS）：把交付成果拆到可负责的层级

这一步帮助团队把范围可视化，再分解成便于管理的工作包。工作分解结构是围绕可交付成果展开的分层框架；它回答“为了交付这些成果，需要完成哪些工作”。不要只写“产品做需求、研发做开发、测试做测试”，否则责任看似分好了，具体成果和遗漏却看不出来。

退款改版可以拆为四组成果：状态规则、用户页面、接口对接、验收与交接。再逐层细分，例如“用户页面”包含进度展示、补充材料指引和异常提示。每个最末级工作包都应有人负责、能估算工作量，并能判断何时完成。过细拆到每次沟通、每次点击，反而不利于维护。

检查完整性时，从范围表逐项追到工作包：既然承诺异常提示，WBS 中就要有设计、实现和验证它的工作；既然承诺客服能解释状态，就不能漏掉客服交接。反过来，如果工作包里突然出现“自动审批引擎”，就要检查它是否越过了本期边界。

Boardmix 社区中的 WBS 工作分解结构表可以帮助整理分解编号、责任人和资源。下图用客户考察项目演示表格结构，责任、辅助、通知和审批角色分别记录；用于退款改版时，应改成自己项目的工作包和角色，而不是直接照抄任务名称。

可前往包含WBS工作分解结构表的项目管理模板集查看具体字段。如果还不清楚拆分层级，先阅读WBS工作分解结构图的绘制方法，再决定哪些部分需要继续细分。

WBS 确定后，才能进一步安排先后顺序、投入人员和预计时间。PMI关于WBS的说明强调完整覆盖项目工作与可交付成果。对应到这次改版，就是不要只拆页面开发，而漏掉规则确认、异常处理、验收和交接。

4. 验证项目范围：按成果验收，让新增需求有明确去向

开始执行前，需要由相关干系人确认范围及其边界；交付过程中，还要对照验收标准检查已经完成的成果。这是两次不同的确认：前者约定要做什么，后者确认实际交付是否符合约定。签过一份范围说明，不等于后面的所有成果已经通过验收。

退款页面完成后，可以按第二步的范围表逐项检查。正常状态显示正确，但“需补充材料”无法进入提交页面，就属于已承诺成果尚未完成；客服此时提出“增加批量自动审批”，则是新需求。前者按原验收标准记录差异并安排处理，后者评估对范围和计划的影响，不能混在同一份“新增需求”清单中。

中途加一个功能，怎样作出取舍

假设第四周有人提出增加短信通知，先问清楚：通知谁、在哪个状态发、由哪个系统发送、失败后怎么办。研发估算和供应方条件尚未明确前，不要直接答应“顺手加上”。把影响写清后，决策通常落在三种选择中：

• 本期加入：如果是必须解决的关键问题，确认增加所需的资源或交付时间，并更新验收条件。
• 替换已计划内容：若六周期限不可变，说明准备移出哪一项工作，以及这项取舍是否仍能满足项目目标。
• 后续再做：保留需求来源、价值和暂缓理由，纳入后续规划，避免下次重新讨论时丢失背景。

一条可用的变更记录可以这样写：“新增退款状态短信通知；原因是用户离开页面后无法得知需补充材料；影响范围包括通知服务、发送规则、失败处理和测试；决定暂不纳入本期，先完成页面指引，下一期结合通知服务条件评估；决定由业务负责人确认。”如果选择本期加入，还应补上调整后的时间、负责人和范围版本，不能只在群聊里留一句“同意”。

甘特图跟踪时间，验收表跟踪是否交付

项目进行时，要持续比较已完成工作与计划工作。甘特图能帮助看清任务时间、先后关系和进度偏差；但进度条走到终点，并不能证明范围已经全部完成。退款页面按时上线却缺少异常处理，仍需要回到范围表和验收记录发现问题。

需要组织时间安排时，可查看技能中心工作甘特图模板的布局，把横轴改成项目周次，再填入自己的工作包。每次检查进度时，同时看未通过的验收项和已批准变更，避免只关注“做了多少”，忽略“答应交付的是否都完成”。

项目范围管理允许变化，但变化应经过理解、取舍和确认。APM对范围管理的说明同样强调范围内外的边界，以及不同项目生命周期下的管理方式。固定交付窗口的项目要决定窗口内做什么；持续迭代的产品也要明确当前迭代承诺，不能把需求池全部当作当前范围。

实际开始时，不必一次准备很厚的文档。先把范围约定、需求与排除项、WBS、验收和变更记录组织清楚，让团队能沿着同一个需求追到任务、成果和决定。打开Boardmix工作区后，可以用文本、便签和表格将这些材料放在一张画布上，从六周退款改版这样的具体项目开始，逐项补齐自己的交付边界。