项目中的需求经常变更如何管理?

[chendev]

现在本人管理的一个项目由于需求变更较频繁，甚至于原来需求相反，实现起来很麻烦，对于这种那位大侠能否指点迷经？

[molder]

需求分析是软件工程中首先和最重要的一环，但很少有人能在规定的时间完成需求分析或者保持需求分析的原汁原味。需求分析总是在一个螺旋的过程中，反复修改、不断完善。当你
看到最后成熟的需求分析报告时，也许你会发现此时的需求可能与最初的用户想法有很多不同，甚至会相反，这都是可能发生的。所以你不必紧张、焦虑，判断需求分析是否成功的关键不是要保持始终如一、坚持用户唯一，而是要在周密、实际、细心、谨慎、勇敢的状态下，在你与客户不断的沟通之中，达到一种双方都满意的情况。需求分析是为了解决开发方与客户之间的矛盾应运而生的，通过做需求分析的过程，达到开发方熟悉客户需求、客户了解开发过程
的大体框架。需求分析是会随着工程的进展不断修正，因为只有实践才是检验真理的唯一途径。无论我们计划得多么周密，总会有疏漏，随着不断实践，我们会不断完善需求文档。
软件是要为人服务的，衡量软件是否成熟，就要看它用起来是否真的和它看起来一样有吸引力。每一人软件人所梦寐以求的目标就是让自己做出来的软件无论经历怎样的狂风暴雨仍然能茁壮成长！！

[kingdl]

第一，变更控制委员会，
第二，变更控制委员会，
第三，变更控制委员会。

需求变更是不可避免的，但必须要保证在控制之下（under control）。最好的方法就是变更控制委员会（CCB）。因为如果用户不经过一个固定的程序就可以变更需求的话，那么他当然任意妄为。可如果要是经过程序，提交书面材料的话，就会谨慎多了。而且程序员的golden garbage也很讨厌，也要用需求变更控制管理起来。总之，under control。

[kingdl]

还有，对于molder说的有点想法。其实由于资源限制，还有很多制约因素，双方都满意很难达到。只有妥协，相互妥协才是上策。有时不能太由着客户，当然要讲方法了。区分优先级是种比较好的做法，还有区分工作量和风险，进行特征评估。总之，没有完美的需求，只有付费的需求。联系mail：[e-mail]

[ntlan]

需求变更这是肯定的，无论多么周到的需求分析也不可能把以后的需求做得面面俱到，但于项目工程来说并不是就没有办法。
解决需求变更的问题，更重要的是在需求分析时，接口留得如何的问题，如果这变更直接冲击的是系统核心，那这种变更势必会让整个工程面临重做的危险，但幸好这样的变更不是很多，如果有也可以算做以后的系统升级，但中国的不少小公司就在这里面吃了不少苦头！
另一种变更应该是比较普遍的，那就是某业务功能的变更，这种变更往往面临的是一动全动的危险（如果程序功能模块化不够、如果数据结构不干净），如果说解决这种问题最好的办法，那应该就是在工程需求到数据模型、程序实现阶段要认真对待。当然如果要解决当前问题，就要经系统分析员、数据库专家与技术经理的商导，才能确认一个好方案来修改！在此我想，如果把这样的业务变更用一些不成为理由的理由去“蒙”一下客户的话，是不可取的，如果软件是一块面包，用户要求你提供一张纸的要求不为过。

[xalieren]

对于项目管理和需求管理我的体会是
没有一步到位的项目(迭代)
没有一成不变的需求

[silkeen]

mark

[nrcrjb]

每本有关需求分析的书上都讲了有关需求变更控制委员会的重要性，然而实际上在国内许多的软件企业内需求分析并没有得到充分的重视，那自然更不需要讲什么需求变更控制委员会了。

我现在所在的这家公司也是在不断的失败中才意识到软件原来还有需求分析这么一说，尽管如此，却也并没有真正意义上的重视起来。所以许多的情况下，根本没有办法控制用户需求的变更。