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

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

问题：

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

回答原文：

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，体量如下：

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

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

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

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

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

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

5. 培训计划

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

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

客户端技能树

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

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

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

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 有网管有安全部门有运维部门有扫地大妈的公司。

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

（放完了）