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

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

不错，只是实现起来很难

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

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

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

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

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

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

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