如何处理软件项目中发生的需求变化

我原来是做产品的，产品和项目有点不太一样。我们接触的人都是自己人，比如现场用服、市场等。
一般来说会按照这样的程式来做。
1、先审查需求，值不值得做。
2、值得做谁来做，现场还是总部基线版本
3、如果总部来做，就开始分析需求，看看多大的工作量
4、如果工作量太大，就和现场或者市场商量，这个需求有多紧急。
5、如果工作量不大，Ok，提个需求变更，加入到当前计划中。
6、如果工作量大，现场又很紧急，那么开始需求评审，需要多少人，多少工作量。可接受范围内，加班搞定。
7、如果工作量实在太大，人力又不足，进入下个版本计划，一般来说我们一个月一个小版本，三个月一个大版本

第七条是好办法，可惜有些老板会问“为什么工作量这么大，还没做怎么知道工作量大？这点人不够吗？已经够多了”
这时候你怎么办?

开发灵活的软件系统，以不变应万变。

何谓你说的“灵活”？有啥高见。说出来听听。

    一般经常变化的，不是一般的门户类网站或电子商务类网站，往往是一些管理系统，这些系统需求总是变，是因为新的业务特性或公司内部战略调整等，当然也不排除其它原因，我们目前发现在最好解决方法是开发可配置的系统，解决大部份的一般性业务需求，其它复杂的业务需求再进行定制开发。

以前也经历过开发可配置系统的经历，问题是在有时候客户反映他们想配置的不是我们的系统里允许让他配置的。
这时候还是属于需求变更，那不还是要重新在搞？
我个人认为敏捷管理论中让一个业务专家陪同开发过程是明智的，这让开发人员随时知道客户真正的需求是什么。
可惜这引出另外一个有中国特色的管理问题，那就是客户没有这样一个“业务专家”的角色。结果还是我们这里出这么一个人，东西作出来还是客户这个不满意，那个不满意。唉，中国客户的确很难搞，特别是吃公家饭的那些~~

做项目就象战斗

客户就是敌人

做需求分析就是侦察兵

售前/沟通 的就是 谈判专家

设计者就是参谋

编码人员就是步兵  只是消耗品和炮灰

前3种人的责任很大


什么叫需求变化?
你忽悠摆平敌人就可以少消耗炮灰.
敌人牵着你的鼻子走就可以拖垮你.

需求中有合理需求: 做需求分析的要了解业务,设计可性的流程,然后靠强大的忽悠摆平客户

不合理的需求就是敌人的吹毛求p ,或者拿你寻开心．．．．．

所以不是需求变不变，而是人行不行，搞不搞得定客户。

实在不行拿２套方案

一套陪客户玩　　ppt或flash实现远景目标　就是画个大饼子

一套给用户操作　　能用就行．．

当然背后公关就是少不了了

大家都爽了　等着死线的到来．．

中国IT项目就是像楼上说的那样做的，因此中国IT行业就是一个混混和吹牛者赚大钱，掌大权的行业。最苦的还是技术人员，因为只是炮灰，该要你死的时候就要你死～

东风吹　战鼓雷　　
这个世界谁怕谁？

找准位子　　摆正心态

做炮灰有炮灰的快乐，机器用永远比人好伺候．
．

被上司给穿小鞋实在混得不开心不会当逃兵么？反正山头多？哪个大王口碑好多打听？

在管理者面前，技术牛人永远是优势的．做人不要太贱，该发飙就发飙．．像团棉花才会被修理．．．．