需求收集模板：我在项目中使用的 7 个实用技巧

需求收集模板只有在迫使大家尽早进行艰难对话时，才有存在的价值：谁来签字，谁能叫停，成功是什么样子，系统必须多快。本指南写给需要一份经得起第一次指导委员会会议考验的模板的项目经理、业务分析师和 SAP 负责人。下面是我用的完整大纲，每个部分都有负责人，还有我从不跳过的五个部分，以及七个关于访谈、优先级排序和变更的技巧。把大纲复制到您自己的文档里，在设计开始之前填好。

我曾眼看着一个金额达六位数的项目崩盘，原因是没有人认真做过需求。客户期待的是一样东西，开发团队做出来的是另一样。所有人都被推出去背锅，我就是在那个时候被请去的。

这种情形并不少见。PMI 2014 年关于需求管理的《职业脉搏》（Pulse of the Profession）报告发现，47% 的失败项目是因为需求管理不善而未能达成目标。我亲眼见过几十次。

在一次大型系统推广中，我自己也差点走进同样的局面。干系人各说各话，开发人员在猜。我们停了下来，搭起一份像样的需求模板，最后按时、在预算内交付了业务真正需要的东西。

一位朋友的公司花了 35 万美元定制了一套 CRM，结果没人用。销售需要一样东西，市场部想要另一样，开发人员则按自己以为大家想要的做了出来。

我有一位医疗行业的客户，在一套医生拒绝使用的电子病历（EMR）系统实施上白白浪费了 18 个月。没有人问过医生们，他们日常工作流程中需要什么。项目被废弃，重新来过。

发现得晚，代价高昂。一项NASA 关于差错成本升级的研究发现，在集成和测试阶段才发现的需求错误，修复成本是在需求阶段发现时的 21 至 78 倍。到了运营阶段才发现，这个倍数从 29 倍一直到 1,500 多倍。在企业级项目群里，这就是一场工作坊和一份价值数十万的变更请求之间的差别。

1. 需求修复的基准成本在需求仍在撰写时发现
2. 集成与测试21 至 78 倍的成本在系统建成并处于测试阶段时发现
3. 运营29 至 1,500 多倍的成本在系统上线之后发现

来源: NASA 关于差错成本升级的研究

吃过苦头之后我才明白，这五个部分是任何需求模板都不该跳过的。

1. 带签字栏的执行摘要

忙碌的高管不会去读一份 30 页的需求文档。我曾遇到一位发起人，没弄懂自己签的是什么就批准了项目，看到结果后大发雷霆。把它控制在一页：业务影响、时间表、资源、预期收益，并在同一页上放签字栏，这样审批人就没法说自己漏看了关键细节。

2. 角色与影响力图谱

光有一份名单是不够的。您需要一张权力地图：谁能搞垮项目，谁必须征求意见，谁只需要知会进展。在之前的一份工作中，我们已经开发了六个月，法务部才带着需求出现，逼得我们重新设计。当初没有人想到要把他们纳入。把每个受影响的部门、它的代表和它的影响力都梳理出来。

3. 要业务目标，而不是技术需求

我们要解决什么问题，又如何衡量成功？有一家制造客户严格按规格实施了库存软件，结果仓库作业慢了 20%。模板应当迫使干系人用当前的基线来定义业务上的成功，而不是列一张功能清单。

4. 开发人员用得上的功能性需求

去掉行话。让每条需求都具体、可测试。“系统应当改善客户体验”毫无用处。“用户必须能在 3 分钟内处理完一次退货并办理退款”才是一条需求。如果您无法验证它是否做到了，就重写。

5. 非功能性需求

性能、安全、合规、可用性、可扩展性。这是几乎人人都跳过的部分，结果系统在负载下垮掉，或者没通过安全审计。我听说过一个零售项目，系统一直运行得很好，直到黑色星期五，在负载下崩溃了，原因是没有人规定过性能要求。把响应时间、正常运行时间、用户峰值负载和合规义务，都用数字写下来。

这是完整的大纲。上面的五个部分都在其中，另外还有让它在签批之后依然保持鲜活的几份日志。

部分	内容	负责人	签批人
1. 执行摘要	问题、业务影响、时间表、资源、预期收益。一页纸，带签字栏	发起人，由业务分析负责人起草	发起人和财务
2. 范围与部署基线	范围内外、约束条件。对 SAP 而言：Public Edition、Private Edition 或本地部署	项目群总监	指导委员会
3. 角色与影响力图谱	部门、代表、影响力级别、征求意见还是知会	业务分析负责人	发起人
4. 业务目标	每个目标都有一项 KPI、当前基线和目标值	流程负责人	发起人
5. 功能性需求	ID（如 REQ-FUN-023）、描述、来源、优先级、验收标准、Fit-to-Standard 决策	功能负责人	流程负责人
6. 非功能性需求	性能、安全、合规、可用性；对 SAP 而言，还有每个差异的扩展方式	解决方案架构师	IT、安全与合规部门
7. 待定清单	被推迟的请求、提出人、下次评审日期	业务分析负责人	升级为正式需求之前无需签批
8. 否决日志	什么被否决了、原因、时间和决定人	业务分析负责人	发起人
9. 变更日志	签批之后的每一项变更，及其对时间和成本的影响	PMO	变更委员会

1. 在干系人访谈中使用“五个为什么”（Five Whys）

问“您需要什么？”，得到的是一份愿望清单。改问痛点：“什么事让您想把电脑从窗户扔出去？”然后追问为什么，再追问为什么，一共问五次。真正的需求，通常和最初的请求不一样。

我遇到过一位干系人，坚持要复杂的报表功能。我们把他实际的使用场景过了一遍之后，他需要的只是三块简单的仪表盘。

2. 建立一个需求“待定清单”（parking lot）

干系人提出的需求里，有相当一部分永远不会被用到。有人坚持要一样存疑的东西时，我不争辩。我把它放进待定清单，每月发一次提醒，问它是否该转入正式需求。大多数就此一直停在那里。

3. 对总是改主意的干系人，使用三次规则

他们可以改两次方向，不会有任何后果。第三次改动时，他们要给自己的老板发一封邮件，说明这次改动及其影响。没有人愿意发这封邮件。改动就停了。

4. 用资金分配法，逼出优先级

给每位干系人 100 虚拟美元，分配到所有需求上。他们不可能什么都要，于是就把钱花在真正重要的地方。我用这个办法处理过一家金融服务客户，他们有 200 多条“关键”需求。一个小时之内，我们就得到了真正的前 20 条。

5. 给每条需求编号

使用统一的格式，比如 REQ-FUN-023。它能终结“我们在说哪一条需求？”这种浪费会议时间的混乱。记录来源、谁提出的、为什么提，这样需要砍条目时，您就知道该找谁。

6. 用干系人自己的语言把需求复述一遍

文档写完后，用干系人自己的话把需求读给他们听。凡是复杂的内容，在开发开始之前先做一个快速原型或线框图。误解在还很便宜的时候就浮出水面。

7. 把被否决的内容记录下来

到了第五个月，总会有人把一条被否决的需求重新翻出来。“我们四月讨论过这件事，当时决定不做的原因在这里”，几句话就能结束这场对话。没有这份日志，这场争论就得再来一遍。

这七个技巧适用于任何项目。SAP 项目群需要在模板里再加三样东西。

部署模式要写进基线

在收集功能性需求之前，先确定部署模式：S/4HANA Cloud Public Edition（通过 GROW with SAP，或 RISE）、Private Edition（通常通过 RISE）或本地部署。它决定了哪些事可行。Public Edition 不允许修改核心，所以依赖非标准流程的需求必须重新调整或予以否决。Private Edition 和本地部署允许的更多，代价是升级时的工作量。

如果在这个决定之前就收集需求，等决定下来，您会把其中很多重写一遍。

每个差异都要有一个扩展决策

SAP 的 Clean Core 方法意味着，每个差异都需要一个有记录的决策：通过配置解决，借助已发布的 API 扩展（借助 ABAP Cloud 做 on-stack 扩展，或在 SAP BTP 上做 side-by-side 扩展），或者否决。在 Public Edition 上，这是由产品强制执行的。在 Private Edition 和本地部署上，这是 SAP 的强烈指引，而您允许的每一项修改，日后都会变成升级工作。把这个决策放进模板的第 6 部分，紧挨着性能和安全，并授权一位架构师来批准。我的 Clean Core 指南解释了各个层级。

AI 起草，人来决定

如今 AI 可以帮忙处理文书工作。SAP Cloud ALM 提供需求生成功能，可以根据 Fit-to-Standard 工作坊的会议记录，把需求起草到模板中，通过 AI 单元付费。Microsoft Copilot 这类通用助手，则可以根据会议笔记起草摘要和纪要。

当原始材料干净时，AI 起草工具确实能在文书工作上节省时间。但它们改变不了访谈。提出“五个为什么”的，仍然是人。也没有哪个工具能让部门负责人在执行摘要上签字。验证、优先级排序和签批，依然是人的工作。

软件开发。加上技术约束、集成点、用户流程（用户实际采取的步骤，而不只是功能），以及通过/不通过的验收标准。我们在一个客户门户项目上漏掉了这些，结果花了三个月争论功能是否“工作正常”。

流程改进。梳理现状时，把大家在会上不会提的那些杂乱的变通做法也都画出来，按角色评估影响，并记录确切的绩效基线。有家制造客户在没有基线的情况下彻底改造了仓库流程。六个月后，它既无法证明有改善，也无法为这笔开支辩护。

供应商选型。把必须有和最好有的分开，给评分标准设置权重，并把支持和实施方面的期望写得细到让人发怵。我见过一家公司几乎完全凭功能和演示印象选了供应商。它忽视了支持要求，最后得到一套系统，不额外花一大笔咨询费就实施不下去。

对较小的项目：用 Trello 让需求走完各个审批阶段，用带批注的 Google Docs 做评审，用 Miro 在工作坊里画流程图。

对企业级项目群：用带需求管理插件的 Jira，用 Confluence 维护活文档（它的 AI 功能现在归在 Atlassian 的 Rovo 品牌之下），如果您用 Azure DevOps，则用 Modern Requirements。在 SAP 项目群里，SAP Cloud ALM 把需求、用户故事和测试用例放在同一个地方，并与 SAP Activate 路线图关联。

工具本身不如关联重要。把需求与项目计划和测试用例关联起来，需求一有变化就自动发通知。“我不知道那个改了”，比工具不好用更能毁掉项目。需求签批之后，如何守住它们，我写的如何避免 SAP 实施中的范围蔓延讲了；需求签批在治理周期中处于什么位置，SAP 质量关口讲了。

签批之后就没人再打开的模板，只是走过场。真正管用的模板很简短，每个部分都有人负责，每次有人改主意就更新一次，而在任何值得做的项目群里，这几乎每周都会发生。

需求收集的 5 个阶段是什么？

1. 需求获取：通过访谈、工作坊和观察来收集信息
2. 需求分析：整理需求、排优先级，并化解需求之间的冲突
3. 需求文档化：编写规格说明（根据方法不同，是 BRD、FRD 或用户故事）
4. 需求验证：确认需求反映真实需要，并且可以测试
5. 需求管理：在项目剩余的时间里跟踪变更

每个阶段都建立在前一个阶段之上。多数团队都会匆忙完成需求获取，这会在之后的每个阶段制造问题。

BRD 和 FRD 有什么区别？

业务需求文档（BRD，Business Requirements Document）涵盖业务需要：背景、目标、干系人、约束条件和高层级需求。它回答的是“业务需要什么？”

功能需求文档（FRD，Functional Requirements Document）涵盖系统将如何运行：用户故事、系统行为、接口和验收标准。它回答的是“系统必须做什么？”

我总是先从 BRD 入手，在写 FRD 之前先拿到业务上的一致意见。直接跳到 FRD 的团队，常常做出一套技术上正确、却解决了错误问题的系统。

需求的 3 种类型是什么？

1. 业务需求：项目为何存在、它的目标和成功衡量标准
2. 功能性需求：系统必须做什么
3. 非功能性需求：系统必须做到什么程度（性能、安全、可扩展性、合规）

我见过的项目失败，大多可以追溯到缺失的非功能性需求。系统做到了被要求的事，然后在真实负载下垮掉，或者没通过合规审计。

SAP 的部署模式如何改变需求收集？

先把它确定下来。S/4HANA Cloud Public Edition 不允许修改核心，所以建立在非标准流程上的需求必须重新调整或予以否决。Private Edition 和本地部署允许更大的灵活性，但每一项修改都会增加升级的工作量。

如果在这个决定之前就收集功能性需求，您会把其中很多重做一遍。为每个差异加上一条有记录的扩展决策（配置、通过已发布的 API 扩展，或否决）。

什么样的需求才算可测试？

有一个清晰、可衡量的通过/不通过条件。“系统应该很快”不可测试。“在标准负载下，95% 的查询必须在 2 秒内返回搜索结果”才可测试。

我的检验方法：您现在能不能立刻写出测试用例，并带有清晰的通过/不通过标准？如果不能，就重写这条需求。在我见过的情形里，没法测试的需求引发的上线争议，比任何其他原因都多。

如何防止需求不断变化？

1. 变更控制：签批之后的任何变更，在有人批准之前，都要记录其对时间、预算和资源的影响。让变更的成本看得见。
2. 待定清单：新请求进入待定清单，而不是直接进入范围。每月评审一次。多数看似紧急的请求，经不起等待。
3. 质量关口：定义“需求完成”意味着什么，在达到之前不要开始设计。

在 SAP 项目群里，扩展决策又加了一道技术检查：需要修改核心的请求，必须先通过架构师这一关，才能获得批准。