毁掉你们团队的2种“先天残疾”

引导5.png


随着产品的更新迭代,团队也由一个小团队成长壮大起来,管理的复杂度也随之增加。

 

这个时候,产品经理/项目经理通常会考虑划分特性团队,以保持小团队的管理效率。

 

从我看到的划分方法里,通常情况下大家做到了的是:

1. 划分之后,有了几个按照特性命名的团队;

2. 每个有名字的团队分配了一个特性负责人(FTO)。

 

单独看做到的这两点,是不是就可以认为划分好了呢?

 

不可以。除此以外,还要看以下几点注意事项是否都在划分的时候注意到了。

 

在说注意事项之前,我们先来看一下特性团队的定义:

 

长期的、具备交付价值所需的各种角色的、可以协同完成完整用户价值交付的团队。

 

再来说我看到的特性团队划分常见的几个误区:

 

误区一,团队人员不固定,不长期。通常,导致这种情况的划分都存在没有解耦的共享人力资源。

 

 

比如整个测试团队是几个团队之间共享,甚至整个开发团队是两个团队共享的。

    

根本原因:资源不足。

 

可能造成的影响:资源冲突,阻塞产品交付。

 

建议:

  • 如果两个团队仍然在增补各自的开发/测试人员,建议逐渐将共享的资源分配到两个团队当中,以实现解耦。

  • 如果短时间内不会增补充分的开发/测试人员,特别是整个开发团队被共享的情况,建议将划分开的两个团队合并,合并后的产品团队统一排需求优先级。

  • 如果存在少部分稀少资源(比如专家资源)共享的情况,第一,需要预先制定共享资源的使用规则, 第二,需要注意关注共享资源的阻塞风险,一旦出现要及时进行仲裁和处理。

 

误区二,设置过多的公共资源团队,比如“设计资源池”,“测试资源池”。

 

 

导致上面这种划分的原因来自一种直觉:如果一个团队同时为N个团队工作,这个团队的生产力立即就乘以N了。

 

当把这种直觉写出来的时候,能很明显地看出来这其中的谬误。

 

真相是:一个团队,如果同时为N个团队工作,这个团队的生产力仍然和他们为一个团队工作相同,甚至减少(因为增加了任务切换导致的浪费)。

 

可能造成的影响:资源冲突,阻塞产品交付。

 

建议:

  1. 可以接受存在一些公共的资源团队,以保证产品一致性和建设可以共享的软件研发基础设施。

     

  2. 在以上的情况下,划分建议向特性团队倾斜(而非向用于公共资源的组件团队倾斜)。也就是,分配更多的人力资源到特性团队。

     

  3. 决定是否设置公共资源团队/划分倾斜度的时候,需要考虑该公共资源团队的排期对软件研发过程的影响程度。

     

    影响程度越小,越可以向公共资源团队倾斜。比如,软件工程专家团队,用来在各个特性团队遇到问题的时候提供支持,又比如,运维团队,给各个特性团队提供几乎无差别的标准运维服务。

 

误区三,划分的特性团队个数越多,单位时间内整个项目的产能(交付的软件规模)就越大。

 

 

导致上面这种划分的原因来自一种直觉:一个团队被划分为N个团队,(同样的)这一群人的生产力就立即乘以N了。

 

很明显的,这个直觉不对。

 

划分特性团队固然可以通过提升团队专注程度,降低管理复杂度来提升效率,但是这个效率提升是有限的,因为受到资源有限的约束。

 

在同样的人力资源规模的情况下,划分特性团队对整体效率提升有帮助,但同时可能会降低单位时间里单个特性交付的软件规模。

 

原因很简单:划分后的单个团队人变少了,生产管道变窄了。

 

建议:

如果希望能通过划分N个团队达到生产力乘以N的效果,就要增加人力资源,让每个特性团队具备和原来的团队相当的规模。

 

总结一下:

特性团队是长期的、具备交付价值所需的各种角色的、可以协同完成完整用户价值交付的团队。

 

划分特性团队需要考虑团队解耦、未解耦资源的资源冲突风险,和整体人力资源约束。

 

欢迎你在下面留言,说说你是怎么划分团队的?你的建议是什么?

                 

END


精选文章

年会宣布996后,那些保持沉默的人

京东末位淘汰:为什么末位淘汰不适合用在软件研发团队(附特朗普亲身示范正确做法)

关于罗振宇:为什么我们买了很多课程,却依然过不好这一生?


“轻松做软件”是IT人的效率公众号,不加班必备

科学工作,少走弯路,快来关注吧!

image.png

 

没有更多推荐了,返回首页