面向價值程式設計：高ROI工程之旅

泊浮目發表於2023-03-17
程式設計
版本日期備註
1.02023.3.6文章首發

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. 第二個例子中，獲得的成果是我們可以將開發從繁瑣細節、問題中解放出來，更好的支援業務功能迭代。同時我們建立了資料思維，根據指標來判斷我們落地的結果，使質量問題長期來看處於收斂趨勢。

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

相關文章