版本 | 日期 | 备注 |
|---|---|---|
1.0 | 2022.9.19 | 文章首发 |
- 反内卷：有关业务发展已经到达瓶颈，甚至产生无意义的内耗。
- 裁员：有关业务可以用更少的人来维持发展，甚至不发展。
这里面最终都指向了一个东西——钱。 1. 为什么要面向价值编程 许多同学当初从事这个行业是为了高薪，但大家有没有想过为什么老板愿意付你高薪？自然是因为你能创造更大的价值。因此，公司里的每个小组，每个业务线，每个部门，都会产生开销，也会产生价值。 当你所在业务线特别赚钱时，绝大多数老板都会愿意分你一杯羹，这就是一些天价年终奖的由来；当你的业务线不赚钱或者给业务带来发展问题时，老板自然不会看见你好看。简单来说，就是你的业务线投入产出比越高越好，拆分到每个人身上，就是每个人的投入产出比越高越好。 回到商业的视角，我可以把技术看作商业中的一个板块，技术上的投入，最后应该可以体现出对于业务的价值（比如增长或者利润）。 2. 如何面向价值编程 其实从上面我们可以定义出什么是面向价值编程——通过技术去支撑业务的发展，或为在原基础上提供更多的利润。 这里面有很多很多的具体方法，但在聊具体方法之前，我们先从上开始拆解——做面向价值编程这件事，核心的指标有哪些？ 无指标则无度量。无法进行有效度量时，大家就只能靠一张嘴来说自己做的事有没有价值了。 最常见的功能生命周期一般是：需求评审、技术评审、开发、测试、上线。 对于一些有销售的公司来说，他们往往会问产研团队什么时候能给到（交付给）客户？如果等太久，可能就被别人抢单了。这里面还有个潜台词，保质保量（销售肯定不希望你带着BUG给他的客户）。类似的，所有公司都会关注这个事。 这里面我们可以拆分出几个指标：
- 交付效率方面
- 需求交付周期：从需求创建到分析、开发，再到需求交付（验收）的时间周期
- 需求吞吐量：单位时间内交付的需求个数
- 交付质量
- 部署成功率：统计周期内部署成功次数占上线总数的比例
- 事故数：统计周期内线上事故的次数
以上是结果指标，我们还需要关注过程指标，才能去改进结果。比如需求交付周期，里面其实有5个环节，那么我们就需要获取5个环节对应的交付周期，以便分析。 如果能建立起以上的指标体系，其实就能够分析出很多问题了。比如最常见的研发质量问题，技术债务问题，需求变更问题，都会交付周期相关指标里体现出来。 上述指标体系适合在百人级研发团队。千人级研发团队需要更多的指标去做度量辅助分析发现问题。这就像你平时发现了一个优化的技巧，可以减少1%的冗余数据，在小场景下可能并不怎么有用，但是如果在大场景下，1天有几TB的数据场景下，这个优化方法一年下来可以省很多存储的钱。 根据不同的时期、以及团队情况，我们可以选择不同的指标进行度量，但宏观上，应该遵守以下原则：
- 结果指标 > 过程指标
通过结果指标评估效能水平，通过过程指标指导改进。
- 全局优化 >局部优化
过度的局部优化可能会导致全局的劣化。如果仅仅关注局部，容易不知不觉影响全局。因此全局指标的优化优于局部指标的优化，团队指标的优化优于个人指标的优化。
- 定量指标 > 定性指标
使用自动采集量化指标进行客观评价，不排除部分综合评价的定性指标。
- 指导性，可牵引性行动
指标设定为目标服务，指标的数值和趋势可以迁移团队改进。比如，适当设定缺陷类指标，可以促进质量内建能力的建设。
- 全面性，可互相制约
如：需求交付周期和线上缺陷数量还有投入人员数量、研发周期和技术债务还有研发人员数，都是成对出现且互相制衡的指标。
- 动态性，按阶段调整
随着团队能力提升，指标也需要进行相关调整，从而促进团队持续改进。 聊完指标，我们再说说“面向价值编程”的两个常见做事方向：
- 对外：又快又好的交付功能，赋能业务。
- 对内：降本增效，用更低的成本去迭代功能。
“对外”上面已经提到过一些了，而降本增效往往是一本万利的，很难找到理由不去做（除非意识不到）。Saas一份标准化，可以多份卖。ZStack可以一份标准化，多份卖。那为什么建设一次就可以让所有人享受的自动化设施不去建设呢？假设两个公司在市场上攻城略地，市场份额都差不多，A后期平均迭代一个功能2w的成本，B平均迭代一个功能1w的成本。如果在财报上体现出来，市场愿意给谁更高的股价？如果去找投资人，哪家公司会获得更高的估值？ 3. 小结 本文对“面向价值编程”进行了诠释，并从上至下进行了拆解，给出了一些基本的框架。在之后的系列文章中，我们会看到几个典型案例，来加深对于面向价值编程的理解。
