产品团队之矩阵式组织结构

什么是矩阵式组织结构的产品团队

一般来说，一个产品的运行是多个业务模块配合的结果，很多时候要开展一个项目，多个业务之间都需要配合互动。（假设一个业务模块称为一个topic）拿我们熟悉的o2o业务来说，一般都会包括面向用户的部分、面向商户的部分、平台部分、用户中心/商户中心等应用部分。相应的,就一定会存在一个多人配合的产品团队。

以下图是一个矩阵式模型。

纵向是以业务区分的职级结构，横向则是以项目区分的临时组合。

当一个项目展开的时候，需要去协调各个topic的人力来配合展开。于是，也就出现了一个临时的，横跨多个topic的小组了。

这种组织结构的好处与坏处

坏处：对每个pm的综合素质要求更高，工作量更大。
当你决定要做一件事情的时候，你需要考虑这个事情要用到哪个topic的资源，以及你如何说服他们来配合你。这要求pm要熟悉全部的业务，同时有很好的沟通、协调能力和人格魅力。

好处：

  以上的坏处其实就是最大的好处：能更加锻炼产品经理的能力。

一个pm对单一模块的熟练程度，只决定了你最基础的能力，而对其他模块的熟悉，以及把这些模块链接起来的对整个业务的熟悉才是核心能力。另外一个看不见的更重要的能力是，你沟通和协调资源的能力。

     利于轮岗

         试想一下，你在纵向上非常了解自己的topic业务，比如用户端APP；你在横向上了解其他topic的业务，比如订单分发策略。于是，一部分pm开始找到自己真正喜欢的topic，他会选择轮岗，这种轮岗因为之前有了解的基础，不至于出现不适应。

总结

        纵向了解自己，锻炼自身的专业能力，横向扩展沟通、协调能力，会对整个pm后续的发展空间非常之有效。
对于产品经理的能力模型来说，应该是一个T字型的结构，纵向的是专业能力提升，横向是沟通协调能力。矩阵式的产品团队组织结构，正好是适应这个T字型的能力模型的。同时，这个结构具有较强的适应性，尤其是拥抱变化的时代。

权责的划分

      作为矩阵的2个边，一边是自己职责所在的topic，一边是配合其他topic的项目。

      做好自己topic里的事情，是最基本的要求；

     谁发起的项目，谁负责，谁就要去协调资源，如果别的topic不配合你，导致项目完成的不好，你自己要承担绝大部分责任，其他topic的人承担小部分的责任。

    注：这个理论的来源点在于，协调、沟通能力，是pm的核心能力之一，如果你做不到产品内部的组织与协调，你必然也做不好跟研发及运营资源的协调了。

为什么要有矩阵式组织结构

考虑到专业性
     产品团队会按照不同的业务模块安排专门的人员进行负责。假设每个业务模块称为一个topic ，比如用户端APP、商户端APP、分发/派单策略、系统后台策略、用户中心、商户中心等等。

考虑到组织结构扁平化
      产品人员的层级要尽量的少。一个产品团队的结构一般来说3层相对合适。
      pm leader（产品总监）对整个产品负责；
      topic leader（高级产品经理）对具体的业务细分负责；
      pm（中、初级产品经理）对业务细分的业务模块负责。

考虑到提高资源利用率，降低人员配置成本
     一个产品的运行是多个模块配合的结果，很多时候要开展一个项目，多个业务之间都需要配合互动。
     这个时候，一般的组织会出现一个叫做项目经理的角色，负责协调资源，制定进度表等。
     当你的组织人足够多的时候，这样当然是最好的。不过，本着把每个人的能力都压榨干净的思路，在没有项目经理的时候，可以采用矩阵式的组织结构来保证项目的进度。