Problem Behind Question
工作上經常問題還沒被看清楚，只求快，要有成果，往往都只是做表面工作。
這篇整理自 2022/09/08、2022/07/22 我自己的思考的筆記，延伸 QBQ (問題背後的問題) 以及 如何意識到問題的存在，我自己深度體悟與昇華後的心得。
表象、議題、問題
普遍的 表象 都只是些 現象，還在 議題 (Issue) 階段，真正的 問題 (Problem) 還沒顯現。
需透過眾人的 提問 (Question)，經過 思 (Thinking)、辨 (Discussion)、分析 (Analyze)、總結 (Conclusion)，然後真正問題背後的問題：
Problem Behind Question (PBQ)
真正核心問題才會出現，接下來的行動才有機會是提出 解決方案 (Solution)、討論各個 執行計畫 (Plan) 的優缺、進行 執行策略 (Strategy) 謀劃，問題 (Problems) 才能真正的 被解決 (Resolved)。
定義用詞
定義前面提到幾個用詞：
Issue: 翻譯成議題，抽象名詞，泛指事件的統稱，包含已確立的、尚未釐清的、混沌不明的 …- 這個詞源源自於 Redmine，任何需要被處理的事情都抽象成 Issue。更多參閱 協同合作系統建制與導入 - 以 Redmine 為例
Question: 這裡我翻譯成提問，而不是問題，指的是針對事件的現象進行提問，大部分背後動機都是收集事件的資訊、上下文 (Context)Context: 背景資訊、上下文、前後文。提問過程，蒐集到的資訊，例如人事時地物等，以及因果關係。Problem: 問題，已經確立根本的因素，包含實際影響 (Impact)、關鍵觸發者 (Event Source)、範圍 (Scope)，有具體的問題根源 (Root Cause)Solution: 解決方案，針對問題 (Problem) 的因素而設計的處理方法。留意，是針對性地。Resolved: 已經解決，是個狀態。透過 Solution，把問題根源排除。Strategy: 執行策略，當問題被定義好了，通常不會只有一個 Solution，而是會有多個，然後衍生出各個執行計畫，這時候可以比較 Plan A / B / C 的優缺點 (Pros / Cons)，然後往下執行才有策略可言。
Problem Behind Question
改一下很常用的
QBQ: Question Behind Question
問題背後的問題，這是本很有名的書。
我把這段話改成這樣：
Problem Behind Question, PBQ
可以翻譯成：提問背後的問題
我想要強調的重點是：
在還沒把
議題 (Issue)的背景資訊 (Context)搞清楚之前，問題 (Problem)是無法定義。
我常常看到這樣的狀況：
在一些關鍵的問題，像是系統架構、商業決策，很常看到還沒確認問題，就開始急著討論解決方案、什麼時間完成，往往核心問題、核心需求都還沒搞清楚。所以最後解決的往往不是根本因素 (Root Cause)。
大部分 議題 (Issue) 剛開始看的現象，在背景資料 Ccontext) 不足的情況、情報不足，都還不足以確認、或者定義問題 (Problem)，貿然出手處理，如果經驗又不足，往往處理的，只是表面的東西。
註：
緊急事件的止血行為不在此範圍。
解決方案 (Solution) 處理的是 Problem 的根本因素 (Root Cause)，而提問 (Question) 是探索 Problem 的 Context，搜集情報的過程、疏理 Context、進而找到 Root Cause，然後才定義問題。
越是關鍵的問題，越是要嚴正以待，提問是很關鍵的一關。
開會是在浪費時間？
其實很常聽到同事說，開會是在浪費時間，因為沒有像寫程式一樣有具體產出。
開會的重點在於，問題 (Question) 提出來，經過思辨、搜集各種角度的想法、最後需要一個人 (最好是 PO)，去整理這些討論與問題，然後分析、總結脈絡，最後做策略性選擇。
通常問題就在於，沒有針對狀況提問，問題本身沒有經過精煉或者討論。
最慘的是，時間花了，卻沒有去 整理、分析、總結，所以開會當然會變浪費時間。
知道問題點在哪，就針對問題用技術能力去改善，而且是一針見血的執行，這樣的開會自然就會有意義，而且是非常有意義。
開會的方法請參閱：一場有效的會議
工程師的等級
把問題定義清楚，再來談技術。
而不是談了一堆技術，卻不知道在解決什麼。
我常舉的例子：
沒有方向的開車，跟酒駕沒什麼兩樣。
下圖大概是最好的描述。
未完 …
我先整理這段核心想法，延伸 QBQ (問題背後的問題) 以及 如何意識到問題的存在，未來再整理完整版。
相關的書
延伸閱讀
更新紀錄
- 2023/09/09 (Sat): 新增 工程師的等級
Comments
About
著作
演講
AWS Certifications
