“技术债与业技融合”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小结:

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

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

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

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

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

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

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,922评论 6 497
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,591评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,546评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,467评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,553评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,580评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,588评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,334评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,780评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,092评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,270评论 1 344
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,925评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,573评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,194评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,437评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,154评论 2 366
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,127评论 2 352