问：要保证交付，团队最合适的leverage模型是什么样的？
要保证成功交付，上面哪个团队的更接近合适的leverage模型？有没有一个固定的比率？
这首先取决于工作的类型，专业服务工作一定会面临如下三种类型的工作
- 开拓型工作
- 挑战型工作
- 常规型工作
不同类型的工作势必要求团队形成不一样leverage模型，作架构咨询的团队leverage会低些，而作个中型规模的网站leverage会高些。请问，你所在的团队面临的工作类型是什么？
这还取决于成功的定义，左边的leverage模型在通常的状态下，更接近成功的交付软件产品，但它不意味着从公司层面，团队进行了一次成功的交付服务。可能因为没有赚到钱，没有赚到钱的原因是leverage太低，这个算式很简单。
公司盈利 ＝ 收入 － 团队工资 － 杂费
杂费比较固定，收入会在市场价格附近波动，团队工资越高，盈利就越少。那么第一个模型的工资成本显然会高些。还有很多其它不成功的原因，譬如没有培养出足够多的人才，没有营造出良好的团队氛围，员工对公司的不满增加。请问，你们项目的成功定义是什么？
Leverage模型随着项目的进行会产生变化。即便我们确定了项目类型，我们也无法确定一个最合适的leverage模型，因为随着项目的进行，所需要的Leverage会变化，项目开展的前期和后期开拓型，挑战型的工作会比较多，因为牵扯到技术选型，布署等极具挑战型的工作，而中期常规型活动会比较多。项目所处的阶段也会对Leverage模型产生影响。请问，你们项目处于阶段？
如果我们能回到上述所有问题，这个题目本身也就不难回答了
问：如果我的团队没有达到所需要的Leverage模型，怎么办？
发现专家，团队中的成员不应该通过他们的grade来盖棺定论，有些人整体上来看经验尚浅，但他在UI方面是行家里手，找到这些团队成员，帮他们找到更合适的位置会在局部改善团队的leverage模型。
重点培养，有些人的性格特质决定了他会脱颖而出，他们通常更自律，更勤奋，找到他们，重点培养，让他们快速成长会逐渐改善团队的leverage模型。
检查点，见建设全功能团队 － 实践篇 之结对编程，不止于结对一节，通过设立检查点的方法提高leverage效率，从而改变leverage的模型。
哭喊，前面的招数如果都没见效，请开始哭喊，学会升级问题，在PM这个层面难如登天的问题，对于CP, RM来说可能是个小问题。
换人，还不成的话只有换人了，或者是你自己，或者是团队成员。
问：在什么情况下引入上面的实践？
相信群体智慧，Retrospective这样的实践不是设计出来吐苦水的，一个人的能力毕竟有限，对信息的了解也不够全面，善用群体智慧带来的好处是不言而喻的，而且集体决策还带来了更强的责任感。
