2.3　軟件實現側該追求什么目標

現在我們開始分析軟件實現側要追求的目標。為什么要分析它呢？因為軟件交付過程是軟件實現側的所有事情中的一部分。我們先把軟件實現側整體要追求的目標分析清楚，然后再看具體到軟件交付過程，也就是本書主要研究的范圍，要追求什么。

首先是軟件實現側要出活兒。也就是要有較高的產能，或者叫吞吐量（Throughput）。吞吐量是指系統在單位時間內處理請求的數量，在這里就是指軟件實現側在一定的時間內能夠實現的軟件需求的總量。比如有兩個相互競爭的企業，它們在軟件定義側的能力是差不多的，但是在軟件實現側，其中一個企業一年能發布100個新特性，另一個企業一年只能發布20個新特性，那大概率后者會被淘汰掉。

把更高的產能作為追求的目標，這是“與生俱來”的。哪怕是當年流行的瀑布模式，同樣也追求更高的產能。現在我們也同樣要追求更高的產能。

那么，如今的軟件開發跟當年的軟件開發，在理念上有什么不一樣的地方呢？從追求目標的角度來看，最明顯的變化是，如今在追求更高產能的同時，越來越重視另外一個目標，那就是更快的響應速度。

前面我們分析時說，得小步快跑。靠定義側定義小步，靠實現側快跑。跑得快意味著，當定義側把一個用戶故事交給實現側，說“拜托你趕快做出來”的時候，實現側真的可以很快做出來，把它發布上線，使前置時間（Lead Time）很短。按照精益思想，追求快速響應、快速實現，可以稱為聚焦價值流動效率。

為了更好地理解更高的產能和更快的響應速度這兩個目標，我們做個類比，假如你是一個只做外賣生意的飯館老板，那么你既要關注本飯館的產能：一天能夠炒出多少盤菜，因為這對應著飯館的每日收入，也要關注本飯館的響應速度，也就是從用戶下單到菜打包好需要多久，因為這影響著食客的用戶體驗。假定本飯館的“香菇油菜”這道菜很受歡迎，其中香菇都是干香菇泡發的，食客點了這道菜之后，后廚就去泡發香菇。那你一定會想辦法改進這件事情，比如從用溫水泡發改成用熱水泡發，以求減少泡發時間，或者干脆把一定量的香菇提前泡發好。做這樣的改進，大概對這道菜的產能提升幫助不大，因為產能的瓶頸是廚師每小時能炒出多少盤，而不應該是每小時能泡發出多少香菇。就算拿大澡盆每小時泡發出100盤，如果廚師只能炒出10盤，那還是只能賣10盤。但做這樣的改進，會對這道菜的響應速度有明顯的提升，比如從食客平均需要等待50分鐘變成只需要等待25分鐘就可以吃上了。

除了產能和響應速度，我們當然也得關注質量。這里所說的質量，是指用戶能夠感受到的軟件服務質量，所以也包括穩定性、可靠性、安全性等。

注意，跟前面兩項追求產能越高越好、響應速度越快越好不同，質量并不是要一味地追求越高越好。到底需要多高的質量，要看具體是什么業務場景。比如，對俄羅斯方塊的質量要求肯定不如對無人駕駛汽車來得高。前者就是一個單機游戲，后者可是人命關天。甚至同一個系統內部的不同部分，對質量的要求也可能不同。

為什么質量不是越高越好呢？因為高質量是有代價的。質量越高，代價越大，代價包括產能變低、響應速度變慢、成本變高等。所以要看在特定的業務場景下，達到什么樣的質量最“劃得來”。所以說我們要追求的第3個目標是，適當的質量。

舉個例子，谷歌的網站可靠性工程（SRE，Site Reliability Engineering）[2]追求的就是適當的質量。不同的服務有其不同的錯誤預算：如果每個季度服務的可靠性目標都是99.99%，那么錯誤預算就是0.01%。不用追求零事故運行，只要不超出錯誤預算就行了。在此基礎上，應盡可能地加快功能上線速度。

質量不是非得越高越好，對應地，成本也不是非得越低越好。成本包括人力資源成本、硬件資源的投入、軟件許可證的購買等。成本應當是一個適當的、可接受的值。成本不要離譜，比如為每一個開發人員都搭建一套其獨占的由1000臺服務器構成的測試環境來進行整個系統端到端的測試和調試，就離譜了。如果有改進方案，能在不影響產能、響應速度、質量的情況下，把某個方面的成本明顯地降一降，那挺好。但是整個軟件實現過程的改進重點通常不應該是降低成本——既然是從事生產活動，那么主要關注點應該是創造更多的價值，而不是省錢。

總結一下，軟件實現側要追求的目標通常是：

? 更高的產能。

? 更快的響應速度。

? 適當的質量。

? 合理的成本。

這正好對應“多、快、好、省”：

? 多——更高的產能。

? 快——更快的響應速度。

? 好——適當的質量。

? 省——合理的成本。

當然，你也可以把它對應到項目管理三角形：“多、快、省”對應三角形的范圍、時間、成本這三條邊，而“好”則對應三角形中間經常寫著的“質量”兩個字。

反正就這四個方面，你覺得怎么好記就怎么記。關鍵是要理解，更高的產能和更快的響應速度是我們要追求的核心目標，而質量要達到特定業務的要求，同時適當考慮成本。