认识达内从这里开始

认真做教育专心促就业

工程师如何正确处理项目需求的变更

发布：运城达内教育官网
来源：互联网
时间：2017-06-27 10:15

我们在进行软件开发或者是网页设计的过程中，比较难解决的问题就是产品端或者是服务器端需要进行一些需求上的变动，而这就意味着我们的一些工作又发生了变化，甚至是已经完成的工作都要重新返工。所以，我们今天就一起来了解一下关于如何正确处理需求变更的问题。

工程师如何正确处理项目需求的变更

主干流程优化

项目上根据实践经验发现仅靠需求评审无法完全保证需求方清楚的澄清所有需求，以及交互方充分的理解需求方的要求，其本质原因在于PRD并不能完整的描述清楚整个场景，许多需求层面的细节和串联即便在需求评审结束后依然可能覆盖不全;只有随着交互设计师把需求完善成结构严谨的逻辑图和场景说明，往往才会发现一开始需求设计不到位的情况，在大版本的情况下，等到整个交互稿都拿出来了再去做变更，变更代价过大/感受也不好。

管理变更的理念

变更管理的核心在于评估需求变更的价值，然后决定做不做以及是否在当前版本做，我们尝试从更多角度去思考，包括说产品的规划，需求的特点。

首先分析产品阶段特点：我们处在产品转型这样一个新旧交叉时期(简单说就是一方面要维护原有功能，另一方面更需探索设计新的功能)，因此这个时期的需求变更可以划分成四个维度：原有核心功能，原有周边功能，新功能核心功能，新功能周边功能;变更也按上述维度进行分类，再考虑版本上线时间和质量，按照以下顺序去考虑需求变更(笔者假设质量是恒定的，范围和进度是变量，所以对范围和进度进行优先级排序)：新功能核心功能变更>原有核心功能变更>版本上线时间>新功能周边功能变更>原有周边功能变更。

执行变更的步骤

需求方提出变更(建议同一个角色集中由一个人来提变更，比如运营/市场需要分别指定唯一的输出需求变更的接口人)，策划评估变更必要性，制定变更的方案(建议变更统一由当前版本负责的策划来统一收集和输出);如果需要交互设计，需要和交互一起讨论实现方案。

策划通知开发，开发同学评估变更工作量，一般情况下，开发和策划共同决定是否在当前版本实现变更，如果意见不能一致，需要提交可以负责的干系人审批决定，但这种情况往往较少，大部分情况还是要靠产品和开发撕出一个结论。

PK成功的变更将进入研发，站会周知，项目经理评估风险;PK失败的变更进入需求池，在池子里重排优先级。对于PK成功的变更，一般而言我们会拿掉一个优先级较低的需求，保证迭代里工作量相对恒定;但，这只是原则上的做法，我们也会灵活的分析当前剩余工作量，来决定是否可以直接添加变更，这种做法建议是尽量要少。

好了，关于项目如何进行需求变更的方法今天我们就给大家介绍到这里了，如果您对软件开发或者网页开发感兴趣的话，可以与我们的在线服务人员联系，获取更多材料进行了解。

< 上一篇：共享经济的发展方向以及演变趋势

下一篇：app软件的人机交互功能是如何开发的 >