成都的夏天總是雨的季節，淅淅瀝瀝，停一會兒，下一會兒，濕潤的空氣掩蓋了些許PM2.5的焦味，卻淡不了公司焦躁的情緒。臃腫的Bug列表、遲緩的解決速度、日益逼近的Milestone以及長時間加班激起的不滿情緒……蔓延在整個辦公區域。“提高效率”成了Management  Meeting上呼聲最高的詞語。

　　不幸的是我被派去推動整個項目改進計劃，請允許我摘一段和項目經理的談話來引入今天要討論的正題：

　　PM一頭霧水：“這次Milestone指定保不住，客戶批了好幾次，我們的效率太低了。”

　　我不解：“為什么不快點呢？”

　　PM有點生氣：“Demo總是過不了，怎么快？”

　　我更不解：“Demo為什么不過呢，功能實現完沒？”

　　PM真生氣了：“都是腦殘的客戶，說不是他想要的，我們都實現了他的要求……”

　　我不想重復上面那種你來我往的問題，這已經說明了這個項目存在諸如效率低下的問題，被客戶責備，在這種情況下，我們需要問自己“為什么效率低下？是什么導致效率低下？”，而不能因為客戶老說我們的Demo不是他們想要的，我們就重復Demo的改進，我們更需要去思考，什么阻止了我們的Demo不能滿足客戶的需要。在我做咨詢的日子里，見到影響團隊效率提高的原因不外乎以下三個。

　　制度問題：常見的如產品公司，比如Adobe的Photoshop，用戶告訴HelpDesk說，你的畫刷不好用，Adobe拿到這個問題，可能需要不下十個部門的審核，最終給出解決方案。

　　技術問題：某類技術問題太難或者某類問題重復出現。常見如大型軟件產品中疑難問題導致了某個迭代里程碑不能順利發布。

　　能力問題：整個組織或者團隊Competence不行。

　　解決此類問題，我們必須先知道哪塊石頭絆倒了自己，在歐美軟件公司流行兩個詞語：RCA和EDA。一個是傾向過程分析，一個是角色分析。

　　找到問題的本質原因（Root Cause）是一個高效技術團隊必須具備的能力，但常常效果并不理想，主要表現在以下幾方面。

　　問題的原因盤根錯節：比如通信產品的一個Bug可能是很多Team共同導致的，也可能是因為歷史遺留或者技術升級造成的。

　　問題肇事方橫跨國際：在技術國際化的今天，經常出現在中國開發，在印度維護，在韓國修復這種類似的情況。

　　調查方認知狹窄經驗不足：人員流動是技術類公司的普遍特點，我們經常出現剛組建不久的團隊需要去修復很久以前的Bug，由于團隊新、員工能力薄弱，很難看到問題的本質。

　　為交差而非探究：這種情況在外包類公司很普遍，外包分為Capacity外包或者Content外包。團隊成果交付的界限是完成任務，所以在分析問題時，很多目的為了完成里程碑，為了交付。殊不知這個問題一次不能徹底解決，可能在后續會不斷重現，其疊加效應造成的成本流失更大。

　　在問題的重復中迷失：開篇的一席對話，其實就是這個原因的佐證，我們沒能一次解決問題，而是修修補補，發現同質不同樣的問題不斷重現，交付的時間越近，大腦越是沒有片刻的清凈去思考問題的本質。

　　除以上幾點原因外，在我們的外包實踐中，遇到過很多其他的問題，比如團隊管理松散、流程執行不嚴格、風險管理滯后等，都直接削弱了技術團隊的高效性。那么我們是如何解決如上問題的呢，我們遵循的是“5W法則”。

　　在我向公司引入6Sigma質量管理方法論時，曾經深入地研究過這個法則，同6Sigma一樣，5W法則來自日本豐田公司，由豐田佐吉先生發明，以此來改進豐田生產線上的諸多問題。其最基本的原則就是：任何生產型問題都可以連續問5個為什么找到答案。

　　“打破砂鍋問到底”：5W法則和我們民間常說的“打破砂鍋問到底”如出一轍，但又有不同，5W法則需要有技巧地去問，需要有規則地單向地去問，具有單點目的性，但后者則沒有這些特點。

　　5W法則要旨在問，原則在中立：我們做問題分析時通過問的方式進行，但要采用問題中立的原則，不能有問題方的心理障礙在里面，這是最基本的原則。

　　5W法則在歐美企業中的典型應用：RCA和EDA。RCA意為Root CauseAnalysis（本質問題原因分析），EDA意為Espcae Defect Analysis（控制遺漏分析）。

　　我們可以跨域地借鑒這個在制造業中的方法到我們的技術型團隊中，接下來我們對開篇的那個讓項目經理頭疼的問題采用5W法則找一下問題的原因，來看看在實際的團隊運作中如何使用。

　　第一步：成立分析組

　　對于典型問題或者核心問題，要成立問題分析組，為了分析開篇實例中的問題，我們成立了分析組，取名為：P7延期分析組。

　　該分析組需要以下特點。

　　分析組的Leader：必須是Scrum Master或者Team Leader，或是問題整個參與者。因為Leader需對問題有比較全面的了解。

　　分析組組員需要包含問題相關方：比如我們P7的Milestone延期，可能因為Demo沒有通過，那么就需要Demo的相關方（比如開發者Eric、資深Tester Tom、Product OwnerSusan還有產品專家Sean）一起參與。只有問題的相關方都參與，我們才可以全面分析問題的原因。

　　第二步：準備5W分析表

　　有些公司習慣將5W分析稱為RCA表。圖1是我們公司喜歡用的5W表，當然別的公司可能有自己的形式，這不是重點。重點是內容需要體現5W的思想。簡單說一下每個元素。

　　Root Cause Analysis列：這里列出將被分析的問題，比如“37號基站扇區配置失敗”，比如“Excel中的格式刷在大文本下無效”或者也可以是“每天早上總有20%的員工遲到”等。這里需要用簡明的語言列出被分析的問題。

　　Why1至Wh5：這五個列，則是對第一列的問題引申出的原因。

　　Root Cause：該列就是我們針對該行的Why分析出的最本質的原因。

　　Actions：最后一個列則是針對前面的Root Cause提出的改進計劃。

　　表中的粗線左向箭頭：其代表著問題的層次性，比如Why1下的第一個原因，可能會引出Why2下的另外幾個原因，以此類推呈樹狀散射分布。

　　表中的文字：每一個Why的內容，都需要以“因為（Because或 As）”開頭。

　　第三步：進行分析

　　在前兩步準備好后，我們進入非常重要也是非常有意思的第三步。我們的Leader Warren會找一個寬敞的會議室，帶領大家進入主題，我以影視場景的方式描述整個過程。

　　劇情1：Warren會說：“今天我們分析P7延期的問題，大家暢所欲言，為什么會延期？直接原因是什么？”

　　劇情分析：這是第一個“為什么”（Why），組員需要去想導致這個問題的最直接的原因是什么？而不是比如：C++沒學好、物價飛漲等間接原因。也許C++沒有學好可能導致Developer代碼的質量不好、物價飛漲或許會讓員工無心工作，但切記這都不是最直接的原因。

　　劇情2：Warren說完后Susan迫不及待地說：“因為Demo兩次沒有過。”Tom失落地說：“我們的工作檢查表中有三項沒完成。”后面大家一起抱怨說：“時間太緊迫。”突然角落一個聲音傳來，資深開發Eric無奈地說：“客戶的需求一直在變。”這個話題引起了大家的共鳴，開始你一句我一句進入了發泄和辯論的環節。這時Warren優雅地拍了拍手，提醒大家暫停，并且引導說現在是分析最直接的原因，已經有四個原因，大家同意嗎？經過大家投票Eric的原因不是直接原因，其他三個是。于是Warren淡定地把這三個原因寫到Why1的列。

　　劇情分析：這就是分析現場，很多經驗尚淺的分析小組，最后陷入一團糟，甚至引起關系緊張的論戰。所以Leader很重要，需要引導大家，按照“直接原因——依次深入”的方式進行。

　　經過第一個Why的詢問，我們發現導致P7延期的有三個直接原因：Demo審查不過、工作表有三項沒完成、時間緊迫。

　　那么還有第四個原因嗎？這個需要團隊決定，當時大家一致通過沒有。同時Warren需要出來引導組員：既然大家同意只有三個直接原因，那如果順利解決了這三個問題，是否P7就不會Delay？

　　注意這里就是5W法則在執行過程中的一個很重要的原則——閉環性。即一旦次級的原因解決，那么本級的問題必然被解決。Warren帶領大家完成了Why1的分析，很漂亮地找到了三個原因，接下來進入Why2的分析。

　　劇情3：Warren指著“Demo審查不過”這一條，問組員：“為什么審查不過？”這時組員列出各種原因，比如“代碼沒有寫完”，“實現需求和客戶期望有差距”等。也有組員說“時間太緊了”。

　　劇情分析：注意對于最后一個關于時間太緊的問題，需要在這個Why2分析域中移除，因為它屬于Why1的第三個原因。想必大家明白此舉的目的，即防止重復分析、提高分析效率。

　　我們不斷重復著Why1和Why2的節奏，無限地延伸到WhyN，但終點在哪里呢？如果我們不停止，我們可以從一輛飛奔的汽車一直分析到每一個金屬原子的夸克結構。如圖2中的深紅色圓圈就是我們末態原因。判斷是否需要停止進一步分析時，需要滿足幾個條件。

　　這個原因大家明確且可修復：比如我們沿著“任務中三項沒完成”脈絡分析到“因為Master請假沒有及時檢查任務完成情況”時，這個原因大家都明確，且只要Master不請假或者請假也能及時檢查就可以修復。

　　這個原因不在自己的控制范圍：比如我們沿著“Demo審查不過”分析到“客戶的需求文檔開發人員離職”，到此我們就無須深入，因為員工離職我們可能分析出各種原因，但他不是我們所能掌握的，所以他是我們的職責之外。如果需要繼續則需要客戶方參與。

　　這個原因原子不可分：比如我們沿著“時間太緊”分析到“因為端午節放假”，這個就已經不能再分，因為你無法再繼續去分析為什么端午節放假的問題了。

　　有沒有超過5個Why呢？

　　在我帶領我的團隊作分析時，開始時經常出現類似情況，一個問題，按照5W法則我們希望在5個Why之前就可以找到問題的本質原因，可是總有組員嘗試刷新紀錄搞出很多個Why出來。切記如果某一個Why的次級Why的個數太多則說明如下幾個問題：

　　上一級Why粒度太大；

　　被分析對象粒度太大；

　　分析者沒有全局掌握；

　　分析者沒有有效合并。

　　比如我們如果分析一下PM2.5為什么超過300，那么我們無論如何都不能用5Why搞定，因為被分析的對象太寬泛，我們需要把這個大問題劃分成很多個子問題再分析。

　　通過前面的分析，我們總結一下5W法則的實施原則，如圖3所示。

　　Host是分析過程的引導者：分析問題過程中，不同的角色很容易執迷于自己的方向，而讓整個分析過程一團糟。所以Host需要引導組員并在一些比較迷茫的問題上或大家都沉默時，利用發散思維、合理引導，比如可以說：是否存在這樣的可能，是否存在那樣的可能等。

　　一次只分析一個問題：我們都喜歡大而化之一個問題，但我們會在眾多的問題中迷茫，所以在分析時選擇一個問題分析，在每一個Why的階段，只分析一個階段的Why，不要涉及其他Why。

　　最后一個Why結果就是Root Cause：在每個Why分析到末態時，如圖2中我們用深紅色標注的部分，那就是末態原因，是我們尋找的Root Cause。

　　費了這么多功夫，我們都是在找Root Cause，那么Root Cause有什么特點呢？

　　正交性：意指最終Root Cause列中所列出的原因，彼此不能包含，原因間彼此獨立。如果出現包含或者重疊的問題，那就說明我們在前面的Why分析中做了重復分析。比如出現以下Root Cause：P7延期因為文檔不全和P7延期因為需求說明文檔缺失。明顯后者被前者包含。如果出現這個問題，我們需要把這個兩個原因合并。

　　原子性：意指末態Root Cause不能再分或者不屬于我們的掌控范疇，我在前面的篇幅中已經講解。

　　可度性：這個概念引申于SMART原則，指我們的Root Cause是可以度量的。也就是可以切實去理解、規劃和實施。不能出現如：P7 Milestone延期是因為“客戶希望我們成為一名偉大的人”，這種原因是不能度量的。

　　閉環性：閉環就是每一級的Why可以覆蓋上一級Why，簡而言之，如果我們可以把這一級Why中的所有問題都解決，那么上一級的所有問題都不會出現。閉環性是檢驗我們分析問題的是否完整的主要手段。比如P7的Why1里面的三個問題都被組員認可，但我們采取了很多Action解決了之后，發現問題依然存在，就說明我們的5W分析違背了閉環性的原則。

　　經過上面分析，用了一個小時的時間，最終我們的P7延期問題分析小組終于完成了所有的5W分析。最后找到7個Root Cause：

　　因為Sprint開始估計項目Task時間不準確；

　　因為客戶的需求提供者要求不穩定，沒有文檔化；

　　因為結對檢查規定沒有執行；

　　因為Demo時準備的資料不具體；

　　因為演講者口語不好；

　　因為新加功能處Case沒有覆蓋；

　　因為新工具沒有培訓就使用。

　　這就是我們想要的結果，根據閉環性的原則，我們如果解決了這最終的7個問題，P7延期的問題就可以解決。于是我們制定Action，也就是改進措施，加入到5W表的Action列：

　　一個高效技術團隊或者生產團隊，需要有面對問題的勇氣，同時也需要解決問題的方法和能力，小的技術團隊可以坐在辦公室里用10分鐘的時間想清楚所有問題的脈絡，但對于人數較多的大型技術團隊，就需要一套好的方法論支撐。效率來源于工作流的流暢性，不應該讓困難的問題成為節點，不能讓不清楚的問題重復出現。所以需要5W方法論來自省和分析。

　　高效的團隊來自每個節點的高效，如果沒做好些細節，5W法則可以幫你找到。

　　每級的原因都需要半數以上的人首肯：因為分析小組成員都是問題的參與方，都會直接或間接為分析結果負責，這個也避免了敏感問題上組員人為規避的可能。比如有個案例就是：P7延期是因為項目經理沒有嚴格推進流程監控。這個原因可能會使在場人員考慮到項目經理的情緒，不敢提。所以Leader需要在這里提出來，引導大家，并且征得大家半數以上人同意。