最近又重新發現新的問題
就是自己的腦部同時進行訊息輸出跟彙整的過程中，會有闡述完概念，忘記目的的問題。
原因一方面是腦部運轉速度變慢了，另一方面也是其他感官單位時間內能獲取的資訊量比以往更多所致。但不知道哪個變因的影響比較大。
背景：溝通工具與訊息傳遞效率的關係
如果把人腦想像成一個獨立運作的系統，感官是我們的輸入設備，語言、肢體、表情是我們的輸出設備。當我們想要把一個完整的概念，從自己的腦中，傳輸到另一個人腦中的時候，首先要面臨的問題是，透過口述，只有一分鐘 160 個字左右，而在我們說話的過程中，我們必須把腦中的概念壓縮編譯，讓對方解壓縮解譯，由於編譯跟解譯的規則，受到各自具備的知識、關注的重點及接收當下的情緒等變因影響，所以單位時間內可傳遞的概念，並不是可靠的 160/分鐘，甚至是更少。
口述的另一個問題，就是接收端的快取記憶體，由於腦部處理訊息可能需要反覆驗證，但是如果對方接收資訊後，不是把所有字元完整記憶，那麼事後解譯的正確性就會隨時間遞減。因此，當利用語言傳遞資訊時，接收端通常不是記住內容，而是快速轉譯成自己理解的版本來幫助記憶，因此很多時候，發出訊息跟接收不只可能有誤差，甚至可能概念完全相反。
除了口述之外，我們還能透過文字、圖像等方式來傳遞概念，而文字跟圖片可以是在通訊軟體內片段的對話，也可以是一篇文章，或是一份報告，這些傳遞媒介也分別有不同的效益跟問題。
有關溝通工具跟適合用途，底下做個整理：
- 對話式口述
- 優點：低門檻，易於輸出情感、抽象概念。
- 缺點：易失真，效率低落，在保証接收端正確解讀這方面，超級不可靠。
- 適用：短週期訊息傳遞、任務微調、快速確認。
- 對話式圖文訊息
- 優點：低門檻，中等程度輸出情感訊息，可紀錄後查。
- 缺點：易失真，效率低落。
- 適用：任務微調。
- 演講式口述
- 優點：相對完整概念輸出，若輸出端表達能力良好，核心概念較能被正確擷取。
- 缺點：訊息量過大，接收端易疲勞，接收端只能獲取 10% ~ 20% 核心訊息。
- 適用：策略、核心價值、組織目標及大方向說明。
- 段落式文字敘述
- 優點：完整闡述概念，並有實體紀錄可反覆檢視。
- 缺點：產出跟接收效率中等，越抽象的情感或概念越難以表述。
- 適用：工作、任務簡述，快速協助新參與者進入狀況。
- 表列式文字敘述
- 優點：多角度描述，可交叉闡釋概念
- 缺點：容易閱讀疲勞
- 適用：定義規格、檢查表、SOP
- 投影片圖文簡報搭配口述
- 優點：組合多項溝通工具，聚焦核心概念，短時間內有效溝通概念。
- 缺點：不適合闡述細節，口述部份事後無法保存，但往往是訊息的核心。
- 適用：協作前期的概念、需求說明，或輔助議題討論
- 章節式圖文著作（含企劃）
- 優點：完整闡述概念，可事後檢視、驗證
- 缺點：產出速度慢，資訊量過大，接受端不易一次完整吸收
- 適用：大型多目標團隊，或時間跨度大的協作項目等，成員預期會產生異動的情況。
基於不同的可用時間跟目標成果，最好的方式就是盡可能複合式地運用各種工具來優化溝通效率。
問題：訊息擷取能力上升、彙整能力下降
隨著經驗、年齡的成長，觀察力、分析問題的能力，以及支持這些能力所需的記憶、經驗、知識都有所增加，也就是說，做同樣的事情，腦中有了更多的資源可以參考。但並不是每個觀察到的訊息，或每個腦中記得的經驗，都有助於眼前的溝通，以至於想到跟表達出來的過程中，需要一點時間處理。而資料量越大，處理時間越長，甚至有可能出現來不及處理完，直接輸出，然後再輸出的當下，又接著反饋回腦中，接著處理，變成一種邊講話邊思考的循環。
在溝通的時候，邊講邊思考是很危險的，因為這過程很可能自己提出相互矛盾的概念，但接收端不一定能區別，畢竟對對方而言，他正在試著了解你正闡述的「一種概念」，因此通常不會預期這個「概念」其實仍在對話的過程中做調整。
單向的概念傳遞尚且如此，到多人 Brainstorming 的情況，因為具體的概念都還在形塑中，每個人拼揍的全貌也多半有所不同，因此很容易發生，大家討論的共識跟方向是接近的，但一些執行細節卻有認知上的差異。
心得：終究是人的問題
過去我曾經試圖鍛鍊，不管接收端能力、知識水平如何，或者有沒有做紀錄的習慣，透過我單方面的演繹跟努力，去確保訊息傳遞的品質有個大致的基礎。
這個做法當精神飽滿，對事情有熱情的時候，自然產出就會有一定的水準，一開始我會利用簡報來描述專案的目標、限制，以及當中較複雜的問題預期的解決方向，另外也會搭配表格及專案管理工具，列出需求、功能、待確認項目及初步的工作分配、時程安排等。而當需求明確時，再投入開發前也會完成初步的資料規劃、API定義及介面 Wireframe 的製作。
不過，即使規劃涵蓋的範圍很廣，隨著細節越來越明朗，自然會出現許多一開始無法描述清楚的細部規格，需要定義跟釐清。而一但投入開發，我自然也沒有心力去把每個細節都用同樣的方式明確定義，很多時候是在日常的討論回答問題，臨時做決策。
而往往就是這類決策，會引導團隊走向難以預期的結果，比如花一個月深入探討、研究跟開發一個實際上不需要的功能。
這點讓我相當苦惱，畢竟時間是寶貴的資源，浪費一個月不只是燒掉一個月的人事成本，更是產品完成的時程受到一個月的衝擊，進入市場的時間點晚一個月，競爭力晚一個月，這般的影響。
當我進一步檢討為什麼發生這個狀況，得到的答案往往是「我說的」
原來是我要求他們去做一個我不會贊同的規格，而且規格內的細節顯然不合乎使用者的期待。那揪竟這決策怎麼形成的呢？
一開始我歸咎自己的初老現象，畢竟年紀大了，記憶力不如以往，不過我從高中記憶力就不好，從來就不是一目十行，過目不忘的人，因此我在做決定的時候，習慣會根據一套基本原則：
1. 首先不能違反公司的商業利益
2. 次之不能影響用戶的權益
3. 直接面對最難的問題才是最省工的做法
4. 在上述前提之下盡量讓架構簡單，藉此減少維運成本
5. 盡量採用貼近直覺的設計
通常這些原則不會隨時間變化，因此只要決策明顯違背上述原則，我多半可以判斷不是我做出的決定。
經歷了好幾個團隊，跟不同的人合作過，慢慢發現即使投入大量時間規劃、溝通，但認知失協情況仍舊會發生的原因，除了作出決策的這方要盡量確保資訊的完整性以外，還有很重要的是，接收端是否有關注資訊的正確性，跟檢驗資訊的能力，也是一大關鍵。
每當發生這類問題的時候，最常見的原因當然就是我做決策的當下，沒有把規格寫下來，如果我把規則寫下來，那麼原則就是由我保護，大家解讀規格能衍生的誤差就有限，同時如果他們做錯，只要核對我定義的規格文件，就一拍兩瞪眼，沒得含扣。
但探究更核心的問題，則是這些決策原則並沒有被正確傳遞出去，因為一但團隊成員都知道這些原則，自然在接收到違背原則的訊息時，會感到違和，從而有機會在第一時間確認並釐清。
而另一個問題是，團隊成員可能感到違和，但卻礙於內部溝通障礙，而不願意主動提出問題，進而讓問題發展到不可收拾，直到決策者發現。
原則的正確傳遞，本來就不容易，但更讓人痛心的是後者，即使再怎麼強調 Speak Freely，且從來沒有人因為提出問題被懲罰，但總是有人會怯於去面對衝突，勇敢提出問題。
最終，我們能做的，就是讓無法理解、認同原則的人離開，讓更多敢提出問題，不怕碰撞的人加入，把團隊的風氣跟文化，調整到正確的方向。而這一切要達成，只有一個辦法：
一套「持續汰換的人才招募機制」
團隊中不需要表面聽話但害怕檢討的人，
需要敢於提出意見且接受指教的人
留言列表
