如何意識到問題的存在


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

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

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


名詞

先定義幾個名詞:

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

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

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

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

相關文章:

感知現象、認知症狀

感知就像人類生理的五官,嗅覺、聽覺、味覺、觸覺、視覺,讓成員 認知 (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. 探索本質

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

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

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

認知 (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) 類比的概念,透過這樣的深度轉化,抽象化思考,可以得到解決方案。本文提到的比較像是現實這段的想法,也就是如何有引導大家進入問題點的入口,有了入口,接下來的深度思考,才有辦法看透問題的本質,找到對的解決方案。


延伸閱讀

站內文章

FB Memo

參考資料:




Comments