面向价值编程：高ROI工程之旅
| 版本 | 日期 | 备注 |
|---|---|---|
| 1.0 | 2023.3.6 | 文章首发 |
| 1.1 | 2023.4.2 | 错别字修复 |
本文首发于泊浮目的掘金:https://juejin.cn/user/1468603264665335
0.前言
在前面的系列文章中，我提到了相关的理论，实操，以及一段工作经历。在这篇文章中，我会用我自己和团队的经历来作为例子，诠释面向价值编程，并通过两个例子说明高ROI工程的打造过程。
ROI一般指投资回报率。 是指通过投资而应返回的价值，即企业从一项投资活动中得到的经济回报。在这篇文章中，我们指的是一个项目的投入产出比——当一个项目投入产出比高的时候，老板则会很乐意持续投入，相关人员也可以获得更高的报酬。反之则不然，甚至还会面临裁员风险。
1. 初生牛犊不怕虎：刚好有个重构的机会
刚到沃趣的时候，QPlus刚好在进行重构——原因是这个产品卖的还行，而其本质应关注数据库相关的业务，但实际开发时开发者需要关注底层基础实施的逻辑，而基础设施这块没有相关人员的储备。而我的到来刚好可以弥补这点，我略懂一些Iaas，基于现有的开源项目也可以做出二次开发来满足业务需求。虽然我们利用Iaas来快速的满足业务需求，但在迭代过程中其复杂性也是需要我们控制的。
之前在ZStack的时候研发和QA的配比是1:2。
在项目的一开始，我就在团队里强调CleanCode和白盒测试的重要性——Iaas实在太复杂了，一开始团队里就3个研发1个QA，我们二开时如果不去刻意收敛它的复杂度，到后面的开发成本是收不住的，因此我们需要通过自动化测试来保证正确性。但这在当时重构的时候带来了额外的成本——团队的同学不仅要去了解二开，还要做好CleanCode（因为CleanCode做不好，白盒测试是做不了的），这减慢了开发速度。当时公司里也出现了不支持的声音——之前别的团队也没有搞过自动化，照样能迭代出产品，为什么你们一定要搞自动化，搞的这么慢？这种情况下，整个团队压力特别大。
放在2018年的时候，国内公司普遍讲究研发一把梭，梭上市场看效果。研发成本治理这个事基本不会提，堆不动就堆人。但我对此一直有不同的看法——如果我们可以把成本降得更低，我们的利润就会更高。而且这个行业怎么可能一直是夏天（不停的增长），总有遇到冬天的时候，这个时候ROI就特别的重要。
万幸的是，我们还是完成了重构，自动化的理念也在公司内部开始传开。再后来这个产品迭代得逐渐成熟。当我在2022年的时候和同事聊起时，它已经成了一个高ROI的项目，用两个人就可以支撑非常可观的销售额。
而关于ZStack二开、CleanCode和AutoTest，我们在实践中也积累出了一些经验。本着前人挖坑后人填坑的精神，我也是把相关的专栏列在这里：
- ZStack源码分析：https://juejin.cn/column/6963644910666776612
- 代码与技巧：https://juejin.cn/column/6964737683717357599
2. 盛年不再来，一日难再晨：一把梭的代价
当我们发出了新版的QPlus后，公司正在做一个新的产品线，主要是做数据同步相关的事，我对它非常感兴趣，便申请转过去了。
当时产品线已经有了天使客户，落地效果以及利润也不错。所以想着寻找一些行业里的典型客户，成为行业解决方案后再在行业里复制开来。这个版本的版本号我们定为2.0。当时的产品经理对迭代速度是有要求的，于是乎大家都热火朝天的迭代，以至于大家review代码都要省着时间——PM认为这事当前没有价值。同样的是我们对于老框架的质疑，这让我们的开发人员一次又一次的陷入底层细节，这也给后面的质量问题埋下了伏笔。
底层细节：诸如数据同步有误、位点丢失等等等。我们在使用Kafka与Storm时常常遇到这样的问题。
这事再一次告诉我们——软件开发中的不可能三角是真实存在的：人力、质量、速度。当人力固定时，速度和质量只能二选一。
2.0后面迭代出来，落地到一半时，公司成立了新的产品线，从我们这里抽调了一部分人走，再加上人员变动，当我作为主程时，研发最少的时候只有3个人。那是最难熬的时候，我要处理一堆2.0的问题，食了前人种的果。
后来随着业务机会的变多，我们打算逐渐停止v2版本的维护，去做v3版本的开发——这个版本主要是对v2版的技改，意在降本增效——通过框架的封装来避免开发陷入底层细节逻辑。再后面就是团队逐渐扩招，研发扩招至7人，整个团队最多的时候有16个人。因为一开始项目是三跑的，v2的落地和v3的开发都要推进，v1的维护也要关注。后面我们放弃了v2版本的落地，专心开始v3的迭代了。
v3版部分组件是完全重写的，基于新框架，底层基础功能的确再也没有出现过问。但管控平台部分沿用了之前的代码。因此仍有一系列质量相关问题需解决，如：
- 自动化测试在团队中已有相关实践，但大家不怎么乐意写，因为从短期来看这会增加个人工作量。但长期来看，这会增加软件的不稳定性。
- 负责code review的同学，帮A同学review代码，这次review出了一类问题，下次A同学还是写出了这样的问题，review仅仅是检查，并没有让A同学成长，长期来看这部分工作量并没有收敛，写出来的代码也没什么提升，间接带来质量风险。
- 线上问题频繁出现，但大家都觉得软件有问题是正常的。因此团队里的同学对于软件质量这块的关注是十分少的，但我们以一个整体视角来看：一个bug从客户现场发生，驻场同学报告，报到PM，让QA复现，让研发跟进，这里面会有多少环沟通？又会有多少的细节在沟通中缺失？举个例子，有一次客户现场出了一个诡异的问题，我们想把日志捞回来，得知连机器的copy文件的窗口是xx点到yy点，现在已经过了，因此要等明天才行。到了第二天，我们拿到日志开始分析，写好补丁本地验证，到了第三天发布过去，和客户沟通上线时间，然后发布验证。这个case，一个bug花了3天才解决。但如果在内部发现，可能2小时就解决掉了。因此得出结论，一个bug被发现、修复的越早，带来的成本越小。
- 因为问题频出，销售对于销售软件的信心和意向度也会逐渐减少， 长期来看不利于提升产品的收入，简直从根源上抹杀了产品发展的可能。
但如何说服老板去做一个质量治理，以及如何让老板看到过程中的效果、最终拿到结果，这是需要仔细考虑的——团队大了，开销也上去了，决策上的失误会让公司浪费资源，我们应该尽量避免这样的事发生。
我认为，bug产生于开发期间，从它到客户现场被发现，中间还有许多环节，我们应该鼓励事前发现，而不是事后救火。而那个时候业界里已经有了很多成熟的方案，我在参考了许多方案后，做法如下：
- 关注稳定性：从写代码，到自测提交代码，到提测，到上线对整个软件生命周期进行关注，并量化跟踪考量。
- 写代码时：关注代码规范扫描，设计文档与框架约束
- 自测提交代码时：关注自测覆盖率（白盒测试）以及代码review中review出的问题数
- 提测时：关注千行代码bug率
- 上线时：关注告警与重大问题统计，以及模型抽象合理程度
-
找合适的人来落地这些事：根据团队的梯队划分来赋予更多的权利和职责
- 对于职级高的同学，需要负责更多的模块，对相关模块的质量负责。质量好更利于绩效的评优
- 对于发展意愿强的同学，尝试给他额外的模块负责其质量
整体的方案比较简单，并没有引入特别多的指标以及一系列的平台工具。数据的收集事通过人工来做的——这在团队规模较小时是可行的，这点也是考虑到为了快速落地。在实施以上方案时，团队每个月还会进行一次简单的谈话，和团队成员沟通相关的指标是否符合预期，以及接下来的目标或不足之处等。经过了小半年的治理，整体的质量有了较大的提升，团队里的成员也切实感受到了这套方法的可行性。
3. 小结
以上两个例子和降本增效有着密切关系：
- 第一个例子中，获得的成果是通过两个人可以支撑起可观的销售额。
- 第二个例子中，获得的成果是我们可以将开发从繁琐细节、问题中解放出来，更好的支持业务功能迭代。同时我们建立了数据思维，根据指标来判断我们落地的结果，使质量问题长期来看处于收敛趋势。
而数据思维让我们的目标更加明确，也让我们可以更好的去判断我们是否有做好这件事、这件事是否有在好的方向发展。而不是全凭一张嘴——这样将会很难说服众人，便无法对齐这件事的价值。
