查看完整版本: 需求变更流程

需求变更流程

向大家推荐需求变更流程，实战级别的！不是理论

好贵啊，要5个钱啊
不过资料好，也得要啊::em55::

不错，只是实现起来很难

这个应该是公司比较大，而且很正规才能执行起来。
而且如果按照上面的流程，是不是要求产品很成熟，否则一个需求变更到用户手里，需要很久。

觉得很不错，内容详细、具体，可操作。

回复 5# 的帖子

谢谢，对于需求变更现在很多项目都会频繁出现，让开发人员很头疼的事情，所以在做需求的时候还是要给予很高要求的，让需求尽量做得精细，可以采用评审来完善，但评审绝对不能流于形式。变更的复杂性也能约束需求分析人员的做事谨慎度，让他们尽量的考虑清楚一句话绝对不能出现二义性，让客户跟项目走起来。

需求变更流程，我最近正在整理，借鉴下楼主的方法

变更的种类、实施的范围、产品成熟度、公司与客户的关系、公司的规范程度、需求分解的颗粒度以及需求管理的方法，都与变更流程的制定有一定的关联。在制定流程时，环境不同，这些因素的权重也不同。楼主的文章很是不错，希望多分享一些制定流程的时候的思考方式，和在实施的时候如何根据情况进行流程的调整与升级。

9.5 需求变更控制
需求发生变更的起因主要有：
随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。
市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。
提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。
需求变更控制的目的： 如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。
需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”：
开发方与客户方达成“事不过三”的约定（符合中国人的习惯），即允许客户变更三次需求；如果客户第四此变更需求，开发方有权拒绝，除非客户愿意补偿开发方的损失。
如果事先没有“游戏规则”的话，开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求。

开始学习

我们公司分了开发和需求组,我要向需求发展

不错不错~~学习一下  :)

非常需要，下来好好学习一下。谢谢。

这套流程什么样的项目适合贯彻使用呢

一直会遇到需求变更的问题
客户不停的提需求
虽然我们了解不能随便变更
但是到最后还是全盘接受
很痛苦
乙方不易作

公司与客户的关系很重要

汗，好贵的说，努力发帖，早日下载！！

很好，需求变更流程的制定，以及真正落实，让开发人员应该可以轻松不少的

刚开始学写需求

刚开始学写需求，没有一点方向，好混乱噢。

一份价钱一份货阿，我太喜欢了::em55::

waste my money !