需求变更，相信大家一定都遭遇过，即使项目在启动时已经具备完整的需求，在项目启动后还是可能会变动。而且由于管理模型的不同，在项目启动后对需求变更会是件特别耗时费力的事。
这就是为什么我们需要一个持续的需求管理流程，这样能不仅能帮助控制成本，避免规模失控，还能保证完整的可追溯性。好的需求管理系统在需求变化时，能够实现灵活地管理，还能高效地交付功能。我们在实践中总结了一些能帮助我们避免需求的频繁变更的方法，下面就来简单介绍。
一、尽可能多的渠道搜集需求
首先是搜集需求。这个过程要包含所有相关的渠道：比如新老用户、管理人员、业务分析师和其他的参与人员。尤其是注意那些会真正使用系统的用户，因为在系统性能和用户界面方面，他们会给你提供最可用的信息。把他们作为最高级别的需求来源能让你的产品或服务真正解决客户的痛点。
怎么从用户获得需求？
注意用户非正式的评价或吐槽 - 需求也许就藏在其中。
对于预设的问题，要捕捉用户的反应。
和那些能与用户直接交流的管理人员持续的开展头脑风暴。
仔细的看看用户所处的环境。
更多的从用户角度去了解 - 比如他们日常是如何使用产品来开展任务的，他们的工作流程、任务的排序、内部规则、可能会遇到哪类问题，或者是用户、团队成员之间的交流。
我们通过PingCode，汇集了用户、市场人员、售前、客服等不同渠道的用户需求
二、确定需求优先级
分类需求并不是一件简单的事。当项目成熟时，我们要把需求文档化，并把所有信息保持在最新状态，来保证其在测试和验证时可追溯。需求的优先级整理，能确保团队发现缺失，矛盾或者是重复。清晰的需求结构有助于测试管理期间更容易的决定执行哪些操作，包括指定相关的测试用例。这两个流程彼此紧密关联，只有在受控和良好的计划下进行，才能达到项目目标。
在与相关人员商量需求的优先级时，他们自然会提出各种的意见：哪些关键，哪些想要，又有哪些是强制或可选的。关于需求的优先级，让所有参与者统一意见是困难的， 这也是为什么这件事最好在项目早期做。为了更好的掌握需求的优先级及其依赖关系，按层级关系把它们组织在树状图中是最佳途径。
通过组织确定需求的优先级，可以使团队快速筛选出缺失、重复或者矛盾的需求
三、尽可能邀请所有相关人员参与评审，并达成共识
一旦需求整理完毕，与所有相关人员开会评审是必须的。并且尽可能确保项目成员都参与进来。这个过程中中即使是在会议的最后一刻需求也可会发生变动，而这恰好是大家取得共识的关键时刻。在整个应用生命周期中，我们需要确保系统的开发不只是盲目的在符合一组宽泛的需求，而是应该灵活处理，优先减少成本，尽早交付。这就是为什么要尽早确定需求的优先级，然后再是是集齐需求，等待最终评审。这些需求以及他们的优先级将指明项目未来的方向。在此之后，剩下的就是让那些具备丰富需求管理经验的同事来检验你的需求规范。
总之，在核实需求时我们要注意下列标准：
1.特有的、整个项目过程完整不变。
2.易于测试、可追溯。
3.在团队能力范围之内，便于后期验证。
如果你觉得哪些需求没有达到这些标准，修改或干脆删掉。
四、需求验证
通常，要时不时的让提出需求的相关人员来审核文档，并且要尽力帮助他们理解需求。当这些需求实现时，还要准备好相关的说明文件。根据不同的工作流程，你要提供不同格式的比如活动图，工作流模型图以及流程图来说明。最好是把需求以文件夹形式的来组织，并以树状图显示，方便用来验证。这样你就能构建一个包含少数功能的可用环境，用户就可以在需求最终评审之前尝试不同的方法来验证。另外，这种组织形式还能让参与者明了，具体的需求是如何代表他们的工作目标，以及它们是如何组成项目的总体目标。同理，清晰的展示所有对象间的关系和问题也同样重要。
五、评估需求变更的影响
这种类型的评估会让团队认识到需求变更带来的影响，能帮助团队做出最有效的业务决策。影响力分析在那些重视质量和安全性的项目中非常重要（比如医疗或自动化项目）。这种分析用来检查需求的变更会导致哪些组件也需要更改。
大体来说，影响力分析是指：
理解需求变更带来的影响 - 例如， 在产品中新增一组功能会降低性能，对部分用户来说是不可接受的；
如果需求变更了，要指出哪些文档，模型，和文件可能需要修改。
明白哪些任务涉及到变更的需求，以及要实现这个变动要花费的成本，两者同样重要。
如同你改变已有的需求，系统本身也会变动。开发团队需要良好的版本管理机制来控制这些变动，包括测试管理在内，还要有个的组织良好的后期执行方案，来降低因成员间误解带来的风险。
六、用好需求管理工具
使用PingCode管理需求
借助正确的工具来搜集和文档化需求是最有效的。如果你的开发团队使用PingCode，就可以很好的进行需求管理。因为它覆盖了包含项目、任务、需求、缺陷、迭代规划、测试、目标管理在内的研发管理全流程。
就以需求管理来说，借助于PingCode，你能够通过建立一个项目便捷的汇集市场人员、销售人员、及内部其他渠道产生的需求或者缺陷，并且使用史诗/特性/用户故事对需求进行分级管理，让产品负责人可以为需求设定优先级以及指定需求的业务价值。而这些，都可以作为迭代规划时的依据。
文章来源Dzmitry Hryb
译|WT刘亮