離岸經營的啟發（二）分拆軟體業務

高居軟體界前列的巨匠們相信，一切問題可以由技術或技術人自己解決。於是，該由需求分析師搞掂的問題，需要開發人員“擁抱變化”，該由測試人員搞掂的問題，需要開發人員“測試驅動開發”，該由技術管理解決的問題，需要Team Dev“自組織”，該由文檔工程師搞掂的事，需要開發人員“編寫高可讀性的代碼”。

但現實的問題是，大量軟體項目中，無論團隊多麼優秀，最終都會延期、不合格、轉手甚至宣告停止。

現在國內軟體外包流行兩種模式：項目外包、人力外包；項目外包，目前大多數技術型的公司缺乏業務高手，無法駕馭整個項目的需求實現程度；人力外包，服務商可以採用自身的管理體系、客戶關係來操縱項目進展，相對而言也可以比項目外包組建角色上更完整的團隊。後者的模式很像在軟體開發教科書上描繪的模式：客戶公司組成顧問團、研發公司帶上Team Dev，還有產品經理、使用者體驗師……大家克服一個又一個的困難，遇上一個又一個不可思議的問題，期限到達，項目延期或正式上線（延期一般都是99.9999...%）。軟體工程因此發展起來了，各種各樣的流程改善、規範完善又到自組織的敏捷團隊，但起碼到目前，軟體項目，it's always been the same old story.

看看離岸經營是怎麼做的吧！需求分析師、系統架構師的位置設在客戶總部，各個Team Dev位於全球任何一個提供比較優勢的程式員生活的城市；用文檔闡清需求和設計約束，各個Team Dev進行編碼、測試然後交付清單和檔案。在這裡，很多時候需求依然是不明確地，變化的，但有專人和時間去做調研並且——比我所知的任何地方都高效和高品質。

離岸經營帶給我們的啟發是，從管理（宏觀）而非團隊內部（微觀）入手去解決問題。想想吧，這僅僅只是一個Team Dev而已，你無法得到更多。如果你是只想著利益的老闆，這正是你重新審視賺更多錢方式的機會；如果你是一個只想著忽悠的經理，我建議你要麼改進要麼走人，因為問題就出在你那兒；如果你是客戶，也可以想想這些年你的付出所得是否成正比。

需求、設計、開發、測試、交付、維護，軟體項目所涉及六個業務範圍，軟體工程所研究和提供的僅僅只是調節六大模組互動的時間與順序，採用什麼樣的方法論並不重要，重要的是正確的人坐到正確的位置。根據業務範圍拆分軟體項目為五至六個業務模組，制定模組之間的協作策略（文檔、工作流程），然後挖掘自己最有價值的業務，其它的進行外包——日本人就是這麼乾的，如果那麼多對日外包的程式員能轉換一下立場，我們會從中受益。

本文在開初就說了，我們更多的是需要模仿和學習，因為在這個行業，有太多值得我們模仿和學習的現成的東西；在能夠解決開發中一系列難題之後，歡迎在行業中有更大目標的技術人投入到宏觀視角和管理視角上來看待我們的處境，這裡沒有“為國內軟體業創造一個美好的環境”的口號，而是去解決我們自身技術所不能解決的問題。