美文网首页
“技术债与业技融合”

“技术债与业技融合”

作者: 清水舍 | 来源:发表于2022-07-07 15:39 被阅读0次

    前段时间麦肯锡推出了一项新的技术服务(见右图),通过“技术债评分”量化企业技术债务并和同业进行对比。

    通过“技术债评分”量化企业技术债务并和同业进行对比。

    由此引发了我们公司的人进行了一些非常有趣的讨论。

    技术债可以看作是软件研发过程中不良设计带来的软件额外修改成本,随时间推移产生利息。

    具体的表现可能是“架构的频繁重构”、“需求交付过程中不同团队高额的沟通成本”、“由QA人工补偿的自动化测试”等等。

    那么,如果技术债能够量化,是否也可能用经济化的手段来解决呢?

    当然,从纯粹意义上说,要把技术债的成本换算成钱,得知道逼近最佳设计的成本,再用当前成本减去求差。且不说这个过程中数不清的变量怎么计算,单是知道什么是最佳设计本身就难以成立,这个结果是在多变的商业环境中迭代摸索出来的。

    “技术债”在实际交流中更像是一种隐喻,以促使团队在开发过程中意识到有这个问题,能投入去避免或者解决。只要可以促进提高自己的编码和设计水平,就足够了。

    但是当进行技术管理或者业务方对开发质量、进度有要求时,技术与业务之间结算的需求优势客观存在的。

    接下来的讨论里,我们可以换个词,用“交付债”来避免歧义。

    近几年业界大量讨论“业技融合”的模式,就是因为传统领域企业进行数字化改革的时候,技术研发很难为业务结果负责,而业务部门又无法对技术领域进行管理。

    (互联网公司相对来说少见这个问题,是因为对互联网产品来说,产品部门本身既是技术部门又是业务部门,当然,他们的类似问题就会体现在前台团队与中后台团队的摩擦上。)

    在“业技融合”的场景里,我们来类比前面提的三个条件,看看分别又面临什么问题?对业务部门来说:

    开发资源是稀缺资源,某些产品/业务的数字化为公司带来的资产更多;但在规划阶段,哪些业务/产品更有价值,无法量化;

    不同业务部门需要争夺开发资源,但往往缺乏决策依据,最终往往是领导拍板;

    向技术部门的投资能为业务部门带来的好处,但业务部门难以感受到,也缺乏结算方法。

    在企业管理领域,上述问题也是盘根错节的常见问题,那么让我们看看前面案例总结的理论是否能一定程度上提供帮助?

    假设不同交付团队在承接需求时,都向业务部门发售一定额度代表开发成本、质量的交付债;到期交付后,如果出现延期、质量问题,则计入“违约记录”,并继续发布债务直至业务侧验收;

    对业务侧团队来说,交付债的价值不由成本计算,而是以带来的业务价值计算:

    业务团队需要在规划阶段定义好衡量该上线功能的业务价值衡量方法,如果达标,则债务成立。在季度/年度财务核算时,将所有成立的债务以一定比例核算,作为业绩的财务收入分成作为技术团队奖金,该比例与“交付债占公司交付债整体数量”的比重正相关;若不达标,则成为废债,仅记入成本,技术团队没有奖金分成。

    开发团队间则用devops记录追踪过程数据,结合“违规记录”,进行横向对比;比如一个迭代,开发了多少个故事卡、达成多少验收标准、有多少条“违规”、有多少交付债是由于技术债导致额外增加的?

    对开发团队来说,交付债的债务价值是放到一个迭代周期里,由不同团队间数据结果对比出来的;技术领导参考数据表现,从“数据牵引团队协作变化”的角度,分配奖金。(奖金来源于上文中的业务收入分成)

    当然,为达成上述理想状态,组织也需要允许业务团队与技术团队双向选择。

    对业务团队来说,不同技术团队的债务价值不同;交付结果质量越好,稀缺性越强;迭代越快,交付越快,流通性越强;越受业务团队认可的技术团队,其交付债溢价越高。

    对技术团队而言,不同业务团队的优先级也有所不同,更能带来业务成效的产品设计越容易获得开发团队的支持和认真对待,因为业务成果决定其奖金。

    再回过来看前面提到的三个问题:

    在规划阶段,将需求描述的越清楚、成功标准定义越清晰、团队信誉越强,越能获得开发团队资源的倾斜,且产品上线后的业务数据作为后验指标加强其团队信誉;

    不同业务部门需要争夺开发资源,可以通过购买“交付债”的多少来进入优先级,技术团队也会在交付债多少与达标后成立的交付债间做权衡;

    技术项目立项的价值验收,也可以通过降低团队“交付债”总支出的角度做衡量。

    这种机制的设计,不仅让团队在双向选择的过程中,打破部门墙,做到业技融合

    同时还可以牵引团队把实践做标准。(业务的需求分析要更精细,才能获得技术支持且降低交付债投入;技术团队的技术实践要做更好,才能降低交付压力,且获得更多的业务分成)

    另外,对交付债进行财务核算,再与之和“软件所达标的交付债总量”做结合,还能一定程度上解决软件资产化的问题。

    “业技融合”的问题表面上是企业部门墙的问题,但实际上是传统企业传承自工业时代的管理方法论:只善于从“成本”角度进行财务核算,而缺乏对产出价值度量的方法。而正如前文讨论的那样,进行数字化转型的过程里,就是逐渐用「迭代生长的数据体系」来核算价值。

    数据体系是新型货币,数据的生产方式和对比,是该货币体系的锚定物。(从哲学上看,货币价值取决于信任关系,数字时代的信任关系由数据洞察和逻辑构建。)

    小结:

    步入数字时代,协作的频率和节奏都在加强,也就对结算的高效性和有效性有着更高的要求,数据体系可以形成这种结算机制是因为:

    稀缺资源对不同人来说,产生的价值有所差异,数据体系能让这种差异化显现;

    数据体系的指标设计只是让协作有了靶子和目标,市场驱动的运作机制才是落地的保证;

    以数据体系形成的虚拟结算,需要对接财务体系动态调节资源价值,以获得市场共识;

    上述三点即是这是“新型货币”的特点,也是构建过程中对能力的要求,反映着数字时代社会的另一关键变化:

    社会需要从工业化时代依赖「成本核算的财务系统进行成本管理,向数字化时代使用「迭代生长的数据体系进行价值管理」做转型。

    (本章探讨的更多是社会需要以数据体系辅助结算,讨论的是业务方案,区块链等技术的应用场景,会在后文有所展开。)

    相关文章

      网友评论

          本文标题:“技术债与业技融合”

          本文链接:https://www.haomeiwen.com/subject/qxdpbrtx.html