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

中国的事情嘛都讲个人情世故，你做得辛苦客户也看在眼里，他也没必要把你累死，对他没什么好处，所以放心好了，做到一定的时候就会扔掉重新来，其实跟按时间付费没多大区别

哈哈哈，不过估计维护一年左右，人家就不会再提什么过份的要求的了。
他们还是比较讲道理的，当然也得益于我们推掉这些问题的能力……

这样对公司是很好。
只是这样会累死个驴啊。
所以现在我很害怕半夜有电话打过来说“出问题啦，要是明天早上弄不好，我们要赔钱的。。。”

咳，把郁闷的东西说出来，心里好受多了。
继续当驴。

这根本就是两码事
难道你把需求搞定了老板就找不出由头来让你加班？

需求管理的好，项目运作规范的话。显然项目组成员会更舒服，更惬意。从项目团队成员的角度讲，这是有很大差别的。

加班好啊加班，我们公司加班费三倍工资可不是吹牛的。。。
只是，老板不会叫我们加班的，客户会……客户叫加班可没有加班费。
所以把需求弄好了，对自己有好处。
在这个公司的好处是闲的时候闲得要死。坏处是忙的时候也忙得要死。

同意这个说法。

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

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

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

同一类项目做了3-4个还是这个状态，显然也是有点问题的。
除非你所在的公司对这个细分市场的后续前景不太看好，否则还是应该往平台+产品走。
做完每个项目都要对项目的实施过程和类似项目的需求合一性进行总结，逐步为走框架==>产品+平台的路子走,适当增加研发投入。但不论怎样，将来这么些类似项目的维护和转换都是大问题。
开发+实施型的项目，没什么好办法。套路都是那样，只不过在于怎么降低自己的期望值而已，特别是进入一个相对陌生而且看起来比较简单的行业。有时，老练一点的客户都会主动让你降低期望值并降低对你的期望值。
产品配置/二次开发的项目实施方法就完全不一样。当然，产品是建立在对行业业务足够把握甚至其管理理念要比当前要实施的企业的相关方面还要成熟的前提下的。这个时候向高层推介理念以及在实施过程中持续的进行变革管理(不是指需求变更)也成为非常重要的一个环节，而且就产品所体现的模式和目标业务实践相折中的业务蓝图设计阶段是最重要的。不过这就扯远了。