如何处理软件项目中发生的需求变化
在IT行业中，有一个不能忽视的问题。这个问题就是如何面对那些经常在发生变化的业务需求。做IT项目，客户老是喜欢在项目进行过程中修改需求或者增加新需求。诚然，在项目一开始的阶段，客户不清楚自己到底需要怎么样一个系统，往往在项目进行中突然明白或者说清楚自己真正想要个什么样的系统。所以这些在项目过程中提出来的变化需求也并不是客户在无理取闹，反而对客户来说比在项目开始阶段那些双方互相确定的需求更加有意义和重要。
就我以前的经验和思路，我对这个问题的解决思路基本上是这样的。
首先，变化就意味着风险。我们当然要把这个问题当作项目中风险的一种来处理。那常规的处理方法也就这么几个。风险的量化，风险的监控什么的。实际上判定一种风险对我们的影响程度究竟有多大的时候，我们往往只需要问自己一个问题就可以：新需求发生或者老需求变化时候，我们是否已经习惯处理这样类似的突发事件?我总结了一下，我们以前处理的时候无非也就是这样五种情况。
1． 我们以前解决过，这对我们没什么，很正常的事情。(作战能力强的团队都有资格这么说)
2． 我们没解决过，但公司里其他项目组，产品组好像解决过。有专门的解决方案文档可以查阅。（向公司内部寻找帮助是个好办法，但在中国行不通，我就看见过有人可以解决但就故意不配合你，让你自己解决去，而不给予任何帮助。）
3． 公司里没有这样的解决方案的资料，但是有很多第三方的资源可以利用。（做JAVA的人好像都喜欢，的确我也听说这样一句话：“内事不决问老婆，外事不决问google”）
4． 好像听说过有人解决过，不过记不清楚了。（等于没说，其实就是没办法解决问题）
5． 的确之前没有解决过这样的问题。但可以试一下，可以作点有开创性的工作应该会有成就感。（以积极的态度来看待自己从来没有经历过的工作）
其实当我们面对一个变化的需求或者新需求时候，可以看看我们是采取上面五种情况里那一种来解决。我认为如果能用前面三种情况解决，基本上我们就可以答应客户去做或者更改需求。如果是后两种，最好还是慎重点为好，特别是最后一种，虽然态度是不错的，但态度有时候并不决定一切。好心办坏事的事情屡见不鲜。
但是就算这样，并不能算结束了。其次我们还要评估一下需要增加或者修改的需求对客户的重要性问题。对于客户那边的业务人员来说，这样一个需求在他们眼里是怎么样的也决定了我们是否答应他们做这个需求。
如果系统中没有这样一个功能，业务人员是否会注意？或者他们会注意到没有这么一个功能但觉得并不影响他们使用系统。又或者是一小部分或者一大部分甚至整个系统都需要依赖这个功能，没有它影响很大？这个也是我们在评估的时候需要考虑到的。
还有一点就是如果我们这个项目团队没有人会完成或者修改这个需求所需要的技术怎么办？因为我是做JAVA的，JAVA的东西是在是太多了，就我看见的技术人员，没有一个人是十八般兵器样样皆精的。所以这也是需要考虑的。这样一个需求所需要用的技术是否是我们需要一段培训时间才能掌握的？或者有可能我们会，但是掌握的不太熟练，需要用一段时间才能达到熟练水平。当然也有可能我们已经很熟练了。或者对我们来说这完全是小菜一碟。
所以当我们面临这样一个崭新的或者变化的需求，我们要从过去的风险解决经验，对客户业务人员的重要性和技术团队使用技术水平这三方面来评估。
我以前也是经常这么做的，说老实话我觉的还凑合，基本上不会让客户说闲话。而且有时候我们要顶住客户的无理需求时候，拿这三个做理由往往都能让他们无话可说。毕竟我们讲的出道理为什么不答应做这个新需求。 38 楼 yangyi 2009-06-15 darkewiser 写道中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。
所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。
中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？
因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。
我做会计的老婆都知道软件公司是最累最不赚钱的公司，也许从一个行外人眼中可以反映出软件产业发展的现状 39 楼 黑暗浪子 2009-06-15 yangyi 写道darkewiser 写道中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。
所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。
中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？
因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。
我做会计的老婆都知道软件公司是最累最不赚钱的公司，也许从一个行外人眼中可以反映出软件产业发展的现状
不赚钱是在国内，你去看看国外IT小公司的生活状况。我只同意最累。
40 楼 RCFans 2009-06-15 darkewiser 写道中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。
所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。
中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？
因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。
这点我不赞同，老外的管理是非常细化、科学的，是告诉你做什么，怎么做。就像CMMI，外资企业和国内企业，完全是两回事。外资企业里怎么去做需求、设计、编码、估算、测试，一套一套的方案、部门、职能全部齐全，而国内只知道“出个文档”，并且，还只有程序员这个角色。 41 楼 黑暗浪子 2009-06-16 RCFans 写道darkewiser 写道中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。
所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。
中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？
因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。
这点我不赞同，老外的管理是非常细化、科学的，是告诉你做什么，怎么做。就像CMMI，外资企业和国内企业，完全是两回事。外资企业里怎么去做需求、设计、编码、估算、测试，一套一套的方案、部门、职能全部齐全，而国内只知道“出个文档”，并且，还只有程序员这个角色。
你说的很不错，我再补充一点，其实敏捷管理只是方法论，它就是告诉你怎么做到这些。要做什么东西是CMMI的事情。还有像RUP，PMP，6西格玛什么的都是和敏捷一样是告诉PM怎么做到CMMI中定义的那些标准。
42 楼 lluupp1975 2009-06-18 seemoon 写道在做项目计划的时候，应该明确项目范围，确定边界，范围内的事要做也必须做，范围外的事坚决不做。这是原则。
如何确定范围需要方法和技巧，对项目背景理解，产品了解，用户需求分析...这些是技能和方法。
当用户提出这样或者那样需求的时候，要根据确定的范围进行管理和控制，这是执行力。
原则+方法+执行力=需求管理
原则和方法可以通过学习和实践获得，而执行力更多依赖于管理者的个性、能力，包括职权。
在需求管理上面，实战经验没有多大意义，在他那边行得通在你这边却行不通，就是因为项目环境和人之间的差异。因此只有一些原则方法来作为指导，具体管理仍要看管理者自己。
由于软件的“软”特质， 用户对需求的认识是逐步明朗化，因此应对需求变化需要软件系统具备一定的弹性和适应性，这一方面来源于软件的架构和设计，一方面取决于开发方法的采纳，比如用敏捷方法开发软件在应对变化上必然强于过程开发。
制定原则跟需求分析一样重要 需求分析是控制软件产品的形成 制定原则是控制管理为开发项目保驾护航。说的明做的开 制定原则多依赖实战经验＋处事经验（毕竟人的理解能力是有差异的这就要靠处事经验来沟通，靠实战经验来摆事实说明可行不可行的利弊）来权衡利弊。在制定原则时 需求分析是辅助性的 当需求分析转化成项目时制定的原则就是辅助性的 关键就是亲兄弟明算帐说的明才能做的开。对于需求变化 客户在行业上是专家但在项目实现上是外行 客户是最终的使用者他关心的是自己。对于变化要权衡利弊可以对变化要求延长开发时间和要求资金，一般客户会搁置问题的。 43 楼 kofren 2009-06-23 我觉得应该是设计时的可扩展性，不知道可否理解为敏捷式开发. 44 楼 warison_2008 2009-06-26 内事不决问老婆，外事不决问google，这句话，我喜欢 45 楼 seemoon 2009-06-26 kofren 写道我觉得应该是设计时的可扩展性，不知道可否理解为敏捷式开发.
no.
设计可扩展性体现在设计能力，敏捷开发体现在敏捷能力，比如，你的代码能否经受住需求变更后仍然具备高质量？这显然不仅仅是设计问题。
46 楼 seemoon 2009-06-26 黑暗浪子 写道RCFans 写道darkewiser 写道中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。
所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。
中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？
因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。
这点我不赞同，老外的管理是非常细化、科学的，是告诉你做什么，怎么做。就像CMMI，外资企业和国内企业，完全是两回事。外资企业里怎么去做需求、设计、编码、估算、测试，一套一套的方案、部门、职能全部齐全，而国内只知道“出个文档”，并且，还只有程序员这个角色。
你说的很不错，我再补充一点，其实敏捷管理只是方法论，它就是告诉你怎么做到这些。要做什么东西是CMMI的事情。还有像RUP，PMP，6西格玛什么的都是和敏捷一样是告诉PM怎么做到CMMI中定义的那些标准。
敏捷是方法论？明显你还不懂敏捷。
做什么是CMMI的事？观点尤其很搞笑。
最后CMMI对RUP,PMP,6C都包圆了？ 糊涂阿糊涂，淅沥糊涂
47 楼 黑暗浪子 2009-06-26 seemoon 写道黑暗浪子 写道RCFans 写道darkewiser 写道中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。
所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。
中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？
因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。
这点我不赞同，老外的管理是非常细化、科学的，是告诉你做什么，怎么做。就像CMMI，外资企业和国内企业，完全是两回事。外资企业里怎么去做需求、设计、编码、估算、测试，一套一套的方案、部门、职能全部齐全，而国内只知道“出个文档”，并且，还只有程序员这个角色。
你说的很不错，我再补充一点，其实敏捷管理只是方法论，它就是告诉你怎么做到这些。要做什么东西是CMMI的事情。还有像RUP，PMP，6西格玛什么的都是和敏捷一样是告诉PM怎么做到CMMI中定义的那些标准。
敏捷是方法论？明显你还不懂敏捷。
做什么是CMMI的事？观点尤其很搞笑。
最后CMMI对RUP,PMP,6C都包圆了？ 糊涂阿糊涂，淅沥糊涂
我不是很有时间和你说这件事情。我也不知道你的观点从何而来。
请你多阅读几本07-09年出版的敏捷管理书籍再来和我说这件事情。当然目前这些书籍都没有简体中文版。你的消息闭塞我是可以理解的。
48 楼 seemoon 2009-06-27 黑暗浪子 写道seemoon 写道黑暗浪子 写道RCFans 写道darkewiser 写道中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。
所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。
中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？
因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。
这点我不赞同，老外的管理是非常细化、科学的，是告诉你做什么，怎么做。就像CMMI，外资企业和国内企业，完全是两回事。外资企业里怎么去做需求、设计、编码、估算、测试，一套一套的方案、部门、职能全部齐全，而国内只知道“出个文档”，并且，还只有程序员这个角色。
你说的很不错，我再补充一点，其实敏捷管理只是方法论，它就是告诉你怎么做到这些。要做什么东西是CMMI的事情。还有像RUP，PMP，6西格玛什么的都是和敏捷一样是告诉PM怎么做到CMMI中定义的那些标准。
敏捷是方法论？明显你还不懂敏捷。
做什么是CMMI的事？观点尤其很搞笑。
最后CMMI对RUP,PMP,6C都包圆了？ 糊涂阿糊涂，淅沥糊涂
我不是很有时间和你说这件事情。我也不知道你的观点从何而来。
请你多阅读几本07-09年出版的敏捷管理书籍再来和我说这件事情。当然目前这些书籍都没有简体中文版。你的消息闭塞我是可以理解的。
你原来还挂着片树叶的，但这么一说就把这片可怜的黄叶也被风吹走了
管理学被你用中英文衡量简直是在亵渎管理二字 49 楼 黑暗浪子 2009-06-29 seemoon 写道黑暗浪子 写道seemoon 写道黑暗浪子 写道RCFans 写道darkewiser 写道中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。
所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。
中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？
因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。
这点我不赞同，老外的管理是非常细化、科学的，是告诉你做什么，怎么做。就像CMMI，外资企业和国内企业，完全是两回事。外资企业里怎么去做需求、设计、编码、估算、测试，一套一套的方案、部门、职能全部齐全，而国内只知道“出个文档”，并且，还只有程序员这个角色。
你说的很不错，我再补充一点，其实敏捷管理只是方法论，它就是告诉你怎么做到这些。要做什么东西是CMMI的事情。还有像RUP，PMP，6西格玛什么的都是和敏捷一样是告诉PM怎么做到CMMI中定义的那些标准。
敏捷是方法论？明显你还不懂敏捷。
做什么是CMMI的事？观点尤其很搞笑。
最后CMMI对RUP,PMP,6C都包圆了？ 糊涂阿糊涂，淅沥糊涂
我不是很有时间和你说这件事情。我也不知道你的观点从何而来。
请你多阅读几本07-09年出版的敏捷管理书籍再来和我说这件事情。当然目前这些书籍都没有简体中文版。你的消息闭塞我是可以理解的。
你原来还挂着片树叶的，但这么一说就把这片可怜的黄叶也被风吹走了
管理学被你用中英文衡量简直是在亵渎管理二字
你是不是最近很无聊，想和人吵架啊？
真是的，弯曲别人的意思可真在行。弄库以饿~
50 楼 黑暗浪子 2009-06-29 seemoon 写道黑暗浪子 写道seemoon 写道黑暗浪子 写道RCFans 写道darkewiser 写道中国人跟老外的思路是不同的，完全照搬国外的方法，体系困难重重。正如楼上所说，东西咱都知道，但是具体的问题却无法克服。国外的软件理论与管理方法，是多年演变出来的，长时间内形成了很多解决具体问题的方法跟经验，但所有这些经验都是与当时的实际状况相关的。而管理理论一般只是抽象，综合后的结果：告诉你要做什么东西，但无法告诉你怎么做到这些。
所以想仅仅靠规定，架构等方法解决所有问题，是远远不够的。要使用国外的方法，观念上就得跟老外一致。
中国的软件行业总体来说还是很浮躁的。没办法，大趋势如此。毕竟很多公司还在生死线上挣扎。试问在这种情况下，又有多少人会去做项目各项参数的积累与分析呢？
因此，在这种状态下，需求的变化是无法避免的，因为在项目前期无法对项目的任何状况做出正确的判断--包括客户的“无知”，这本身就应该在风险计划中。
这点我不赞同，老外的管理是非常细化、科学的，是告诉你做什么，怎么做。就像CMMI，外资企业和国内企业，完全是两回事。外资企业里怎么去做需求、设计、编码、估算、测试，一套一套的方案、部门、职能全部齐全，而国内只知道“出个文档”，并且，还只有程序员这个角色。
你说的很不错，我再补充一点，其实敏捷管理只是方法论，它就是告诉你怎么做到这些。要做什么东西是CMMI的事情。还有像RUP，PMP，6西格玛什么的都是和敏捷一样是告诉PM怎么做到CMMI中定义的那些标准。
敏捷是方法论？明显你还不懂敏捷。
做什么是CMMI的事？观点尤其很搞笑。
最后CMMI对RUP,PMP,6C都包圆了？ 糊涂阿糊涂，淅沥糊涂
我不是很有时间和你说这件事情。我也不知道你的观点从何而来。
请你多阅读几本07-09年出版的敏捷管理书籍再来和我说这件事情。当然目前这些书籍都没有简体中文版。你的消息闭塞我是可以理解的。
你原来还挂着片树叶的，但这么一说就把这片可怜的黄叶也被风吹走了
管理学被你用中英文衡量简直是在亵渎管理二字
你是不是最近很无聊，想和人吵架啊？
真是的，弯曲别人的意思可真在行。弄库以饿~
51 楼 xiaojiit 2009-06-29 小弟学习啦！ 52 楼 rocwon 2009-07-28 需求变化了吗？大部分时候需求从没有变过。
所谓变化，只是我们对需求由误解到理解这个过程中的小插曲。 53 楼 lovit 2009-07-29 rocwon 写道需求变化了吗？大部分时候需求从没有变过。
所谓变化，只是我们对需求由误解到理解这个过程中的小插曲。
真正企业的应用，需求是经常变化的，所以一般的企业，如果有可能，都会养一个技术部。 54 楼 yiding_he 2009-07-29 rocwon 写道需求变化了吗？大部分时候需求从没有变过。
所谓变化，只是我们对需求由误解到理解这个过程中的小插曲。
说到点子上了，只是很多人不肯承认而已。 55 楼 lovit 2009-07-29 yiding_he 写道rocwon 写道需求变化了吗？大部分时候需求从没有变过。
所谓变化，只是我们对需求由误解到理解这个过程中的小插曲。
说到点子上了，只是很多人不肯承认而已。
是吗？？？ 56 楼 anzn20 2009-10-28 很有见地！ 57 楼 黑暗浪子 2009-11-03 legenda1 写道需求在开发时需要先建立需求基线，在基线里增、删、改需求项可以申请基线变更，变更后生可选择生成新的需求基线，一切修改都是可查的，可以使用需求管理工具进行，我所处开发团队使用的是“Qone软件过程管理平台”，他们官网上有详细的产品试用信息
[url]http://qone.nfschina.com[/url
知道了。baseline的东西做过项目管理的都知道。
