本文首發(fā)于泊浮目的掘金:https://juejin.cn/user/1468603264665335

0.前言

在前面的系列文章中，我提到了相關(guān)的理論，實操，以及一段工作經(jīng)歷。在這篇文章中，我會用我自己和團隊的經(jīng)歷來作為例子，詮釋面向價值編程，并通過兩個例子說明高ROI工程的打造過程。

ROI一般指投資回報率。 是指通過投資而應(yīng)返回的價值，即企業(yè)從一項投資活動中得到的經(jīng)濟回報。在這篇文章中，我們指的是一個項目的投入產(chǎn)出比——當一個項目投入產(chǎn)出比高的時候，老板則會很樂意持續(xù)投入，相關(guān)人員也可以獲得更高的報酬。反之則不然，甚至還會面臨裁員風險。

1. 初生牛犢不怕虎：剛好有個重構(gòu)的機會

剛到沃趣的時候，QPlus剛好在進行重構(gòu)——原因是這個產(chǎn)品賣的還行，而其本質(zhì)應(yīng)關(guān)注數(shù)據(jù)庫相關(guān)的業(yè)務(wù)，但實際開發(fā)時開發(fā)者需要關(guān)注底層基礎(chǔ)實施的邏輯，而基礎(chǔ)設(shè)施這塊沒有相關(guān)人員的儲備。而我的到來剛好可以彌補這點，我略懂一些Iaas，基于現(xiàn)有的開源項目也可以做出二次開發(fā)來滿足業(yè)務(wù)需求。雖然我們利用Iaas來快速的滿足業(yè)務(wù)需求，但在迭代過程中其復雜性也是需要我們控制的。

之前在ZStack的時候研發(fā)和QA的配比是1:2。

在項目的一開始，我就在團隊里強調(diào)CleanCode和白盒測試的重要性——Iaas實在太復雜了，一開始團隊里就3個研發(fā)1個QA，我們二開時如果不去刻意收斂它的復雜度，到后面的開發(fā)成本是收不住的，因此我們需要通過自動化測試來保證正確性。但這在當時重構(gòu)的時候帶來了額外的成本——團隊的同學不僅要去了解二開，還要做好CleanCode（因為CleanCode做不好，白盒測試是做不了的），這減慢了開發(fā)速度。當時公司里也出現(xiàn)了不支持的聲音——之前別的團隊也沒有搞過自動化，照樣能迭代出產(chǎn)品，為什么你們一定要搞自動化，搞的這么慢？這種情況下，整個團隊壓力特別大。

放在2018年的時候，國內(nèi)公司普遍講究研發(fā)一把梭，梭上市場看效果。研發(fā)成本治理這個事基本不會提，堆不動就堆人。但我對此一直有不同的看法——如果我們可以把成本降得更低，我們的利潤就會更高。而且這個行業(yè)怎么可能一直是夏天（不停的增長），總有遇到冬天的時候，這個時候ROI就特別的重要。

萬幸的是，我們還是完成了重構(gòu)，自動化的理念也在公司內(nèi)部開始傳開。再后來這個產(chǎn)品迭代得逐漸成熟。當我在2022年的時候和同事聊起時，它已經(jīng)成了一個高ROI的項目，用兩個人就可以支撐非常可觀的銷售額。

而關(guān)于ZStack二開、CleanCode和AutoTest，我們在實踐中也積累出了一些經(jīng)驗。本著前人挖坑后人填坑的精神，我也是把相關(guān)的專欄列在這里：

• ZStack源碼分析：https://juejin.cn/column/6963644910666776612
• 代碼與技巧：https://juejin.cn/column/6964737683717357599

2. 盛年不再來，一日難再晨：一把梭的代價

當我們發(fā)出了新版的QPlus后，公司正在做一個新的產(chǎn)品線，主要是做數(shù)據(jù)同步相關(guān)的事，我對它非常感興趣，便申請轉(zhuǎn)過去了。

當時產(chǎn)品線已經(jīng)有了天使客戶，落地效果以及利潤也不錯。所以想著尋找一些行業(yè)里的典型客戶，成為行業(yè)解決方案后再在行業(yè)里復制開來。這個版本的版本號我們定為2.0。當時的產(chǎn)品經(jīng)理對迭代速度是有要求的，于是乎大家都熱火朝天的迭代，以至于大家review代碼都要省著時間——PM認為這事當前沒有價值。同樣的是我們對于老框架的質(zhì)疑，這讓我們的開發(fā)人員一次又一次的陷入底層細節(jié)，這也給后面的質(zhì)量問題埋下了伏筆。

底層細節(jié)：諸如數(shù)據(jù)同步有誤、位點丟失等等等。我們在使用Kafka與Storm時常常遇到這樣的問題。

這事再一次告訴我們——軟件開發(fā)中的不可能三角是真實存在的：人力、質(zhì)量、速度。當人力固定時，速度和質(zhì)量只能二選一。

2.0后面迭代出來，落地到一半時，公司成立了新的產(chǎn)品線，從我們這里抽調(diào)了一部分人走，再加上人員變動，當我作為主程時，研發(fā)最少的時候只有3個人。那是最難熬的時候，我要處理一堆2.0的問題，食了前人種的果。

后來隨著業(yè)務(wù)機會的變多，我們打算逐漸停止v2版本的維護，去做v3版本的開發(fā)——這個版本主要是對v2版的技改，意在降本增效——通過框架的封裝來避免開發(fā)陷入底層細節(jié)邏輯。再后面就是團隊逐漸擴招，研發(fā)擴招至7人，整個團隊最多的時候有16個人。因為一開始項目是三跑的，v2的落地和v3的開發(fā)都要推進，v1的維護也要關(guān)注。后面我們放棄了v2版本的落地，專心開始v3的迭代了。

v3版部分組件是完全重寫的，基于新框架，底層基礎(chǔ)功能的確再也沒有出現(xiàn)過問。但管控平臺部分沿用了之前的代碼。因此仍有一系列質(zhì)量相關(guān)問題需解決，如：

1. 自動化測試在團隊中已有相關(guān)實踐，但大家不怎么樂意寫，因為從短期來看這會增加個人工作量。但長期來看，這會增加軟件的不穩(wěn)定性。
2. 負責code review的同學，幫A同學review代碼，這次review出了一類問題，下次A同學還是寫出了這樣的問題，review僅僅是檢查，并沒有讓A同學成長，長期來看這部分工作量并沒有收斂，寫出來的代碼也沒什么提升，間接帶來質(zhì)量風險。
3. 線上問題頻繁出現(xiàn)，但大家都覺得軟件有問題是正常的。因此團隊里的同學對于軟件質(zhì)量這塊的關(guān)注是十分少的，但我們以一個整體視角來看：一個bug從客戶現(xiàn)場發(fā)生，駐場同學報告，報到PM，讓QA復現(xiàn)，讓研發(fā)跟進，這里面會有多少環(huán)溝通？又會有多少的細節(jié)在溝通中缺失？舉個例子，有一次客戶現(xiàn)場出了一個詭異的問題，我們想把日志撈回來，得知連機器的copy文件的窗口是xx點到y(tǒng)y點，現(xiàn)在已經(jīng)過了，因此要等明天才行。到了第二天，我們拿到日志開始分析，寫好補丁本地驗證，到了第三天發(fā)布過去，和客戶溝通上線時間，然后發(fā)布驗證。這個case，一個bug花了3天才解決。但如果在內(nèi)部發(fā)現(xiàn)，可能2小時就解決掉了。因此得出結(jié)論，一個bug被發(fā)現(xiàn)、修復的越早，帶來的成本越小。
4. 因為問題頻出，銷售對于銷售軟件的信心和意向度也會逐漸減少， 長期來看不利于提升產(chǎn)品的收入，簡直從根源上抹殺了產(chǎn)品發(fā)展的可能。

但如何說服老板去做一個質(zhì)量治理，以及如何讓老板看到過程中的效果、最終拿到結(jié)果，這是需要仔細考慮的——團隊大了，開銷也上去了，決策上的失誤會讓公司浪費資源，我們應(yīng)該盡量避免這樣的事發(fā)生。

我認為，bug產(chǎn)生于開發(fā)期間，從它到客戶現(xiàn)場被發(fā)現(xiàn)，中間還有許多環(huán)節(jié)，我們應(yīng)該鼓勵事前發(fā)現(xiàn)，而不是事后救火。而那個時候業(yè)界里已經(jīng)有了很多成熟的方案，我在參考了許多方案后，做法如下：

• 關(guān)注穩(wěn)定性：從寫代碼，到自測提交代碼，到提測，到上線對整個軟件生命周期進行關(guān)注，并量化跟蹤考量。

-   寫代碼時：關(guān)注代碼規(guī)范掃描，設(shè)計文檔與框架約束
-   自測提交代碼時：關(guān)注自測覆蓋率（白盒測試）以及代碼review中review出的問題數(shù)
-   提測時：關(guān)注千行代碼bug率
-   上線時：關(guān)注告警與重大問題統(tǒng)計，以及模型抽象合理程度

• 找合適的人來落地這些事：根據(jù)團隊的梯隊劃分來賦予更多的權(quán)利和職責

  • 對于職級高的同學，需要負責更多的模塊，對相關(guān)模塊的質(zhì)量負責。質(zhì)量好更利于績效的評優(yōu)
  • 對于發(fā)展意愿強的同學，嘗試給他額外的模塊負責其質(zhì)量

整體的方案比較簡單，并沒有引入特別多的指標以及一系列的平臺工具。數(shù)據(jù)的收集事通過人工來做的——這在團隊規(guī)模較小時是可行的，這點也是考慮到為了快速落地。在實施以上方案時，團隊每個月還會進行一次簡單的談話，和團隊成員溝通相關(guān)的指標是否符合預期，以及接下來的目標或不足之處等。經(jīng)過了小半年的治理，整體的質(zhì)量有了較大的提升，團隊里的成員也切實感受到了這套方法的可行性。

3. 小結(jié)

以上兩個例子和降本增效有著密切關(guān)系：

1. 第一個例子中，獲得的成果是通過兩個人可以支撐起可觀的銷售額。
2. 第二個例子中，獲得的成果是我們可以將開發(fā)從繁瑣細節(jié)、問題中解放出來，更好的支持業(yè)務(wù)功能迭代。同時我們建立了數(shù)據(jù)思維，根據(jù)指標來判斷我們落地的結(jié)果，使質(zhì)量問題長期來看處于收斂趨勢。

而數(shù)據(jù)思維讓我們的目標更加明確，也讓我們可以更好的去判斷我們是否有做好這件事、這件事是否有在好的方向發(fā)展。而不是全憑一張嘴——這樣將會很難說服眾人，便無法對齊這件事的價值。