2.2　小步快跑

軟件定義側，定義軟件應該長成什么樣子。大體上，從CEO到產品經理、PO（Product Owner，產品負責人）、BA（Business Analyst，業務分析師）等角色都在做相關的工作：制定正確的戰略方向，抓住市場機會，最后落實到做好具體的軟件產品設計上，也就是確定軟件需求。

軟件實現側，把軟件需求落地實現交給用戶，其包括架構設計、編程實現、軟件交付過程，也包括運維等工作。

我們先來看看軟件定義側要追求的目標：當然是正確地定義軟件應該長成什么樣子。目標要定得準，如果方向錯了，費半天勁開發出來的東西沒人用，那可真是浪費。

如何才能做到正確地定義軟件應該長成什么樣子呢？這可是一個大學問，這里沒法全面展開。我們只提與軟件實現側相關的一件事情：根據軟件行業多年來發展的經驗，應該以比較小的代價多嘗試、多探索，然后根據市場反饋采取進一步的行動——是放棄這個方向，還是調整這個方向，抑或是進一步投入、建設、完善。

為什么要這樣做呢？是因為需求的不確定性。你也不知道，打算做的這個功能，是不是真的合廣大使用者的胃口，將來有多少人用。所以先做一個MVP（Minimum Viable Product，最小可行性產品）試試看。在不同方向多試試，多打幾槍，說不定就打著了。

軟件定義側期待軟件實現側趕緊把這個試驗品做出來，交給用戶試用，越快越好。為什么呢？因為在單位時間內，能嘗試的事情越多，總體來看，先找到正確方向的可能性就越大。假如有兩個相互競爭的初創公司，它們在軟件定義側的水平都差不多，但是在軟件實現側的能力有差異，其中一個公司能在半年內嘗試三種業務打法，另一個公司只能嘗試一種業務打法，那么前者搶先摸到門道的可能性就大得多，先做出來的那個公司，會吃掉大部分市場份額。試錯的成本越低，效率越高，成功的概率就越大。

必須得小步快跑：軟件定義側只定義一小步，然后期待軟件實現側快跑。

以上是說，用戶的心思拿不準，因此需要做一個MVP盡快試試，所以得小步快跑。我們再從另一個角度看一下小步快跑：市場環境可能瞬息萬變，昨天覺得還不需要做的，今天可能就著急上線了。比如，競爭對手推出了一個新的市場推廣活動，還挺受歡迎，那咱們也趕快“仿”一個，為此需要開發團隊趕快配合一下，最好今晚就發布上線。快！趕快！

我們再從第3個角度看一下小步快跑。假定需求都調查清楚了，這個需求就是用戶想要的，它包括10個子功能，每個子功能的上線都能給用戶帶來一定的好處。用戶眼巴巴地等著，不，是軟件定義側眼巴巴地等著軟件實現側趕緊把它們做出來。但都做出來要10個星期，因為每個星期可以做出來一個子功能。那問題來了，是把這10個子功能都做出來以后，一起發布給用戶，還是把每個子功能做出來后就先把它發布給用戶呢？當然要盡量選擇后者。因為前面已經說了，每個子功能的上線都能給用戶帶來一定的好處。那讓用戶早點兒享受多好，哪怕當時還不能享受所有的好處（見圖2-1）。

圖2-1　早發布，多受益

所以，從定義側和實現側協作的角度來看，定義側應該不斷地定義小的需求，交給實現側，然后實現側盡快實現和交付這些小的需求。這就是小步快跑。