责编 | 韩楠
约
4698
字 | 9 分钟阅读
我想可能有很多人和我一样，最初对于研发效能的理解就是等同于研发效率，认为只要从技术和工具层面持续改进，把原来需要人工执行的操作变为可以自动化执行的，就可以实现研发效能的提升。
当我抱着这个理念在工作中频频碰壁时，我才重新思考它的价值，
而我现在常常拿军队的工程能力和组织效能来类比研发效能，不知道你对于研发效能这件事又有什么样的认知、想法呢？
可以说，研发效能，绝对是2022年软件研发领域最热的词之一。不过你有没有发现，针对研发效能的看法，出现了两极分化？
一些人极度重视研发效能提升，他们投入时间学习相关知识、搭建工具链和度量体系；而另外一些人却是持有负面的看法，认为研发效能是个噱头，终有一天会搞垮团队。
研发效能＝工作时间？
研发效能＝个体的效率？
之所以出现这样的分歧，在我看来是由于不同人的视角不同，进而出现了不同的观点。就如凯撒大帝的名言里说的：“人们只会看到自己想看的东西”。
比如有些管理者甚至错误地把研发效能和工作时间等同起来了，只要团队投入足够多的工作时长就能够得到研发效能的提升。
这种认为加班能带来效能提升的想法，是存在明显逻辑错误的，效能是对效率和效果的综合评价，这种思路明显是只考虑效果而忽略了效率的做法。
另外有些工程师把研发效能等同于个体的效率，认为只要从个人角度干活儿爽了就能带来研发效能提升，而不需要再通过度量给自己戴上紧箍咒，觉得研发效能就是管理者为了压榨员工而编造的谎言。
管理者VS员工
整体VS局部
其实这种情况，应该是管理者只关注效能的结果数据，而忽略了团队成员的感受，由于管理者关注的效能代表了整体，而员工个体代表了局部，往往整体和局部存在关联性的同时，又存在一定的差异性。
而
研发效能
，
恰恰是从提升个体效率和整体协同两个层面着手，从而才能够使一个团队组织在一起达到一加一大于二的效果。
实质上，之所以产生这些对于研发效能的负面的看法，就是由于从管理者角度和从一线工程师角度，对其理解存在不一致。而在如火如荼的研发效能提升运动中，一线工程师往往处于被动位置，即使对于一些研发效能提升的做法和度量指标并不一定完全认同，也不得不去努力适应。
下面我就分别从两种视角，来分别梳理下对于研发效能的理解。
其中包含
管理者视角对于研发效能提升做的不到位的地方，
以及
工程师视角如何正确理解和应对研发效能提升这件事情。
管理者视角的研发效能
理论上来说，管理者视角对于研发效能的理解，应该是更接近其真实意义的，因为效能的本意就是强调工作成果的最终有效性。
从整个企业组织来说，其工作成果的最终有效性是让企业的业务达成目标，获得成功，而企业的管理者是更关注和理解业务成功这件事的。
业务结果固然重要，
管理不到位却暗藏隐患
但实际情况是，有些管理者在关注最终结果的同时，却在一些细节方面做的并不到位。
举个例子，就拿最常见的做法来说吧，他们简单粗暴地用研发效能度量结果数据，在不同团队或是不同个体之间横向对比，这就会导致研发团队和工程师之间的过度内卷。
那怎么做才能够少走弯路，改善或改变这样不良的业务现状等？下面我将结合过往的一些实践中总结、归纳沉淀下来的经验，以及一些切身心得，与你进一步讨论交流下。
我主要将围绕目标的一致性、关注团队和个体的差异性、关注基础设施和工程师文化建设这四个方面，分别阐述下建议管理者着重关注的地方。
Get这四招，助你破局
1）目标的一致性：在很多企业内部，不难发现，往往主要是由管理层负责整体目标的制定、大方向的决策，而下面的团队则逐级实现目标的拆解并负责具体任务的执行。
而目标和方向的正确性，是业务是否能够获得成功的一个关键条件。
那么当有些组织由于层级过多或者其他原因，造成了上级管理者制定的目标和方向，并没有很好地传达下去，导致下级团队没有获取足够的信息，就会使执行者之间形成各自的理解，当彼此之间朝向相反的方向产生反向作用力时，就会形成内耗从而降低整体的组织效能。
总结一句就是：
上
传下达多把关，层层目标拆解好，不然，内耗低效跑不了。
2）关注团队和个体的差异性：由于制定度量标准和流程机制是需要成本的，那么有些管理者常常为了节省成本，而采用统一的度量标准和流程机制，来衡量和约束不同的团队和个体。
中后台研发团队和前台业务研发团队的效能指标，理应是存在一些差异性的。
中后台研发团队所开发的系统服务更关注稳定性，而前台业务研发团队，则更需要关注需求的快速响应，从而支持业务需求的不断迭代。这时候如果采用同样的效能指标，来横向对比，则是不可取的，会造成团队的真正目标和度量指标之间的脱离，从而对研发效能提升带来负面效果。
总结一句，
效能指标需得有差异，管理也并非一锤定音，咱大可一试。我想，管理有方，同心协力，出不了奇迹，也定能出个好成绩。
3）关注基础设施建设：一些研发管理者，喜欢重点关注团队的开发模式和流程规范，比如敏捷开发和质量内嵌流程规范的推行，而对于研发的基础设施关注不够。这里指的基础设施包含高度自动化的效能工具、可扩展的系统架构设计，以及低技术债的代码。
而
如果没有一定的基础设施支撑，仅仅靠模式和流程的改善带来的效能提升
，
只是表面的
，
无法持久。
4）关注工程师文化建设：工程师文化的建立不是一朝一夕的，研发团队的核心骨干和架构师的工作风格习惯，往往会极大地影响一个团队的文化，还需要
管理者的关注和引领，才能够使工程师文化固化
、强化
到团队的行为
、
习惯中去。
比如对于效率和质量的极致追求，能够激发团队潜力持续追求较高的研发效能，而不是机械地去应付效能指标的要求。
前面提到的几点不足，并不一定全面，只是
希望在研发效能提升的过程中，研发管理者作为团队的重要角色，能够
有
意地多一些思考和前瞻
性思维
，从而起到正确
、有威信力
引领的作用。
与管理者不同的是，一线工程师在工作中每天面对的，都是具体的工作和问题，比如架构设计、代码编写和沟通协作等。
在很多研发团队中都存在着这样的现象，有些技术能力很强的工程师，具备优秀的技术功底和个人素质，却没有很好的绩效，得不到领导的重视，没法完全发挥自己的价值。
或许说到这，你也已经考虑到了。的确，这都是由于从工程师的视角，缺少了对全局角度研发效能的关注，而过多关注个体的效率提升，因此需要培养换位思考的习惯。
研发效能提升这场仗，怎么化被动为主动？
下面我带你一起从提升个人工作的有效性、关注整体工作成果的有效性，和有效使用效能度量指标三个方面，分别梳理下如何一步步实现视角的转变，从而在研发效能提升这场战役中化被动为主动。
个人工作有效性的提升，代表了战争中单兵的作战能力，士兵需要通过不断地刻意训练来获得提升。放到咱们这行，道理如出一辙，比如我们参与大规模分布式系统的设计与开发，或者应对电商系统的大促备战活动等，都能够在实践过程中获得能力的提升，并不断验证个人工作的有效性。
装备齐全的古罗马士兵
图源：知乎专栏@冷兵器研究所
下面是工程师提升个人工作有效性，需要关注的三个核心要素：架构设计、代码质量和沟通协作。这里就不一一展开说了，我分别梳理、归纳总结了几点，具体内容大家可以结合下图来看。
我们接着聊，不知你有发现、遇到过没，现实中有一些个人能力很强的工程师，往往给人留下难以沟通的印象。如果看到这里，沟通方面你也有些困惑，或是曾经抑或当下仍时不时或偶尔犯难。
我建议，咱倒不妨这里就先停下来一会，再细看下这三点中的沟通协作部分，或许可以给你带来或多或少的启发、思考。当然，后续我们也仍需多加关注，持续精进。
当然，沟通的形式有多种。除了通过语言沟通以外，写出好的文档、注释和项目日报等，也都很好的，抑或特定、关键节点、阶段，于你而言很重要。
当我们通过充分表达自己的代码设计意图和工作进展，不但能够让其他团队成员或者管理者，更好地了解自己的工作，而且还可以进一步帮助你提升自身工作的有效性。
如果你看过《三体》，应该会惊讶于三体人高效的沟通方式，他们通过脑电波沟通，每个三体人大脑的意图都是完全透明的，这样会极大提升沟通和协作的效率。
能够具备全局思维是工程师成长为架构师的必备条件，从需求阶段、到代码设计和编写、再到测试和运维去关注整个研发生命周期，目的是为了消除从局部视角对效能理解的不足。
如果把IT团队和工程师比做古代军队中的工程兵，修桥铺路的工程能力是能够协助战争获得胜利的重要条件，其前提也是能够在合适的时间、地点构建有效的工程设施。
古罗马军队的防御工程设施
图源：知乎@手望Sowarm
《七月的皇帝：凯撒大帝的传奇人生》
因此工程师作为团队的一员，除了关注个人工作有效性的同时，还需要更多的在需求和实现的一致性、进度和风险层面，给足够的关注，才能更大程度上促进提升团队整体工作的有效性。
研发效能度量的目标，是团队而不是个人，但并不是说工程师就不用关注效能指标了，我们
可以
通过对齐团队的效能指标，来审视自己的工作内容和产出。
随着研发效能度量体系的日臻完善，相关指标数据也越来越多，常常使一线工程师有无从下手的感觉。那么基于全局优先的角度出发，我认为工程师视角应该
更加聚焦于外向型行为相关的效能指标，因为这些行为更能影响全局的效能提升。
度量的目的是为了驱动改进，因此在重视全局而且面向结果的度量指标基础上，还需要通过层层拆解才能够落实到具体的行动上。最常见的就是团队需求交付周期的度量，需求交付周期是效率维度的全局指标，其特点是链条比较长和参与角色较多。
研发工程师视角的工作产出，一般会影响到设计、编码和测试这仨阶段。因此就跟下面这图中的一样：
首先我们可以做的就是通过改进工作方法，或者利用一些效率工具，来降低研发测试周期，在整个需求交付周期中的占比。
然后可以通过关注全局效能，分别把影响范围逐步扩展到整个需求交付周期，这是一个由内而外、层层递进的顺序。
在我看来，站在工程师的视角对待研发效能的正确态度，应该是把它作为一个方向指引，而不是作为标尺和模具来束缚自己，通过定期关注度量指标来改善自身的行为，持续提升个人有效产出并重点关注与外界发生交互的外向型行为。
总结起来就是
瞄准正确的方向，做好自己的事情并持续影响他人。
最后一部分，我还想给你介绍两个融合多视角的研发效能领域的工程实践，需要借助工具来实现信息的打通和多视角的融合。
拿现代化的城市举例，比如地铁线路和立体公路这样四通八达的交通基础设施，往往代表了其现代化程度，是因为这些设施能够极大促进人员和物资的流动效率，从而促进整体的经济发展。
图源：天空之城 城市的动脉
而
在软件开发生命周期过程中，也会涉及到不同阶段和不同角色，会有不同的数据产出，如何实现数据和流程的打通，是研发效能领域需要关注的事情，
下面就分别介绍下。
通过以不同层级的需求为主线，把执行具体技术任务所产生的研发过程资产串联起来，这样的好处一方面从管理者和业务方的角度，能够更加清晰地了解一个需求在技术层面的投入和风险等信息。另一方面作为工程师，在针对具体技术任务的事前准备、执行过程和事后复盘等过程中，都能够更加关注其所产生的需求价值。
保持专注和不受干扰，是能够提高研发效能的重要因素。而如果能够把管理者与工程师之间、团队内部不同角色之间约定的一些规则，通过自动化的方式实现，就能借助自动化本身高效和客观性的特性来消除干扰和提高效能。
这些规则是建立在打通研发流程工具链的基础上实现的，可以包含需求任务的状态自动变更、进入当前阶段的标准阈值判定、对质量标准的自动结果检查、效能度量数据的自动汇总分析和风险的自动预警等。
优秀的工程实践的推行和实施，需要团队的管理者和工程师都能够参与进来。而
需要的工具支撑
，
大多是由专职或者兼职的研发效能团队来实现的，因此也可以说在这里补充了研发效能团队视角的效能提升。
结语
我的主要工作是从事研发效能平台建设和具体实践的推动，同时也分别从事过测试、开发和产品岗位，基于工作需要也与一些架构师、质量管理者和开发经理等角色，探讨过研发效能的话题，因此本文我努力站在旁观者的角度，带你一起梳理了不同视角对于研发效能的理解。
其目的也在于想要帮助研发效能提升的关键角色——广大的研发工程师，能够从多角度、全方位，来看研发效能提升这件事情。在日常的研发工作中，能够持续地关注价值、保持专注且目标明确。
全文思维导图
（可点击图片，放大查看)
便于快速回顾、梳理全文，抓关键点
这里再来思考下，之所以对同一件事情，管理者和工程师，分别有着不同的理解甚至冲突，有时候甚至都认为对方在拖后腿。到底为何才会如此？
我想，就是因为双方的视角不一样，管理者更关注全局有时候忽略了细节，工程师专注于细节而常常缺乏全局思维，这样就会造成双方努力方向有偏差、前进的步调不协同。
而反观一些高效能的团队和个人，往往都能实现个人和整体的良好协同，并能够最大化利用先进的流程和工具。“道长且阻，行则将至”，无论你工作中是何种角色，让我们一起探索研发效能提升之路。
今天的分享到这里就结束了，希望今天你可以有一定收获。如果对今天的内容有共鸣，也可以分享给你的朋友。我们可以留言区里一起继续交流、讨论。
THE END
转载请联系ITPUB官方公众号获得授权
—————————————————————————————————
