- 问题
传统团队存在什么问题？
- 在谈到何为敏捷团队之前，先看看传统团队的问题，不要把团队转化完了，问题还存在；换言之，解决问题是目标，转化团队是手段。
- 各部门打架严重： 来自于分工中的灰色地带 / 各自目标和绩效的不一致
- 各部门流程/文档繁杂： 跨部门之间沟通成本高，需要大量流程和文档来规范接口
- 解决方案
组建跨职能的敏捷团队，来消除部门之间的分割
1. 3～5人规模的小组内实现跨职能（小组长可推行）
-
这个是无需行政授权，小组长就能做的事情。
通过1-3-9团队形成L型代码结构，局部的“部门”打架和文档问题迎刃而解。 139团队中，整个小组的目标是一致的，而且成败都由师傅负责，因此他会成为跨人员的桥梁，把整个团队的事情当作自己的事情，解决个人的打架问题。 L型代码结构可以有效降低文档量。当积木代码基本形成后，所有功能大致只有界面和业务逻辑的设计，经常一个功能只有50行代码左右，很多设计都可以因此省略。
2. 10～20人规模的开发组内实现跨职能（项目经理可推行）
-
实际上没有办法让10～20人可以互相修改别人的代码，但在这个规模上，合作的需求更高，代码的复用利益更大，跨职能势在必行。
这里所说的跨职能，不是代码级别的，而是在业务接口问题上，大致有以下几种情况。
一是经常有一些接口类功能，说不上来该谁做，这时候项目经理（就是10～20人的头）要协调其中一方完成，并为这方争取更多的资源（工期和人数）。
这里多少要建立团队可以提请要人的机制，而且项目经理能临时分配人员，比如把小李交给老王那组工作一段时间之类的。在139团队里边这个相对好办一些，如果是1个人管理12个人，就很难办。
3. 组织方案
3.1 进度-质量目标的合并（研发的部门经理可推行）
也就是无论是否还有开发-测试的分割，必须把进度绩效和质量绩效统一管理。 一个项目延期了，测试也有责任；一个项目质量差，开发也有责任。结果大致会变成：
-测试团队与开发团队融合
一般是测试团队分解到开发组，从事自动化测试的执行工作。 多数自动化脚本开发团队可以编写，但是多半要配置一些脚本、写一些测试用例什么的，由测试人员执行。 这种模式下，对测试团队的人数要求很少。
-测试团队与需求团队融合
质量工作彻底交给开发团队负责，测试团队只负责业务级别的验收测试（还负责早期的需求理解和机遇需求的测试用例编写）。 开发团队分化出一些人负责执行测试，这些人的数量一样要求很少；开发团队同时对进度和质量负责。 这两种方法都不容易做到，而且还有无穷无尽的问题，但告诉大家一个方法来解决：那就是每当自己心里想问：“可是，怎么……呢？”，自己要先想三个答案，然后再问；有时候会发现不用问了，答案已经被自己说出来了。
3.2 市场/销售/产品/研发的跨职能（总经理/副总经理可以推行）
简单说就是市场/销售/产品团队，要为研发的成本负责（比如销售要先扣除研发成本，再谈提成）；而研发要为销售/市场负责（比如如果销售额上升，研发团队也有一个提成）。
- 关键成效
敏捷团队相比传统团队的优点有哪些？
更紧密的沟通和配合促使了跨职能团队能够更有效的达成目标。较高交付的速度是敏捷团队最显著的优点之一。敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外，较短的迭代周期使团队成员能迅速进入协作状态。
- 参考文章：
- 1. 1-3-9团队构建
- 2. L型代码结构
- 3. 传统团队如何转变为敏捷团队
职场加油站
- 想更深入学习高效敏捷技巧，体系化降低产品创新风险，为你推荐《组建高效敏捷团队 》课程。
2 thoughts on “入门指南 | 传统团队如何转变为敏捷团队？”
这篇文章提供了很好的团队转变思路，应该多多借鉴。
小规模的跨职能团队能够更好地协作，确实是一种有效的解决方案。
[…] 在企业的团队中，有两种错误的认知很常见。营销团队常常认为，广告触达用户后，我们的任务就完成了。而对于产品团队而言，用户能正常使用产品，我们的目标就达成了。但事实上，用户与产品或品牌建立关联是一个连贯的过程，不应该被孤立成不同的节点。 […]
[…] 在企业的团队中，有两种错误的认知很常见。营销团队常常认为，广告触达用户后，我们的任务就完成了。而对于产品团队而言，用户能正常使用产品，我们的目标就达成了。但事实上，用户与产品或品牌建立关联是一个连贯的过程，不应该被孤立成不同的节点。 […]