干活靠喊

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

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

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

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

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

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

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

小团队和大团队

该图采用 graphviz 绘制,可下载源码:

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

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

随便举几个例子吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

(全文完)

留言

2016-11-08
次访问