不只是解決問題：找到雜訊中的 Root Cause

設計師的核心工作一直都是解決問題。但在 AI 發達的今天，解決問題的手段變得前所未有地多，反而讓「如何定義問題」變得更重要。

在實際的工作環境中，問題往往不只來自任務本身，還包含流程與人際溝通。這些因素交織在一起，讓問題看起來模糊又複雜，也更難找到真正的根因。

而比問題沒有被解決更糟的是——投入大量時間與成本後，才發現當初定錯了問題。不只讓事情沒有改善，還帶來更深的挫折感以及時間精力的浪費。

在過去的工作中我反覆經歷這樣的情況。直到進入現在的公司，接觸到一些思考工具後，才逐漸建立起一套拆解問題的方式，幫助我在面對複雜情境時能更有效地找到關鍵問題。

因此這篇文章，我想分享在工作中整理出的一套問題思考脈絡。

心態對齊

工作情境中，多數情況是多人一起 Retro¹ 工作上遇到的困難。為了避免變成抓戰犯大會，事先需要先對齊心態，這場會議（或個人復盤）是為了使事情變得更好。

打個比方：開發中的資訊沒有及時資訊同步回團隊導致重工，這是因為 A 來開會，回去後沒有和團隊同步資訊。所以問題在 A 身上，A 下次要記得。這就屬於無效結論，這類無效結論之所以危險，是因為它給了團隊一種『問題已解決』的假象，卻忽略了系統性的漏洞。

• 這是流程問題還是一次性的隨機問題？(事件釐清)
• 這件事情的發生頻率多高？造成的影響多大？(影響範圍、價值)
• 我們能做什麼，以及我們想花多少成本避免這件事繼續發生？(行動、成本)

以『我能做什麼』為出發點來探索問題與解法，才能得到對事情推進有效的答案。將期待放在影響圈外的「他人」，讓事情模糊地停留在對個人工作態度的期待上反而是高風險投資，因為我們無法控制他人想法和行為，這件事下次仍有可能發生。

而以『我能做什麼』出發，並非要將責任攬在自己身上，而是去思考：我有什麼手段（工具、流程、機制）能讓這件事在未來自動化地避免？

事實復盤 (ORID)

Retro 中我們很常用到焦點討論法 (ORID) 這個提問與思考框架。

以某個專案的 Retro 為例，我司常見的流程是會先請大家寫出合作中的心情和感受，目的是藉由比較軟性的題目讓大家快速放鬆地進入狀態，也是為了初步理解大家對這次合作的狀態、心情。

心情和狀態分享階段我們不會做任何評論，接受任何想法和感受。

而在感受分享之後，會請大家在 5 分鐘內寫出在這個專案中你看到的事實，好的、壞的都可以。例如工作溝通因為什麼事情不通暢、資訊沒同步導致一個問題要重複好幾次、某個人注意到了架構問題並且及時提出討論，讓後續的開發更順暢。

由於每個人看到的角度不同，這些分享出來的事實就會組合成這件事在團隊眼中的全貌。後續就可以請大家將這些事實分組，變成較大的區塊去看哪些是我們希望更好，哪些是希望保持的。

當分出的組別眾多時，會請大家在事件上選出 1-3 個 感受好＆不好的事件，幫助我們釐清哪些事在有限時間內更值得被討論。

到這裡基本就完成了較為完整的事件復盤。

收斂 / 定義問題

完成了復盤，找到了想要改善的問題，基本上就可以繼續更深的探究問題發生的原因。如心態對齊提到的模擬情境。我們需要針對事情的頻率、影響範圍，以及發生的根因來做探究。

比較容易找到根因的問題，例如：

1. 資訊同步不及時，是因為離開會議後被其他事情打斷。 這屬於流程可以改善問題。
2. 開發完才發現畫面與 PO 、 Designer 預期不符。盤點過程，如果開發前再次對齊就能減少問題發生，這也屬於流程問題。

這些都可以直接進到 Decision 的階段，決定我們要怎麼解決、後續行動是什麼。

而比較複雜的問題，例如：反覆的發生任務延宕，無法在 Sprint² 內完成，這類可能有各種複雜原因在內的問題，如果在一場 Retro 內無法完成，則可以先暫停，約下一場會議繼續找尋根因。

需要特別注意是，會議同樣是需要時間與精力成本的投資，因此約下一場會議的小前提是：「確保大家都同意這是一個值得花時間解決的問題」

Action : 讓改變落地，推進成長與變化

如果沒有行動，那麼即使我們發現了重要問題也很難讓事情推進。因此 Retro 後很重要的一個環節是訂定 Action³。當我們要訂定 Action 時，有時會建議可以使用 SNT 的格式來讓整個行動更具體，避免訂出過於模糊的 Action 反而讓改變無法落實。

以前面舉的問題為例：資訊同步不及時，是因為離開會議後容易被其他事情打斷導致遺忘。

• 無效的 Action 是： 之後要更小心，出會議室要馬上找團隊同步資訊。（太多不可抗力因素）

• 有效的 Action 是： 之後的 每一次 會議 結束前 必須在公開的群組或是共用文件區發送會議記錄，並且 Tag 需要知悉的相關人員。(包含時間、次數、具體行動)

*SNT 不是每件事需要嚴格遵守的標準，但他是一個可以拿來檢視、評估可行性的結構。

而為了確保 Action 發生，會議結束前，這些大家一同產出的 Action 需要有 Action Taker 認領。但雖然有 Action Taker⁴ 存在， Action 的行動責任依舊在所有與會者身上。Action Taker 是確保事情發生的守護者，而非孤軍奮戰的苦主。行動的責任依然屬於所有與會者，我們是為了彼此的進步而訂下承諾。

除此之外，Action 是為了推進事情往好的方向前進，但不是所有 Retro 都會有 Action 產生。一些常態性的團隊合作 Retro 不一定會有問題被發現，或是發現的問題暫時沒有太大影響，因此只有共識產生，沒有 Action。而有時候成員身上堆積事物過多，也有可能產生是否真的需要採取行動的討論，這就需要說到優先序。

優先序：不是每個問題都需要被解決

生活與工作中總是會有各式各樣的問題需要解決，每當一個問題解決了，總會有新的、更緊急的問題出現。但是時間和精力有限，我們只能投入在最有價值的事情上，讓我們的時間和精力效益最大化。

那麼怎麼判斷價值的高低來判斷優先順序呢？首先需要看這些問題在這兩個四象限圖的位置分別在哪：

當這兩張地圖重疊時，我們會發現那些「重要且緊急」且「高影響、低成本」的項目，就是我們必須優先解決的重點項目。當我們能看清這些刀口在哪裡，那種「漫無目的」的焦慮感自然會消退。

看見問題卻選擇不處理，固然會帶來不安全感，但很多時候，選擇不解決哪些問題，比選擇解決哪些問題更需要勇氣。只要你與團隊對這樣的價值選擇達成共識，那麼你選擇留下的，和你決定放棄的，都具備同等的重量與專業價值。

以上大概就是我平時在工作或生活上遇到問題時會使用的流程思路。 但有時我遇到的問題未必是團隊的。當個人遇到了一些工作、生活上的問題想解決時，單純的 ORID 可能會因為人數和觀點較為局限無法深挖出更底層的問題，這時我會視情況採用譬如 5W、魚骨圖、邏輯樹 等等工具進行思緒的發散與整理。

篇幅限制就不再多說，如果未來有相關文章再分享使用情境和心得。 不過小提醒！生活上遇到的困難更多時候難以單純用理性的方式分解，如果是和家人、伴侶、朋友溝通情況， ORID 和 SNT 之類的東西就太硬了反而容易吵架！建議還是拿來自己梳理就好XD！

在這個資訊爆炸的時代，感謝你願意慢下時間閱讀這篇文章，如果有任何問題或是想分享的知識或看法，歡迎留言或來信！

註解：

1. Retro : 回顧會議，敏捷開發中短期衝刺結束時舉行的會議。目的是反思過去的合作、溝通、成果，找到可保持和可優化的地方，持續優化團隊效率。 ↩︎
2. Sprint : 敏捷開發的衝刺週期，通常是一週或兩週為一個循環，開發團隊需要在這個週期內完成和 PO 共同訂定的衝刺目標。 ↩︎
3. Action : Retro 會議後，針對做得不好的地方提出的「具體改善行動」。 ↩︎
4. Action Taker : 促使改善行動發生的人。 ↩︎