Architecture Journal
企業架構實務（十）：企業架構訪談技巧，如何從受訪者取樣、事件追問與交叉驗證建立可追溯的現況證據與決策依據？
這篇要回答的問題
企業架構分析很少能只靠文件完成。系統清單可能過時，流程圖可能和實際工作不同，責任矩陣可能寫得很完整但沒有人照著做。訪談因此很重要，但訪談本身也有風險：
- 每個角色只描述自己看到的局部
- 受訪者把偏好的解法當成現況
- 問題被說成別人的責任
- 訪談者只尋找支持原本假設的答案
- 會議結束後只留下印象，沒有可追溯證據
EA 訪談的目的不是取得一個大家都同意的故事，而是找出事實、假設、分歧與需要進一步驗證的邊界。
訪談要回答四個問題
訪談目的可以收斂成四個問題，而不是先準備一長串題目：
- 現在怎麼運作？ 了解 As-Is 現況、角色、流程、系統與資料。
- 哪裡有痛點？ 找出效率、品質、風險與使用體驗問題。
- 為什麼會這樣？ 透過追問找出直接原因與根因。
- 未來需要改變什麼？ 確認必要成果、約束與成功定義，再由有決策權的角色形成 To-Be 方向。
這四個問題可以把訪談和後續的現況分析、gap、願景與目標狀態接起來。
用 What、Who、How、Sequence 設計蒐證
PMI-PBA 的官方考綱把 requirements management plan、elicitation tools and techniques、stakeholder analysis 等列為相關能力。[1] 本文借用這個範圍，把訪談前準備工作化成四個面向；What、Who、How、Sequence 是本文採用的整理方式，不是 PMI-PBA 的固定分類：
| 規劃項目 | 核心問題 | 產出 |
|---|---|---|
| What | 要蒐集什麼資訊，要形成什麼結論？ | 訪談大綱、問題清單 |
| Who | 誰知道這些資訊，誰對結果負責？ | 利害關係人清單 |
| How | 用什麼方式取得，才能兼顧深度、廣度與證據？ | 訪談、工作坊、問卷、文件分析或現場觀察 |
| Sequence | 先後順序如何安排，哪些資訊要先取得？ | 訪談計畫與排程 |
受訪者選擇可以同時參考 Power／Interest Grid 與 RACI，但兩者不能取代取樣判斷。PMI 的業務分析文章也把 Power／Interest Grid、SME 識別與 stakeholder／requirements RACI 放在 stakeholder analysis 的脈絡中。[2] RACI 適合說明工作或決策的責任，不代表只有 A（Accountable）、R（Responsible）和 C（Consulted）才知道現況。除了這些角色，也要找實際執行 workaround 的人、受影響的使用者、非正式決策者、外部夥伴，以及能提供反例或不同定義的人。I（Informed）通常不是主要資訊來源，但若其掌握決策背景或影響範圍，仍可能需要訪談。
訪談順序不必固定成「先高層、後第一線、最後驗證」。可以先確認決策問題與範圍，再盡早接觸一線案例或原始紀錄，避免高層敘事成為後續訪談的預設答案；之後再依照缺口安排策略、流程、系統與營運角色的訪談，持續用紀錄交叉驗證。高階主管或資訊長通常適合說明策略、預算與成功標準；部門主管通常適合說明流程、KPI 與跨部門問題；IT／BU working level 則通常適合驗證實際步驟、系統限制與導入風險。
訪談前先定義要做的決策
沒有決策問題的訪談，很容易變成「請介紹一下目前系統」的漫談。訪談前至少先寫清楚：
- 這次分析要支援哪一個投資、風險或轉型決策？
- 要確認 current state 的哪一部分？
- 哪些假設可能會改變 target state 或 roadmap？
- 需要哪些證據才能進入下一個決策閘門？
- 哪些內容是探索，哪些內容已經有正式決策？
- 誰擁有這個決策、何時必須做出決定，以及判斷門檻是什麼？
例如，不要只問「客戶資料系統目前有什麼問題」，可以改成：
為了判斷是否需要建立新的查詢能力，我們需要確認客戶欄位的來源責任、更新延遲、錯誤處理與實際人工 workaround。
這樣受訪者比較容易提供具體情境，訪談結果也比較容易回寫到 evidence register。後續可以再接到現況能力評估、gap analysis與影響評估與優先排序。
受訪者不是職稱清單
同一個系統需要從不同角色取得不同證據。可以用問題與責任來安排訪談對象：
| 角色 | 主要要理解的內容 | 適合追問的問題／證據 |
|---|---|---|
| 業務／流程 owner | 目標結果、例外、風險與業務優先級 | 哪個流程失敗時代價最大？多久發生一次？ |
| 產品／需求角色 | 使用情境、需求變更與價值排序 | 哪些需求被迫用人工 workaround？為什麼？ |
| 實際使用者／受影響者 | 真實操作、替代流程、客戶或合作夥伴影響 | 最近一次如何完成工作？哪一步最常繞路或等待？ |
| 系統／服務 owner | 系統責任、契約、依賴與變更方式 | 最近一次跨系統變更如何完成？誰需要配合？ |
| 開發／測試團隊 | 實作限制、驗證方式與返工 | 哪些改動最容易造成回歸或等待？ |
| 營運／支援團隊 | 事故、容量、觀測、回復與長期負擔 | 最近一次異常如何定位？哪個資訊缺失？ |
| 資安／法遵／資料治理 | 權限、稽核、資料使用與保留限制 | 哪些規則有正式證據？哪些靠人工判斷？ |
受訪者的價值不在於職稱高低，而在於他能否提供與決策相關的觀察、紀錄或責任資訊。高階角色能提供方向與取捨，第一線角色往往更清楚實際流程如何繞路。
問法要從具體事件開始
先問具體事件，不只問最近一次
抽象問題容易得到抽象答案；只問最近一次也可能受到回憶與事件嚴重度影響。與其問「流程是否有效」，不如要求受訪者比較最近一次、最嚴重一次、最常見一次或最昂貴的一次：
- 最近一次這個流程從需求到上線花了多久？
- 最近一次、最嚴重一次與最常見一次是同一個案例嗎？如果不是，差異在哪裡？
- 最近一次資料不一致是怎麼被發現的？
- 最近一次跨服務變更需要通知哪些團隊？
- 最近一次事故從告警到恢復經過哪些步驟？
- 最近一次有人提出例外時，誰做了決定？
具體事件可以讓訪談從理想流程回到實際行為，也比較容易要求對應的紀錄。
再問邊界與責任
事件描述清楚後，繼續追問：
- 哪個系統或角色負責做這個決策？
- 哪個資料可以被誰修改？
- 這個介面由誰維護，變更時誰需要被通知？
- 出錯時哪個團隊先處理？什麼情況會升級？
- 如果 owner 不在，誰可以做替代決策？
很多 EA 問題不是完全沒有流程，而是流程在交接、例外與責任轉移時失效。這些追問通常比詢問「是否有標準流程」更能看見真實邊界。
最後問代價與例外
- 如果不改變目前做法，半年後最可能增加什麼成本？
- 哪個 workaround 已經被當成正常流程？
- 哪些例外原本應該是暫時的，現在卻沒有退場日期？
- 哪個限制是技術造成的，哪個其實是政策、資源或責任造成的？
- 有沒有一個低成本的方式先驗證這個判斷？
這些問題會把訪談內容連回 impact assessment 與 roadmap，而不是停在抱怨或願望。
把事實、陳述與推論分開
訪談記錄不應該把所有句子都當成同一種證據。下表同時保留陳述類型與驗證方式；它們不是完全互斥的標籤，一句受訪者陳述也可能在補上紀錄後變成已驗證的事實：
| 類型 | 例子 | 如何處理 |
|---|---|---|
| 已驗證事實 | 監控紀錄顯示上個月有三次查詢逾時 | 連結原始紀錄，標記時間範圍、資料 owner 與查詢條件 |
| 受訪者陳述 | 服務 owner 認為每次變更都需要人工通知 | 找變更紀錄與其他角色交叉確認 |
| 現場觀察 | 團隊常在發版前才發現 consumer 不相容 | 記錄觀察時間與範圍，追查測試、契約與 incident 證據 |
| 推論 | 缺少 contract test 可能是返工的主要原因 | 標記假設，設計驗證行動 |
| 未知 | 尚未知道資料延遲的可接受上限 | 指定 owner 與下一個確認方式 |
這種分類不是為了降低受訪者的可信度，而是讓後續討論知道哪些內容可以暫時採用，哪些仍需要補證據。沒有原始紀錄支持時，「可驗證」不等於「已驗證」。
用交叉驗證找出真正的分歧
同一個問題至少可以從三個角度核對：
- 業務結果：這個問題是否真的影響流程、客戶或風險？
- 系統行為：系統、資料、介面或指標是否呈現相同現象？
- 交付與營運：團隊是否在變更、事故或支援過程中付出相同代價？
如果三者不一致，不要急著選一個版本當答案。先把分歧記錄下來，再判斷它是 gap、定義不一致、時間範圍不同、資料品質問題，還是不同角色的合理視角：例如業務認為資料即時，系統設計卻只提供批次更新；產品認為 API 穩定，consumer 團隊卻持續因欄位變更返工。
可以在 evidence register 裡保留：
- 哪些角色支持這個觀察
- 哪些角色提出不同描述
- 差異發生在哪個定義或時間範圍
- 下一個需要驗證的紀錄或實驗
Evidence register 的最小欄位
如果訪談結果要接到 current state、gap、impact 與 roadmap，evidence register 至少要能回答「誰在什麼時間、以什麼資料，支持哪一個判斷」：
| 欄位 | 用途 |
|---|---|
| ID | 讓訪談陳述、文件、指標與後續決策可以被引用 |
| Claim／Current observation | 清楚寫出目前的主張或可觀察狀態，避免只留摘要印象 |
| Source | 訪談識別碼、受訪角色、文件、系統或紀錄位置 |
| Time／Scope | 觀察期間、案例範圍、適用流程或系統邊界 |
| Evidence type／Status | 受訪者陳述、觀察、已驗證事實、推論或未知；以及未驗證、部分驗證或已驗證 |
| Corroboration／Disagreement | 支持、反對或尚未交叉檢查的角色與資料 |
| Related decision／Gap／Impact | 這筆證據影響哪個決策、缺口或業務結果 |
| Owner／Next check | 誰負責補證據，以及下一個驗證行動與期限 |
原始訪談筆記、受訪者陳述與分析者推論要分開保存；register 保存的是可追溯的判斷摘要，不是把不同層次的內容混成一段話。
用半結構式訪談從探索走到結論
訪談執行可以分成三步，但三步通常會來回迭代，不是一次性的直線流程：
- 探索式半結構訪談：所有角色都使用共同的核心問題，再依其責任與經驗開放追問，探索尚未知道的方向、痛點與限制。
- 驗證式半結構訪談：把已出現的假設、具體事件與數據帶回不同角色，確認真實性、嚴重程度、適用範圍與反例；不是只對第一線人員使用固定問題。
- 整理與收斂結論：把訪談寫回 evidence register，保留共通議題、分歧、轉型假設、證據狀態與後續驗證行動，再決定是否需要補訪。
不要一開始只用結構式問卷，也不要直接問「要改什麼功能」。先探索問題，再驗證假設，才能避免把訪談限制在預先想好的解法裡；當需要估計普遍程度或比較群體差異時，問卷仍可以作為後續補充。
用 5 Whys 往根因追問
受訪者常說的是症狀，例如「系統不好用」、「報表太慢」、「資料不準」或「整合很困難」。5 Whys 的重點不是一定問五次，而是持續追問「為什麼會這樣」，直到找到可以介入的根因。它產生的是待驗證的因果假設，不會自動證明只有一個根因；跨系統問題通常需要同時檢查流程、資料、技術、責任與治理因素。
例如護理人員需要重複輸入病患資料，以下只示範一條可能的假設鏈：
重複輸入（已觀察，仍需保留實際案例）
→ 同一筆資料要分別輸入不同系統（確認欄位、角色與頻率）
→ 兩個系統缺乏可用的共享或介接機制（待驗證）
→ 可能是介接能力不足、資料 owner 不明，或受到資安／政策／契約限制
→ 可能與不同時期建置、缺少共同整合原則有關（待驗證）不要把這條鏈的最後一格直接寫成「組織缺乏整體資訊架構與治理規劃」。如果只停在「請做一個按鈕」或「請增加欄位」，可能會改善操作表面，卻保留真正的資訊架構問題；但反過來，若未驗證就直接歸因於治理不足，也可能錯過較小、可逆的流程或介接改善。
傾聽內容、脈絡與落差
主動傾聽不只是記下受訪者說了什麼，還要注意：
- 內容：受訪者描述了什麼事實與資訊？
- 脈絡：為什麼在這個角色、流程或限制下會這樣說？
- 落差：不同角色的說法是否互相矛盾？
遇到「每天都要重複輸入很多資料」這類描述，可以先用中性的覆述確認：
我聽到的是：你每天需要在不同系統輸入同一批資料。可以帶我走一次最近的案例，看看涉及哪些欄位、交接與限制嗎？我先把「跨系統整合不足」記為待驗證假設。
覆述不是替受訪者下結論，而是把目前的理解攤開，讓對方修正，也讓後續紀錄知道哪些內容已經確認、哪些仍是分析者的假設。
EA 訪談要特別補問的架構問題
一般需求訪談容易停在功能、痛點與願望；EA 訪談還要把觀察接回跨域邊界與長期治理：
- 這個問題影響哪個業務能力、價值流或業務結果？能力的責任邊界在哪裡？
- 哪些資料是誰的 owner？資料如何建立、修改、交換、保存與淘汰？
- 哪些系統、團隊、供應商或流程形成依賴？變更時誰需要被通知或核准？
- 真正的約束是技術、資安、法遵、政策、預算、技能，還是決策權不清？
- 目標狀態需要哪些非功能需求，例如可用性、延遲、可追溯性、恢復時間或稽核性？
- 如果不能一次完成，過渡狀態、可逆的小實驗與淘汰條件是什麼？
一個訪談流程
訪談前
- 寫下決策問題與初始假設
- 依 People、Process、Technology、Information 分配觀察範圍
- 選擇能提供不同視角的受訪者
- 預先取得架構圖、流程、紀錄或指標，但不把它們當成已驗證事實
- 告知訪談目的、使用方式與預計輸出
- 先確認是否錄音、如何匿名化、誰可以查看，以及受訪者如何更正紀錄
- 指定記錄者、時間盒與訪談後的摘要確認方式
訪談中
- 先請受訪者描述實際事件，再談理想做法
- 追問時間、頻率、責任、例外與影響
- 把關鍵名詞寫下來，確認不同角色是否使用同一個意思
- 區分觀察、意見、假設與解法
- 追問什麼證據可以支持或推翻目前假設
- 不在當場急著承諾方案或責怪個人
訪談後
- 將內容回寫到 evidence register
- 把未知與分歧列成待驗證項目
- 對照系統紀錄、流程文件與其他訪談
- 將訪談摘要交給受訪者確認事實、範圍與名詞，但不把分析結論交由單一受訪者審批
- 更新 current state、gap、impact 或 owner
- 把需要決策的事項帶到適合的治理節點
參考資料
本文的 What／Who／How／Sequence、evidence register、半結構式訪談流程與 EA 追問清單，是本筆記的工作模型；以下來源只支持 PMI-PBA 的業務分析、蒐證與利害關係人分析脈絡，不代表本文整套分類是外部標準。
- [1] Project Management Institute，〈PMI Professional in Business Analysis (PMI-PBA) Examination Content Outline〉，2013。
- [2] Greta Blash、Steve Blash，〈Project Management and Business Analysis: A Real Life Partnership〉，PMI Global Congress 2015—North America，2015。