怎么做好互联网公司的技术负责人？
这篇文章是我在知乎上的一个回答。 问题： 如题，怎么做好互联网公司的技术团队负责人。互联网公司的技术团队负责人应该具备怎样的能力 回答原文： 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 感兴趣的话题，根本不用我提醒就能滔滔不绝讲下去，那是拦也拦不住的，二面分分钟超过两小时，而且我都插不上话！我经常用这种方法在面试的时候偷懒，既能少回去开会，也能多了解这位同学的方方方面面。 前几天刚面了以为只闷不骚的同学，这位同学有一种逆天的技能，就是所有的句子都是短句，所有的回答都是封闭性回答，所有的谈话都不展开。即使是我的开放式问题，他也能转换成封闭式问题然后给一个短句答案。我举两个他回答的经典语录：
当然，上面说的是一些极端情况，大部分程序员还是挺本分的，中规中矩，不温不火。作为技术团队的负责人，在招聘中需要睁大眼睛分辨这类大多数情况，保证不漏过一个可以培养的骚人，也不能招入一个没法培养的弱人。 在我看来，闷骚的程序员可能有下面几个特性：
上面的特点可以说是极骚，下面的是普骚：
2.2 面试的两级要筛选出足够好的人，面试一定要慎重。我曾经就因为太想找到 “能干活的人” 而吃了许多苦头。我碰到过干了一个月从不加班等到发薪水那天晚上加班到 21 点薪水到账就马上删除代码来要挟我们的；也碰到过受不了一点批评摔门而去的；还碰到过使用物理技能攻击公司 boss 然后威胁 format d: /P 的…… 一些事情到现在想起来还会呼吸急促，大脑缺氧。 上面这些人中，有从 360 公司回来的北漂，有十几年的程序员，甚至有公司的创始员工…… 所以，在面试层面多花点功夫是值得的。面试至少要有两面。下面是我的老大给的关于面试的要求：
其实就算是严格执行上面的建议，也很难杜绝所有的问题。曾经有一个十年经验的程序员，经过了两轮面试，表现都很好。但工作起来和面试感受完全不同。没过多久他主动提出了离职，给出的原因让人匪夷所思，就是觉得工作上很 “别扭” 。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 的基本知识，并将其运用到最终产品中；程序员要了解商务和运营的各种术语，要学会查看各种运营报表，从中分析出产品在前端方面的问题；程序员还要熟悉各种网络通信协议，要了解服务端开发的特点，要熟悉数据库、服务器性能，熟悉移动网络的特点，才能做到和服务端团队协同配合提升游戏的网络体验。 可是，大多数客户端程序员都不擅长做上面的工作。然后我可以反其道而行之，让其他团队了解一些客户端的工作。 我发现其他团队在制订操作方案的时候，并没有过多地考虑手机游戏的特点。这并非是由于他们不想做到更好，而是不知道我们前端团队能做到哪一步。和前端团队一样，其他团队也是对自己团队的工作范围熟悉，对其他团队的工作不熟悉。如果我们可以让大家互相多了解一些，那么在涉及到多个团队协作的部分，效率就会更高。 例如界面切图工作。美术同学切图可能不会考虑共享资源的重用，以及 scale9 等技巧，由于不了解界面在游戏中如何分割，图像文件的分类也不一定合理。而由于客户端程序员对 PS 等工具并不熟悉，也无法提出合理的修改意见。最终导致的结果就是美术素材浪费了内存和增大了最终包体积，或者客户端团队需要对美术资源进行二次修改才能使用。 要提高这部分工作效率，我采用的方式是让了解美术的前端程序员和美术团队一起工作，了解具体的切图流程，在切图过程中确定一些常用的规则，并让美术团队了解这样做的目的。一来二去，美术团队对客户端的需求会越来越了解，资源返工的可能性就越来越小了。 再比如，商务团队在和渠道谈 SDK 接入的时候，会涉及到一些技术问题，而渠道方负责合作的人员往往并不是技术人员，此时和我们客户端团队对接就会出现问题。如果商务团队了解一些接入的基本规则和技术术语，在和渠道方合作的时候，就能够更加得心应手地处理沟通问题，为客户端团队节省了大量的沟通时间。 7. 团队文化文化有非常浓厚的个人烙印。一个公司的文化，一定有浓厚的创始人风格。而一个团队的文化，则反映着 Leader 的特点。 在创业时，我从无到有完整地打造了公司行政、人事流程和公司文化。而现在，我更希望按照公司特点打造一个高效的客户端团队。 文化是对共同价值观的认同。没有共同的价值观，也就没有共同的文化。我希望的团队文化必须是轻松的，有趣的，发展的，共赢的。 团队文化的建设即是实实在在的，又是潜移默化的。我们可以从日常的团建工作中找到突破口。所有这类工作，必须让所有人一起参与。比如我们团队上一次团建的内容这就是这么定下来的： 这是我发的第一封开脑洞邮件：
期间，给一些合适的引导：
经过了十几轮邮件轰炸之后，结果变成了这样：
团建本来是轻松的事情。但开放式讨论必须有人收尾。就像我初中时团支书说的那样：既要民主，也要集中。按大家的兴趣点把时间地点人物确定，整件事儿基本上就可以愉快地开始了！这次团建大家都是蛮 Happy 的：客户端团队圣诞团建回顾我们的快乐与大家分享！ 团建仅仅是团队文化建设的一部分。更多的文化建设是潜移默化进行的。例如在上面提到的培训过程中，合作者与执行者的交流，每次授课之前的小范围试讲；再例如根据每个程序员的特点安排不同的工作，安排不同项目之间的经验交流；还有让团队中每一个成员都了解自己的位置和发展方向，都知道碰到某些问题的时候应该找哪位成员询问等等。这些看似平常，但都是文化建设的重点。 团队文化建设的前提，就是 Leader 要充分了解团队成员，知道每个人的喜好和特点，还要保持鲜明的个人风格，并把自己的风格与团队成员特点，公司风格融合起来。这样建立起来的团队文化，才是经得起考验的，才是能帮助团队成长的，才是能和公司一同进步的。 8. 积累想要做一个称职的 Leader，积累是至关重要的。 在技术经验上，你的积累能够帮助你的团队快速解决棘手的问题。当然，这是技术 Leader 的基本功。我说一点技术之外的积累。 8.1 谈话一对一谈话是了解团队成员想法的重要手段。上面谈到的对团队成员兴趣的了解，大多数都是通过一对一谈话来完成的。谈话的内容要实时做好记录，并做好对每次谈话的结果分析。 下面是我做的一个典型谈话分析。包括谈话内容，对于普遍情况的总结，以及对于特殊情况的描述，最后包括解决这些问题的可选方案。 只有记录了每一次谈话的内容，才能在下次谈话的时候根据原来的记录做出合理的比较，看看哪些人进步了，哪些人的方向变化了，然后继续寻找更合适的方法。 8.2 人事人才和面试，是团队成长和建设的重中之重。上面我专门用了两个独立的章节来讲。 我对所有经手的面试和离职都会做好记录。在有员工离职时，我可以通过对比分析其他员工的离职原因，看看到底是因为干得不爽还是钱没给够。每个优秀员工的离职，对团队都会有一定的影响，对我的工作也是一个考验。如果能够在离职之前发现问题所在，有针对性的进行工作的调整和团队建设，无论对团队来讲还是对离职员工来讲，都是件好事。 所有的面试资料中都包含简历资料，在一个新员工入职后，我可以通过 TA 的表现，慢慢去印证当时的面试有哪些偏差，是否出现了判断错误，把一个优秀的求职者放弃了？还是看走了眼，招入了一个平庸的人？ 8.3 GTD大多数公司都会使用邮件来管理和发布工作。但邮件并不是进行工作管理的好工具。为了方便分析和整理，我会把每天的工作记录下来。这些工作包括一些重要的邮件，讨论和会议，还有一些就是日常的杂事。 有了每日工作记录，就很容易写出周报和月报并作出总结。一些比较独立的事件，并不放在日报中，而是将它们进行单独记录，再以链接的形式将其加入到每日工作记录中。每月结束的时候，回顾一下这些记录，对下个月的工作安排有极大的指导意义。 9. 结语本来准备随便写写的，一不小心就写成了工作汇报。谈不上经验，就是胡扯而已。就像我在游戏逻辑程序员的成长出路？ 曾嵘的回答里面说的那样：
我现在就在有 HR 有网管有安全部门有运维部门有扫地大妈的公司。 所以你们就当我放屁好了。 （放完了） http://zengrong.net/post/2433.htm sohu-dba 本文转载自：微信公众账号 - SOHU-DBA，版权归原作者所有！ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
