《守得住范围，扛得起项目—研发项目范围界定实战》

《守得住范围，扛得起项目》

研发项目范围管控实战

主讲：查理老师

【课程背景】

做研发项目的都知道，最怕的不是技术难题，是“变”。需求变、范围变、领导的想法变、客户的口风变。项目启动时说好的八个功能，做到一半变成了十二个；上线前客户突然说“再加个报表就行”，销售随口答应“这个简单”，然后活儿就落到研发头上。没人签过字，没人估过工期，但做不完就是你的事。

我们听到太多研发项目经理这样吐槽：“客户提的需求我们根本不敢拒绝”“销售答应的东西，开发团队最后才知道”“需求文档写得很清楚，做着做着就偏了”“每次评审都说‘顺便再加个小功能’，结果项目永远做不完”。

这些现象背后，是一个被反复验证的规律：项目延期、成本超支、团队加班，绝大多数不是因为技术能力不行，而是因为范围没管住。研发团队往往习惯性地把精力放在“怎么做”上，却忽视了最应该先搞清楚的问题是“做什么”和“不做什么”。范围管理不是流程枷锁，它是研发团队唯一的“护城河”——守不住它，你的工期、成本、质量全都会被冲垮。

本课程不讲复杂的项目管理理论，直接从研发一线最真实的痛点场景出发，帮团队建立一套能落地、好执行的范围管控方法，让“该做的做到位，不该做的守得住”。

【课程收益】

清晰理解范围管理核心价值，能向干系人解释范围蔓延的真实代价

运用5Why分析法与用户故事地图，有效区分“想要”与“需要”，识别伪需求

使用MoSCoW法则或Kano模型对需求进行优先级排序，合理安排开发节奏

制定符合SMART原则的验收标准，减少“做完又说不对”的返工

建立变更日志与“红灯机制”，控制自发扩范围行为

独立组织需求澄清会议，运用原型工具快速验证需求，降低理解偏差

【课程对象】

研发项目经理、产品经理、技术负责人、需求分析人员、研发团队骨干

【课程时间】

1天（6小时/天）

【课程大纲】

一、范围都管不好，凭什么保证项目不延期？

1. 范围蔓延的“温水煮青蛙”效应

什么是范围蔓延：不是一下子崩的，是一点点加的

范围蔓延的三大连锁反应——工期延误（平均超20%）、成本超支、质量被迫妥协

研发项目中最常见的三种范围蔓延路径：客户自发型、销售承诺型、团队自作主张型

案例：某企业ERP项目，因为“每个模块都加几个小功能”，最终延期3个月的完整过程拆解

2. 范围管理的核心逻辑

范围管理的本质不是“拒绝变化”，而是“透明决策”

范围基准三件套：范围说明书 + WBS（工作分解结构）+ WBS词典

一个核心原则：先管住“做什么”，再管住“不做什么”

讨论：你正在做的项目里，有哪些需求是“当初没说好，现在甩不掉”的？现场梳理并分享

二、需求源源不断，你怎么判断哪些真该做、哪些只是“想要”？

1. 识别真伪需求——不要被“用户说了什么”带偏

5Why分析法：连续追问五个“为什么”，从“想要”挖到“需要”

用户故事地图：把用户使用场景画出来，需求该不该做一目了然

区分“Want vs. Need”的核心提问话术（直接给句型，回去就能用）

案例：某电商后台“想要一个大屏数据看板”——通过5Why发现真实需求只是“每天早会能快速看到核心数据”，最终用一张简单报表就解决了

演练：给定一个模糊的客户原始诉求，小组现场用5Why法进行需求挖掘，讲师点评

2. 需求优先级排序——资源永远有限，先做什么由谁定

MoSCoW法则：Must（必须有）、Should（应该有）、Could（可以有）、Won‘t（这次不做）

Kano模型：区分基本型需求、期望型需求、兴奋型需求，把精力花在“对的地方”

排序的核心原则：不是技术难度决定优先级，是业务价值决定

工具输出：需求优先级评估矩阵模板（学员可带回直接使用）

三、需求搞清楚了，怎么验收才能让“做完了”真的等于“做对了”？

1. 验收标准必须说人话、可衡量

SMART原则：具体、可衡量、可达成、相关、有时限

验收标准错误的典型表现：太模糊、太主观、无法验证

好的验收标准长什么样——对比10组“差 vs. 好”的验收描述

讨论：分析3条真实项目中的验收标准，找出问题并现场改写

2. 需求澄清会议怎么开才不白开

会前准备：需求文档前置阅读 + 问题清单提前收集

会中管控：谁拍板、谁执行、谁验收，三方当场确认

会后闭环：会议纪要怎么写才能“不留活口”

四、销售一句话就加需求，研发怎么接得住、挡得回？

1. 给销售立规矩——不是不配合，是有底线地配合

售前承诺必须经过技术评审：没有评审的口头承诺，研发不背书

建立“销售-研发需求交接 checklist”，堵住源头漏洞

用成本和工期说话，把“能不能做”转化为“值不值得做”

案例：某SaaS公司如何通过一张“需求影响评估表”，把销售随意承诺率降低了70%

2. 用原型工具把需求“画出来再说”

Axure/Figma等原型工具在需求验证中的实战价值

先验证再开发：原型评审通过后才进入编码，减少返工70%以上

演练：给定一个需求描述，小组用简易原型方式快速验证需求的合理性

五、变更躲不掉，怎么让“加需求”变成“走流程”而不是“白加”？

1. 建立变更控制委员会（CCB）——谁有权说“加”，谁有权说“不”

CCB的组成与决策机制：不是一个人说了算，是规则说了算

变更的三种处理结果：同意、拒绝、延期

2. 变更日志与影响评估——每一次变更都有“价签”

变更影响评估三要素：工期影响 + 成本影响 + 质量影响

变更日志必填字段：变更描述、提出人、提出时间、影响评估、决策结果、是否追溯

3. 对自发扩范围行为设置“红灯机制”

研发团队“顺手多做一点”的三种危害（你以为在加分，其实在挖坑）

红灯机制操作规则：未经评估的新增工作，一律不做，先亮红灯再评估

工具输出：变更日志模板 + 变更影响评估表（学员可带回直接使用）

六、说一千道一万，来个真项目练练手

综合案例演练：

背景：某中型制造企业实施ERP系统升级项目，合同约定6个月完成财务、采购、库存、生产四大模块上线。项目进行到第4个月时，客户各个部门开始频繁追加需求——财务部要求增加3种自定义报表，采购部要求增加供应商评分功能，生产部要求增加工序级排产看板。客户项目负责人说“这些都是小功能，顺便做一下”，但开发团队测算下来至少还要加2个月工期。

分组任务：

任务1：用MoSCoW法则对追加需求进行分类，给出建议处理方案

任务2：绘制一份完整的“范围失控因果图”，找出蔓延根因

任务3：针对该场景，提出至少3条可落地的控制措施，并撰写一封给客户的变更沟通邮件

成果展示与讲师点评：每组10分钟呈现，讲师逐一点评并复盘关键控制节点

七 全天收尾：守得住范围，才扛得住项目

全天核心工具与流程全景回顾

每位学员制定个人行动计划：你当前项目中“最危险的一个范围隐患”是什么，你打算接下来怎么管住它

Q&A及课后工具包发放（含全部模板）