需求变更是大家永远的痛点话题。我们不但不能阻止变化，还要拥抱变化，要做的仅仅是管理变化。我们做过许多银行项目，他们系统间、各系统的模块间，牵连关系异常复杂。可以借鉴他们的需求管理方法。个人总结了下他们做需求管理的几个思考维度：
从源头减少变更——保证需求提出质量许多需求之所以频繁变更，是因为前期没做好分析。所以考虑从源头开始管理，尽量在需求提出时分析清楚来减少后期不必要的变更。为了提高需求提出质量，他们做了许多事情，包括：
- 统一收集需求，设立专人受理。
需求方通常是前端业务人员，提需求不一定能以系统化角度来提，让他们按模块或技术标准来提就会对需求方提出更高要求。目前需求方无法达到这个水准，就需要有专业人员来补齐这块短板。因此他们会通过统一途径（比如OA系统、需求管理系统、项目管理系统等）来收集需求，然后由专业人员进行受理，对需求进行初步审核和分发。通过这个角色，一是为业务和技术双方搭建桥梁；二是起到隔离带的效果，有统一对口人，避免需求方直接找开发人员。
这个角色可以是产品人员或其他对业务与系统都熟悉的人员，重要的是受理的过程，保证需求到达开发之前是经过分析的。
如果需求方依然越过这个角色直接找开发，需要从流程规范上做控制，比如告诉需求方只能通过产品人员来接收需求，否则将不被受理。
- 总结需求提出规范，给需求方提供模板。
即便需求方无法识别影响的系统模块，但依然可以从业务角度把需求提清楚。比如设定需求模板，要求必须写上需求的提出背景、应用场景、操作角色、应达到的预期结果等。
甚至一些银行对需求做了精细的结构化管理，需求提出时通过识别业务类型、场景、条件等，通过系统工具自动识别影响的系统和模块甚至是需求工作量，将需求提出规范做得更加智能化。但做到这个程度需要对历史需求做大量梳理，更适用于业务稳定的这类需求，而不适用于创新业务类的需求。
同样，如果无法做到自动识别涉及的模块，就只能人工替代，让专业人员来识别。
- 特殊情况，特殊处理。
虽然需要避免需求随意提交到开发打乱开发节奏，但确实存在某些需求需要紧急处理。因此需要对需求定义优先级或紧急程度。最好能明确定义，比如影响到前端业务无法进行的被定义最紧急需求，对于UI优化等定义为不紧急需求。若不能明确定义，也可以人工分析，在受理时进行沟通确认。
同样为了有效管控，他们也想了很多办法，比如：
- 每次变更都需要经过审批流程并留痕。
- 变更同样要规范提出的信息，并分析影响。每次的变更都相当于一条新需求来处理。
- 变更需求必须通知到相关人，以便让正在完成相关需求的人员都能及时同步到信息。其中可能涉及产品人员或项目经理重新评估需求影响，进行工作计划调整，比如停止正在进行的相关工作按变更后的执行，还是将变更排到下一个开发周期，让开发团队遇到变更也能有条不紊的进行。
- 不论新需求或变更，都尽量通过分解和全链路追踪的方式。在面对大需求时，需求分解是非常好的方法。需求分解后，每条小需求可以独立状态进行跟踪。变更发生时产品人员或项目经理能马上跟踪到原始需求分解了哪些小需求，各个小需求都进行到了哪一步，如还未分析设计，或已开发完成在等待测试，以便工作计划及时调整。
对于以上，都需要借助系统工具进行管理，否则只靠人工和线下Excel表格是很难的，特别是这些业务数据间的复杂关系处理。我们接触过的银行客户很多都用的易趋的管理软件，看起来效果还不错，希望对题主能有帮助。
最新评论