小团队和大团队

  • 本站文章除注明转载外,均为本站原创或者翻译。
  • 本站文章欢迎各种形式的转载,但请18岁以上的转载者注明文章出处,尊重我的劳动,也尊重你的智商;
  • 本站部分原创和翻译文章提供markdown格式源码,欢迎使用文章源码进行转载;
  • 本博客采用 WPCMD 维护;
  • 本文标题:小团队和大团队
  • 本文链接:http://zengrong.net/post/2595.htm

干活靠喊

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

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

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

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

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

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

小团队和大团队

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

  small-and-big-team (2.3 KiB, 112 hits)
小团队和大团队 dot 源文件

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

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

随便举几个例子吧。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

(全文完)