怎样控制需求变更

1、研发人员要学习业务
自己不懂业务，怎么能设计出客户喜欢用的系统来。
2、需求要评审
同样业务专家和技术专家一起评审，怎么做出业务扩展性号的系统来。
懂了业务，才有可能知道，以后那些地方可能要改
3、需求变更要评审
客户和业务专家一起去，说做这个需求对系统有什么影响，对客户工作有什么影响等等。
4、需求交流要业务专家去
老板谈谈商务，管理管理人就好了，去谈什么需求嘛。真是SB，应该研发加业务专家一起去嘛
5、如果是一全新的产品，高开始绝对要做一个模拟系统。可以点击的，数据在js里写死。一定是高保真的，除了数据不是动态查出来的，别的都是真的。


总之，你们没有业务专家，那就自己培养一个！

叫你们老大与客户商量好了再开发,而且必须做出DEMO的,不要马上动工,看最后的决定!

你可以给boss提议在确认书里面加上各个功能的画面截图，然后找客户确认，并要求客户签字。可以看出你们boss不够强硬，这样的后果是项目失败的责任就的你们公司承担了

这样的问题我在给ctr做网站就遭遇了，前前后后折腾了大半年，亏本阿

典型的“中国特色的软件开发”，movingboy和o6z给出了很有见地的意见，需求不是拿来控制的，需求需要去完善和追踪，方法就是迭代和短周期交付。有个兄弟问题提的很好，成本固定，迭代需要花成本，这在项目中怎么解决？这个问题在我看来要跟你的开发团队甚至公司的开发过程有很大的关系，假如还没有敏捷的任何实践经验，成本是大的，但是相比于经过漫长开发出来后再被boss或者客户一个字“改！”恐怕成本未必见得高。这个问题很深，这里不打算展开。之所以特别提到“中国特色的软件开发”，有几个地方需要说的就是在中国的软件开发缺少一些角色，比如缺少BA(Business Analyst)，缺少Interaction Designer(交互设计师，也可以说是界面设计师)，这些缺失给需求的捕获和精化带来很大的障碍，不过这也成就了中国的pm们：）

需求分析的变更真的是无法预料的，其实有的时候客户连自己都不知道要得到什么样的系统··只要开发者初步设计了，客户才知道该如何改进···

很同意楼上所说的，很有感触

很同意楼上所说的，很有感触

DEMO 做完后,让客户签字, 不过, 在国内, 估计变更太正常了, 信用问题.

我以前也碰到这个问题，被这个问题把项目拖延了5个月，客户也怀疑我们。

最后，我用原型开发方法，先把demo开发出来，所有数据是模拟的，按钮都是可以点的那种，也不是静态网页或者图形。

用这种方法，第二个项目缩短了3个月，与客户关系也好得不能再好了。