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

。、。
面试时候人家问你为什么跳槽这么频繁，难道回答一句：良禽择木而栖。人家就会请你？
有时候稳定也是人家招聘的一条条件。况且再现在大环境如此不好的情况下，走出去又有风险，又不一定能保障你自己的利益。
我是很理解开发人员心理，可是有些猎头和HR甚至老板都是不理解的。

说得很幽默，，但也很在理。。。

客户是不懂技术的（大多，即使懂，也很一般），这时候他们认为哪个应该有和必须有是和原需求与技术无关的，客户认为你必须考虑他的需求，而他是不会替你考虑的

   我们中国的软件项目有很多都是这样，一开始有个大致的需求，有个功能需求列表，有个系统框框，至于其中的规则、算法、弊病、特殊条件下的业务规则等等，这些对系统最终结果有重要影响的方面，则提及很少或根本不描述。 根源既有开发商的责任，也有甲方客户的责任，不一而足。
    但遗憾的是这是事实，这就是中国国情。 企业对信息化结果的认识、对信息化过程的理解，目前就发展到了这个阶段，期望企业的判断能力达到IT咨询专家的水准是不现实的。 另一方面，在残酷的竞争的面前，指望IT企业不夸大其词，不迎合客户口味，而改为更阳春白雪式的纯IT正规思路和方法将项目进行下去，也是不靠谱的。 
    虽然第三方的咨询机构，可以在甲方乙方的中间建立问题本身的解决过程的控制逻辑，但由于几家客户认同这笔看来有些额外的费用呢。 立足现在，我认为有两个方面的努力可以尽可能减少由于需求变化所带来的影响。
    1、无非是老话题，建立需求管理及需求跟踪。 但建立体系不是目的，认真执行，严格监控，对需求变更的影响讨论再讨论，沟通再沟通。真正把需求变化，对于客户的影响、对于系统的影响、对于开发商的影响，明确到不能再明确。讨论到客户理解，需求的变化导致哪些问题、增加多少工作量、对系统主题有何本质上的危害和补充。讨论到架构人员理解，我们的基础体系的短板，这些不合理存在的原因、危害和提高改正的可能性。为什么不能看到，害怕改变的原因，其实是因为不具备适应变化的能力。不能适应变化的短板可能来自架构，或者我们的设计思维。 讨论到开发人员理解，我们设计一个模块灵活性、兼容性、适应性的重要，我们曾经引以为豪的某某功能，不能给客户带来他真正有意义的、美好的使用感受和使用价值，我们就还需要提高。
    认识到问题所在，离真理就更近了一步。
    2、从体系角度，设计的模型，更加积木化、平台化、插件化、个性化。不要老想着A功能如何B功能如何，把所有的功能放在一起，统筹看，都有些什么呢？ 只有这些：更快的速度、更稳定的运行、更方便的录入界面（包括导入）、更灵活的业务规则（随时定制特殊业务及其发生地条件）、更多汇总报表挖掘数据KPI（包括垃圾的不能再垃圾的所谓自定义报表？）、更顺畅的工作流程梳理、更高效的业务配合。
    将基础平台进行可定制的积木化，不要限定软件能做什么（虽然你知道它能：输入、计算、存储、显示），抽象了软件的这些基础概念，就像抽象积木为：圆、方、三角、长条、板、挂钩等等， 我们平台不但应该能产生等腰三角形，还可以经过配置产生诸如以下三角形：等腰直角三角形，勾3股4弦5三角形，一条边等于另一个正方形边的三角形，一个像楔子一样长长的窄窄的三角形，一个可以组成矩阵的等边三角形，一个大小支持挖一个中空图案容纳麦当劳赠送的小塑料熊的三角形，一个一面红一面绿的三角形，一个可以在最长边上嵌入磁铁条的三角形，等等。
    不是做不到，而是想不到。 当我们的工具不再是为单一目的而创建，而是具备了实现不同思想，不同功能的时候，当我们软件的功能和适应性，比客户想到的还要多，还要远，我们还惧怕变化吗？在不怕变化进而拥抱变化的基础上，客户的变化要求，就变成了我们检视自己、提高自己的驱动力和持续发展的动力。
    不要指望着我们的软件一开始就恰好适应客户的需要，退一步讲，就算一开始就适应了，我们就能把握未来吗？    
    总结一下，上述两点，一个是提升软件能力，一个是强化管理，也算老生常谈，占大家时间，给大家解闷。

说的很有道理。就是麻烦格式再编排一下。谢谢。

如果公司流程合理 变更管理是最好的处理方式

主要还是开发商的责任，我们的甲方基本上是不懂技术不懂潮流的人，但是甲方基本上是被以大厂商为代表的“开发商”忽悠晕了的，比如ERP,SOA,SAAS，签合同之前牛b吹大了，做的时候总是糊弄，能推搪的推搪，毫无专业可言，所谓无知者无罪，客户无知，你也无知吗？看看你身边从业的人员，有需求调研需求采集需求管理需求文档编写业务分析很牛的人吗？没有！


还是“专业”，我们不专业，我们懂得一堆道理，要有需求管理，要有变更控制，但是落实呢？执行力呢？也没有！
架构只是问题的一小部分，适应性还来自开发方式，瀑布式的模式国内用得太多，做烂了n多项目，敏捷只成为攻击的标靶，而不是实践，哪来适应性呢？架构只是底层的东西，架构上面是复杂的业务实现，业务实现无法避免调整和重构，测试代码都没有如何适应？单单架构解决不了问题，强调架构的一个极端就是过度设计，镀金，浪费。



没错，计算机业界一直朝着这条路子走的，组件化，积木，n年前我见过java bean拖拉实现IC类似的图形化组件解决思路，ejb也强调把业务统统组件，现在鼓吹面向服务，你看到软件危机解决了吗？没有。我们不能用三角形，几何图案来简化计算机模拟实现业务这个过程，它不单单是技术问题,我们可以用bruce eckle的shape、rectangle来描述面向对象，但是描述业务，构建数据，实现流程还远远不足，这些只是提供了基础，如砖头、钢材、混凝土，一堆东西，但你不能说这就是大楼。

中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。

所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。

中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？

因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。

我做会计的老婆都知道软件公司是最累最不赚钱的公司，也许从一个行外人眼中可以反映出软件产业发展的现状

不赚钱是在国内，你去看看国外IT小公司的生活状况。我只同意最累。