今天在Javaeye上看到一个抱怨客户的无底洞需求时，一个网友的回复，觉得不错，对以后自己接项目做个警示：
From: http://www.javaeye.com/topic/180477
==========================
问题
==========================
越来越像无底洞的需求
首先声明俺们是做项目的，每个项目都大多相同，但是有很多细小的地方是不一样的。
于是乎，每个项目的需求总会有些差异。。。
于是乎，需求就越来越无底洞了。。。
俺正在做的一个计费的程序，就是这样，从一个小蜗牛成长一只大乌龟（当然从遗传说角度来看这是不可能的）。
最开始的时候，这个计费是很简单的，只需要处理以下几个情况：
从数据库固定的域里面读取出用来计费的依据。
从数据库固定的域里面读取出用来筛选的域。
按照三个固定的计费规则去计费，固定的收费，按比例的收费，按区间固定的收费。
本来这不是特别重要的，也没有特别去重视。
但是这个需求开始慢慢鼓胀了。。。每个地方的项目总会有那么几个不一致的地方。。。总要改一下……
后来简直发展成每个地方一个版本了。
首先，计费的依据不再是从数据库固定的域里面去读取了，而是可以自由指定一个数据库的域。伤筋动骨啊。
然后，计费规则也发生变化了，固定的收费，按比例的收费，按区间固定的收费，按区间固定比例的收费，按区间固定比例累加的收费。
计费的方式也有了变化，有把要计费的依据加起来一起收费，也有把各个依据分别收费然后再总和起来。。。又是一个伤筋动骨。
于是在春节前后，趁着没啥事的时候把整个程序扔了，用了decorate模式。心想，这次完事了吧？
没想到……又有了更加BT的需求了。。。
痛苦啊！！！！
遇到这种情况的时候，大家有什么感想……
==========================
回复一：
==========================
对项目的业务不清楚，光靠前期的调研只能知道大致要做的，实际上的细节用户自己也很难说清，等系统上线了，有了实际的原型，就是你认为开发完了不应该再变 动的系统，用户才会有具体的详细要求，当然也不是一次能给你，只会在碰到什么实际业务时突然想起，这是很常见的情况。
这种模式很常见，也就很合理，再做项目的时候，首先要考虑对用户的业务熟悉不熟悉，如果不熟悉，就要考虑好这种情况，换个角度来看，这种由于业务不熟悉导致的需求变更，是公司应该交的学费，怎么在前期做好项目策划，就非常重要。
对具体做事的程序员来说，首先要清楚，这类项目上线后，才是原型完成，后面将有一轮又一轮的详细需求，开发时间基本上和模块开发时间相当，要做好 持续修改的准备，业务等于在这个阶段才真正开始做测试。第二就是，用户的每个需求变更都是有原因的，要把原因找到。第三，把工时记下，提交给项目经理。
===========================
fight_bird 的回复
===========================
楼主遇到的需求变更、膨胀状态其实是国内定制化软件项目业务逻辑挖掘的一个正常过程，并非存在所谓的无底洞，本质问题还是需求调研没有做好、做细，却匆忙开始系统分析和编码，结果当然是不停的做炒冷饭的事情！
恕我直言，根子还是在项目管理的水准，这么粗的需求分析状态下不应该允许进入详细设计阶段，我怀疑你这个项目是几个人的小项目，你们公司的项目监理机制几乎不起作用。
说得上纲上线一点，你们公司在国内项目业务需求的调研上没有成熟的方法论指导，还处于客户“指哪打哪儿的状态”，这种状态长期下去会拖垮开发团队，这对于处于创业成长阶段的公司倒是可以理解，但对于想做大、做强的公司来说却是必须跨越的阶段，否则这样的公司长不大的。
===========================
一蓑烟雨任平生 说：
===========================
项目管理也许有些问题，但我觉得还是项目策划的问题，对一个业务不熟的项目要有一个策略，成本估算时要充分考虑到后期的反复，这个跟走不走需求管理的流程没有关系。需要清楚的是怎么做这个项目，如果不挣钱，以后能从这个项目中得到什么？
因为对业务不熟，到最后才能了解业务的细节，这里面有一个长期的学习过程，这个过程是要付出代价的，这个成本在项目的策划时就应该考虑到，同时要 考虑这代价在以后的项目中怎么逐步降下来，产品化不产品化不重要，重要的是业务的积累和团队的稳定，否则以后还会付出更大的代价。
===========================
RCFans 说：
===========================
这不是需求不清的问题，而是软件设计人员经验不多的原因。
我近来在和你做一个有点类似的项目
从多个源里面读取用来评分的依据
从...读取用来评分的标准
按照标准去计分，目前分四个：价格/交付/质量/服务
我们的源是多样的，数据库有，Web service也有，而且不断增长，关于数据处理的问题在一开始就了解必须设计得非常活；关于评分标准，在项目一开始我就给组员说这个项目的难点就是“标 准不标准”，提出必须使用“评估因子组装”的方案来构成标准，我们尝试参考了一下Enterprise Library的策略注入，最后在业务分析师的协助下学习了SAP Vendor Evaluation（发现该系统的打分原理和我设计的一样，但还增加了weight factor），现在设计出来的系统可以说满足OCP。
==========================
fight_bird 回复：
==========================
对于国内项目这种事情很常见，就看搞售前和商业策划的本事了，这时候就凸显行业经验的重要性和价值，这样的项目最合适的方式是分期完成，合约也分期签署，前期做好了，后期可能合作更深入，可以达到双赢，反之，可能双亏了。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
