轻松玩转项目,听网易导师谈——Team Split

2 评论 2831 浏览 4 收藏 10 分钟

团队规模的增长,带来的不仅仅是工作产出的增加, 还带来各种各样的成本的增加,效率反而大不如前了。所以拆分团队,就成了团队转型其中的很重要的一部分。

随着业务的不断发展,团队也在不断的发展。特别是在互联网公司,团队增长的速度比母鸡下蛋的速度还快,原本一个十来人的团队很可能在短短半年到一年的时间里,裂变成上百人甚至上千人的团队。团队规模的增长,带来的不仅仅是工作产出的增加, 还带来各种各样的成本的增加,效率反而大不如前了。

管理者往往纳闷, 原本同样的一项工作,小团队很快就执行完成了,而现在团队大了怎么就迟迟执行不下去了呢?

于是,团队的拆分就成了团队转型其中很重要的一部分。

在观察了众多的组织转型、案例之后,再加上我的一些实践,其实我心中的疑虑越来越多,在拆分的道路上也充满了荆棘,这荆棘还真的不仅仅在于高层对组织结构转型的支持,更多的还是在于组织转型和拆分,真的有效吗?

以下就是困扰了我许久的问题和对这些问题的一些理解。

一、团队大了是不是真的就要拆?

团队大了往往带来的是效率的下降,我个人认为改进效率的首选方法还是从管理方法本身上先进行改进,不断挖掘团队的潜力和合作效率。团队的拆分是需要从业务或产品的源头开始拆分的,假如过早的拆分、或者生硬的拆分都会导致效率不升反降。

所以判断是不是要拆,我觉得不是看是不是团队大了,而是得思考一下:

  1. 目前的效率满足业务了吗?
  2. 是否在原本的基础上还有改进的空间?
  3. 拆分之后是否真的会提高效率?

二、团队应该按照什么维度来拆?

主流的意见都是以业务的角度去拆分团队,我个人觉得这个意见是没有错的,但我们却也无法忽略其他职能团队组件团队的存在。

如果团队大了, 那就不会是一个单一的简单组织形式, 必定是复杂的系统组成,而不同类型的团队组织形式也是为了解决不同层面上的问题。没有职能团队,那么谁来关注不同职能的人员的个人成长?没有组件团队,谁来解决系统的通用性问题?

所以,在大团队下,不能脱离现实状况来考虑团队拆分,也不能脱离环境变化的因素而一成不变。这三种类型的团队,应该是融合的,不断转换的。

三、怎么“拆”团队?

与其说是“拆”,不如说是“演变”。上文说到,团队的组织形式有三类,业务、组件和职能。它们各有优劣,只不过在不同的环境和时间段,团队有着不同的重点和目标,这就需要这三类组织形式不断的变化与之相匹配,使之达到平衡高效的状态。

另一方面,还可以减少组织结构的调整对于整个团队的利益冲击所导致的巨大阻力,增加团队领导对于团队组织结构调整的信心和决心。往往我们可以适时适度对目标进行调整倾斜,组织起相对松散的虚拟团队,慢慢增加目标的比重,使得虚拟团队越来越起到重要作用,并让凝聚力增强。

然后达到一定程度的时候,领导只需要决定是否给出名正言顺的明确组织结构而已,那时候的调整已经变的非常自然。

但也要注意,另一个层面的组织结构就会被削弱,但我们并不能完全摒弃它,因为在大团队下一定会需要不同形式的组织形式存在起到一定的平衡作用。也许在哪一天,可能又会因为环境时间的变化,而“演变”回去,只因他需要重新达到一个高效的平衡状态。

四、如何治理拆分出来的团队?

团队一旦拆了, 可能团队会被拆分的越来越多,拆分并不是越细越好

我个人意见还是:首选并不是拆团队还是在改进管理,但因为业务需要不得不拆出来,那么拆分出来团队的治理就变的越来越重要了。

以下稍稍罗列一下我以为的一些需要注意的治理的点:

  1. 整体目标到各团队目标的拆分(不建议拆责任);
  2. 整体计划的制定;
  3. 整体信息的同步和风险监控;
  4. 整体资源的调度;
  5. 整体技术架构规范;
  6. 整体的工作方式和节奏;
  7. 整体的培训;
  8. 整体的文化建设。

这些整体性的管理规范的确立,能够降低和减少更多团队拆分的影响和成本,能够用比较短的时间融入整体大团队,极大的减少团队拆分而带来的副作用。

五、如何衡量团队“拆”分之后的效果?

这点还真的问倒我了,我真的不能定下一系列的标准,或者数据指标,来很明确的告诉我们“拆”完之后的效果是好还是不好。但“拆”分团队,跟其他管理手段一样,都是为了解决某个或者某些问题,而且还是一个相对成本较高的管理手段

所以上文也多次提到,如果有其他的成本较低的管理手段,请不要把“拆”分作为首选。

如果真的需要使用“拆”分团队,我们就必须仔细思考和分析,是否能解决这个问题?采用“拆”分团队的方法解决这个问题所带来的副作用我们是否能够承受?

最后,真要评判“拆”分之后的效果如何,我只能说,我们需要看看想要解决的问题是否一定程度上解决了?加上产生的副作用后整体的效率是否仍旧得到了一定程度上的提升?

当然,“拆”分之前,我们思考分析的再多也无法完全避免随之而来的风险,无法完全预估到所产生的效果是好是坏。所以,我更推荐的方法是通过逐步细小的“演变”来“拆”分团队,这样能够有效的控制风险,弱化“拆”分的成本。

我们在组织转型和拆分团队的过程当中经常遇到困境,究其原因,我猜想往往是因为对于团队这个复杂系统还是想的过于简单了。复杂系统的形成是有其内部的运转体系和力量形成的,有时候并不完全取决于领导单方面的意愿,或者说并不适合采用破坏性的力量去打破重组,这样的方式太过于具有破坏性, 这本身就违背领导和团队的意愿。

复杂系统就是因为有各种形式的平衡所形成的,也并不能使用一种或者简单的方式来组织和定义团队。团队的任何一种改变,必定会有有益的一面, 也会有副作用的一面,组织转型并不像乐高玩具可以随意组装,他只是从一种平衡走向另一种平衡,但是对外表现却会不一样。

以上都只是就本人而言对于拆分团队和组织转型的经验和理解,希望对有同样困扰的人有所帮助,同样也希望管理者在进行拆分和转型的时候,慎重思考小心实践,我相信团队一定会起到很多积极的变化。

 

作者:钟欣,网易杭研项目管理部资深项目经理,CSM、CSD、CSPO、PMP,曾任职于博克软件和印孚瑟斯,是国内早期敏捷的实践者,并深谙传统软件开发的理论和实践。在构建敏捷团队和敏捷转型等领域积累了不少实践经验。自2014年加入网易以来,一直担任云计算的整体的项目管理工作,帮助云计算这样的百人以上团队成功完成了产品化转型,并起到了显著的效果。

本文由 @网易杭研项目管理(微信公众号:NetEasePM) 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 文章很棒,尤其是整体的规范的确定和隐形组织向明确组织转换

    来自北京 回复