那到底怎么来保证不同的人干同样的活呢？不用说了，就是繁琐的文档和评审。
那如何来解决需求的频繁变更？如何解决设计缺陷？还是文档和评审：需求的不稳定是由于各个部门、人员交流方式不当（对于产品不存在直接客户，需求由市场人员提出），而且没有采用较好的分析技巧，在分析过程中没有有力的评审；设计不好除了评审的缺失外，就是由于文档模板不够傻瓜，让人看了产生歧义照成的。
按CMMI+的观点一路走来，整个过程的关键就在于怎么写好文档和做好评审上了。文档和评审大家都不陌生吧，但就我体会看来，这两个东西都是徒有其名而已，形式大于内涵。而且过多的文档只会造成内容同步问题和时间浪费，这也是我作为程序员最反感的地方。
何谓以利益驱动？说的简单点就是加强绩效考核。出席评审提问数、建议数和奖金挂钩；需求整理关键点与奖金挂钩……似乎一切都明白了。看来要将这一套流程做下来，首先要改革僵化的绩效策略，变更部门的管理。这不是我小小的程序员力所能及的。
可是我不仅仅要疑问下：如果可以利益驱动来提高QA、评审人员等等的素质和职业道德水平，那么我们开发人员难道是不食人间烟火的榆木脑袋吗？如果IPD、CMMI能在一个公司高效运行起来，XP、RUP等等也能在开发中很好的运用起来。
谁料到，在最后我却得出这样一个结论：如果一个公司或者部门能高效的运转起来，能够调动每个人的积极性，管它什么方法论，都能立于不败之地。这是又想起这句话：人才是最关键的因素。
PS：老师在会上聊到了很多他自己所知的商业故事，我很感兴趣，听得也格外投入，第一次培训竟然两天都没有睡觉。
