在組織裡推動事情，最困難的往往不是技術上的執行問題、不是成本問題、溝通問題、協作問題，困難的是：

如何讓高層、主管、團隊成員 意識 (Awareness) 到：這是一個必須被正視的問題。

當問題被正視了，大家都 Awareness 了，接下來才有開始討論如何解決、如何 有效定義目標與執行、落地、資源才會進來 …

名詞

先定義幾個名詞：

1. 現象：Appearance，問題的外在特徵、表象，像是網站回應速度變慢了。
   • 舉例：感冒的現象就是 體溫上升
2. 症狀：Symptom，問題的內在特徵、問題，像是網站的 5XX 問題、內部記憶體問題。
   • 舉例：因為感冒的症狀打噴嚏、流鼻水、發燒、喉嚨痛
   • 如果不是針對問題，那可以用 特徵 (Characteristic) 對應，例如 Apple 產品的特徵是極簡
3. 特徵：Characteristic，問題症狀 是一種負面描述，症狀另一種形容描述就是 特徵。
   • 所謂 正常系統 的特徵，其實只是種 異常現象 中的一種特例。請參考 Slogan in SRE
4. 感知：Perception，察覺、體察
   • 就像人類的五感，或者動物生理的接受器、機器的感應器 (Sensors)
   • 抽象感知：像是對於聲音／音樂的靈敏度、對於市場變化的體察 …
5. 認知：Awareness，意識、意會。
   • 感知收到的訊息，透過經驗、分析、理解後，產生資訊、意識，最後產生行動。

這幾個名詞，以 發現問題 來說，發生的先後次序：

1. 現象 -> 2) 症狀 / 特徵 -> 3) 感知 -> 4) 認知

這些名詞，後續會因為情境、文句通順考量，而交錯使用。

相關文章：

• 如何有效的回報問題 (How to Report Problems Effectively)：描述現象、症狀在問題回報的概念
• Study Notes - CloudWatch：Log 分析流程的概念 蒐集 -> 儲存 -> 分析 -> 呈現，類似於 現象 -> 症狀 -> 感知 -> 認知

感知現象、認知症狀

感知就像人類生理的五官，嗅覺、聽覺、味覺、觸覺、視覺，讓成員 認知 (Awareness) 到問題的症狀是第一步。大部分的人對於存在的 現象 (Appearance) 比較沒有察覺能力，當問題的 症狀 (Symptom) 被發現時，通常已經是見血了，見血的生理症狀最強烈：痛，在系統就是炸鍋，所以才有這篇 系統發生異常時，第一時間如何快速止血？。特別是抽象問題的現象是最難被感知到的，像是 結構性問題、溝通成本、系統架構、業務架構 … 等比較抽象的。

舉個關於溝通的例子來說，我在 導讀持續交付 2.0 - 談當代軟體交付之虛實融合 的分享中提到的現象：

類似的溝通案例，我在觀察組織運作時，實際上遇過好多次，舉一個最近 (2019/09-10) 發生的案例：

為了滿足一個業務需求，而 PO 或者 Tech Lead 覺得是很簡單的問題，但是負責的同仁卻為了資源與技術架構問題，在 *五、六個團隊- 之間 *來、回好幾次- 詢問該怎麼弄，但每個人答案與建議都不一樣，就這樣一直周旋著，前後總共花了 *兩個月- 的時間，中間也跑來跟我求救。對於溝通成本有感知的人，只要稍加關心，就會發現問題，意會到問題的存在。

這個案例，稍加分析如下：

1. 現象 (Appearance)：看似簡單、單純的問題
2. 症狀 (Symptom)
   1. 跨越五、六個團隊的溝通
   2. 花費兩個月的時間
3. 察覺 (Perception)
   • 溝通成本: 簡單問題 + 很多人 + 很多時間
4. 認知 (Awareness)
   • 組織結構性問題、系統架構問題、服務邊界問題

後來採取行動：

協助釐清系統服務邊界、與技術主管／團隊溝通，讓他們知道各個服務的邊界在哪，未來可以自行處理需求。

這個案例中，很多人一開始只會想要解決方法，技術解、暫解 … 但是沒有了解 問題的全貌，在沒看清楚全貌的狀況，就開始用技術解，之後也沒有持續改善，認知問題的核心點在哪，往往過程中只想要一個解決方案。

下面簡報同樣是 導讀持續交付 2.0 - 談當代軟體交付之虛實融合 分享中提到的，主要是針對工程團隊常遇到的現象：

這個案例，應該相關的技術主管、資深工程師都要主動跳出來：

1. 一起把問題全貌找出來、看清楚
2. 一起感知現象、症狀
3. 一起認知然後定義問題

當大家都可以一起走過這段，接下來的技術解決方案 (Solution)，讓團隊挑戰找出來、實作出來，而管理者要做的是：協助找資源、提供建議、參與討論。

引導認知

在團隊裡，我最常做不是跟同仁講技術上怎麼實踐，反而最常引導的是：

1. 體察現象
2. 認知問題
3. 找到全貌
4. 探索本質

當同仁可以觀察到表象／現象，進而分析出症狀，最後自主性的感知、認知問題，下一步協助 勾勒問題全貌，看到問題本質 … 當成員真的意會到問題本質時，剩下的是技術問題。

底下文章有提到怎樣找到全貌的方法

• 看見怎樣的全貌
• Infra 團隊適合 Scrum？

而技術我平常會給予一些固定的學習方向，透過各種形式，像是讀書會、技術分享、技術演講 … 等場域，培養大家對技術的掌握度與靈敏度，如此搭配的效果，成員就可以獨立提出非常一針見血的解決方案。

認知 (Awareness) 問題，是第一步，認知到問題，就不用見血才開始行動，而是能夠採取防禦性計畫，主動出擊。

學習認知

以前第一次教琴的時候，覺得上課像是一場 Show，覺得要用很帥的方式教。幾次後發現一個殘酷的事實：

只有帥，還是會被卒吃掉，學生還是不會彈，是失敗的教學

後來調整了教學方法：

引導學習者去察覺與體驗音樂性

目的就是讓學習者透過對音樂的體驗與意識，然後更有效地掌握音樂性。過程中設計一些體驗性質的內容，包含如何聽音樂、了解音樂背景、當代背景，讓學習者的耳朵打開，意味到音樂的特性；除了音樂本身之外，演奏技巧也設計了類似於 刻意練習 的方法（後來看到刻意練習這本書，發現我就是在做這件事 XD）。吉他手很重視 手感，專業術語大概就是 dynamic / touching …

但是這樣是有很多前提的，特別是對於初學者而言，至少要度過手痛的過程，耳朵聽到自己彈的音符，學習如何聽音樂等過程，簡言之：

察覺音樂 (Awareness)

這是個漫長的訓練，有人在幾次的練習之後，就會察覺到和弦的 特殊性、特徵性、功能性，甚至是 感覺、畫面、情緒 等抽象層次。也有很多人，會一直停留在瞭解和絃的基本蓋念，或者手指的指法、動作等。這過程，如何學習聆聽是關鍵，如何聽出聲音的情緒是影響學習進度的關鍵。

樂器的學習很吃 刻意練習，創作則吃 深度工作 (像是作曲、編曲) … 察覺到正在學習這件事情是很重要的關鍵，就像有人會問我你聽得出這是啥和弦？我可能說不出絕對音符，但我說得出相對 感覺，情緒層次的，因為有過刻意練習的察覺。

認知什麼是好？

什麼是好軟體？ 這篇文章提到一些關於 好 的想法。好軟體、好音樂、好料理、好小說 … 好 是一種正向的症狀，這種症狀稱為 特徵 (Characteristic)。好 東西有表象、特徵，觀察到這些之後，進而感知、認知。

好需要比較，比較特徵值，需要跟不好的比較。例如好的肉圓是什麼？皮嫩、肉多、醬汁美味，入口即化、加辣 … (我餓了@@)

試著用我提出的四個步驟，重新定義你心裡的 好：

1. 表象 (Appearance)
2. 特徵 (Characteristic)
3. 察覺 (Perception)
4. 認知 (Awareness)

因為好是體驗出來的，這四個步驟就是體驗的具象化，好的體驗，讓你有後續行動、產生欲望、深度了解。

所以再一次問問你自己：

什麼是好的軟體？
什麼是好的服務？
什麼是好的音樂？
什麼是好的工作？
什麼是好的生活？

Q and A

Q: 沒有意識到問題，會怎樣？

1. 因為一開始就沒看到全貌，很容易因此頭痛醫頭、腳痛醫腳，時間久了之後，最後就歪樓、發散、混亂，熵值呈指數上升。
2. 衍伸現象就是溝通成本巨大，一個會議常常出現雞同鴨講現象，同一個名詞，有多種意思，或者同一個東西，有多種名稱。最後會衍伸政治性問題，而且過程中，很多人無法察覺 溝通成本越來越巨大。
3. 更嚴重的現象，就是 導讀持續交付 2.0 - 談當代軟體交付之虛實融合 提到的 組織問題、架構問題、業務問題。
4. 最常見的類似就是 Issue Tracking 系統的導入，只是找工具為了做而做，沒有意識到核心本質：資訊流、KM。

Q: 如何訓練團隊意識到問題？

第一步要觀察事物的表象、症狀，在工作工程中，就要做這樣的練習。類似的做法在：如何有效的回報問題 就是最好的練習。回報問題不僅止於 QA 回報問題，而是整個團隊如何描述一個問題，就是在訓練了。另外就是從生活中去體驗，像是面試我會問：你覺得 什麼是好軟體？ 會去觀察的人，會去深度理解的人，對於好與壞的靈敏度 (Sensitive) 會比一般人高很多。

Q: 朋友 Earou Huang 留言提問：如果高層主管、團隊成員都沒有意識到的問題，或不覺得那是個問題，有沒有可能認知錯誤的是自己本身。如果能認同與識別問題的是少數人，那推動改革會有效益嗎？

好提問，我把問題分成兩個：

1. 有沒有可能是提問者自身認知錯誤？
2. 只有少數人認同、意識到問題，那推動改革會有效益嗎？

提問的人，必須對問題本身有深度思考、深度認知，對問題未來方向、風險，都有想法，甚至具體的作法、實踐，也都有八九成掌握。這個過程，很吃提問人自己的經驗、能力、視野、對於狀況的掌握，透過這些深思，確認這個問題是正確的。

如果這些都具備了，剩下的，就是如何抓到適當的時機，展開說服、驅動認知事件。時機很重要，如果沒有十足的把握，輕易地敲動，很容易有反效果。所以有時候必須眼睜睜的讓事件發生，透過震撼教育的手段，然後切入取得主導權，接下來才是真的開始執行與落地，詳細參閱 有效定義目標與執行、落地。

至於有沒有可能是提問者自身的誤解、或者方向錯誤，當然也是有可能的，最常見的例子，就是盲目導入新技術／微服務架構、一窩蜂導入敏捷開發。所以如同前述，提問者自身的深度思考、考慮完備、執行能力，都是必要的。

第二個問題，只有少數人認同，還有必要推動嗎？我直接想到日劇 王牌大律師 古美門 (如下) 這段令人深刻的辯論，探討的是當民意大於司法的時候，要以民意為主？還是司法為主？還是那句話，有完整且深度的思考，就會有答案。

結論

這篇文章 源自於兩篇在 Facebook 的隨筆：2019/10/23: 學習的感受與意識、2019/11/21: 意識問題，重新整理後，加入了 如何有效的回報問題、看見怎樣的全貌、什麼是好軟體？ 等文章的綜合想法。

網路上有所謂 解決問題的步驟，步驟大概是：

1. 看見問題
2. 了解問題
3. 承認問題
4. 面對問題

其實概念是類似的，而本文用 意識 (Awareness) 表示從外在感官、到內心深處都感覺到問題，最後所產生一連串的動作與行為。

最後，下面這張圖引用自 “跳出思考框架”到底實際上要怎麼做? 怎樣才算是”深度思考”? | 深思快想 | 啾讀。第31集 | 啾啾鞋，談的是深度思考的過程，抽象化思考。整理出了 1) 現實、 2) 結構、 3) 本質、 4) 類比的概念，透過這樣的深度轉化，抽象化思考，可以得到解決方案。本文提到的比較像是現實這段的想法，也就是如何有引導大家進入問題點的入口，有了入口，接下來的深度思考，才有辦法看透問題的本質，找到對的解決方案。

延伸閱讀

站內文章

• 有效定義目標與執行、落地
• Infra 團隊適合 Scrum？
• 看見怎樣的全貌
• 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
• 如何有效的回報問題 (How to Report Problems Effectively)
• Study Notes - CloudWatch
• 什麼是好軟體？
• 系統發生異常時，第一時間如何快速止血？
• Issue Tracking in Redmine、Issue Tracking 在企業裡的價值 - KM

FB Memo

• 2019/10/23: 學習的感受與意識
• 2019/11/21: 意識問題

參考資料：

• “跳出思考框架”到底實際上要怎麼做? 怎樣才算是”深度思考”? | 深思快想 | 啾讀。第31集 | 啾啾鞋
• 悲傷不是盡頭，只要你願意繼續向前走！淺談悲傷五階段