如何应对软件需求不明确、需求频繁更改和需求的无底洞

入职以来一直会遇到这种问题，也许是软件行业的死穴，任何项目如果处理不好解决不了这些问题，就相当于得了慢性绝症，不但项目的结局是死路，经手项目的每 个开发人员到管理者都在经受挑战人体极限的折磨。开发人员就像交通工具，上级传达指令，他就会最高效的将之送到目的地，如果老板自己都不知道想去哪里或者 不会开或者GPRS导航都不会用，就算给他一辆保时捷或者飞机都是白搭，说到这就知道为什么软件行业跳槽之频繁了。

一、问题列表：

1.客户(或上级)自己不知道自己想要什么。
2.客户需求已明确，后由于业务需要，频繁更改，更改后发现还不是想要的。
3.无底洞的需求变更和功能修改。
4.项目催的紧，本来两天的工活一天要完成，项目变成拔苗助长。
5.后期软件改成一锅粥，程序员一走，基本无人能明白需求和可以接手。

二、搜集的例子：

1. 几年前，我和一位同事在外地共同参与一个软件项目的开发。项目本身并不算很大，开始的需求调研进行了很长时间，期间不但几乎拜访了所有部门，还与用户反复 讨论，征求意见，需求文档几易其稿。即便这样仍然有许多不确定因素，搞得人心烦意乱。当时我牢骚很多，总觉得又花时间似乎还没真正做事。
我的同 事经验比较丰富，他给我说了一个他自己的亲身经历。那时候他在深圳参与一个证券项目，当时软件开发管理非常不规范，基本上是了解需求后就编程序，根本没有 太多的交流，需求文档就更没有了。系统开发出以后，用户不断提出新需求。每天追着开发人员解决问题，项目实际是一个无底洞，没完没了地往下做，按他的说法 是项目成员“肥的拖瘦，瘦的拖死”，实在做不下去只能跑了。

2.前段时间，我出任项目经理承接了一个中型软件项目，公司再三叮咛我一定要尊重客户，充分满足客户需求。项目开始比较顺利，辛辛苦苦熬了几个月的通宵，基本保持项目的正常进度，客户相当满意。但进入后期以来，客户频繁的需求变更却带来很多额外工作。
需求变更不但越来越多，更可怕的是为了节省时间，客户不再向我申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关 文档也忘记修改。很快就出现一个问题，就是需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统到底改成什么样。后来因频繁出现改好的错误又重新出 现，这让我很无奈。

3. 这是我进入公司以来的第三个项目。做这个项目给我的最大感受就是：做项目前一定要弄清楚需求。否则只有无数次的反工。导致项目一直延期。成本超出预算。
我们公司是甲方。我们只做UAT测试。当已方把代码写完。提交我们测试的时候。我们竟然发现已方都没有做系统测试。最后我们只好又做系统测试，又做UAT4测试。
最初是分析需求，写用例。需求变化的非常频繁，以致于最初的需求和后来做出来的东西相差很大。导致三周写的用例变成了无用功。后来因为急于上线，大家加班 加点的测试，改BUG，回归BUG。还加班了好几个通宵呢。在主要流程凑合跑通的情况下。系统上线了。大家终于松了一口气。近两个月的加班加点，终于让系 统上线了。
接下来就是进一步的测试。很多细节都还没有测到。也不用那么加班加点的赶了。好景不长啊。不到一个月，第一次的需求便更来了。而且变化很大。又一次加班， 接下来就是接二连三的需求变更。就连主要流程都变了。同一个功能的需求两天内就变了三次。以致于到最后，和最初做的系统相比已经面目全非了。呵呵。等于又 重新做了一个嘛！这样不仅一直拖延工期，使得项目一直不能告一段落，而且预算超出很多。开发部、测试部的同事也很厌烦。尤其是测试部门的。大家都说用不着 细测的啦。反正过不了几天这个需求还得变。现在测了也没用。呵呵。看看。大家都有了这样的心里了。这测试的质量很难保证的啊。大家干活一点积极性也没有。

4.转自Javaeye的一篇：
==========================
问题
==========================
越来越像无底洞的需求

首先声明俺们是做项目的，每个项目都大多相同，但是有很多细小的地方是不一样的。 
于是乎，每个项目的需求总会有些差异。。。 
于是乎，需求就越来越无底洞了。。。

俺正在做的一个计费的程序，就是这样，从一个小蜗牛成长一只大乌龟（当然从遗传说角度来看这是不可能的）。

最开始的时候，这个计费是很简单的，只需要处理以下几个情况： 
从数据库固定的域里面读取出用来计费的依据。 
从数据库固定的域里面读取出用来筛选的域。 
按照三个固定的计费规则去计费，固定的收费，按比例的收费，按区间固定的收费。

本来这不是特别重要的，也没有特别去重视。 
但是这个需求开始慢慢鼓胀了。。。每个地方的项目总会有那么几个不一致的地方。。。总要改一下…… 
后来简直发展成每个地方一个版本了。

首先，计费的依据不再是从数据库固定的域里面去读取了，而是可以自由指定一个数据库的域。伤筋动骨啊。 
然后，计费规则也发生变化了，固定的收费，按比例的收费，按区间固定的收费，按区间固定比例的收费，按区间固定比例累加的收费。 
计费的方式也有了变化，有把要计费的依据加起来一起收费，也有把各个依据分别收费然后再总和起来。。。又是一个伤筋动骨。

于是在春节前后，趁着没啥事的时候把整个程序扔了，用了decorate模式。心想，这次完事了吧？

没想到……又有了更加BT的需求了。。。 
痛苦啊！！！！

遇到这种情况的时候，大家有什么感想……

==========================
回复一：
==========================
对项目的业务不清楚，光靠前期的调研只能知道大致要做的，实际上的细节用户自己也很难说清，等系统上线了，有了实际的原型，就是你认为开发完了不应该再变 动的系统，用户才会有具体的详细要求，当然也不是一次能给你，只会在碰到什么实际业务时突然想起，这是很常见的情况。

这种模式很常见，也就很合理，再做项目的时候，首先要考虑对用户的业务熟悉不熟悉，如果不熟悉，就要考虑好这种情况，换个角度来看，这种由于业务不熟悉导致的需求变更，是公司应该交的学费，怎么在前期做好项目策划，就非常重要。

对 具体做事的程序员来说，首先要清楚，这类项目上线后，才是原型完成，后面将有一轮又一轮的详细需求，开发时间基本上和模块开发时间相当，要做好 持续修改的准备，业务等于在这个阶段才真正开始做测试。第二就是，用户的每个需求变更都是有原因的，要把原因找到。第三，把工时记下，提交给项目经理。

===========================
fight_bird 的回复
===========================
楼主遇到的需求变更、膨胀状态其实是国内定制化软件项目业务逻辑挖掘的一个正常过程，并非存在所谓的无底洞，本质问题还是需求调研没有做好、做细，却匆忙开始系统分析和编码，结果当然是不停的做炒冷饭的事情！

恕我直言，根子还是在项目管理的水准，这么粗的需求分析状态下不应该允许进入详细设计阶段，我怀疑你这个项目是几个人的小项目，你们公司的项目监理机制几乎不起作用。

说得上纲上线一点，你们公司在国内项目业务需求的调研上没有成熟的方法论指导，还处于客户“指哪打哪儿的状态”，这种状态长期下去会拖垮开发团队，这对于处于创业成长阶段的公司倒是可以理解，但对于想做大、做强的公司来说却是必须跨越的阶段，否则这样的公司长不大的。

===========================
一蓑烟雨任平生 说：
===========================

项目管理也许有些问题，但我觉得还是项目策划的问题，对一个业务不熟的项目要有一个策略，成本估算时要充分考虑到后期的反复，这个跟走不走需求管理的流程没有关系。需要清楚的是怎么做这个项目，如果不挣钱，以后能从这个项目中得到什么？

因 为对业务不熟，到最后才能了解业务的细节，这里面有一个长期的学习过程，这个过程是要付出代价的，这个成本在项目的策划时就应该考虑到，同时要 考虑这代价在以后的项目中怎么逐步降下来，产品化不产品化不重要，重要的是业务的积累和团队的稳定，否则以后还会付出更大的代价。

===========================
Joo说：
===========================
说的很在理，基本上在国内这种状况能占了80%的项目（国外不知道，可能会好那么一点点？） 
但是一般往往软件费用在第一次上线之前就已经谈定了，再接下来要改你要收钱他就翻脸：不是之前说好的么？

==========================
fight_bird 回复：
==========================
对于国内项目这种事情很常见，就看搞售前和商业策划的本事了，这时候就凸显行业经验的重要性和价值，这样的项目最合适的方式是分期完成，合约也分期签署，前期做好了，后期可能合作更深入，可以达到双赢，反之，可能双亏了。

==========================
hax回复：
==========================

需求调研不可能达到做好做细的理想境界。

a. 需求本身就在变化，比方说在6个月的开发周期中可能客户自己的人、事、组织都有了变化。 
b. 客户代表本身不一定能很好的认识和把握需求，有许多细节是不可能在初期确定下来的。 
c. 企图做好做细，只会大大增加前期的时间和沟通成本，而且团队在拿到所谓的需求说明书之后往往忽略了开发过程中的沟通和调整，问题被掩盖、推迟和归咎于需求没做好的借口。

大 多数项目为什么会失败？失败并非是单纯的做不出东西，而是指无法在给定资源（时间、费用等）下完成项目，有大量资源被浪费了，做了无用功。所以很多人就认 为要一开始先把好关，避免浪费。然而认为把需求做好做细就能避免资源浪费，是一厢情愿的想法。因为需求是无止境的，你也无法有效验证需求的合理性。从理论 上说，需求做的是不是好，最后还是要看实施结果，所以前期对需求是不是足够好足够细的判断，只能基于猜测或者形式上的要求（比如写了多少页画了多少图开了 几次会）。 
==========================
abang回复：
==========================

看了楼上各位的留言，使我受益匪浅

总结了一下：需求的尽量全面细化与时间尽量少是一矛盾，需求越全面越细化，花费的时间就越多，花费的时间越少，需求就很难做到全面细化，解决这一矛盾的关键还是掌握好火候，使需求和时间的配比做到最佳。

说说容易，做起来难….
==========================
zhangshoukai回复：
==========================
国内的客户吧？

三、解决方法：

古人根治绝症的方法无非是从根源将其除之，软件行业的这些问题追其根源还是在于人，人性有很多弱点，如果卡耐基在世并且也做软件，应该不存在这些问题。 
说笑了，我想在目前软件行业发展的基础上，最好的方法还是多加强沟通，多学习国外的软件管理和规范，客户和老板要多考虑业务实际需求，项目经理严把关卡，开发人员也要学会拒绝。需要客户、老板、项目经理、开发人员四者配合才可以妥善解决。