2.2　探索環的4個關鍵環節

探索環（Discovery Loop）是指團隊通過一系列工作環節，能夠識別和定義業務問題，制訂相應的衡量指標，并找出低成本且可快速驗證的最小可行解決方案（Minimum Viable Solution）。這是一個理解真實需求、判斷優先級、再評估需求的過程，具體包括以下4個環節。

（1）提問：通過有針對性的提問與討論，找出團隊期望達成的業務目標或者希望解決的業務本質問題。

（2）錨定：針對該問題進行信息收集，經過分析，去除干擾信息，得到適當的指標項，并用其描述現在的狀況，以及我們希望的結果或狀態。

（3）共創：通過深入討論，找到所有可能的解決方案。它是一個深入理解和驗證問題的環節。

（4）精煉：結合實際情況，進行評估，篩選出最小可行性解決方案或方案的集合，以作為驗證環的輸入。等待它的真實反饋，再做價值判斷。

以下詳述實施這4個關鍵步驟的具體方法。

2.2.1　提問

該環節是持續交付“8”字環的起點。其目的在于通過不斷地提問，澄清客戶需求背后要實現的真正目標，以便找尋更多解決問題的方法，同時也有助于團隊成員從業務問題出發，充分理解業務問題。

敏捷軟件開發方法已經非常流行，“用戶故事”作為一種描述需求的方式也被廣泛采用，然而，軟件研發團隊更關注“需求是什么”的問題。例如，我們經常遇到下面這種團隊需求討論的場景。

業務人員：你按照這個文檔中的業務流程和界面樣例開發就行了。

開發人員：這個流程走到這里時，遇到（……）這種情況時，這個字段里應該包含哪些選項？

業務人員：你可以這么做（……）

開發人員：那這樣處理以后，接下來怎么辦？

上述的提問目標是澄清用戶的直接需求（即業務人員提出的解決方案）。從“滿足客戶需求”的服務心態來看，這樣的工作方式也沒有什么問題。然而，按照業務人員編寫的文檔開發，就能滿足他們真實的需求嗎？

探索環中的提問環節要求不僅僅是找到“實現什么”以及“如何實現”，更是要了解客戶需求背后要解決的真正問題“為什么要實現”，以便規劃更加方便快捷的驗證方案或解決方案。

由于角色慣性，從開始討論的那一刻起，我們就很容易跳過最重要的問題，也就是說，如何更好地為客戶解決真正的問題，而這恰恰是我們應該做的。因此，要通過持續提問，對問題進行深入探究。

設想一下，我們正舉辦一個為期一天且付費的小型線下聚會，主題是“DevOps和持續交付2.0”。午休期間，有位聽眾希望下午能夠喝上一杯星巴克咖啡。為了更好地為客戶服務，作為主辦方，我們耐心地詢問他“需要哪種口味的咖啡？”“熱的，還是冰的？”“大杯，還是中杯？”“希望什么時間拿到？”。

然而，所有這些問題都只是在問“做什么”和“怎么做”，并沒有任何一句問及原因。如果客戶想要解決的真正問題是“在下午聽講時不會因為困意而錯過了聽講”，我們也許有很多方法解決他的訴求？也許我們可以錄制視頻，這樣即使參與者在過程中開小差，在沙龍結束后，他們也能夠回顧一下沙龍的所有內容。我們還有更多的方法來滿足用戶不錯過精彩內容的需求，例如：

（1）沙龍的組織者可以將演講模式改成互動參與模式，增加互動環節；

（2）安排站立區，允許參與者走動；

（3）發言者的發言更有吸引力；

（4）在會場角落提供其他冷熱飲品。

這個假想的案例可能并不準確，但你一定已經領會了其中的含義。的確，為了解決客戶的問題，我們可能會找到很多種解決方案，但前提是我們必須發現“正確的需求”。所謂“正確的需求”，是那些能夠解決客戶真正想要解決的問題，而不一定是由客戶提出的解決方案。

因此，當我們接到一個工作任務時，我們應該更多地深入理解所要解決的問題，了解其背后的真正原因，不要過早地進入解決方案環節的討論，而忽視了對問題的討論。這樣才能更好地解決問題，而不僅僅是完成軟件功能的開發工作。

在“提問”這一環節中，組織者需要注意以下4點。

（1）問題域的提出方及解決方案的提供方代表盡量到場，參與討論。

（2） 多問幾個“為什么”。盡量避免因為感覺自己熟悉這個問題域，而過早地放棄探索。

（3）在條件允許的情況下，盡可能收集數據信息，以便作為問題理解和分析的佐證。

（4）移情，使用同理心。設身處地站在客戶或問題提出方的角度思考問題，還原客戶問題的場景。

2.2.2　錨定

當我們已經選定要解決的問題領域時，接下來就要確定我們要達成的具體目標與結果。“錨定”是設定目標以及目標分解的討論過程，其目的是確定要達成的目標以及可以衡量它的指標，并能夠指導后續的共創與精煉活動。

我們應該盡量避免模糊不清的目標，它會影響團隊成員之間的交流。清晰地描述目標讓我們自己知道當前所在的位置，離目標還有多遠。只有這樣，我們才能以終為始，結合現實環境，選擇和制訂相對合理的解決方案。清晰的目標通常是具體且可衡量的，并有時間限定。如果沒有時間限定，它很可能會成為一個企業愿景，就無法直接指導企業日常生產管理的具體活動，如圖2-2所示。

圖2-2　愿景與目標

最好的方式是讓目標可客觀衡量。有時，我們很難立即拿出一個可衡量的標準。但是，我們可以通過描述目標狀態，并根據這一目標狀態可能產生的結果來尋找可客觀衡量的目標結果。如何發現可衡量的指標呢？我們可以這樣來思考：如果某個產品滿足了用戶的需求，那么用戶會非常滿意，而用戶的滿意會帶來復購，同時會有更好的品牌知名度，從而帶來更多的用戶。那么，我們是否可以設定用戶數量和營業收入作為產品的指標維度，如圖2-3所示。這兩個指標的特點是：容易收集和容易量化，這有利于降低收集衡量指標的成本。

圖2-3　易收集、易量化的目標

例如，對某個提供新聞信息流服務（Feed流）的移動應用產品來說，企業希望“讓用戶喜歡它所提供的信息服務”。然而，“喜歡”是一個很難量化和佐證的目標，這就需要進一步錨定。如圖2-4所示，我們可以推斷，假如用戶喜歡這個產品，那么：

（1）用戶會閱讀更多的內容，而且會花費更長的時間。

（2）用戶會將產品推薦給朋友，朋友們也會喜歡并成為產品的用戶。

圖2-4　Feed流產品的指標選擇示意圖

從上面的假設中，我們提及3個易收集和易衡量的指標，它們分別是推薦朋友數、單位時間內的用戶數和單個用戶平均使用時長。這3個指標都能作為企業目標的指標維度。到底選擇哪些指標作為目標，需要根據企業現狀、產品處在的生命周期階段以及外部市場環境進行綜合判斷來決定。

另外，目標需要針對不同的組織層級而設定。一個企業的總目標應該是整個企業范圍內的目標，而不應該只是企業中某個團隊的目標。一旦制訂了企業總目標，企業中的每個團隊都要以它為方向，根據自身團隊的職責與性質，制訂各自相應的目標，并為實現它而集思廣益，群策群力。例如，提高用戶操作流暢度，提高API請求響應速度，推薦給用戶更多他們喜歡的內容，提高服務的穩定性，等等（如圖2-5所示）。

圖2-5　總目標與子目標

對于目標的選擇，應該遵循兩點：一是識別價值指標，而非虛榮指標；二是指標應該可衡量且可獲取，易于客觀對比。虛榮指標這一概念是《精益創業》一書中提及的。它是指讓你的產品效果看起來很好的那些指標，如注冊用戶數、網站最高訪問量等。雖然這些指標在一定程度上反映了產品的狀態，但并不是最有價值的衡量指標。相比較而言，日活躍用戶、月活躍用戶、日留存率、月留存率、有效購買率等可能是更好的價值衡量指標。

當然，對于更加具體的問題域或者產品階段，我們還會發現比活躍用戶、留存率等更恰當的價值衡量指標。這需要團隊根據業務特點及階段側重點自行發掘和定義。

2.2.3　共創

共創就是指：當我們制訂了想要達到的目標后，團隊為設法驗證或達成目標而找出多種可行性解決方案的過程。共創要在理解問題和制訂目標之后進行，否則會因為缺少目標約束，使得解決方案容易過于發散。這一環節的產出應該是很多帶有量化指示器的解決方案。事實上，每一個解決方案都是基于一定的假設條件或猜想得出的，而每一個假設都等同于一個風險項。因此，每個解決方案都只是“試驗方案”，試圖解決問題域中的某個具體問題。

這一環節的分析方法有很多，在這里介紹其中的兩個，一是“量化式影響地圖”；二是“用戶旅行地圖”。

1．量化式影響地圖

Gojko Adzic在《影響地圖：讓你的軟件產生真正的影響力》中解釋了什么是影響地圖，它是用Why-Who-How-What的分析法，通過結構化的顯示方式（如圖2-6a所示），讓團隊尋找達成業務目標的方法。對科學驗證來說，這還顯得不夠完整。我們不但應該知道“做XXX可以影響YYY”，還應該了解當前的影響程度，以及對實施后達到效果的預期。也就是，從業務問題域出發，按“角色—影響—方案—量化”的順序進行討論，如圖2-6b所示，從而盡可能多地發掘出可行性解決方案。我們可以稱它為“量化式影響地圖”。

圖2-6　量化式影響地圖

量化式影響地圖的具體制作步驟如下所示。

（1）角色：列出該問題域所涉及的人或角色。

（2）影響：針對每類人或角色，思考他們有哪些途徑可以影響該問題的解決（既可能是積極的影響，也可能是消極的影響）。

（3）方案：針對每一種途徑，討論并列出所有可能影響該問題的解決方案。

（4）量化：如果可能，盡量為每個解決方案定義一個可衡量的指標項。

下面，我們以某移動App應用的用戶增長目標（兩個月后達到20萬用戶）為例，可能涉及的內外部人員包括：（1）App的使用者；（2）推廣渠道；（3）客服團隊；（4）產品研發運營團隊；（5）內容提供商以及更多角色。按照上面給出的4個步驟，列出多種可實施方案，如圖2-7所示。

圖2-7　量化式影響地圖示例

我們有時無法馬上對所有指標進行量化。例如還沒有收集和統計過與指標相關的數據。此時可臨時性地收集一部分數據，并進行相應的推斷，通過一段時間的運行，進行指標量化的校準即可。例如，某公司希望提升研發效率10%（目標），其中一個方案是提升運維人員的部署操作效率。但是，之前并沒有收集過部署操作所需時間。因此，我們利用一周時間，對當周進行的兩次部署任務進行了數據采集，并據此進行推斷，共同定義了團隊認可的部署操作時間周期。另一種可能是希望衡量的指標較難直接量化。此時可通過一些過程指標或相近指標來替代。需要注意的是，這兩種情況都存在一定的偏差，因此在數據的應用過程中，應該格外注意。

2．用戶旅行地圖

用戶旅行地圖（user journey map）是指以可視化方式，將用戶與產品或服務之間的互動，按業務流分階段呈現出來。用戶旅行地圖通常包括以下4部分。

（1）用戶接觸點：旅程中的重要關鍵時刻（如短信消息、軟件操作界面等）。

（2）接觸階段：將整個旅程按順序劃分成不同的階段（例如商品查詢、下單、付款等）。

（3）用戶痛點：在用戶與系統服務的互動過程中，對什么感到不足。

（4）用戶情緒：在旅程中的每一個階段，有哪些情緒變化。

用戶旅行地圖的制作步驟如下。

（1）定義用戶：明確指定為某一類用戶定義用戶旅行地圖。

（2）定義任務或階段：在這些任務或階段中，會有哪些不同事件發生。

（3）用戶與服務接觸點的互動行為：在不同事件發生時，用戶如何操作，操作順序如何。

（4）用戶的動機：用戶在每個操作背后會產生什么樣的想法，有什么痛點。

（5）用戶的心理：在每個操作中，用戶心理會有哪些變化，情緒會如何起伏。

當將其操作流可視化以后，捕獲每個階段的相關信息（如操作時間、等待時間、操作次數等數據信息），通過用戶痛點發現其中可能存在的問題，從而提出相應的解決方案，以改善最初的業務目標。這些解決方案既可能是對原有流程的全面改造，也可能是對某個環節的局部優化。

例如，對線上電商服務來說，一個重要的問題領域是如何縮短從“用戶開始查找商品”到“最終收取貨物”之間的周期。針對這個問題，我們可以通過對整個流程建模（如圖2-8所示），對流程的各環節進行分析（該環節參與的角色、所花費時間及成本）。當獲得問題癥結的假設后，通過創建新的流程或者選擇一些環節進行方案優化，并確定量化指示器。

圖2-8　電商平臺的業務流程示意圖

對電商平臺上的商家服務來說，假如電商平臺的目標是“提升商家滿意度”，那么，很可能縮短賬期，商家就會對平臺更加滿意，而這可能需要對原有的財務結算系統和商家管理系統進行改造升級。

在“共創”這一環節中，需要注意兩個陷阱，分別是分析癱瘓（paralysis by analysis）和直覺決策（extinct by instinct）。分析癱瘓是指因為過度分析（或過度思考）而無法決策或采取行動，最終影響結果產出的一種狀態。通常是由于有太多的細節選項，或者過于尋求最佳或“完美”的解決方案，并擔心做出任何可能導致錯誤結果的決定。而直覺決策是指不做分析，基于匆忙的判斷或直覺反應而做出致命的決定。它是與分析癱瘓相反的另一個極端。

同時，值得注意的是，很多解決方案產生的結果是相互影響和關聯的。一個解決方案可能會影響多個結果指示器。

2.2.4　精煉

精煉環節就是對共創環節中得出的眾多方案進行評估，從中篩選出團隊認為最小可行性解決方案的過程。評估因素包括備選方案的實施成本、時間與人力、效果反饋周期，以及該方案對業務目標的影響程度。

在VUCA環境中，時間是最大的隱形成本。如果實現方案所需時間太多，我們就可能錯失了機會。而且，某些方案實施以后，需要經過一定的執行周期，才能看到它帶來的真實效果，這也會增加時間成本。我們希望盡可能多地選擇試驗方案，因為每個方案都有可能有助于解決我們的問題，達成我們的目標。

作為一個電商網站，Etsy的搜索導航條在2007年如圖2-9所示。盡管當時并沒有認為這個設計是永久性的，但直到2012年，它也沒有發生很大的變化。事實上，大多數買家并不知道怎么用它。例如，幾乎根本沒有人使用其中的搜索項“商店”（Shops）。

圖2-9　Etsy的搜索導航條

在這5年中，搜索下拉框上已經增加了很多內容，承擔了過多的職責，而且并不是所有項目之間都具有直接關聯性。因此，團隊決定對其進行大改造，于是專門成立了一個改造項目。團隊成員提出了很多改造的想法和解決方案。最終他們精煉出一份任務清單，如下所列：

（1）重新設計頁面上的搜索區；

（2）默認為“所有項目”；

（3）更豐富的自動化推薦提示；

（4）在搜索結果列表中給出推薦的商店；

（5）可以將常用過濾器加入搜索收藏夾；

（6）將搜索欄分別放到商品和商店頁面上；

（7）刪除原有的搜索下拉列表。

其中，每一項任務的開發時間都很短，而且每項改造任務的前后效果都可衡量，并且任務之間相對獨立。在改造過程中，每當完成一項，都可以進行評估，并且有機會根據每一次的評估結果修訂原有的項目執行計劃，以更好地達到業務目標。

在上述精煉任務清單中，有一些任務是成功的，有一些任務則并不成功。如圖2-10所示，在第一項改造（在頁面上增加一個商品搜索區）后，用戶數據顯示，幾乎沒有用戶注意到它；而在第三項改造（增加自動化推薦）后，數據效果則比較明顯。

圖2-10　Etsy網站搜索導航的兩個優化項

因此，我們不難看出，即使是一項巨大的改造工程，其解決方案也可以是一組迷你方案的集合。精煉的目標并不是為了刪除在共創階段得出的解決方案，而是將它們按優先級排列，并讓團隊將解決方案進一步分解，順序選出共同認可的最重要改進項，并確保它能夠盡早被驗證。

通過精煉之后，被選擇的方案就可以進入驗證環了。那么，如何判斷我們已經準備好，可以進入驗證環了呢？一個簡單的方式就是你能夠將探索的成果以下述形式表述出來，并且達成團隊共識：

我們相信，通過實現（xxxxx這樣的最小功能組合），我們的指標可以達到（yyyyy程度），說明我們關于（zzzzz）的假設是成立的。