4.1.3 团队之大

在上一章的“项目”里，我们谈到做事需要流程、文档、规则，其实这些最终都是靠人。接下来，将按照一个团队从几个人逐渐变成一家公司的过程，来说说“团队之大”。

从几个人到一家公司

做产品的团队是如何从个人进化成一家公司的？这中间的各种职责为什么要切分？各种职位又为什么会出现？

第一阶段：类比大家在学校的经历：

最开始，一个人的时候，所有事情都由自己一个人搞定，这时候可以认为自己是这个产品的产品经理、程序员、测试等任何人，甚至自己就是整个公司。

后来，大家要分组完成任务，通常会分为“技术”和“非技术”类，强一点人都去做技术，简单地说等价于编程，而啥也不会的人就做非技术，类似于写文档。这里的文档人员就是将来公司里的策划、PD、运营等，但区别在于，多数公司里这类人员很强，很重要。这个差别的原因是因为学校里的作业，大多数是已经明确要做什么，而且不会有真正的用户，所以只要有技术强人实现就可以拿到高分了，所以策划的工作就变成了附属。事实上，决定做什么其实更重要，这不能不说是我们所经历的学校教育的一个遗憾。

再往后，就又产生了更多细分的职责。我们会发现“自己编程，自己测试”很难发现问题，于是把测试的事情独立出来，很多时候是随意地交给一些不懂技术的人去做。而原先的非技术概念也开始扩充，出现了专门做需求的人，他们会处理很多“对外”业务，即与客户相关的事情。而产品经理的概念，似乎除了编码的工作，都有可能去做……

第二阶段：就是相当成熟的公司了，可以分为商业、产品、技术、支撑四大块，几十人，甚至几百人的公司也不外乎如此。

公司大了，人多了，新的难题出现了，那就是——如何设计各种职位，让各种人（职员）与各种事（职责）互相匹配。大致思路如下：做任何产品，或者说公司需要做各种各样的事情，由于事情越来越多，而分工可以使效率提高，所以我们把要做的事情分解成了各种职责，比如开发、测试，再细一点，比如功能测试、性能测试——这是相对容易分析的。然后，老板去找拥有相应能力的人组建团队，于是，由各种各样的人，即职员组成了团队，每个人都有特定的能力，比如有的人喜欢钻研技术，有的人喜欢和人打交道。所以只要职员的能力都可以和要做的事匹配就OK，到现在为止，“职位”的概念还没有必要出现。

第三阶段：公司大了，要做的事情越来越多，分工越来越细，于是很自然地出现了很多人做同一件事的情况，比如有50个“Java工程师”。“偶尔为之的事情只需要可行解，经常做的事情要追求最优解”，所以，我们不能每次都特意去找某个人，成本太高。于是，公司必须找出事与人之间的匹配关系，在“职责”与“职员”两者之间，出现了“职位”的概念，这就能让HR批量地找到合适的人。职位的出现，降低了用人单位与求职者两边的沟通成本，一个词“交互设计师”、“运营专员”，就能传递很多信息。

其实，职位并不关键，在想明白做一个产品要完成哪些事情，做这些事需要拥有哪些能力的人，团队处于什么阶段之后，应该设置哪几种职位的答案自然就出来了。所谓最优团队，每个个案都不一样。互联网与软件公司要做的事情都是类似的，但是每种职位具体做什么在各家公司有所不同，这并不用在意，只要每件事情都有人做就可以了。

接口人存在的价值

公司大了，必然会出现各部门分工做不同的事情，但是，有些事情总是分不清楚，总是需要多个部门之间来配合。比如产品上线以后，PD都会遇到日常的Bug处理、工单处理这类事，常见的故事是这样的：我们开始很有激情，给客服的同学培训完产品以后，许下诺言：“以后用户那边，有什么搞不定的问题都转给我好了，把我手机给用户都可以……”。这时候PD也的确急切地想通过一切途径了解用户对产品的反馈。前几天还不错，每天都有客服转过来的几个问题，有时候也会把用户的联系方法要过来，直接和用户交流，收获不小。渐渐地，随着产品的用户越来越多，问题也越来越多了，我们感到忙不过来，更头疼的是发现很多问题是类似的，占据了日常工作的大部分时间，让人烦躁不堪。有一天，我们终于受不了了，跟老板说，我要变成客服的客服了……老板说，很简单啊，让客服部门确定一个接口人吧。

于是就出现了接口人，他做了我们做的大部分工作，他不存在“变成客服”的抱怨，他本来就是客服的同学。之后，接口人给我们的问题才是真正的疑难杂症，才是真正体现我们价值的问题。不管是客服还是其他部门，接口人一般会让相关部门中比较资深的同学来担任，他起到了问题过滤的作用，可以解决大部分一般同学搞不定的问题，并对相似问题进行合并。

其次，接口人还有个好处，就是缓解“办事要靠脸熟”的问题，一般让沟通能力比较强、已经和公司里多数人很熟的人来做接口人，事先明确了他们的职责，通过他们来连接多个部门的陌生人，可以减少部门合作时，陌生人之间的沟通成本。当然，最好能在公司里培养起“对事不对人”的文化，那会使得沟通成本大大降低。

矩阵型组织

任何一个超过几十人的团队，就必然脱离“一个班长带几个兵”局面，产生自己的组织结构，常见的有职能型组织、项目型组织和矩阵型组织。组织结构是对项目、产品等的支撑，组织结构的设计也可以看作一种很高级的产品设计。

职能型组织：是把相同职责的人划分在一个部门里，有利于同类资源共享，互相学习提高，但公司的目标在分解到各部门之后，很容易不一致，而且每个部门唯一的客户就是“上面”，都只对“上面”负责，导致没有人对真正的客户负责。这种形式比较适合大规模运作型的公司或部门，适合计划经济，比如大多数工厂的车间，人真的可以当作可替换的“资源”的情况。

项目型组织：是把各种职责的人组成一个个的项目组或产品线，团队目标一致，有利于快速推进项目，但是会资源浪费。项目组发展下去就是事业部，甚至分公司。说明一下，从组织结构的角度讲，项目型组织的头是项目经理或产品经理（为了方便起见，这一段下面单说产品经理），和职能型组织的头——部门经理相对应。

矩阵型组织：是上述两种组织结构的融合，就是横向是产品线、业务线，为了对客户负责；纵向是资源线、行政线，为了资源共享。如果说职能型组织比较适合防守型的业务，项目型组织适合进攻型业务，那么矩阵型组织就是全攻全守。但它也有很明显的问题：对员工来说，一面是部门经理，另一面是产品经理，这样的“双头领导”总是很让人头疼，那么这两种职位可以通过兼任来解决矛盾么？

答案是否定的。产品经理主要管事，有成就感，像“猎人”，类比到军事上，就是对打仗负责，需要有攻城拔寨的能力；部门经理主要管人，有权力，像“农民”，对练兵负责，贡献技术与人，有防守与后勤的感觉。那么，部门经理如兼任产品经理，就会用权力来寻求成就感，或者在产品KPI的重压之下，放弃农民的责任去做猎人，造成行为的短视，主动或被动地忽视团队能力的提升。这是人性的弱点，无法避免，目标不同导致手段不同。在矩阵型组织下，部门经理和产品经理就应该各司其职，至于“双头领导”的协调，应该由用人的产品经理提供建议，养人的部门经理决定对员工的考核，同时培养每个人对事负责的态度。