作者：DevOps阿伦

　　来自：DevOps探路者

　　6.2、解决技术债的管理

　　在工作多年之后，我常常发现，解决问题的方法在问题体系之外，在技术债这个问题上，也是一样。当你计划去解决技术债的时候，会发现最需要协调的资源、支持往往都不是不是技术方面的问题，而是管理层的理解和支持。

　　然而，技术债的处理是一线的问题，管理层们离一线都很远，为了让管理层们了解技术债是什么、为什么会出现、会有什么样的影响、打算采取怎样的措施来解决技术债、需要依赖哪些资源，我们通常需要编制PPT、上会、请示、跨团队甚至跨部门的反复沟通协调，这个过程中要反复修改资料、斟酌话术、化解纠纷、平衡利益，很多人因为不堪忍受这个过程，抱着“反正我跟你们说过了，你们不理解不重视，我也没办法”的心态，放弃了解决技术债。

　　理想的情况是这样的，从一线到高层，从主建团队到相关方，每个方面都能够快捷、准确的了解到技术债的影响，而这依赖于以下这些艰苦的工作。

　　6.2.1、数字化转型

　　所有的企业都想做数字化转型，然而市场上能够称得上个成功的实践，近乎于无。这一方面在于缺乏衡量数字化转型成功的标准，一方面也在于这个事情本身也是极难的。

　　数字化的前置条件是自动化，自动化的前提是线上化，线上化的前提是工具化。这个依赖链条是不可逆的，也是不可跳跃的。经常见到企业的工具还没有成体系的打通，数据没有完成关联，就建了好多数据录入页面，让员工们额外付出很多的时间去录入数据，然后对数据进行加工、分析和输出决策建议，美其名曰精细化管理和数字化转型，这就是典型的从工具化直接跳跃到数字化，不仅不会形成真正的数字化，反而会加重一线的工作负担，降低数据质量，最终输出的决策支撑也是虚假的。

　　回归到技术债这个角度，数字化带来的好处就是，可以准确度量技术债的收益、成本和影响范围。通过将代码、需求、系统、版本、生产监控数据进行关联，可以由生产问题上溯至具体哪一行代码，也可以准确评估影响，将这些数据通过图表进行可视化展现，即使不懂技术，也能够知道技术债的相关信息。同时，基于数字化带来的数据一致性，从任何维度去看，数据基础都是一致的，由数据产生的共识也可以达成一致，从而避免在技术债问题上的扯皮。

　　6.2.2、高效的反馈循环

　　信息科技企业有个一直以来难以解决的痛点：如何准确评估科技工作创造的价值。这个问题放到技术债上来看，一般情况下也无法准确评估技术债所能带来的收益和风险，也就无法去做好事前控制和风险规避。在解决这类问题上，DevOps的反馈循环理念是一个比较有效的解决方案，其思路就是，我无法准确评估影响没关系，只要我发现问题、解决问题的速度足够快，影响和风险就追不上我。通过时刻监控生产环境所产生的运行数据和业务数据，当发现数据异常时，第一时间自动回滚至稳定版本，并迅速形成事件卡片同时反馈至相关方，然后根据研发交付数据链上溯至代码层面，去制定解决方案，所有暴露出来的技术债都会以最高的优先级在第一时间得到解决，绝不拖延。

　　在DevOps的反馈循环中，所有的问题都可以实时反馈、准实时解决、持续跟踪，从而是问题不断得到解决，不断减少，最终让问题逐渐消失。

　　6.2.3、低成本决策支撑

　　传统管理模式下，管理者对企业发展的认知来自于下面的员工和管理者逐级上报，而在此过程中，每一个层级都会基于自身的诉求对信息进行一番加工，管理者离一线越远，汇报层级就越多，信息被加工的就越多，了解的情况距离真实情况偏差就越大，这种情况我称之为管理信息失真。

　　同时，我们要相信大部分走上高管位置的都是聪明人，他们对于这种失真都是有感觉的，所以在做决策的时候，他们会从多个渠道去获取信息，进行交叉验证，力求获取企业经营的真实情况，来为自己的决策提供支撑。这个过程对于管理者是必要的，但是客观上，成本非常高，而这些成本也会逐级分解，变成员工额外的工作负担。

　　只有自动获取企业的经营数据，自动汇总加工形成面对各个层级的数据分析结果，才能将所有人从这场互相愚弄、互相伤害的数据游戏中解脱出来。所有人都可以在自己的权限内对数据进行查看、使用和挖掘，这样才能对于管理者的决策提供低成本的数据支持。在这个大范畴下，将技术债作为一个决策参数，纳入决策模型，才会比较有效的避免出现降维打击的技术债。

　　6.2.4、还债常规化

　　除了提高数字化管理水平外，要从管理上将解决技术债作为一项常规工作进行管理，无论是每个迭代阶段固定投入成本解决技术债，比如20%税；还是集中所有资源，定期拿出一个版本的时间来突击解决，都是可以采用的方法。但无论如何，我们会发现解决技术债需要较多的资源，而由下向上的申请资源来进行专项解决技术债，其难度往往令人望而生畏，更何况将其常规化。要从管理层面重视技术债，万不可积小病为大病。老话讲：上有所好，下必甚焉。中国的传统文化映射到企业管理中，必然需要上位者的重视，下面才会更重视，如果管理层对于技术债没有概念，那么下面对于举债工作肯定也没有压力，只有管理层的目光投向技术债，举债才会慎重，只有管理层日常关注，还债工作才会比较容易获得相应的资源，从而常规化。

　　6.2.5、测试驱动开发

　　测试驱动开发的概念我就不再赘述了，这里简单分析一下为何测试驱动开发的概念在业界已经提出了多年，但是落地者少。究其根本，无外乎测试左移就代表着成本左移，而收益仍然后置，很多组织在试行一段时间后，没有见到收益，只见到了成本的激增，就放弃了。传统的管理模式中，研发交付过程是个长链条，控制研发过程和成本消耗是重点，而成本分摊在研发各个环节中，有利于管理整合看清成本的消耗进度，并方便进行收益转化率的计算。成本左移之后，中间有相当一段时间是空档，成本分布不均，变现为收益时间长，容易让管理者心里没底。

　　如微软、Google等业界顶级实践证明，测试驱动开发确实是一条行之有效的路。相比传统开发-测试模式，传统模式是双向双车道的话，那么测试驱动开发就是双向八车道的高速公路，然而，即使知道高速公路好，但高速公路投资高，工期长，回本慢的特定，仍会让很多企业选择继续走小路。

　　那么促进企业修高速呢，或者退一步，修个国道呢。那就是一定要让企业管理者见到成本左移的收益，见到因为测试驱动开发减少了技术债而降低的返工成本，这一点要跟数字化转型、反馈循环等结合使用。注意，企业是以盈利为目的，越是股东众多的企业越是追求短期利益，你如果没有办法短期内让经营者看到成本下降或利润上升，那么你的所有诉求都不会得到资源支撑。

　　6.2.6、产品制转型

　　在传统项目制的企业中，解决技术债是非常困难的一件事情，这里的困难不是指忍无可下突击解决，而是将之常规化。因为项目制的本质追求的是资源的高效利用，在这个前提下，多、快、省才是项目制所追求的，好的优先级会直线下降【此处可能会有项目经理的同学不认可，但可以放到实际场景中验证一下，工期紧张、资源紧张、需求固定的情况下，你是选择追加资源、延长交付时间或缩减需求以保证交付质量呢，还是牺牲质量以保证在现有资源下按时全功能投产呢】。同时，项目制配套的投策决策机制、组织结构设计都是在服务于企业内部，解决钱不能乱花的问题，而不是在解决是否为用户提供了价值的问题。只有转型为产品制，以优质的产品为经营核心，才会将技术债这个事情重视起来，因为这时技术债是经营的最大难点之一。

　　如何进行产品制转型，这是一个非常大的话题，而且产品制转型应该属于企业治理范畴的工作，但我不打算为治理单开一节，因为来看这个文章的大多数人，可能对治理是什么都不太感兴趣，所以，在这里只是简单的说一下需要转型，后面我可能会单写一篇企业治理和科技治理的文章，或者那是可以专门论述一下产品制转型的问题。