怎么做好互联网公司的技术负责人?

  • 本站文章除注明转载外,均为本站原创或者翻译。
  • 本站文章欢迎各种形式的转载,但请18岁以上的转载者注明文章出处,尊重我的劳动,也尊重你的智商;
  • 本站部分原创和翻译文章提供markdown格式源码,欢迎使用文章源码进行转载;
  • 本博客采用 WPCMD 维护;
  • 本文标题:怎么做好互联网公司的技术负责人?
  • 本文链接:http://zengrong.net/post/2433.htm

这篇文章是我在知乎上的一个回答。

问题:

如题,怎么做好互联网公司的技术团队负责人。互联网公司的技术团队负责人应该具备怎样的能力

回答原文:

https://www.zhihu.com/question/39421456/answer/81853837


利益相关:4年创业经验,目前带手机游戏前端团队。

1. 在创业公司,最重要的是人,其次才是团队

先就说说这个有负能量的事情。有多负能量?先看看这个: 游戏逻辑程序员的成长出路? – 曾嵘的回答

其实本节的标题可以进一步理解成:必须要有足够好的人,才能通过团队负责人的努力得到一个合格的团队。现在这个时代,不是一个人牛逼就能成事儿的。

当然,你可以自豪的说:以我的能力,一帮乌合之众( 《乌合之众》读书笔记 )也能被我带好了!这种豪言壮语我也说过(哦,是想过),而现在我只能呵呵一笑:兄弟, U NB,U UP!

看看上面那个负能量的例子,想一想:你干得了所有的活儿么?你有精力解决所有的BUG么?你有能力完成所有的流程么?你的工作是让团队干活,不是自己干活。

我们团队内部会议上,我问大家:一个程序员最重要的 feature 是什么?有兄弟说是 出活 。而我认为程序员不仅要能出活,还要高效地出活,出精致的活,不达目的誓不罢休地折腾自己,变着法儿把自己玩坏。

团队打造出来始终是要做事的,技术团队需要高效地完成业务部门需要的结果。高效的团队需要流畅的合作、清晰的流程、明确的目标、严谨的标准,而要准确无误地达到这些要求,就需要 足够好的人。

每个人在团队中都有自己的位置,如果碰到了比较弱的人,TA 就会成为团队合作中的那个短板。我丝毫不怀疑我能把 TA 带起来,但问题是 TA 在成长的同时,团队中的其他人也在进步,你需要在 TA 身上花多少精力才能保证 TA 的成长速度呢?弱的人总有弱的理由,强的人自有强的原因。还是把有限的精力,投入到能更快成长的团队成员身上吧!

所以,团队中最重要的问题,不是你有多牛逼,而是团队中的其他人有多牛逼。负责人需要解决的问题就是让这群牛逼的人在一起能更牛逼。避免弱的人进入团队的最重要的一关就是招聘。那我就来说说招聘。

2.1 不怕闷,就怕不骚

都说程序员很闷,所以才有上面 @财神 说的赚够了钱去嫁程序员的段子,毕竟话少钱多死的早的老公并不是到处都有。但优秀的程序员往往是闷骚的。当然,明骚的程序员也不是没有,只不过TA们容易把大部分精力都花在骚上,这也不好。

闷骚的特点在面试的时候就能看出来。一个优秀的闷骚,面对TA感兴趣的话题,根本不用我提醒就能滔滔不绝讲下去,那是拦也拦不住的,二面分分钟超过两小时,而且我都插不上话!我经常用这种方法在面试的时候偷懒,既能少回去开会,也能多了解这位同学的方方方面面。

前几天刚面了以为只闷不骚的同学,这位同学有一种逆天的技能,就是所有的句子都是短句,所有的回答都是封闭性回答,所有的谈话都不展开。即使是我的开放式问题,他也能转换成封闭式问题然后给一个短句答案。我举两个他回答的经典语录:

  • 问:你之前做页游的时候写了两年多AS3,对语言算是比较熟悉了。你最深的感受是什么?
  • 答:加班。
  • 我:……
  • 问:你为什么热爱程序员这个很有前途的职业?
  • 答:我能比较积极的完成工作,并能保证工作的质量,所以我热爱程序员工作。
  • 我:……
  • 问:AS3、C++和Go语言你都用过,对比一下它们的特点?
  • 答:主要是定义不同,Go语言的定义需要大写。它们的 API 不太一样,其他都差不多。
  • 我:……

当然,上面说的是一些极端情况,大部分程序员还是挺本分的,中规中矩,不温不火。作为技术团队的负责人,在招聘中需要睁大眼睛分辨这类大多数情况,保证不漏过一个可以培养的骚人,也不能招入一个没法培养的弱人。

在我看来,闷骚的程序员可能有下面几个特性:

  1. 自信
  2. 挑你的刺儿
  3. 有自己的想法
  4. 不愿和你妥协
  5. 知道如何拒绝

上面的特点可以说是极骚,下面的是普骚:

  1. 干活快
  2. 喜欢啥都接着
  3. 有记录,有安排
  4. 学习快

2.2 面试的两级

要筛选出足够好的人,面试一定要慎重。我曾经就因为太想找到“能干活的人”而吃了许多苦头。我碰到过干了一个月从不加班等到发薪水那天晚上加班到21点薪水到账就马上删除代码来要挟我们的;也碰到过受不了一点批评摔门而去的;还碰到过使用物理技能攻击公司 boss 然后威胁 format d: /P 的……一些事情到现在想起来还会呼吸急促,大脑缺氧。

上面这些人中,有从360公司回来的北漂,有十几年的程序员,甚至有公司的创始员工……

所以,在面试层面多花点功夫是值得的。面试至少要有两面。下面是我的老大给的关于面试的要求:

一面:

着重考察技术能力,不必涉及文化、性格、价值观和软技巧。但一面面试官可反馈这方面对候选人的主观印象。

二面:

  1. 事业心。是否积极主动追求事业(技术)上的成功,有什么样的事例(或者成绩)可以证明?是否有家庭、情感方面的困扰阻碍候选人全身心地投入工作?能否接受合理的超时间工作和学习(无论是在公司,或者在家利用业余时间学习或者工作)?
  2. 与人沟通交流和合作情况。可以问问他如何评价前领导、同事,有什么业余爱好,参加什么集体活动,在集体活动中做什么。
  3. 职业生涯规划。对Junior员工可以接受他没有清晰的规划。考察他留在武汉的意愿,从事游戏行业的意愿,工作稳定性。
  4. 住址。除特别优秀外,不建议招上下班太远的人。

我们招的人,一定要有优秀、过人之处,有较强的学习能力并能在我们的环境下持续成长,而不仅仅是能应付眼前的工作。有三年工作经历的人,就一定要有三年或者三年以上的工作经验和能力。请大家谨记。在面试时,一定要带着这个问题:这个候选人如何融入到我们现有的环境,如何成长,如何适应未来的变化?

其实就算是严格执行上面的建议,也很难杜绝所有的问题。曾经有一个十年经验的程序员,经过了两轮面试,表现都很好。但工作起来和面试感受完全不同。没过多久他主动提出了离职,给出的原因让人匪夷所思,就是觉得工作上很 “别扭” 。HR 无法接受这样的离职原因,我们也尝试了各种方式努力挽留(包括解决他目前的工作问题,承诺即将到来的适合他的工作任务等等),依然无法得知他离职的真正原因。不过,上了二十年小学的柯南同学说过,如果排除所有不可能的情况,那么无论如何不可相信,真相就是真相。

十年的工作经验,不一定就是真是十年。 有些人是做了十年不一样的事,有些人则只是把第一年的事情做了十年。 对于上面的这个情况,我觉得在我当时的能力下无可避免,可亡羊补牢,犹未晚矣。现在我至少找到了两个解决办法:

1. 充分求证

对简历进行充分求证。了解每个项目的始终,并通过其能提供的原同事信息进行求证。 《注意!有人在盯着你》 一书中提到了一些关于背景调查的问题,也可以问一下。多花点时间总比最后承担后果要好很多。

2. 相信直觉

比较糟糕的员工,在我第一次和他们见面的时候,我的直觉总会告诉我哪里有些不对。但之后,我的理智又告诉我现在是急需用人的时刻,这人经验丰富,能把项目向前快速带动……此时直觉就被理智给压制了。最后出事的时候,往往发现给项目带来的影响比之前还要大许多。

人的直觉往往非常准,但也经常被理智所否定。大脑总会认为理智比较靠谱而直觉比较玄乎,而事实似乎正好相反。直觉是在你的感官观察到这个人的第一印象的时候做出的,其实在用大脑思考这个人的时候,你的感官已经对这个人的一些细节做出评价了,一旦有不符合常理的地方,你的直觉就会报警,而此时你的大脑还没有开始视觉分析呢!

下一次碰到不知道该不该录用一个人的时候,尝试一下相信自己的直觉吧!当然是在充分求证之后!

3. 兴趣分类

除非是超人或者有别的重要目的,否则大多数人都只愿意做自己感兴趣的事。程序员则更是如此。因为闷骚的特性,TA们的兴趣点大多比较集中,或者说在一段时间内比较集中。这样,要TA们能高效的出活,就要找对路子。这个路子就是抓住TA们的兴趣点。

我会保持每季度都能和团队所有成员一对一沟通一次。平时大家的能力,特点都已经在日常工作中了解得八九不离十,但内心的想法大家并不会全告诉你。而且一对一沟通中,我可以全面了解团队成员内心中的想法,一些平时忽略掉的细节也会在这种沟通中被放大,同时一些平时工作中不方便说的事情,也可以在这次沟通中进行全面交流。

这种沟通是非常重要的。我在沟通中了解到了大量平时无法观察到的问题,甚至是可能得到对一个人完全相反的印象。我更愿意把自己的职责归结为如何帮助团队成员成长,所以在沟通中我说的最多的就是:“我能帮助你做什么?”

下面这次沟通汇总是我担任 Leader 之后三个月不到时进行的。这次谈话过程中,我制定了一些特定的技能点问题,谈话结束后,再整理大家的回答,对每个技能点进行打分。下面是这次沟通的结果:

统计分析

根据这个结果做出下面三张图表:

兴趣点分布

这个图表代表了每个人关注的兴趣点,数量越多则代表这个人越有发展的可能。需要注意的是“无趣”和“Lua”这两个点。

“无趣”代表其认为目前的工作无法给其带来快感。这种感觉比较普遍,集中在3年以上工作年限,以及对技术有理解和追求的程序员身上。

“Lua”则代表多数人愿意往 Lua 脚本化方面转换。这也符合目前 C++ 为主的技术特点。

兴趣点分布

重点指示

大部分的人的主动性是不错的,少部分人有很强的自我推动力。C++底层是老本行自然分数高,Lua 也在情理之中。但有趣的是服务器技术和 3D 技术的关注度。另外少数人有难得的产品思维和管理思维,值得培养。

重点指示

潜力

该表能在一定程度上指出个人潜力 ,但由于数值的广泛性缺失,并没有决定意义。

潜力

做产品久了,程序员的眼光会局限在某一块,纠结于产品逻辑,少有技术创新。为了维持团队稳定,保持推动力,我根据团队成员的兴趣点制定了兴趣组计划,把整个团队按兴趣方向分成了3D、HTML、Lua几个兴趣组,并着手申请现有项目的HTML5移植和脚本化。

这次沟通的结果就是促成了兴趣组的建立。兴趣组对团队成员是一个重要的推动,同时也是对客户端开发培训工作的方向性指导。

到了年底,我让大家写2016计划之后,又针对TA们的个人计划进行了一次统计:

兴趣点的人员分布

兴趣点的人员分布

人员的兴趣点分布

人员的兴趣点分布

可以看出,由于是计划,大家放得比较开,各种不同的想法和各种零碎的细节都出现在计划中,下一步,就是把这些碎碎念都能融入到兴趣组计划中。兴趣组已经不再局限于技术,写作、读书、健身都可以是兴趣的一部分,这类有生活气息的兴趣组与基于技术的强连接兴趣组相辅相成,更能加强团队成员之间的联系交流,保持团队活力。

4. 让团队成员信任你

都说文人相轻,其实程序员相轻地更厉害。作为一个“空降”的 Leader,用什么方法让你的团队成员信任你,从而提高工作效率?

很多空降的家伙们喜欢直接推翻前任的设计重来一次。我不否认这是一种不错的方式。同样的,这还是一种最偷懒的方式,一种最轻松的方式,一种最高效的方式。

可惜我不能这么做。我们团队负责的4个项目,每个项目都在线上跑。每个项目都抽不出人手来调整现有架构。何况,4个项目的架构还都不太一样。对这样的架构动大手术,稍稍不注意就会造成大的问题,影响收入。而我初来乍到,还没有得到团队成员的认可就进行大的改动,大家心里也不会认同。如果得不到全力的配合,就会事倍功半,把好事办砸。

我采用的方法是,找到一个痛点集中精力解决掉。 这个痛点应该让大家都感到棘手(凸显你的能力),使用非常频繁(大家会记住你),很难修改,比较复杂,但修改它(或者重写它)不能对现有的项目有太大的影响(安全),不用动用太多人力就能搞定(最好是你自己搞定)。

这个痛点就是项目的打包工具。旧的打包工具是一个设计得相当复杂的系统(其实就是没有设计),该系统由多人(5+)完成,多人(10+)对其进行了具体的实现和修改,最后的情况就是没有人知道这个系统的完整设计是怎样的。系统大部分由 bash 写成,在 windows 上依赖 cygwin,体量如下:

程序体量

我阅读了所有代码,绘制出了系统的架构图:

系统架构图

这套架构违反了许多设计原则,但正因为其复杂,最后没有人愿意改它。

submodule 和 配置文件的关系

打包的同学每接入一个 SDK,就需要写几百行 bash 脚本,这些脚本从别的 setup.sh 文件复制过来,再进行修改。这导致如果有了更好的实现,也只可能在最新的脚本中才可以用上,没人敢跑回去改老的脚本。

这样一个系统整合符合我的选择。我花了一些时间询问所有和打包系统相关的人,弄清楚了整套系统的结构,用 Python 写了一套全新的打包工具,这套工具不必再依赖 cygwin 。新的打包系统设计了一套继承和覆盖流程,让负责发布的同学可以不用写脚本,直接通过配置文件就能支持新的 SDK。新的配置文件基于 ini 格式,测试同学可以更易懂地进行配置。由于有完整的设计文档和使用文档,再加上使用了配置文件模版,无论是修改还是扩展都很方便。

配置文件的级别

项目中很快用上了这套工具,事实证明打包效率的提高是非常明显的。我在每个项目中找了一位同学负责该工具的后续维护,我就全身而退了。

后面的事情证明,这套工具不但带动了大家主动学习 Python 的热情,还增强了大家对文档的认识,同时我的设计思路和执行方法也得到了大家的认同,后面对工具、框架、方法的推动就比较容易了。

5. 培训计划

在和团队成员沟通的过程中,我发现许多人并不是不够努力,而是不知道往哪个方向努力。或者说,不知道应该如何努力,才能更快地成长。有些人认为已经掌握的技能足够解决目前的问题,就开始懈怠,或者开始焦虑。大家不知道自己处于技能树的那个级别,也不知道下一步应该爬往哪个方向。

于是,培训,尤其是系统的培训计划就相当重要。我根据手机游戏客户端技术的特点编写了一个技能树:

客户端技能树

所有的培训内容、文档、PPT 和源码都是通过 git 管理的。主要文档使用 Sphinx 写成,所有团队成员一起维护,所有的培训都有记录。绝大部分培训都有练习。每个人都可以是合作者、执行者和学习者。

采用这种方式,我可以直接在技能树培训的过程中,顺便把入职培训的内容也做了。后面进入团队的新人,可以直接 无缝接入 这套培训系统。

因为培训的内容都在内网,这里给出两张截图:

培训开展流程
Sphinx 和 Markdown

6. 拉动其他团队

在游戏公司里,前端团队是非常特殊的存在。前端是产品从设计到成果的最终一环,玩家能直接体验到前端团队的成果。一个优秀的产品,必须是由一个优秀的前端团队打造出来的。

我一直认为一个优秀的手机游戏前端程序员必须做到以下几点:

  • 能指导美术团队按照客户端的优化需求切图;
  • 能给UI/UX团队提出靠谱的修改建议;
  • 能根据技术特点与商务团队沟通的SDK接入策略;
  • 能根据各OS平台特点和运营团队讨论推广策略;
  • 能根据客服团队需求设计更方便的反馈模块;
  • 能制订通信编码协议(必须是客户端制订);
  • 能与服务端团队讨论性能和优化策略;
  • ……

做到这些并不容易。前端程序员不但要熟悉美术工具,对各种媒体格式了如指掌,还必须了解UI和UX的基本知识,并将其运用到最终产品中;程序员要了解商务和运营的各种术语,要学会查看各种运营报表,从中分析出产品在前端方面的问题;程序员还要熟悉各种网络通信协议,要了解服务端开发的特点,要熟悉数据库、服务器性能,熟悉移动网络的特点,才能做到和服务端团队协同配合提升游戏的网络体验。

可是,大多数客户端程序员都不擅长做上面的工作。然后我可以反其道而行之,让其他团队了解一些客户端的工作。

我发现其他团队在制订操作方案的时候,并没有过多地考虑手机游戏的特点。这并非是由于他们不想做到更好,而是不知道我们前端团队能做到哪一步。和前端团队一样,其他团队也是对自己团队的工作范围熟悉,对其他团队的工作不熟悉。如果我们可以让大家互相多了解一些,那么在涉及到多个团队协作的部分,效率就会更高。

例如界面切图工作。美术同学切图可能不会考虑共享资源的重用,以及scale9等技巧,由于不了解界面在游戏中如何分割,图像文件的分类也不一定合理。而由于客户端程序员对PS等工具并不熟悉,也无法提出合理的修改意见。最终导致的结果就是美术素材浪费了内存和增大了最终包体积,或者客户端团队需要对美术资源进行二次修改才能使用。

要提高这部分工作效率,我采用的方式是让了解美术的前端程序员和美术团队一起工作,了解具体的切图流程,在切图过程中确定一些常用的规则,并让美术团队了解这样做的目的。一来二去,美术团队对客户端的需求会越来越了解,资源返工的可能性就越来越小了。

再比如,商务团队在和渠道谈SDK接入的时候,会涉及到一些技术问题,而渠道方负责合作的人员往往并不是技术人员,此时和我们客户端团队对接就会出现问题。如果商务团队了解一些接入的基本规则和技术术语,在和渠道方合作的时候,就能够更加得心应手地处理沟通问题,为客户端团队节省了大量的沟通时间。

7. 团队文化

文化有非常浓厚的个人烙印。一个公司的文化,一定有浓厚的创始人风格。而一个团队的文化,则反映着Leader的特点。

在创业时,我从无到有完整地打造了公司行政、人事流程和公司文化。而现在,我更希望按照公司特点打造一个高效的客户端团队。

文化是对共同价值观的认同。没有共同的价值观,也就没有共同的文化。我希望的团队文化必须是轻松的,有趣的,发展的,共赢的。

团队文化的建设即是实实在在的,又是潜移默化的。我们可以从日常的团建工作中找到突破口。所有这类工作,必须让所有人一起参与。比如我们团队上一次团建的内容这就是这么定下来的:

这是我发的第一封开脑洞邮件:

Hi all:
我们客户端团队要搞一次团建活动,请大家开一下脑洞。
唱歌就不必了,一群爷们木有妹子。
吃饭啥的有点 low,做备选方案吧
内容要有趣,大家都想参与
比如攀岩啥的,大家没搞过的在预算内的都可以搞搞
客户端共xx人,公司预算每人xxx,我再出xxx,大家按这个来计算。若再超过,大家 AA 多出的部分。
今天下班前,每人必须回复。
没想法的请回复: “没想法” ,然后 AA 的时候出2倍。

期间,给一些合适的引导:

Hi game client:
LHJ制作人JY同学组织了一群乌合之众试图与我们在网吧一争高下,请大家准备好,给他们点 color 瞧瞧,让他们知道游戏是用键盘敲出来 DI !!!!
@JX,是不是可以设计点彩头哇……

经过了十几轮邮件轰炸之后,结果变成了这样:

Hi all:
投票结果已经出来了,见附件。
可以看出,69%的同学选择网吧游戏,46%的同学选择吃饭。那么我们这次就搞 网吧游戏+吃饭 的团建吧!运动也有不少同学选择,我们在下次团建考虑。
时间上,由于必须在 12月31日前完成,我选了3个时间点。54%的同学选择了圣诞节当天,那么我们就定这个时间。

团建本来是轻松的事情。但开放式讨论必须有人收尾。就像我初中时团支书说的那样:既要民主,也要集中。按大家的兴趣点把时间地点人物确定,整件事儿基本上就可以愉快地开始了!这次团建大家都是蛮Happy的: 客户端团队圣诞团建回顾–我们的快乐与大家分享!

团建仅仅是团队文化建设的一部分。更多的文化建设是潜移默化进行的。例如在上面提到的培训过程中,合作者与执行者的交流,每次授课之前的小范围试讲;再例如根据每个程序员的特点安排不同的工作,安排不同项目之间的经验交流;还有让团队中每一个成员都了解自己的位置和发展方向,都知道碰到某些问题的时候应该找哪位成员询问等等。这些看似平常,但都是文化建设的重点。

团队文化建设的前提,就是Leader要充分了解团队成员,知道每个人的喜好和特点,还要保持鲜明的个人风格,并把自己的风格与团队成员特点,公司风格融合起来。这样建立起来的团队文化,才是经得起考验的,才是能帮助团队成长的,才是能和公司一同进步的。

8. 积累

想要做一个称职的 Leader,积累是至关重要的。

在技术经验上,你的积累能够帮助你的团队快速解决棘手的问题。当然,这是技术 Leader 的基本功。我说一点技术之外的积累。

8.1 谈话

一对一谈话是了解团队成员想法的重要手段。上面谈到的对团队成员兴趣的了解,大多数都是通过一对一谈话来完成的。谈话的内容要实时做好记录,并做好对每次谈话的结果分析。

下面是我做的一个典型谈话分析。包括谈话内容,对于普遍情况的总结,以及对于特殊情况的描述,最后包括解决这些问题的可选方案。

只有记录了每一次谈话的内容,才能在下次谈话的时候根据原来的记录做出合理的比较,看看哪些人进步了,哪些人的方向变化了,然后继续寻找更合适的方法。

谈话记录

8.2 人事

人才和面试,是团队成长和建设的重中之重。上面我专门用了两个独立的章节来讲。

我对所有经手的面试和离职都会做好记录。在有员工离职时,我可以通过对比分析其他员工的离职原因,看看到底是因为干得不爽还是钱没给够。每个优秀员工的离职,对团队都会有一定的影响,对我的工作也是一个考验。如果能够在离职之前发现问题所在,有针对性的进行工作的调整和团队建设,无论对团队来讲还是对离职员工来讲,都是件好事。

所有的面试资料中都包含简历资料,在一个新员工入职后,我可以通过 TA 的表现,慢慢去印证当时的面试有哪些偏差,是否出现了判断错误,把一个优秀的求职者放弃了?还是看走了眼,招入了一个平庸的人?

人事记录

8.3 GTD

大多数公司都会使用邮件来管理和发布工作。但邮件并不是进行工作管理的好工具。为了方便分析和整理,我会把每天的工作记录下来。这些工作包括一些重要的邮件,讨论和会议,还有一些就是日常的杂事。

每日记录

有了每日工作记录,就很容易写出周报和月报并作出总结。一些比较独立的事件,并不放在日报中,而是将它们进行单独记录,再以链接的形式将其加入到每日工作记录中。每月结束的时候,回顾一下这些记录,对下个月的工作安排有极大的指导意义。

月记录

9. 结语

本来准备随便写写的,一不小心就写成了工作汇报。谈不上经验,就是胡扯而已。就像我在 游戏逻辑程序员的成长出路? – 曾嵘的回答 里面说的那样:

如果你所处的是有 HR 有网管有安全部门有运维部门有扫地大妈的公司。就当我放屁好了。

我现在就在有 HR 有网管有安全部门有运维部门有扫地大妈的公司。

所以你们就当我放屁好了。

(放完了)