11 KiB
第167讲 | 俞圆圆：合格CTO应该做好的5件事（下）
你好，我是VPGAME的CTO俞圆圆，今天继续和大家聊聊一个合格的CTO应该做好的5件事。在上一篇文章中，我们聊到了“技术原点”和“技术方向”两方面的内容，这一期，我们继续说说其他的3个方面：“技术决策”，“技术外沿”，和“技术人才”。
技术决策：依赖“常识”做判断，做正确的事
即使再勤奋努力，我们也不可能做到对每个技术领域都有足够的学习和了解，所以作为技术领导者，很重要的一个素质就是在没有充分了解一个领域的情况下，如何还能有效地帮助团队做出正确的判断。
这些年的创业热潮催生出很多有趣的现象，其中一种叫潮词金句新概念癖。讨论问题的时候，不提几句认知、降维、赋能、反脆弱，似乎都不好意思说自己是创业者。处于这样的环境中，一个团队以及它的核心成员很容易产生一种“时不我待”的焦虑感。新的概念我们需要去了解，但并不是所有的新兴概念都能真的带来价值的。作为团队的领导者，如何在高不确定性的环境下去有效地甄别和选择哪些是“正确的事”和“正确的方法”，是极其重要的工作。其结果不但会影响团队中短期的决策和方向，更可能会影响团队长期的文化氛围。
好的技术团队文化很难概括，但大多有些共性，比如讲究常识，说人话，重视逻辑，以及互相间尽可能平视的视角等等。同样，在面对知之不深的领域的时候，“常识”，也许是能够帮助我们做出正确判断的最有效的方法。
对于技术领导者来说，有哪些是可能要面对的知之不深的领域呢？
1.技术面试的时候：你对候选人不了解，你也很可能对他擅长的技术背景不那么精通；
2.技术选型的时候：流量、负载、容错性、可扩展性等等，都是未知但却必须考虑的因素；
3.技术攻坚的时候：不同的技术团队遇到的不同领域的技术难题需要你去指导解决。
那有哪些“常识”能够协助我们做出判断呢？
-
1.评估候选人的能力（比如责任心，抗压力，创造力），而不是知识
-
2.做任何决策，先问问评估成败的核心指标是什么
-
3.核心指标宜少不宜多
-
4.指标要尽量可量化
-
5.先抗住再优化，边重构边生活
-
6.持续迭代，而不是过度设计
-
7.化繁为简
-
8.其他人听不懂的一定不是好的技术方案
-
9.让懂的人和不懂的人都能坦然地表达自己的“有知”和“无知”
-
10.有违价值观底线的方案坚决不采纳
-
11.先统一思想，再约束行动
……
这些“常识”性的原则看起来也许比较抽象，但其实真正在日常工作中应用起来却并非如此，我们举个例子：大部分的技术团队都会有一定的绩效体系，不论是KPI也好，或是OKR也好。在此我们不讨论KPI好还是OKR好, 何为道，何为术等等抽象的问题。每个团队的实际情况不同，每个leader的个人风格不同，应该都会有自己的判断和选择。在这里我想说的是一点通用的“常识”，就是不论我们用的是何种绩效体系，如果我们评价的核心指标十分繁复的话，那这个体系所产出的结果很可能是不理想的。
如果一个员工将自己一个季度的绩效目标划分为7-8个小项来评估，每个小项占10%-15%的权重，那这就是一个强烈的信号，说明这个团队的管理或者这个员工的自我管理出现了不小的问题，具体存在以下这些可能性：
- 当一个员工的目标如此繁多而琐碎的时候，他的工作很可能是没有重点的。什么都想做好，往往是什么都做不好。
- 这个团队对于当前核心任务的拆分比较混乱，导致员工必须完成很多不同的工作才能达到团队的目标。员工可能疲于奔命，团队也可能顾此失彼。
- 团队负责人对于员工的帮助或指导可能是浮于表面的，作为一个领导者, 我们真的能同时对员工的7-8个不同的工作或能力做出有效的评估和指导么？我们是否真的了解了我们的小伙伴最迫切需要提高的核心能力是什么？
- 员工或团队对于以结果导向来证明自己的贡献和价值没有信心，而正是因为缺乏这样的信心，才抱着“这么多事，总能做好3-4件吧，这样至少有个交代”的心理，以很多细碎的小目标来掩饰心虚。
根据这个常识性原则，我们团队在制定季度和年度绩效目标的时候，一直是强行规定必须只能有小于等于5个分目标，有时在一个季度的时间范围内甚至会规定必须只能有小于等于3个甚至2个分目标。如果做不到，那说明我们对当前最需要解决的问题剖析的还不够深，我们对赖以生存的关键条件分解的还不够细，我们的精力和资源还不够聚焦。
技术外沿：项目之外，还有你需要关心的
作为团队的技术负责人，确保业务及时安全稳定的交付是我们的本分，追求技术有序高效深入的演进是我们的愿望，但除此之外，其实还有很多其他重要的工作需要我们的关注，在此试举一些：
1.专利申请
2.外部的技术影响力和技术形象
3.内部的技术氛围
4.企业基础IT建设
5.成本管控（人力成本，运维成本等）
这些工作看似和项目交付、创造营收等没有直接的联系，但其实会在潜移默化中影响一个技术团队的长期产能，是我们责无旁贷要去关注的。并非每个企业，特别是初创企业，都配备了完整的职能部门帮助你完成上面的各类事项，所以很多时候需要技术负责人自己去主动补位、主动担当。比如专利申请需要法务或行政部门的配合，技术形象和技术影响力依赖外部技术渠道的运营可能需要市场或商务部门的配合，内部的技术氛围需要HR培训部门的配合，企业IT建设和成本管控需要采购或财务部门的配合，我们并无法保证所需要的资源和支持一定能够全部到位，但我们也不能坐而论道，等待客观条件都成熟了才去行动。对团队有利并且当前必须要做的事，有条件的就执行的坚决一些，没有条件的就创造条件去执行。
举个例子，VPGAME是一家创业公司，和很多其他创业公司一样，我们在很多领域并没有完整建制的部门人力资源，比如当我们想将积累下来的一些技术沉淀回馈给技术社区的时候，却发现公司的市场商务部门并没有现存的技术渠道关系，也没有相关的技术市场建设的铺垫，甚至没有相关的市场人员有精力或经验来负责这部分工作的。所以最开始起步的时候，我就直接拉上HR招聘部门的同学一起来做技术市场推广和对外技术影响力建设的工作。
我和招聘部门的同学是这样解释的：也许这部分投入在短期内未必会看到回报，但从中长期来说，我坚信这些投入一定会给招聘工作带来反哺。我们想要找到那些优秀的志同道合的研发人才，不能单纯地依赖传统的招聘渠道，在我们寻找技术人才的同时，我们也希望技术人才能注意到我们，能了解到我们是一家以技术为核心驱动力的互联网创业公司，能知道我们对技术的尊重和积累，从而多多少少给他们心中留下一个VPGAME的印象，甚至有可能主动地和我们来联系。即使做一整年这样的工作就换来一个优秀研发人员的加入，我觉得都是值的。
事实上，我们也确实通过这样的坚持，收获了不止一个的优秀技术人员来加入我们的团队。
很多“技术外沿”的工作经常是没有短期直接回报的，但作为技术团队的领导者，我们应该有这个战略眼光，在合适的时间为了一些长期的价值坚持去做相应的投入。积一时之跬步，臻千里之遥程。
技术人才：你就是团队最重要的HR主官
作为技术领导者，你最重要的工作职责之一就是为团队培养和选拔人才。HR关于人才体系的各个环节，不论是招聘，培训，还是绩效等等，我们千万不能认为“交给HR就好了嘛”。我们自己才是团队最重要的HR主管，人才选拔、培养、留存、汰换的各个环节，我们的参与和重视程度，会极大的影响最终的结果。让我们分几个阶段来简单地看一下：
1.招聘阶段：从待招岗位的JD到面试前的准备，你都有充分了解和准备么？你团队里的新员工有多少是你亲自面试过的（不同的发展阶段会有不同的答案）？一场面试，你是不是等候选人到前台了才匆匆拿起HR给你的简历扫了几眼，然后就开始临场发挥了？你是不是一直在用同样一组问题在评估所有的候选人？面试后所有的面试官对于候选人有没有进行审慎的讨论合议？
2.培训阶段：你的团队给员工提供了怎样的内部和外部的培训资源和渠道？是否有定期的培训计划，还是想到了就做做，忙了就再说呢？你自身是否做过什么表率性的工作来告诉团队持续学习的重要性？员工是否将学习提高作为他们工作的必要组成部分？员工之间是否有良好的技术分享和讨论的氛围？有多少员工是能够上台做一个出色的内部技术分享的？外部的技术分享呢？
3.绩效阶段：在制定绩效目标前，我们是否对团队的职责进行了足够的拆分和明确？我们的团队是否足够精干简练，从而每个人的工作成效都能和结果成直接因果关系？一个团队如果有5个人对同一目标负责，是不是意味着如果目标不达成那这5个人的考核就全部是不合格的？拆分了职责之后，我们充分授权了么？
4.汰换阶段：271的原则要不要遵守？末尾或者后10%淘汰是不是必要的？绩效改进计划(PIP)的目的是什么，目的是单一的么？
我列出了很多问题但没有给出什么答案，因为这里很多内容展开的话自身就够写一篇文章的了，所以在这里我只是想说，如果这些问题和工作，你作为团队的技术负责人没有想过而是全部交由HR部门来处理的话，也许那并不是最好的安排。
感谢大家的阅读，希望这篇文章对你有一点小小的帮助，也欢迎把它分享给更多的朋友。
作者简介
俞圆圆，VPGame CTO，TGO鲲鹏会会员，前UCloud 基础云计算研发中心总监。曾经分别供职于 Microsoft Windows Azure 和 Amazon AWS EC2，历任研发工程师，高级研发主管，首席软件开发经理。经常深入第一线为客户提供技术支持，全面参与日常运维和现网问题排查，并组建和带领过实战能力极强的研发团队。在大规模、企业级分布式系统、面向服务架构、TCP/IP 协议栈、数据中心网络、云计算平台服务的研发和运维等方向积累了大量的实战经验。