越来越像无底洞的需求...

回楼上，我不是highsoft的。
但是我相信国内跟我们情况一样的公司一打打的，从这个意义上讲，我们是“同一个”公司的。

用了一年半的时间把一个买给一家客户的定制软件最后发展成产品，到离职时有30家客户。前10家客户的需求几乎是来者不拒，后10家客户的需求大部分是给钱都不做。

几点自己的经验
（1）快速原形进行需求沟通；
（2）给第一家做的系统，不可能也不该包含到太多后续客户的需求，所以系统后续的更改必不可免，前面10家的需求是产品化的宝贵财富；
（3）部分模块在适当的时候可以或者说必须重写或重构。比如我们一个计算佣金的模块全面重写过三次，第三次改之前专门去过三家业务做得很细的公司调研他们的佣金处理业务；
（4）尽量让客户代表阶段性的提供需求更改列表，不要想到了就提个需求然后马上说要；阶段性的进行批量需求更改也好进行版本控制；


几点现在的反思
（1）项目是否要做成产品，公司在最早最好有个明确的定义，这样在开发前可以找两到三家客户进行需求调研。根据一家客户的需求开发的系统会缺乏扩展性，比如我们最早的权限角色就完全不具备扩展性。
（2）维护在合同中一定要考虑到，这个也是我们产品卖到后面销售最注意的一点。
（3）需求的备案整理和管理，开发人员流动走了，最后需求可能比代码更有价值

在我们这个飞速发展、朝令夕改的社会，软件是很难做的。
社会都在不停地变，软件也要不停地变。
一切都是摸着石头过何，缺乏统一的标准和模式，任何高深的理论到了中国软件业，都是那么苍白无力。

曾经羡慕JEE的“长治久安”，高度的组件化和伸缩性，多么令人神往。
可现实中，很少有这样真实稳定的需求。真实的需求是随需快速应变，于是用了RoR之后，舒服多了。不是说对RoR的运行效率和稳定性没有疑问，而是它可以很快地随需应变。

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

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

说说容易，做起来难....

啝伱差吥茤,哬哬~

需求变更，走商务

出现这种现象只能说是自己的公司和客户都不成熟。如果你们专注的做一个行业5年以上或许你就不会认为客户的需求有多大的变化了。我到认为真正的需求变化并不是很多，很多变动是因为我们遗漏或理解错误的需求。以前看到过一句话“变化的大多不是需求，而是你对需求的理解”，感觉挺对的。敏捷开发中的现场业务专家可以很好的理顺需求的变更。我以前在项目组中做了三年的需求分析，再加上自己以前做运维的三年，
感觉是用了六年的时间才对整个系统有了比较深刻的理解。很可惜，后来项目不做了，基本都外包了。想想以前的日子，做做需求，写写代码还真是舒服。我后来也在一个外企写了两年的代码，需求都是在国外完成的，就感觉做项目没有了很多的乐趣。做需求也有很多的技巧需要掌握，需要自己慢慢的总结和反思。但一个积极的心态是很关键的，我自己认为很多程序员对待需求变更的态度有问题。顺便说明一下，我都是给自己公司做开发，可能和你的情况也不太相同。

所以说定下来的需求都要签字，以免说不清楚后来的东西算不算新的

呵呵，看来让用户在需求文档上签字是好多乙方确定需求的不二法门。但该变的还是要变，只要你的需要抽象和实际业务有出入就得变。当然了，签了字的需求文档会对项目管理有帮助，可是对我们实际工作的帮助又有多少了？况且，在开发过程中，随着我们对系统的理解，我们也会对前期的一些需求有另外的看法或处理，难道我们要熟视无睹吗。在我这些年和别人的合作中，这种现象还是很多，有些人写代码好像只是完成需求文档的任务。想想这里要说的还挺多，以后有空再细说吧。《软件工艺》中有一个称谓“软件工匠”，凡“匠”者都对其作品非常的喜欢。其实，我们做东西的时候有了这种“匠”者的心态，再加上一些经验和技巧，离一件成功的作品就不远了。

客户预算既定的情况下就要限定需求的范围和细化程度，签字之后的更改走变更流程，加估工时。
设计的灵活可以保证在重大需求变更时改起来不会让已开发的地方崩掉。