解决技术债务问题的五个技巧

CIOAge
许多CIO已经开始专注于寻找削减技术债务的方法。经验丰富的技术领导者也分享了他们用来控制技术债务的五种策略。

数十年来,CIO们一直在与技术债务作斗争,但许多人仍未能充分管理它,这也让他们付出了惨重的代价。

管理咨询公司Protiviti在其《2023年全球技术高管调查报告》中调查了1000多名技术高管,结果发现,对于高达70%的受访者来说,技术债务是企业创新的主要障碍。高管们还报告称,技术债务消耗了31%的IT预算,且占据了21%的IT资源。

LeanIX发布的《2023年IT成本优化调查报告》也有类似的发现,56%的受访者表示,过时的技术和技术债务是浪费IT预算的主要原因。

与此同时,成功管理技术债务的IT领导者能够助力其企业表现得更好。根据研究和咨询公司Gartner的说法,积极管理和减少技术债务的基础设施和运营领导者可以将业务服务交付时间至少缩短50%。

鉴于这些发现,许多CIO已经开始专注于寻找削减技术债务的方法。经验丰富的技术领导者也分享了他们用来控制技术债务的五种策略。

1、分析衡量你的技术债务

信息技术研究集团(Info-Tech research Group)基础设施和运营实践研究主管Andrew Sharp是技术债务编目的强烈支持者。分析师建议IT领导者建立一个关键技术债务的清单,了解债务的业务影响,并有一个处理它的过程。

他认为许多CIO往往在这三个基本问题上做得不够。最大的挑战之一就是理解和组织技术债务的范围。由于技术债务会蔓延到不同的系统中,并产生连锁反应,所以对于IT团队而言,了解技术债务的数量和影响确实是一项艰巨的任务。

Sharp表示,就像当今业务中的大多数其他事物一样,如果不进行衡量,债务就永远无法得到成功管理。IT部门需要更好地识别、跟踪和衡量技术债务。

他表示,“IT部门总能感觉到问题出在哪里,但往往缺乏正式的分析。我认为,用结构化的方法来看待这个问题,可能是思考以前从未考虑过的事情的一个机会。因此,我们不仅要知道我们有问题,还要知道问题是什么,并了解其影响。在此过程中,可见性真的很关键。”

不过,Sharp也告诫称,不要追踪每一笔技术债务,相反地,必须要去追踪打算修复的债务。

Progrexion高级副总裁兼CIO Ken Knapton也谈到了了解IT部门累积债务细节的重要性。

为此,他和IT团队开发了一种衡量债务的方法。他们根据关键技术属性(可支持性、预期剩余寿命、稳定性和跨度)以及另外两个属性(业务关键性和战略一致性)对债务进行评级。他们将四个关键属性的和乘以后两个关键属性的和,然后将值规范化为0到1之间的比率。

Knapton表示,任何评级在0到0.4之间的技术债务都是可以接受的,任何评级在0.5到0.7之间的都是令人担忧的,而任何高于0.7的都是严重的。

他补充道,“现在我有了一个衡量技术债务的框架,我们能够跟踪它。如此一来,我们便能够专注于要解决技术债务的哪一部分,以及我们现在要做什么。”

2、通过在路线图上优先偿还债务

Knapton表示,他亲眼目睹了不及时偿还技术债务的代价。

他指出,在过去的一起事件中,一个开发团队使用了Java库,但出于时间和上市速度的考虑,没有返回更新的代码,这通常是负债的核心原因。这个决定虽然在产品的初始开发和部署时是合理的,但却阻碍了团队后来添加更新或进行所需更改的能力。

Knapton清楚地认识到,如果后续不再重新考虑临时决定的话,那么当初的临时决定就会成为持久的存在。技术债务就会因为得不到及时偿还而不断累积,使企业丧失灵活性。

Knapton补充道,“现在我们衡量它,管理它,并认识到,如果我们要承担一些技术债务以率先进入市场,我们必须坚持到底,并在发布后及时偿还这些技术债务。”

为了确保这些债务能够偿还,Knapton及其团队知道“必须在时间表中加入管理和解决问题的能力。” 为了支持这一点,Knapton的团队(他们在整个IT部门以敏捷的方式工作)已经将“减轻技术债务”定义到了项目“完成”的标准中。

Knapton指出,“直到回头调整所承担的技术债务,一个项目才算真正完成。在缓解工作完成之前,技术债务是团队积压工作的一部分。我不希望一个暂时的解决方案变成永久的,所以我们把它正式列入了我们的路线图。”

其他人同样主张分配资源(时间和金钱),并为处理债务建立问责制。例如,Sharp谈到了“改进对项目价值的验证,了解并密切关注漏洞,为维护和所需的任何新设备制定预算。” 他补充道,但很可惜,数量惊人的企业并没有这样做。

3、将技术债务视为业务风险

微软数字应用创新专家Enoche Andrade曾就技术债务问题向高管提供咨询。他表示,技术债务不仅是IT行业的问题,同时还具有业务、财务和安全方面的影响,这也是一种业务风险。

因此,Andrade认为,技术债务是所有高管和业务职能负责人的事情,而不仅仅是IT部门的问题,关于何时和如何偿还技术债务的决定应该与业务战略和业务需求保持一致。

他表示,“CIO肩负着提高董事会和领导团队对技术债务的认识的关键责任。为了培养一种关于技术债务的意识和问责文化,公司应该鼓励跨职能团队,并建立共同的目标和指标,鼓励所有团队共同努力解决技术债务和促进创新。这包括为开发者创造一个安全的环境,让他们可以尝试新的方法和技术,从而实现创新和持续改进。”

Knapton认同在决定何时承担技术债务、衡量其影响和优先偿还哪一部分债务的时候,需要业务部门参与其中。

4、承担新债务时要谨慎

哈特曼行政顾问公司(Hartman Executive Advisors)CIO Mike Huthwaite将技术债务与金融债务进行了比较。他表示,“对我来说,债务是你产生的,然后你来解决。”

Huthwaite解释称,就像有时承担金融债务是明智的一样,选择技术债务通常比不选择技术债务更明智。像其他人一样,他认为团队可能会为了速度和敏捷性而决定承担技术债务,毕竟市场优势超过了技术债务的成本。这是一种权衡,如果继续以个人债务为类比,在某些点或某个决定中,负债是有价值的。但它本质上仍是债务。所以希望你以一种谨慎的方式来做这件事。

Huthwaite建议IT团队在承担技术债务时要慎重考虑,权衡使用次优代码所获得的好处以及这个决定的负面影响。他称之为“有意的”(intentional)技术债务,而“无意的”技术债务则是未经深思熟虑而产生的。

Andrade也给出了类似的建议,他表示,尽管企业不可能消除所有的技术债务,但他们可以采取措施限制技术债务的产生(特别是无意债务的产生)。

他建议团队采用敏捷开发方法、重构、自动化测试和简化流程。团队还应该使用代码分析工具来识别技术债务,并由同行和涉众定期检查代码,以确保代码质量并识别潜在问题。它们还应该包括体系结构的简化、组件化和标准化。

5、认识到债务管理是一个持续的过程

全美农村电力合作协会CIO兼IT高级副总裁Wayne F. McGurk并不认为技术债务是一件好事或坏事,而是“开发过程的自然结果,因为正在建造一些新东西而产生。”

他表示,“人们倾向于尽可能快地获得最有价值产品,而不必在一开始就构建一个过度工业化的应用程序。”团队会做出权衡,选择适合MVP的技术,但他们知道,随着解决方案的扩大,这些技术是不够的。

因此,McGurk不仅将这一因素考虑到他的开发周期中,还将其考虑到IT运营中,引入各种策略来创建一个持续管理技术债务的整体方法。作为这种方法的一部分,McGurk的团队记录并详细介绍了任何新的技术债务的引入,然后通过组织的票据系统跟踪这些债务,以便IT团队可以将其全部提取出来并报告和查看它。

McGurk还考虑了每一项技术债务如何在五个关键领域影响运营:简单性、灵活性、连续性、安全性和透明度。

他解释称,“当技术债务开始阻碍这些运营原则中的任何一条时,它就上升到了我们需要解决的水平。”

McGurk及其IT团队考虑影响的级别、对企业的风险,以及企业的总体战略,然后优先考虑需要注意的事情。之后,他们让这些决定为人所知,从而在整个企业中创建对主题的可见性。

McGurk表示,所有这些都被纳入其IT部门的工作流程,这确保了技术债务的管理不会被视为一次性项目,而是以持续的方式进行管理。例如,他的Scrum团队需要确定新的技术债务,并决定何时以及如何解决它。

他解释称,“你必须建立一种负责任的文化,让你的团队知道,仅仅因为一个项目交付了,它并没有完成。这是一个旅程,没有终点,所以它需要成为你需求管理策略的一部分——既要处理新工作的需求,也要处理遗留工作和技术债务。”

责任编辑:姜华 来源: 企业网D1Net
相关推荐

2022-05-30 10:09:27

技术债

2020-03-30 09:58:16

IO技术债务

2019-10-24 10:04:33

技术债务开发软件

2023-04-14 15:07:05

架构开发自动化工具

2024-01-03 14:52:15

数字化转型

2022-02-11 09:00:00

技术债务数据工具

2022-05-27 10:13:51

IT领导者CIO

2022-04-19 10:23:59

技术债务IT解决方案

2021-05-26 14:44:52

VRVA虚拟现实技术

2022-04-06 10:09:17

云服务云计算

2022-02-10 10:23:48

软件开发商技术债务记录数据

2022-07-03 06:26:53

JetBrains插件

2011-03-25 13:26:45

Cacti

2023-08-18 15:12:00

JavaScript开发

2022-08-12 08:51:51

CIO会议

2022-03-12 09:55:09

安全误报SOC

2023-08-11 17:16:57

AI API人工智能

2023-03-03 13:42:45

2023-05-15 07:06:36

2012-05-09 09:25:19

云计算云服务中断

51CTO技术栈公众号