重構解決方案

直接從問題得出解決方案是很誘人的，而且大多數開發人員都接受過這樣的培訓。不幸的是，由于在回顧活動中出現的問題有時不能被立即理解，所以你需要在開始研究解決方案之前先檢查它們。在收集數據之后，你需要查看問題背后的原因。這就是前言中所說的“生成洞見”階段，這個階段是不能跳過的。

在這個階段可以采用一些活動。一個簡單的活動是詢問便簽背后的故事，以便了解導致這個問題的原因。其他還有魚骨圖和5個“如何”活動。圖1.1所示為魚骨圖。

魚骨圖

魚骨圖是一種根因分析活動，引導師以不同的主題畫出一個魚骨架，比如人員、流程、經濟和技術，將問題背后的不同類型原因作為魚骨進行可視化。然后，引導師要求團隊成員將他們所能想到的不同原因寫在便簽上，并把它們貼在魚骨上。最終會在一條魚骨上顯示出許多不同的想法，回到可能導致問題的原因。也許你會發現，大多數的想法都集中在一個特定的類別中，比如流程或技術，這就提供了下一步工作切入點的輸入。這種技巧通常用于回顧活動的“生成洞見”階段。它也稱為“石川圖分析法”(1)。

以前，我使用過一個叫“5個為什么”的活動來進行原因分析，但由于我從John Allspaw（2014）那里獲得的洞見，我現在改為使用5個“如何”。

5個“如何”

5個“如何”是一種刨根問底、反復詢問的技巧，用于探索特定問題背后的因果關系。該技巧的主要目標是反復詢問：“這是如何發生的？”以此來確定缺陷或是問題的根本原因。每一個答案都是下一個問題的基礎。名稱中的“5”來自于行業中對解決問題所需迭代次數的說法。

很少有問題只有一個根本原因。為了發現多個根本原因，可以重復使用這個方法，每次提問的順序可以不同。

不過，關于探究哪些問題以及需要用多長時間繼續尋找其他根本原因，該方法沒有做硬性規定。因此，即使嚴格遵循該方法，結果仍然取決于相關人員對知識的理解和對問題追根溯源的堅持。

Allspaw（2014）解釋說，問“為什么”，會使得人們試圖為問題找到一個原因，甚至可能導致相互指責；而問“如何”，則可能獲得一段敘述，包括若干個原因。把它變成一個指責游戲顯然是不可取的，更何況想要在一個像軟件開發和團隊協作這樣復雜的系統中尋找出一個原因，這幾乎是一種近乎于輕信的過分樂觀了。你甚至可以在個人層面上嘗試這樣做：下一次當事情沒有按照自己的預期發展時，試著問問自己“如何會這樣”，而不是“為什么會這樣”。

在“生成洞見”這個環節，需要團隊對所有便簽上的內容進行深挖，找到內容背后真實的故事以及其暴露出來的真正原因。

正如《參與式決策引導師指南》（2007）中描述的那樣，每一次會議——包括回顧活動，都有一個發散與收斂的生命周期（圖1.2）。我們希望，一開始就能將會議目的以及期望達成的結果統一在一個較小的共識范圍內；或者至少，應該對會議的主題達成一致。然后我們就進入了發散階段，在這個階段，討論會出現分歧與意見沖突；接下來會是討論區，大家進一步討論問題，不是為了尋求意見的一致，而是為了更多地了解這個話題；在討論了一段時間之后，會議需要進入收斂階段，我們要努力縮小范圍并／或達成共識。如果團隊不能達成一致意見，至少可以接受分歧，并確立接受分歧的條件和理由。

首先，要就主題達成一致意見，類似于回顧活動的“設置場景”階段。回顧活動的發散部分是“收集數據”和“生成洞見”階段。回顧活動的這一部分并不簡單，而且是非常重要的一部分。討論區可以與“生成洞見”階段的最后一部分以及“做出決定”階段的開始部分相聯系起來。收斂是“做出決定”階段的關鍵，當你在回顧活動的最后做出決定時，就是“結束回顧活動”階段了。一定要確保回顧活動的五個階段都逐一完成，并生成深刻的洞見，而不是為了盡快地進入正題就草率地得出結論，從而過早地完成收斂。