关键字
领导型团队，战术型团队，教练型团队，团队管理工具。
CMI是第一个真正属于我们自己的部门，从构思，组建，磨合，到后来持续改进，伪敏捷转型，共同经历了很多痛苦和快乐，我相信这份感情才是维持0离职率的根本原因，薪资，激励，公司文化，个人发展都是其次。就像10年在eStation的时候，刘帅对每个人，对团队和产品都投入了相当的感情，以至于八年过去了，他一句简单的叮嘱我一直记得。
一个团队永远是人与人的联结，其他的制度，结构，奖惩都是辅助，不可能指望做个制度，规定个结构，就能维系部门。只输入制度，萝卜和大棒，得到的团队是没有韧性的。
在CMI的生命周期里，我们在成立之初就对团队结构发展做了一个展望，可惜最后都没有对这个展望进行回顾，这里补上这份文件，聊以慰藉。
领导型团队
这是CMI最初的结构，我觉得也是大部分团队的选择。由于当时公司是强矩阵，PM是项目经理的同时也是部门经理。这种结构是PM集权式管理，优势在于信息集中，决策效率高，没有多余过程。PM对需求，进度，质量，资源，风险等所有信息全面把握，事情来了自己考虑清楚，分解掉就能指派任务开始做，团队成员做好螺丝钉就行了。缺点在于对PM要求较高，对团队成长没有帮助。感觉这种结构适合小型项目。
当时绝大部分部门也是采用这个结构，但是我观察到有些部门犯了非常严重的错误，就是PM让项目组外的干系人直接对接到项目成员，这个外部干系人可能是产品经理，可能是测试，UI设计师，甚至可能是客户。
这样一来就尴尬了，某个主程需要分配精力对接随时可能找过来的干系人，项目信息分散在PM和主程身上，并且信息不一定一致，主程可能对干系人说一些不该说的话，总之这种做法绝对弊端很多。我想，他们这么做的目的是为了并行多个项目，牺牲项目质量，换取更高的绩效。实际上这种做法前期确实绩效更高了，但是长久下去，会导致欠下的质量债越来越多，最终每个项目验收周期都拖长了，甚至验收风险也高了。
正确的做法是PM作为项目团队内外部信息交换的唯一接口。我们当时就是这样，带来的好处是信息统一，团队成员可以不受打扰地专注在业务上。对于测试生命周期的设计PM一个人跟质量部门沟通，什么时候开发，什么时候测试，测试分几轮，什么时候解bug，什么时候回归，哪些bug要解，哪些bug不管，只在PM手里调配，最终开发和测试的工作量都小了很多，对于需求管理PM一个人跟客户和产品沟通，起码可以阻挡70%的变更，流转到开发手里的变更其实都是影响很小的东西，除非真的是前期设计不合理或者需求工程失误了。我想这个原理应该是沟通渠道的减少，带来的消耗减少吧。
战术型团队
在领导型结构跑了一段时间后，缺陷慢慢显现出来了，就是团队成员得不到锻炼，而且随着项目复杂度增加，PM渐渐感觉有压力了。这时，当确认团队成员都准备好的时候，PM就开始不再独占项目信息，而是把信息分享，让所有人参与设计，不单单包括业务设计，系统设计，也包括测试设计，原型设计优化等，这样一来，所有人就像是一个球队，大家商量一个战术来应对比赛。但是PM一定还是要作为唯一的信息接口。这种结构的好处在于把项目变成了大家的，而不是PM一个人的，每个人都有设计和参与感，有更多学习机会，相应的缺点在于决策成本变高了，更关键的是对项目管理流程有了要求。在这种结构下，如果没有对项目管理流程进行固化和优化，很容易造成混乱，一旦混乱开始，项目可视度，进度和质量基本就要崩。好在我们在第一个阶段已经对项目流程进行过固化和几轮改进了。所以在这个阶段比较顺利，团队的工作情绪也比较高。在跑了几个项目之后，我们团队的测试水平和业务能力提高很快，也是在这个时期CMI开始不再依赖测试人员，蔡毅也同意CMI的项目不用经过测试部了，直接准出给客户。
教练型团队
最终我们实现了这种教练型结构的雏形，PM几乎可以做到旁观，团队围绕核心成员自主运行，PM需要的，就是团队给几个版本交付时间，然后提交给PMO审下就完事了，那段时间我整天就去找宇哥打嘴炮。
当时计划的下一步是开始扩张部门，把现有团队的核心成员升到PM岗，还是跟最初的团队做项目，只是补充个别新人进去，PM就另外再带一个新的小组。为了这个计划，CMI还在两个项目上施行内部PM轮岗，由核心成员直接担任PM。
但是当时有个很大的问题，就是敏捷方法建议团队在5到9人，怎么在十多个人的团队里跑敏捷，同时又保持结构扁平，这个问题一直没解决，后来发现在CSM的认证课程里有专门讲到这个话题，当时特别想去学。但是由于很多事情，CMI的生命周期就到一段落了，非常可惜但这也是很早就能推算出来的事情，有市场的原因，有公司的历史原因，也有我自身的原因，总之，我忽然体会到eStation项目里，刘帅把它当孩子一样的心情，CMI就像我的孩子。
团队管理工具
能力意愿模型
员工档案
情境领导理论
团队文化管理
