微信公眾號： 且把金針度與人
作者微信：cindynan77
作為敏捷的追隨者，我相信你對敏捷所能帶來的好處已經可以倒背如流；作為敏捷的實踐者，我相信你對敏捷過程實施也已經熟爛于心。
但是所謂萬事開頭難。敏捷的發起不是單純的自上而下，也不是單純的自下而上。而是兩者結合，既需要下層有改變的意愿，也需要上級強有力的支持和參與。所以"我想我能我可以"還遠遠不夠，怎么引導上下級都能有發現問題的意識，再產生解決問題的渴望，從而變成"我們想我們能我們可以"。這其實考驗的是每一個實踐者的思維方式。
今天我用"云—雨—傘"理論跟大家說說怎么引導一個實踐的開始。
云—雨—傘理論
先來給你介紹下什么是"云—雨—傘"理論。
"天上出現烏云，眼看就要下雨，帶上傘比較好。""
這句話分解來看，其實是對事實、分析和行動三者的比喻。怎么區分？
云代表"事實"。是用眼睛實際觀察到的情況。誰都能看出來天上有沒有烏云。
快要下雨，是從現狀推測出來的"分析"。也就是說從出現烏云這個事實引出可能會下雨這個分析。
最后是雨傘。也就是說從"快要下雨"這個分析得出帶上雨傘這一"行動"。
進一步整理如下：
（事實）"天空出現烏云。"
（分析）"因為有烏云，可能會下雨。"
（行動）"因為要下雨，所以帶雨傘。"
這里最重要的就是區分"事實""分析""行動"。如果將三者混淆或遺漏而得出結論的話，那么結論就會不合邏輯。下面我就說一下在引導敏捷的有哪些常見的失敗。
僅把"烏云"提交上去
這種情況比較少見，但是還是需要避免。如果一開始你只是收集了各個部門反饋給你的數據和問題就輕易得出結論反饋上去，收到的可能只是推諉和抱怨，并不是真正問題的所在。因為根據"基因歸因錯誤"理論，看待自己的錯誤，我們通常只會去找外因，而看待別人的錯誤，我們往往追究其內因。
我們常說產品需要"移情"，站在用戶的角度想問題。需求被形容成冰川，露出海面的只是冰山一角。其實作為管理者，我們同樣需要"客戶思維"，挖掘問題暴露出來的本身進行分析。
比如說，你去醫院檢查血液。一周后，檢查結果出來了。結果上寫著丙氨酸轉氨酶、血球容量計、GGT等一些讓你摸不著頭腦的數據。然后就聽到醫生說："這是血液檢查結果，你看看，考慮考慮。"你會怎么想？
我們往往想要知道的是，這些數據說明了什么？是說明身體已經患病，還是沒有毛??？應該注意什么問題？如果有問題的話，問題是大還是?。磕阆胍恼?數據背后的結論"。
當 PO 跟你抱怨研發總是逾期交付，你要了解是什么原因導致的逾期，是需求本身不理解價值所在，還是需求顆粒度太大?
當 PO 抱怨最終發現開發出來的產品不是他們想要的,你要分析是一開始 PO 就沒有澄清清楚，還是對于驗收標準不明確。
當研發抱怨每天加班的時候，你要拋開現象看本質，是本身需求估算不合理，還是交接帶來的等待時間過長。
拿"云—雨—傘"的例子來說的話，就是只向上報告現在有烏云（相當于報告中的數據或收集到的內容），根本就沒意義。
不提供依據
另外一個常見錯誤是只提交建議。用"云—雨—傘”"做比喻的話，"帶上傘"就是行動。如果只是提交行動計劃，別人就不知道這么做的理由是什么。就是缺少"WHY SO"，也就是"為什么這么做"。
在做敏捷提案時，不能只提出行動計劃。要將現狀和分析也一并提出。出現烏云，說明要下雨（現狀分析），要是帶上傘就好了（行動）。
比如作為敏捷教練，比如你經過分析得到了團隊的問題有：逾期交付；超支；很難變更需求；最終發現開發出來的產品不是他們想要的；貽誤戰機，丟失市場機會等。
然后這個時候你直接說"讓我們來實施敏捷吧，這些問題都可以解決。"可能所有人都不會買賬，因為你只是為了"做敏捷"而去做敏捷。
專業的敏捷教練會去說明"要下雨":
傳統的項目開始的時候，只有預算和目標交付時間是確定的，下面的所有因素都存在不確定性：
1.范圍與具體需求；
2.可能的需求變更；
3.人員（中途有人會放假甚至離職等）；
4.估算的準確性；
5.對現有系統的影響；
6.服務器環境的搭建（需要什么配置、何時能到位）。
最后才轉向敏捷。什么是敏捷開發？它和瀑布模型最大的區別在哪里？具體解決方法和價值觀是怎樣的？
混淆現狀、分析、建議
最后一個錯誤是將現狀、分析和行動建議混為一談。特別要區分現狀事實和意見建議。明確回答"結論"和"依據"。這就是所謂的邏輯性思維的基礎。
如何才能迅速掌握這個技能呢？最簡單的方法就是添加標題：
事實、現狀;
我的解釋分析;
推薦的行動方案;
這樣的話，自己腦中就有一個清晰的結構了。
比如，引導敏捷實施框架如下：
- 事實、現狀：
PO 部門的問題有：
1.逾期交付；
2.超支；
3.看到成品時項目已接近尾聲；
4.缺乏透明度，不知道具體進度；
5.很難變更需求；
6.最終發現開發出來的產品不是他們想要的；
7.貽誤戰機，丟失市場機會。
研發部門的問題有：
1.過度承諾；
2.難以一次性消化所有需求；
3.懼怕需求變更；
4.不斷重做；
5.后期壓力巨大；
6.加班
- 我的解釋分析：
而在項目開始的時候，只有預算和目標交付時間是確定的，下面的所有因素都存在不確定性：
1.范圍與具體需求；
2.可能的需求變更；
3.人員（中途有人會放假甚至離職等）；
4.估算的準確性；
5.對現有系統的影響；
6.服務器環境的搭建（需要什么配置、何時能到位）。
敏捷對解決 PO 的問題：
1．不再需要一次性解釋所有的需求；
2．可隨時提出需求變更；
3．進度透明；
4．確保最重要的需求能在目標交付日期獲得；
5．確保得到正確的產品。
敏捷對解決研發部門的問題：
1．不再需要承諾一個未必能實現的計劃；
2．更早地開工和交付；
3．為當前迭代進行更精確的計劃；
4．適應需求變化；
5．適應不確定性；
6．開發正確的產品；
7．與業務人員的爭執更少。
- 推薦的行動方案：
針對性選出能解決以上問題的時間，比如：
1.圍繞已知的范圍和需求定義用戶故事和建立 Product Backlog；
2.為用戶故事排優先級；
3.商定Sprint的長度；
4.商定Spring計劃會議和評審會議的日程；
5.商定發布計劃；
6.準備相應的輔助工具。
小結
任何提案如果沒有以上三項內容，那么它就沒有太大的說服力。很容易被對方質問"你真正的意思是什么？""為什么要這么做？"
領導變革本來就是一件很難的事情，引導變革開始更是難上加難，但是只要學會思考問題的邏輯方法，很多事情就會迎刃而解。最后在強調一遍"云—雨—傘"理論的要點：
·提案中的現狀（云）
·分析研究（雨）
·行動方案（傘)
更多原創推薦閱讀：
