写这篇文字的动机是我在 ONES 这边理解和获得了管理成长,是时候梳理下了。
    我现在就职于 ONES-技术工程部-性能优化组,负责性能优化和研发效能。
    在这里碰到的管理我认为才是真正的管理(想对之前的管理经历),而且是我可以理解的管理,不会抵触的管理,甚至会向往的管理。

    技术能力是基础,是解决问题的基础。
    很简单的现实是,看你是怎么被晋升到管理的,大部分是因为其有较强的技术能力。我从 21年4月 加入 ONES,在《技术工程部-性能优化组》负责性能有优化,然后做了几个核心的性能优化,这代表着技术能力是可以解决问题的。
    有技术基础也可以是一个很核心的竞争力。很多公司可能这个层级的管理更多是业务结果型管理。他们之前是技术的扛把子,但是已经很久没有接触一线了。特别是对于技术更新迭代频繁的前端来说,会有点脱轨。这个脱轨表现成他们需要通过更厉害的人来获得结果。他们本身不具备自己直接获得结果的能力。
    同时还会看到很多公司的管理是技术扛把子升上去的。
    所以有技术有管理是个很核心的竞争力,形成了独特的竞争力。

    管理也分公司规模。
    我上家在观麦,100 人左右规模。那个时候带着 15 人的前端团队规模。如果让我归纳的话是向下管理。我的重心是怎么把前端团队带好,怎么把业务支撑好,提供子弹给业务方。招人、培养人、团队梯度建设、团队原则建设、成长模型,这里很多都是围绕着怎么给他们创造更好的技术环境,从而更好的支撑到业务。
    而现在的 ONES,500人 ~ 1000 左右规模。很多事情就不一样了。
    就比如一个创业公司招人,更倾向经验少的人,经济点的,来到中心公司或者大公司,更多是找有丰富经验和能力解决问题的人。
    就比如一个创业公司的 leader,没啥体系的管理能力,来到中型公司或者大公司,就需要硬的管理能力,定目标,抓过程等。
    就比如一个创业公司的技术,相对来说接触的比较浅,来打中型公司或者大公司,业务复杂度都比创业公司复杂上很多。
    有幸,我能成为 ONES 的一名管理者,在这里有我成长空间。蛮幸运的。

    是技术也是管理。
    对我来说不可能是纯技术也不可能是纯管理。
    我喜欢技术,喜欢技术带来的效率提升和创新,喜欢技术带来的价值,但是技术有限,前端相对来说天花板是低一些。前端的技术深水区在图形化吃数学能力、在文档编辑器吃长期的架构能力等领域,这类的门槛挺高的,而且和以往的技术可能不是一个维度的事情。也就是可以理解为两类人才类型。做文档编辑器可能就一直做文档编辑器了,再回到常规前端不一定就具备竞争力,技术深了路也窄了,相对竞争也多。
    我也喜欢管理。喜欢和其他人交流,喜欢交流带来的认知扩宽和能力成长。喜欢培养人,喜欢看着他们逐步成长成为一个独立的人。喜欢做出业绩,喜欢业务问题的成就感。但是上面有提到,管理需要技术基础,需要跟上技术迭代,也容易绑定公司。
    对于技术和管理的占比,在观麦是技术大于管理,在 ONES 这边逐渐是管理大于技术。幸运的是我在技术工程部,是技术型管理,做着管理的工作,但是不会脱离技术。所以对于我来说是技术也是管理,喜欢技术也喜欢管理。
    可能这里提到了管理会有不同的理解,在 ONES 的管理是技术型管理,CTO CEO 本身是技术出身,很理想,很技术型管理。

    向上解决问题,向下拿结果。
    也有种说法是向上管理和向下管理,但是这种说法很容易让人抵触或迷茫。我们不妨去思考向上管理实际上是在管理什么,向下管理实际上是在管理什么。向上管理是解决问题,我们需要列出来现在的问题是什么,那些能解决那些不能解决,怎么解决这些问题短期中期长期如何,需要多少资源做多久。向下管理是建立信任感,营造好的氛围,定好目标,做好调度资源,做好计划,完成任务,获得结果。
    一开始团队 2 个人,逐步走到现在的 5 个人,后面还会有几位加入。前期的时候人手不够,自己需要在一线奋斗,处理客户问题,处理性能问题,这个状态持续了半年左右。随着团队的扩大,自己已经没法同时在一线和管理。
    做管理和做一线是不一样,做一线更多是自己怎么把事情做好。做管理要明白一个人的力量是有限的。需要通过别人获取成果。在没这么忙的时候,我开始思考几件事:培养人接替一线的工作;思考团队的流程,怎样让团队更高效的工作; 复盘和思考团队的方向,要解决什么问题,要做什么,做这些需要多少资源;和上面要资源;等等。
    现在回想起来,我应该更早的去做这些事情。也许我就辛苦一二周,知道方向,要到更多的人来做事,解决问题就能更提前点。

    自己要闲下来。
    上提到了很多思考,是因为开始感受到人不够用的时候才做的思考。还有个关键因素是恰好这段时间住院了几次,被动的有时间思考。所以有时候停下来思考是有必要的。
    闲下来。让更多的机会给到一线的同学锻炼,别什么事亲力亲为。
    闲下来。自己去做往前探的东西,探好后面的路。
    闲下来。思考更多团队方向,方向比努力更重要。
    闲下来。只有状态好,精力充足的时候往往能有效的解决问题,精力比时间更重要。
    闲下来。不加班、多运动、多陪家人。说实话,ONES 在加班控制上做的很舒服。

    定目标,只定目标,提供自由度
    这个是最近获得感悟。在之前 ONES 的流程是,PO 定好 OKR,把 OKR 转换成一个个迭代,把迭代的用户故事想清楚,把验收标准想清楚。然而一线的同学更多的是在执行。执行的多了很多人就停留在执行上了。这会带来一些积极性问题,比如只执行,没有去思考为什么要执行,怎么验证自己的执行符合目的。
    后来我做了一个动作,就是定目标,只定目标,剩下的事情的提供足够的灵活度给他们。他们自己定迭代,定用户故事,定验收标准,定周期等等。你会发现当他们去定迭代的时候回去想怎么去定迭代,这个时候会联系到 OKR,从而又加深了 OKR 的理解上。我不需要去关注太多,只需要做一件事情,保证目标不偏离即可,其他自由度都是他们的。

    沟通表达。
    当我们成为管理,会处于一个承上启下的位置,沟通表达就显得尤为重要。
    沟通表达需要清晰。比如有效清晰的沟通让别人理解你的意图理解你的方向,从而执行的时候不会偏差。比如错别字,在汇报周会的时候之前有错别字,导致其他管理者在理解我的周报的时候存在困难,或者理解错我的意思。还好后来改正了。
    沟通表达需要照顾更多群体。比如我在推广性能标准的时候,我觉得我的表达已经够清晰了,但是给测试看的时候,会有很多专业性的词汇他们不理解,后来让测试也介入以前编写文档才能让他们理解。
    沟通表达需要有结构。有人表达的时候像流水,经常描述过程,却不知道听的人无法获取想要表达的意识或者需要猜测,就很容易出现理解不一致。有人表达的时候有条理,听众就很容易明白。
    表达的本质是对这个事情的理解和思考。很多人会说不会表达,表达不出来。其实本质上对这个事情有没有全面深入的理解和自己的思考。如果有的话,表达出来是很轻松的。所以不用特地的去练习表达,而是投入时间去全面理解理解这个事情和加入自己独特的思考。
    表达的最高境界是类比。在理解和思考之上如果能够灵活运用身边的事情来类比就会变得通俗易懂。比如刚刚朋友聊团队中的负面情绪的事情,说了很多团队需要乐观积极的人站出来,最后收尾“哥谭市需要蝙蝠侠”。
    ONES 在面试的时候就会特别的注重这些点,比如总分总、STAR原则、金字塔原理等表达方式。最怕的是巴拉巴拉说了一大堆,别人还不能获取到重点。

    机械化执行。
    一些场景,如面试,每次都需要准备面试思考评价。如每次做报告或者周报都需要想格式怎么表达。如在做导师的时候想怎么带人。如修完一个 bug 需要怎么流转和流转的时候填什么。等等这些场景第一次第二次做的时候是需要思考的,但是第三次的时候就不应该再费时间去思考了,而是需要在前几次沉淀抽象出一些可以后面复用的内容。
    这些内容复用的形式在 ONES 内部叫机械化执行。比如面试会定要要问几个维度的东西,然后怎么打分。比如写报告的时候怎么写,有很多预设好的模板。比如修完 bug,在工具上点击流转状态,就知道可以怎么流转,流转的时候应该填什么,都是有预设好。
    把已有的经验沉淀,总结抽象,再下次遇到的时候机械化执行即可。这样就会带来非常高效的执行。这便是 ONES 的机械化执行。

    一个好的衡量标准。
    假设让你定义一台新能源车加速快,你会怎么衡量?业内说法是百米加速用时,比如 唐 DM-i 百米加速成绩 4.3s。其实生活中处处有标准,比如衡量 CPU 的跑分,比如水杯的食品级不锈钢 GB9684 标准。
    同样工作也处处需要指定标准。假设要提升版本质量,那么有很多种方式可以提升质量,比如严格方案,比如严格 review,比如测试多发散等等。那么衡量质量提升了呢,需要一个指标,指标又怎么定,这些标准哪些有用哪些没用。最终测试选用了一种方式叫 DI 指,就是一种缺陷的计算方式,不同的缺陷优先级对应不同的分数,最终剩下的缺陷的分数 DI < 8 才算版本质量好,才能发版。
    所以要找到一个简单好用能落地的衡量标准真的太难了,有时候需要灵感。
    比如我最近在推的性能 checklist,目的解决迭代内的无效渲染。但是无效渲染是一个技术能感知的东西,门槛高。后来知道 react dev tool 有个渲染高亮功能,当我变更 redux 的不相关数据的时候,如果组件渲染了,就代表这个组件存在无效渲染。这个方式对于技术来说很好衡量和执行,对于测试来说也很好衡量和执行。
    当要推动一个事情落地的时候,一个好的衡量标准很重要。

    假设 2 年后离开。
    这条是我自己总结的。在观麦的时候,时机成熟的时候我会对新人说:假设 2 年后离开,比如去字节,那么在这 2 年内你会做什么。同样的,我来 ONES 的时候我会想,假设 2 年后我离开,我需要在离开前把 ONES 的性能问题解决掉。那么我就需要做的事情是,把关键的性能问题解决掉,其次有一套机制脱离我也能够持续运作。
    至于 2 年后是留下还是离开,留到 2 年后再思考。目标清晰,做好当下。

    参考