头图
版本日期备注
1.02023.3.6文章首发
1.12023.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,我们在实践中也积累出了一些经验。本着前人挖坑后人填坑的精神,我也是把相关的专栏列在这里:

2. 盛年不再来,一日难再晨:一把梭的代价

当我们发出了新版的QPlus后,公司正在做一个新的产品线,主要是做数据同步相关的事,我对它非常感兴趣,便申请转过去了。

当时产品线已经有了天使客户,落地效果以及利润也不错。所以想着寻找一些行业里的典型客户,成为行业解决方案后再在行业里复制开来。这个版本的版本号我们定为2.0。当时的产品经理对迭代速度是有要求的,于是乎大家都热火朝天的迭代,以至于大家review代码都要省着时间——PM认为这事当前没有价值。同样的是我们对于老框架的质疑,这让我们的开发人员一次又一次的陷入底层细节,这也给后面的质量问题埋下了伏笔。

底层细节:诸如数据同步有误、位点丢失等等等。我们在使用Kafka与Storm时常常遇到这样的问题。

这事再一次告诉我们——软件开发中的不可能三角是真实存在的:人力、质量、速度。当人力固定时,速度和质量只能二选一。

2.0后面迭代出来,落地到一半时,公司成立了新的产品线,从我们这里抽调了一部分人走,再加上人员变动,当我作为主程时,研发最少的时候只有3个人。那是最难熬的时候,我要处理一堆2.0的问题,食了前人种的果。

后来随着业务机会的变多,我们打算逐渐停止v2版本的维护,去做v3版本的开发——这个版本主要是对v2版的技改,意在降本增效——通过框架的封装来避免开发陷入底层细节逻辑。再后面就是团队逐渐扩招,研发扩招至7人,整个团队最多的时候有16个人。因为一开始项目是三跑的,v2的落地和v3的开发都要推进,v1的维护也要关注。后面我们放弃了v2版本的落地,专心开始v3的迭代了。

v3版部分组件是完全重写的,基于新框架,底层基础功能的确再也没有出现过问。但管控平台部分沿用了之前的代码。因此仍有一系列质量相关问题需解决,如:

  1. 自动化测试在团队中已有相关实践,但大家不怎么乐意写,因为从短期来看这会增加个人工作量。但长期来看,这会增加软件的不稳定性。
  2. 负责code review的同学,帮A同学review代码,这次review出了一类问题,下次A同学还是写出了这样的问题,review仅仅是检查,并没有让A同学成长,长期来看这部分工作量并没有收敛,写出来的代码也没什么提升,间接带来质量风险。
  3. 线上问题频繁出现,但大家都觉得软件有问题是正常的。因此团队里的同学对于软件质量这块的关注是十分少的,但我们以一个整体视角来看:一个bug从客户现场发生,驻场同学报告,报到PM,让QA复现,让研发跟进,这里面会有多少环沟通?又会有多少的细节在沟通中缺失?举个例子,有一次客户现场出了一个诡异的问题,我们想把日志捞回来,得知连机器的copy文件的窗口是xx点到yy点,现在已经过了,因此要等明天才行。到了第二天,我们拿到日志开始分析,写好补丁本地验证,到了第三天发布过去,和客户沟通上线时间,然后发布验证。这个case,一个bug花了3天才解决。但如果在内部发现,可能2小时就解决掉了。因此得出结论,一个bug被发现、修复的越早,带来的成本越小。
  4. 因为问题频出,销售对于销售软件的信心和意向度也会逐渐减少, 长期来看不利于提升产品的收入,简直从根源上抹杀了产品发展的可能。

但如何说服老板去做一个质量治理,以及如何让老板看到过程中的效果、最终拿到结果,这是需要仔细考虑的——团队大了,开销也上去了,决策上的失误会让公司浪费资源,我们应该尽量避免这样的事发生。

我认为,bug产生于开发期间,从它到客户现场被发现,中间还有许多环节,我们应该鼓励事前发现,而不是事后救火。而那个时候业界里已经有了很多成熟的方案,我在参考了许多方案后,做法如下:

  • 关注稳定性:从写代码,到自测提交代码,到提测,到上线对整个软件生命周期进行关注,并量化跟踪考量。
-   写代码时:关注代码规范扫描,设计文档与框架约束
-   自测提交代码时:关注自测覆盖率(白盒测试)以及代码review中review出的问题数
-   提测时:关注千行代码bug率
-   上线时:关注告警与重大问题统计,以及模型抽象合理程度


  • 找合适的人来落地这些事:根据团队的梯队划分来赋予更多的权利和职责

    • 对于职级高的同学,需要负责更多的模块,对相关模块的质量负责。质量好更利于绩效的评优
    • 对于发展意愿强的同学,尝试给他额外的模块负责其质量

整体的方案比较简单,并没有引入特别多的指标以及一系列的平台工具。数据的收集事通过人工来做的——这在团队规模较小时是可行的,这点也是考虑到为了快速落地。在实施以上方案时,团队每个月还会进行一次简单的谈话,和团队成员沟通相关的指标是否符合预期,以及接下来的目标或不足之处等。经过了小半年的治理,整体的质量有了较大的提升,团队里的成员也切实感受到了这套方法的可行性。

3. 小结

以上两个例子和降本增效有着密切关系:

  1. 第一个例子中,获得的成果是通过两个人可以支撑起可观的销售额。
  2. 第二个例子中,获得的成果是我们可以将开发从繁琐细节、问题中解放出来,更好的支持业务功能迭代。同时我们建立了数据思维,根据指标来判断我们落地的结果,使质量问题长期来看处于收敛趋势。

而数据思维让我们的目标更加明确,也让我们可以更好的去判断我们是否有做好这件事、这件事是否有在好的方向发展。而不是全凭一张嘴——这样将会很难说服众人,便无法对齐这件事的价值。


泊浮目
4.9k 声望1.3k 粉丝

从业7年,创过业带过团队,理财老鸟。目前从事于数据应用方向,希望从数据中发现价值,创造价值。对于研发效能方面也较为关注。