认清它，承认它，然后改变它。
1. 前言
原本以为三部曲之后，相关的话题算是有了个结论。但恰恰相反的是随着输出总结的增加，再次审视当下的研发流程，发现相关人员存在非常大误解。
其中比较典型的误解就有：
- 我这每天忙得喝水时间都没有，这效率还低得了？
- 相较于以前，我们现在已经形式了基本流水线式的分工协作，这效率还不高？
- 问题解决慢是因为人手不足导致的。
2. 先回答问题
- 忙不等于效率高。
这个观点，说起来都认同，但实际执行起来就完全两码事。
坐那神经高度集中，喝口水的时间都没有，同样的工作今天做了明天接着做，第一次解决时候花费一周，第十次解决的时候还是需要五天；然后同样的问题换个团队成员又是从零开始摸索，花费甚至更长的时间；凡此种种，你说这种忙，除了感动得自己之外，它的有效价值能够有多少？哪个冤大头又会愿意为此买单？
另外一个例子就是，需求来了，哎呀限期一周，时间太紧张了，赶紧代码敲起来，不然又得加班了。于是需求大概瞟一眼，"哪有时间看那么细致，做到那里了再说吧"，另外沟通也太耗时了，有什么疑问就直接按照自己认为的方向做就行了，甚至根本不会意识到这个点会存在疑问。
最后到了要交付东西的时候了，这怎么能不是你要的呢？ 我就是按照你的要求做的啊，期间我这还加了两次班呢。 最后就只能让领导出面和客户协商再宽限几日，然后研发这边加班加点地重新实现。
确实很辛苦，但是，这效率高吗？
- 由三十分优化到现在的六十分，看着确实进步不小，能够想象到做出这样的改进，各岗位人员，尤其是关键节点人员，付出的辛劳肯定不少；但是，这和效率高没有半毛钱关系，毕竟你这也就是刚刚及格，上面还有着相当的进步空间。
我们团队确实刚经历过一次这样的优化，现在还对当时改良期间压力最大的那段时间心有余悸，不过好在最后走出来了。
相较于我们过往的团队，研发效能确实有了一定提升，如果只是以自身为参照物，可以说是提升巨大。但是正如初中学过的《资本论》里“商品的价值由社会必要劳动时间决定”， 你觉得自己能牛逼那没用啊，你最终还是要和整个行业平均进行比较。
- 人手少不是问题解决太慢的原因。
首先明确下这个"问题解决太慢"的含义：问题整体数量多，消化慢，甚至出现问题出现的速度快于修复的速度，蓄水池水位不断上升的情况。
很多人，包括不少领导认为问题太多，解决太慢是因为人手不足导致的，但在多年的研发经验，实际观察下来，我始终无法苟同类似的观点。
诚然，增加人手在直觉上可以加快进度，而且在实际中也确实发生了无数次这样的场景。但是，如果仔细回顾和复盘，你就会发现这类场景通常是业务比较简单，系统维护时间较短，中途介入的人需要了解更多的前置知识就可以上手。
软件开发不是搬砖，十个母亲不能在一个月内生出一个孩子。
而且更重要的是我们是不是要思考下：解决问题太慢会不会是应该解决问题的效率太低了?
- 正如上面已经论述完毕的：不是说你忙到喝水时间都没有就是效率高。
- 一个问题花费三天时间解决和一个问题花费半小时解决，这两者有着云泥之别。
软件问题调试这块存在一个共识："解决问题简单，但定位问题很难"。这也是为什么现在的云原生里如此强调"可观测性"。
如何缩短问题解决慢的问题：
- 不断加强系统的"可观测性"，除了在系统设计之初，根据过往经验和业内的最佳实践加入对于可观测性的架构考量；也需要在系统的实际迭代过程中不断增强其可观测性，增加系统透明性。
- 持续强化针对问题定位的反馈环执行效能。这里举个最近发生在我身上的例子。在接到问题报告，明确问题表现后(这其中还经历了一次X-Y问题)，第一轮反馈环从上午十点一直到下午四点才完成，耗时六小时。也就是说如果按照这个效率，第二轮反馈环到下班都是无法完成的。试想在这样的反馈环周期下，问题解决的效能怎么高起来？五分钟的反馈环周期和一天，甚至一周的反馈环周期，两者之间有着千万倍的差异。
- 至于如何加快问题反馈环效能，除了上面所说的基础设施完善，系统架构优化，还有相关的人员技能培养也是应该被逐步规范化，流水线化的。
3. 补充一些现状说明
上面的误区一里，我们主要是从个人角度去探讨研发效能，但其实站在整个团队的角度，传统软件行业也存在着一个非常隐蔽的，导致大量研发效能损失的问题 —— 研发小组的各自为战，以及基础设施的缺失导致研发人员宝贵的时间和精力被大量消耗在所谓"技术难点解决"，以及基础依赖环境维护等细枝末节上。
3.1 "技术难点"？
首先，传统软件公司很难有所谓的技术难点。
其次，这里所谓的"技术难点"，基本只能算是对于当事人而言之前没有接触过，如果站在整个研发团队层面，就会发现其实类似问题，已经解决过很多次了。
但因为团队缺乏相关的沉淀，分享的制度和氛围，小组之间各自为战，导致整个团队始终在低维度问题上循环反复，疲于应对项目工期，无法对问题做进一步的深入；组长觉得研发团队效能低，组员又觉得团队技术low，进步慢。各方都对现状不满，相互抱怨。
研发人员需要耗费大量精力在这些所谓的技术难点上，工期又那么紧张，那沟通上当然能推就推，毕竟功能没实现出来是一眼能看出来的量化标准。
但缺乏沟通导致最终结果不满足最终要求，你能拿我咋滴，我还说你需求表诉不清楚，另外一边人不行，不配合，你确定在用户追着屁股问进度的情况下，你要和我掰扯为什么沟通不畅的问题？
3.2 基础设施缺失
很多时候，我在团队里强调"基础设施缺失"概念的时候，组员甚至领导的第一反应是：我们机器确实不足。
缺乏足够的机器资源确实是基础设施缺失的一个很大的方面，但是如果将问题始终归结于这种短期内很难有所改进的现状，这不是个想要解决问题的态度。
-
基础设施缺失的一个表现是，对于传统软件行业技术团队而言，面对复杂的业务特点，经常出现一个人要应对多个项目的情况，经常需要和多种设施对接的情况，例如ftp，各类数据库，oss，短信服务等等。
研发人员在遇到类似需求的时候，经常无法得到团队层面的支持，甚至这些依赖的下载地址都得自己去找，于是不知道从哪个犄角旮旯找到个版本，然后自己找台机器，甚至就只能在自己本机上安装，然后还要自己去寻找相关的对接操作手册（嗯，这个问题又回到上一个"技术难点"）。
如果一切顺利，那么本机测试通过之后，生产环境上也通过；但现实往往不会如此完美，经常出现的一种情况是研发找到的版本和实际生产环境版本不一致，或者安装配置方式有差异（最典型的就是数据库的编码），导致或者本地测试始终诡异失败，或者本地成功的版本，在生产环境下始终无法成功。
这样的操作只要来个两回，对行业或公司多大的热情都能给浇得透心凉。毕竟整场复盘下来，和所谓技术成长，能力提升，问题解决没有半毛钱关系，有的只是一个人孤军奋战，被小水坑折磨出面对汪洋大海的挫折感。
-
基础设施缺失的另外一个表现就是CICD基本为零，这导致研发团队基本都是研发运维一担挑，测试阶段的版本控制(如果有的话)，安装部署，更新替换，配置更改等等都是研发人员你就自己来吧，所以那些惊为天人的class文件替换，本地环境配置和测试环境配置使用同一套等等基本也就是情有可原了。
在这样的研发测试环境下，明明更新了代码但问题表现还是和之前一样，这样的幽灵问题就并不是什么新鲜的事情了。
试想在这样的氛围下组织起来的团队，你怎么能去奢望所谓的集体荣誉感，团队氛围良好？
4. 突破
以上背景下，我们要从行业认知，职责确认，基础设施搭建等多个维度发力。
4.1 实际的开发中，编码工作量只有1/6
以上结论来自《人月神话》。
首先，需求反复导致的编码过程反复，这里的工作量只有1份， 而不是 1 + 1 + 1 + .... 。
前期偷懒不进行需求详细了解，上来就直接干活导致的编码反复，这不应该算在编码工作量里。
传统业务型软件公司项目特点很大部分都是前期需求不明确，这个是现实，在编码时依据经验多想一步（注意这里的量词），或者按原型方式编码；至于你说我哪能想到云云，公司按照工作经验评定职级，所看重不正是这个吗？另外我们从来没未奢望谁可以第一次作到胜任，毫无改进的重复才是最不被容忍的。
然后就是架构设计时，编码工作量的多少不应该是被主要考虑的问题。但根据过往的经验，喊声最大的就是这些研发人员，这些声音会给架构师常常造成困惑，虽说代码越少，BUG越少；但代码量多少不应该成为架构是否合理的重要指标，架构的重点是落脚于公司的实际业务情况，来进行相应的抉择和各要素间的平衡。所谓代码量问题，完全可以通过代码生成器，二方库等进行补充。
4.2 一个问题：中层技术管理者的责任是什么，应该做什么？
除了技术上的沉淀，以及架构上的不断迭代外，另外一个我们需要重新审视的问题：中层技术管理者的责任到底是什么？
所谓的“技术难点突破，培训新人，对结果负责”等等这些说烂的词这里我不想再嚼甘蔗渣。以下我想要重点强调的是一个我们隐约能够感觉到，但实际执行时却经常置之脑后的职责 —— 想尽一切办法提升研发人员的研发效能，极力避免他们在必要工作之外的精力分散。
上面说法比较抽象，让我们来定义一下必要工作：理解业务需求，将业务逻辑转换为代码。
上面这种说法依然有点抽象，那么让我们再具体一点，理想情况下，假设现在有一个对接阿里云OSS的需求，相应的业务研发人员需要怎么做？
- 从团队提供的研发测试资源管理页面，找到团队预先购买好的阿里云OSS测试账户和密码。 这个过程耗时一分钟。 （相对应的，我见过不少团队里，从阿里云账号申请，资源购买都是当事组员自力更生，然后下一个组员继续）
- 从WIKI中找到部门沉淀的附件操作二方库，在入门操作文档的指引下，完成对于阿里云OSS的业务对接。这个过程耗时半小时。（相对应的，依然是组员自行寻找阿里云OSS的 API文档，然后对照着文档一个个坑地这么踩过去，完成对接）
- 该组员将上一步中二方库的使用心得，以及相应操作文档感觉不完善的地方，在相应评论进行回复，给后来者以提示。（相对应的，我这孤军奋斗搞出来的东西，现在只是看着像实现了，我自己心理都没底，还想让我沉淀，这从零开始写篇文档多费劲，你给钱吗？）
依然以上面的例子引申，在上述理想操作流程之下：
- 研发测试资源管理页面（也就是所谓的资源黄页）以及背后提供支撑的一系列资源。
- 附件操作二方库的发起和迭代，相应使用手册的维护，组件的宣讲培训等等。
以上这些，都是中层技术管理者的责任，而且除此之外，CICD以及周边一整套诸如版本管理，版本发布等等，也都是需要中层技术管理者在实践中不断实践和演化的，总而言之，组员的研发效能是非常关键的考核指标。如果只想着“我把任务分给你了，除了上交成果外，其它的问题你都自己解决，别来烦我”，这样的技术管理者无疑是非常失职的。
只有如此，团队向心力，凝聚力，团员幸福感才不至于是无根之水，才能最大程度地维持住团队梯度的稳定性，不至于组员离职造成整个业务的剧烈震动。
5. 应该什么样？
让我们汇总下，一个新入职的业务研发人员，应该是如何适应团队：
- 一个月之后，任何新人只在业务理解上需要询问别人，其它绝大部分技术类问题都可以自行从部门的知识库中找到答案。
- 研发人员主要精力应该在理解业务上，不应该太多的任何技术难点需要解决。
- 除了理解业务和将业务逻辑转换为代码，其它的都不需要关心。什么打包，发布，版本管理，下载，部署，都已有一套标准化的流程，提交代码之后，整个流程会自动生产相应的制品包，测试通过之后纳入制品版本管理系统，供各方下载使用。待使用出现问题时，借助禅道等管理平台开始下一轮迭代。
- 对于生产环境下反馈的问题， 80%都应该在运维层面就被解决掉，只有剩下的20%问题踩能击穿地方运维，售后，测试构筑的层层防护网，达到研发这，并且这20%问题下次就会变成前80%问题。
6. 参考
- 作为中层领导，你要做的是盘点/整合资源，让下属有活干，成就他们，帮助公司提高基层员工的工作效率。
- 为什么国内开源氛围这么差？大厂都在卷自己的轮子？ - 为解决自己在特定场景下的某个问题写一段代码很容易；为解决大家在多种场景下的某个问题写一段代码真踏马烦。
- 能大规模商用的技术，都不需要智商，否则这种技术就不可能规模化。
- 传统软件行业中技术团队的发展(现状篇)
- 传统软件行业技术团队的发展 - 做好技术栈统一
- 传统软件行业技术团队中如何做好知识沉淀
- 《软技能2》读后感