客户协作 OVER 合同谈判

是的，是的。只不过现在很多用户奢望“干多久，花多少钱，干多少事”都能在事先“测准”。当然，这不能怪客户。软件业为了自身的健康发展，应该担负起在这方面教育客户的责任。

这个在中国很难做到的，其实敏捷原则中很多涉及到客户方的问题都是很难做的。包括前面庄提到的例子。

仔细分析敏捷方法（或者绝大多数方法学），可以看出主要是针对新开发项目或者定制项目,所谓的项目管理就是讲的这意思。

但是很多情况下，公司会有一个主要产品，几年内会在同一个产品的框架下进行少量的定制，客户提出的需求变更基本上不大，如果按照单价合同去计算，那是不可能的事情。所以一般来说还是按照产品的主要功能定价，但是如果产品销售量比较大，那些这些小需求的变更也是很难控制的。

另外，在这样的情况下，如何保持研发人员的士气以及设法不断提高研发人员的技术能力都是很大的考验。

我们基本上对数量不多的定制大功能，产品升级，新模块开发，和数量相当大，周期非常短的定制开发分开管理。但是要注意的是，公司发展到一定程度，第二种情况才是常态。或者最后把开发的部门分开，成立专门的研究院和开发部，但在开发部内部还是如此。


开发方法学的具体做法在整个软件公司的研发管理中是一个局部的概念，而方法学所代表的思想才是最应该贯穿并应用到整个研发管理去的。

开发方法学的具体做法在整个软件公司的研发管理中是一个局部的概念，而方法学所代表的思想才是最应该贯穿并应用到整个研发管理去的。

其实也可以做到，靠浮动质量来做到，这正是很多项目的现实。

浮动质量是什么？

浮动质量标准。

时间来不及了，或者人手不够，就降低质量标准。

哦，竟然一直不知道这个还有专用名词。呵呵，谢谢！

软件领域比较特殊，质量越高，生产力越高。《人件》阐述了这个问题。