析理
團隊很快就替客服問題說出了一個完整故事：新版本上線之後，詢問暴增；詢問一多，客服忙不過來；回覆變慢，客訴自然增加。這個故事聽起來順，甚至每一句都可能是真的。麻煩在於，故事一旦太順，人就容易把「說得通」誤認成「已經看清」。
現實通常沒有那麼守規矩。介面改了多少、使用說明夠不夠清楚、上線時間是否太趕、業務先前做了什麼承諾、使用者原本有什麼習慣、客服端能不能把資訊回到產品端，這些事情可能同時發生，也可能彼此放大。若只抓住最響亮的一條線，我們得到的是一個方便講述的故事，未必是足以施力的結構。
故事把事情排成一條線；析理把事情拆回它原本彼此牽動的樣子。
圖10｜故事是一條線，事情通常不是
把故事拆回結構
析理的第一個動作是理構。它不急著問「誰造成的」，而是先問：這件事由哪些部分組成，它們之間怎麼連。客服案例裡，產品設計、使用說明、上線時程、業務承諾、使用者習慣、客服人力與回報流程，都可能在同一個局面裡發揮作用。理構不是把事情畫得更複雜，而是把原先被故事省略的關係補回來。
接著是溯因。這裡的「因」不等於唯一根因，而是沿著現象往前追：哪些事情曾經推動它形成？例如操作介面變動可能增加困惑，說明文件不足可能讓困惑無法被自行解決，客服人力不足則可能讓已經出現的問題累積。它們作用的位置不同，不能因為都叫「原因」就混成同一團。
原因之外，還有條件
很多事情之所以發生，不只因為有某個推力，也因為當時具備了讓結果出現的條件。相同的介面變更，在一群熟悉產品的老使用者身上，可能沒有太大影響；放到第一次接觸的新客戶身上，結果就可能完全不同。辨條，就是把「推動事情的因素」和「讓事情得以這樣發生的條件」分開看。
這個區分很重要，因為條件一換，原因的力量也會變。上線時程本身不一定造成大量詢問，但若測試不足、說明尚未更新、客服也沒收到完整資訊，時程壓力便可能和其他因素一起把局面推向失衡。世界往往不是一顆骨牌推倒下一顆，而是許多條件剛好在同一時間對上。
圖11｜不是追一個根因，而是找形成條件與瓶頸
擇要：不是每一條線都要同樣用力
結構攤開之後，又會遇到另一個問題：線太多了。若每一項都同樣重要，思考只會從單線故事掉進另一種混亂。擇要不是把複雜重新粗暴簡化，而是問：哪個因素一旦改變，整體最可能跟著變？哪個地方雖然不起眼，卻牽動了最多後果？這是在有限注意力裡，選擇值得先看的位置。
回環：結果也會回頭改變原因
有些局面不只向前發展，還會繞回來加強自己。詢問變多，客服更忙；客服更忙，回覆變慢；回覆變慢，使用者可能重複詢問；重複詢問又讓詢問量更高。這就是回環。若只看最初那一刻，我們會以為問題停在起點；把時間拉長，才看見結果也可能成為下一輪的推力。
尋隘：找到真正卡住流動的窄口
最後是尋隘。瓶頸不一定是最初的原因，也不一定是最嚴重的錯誤，它只是此刻讓整體流動受阻的窄口。假如所有使用者困惑最後都只能靠人工客服消化，那麼即使前面有很多不同成因，人工客服的處理能力仍可能成為眼前最明顯的瓶頸。找到瓶頸，是為了知道哪裡值得先鬆動，不是宣布世界只有這一個原因。
這裡尤其要小心「根因」的誘惑。人很喜歡找到一個可以畫紅圈的答案，因為那會讓複雜突然安靜下來。但真實世界常常沒有一個單獨存在、拔掉就萬事太平的根。更成熟的問法，是看形成條件、關鍵因素、回環與瓶頸如何一起工作，再判斷哪裡值得先動。
故事讓事情容易理解；結構讓事情比較不容易被誤解。
析理做到這裡，還沒有替我們決定下一步一定要怎麼做。它只是讓施力不再只靠故事最響亮的那一句。當結構看清、關鍵與窄口也逐漸浮出來，有時路就會自然出現；也有時候，我們明明已經看懂，卻仍然發現所有熟悉的路都走不通。那時候，問題就不再是「再分析一點」，而是要問：是不是原來的邊界，本身就把我們困住了？
理構、溯因、辨條、擇要、回環、尋隘。看見事情怎麼形成，才知道力量該往哪裡去。