6月29日，由阿裡雲研發協同rdc、阿裡雲雲效和雲栖社群聯合舉辦的“首屆阿裡巴巴研發效能嘉年華”上，阿裡巴巴資深專家、靈活教練洪湖帶來“擁抱‘黑天鵝’”的演講。本文主要從黑天鵝事件開始談起，接着分析了哪些模式是脆弱的，而後分享了通過案例得出了從變化中獲益的啟示，最後着重說明了打造靈活組織的重要性。
随着雲計算、大資料、ai智能等前沿科技的發展，傳統的研發速度越來越難滿足企業快速發展的需求，研發效能也成了繼商業模式、技術突破之後的另一核心競争力。本文主要從黑天鵝事件開始談起，接着分析了哪些模式是脆弱的，而後分享了通過案例得出了從變化中獲益的啟示，最後着重說明了打造靈活組織的重要性。一起來了解下吧：
黑天鵝事件
在發現澳洲的黑天鵝之前，歐洲人認為天鵝都是白色的，但這個不可動搖的信念随着第一隻黑天鵝的出現而崩潰。人們總是以自己有限的經驗和不堪一擊的信念來解釋不可預測的黑天鵝事件。黑天鵝無法預測，我們應該做的是适應這種不可知的未來。
<b>那麼，産品開發中可能會碰到什麼樣的“黑天鵝事件”？</b>
我們先來看看想做一個成功産品的背後會有什麼樣的假設呢？
假設1：找到了正确的問題；
假設2：産品被正确定義；
假設3：産品被正确建構；
假設4：做出來的産品可以解決問題；
假設5：有足夠多的人願意買單。
任何一個假設都有可能不成立，在得到最終驗證之前，你沒法預測假設是否成立。
既然黑天鵝事件不可預測，那就不要天真地試圖預測，我們需要适應它們的存在。
怎樣适應“黑天鵝”事件呢？《反脆弱》這本書中給我們介紹了兩點：降低脆弱性和從變化中獲益的能力。弄清楚什麼是脆弱的，比預測對其造成傷害的某個事件是否會發生、何時會發生要容易得多。
什麼是脆弱的
<b>瀑布開發</b><b></b>
在瀑布模式下：
如果産品目标錯了，隻有産品釋出後才能知道目标錯了。而目标是在我們掌握知識最少的時候做出的決策；
如果架構出問題了，也就是技術風險，可能要到後期測試時才會暴露，而我們在設計階段，未寫一行代碼時就做出了最重要的架構決策；
同樣地，還存在內建風險，大家開發的很多子產品代碼在開始測試時才開始內建在一起；此外還有需求變化、延期等······
總體來看，瀑布開發是很脆弱的，它很難應對黑天鵝事件，一旦發生，我們沒辦法及時響應變化。
<b>傳統項目管理</b><b></b>
對于傳統項目管理，我們會管理四個變量，範圍、時間、成本、品質。大家都說品質很重要，它會影響我們長期的發展，是以品質不能犧牲。然後我們要确定範圍，估算什麼時候可以傳遞，以及需要的成本。
在規定的時間、規定的成本裡，按照品質的要求，成功的傳遞了我們達成一緻的範圍，這就是一個成功的項目。
那麼，如果這時發生了“黑天鵝”事件，我們會怎麼辦呢？
我們會采取一些秘密武器：例如copy
& paste，可以快速的把功能實作出來，此外還可以減少測試、沒有自動化、不重構和去掉同行評審等。
之是以會采取以上的一些方法，是因為品質具有滞後性，其它幾個變量發生變化都是馬上就會有回報的。進而我們的系統開始變的混亂，到處是重複的代碼。每次修改，我們都要祈禱别出問題，因為我們的代碼容易出錯，缺少自動化測試的保護。
整個響應速度越來越慢，我們不斷積累債務，忙于應付新功能，忙于修改bug。
是以傳統項目管理模式是脆弱的。
<b>元件團隊</b><b></b>
現在比較多的團隊是這樣一種分工模式：一群開發按照各自的元件作分工，一個需求過來後，會把任務配置設定給各個人，各自負責一個子產品。他們之間的工作量不會均衡，這時往往會同時啟動多個需求，出現大量并發任務在進行的情況。
這時，如果某子產品進展不如預期，所有需求都會受影響；如果出現有人離職、請假時，或者當需求發生變化時，都需要調整所有人的計劃。
為此，有的組織會組建一個團隊去負責某個子產品，開發人員圍繞軟體子產品組合成團隊。這解決了問題了嗎？并沒有。
這種模式一定會導緻瀑布式開發，當一個團隊負責某一子產品時，由誰來進行需求分析？由誰來完成高層設計？由誰來完成端到端的測試？由誰來做計劃、協調？，都不是某個團隊，這就需要有業務分析師分析好需求，需要一個架構工程師将架構做好，需要有專門的測試人員做端到端的測試，我們還需要優秀的項目經理，來貫穿協調。
如果中間發生任何變化，都會影響到其它團隊，協調起來非常困難。
這種模式也會鼓勵追求局部效率最優，當我們去看所有的需求時，假設有兩個團隊d和e，前面高優先級的需求與它倆都沒有關系，它倆可能會啟動新需求。而當它啟動新需求時，需要與其它團隊讨論，對其他團隊造成幹擾，反而拖慢整個開發進度。
是以，元件化分工、元件團隊也是脆弱的。
<b>高耦合的代碼</b><b></b>
圖中反應的是内聚和耦合的關系，顯然它是高耦合的。
内聚：一個機關内部各種元素之間的關聯緊密程度；
耦合：兩個或多個機關之間的關聯緊密程度。
高耦合會導緻代碼難以重用，加小需求可能需要修改n多個地方，随之可能會帶來一些bug。
是以，低内聚高耦合的代碼是脆弱的。
<b>總結</b><b></b>
什麼是脆弱的？
從流程角度來說，傳統的瀑布開發、項目管理模式是脆弱的；
從技術角度來看，低内聚高耦合的代碼、計劃式設計、缺失自動化保護是脆弱的；
從人的角度的說，專業化分工、元件團隊、豎井組織也是脆弱的。
從變化中獲益
從變化中受益的關鍵之處在哪呢？我們可以從以下兩個案例中得到啟發：
<b>米格-15 vs f-86</b><b>軍刀戰機</b>
為什麼處處占盡優勢的米格-15會敗給f-86軍刀呢？
制勝的關鍵是不是絕對速度更快，而是比對手更快的完成ooda環。
<b>小白鼠實驗的啟示</b>
為什麼用小白鼠？因為它的基因序列與人類很類似，繁殖快，生長周期短，且成本低。
當我們面對不确定的“黑天鵝”事件時，從變化中獲益的關鍵是：更快的、更低成本的學習循環，以更快的速度、更低的成本來驗證假設、響應變化。
是以，我們可以給靈活性定義：組織在不斷變化和不可預測的競争環境中應對變化和創造變化的能力，這就是我們要打造的能力。
打造靈活的組織
那麼，如何才能更快的速度、更低的成本 驗證假設、響應變化？
小批量 à 短周期 à 快速回報 à 響應變化
<b>小批量</b><b></b>
小批量的背後是有理論支撐的，如果分析排隊論，會發現批量以及資源使用率對周期的影響，随着批量和使用率的增加，周期會急劇上升，它不是線性的。
如何小批量呢？
将大需求拆分成小需求，然後按照優先級排序，進行開發。要避免按子產品拆分。
我們考慮風險驅動和價值驅動去排序，先把高價值、高風險的東西完成掉，快速的獲得這些回報，才可能以更少的代價、更低的成本、更快速的獲得收益。
很容易得出，疊代開發模式是更适合來應對黑天鵝事件。
<b>技術支撐</b><b></b>
演進式設計：原來可以完成所有的設計再開始寫代碼，現在要變成一種演進式的設計，不要去實作未來的需求，隻做适度的預先設計并保持合理的設計狀态，才可能在需要添加需求時輕松搞定。
改成小批量也不是沒有代價的，随着批量越大，有些成本是會下降的，而有些成本是會增加的。靈活開發許多技術上的實踐恰恰是希望解決這些問題，如果我們能夠在減小批量時不顯著增加成本，我們就可以更好的應對開發變化。那麼，哪些實踐會幫助我們控制小批量的成本呢？
<b>測試自動化</b><b></b>
我們需要建構分層的自動化測試體系，圖中越向上，越接近業務，反應真實需求狀況；越往下，越面向技術，成本更低、影響範圍更小，發現問題定位起來更容易。我們需要分層的自動化測試體系支撐快速疊代模式。
<b>持續內建</b><b>/</b><b>持續部署</b><b></b>
工程師每修改幾行代碼，每完成一小點功能，我們就可以送出代碼，觸發自動化測試得到驗證，才能快速地獲得回報，去保證軟體一直處于可工作的狀态，如果沒有技術手段的保證，是沒有辦法用疊代開發模式的。
<b>靈活項目管理</b><b></b>
讓範圍成為變量。在開發需求分析過程中，堅持品質内建，在時間和成本的限制下，讓價值産出最大化。
<b>全功能團隊</b><b></b>
在組織層面我們需要全功能團隊，面向特性的自組織團隊保證端到端的價值傳遞。一個需求的交流協作都是團隊内部的交流協作，可以更快速的應對變化。我們更鼓勵無差别的全功能團隊，當需求發生變化時，可以很容易作出調整。
我們希望打造有一個靈活的組織，從傳遞層面講，用小批量、短周期方式更快地作疊代，用全功能的組織形式靈活地響應變化，同時，我們需要獲得快速地回報不斷持續改進。
與其預測風雨，不如打造方舟！