毁掉你们团队的2种“先天残疾”
随着产品的更新迭代，团队也由一个小团队成长壮大起来，管理的复杂度也随之增加。
这个时候，产品经理/项目经理通常会考虑划分特性团队，以保持小团队的管理效率。
从我看到的划分方法里，通常情况下大家做到了的是:
1. 划分之后，有了几个按照特性命名的团队；
2. 每个有名字的团队分配了一个特性负责人(FTO)。
单独看做到的这两点，是不是就可以认为划分好了呢？
不可以。除此以外，还要看以下几点注意事项是否都在划分的时候注意到了。
在说注意事项之前，我们先来看一下特性团队的定义:
长期的、具备交付价值所需的各种角色的、可以协同完成完整用户价值交付的团队。
再来说我看到的特性团队划分常见的几个误区:
误区一，团队人员不固定，不长期。通常，导致这种情况的划分都存在没有解耦的共享人力资源。
比如整个测试团队是几个团队之间共享，甚至整个开发团队是两个团队共享的。
根本原因：资源不足。
可能造成的影响：资源冲突，阻塞产品交付。
建议：
-
如果两个团队仍然在增补各自的开发/测试人员，建议逐渐将共享的资源分配到两个团队当中，以实现解耦。
-
如果短时间内不会增补充分的开发/测试人员，特别是整个开发团队被共享的情况，建议将划分开的两个团队合并，合并后的产品团队统一排需求优先级。
-
如果存在少部分稀少资源（比如专家资源）共享的情况，第一，需要预先制定共享资源的使用规则， 第二，需要注意关注共享资源的阻塞风险，一旦出现要及时进行仲裁和处理。
误区二，设置过多的公共资源团队，比如“设计资源池”，“测试资源池”。
导致上面这种划分的原因来自一种直觉：如果一个团队同时为N个团队工作，这个团队的生产力立即就乘以N了。
当把这种直觉写出来的时候，能很明显地看出来这其中的谬误。
真相是：一个团队，如果同时为N个团队工作，这个团队的生产力仍然和他们为一个团队工作相同，甚至减少（因为增加了任务切换导致的浪费）。
可能造成的影响：资源冲突，阻塞产品交付。
建议：
-
可以接受存在一些公共的资源团队，以保证产品一致性和建设可以共享的软件研发基础设施。
-
在以上的情况下，划分建议向特性团队倾斜（而非向用于公共资源的组件团队倾斜）。也就是，分配更多的人力资源到特性团队。
-
决定是否设置公共资源团队/划分倾斜度的时候，需要考虑该公共资源团队的排期对软件研发过程的影响程度。
影响程度越小，越可以向公共资源团队倾斜。比如，软件工程专家团队，用来在各个特性团队遇到问题的时候提供支持，又比如，运维团队，给各个特性团队提供几乎无差别的标准运维服务。
误区三，划分的特性团队个数越多，单位时间内整个项目的产能（交付的软件规模）就越大。
导致上面这种划分的原因来自一种直觉：一个团队被划分为N个团队，（同样的）这一群人的生产力就立即乘以N了。
很明显的，这个直觉不对。
划分特性团队固然可以通过提升团队专注程度，降低管理复杂度来提升效率，但是这个效率提升是有限的，因为受到资源有限的约束。
在同样的人力资源规模的情况下，划分特性团队对整体效率提升有帮助，但同时可能会降低单位时间里单个特性交付的软件规模。
原因很简单：划分后的单个团队人变少了，生产管道变窄了。
建议：
如果希望能通过划分N个团队达到生产力乘以N的效果，就要增加人力资源，让每个特性团队具备和原来的团队相当的规模。
总结一下：
特性团队是长期的、具备交付价值所需的各种角色的、可以协同完成完整用户价值交付的团队。
划分特性团队需要考虑团队解耦、未解耦资源的资源冲突风险，和整体人力资源约束。
欢迎你在下面留言，说说你是怎么划分团队的？你的建议是什么？
END
精选文章
京东末位淘汰：为什么末位淘汰不适合用在软件研发团队（附特朗普亲身示范正确做法）
“轻松做软件”是IT人的效率公众号，不加班必备
科学工作，少走弯路，快来关注吧！
