小团队和大团队

一个同事聊天时问我，别的公司的技术说 1 天能接 1 个 SDK，我们为啥接那么慢？

有个项目负责人找到我说：外面有个团队手上有个项目，是他们 1 个月开发出来的。据说效果还不错。我们现在开发这么慢，要不把他们的项目引进来？我说：你要是真想他们进来后还那么快，就必须保持团队完全独立，不要和公司的开发流程有联系。这个团队人员的考核和成长都要单独处理。

上面的两位同事提出的问题，都和团队规模有关系。身处大团队，但眼睛盯着小团队，很容易产生这种能力不对称的感觉。

普通员工无法理解也没关系，就像传说 1 天能接 1 个 SDK 的那位（想大叔我当年……），若有必要就解释一下技术细节，若无必要就呵呵一下呗。但如果 Manager 也这么想就有关系了。Manager 的这种想法，会影响其决策和一线技术人员的工作进度。

我来试着解释一下这件事。

无论小团队还是大团队，在工作中总会碰到这些方面的问题： 沟通方式、过程流转、绩效管理、员工成长、产品研发。下面这张图展示了小团队和大团队在这几个方面的区别。

 1digraph team {
 2    graph[fontsize=30;rankdir="TB",label="小团队和大团队"]
 3    //ranksep=.75; 
 4    node[shape=rect]
 5
 6
 7    subgraph cluster1 {
 8        label = "小团队"; fontsize = 20;
 9        style = "filled"; fillcolor=aliceblue;color=azure3;
10        node[shape=Mrecord,style="filled",fillcolor="white",color=azure3];
11        edge[arrowhead=none, color=transparent]
12
13        c1s1[label=" 喊 | 大声喊 "]
14        c1s2[label=" 继续喊 | 人肉 "]
15        c1s3[label=" 没有/口头 | 脑补 | 半年/一年 "]
16        c1s4[label=" 没有/项目内成长 | 个人影响 "]
17        c1s5[label=" 一人搞定 "]
18
19        c1s1 -> c1s2 -> c1s3 -> c1s4 -> c1s5
20    }
21    subgraph cluster2 {
22        style = "invis";
23        node[shape=none, fontsize=20];
24        edge[arrowhead=none];
25
26        c2s1[label="沟通方式"]
27        c2s2[label="过程流转"]
28        c2s3[label="绩效管理"]
29        c2s4[label="个人成长"]
30        c2s5[label="产品研发"]
31
32        c2s1 -> c2s2 -> c2s3 -> c2s4 -> c2s5
33    }
34
35    subgraph cluster3 {
36        label = "大团队"; fontsize = 20;
37        style = "filled"; fillcolor=aliceblue; color=azure3;
38        node[shape=Mrecord,style="filled",fillcolor="white",color=azure3];
39        edge[arrowhead=none, color=transparent]
40
41        c3s1[label=" 邮件 | 电话 "]
42        c3s2[label=" 邮件 | 会议 "]
43        c3s3[label=" 书面成体系 | 跨部门 | 每月/每季 "]
44        c3s4[label=" 阶梯/成体系 | 跨部门/跨业务 "]
45        c3s5[label=" 多人合作 "]
46
47        c3s1 -> c3s2 -> c3s3 -> c3s4 -> c3s5
48    }
49
50    subgraph cluster4 {
51        label = "成本"; fontsize = 20;
52        style = "filled, dashed"; fillcolor=gold1; color=goldenrod3;
53        node[shape=hexagon, style="filled, dashed", fillcolor=white,color=goldenrod3];
54        waiting[label="等待成本"];
55        talking[label="沟通成本"];
56    }
57
58    {
59        c3s1 -> talking;
60        c3s2 -> talking;
61        c3s5 -> talking;
62
63        c3s2 -> waiting;
64        c3s3 -> waiting;
65        c3s4 -> waiting;
66        c3s5 -> waiting;
67    }
68
69    {
70        edge[style=dashed]
71        c2s1 -> c1s1
72        c2s2 -> c1s2
73        c2s3 -> c1s3
74        c2s4 -> c1s4
75        c2s5 -> c1s5
76
77        c2s1 -> c3s1
78        c2s2 -> c3s2
79        c2s3 -> c3s3
80        c2s4 -> c3s4
81        c2s5 -> c3s5
82    }
83
84}

该图采用 graphviz 绘制，可下载源码：

• 沟通方式，小团队靠喊，大团队靠邮件；
• 过程流转，小团队靠喊，大团队靠邮件、会议；
• 绩效考核，小团队不需要，大团队要专人来管理，所有人都要参与；
• 个人成长，小团队可以不考虑，大团队则要考虑体系性和阶梯性；
• 产品研发，小团队可以一个人搞定全栈，大团队则需要多人配合。

从上面可以看出，大团队需要多做的事，都是吃力不讨好的事。这些事增加了等待成本、同步成本和沟通成本。如果没有处理好这些成本，就会造成整个团队工作效率的严重下降。

随便举几个例子吧。

在小团队里，由于一个人负责多个职能，碰到过程流转的时候，他只需要跳起来喊一嗓子，另一个人就能把活儿接过去。由于小团队专注于一个项目，随便的一嗓子互相都知道啥意思，接下来专心把活儿干好就行。

大团队就不行了。不同的职能由不同的人处理，碰到流转的时候，首先需要找到负责下一个流程的人，中间还极有可能会碰到需要某个流程外的人支持的情况。如果涉及的人多了，用邮件效率很低（因为要等其他人反馈），需要组织一个会议，会议的组织又会打断所有参会人的连续工作时间。一个流转，就降低了一批人的工作效率。

在小团队里，绩效考核是不需要的。半年或者一年后出结果的时候，每个人做了什么事，大家一清二楚（因为平时工作靠喊，开会都是全员）。大团队里，某个人的工作情况不可能让所有人知道，为了在年底给出一个所有人信服的评判标准，绩效考核就必须做。定期的绩效考核会消耗员工的工作时间。填写、审核、打分、谈话等等流程，至少需要消耗0.5个工作日。重要岗位的人员消耗的时间更多（例如主程需要为自己项目组的成员评分）。一个考核，就降低了所有人的工作效率。

产品研发上就更明显了。在小团队里，一个人就能完成整个产品的工作。例如我 花了 5 天时间就完成了一个内部工具开发 。产品设计、技术选型、美术、后端、前端都是我一个人完成，中间不需要等待，不需要流转，不需要沟通，效率高的惊人。如果把这个工具交给一个团队来做，就需要有需求调研、美术、前后端分工、测试等等一系列工作。等待成本和沟通成本又增加了多少呢？

这些成本，是大团队不得不考虑的。

张小龙在最近的一次演讲中谈到(via)：

我们的记忆里面只适合处理150人以内的人际关系，一旦超过150人的时候，它就变成一个社会化的组织。这个时候对个体来说是不太舒适的，已经超过了他的舒适区。

要让大团队做得比小团队更快更好，就是要让个体重新变得舒适起来。

高效的大团队有什么好处呢？

从腾讯回来的同事说，他们的游戏服务器受到攻击的时候，只需要通知公司的网络安全团队就行了。 只！需！要！通！知！就！行！了！

我们开发了一套服务型 手机游戏开发框架，已经在 3 个游戏上进行了接入。这套框架可以完成游戏帐号接入、聊天系统、充值系统、SDK 接入、防沉迷系统、配置管理系统等等一系列的工作。开发一款新的游戏，只需要接入该框架的客户端和服务器 SDK 既可以选择性地使用框架提供的功能。这就是大团队的优势。

在大团队中，每个人都能找到自己的位置。如果对当前的工作安排不满意，或者希望学习另一个岗位的技能技巧，完全可以内部调岗以得到更多的锻炼。如果员工愿意在某个岗位上持续研究，大团队也能提供足够的时间、资源和空间。这是一人一岗、快速出结果的小团队不可能提供的。

只有团队中的每个成员都熟悉大团队的沟通流程和方式，互相尊重，互相配合，才可能发挥出大团队的优势。这个熟悉的过程，就是从小团队到大团队的成长阵痛，这是一个成熟的团队必须经历的过程。

我在前几天的吐槽文：一只青蛙怎么收邮件？ 中提到了邮件培训。邮件的使用仅仅是大团队日常工作中的一个很小的细节，这样的细节在大团队的日常工作中还有许多。仅当这些细节为团队中每个成员都熟知的时候，整个团队的工作效率才可能得到质的飞跃。

这需要团队所有人一起努力，尤其是需要 Manager 的认同。

回到前面的例子，我们为什么不能 1 天接 1 个 SDK？我们当然能。小团队接完 1 个 SDK，直接就能上线，出了问题马上发新包。不会影响用户么？当然会影响！但没办法！因为只有1个人嘛！为什么快？因为只有1个人嘛！而我们要走测试流程，在SDK 这件事上起码涉及到3个岗位。每个岗位上的人马虎一点，整个流程就要报废了从头再来。

我们为什么不能 1 个月开发一个游戏？我们当然能。我自己就干过类似的事情。在没有 大团队成本 的前提下，1 个月开发完那个游戏是不难的。这样开发出来的游戏包括主要玩法，但游戏运营工具、激活、支付、分析工具、公告、客服系统等等都是不完备甚至是没有的。它当然也能上线，甚至可能挣钱。它当然也“看起来不错”，但想要把这个游戏运营起来，还是需要一个团队持续跟进，持续完善支持的。这些支持，不能因为刚开始看不到，就认为不存在啊！后续的工作是不可避免的成本，小团队和大团队都避免不了。

做产品，要专注在产品上，但不能只专注在产品上。要带好团队，产品和人同样重要。流程顺了，人的效率提高了，产品质量和开发速度就上来了。如果只把眼光放在面前的一小块儿上，和盲人摸象又有多大分别呢？

（全文完）