怎样控制需求变更

  实际上就算美工和程序员的这样分工可以减少不少工作，但没有解决根本问题，只要客户不断更改就怎么样都要做些重复工作。可是要怎样才能控制需求变更呢？
  我向老总提写议确认书，并让客户签确认书，可老板说这是不可能的，你功能都没做出来，怎么让他们签啊？你做完功能让他们去体验，他们才知道有哪些地方是需要修改的，而页面的变更，实际上很多时候都是我们在开发或者开发完了，老总提出来要更改的。就像上周我们花了一周时间完成了一个功能模块，并经过了第1步测试，结果老板说要改页面，页面的布局和字段全都变化，相当于我们完全没做，而老板还以为页面的更改对功能开发影响不大，当然我也是今天才看到更改后的页面才知道的，而现在老板又在客户那边开会调研，我们无法沟通（而且更改后的页面除了老板同意外，其他美工和我们都觉得那样页面很难看而且变形了）:cry:
  更有意思的是，我们做的功能也一直不去确认，还在那边梳理流程，这样的话，我们开发的越多，以后也就改的越多，甚至又是完全重做！我感觉很可怕，可是解决的办法呢？我想只能做记录，记录下更改了多少，花费了我们多少时间，让老总感觉到其实这些是很耽误时间的，看他是否会重新考虑他现在的做法，不然的话，我们会死的很翘很翘！
  我相信很多人都遇到过这样的情况，不知道大家都是怎么控制需求变更的？怎么解决这些问题的？

评论

44 楼 qdchen 2008-11-28  

需求的变更主要有一下几个原因：
1.客户根本就不知道自己需要什么！ 这就要我们，从感官上去引导客户，让我们站着客户的角度上，去开发客户的需求！
2.客户知道自己要什么，故意的刁难（这样的客户不是存在的），对于这样的客户，我必须采取落实需求，确认！

43 楼 zhoujj303030 2008-11-27  

  主要应该事你们公司管理出了问题吧，需求这个东西怎么能够客户要求改就改啊，需求的变更要根据合同来啊！

42 楼 lzycxy 2008-11-27  

ozzzzzz 写道

心态有问题。需求变更不应该去控制，而应该是跟踪，更好的是做到去引导。
我这里倒是要提醒你们关注另外一个问题，也就是项目部署完成和用户开始时候之后3个月的问题。在那个阶段，客户已经对系统的使用和功能有了比较深入的认识，对于系统的有了更多的要求，而如果你们的合同签的不好，很可能会死在那个阶段。

是否能更详细的解释下，需求变更为什么不应该去控制，需求变更该如何跟踪。
需求沟通后将需求形成文档，在和客户确认后，如果客户没有什么异议，通常都应该向客户说明，我们就按需求文档来做，将来如果你们有什么变更，我们也会帮你们完成，但是，时间上你们得有个准备，我们无法保证你们提出变更后我们能在第一时间完成。
不知道这种做法算不算控制。

41 楼 tibetjungle 2008-11-25  

netfly 写道

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

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

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

现在我们做的一个项目也是用的原型，虽然是静态的，但是点击每一个链接和按钮都可以响应，是对实际业务逻辑的演示，很真实。用户在这个原型界面上确认需求，后续的开发基本上没有什么分歧，变更也得到有效的控制。

sdh5724 写道

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

中国人喜欢拍脑袋做事，脑袋中的东西经常变，所以需求常变也就不奇怪了。

40 楼 tibetjungle 2008-11-25  

Lucas Lee 写道

kayzhan 写道

  ：（请问楼上100分的积分怎么来的？才回我这一篇帖？

嗯，可惜客户说那不直观，不仅要做页面，而且要做出功能说才知道想要什么！- _ -!

这种客户应该比较初级，搞一个比较通用的系统用用就行了，在第一阶段属于体验、扫盲期。不用做的太好。

赞同！

分多个版本做，第一个版本实现主要流程也业务。余下的需求再安排版本。在一个版本中完成所有需求，对上规模的项目而言，简直就是噩梦。

39 楼 netfly 2008-11-24  

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

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

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

38 楼 sdh5724 2008-11-23  

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

37 楼 yunmanfan 2008-11-22  

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

36 楼 yunmanfan 2008-11-22  

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

35 楼 chenzengpeng 2008-11-19  

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

34 楼 seemoon 2008-11-17  

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

33 楼 thunderbow 2008-11-17  

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

32 楼 seasar 2008-11-17  

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

31 楼 kofren 2008-11-17  

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

30 楼 geutopia 2008-11-17  

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


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

29 楼 faithful_czx 2008-11-16  

和客户沟通太少。

28 楼 cenyu 2008-11-15  

    我认为关键是要了解清楚业务实体有哪些，他们之间的关系如何，这些是业务的核心而且基本不怎么变化的东西，也是客户唯一能和你说清楚的东西（如果不能说清楚，证明客户自己对自己的业务都不了解，或者你找错人做需求调研了。。。。）一般涉及业务实体的变更才会带来巨大的工作量，而且牵一发动全身，至于界面和功能性操作的需求，客户是无法一开始和你确认的,但是这部分的修改一般不会产生连锁效应,所以问题不大,我建议你使用迭代的方法来管理开发过程。

27 楼 Ethan 2008-11-15  

好像客户的需求不能去控制它，而且也没法控制。其实应该是在做系统之前就应该了解相对应的业务知识，当客户不清楚自己的需求的时候，需要做软件的人教他们什么是对的，怎样才是正确使用该软件方法，从而让用户感觉到你们的软件确实符合实际需求，这需要资深和权威的顾问做后盾，需要经验的积累。要不然就只有跟在用户的屁股后面跑了。

26 楼 bonepole 2008-11-15  

需求频繁变更，头痛的问题！是客户还是我们的原因？

25 楼 linginfanta 2008-11-14  

同意2楼的，要做Demo，如果客户不认同你的Demo，你开发出来也是白搭。
客户说不直观我觉得是你没有认真对待Demo，Demo应该能很顺畅的跑下去，简单的说，就是拿着Demo给客户讲得清楚。Demo做得好是可以真实的反映你的产品的。