美文网首页
面向价值编程:Why, What, How

面向价值编程:Why, What, How

作者: 泊浮目 | 来源:发表于2022-11-12 12:14 被阅读0次
    版本 日期 备注
    1.0 2022.9.19 文章首发

    本文首发于泊浮目的掘金:https://juejin.cn/user/1468603264665335

    0. 前言

    从2021年,各个大厂的反内卷,再到2022年的裁员,大多数人都意识到互联网行业进入了寒冬。其实并非这个行业如此,其他的行业也正在严寒中苟活。宏观原因其实显然易见,但这并非本文讨论的主题。在这里,更想和大家讨论的是如何在这个冬天苟活下来。

    这些现象后面折射出了一些信号:

    • 反内卷:有关业务发展已经到达瓶颈,甚至产生无意义的内耗。
    • 裁员:有关业务可以用更少的人来维持发展,甚至不发展。

    这里面最终都指向了一个东西——钱。

    1. 为什么要面向价值编程

    许多同学当初从事这个行业是为了高薪,但大家有没有想过为什么老板愿意付你高薪?自然是因为你能创造更大的价值。因此,公司里的每个小组,每个业务线,每个部门,都会产生开销,也会产生价值。

    当你所在业务线特别赚钱时,绝大多数老板都会愿意分你一杯羹,这就是一些天价年终奖的由来;当你的业务线不赚钱或者给业务带来发展问题时,老板自然不会看见你好看。简单来说,就是你的业务线投入产出比越高越好,拆分到每个人身上,就是每个人的投入产出比越高越好。

    回到商业的视角,我可以把技术看作商业中的一个板块,技术上的投入,最后应该可以体现出对于业务的价值(比如增长或者利润)。

    2. 如何面向价值编程

    其实从上面我们可以定义出什么是面向价值编程——通过技术去支撑业务的发展,或为在原基础上提供更多的利润。

    这里面有很多很多的具体方法,但在聊具体方法之前,我们先从上开始拆解——做面向价值编程这件事,核心的指标有哪些?

    无指标则无度量。无法进行有效度量时,大家就只能靠一张嘴来说自己做的事有没有价值了。

    最常见的功能生命周期一般是:需求评审、技术评审、开发、测试、上线。

    对于一些有销售的公司来说,他们往往会问产研团队什么时候能给到(交付给)客户?如果等太久,可能就被别人抢单了。这里面还有个潜台词,保质保量(销售肯定不希望你带着BUG给他的客户)。类似的,所有公司都会关注这个事。

    这里面我们可以拆分出几个指标:

    • 交付效率方面
      • 需求交付周期:从需求创建到分析、开发,再到需求交付(验收)的时间周期
      • 需求吞吐量:单位时间内交付的需求个数
    • 交付质量
      • 部署成功率:统计周期内部署成功次数占上线总数的比例
      • 事故数:统计周期内线上事故的次数

    以上是结果指标,我们还需要关注过程指标,才能去改进结果。比如需求交付周期,里面其实有5个环节,那么我们就需要获取5个环节对应的交付周期,以便分析。

    如果能建立起以上的指标体系,其实就能够分析出很多问题了。比如最常见的研发质量问题,技术债务问题,需求变更问题,都会交付周期相关指标里体现出来。

    上述指标体系适合在百人级研发团队。千人级研发团队需要更多的指标去做度量辅助分析发现问题。这就像你平时发现了一个优化的技巧,可以减少1%的冗余数据,在小场景下可能并不怎么有用,但是如果在大场景下,1天有几TB的数据场景下,这个优化方法一年下来可以省很多存储的钱。

    根据不同的时期、以及团队情况,我们可以选择不同的指标进行度量,但宏观上,应该遵守以下原则:

    1. 结果指标 > 过程指标

    通过结果指标评估效能水平,通过过程指标指导改进。

    1. 全局优化 >局部优化

    过度的局部优化可能会导致全局的劣化。如果仅仅关注局部,容易不知不觉影响全局。因此全局指标的优化优于局部指标的优化,团队指标的优化优于个人指标的优化。

    1. 定量指标 > 定性指标

    使用自动采集量化指标进行客观评价,不排除部分综合评价的定性指标。

    1. 指导性,可牵引性行动

    指标设定为目标服务,指标的数值和趋势可以迁移团队改进。比如,适当设定缺陷类指标,可以促进质量内建能力的建设。

    1. 全面性,可互相制约

    如:需求交付周期和线上缺陷数量还有投入人员数量、研发周期和技术债务还有研发人员数,都是成对出现且互相制衡的指标。

    1. 动态性,按阶段调整

    随着团队能力提升,指标也需要进行相关调整,从而促进团队持续改进。

    聊完指标,我们再说说“面向价值编程”的两个常见做事方向:

    • 对外:又快又好的交付功能,赋能业务。
    • 对内:降本增效,用更低的成本去迭代功能。

    “对外”上面已经提到过一些了,而降本增效往往是一本万利的,很难找到理由不去做(除非意识不到)。Saas一份标准化,可以多份卖。ZStack可以一份标准化,多份卖。那为什么建设一次就可以让所有人享受的自动化设施不去建设呢?假设两个公司在市场上攻城略地,市场份额都差不多,A后期平均迭代一个功能2w的成本,B平均迭代一个功能1w的成本。如果在财报上体现出来,市场愿意给谁更高的股价?如果去找投资人,哪家公司会获得更高的估值?

    3. 小结

    本文对“面向价值编程”进行了诠释,并从上至下进行了拆解,给出了一些基本的框架。在之后的系列文章中,我们会看到几个典型案例,来加深对于面向价值编程的理解。

    相关文章

      网友评论

          本文标题:面向价值编程:Why, What, How

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