生态方案

　　生态方案多半不能直接就上，需要另外一些条件具备。

　　10～20人规模的开发组内实现跨职能（项目经理可推行）

　　实际上没有办法让10～20人可以互相修改别人的代码，但在这个规模上，合作的需求更高，代码的复用利益更大，跨职能势在必行。

　　这里所说的跨职能，不是代码级别的，而是在业务接口问题上，大致有以下几种情况。

　　一是经常有一些接口类功能，说不上来该谁做，这时候项目经理（就是10～20人的头）要协调其中一方完成，并为这方争取更多的资源（工期和人数）。

　　这里多少要建立团队可以提请要人的机制，而且项目经理能临时分配人员，比如把小李交给老王那组工作一段时间之类的。在139团队里边这个相对好办一些，如果是1个人管理12个人，就很难办。

　　组织方案

　　1、进度-质量目标的合并（研发的部门经理可推行）

　　也就是无论是否还有开发-测试的分割，必须把进度绩效和质量绩效统一管理。

　　一个项目延期了，测试也有责任；一个项目质量差，开发也有责任。结果大致会变成：

　　测试团队与开发团队融合

　　一般是测试团队分解到开发组，从事自动化测试的执行工作。

　　多数自动化脚本开发团队可以编写，但是多半要配置一些脚本、写一些测试用例什么的，由测试人员执行。

　　这种模式下，对测试团队的人数要求很少。

　　测试团队与需求团队融合

　　质量工作彻底交给开发团队负责，测试团队只负责业务级别的验收测试（还负责早期的需求理解和机遇需求的测试用例编写）。

　　开发团队分化出一些人负责执行测试，这些人的数量一样要求很少；开发团队同时对进度和质量负责。

　　这两种方法都不容易做到，而且还有无穷无尽的问题，但告诉大家一个方法来解决：那就是每当自己心里想问：“可是，怎么……呢？”，自己要先想三个答案，然后再问；有时候会发现不用问了，答案已经被自己说出来了。

　　2、市场/销售/产品/研发的跨职能（总经理/副总经理可以推行）

　　简单说就是市场/销售/产品团队，要为研发的成本负责（比如销售要先扣除研发成本，再谈提成）；而研发要为销售/市场负责（比如如果销售额上升，研发团队也有一个提成）。

　　日后有机会再谈这个，很多企业都已经有成功经验了，只是都不太分享而已。