這段 筆記 是 2020 年聽 podcast 寫下的心得筆記、跟朋友討論的東西。這整個過程，也是我過去 凝聚團隊共識、人才養成 的實踐方法。

階段

這是我在團隊裡用了一段時間、找共識的方法

• 第一階段是 暢所欲言，誰有什麼想法都提出來寫下來；
• 第二階段是 評估想法，發現不同想法之間的聯繫，把他們用線連接起來；
• 第三階段是 形成決議：把討論中淘汰掉的想法都劃掉，剩下的分出 主、次 和 執行順序，然後整理一下就可以照著做了。

這三個階段，其實就是從 發散思維，到最後 集體的集中思維 的過程。先發揚民主，最後形成集中的共識。

起頭：萬事起頭難，暢所欲言

通常要有人起頭，做個雛形或者樣子，然後要讓大家暢所欲言的討論，把想法丟出來，這段過程很重要。

我常會是把想法丟出來的人，但是跟大家發想的過程，要準備被大家圍毆，或者被整個推翻的心理準備。這個過程要放下身份、身段，讓大家可以 暢所欲言，然後透過這樣的激盪，把想法都放在白板上，過程用顏色區分問題、方向、現況 … 等。

而在討論過程，主軸很容易因為大家的背景、角色、經驗不一樣，主軸一直 飄、亂、散 是正常的，所以一開始發起的人就是要負責讓會議進行有主軸。

這個過程，雖然是我先發起，但過程中也可以探索出下一個可以接棒自己的人才，越有想法的人，就讓他嘗試起頭。
相關文章：問題的難與雜

探索潛力人才

下一步就是要指派一個負責人，開始整理白板討論的內容，通常他也是接下來整個任務的執行者。

這段非常非常重要，因為 整理 就是把想法具象化的過程，沒有這段整理的過程，討論過程激盪的想法與內容等於就浪費了。

接手的人要負責整理這些討論的內容，把發散的資訊，眾人的想法，收斂成一份大家的初版共識。

整理的過程，負責人必須重新深度思考這些討論，重新思考其中的 邏輯結構、先後關係、必要與次要，經過這段重新思考，這個人會變成對整件有最深刻的了解。

可執行的規格與計畫

下一步就是整理成有意義的文件，這份文件會是一份 Guideline、Spec 的草稿版了。這份文件也會是未來執行的起始點，文件內容包含：

1. 問題的描述
2. 目標，得到的好處
3. 解決方案有哪些？他們個別考慮是什麼？適合怎樣的場景？優缺點
4. 具體 PoC 的範圍
5. 常見的問題

有了規格的具象化，下一步才是技術的實驗，也就是 PoC。依據目標與方向的 PoC 才有意義。否則很容易變成無上限的發散。

這個過程有點類似：Working Backwards 的想法

透過技術評估，培養技術專家

紙上得來終覺淺，絕知此事要躬行。再多的討論與想法，沒有人動手去做，終究空談，特別是在技術圈。

所以前面提到的負責人，通常會是實際執行的人，他也會是未來對這個新任務、新技術最熟的人，這是培養技術專家的機會與跳板。

PoC 技術是要解決現場問題。所以根據規格的內容，開始評估需要的技術與 PoC，他要走過所有技術的實踐與考慮，過程就是對於新技術有駕馭能力，獨立研究新技術的方向、如何評估可行性。

現場問題往往比 PoC 的更複雜十倍。但是 PoC 是要了解是否都滿足現場的考量，我常會說：問題的 Consideration (考慮) 是什麼？這些考慮都是必要的？優先續是什麼？

評估過程，不管結果怎樣，只要確實執行，對於技術會有基礎掌握。掌握技術的目的是為了能夠解決關鍵問題，帶來效益。不管評估結果是否適合，都是毀很有收穫的。

2018 年 K8s 剛開始流行的時候，因為團隊需求，期望 K8s 上跑 Windows Container，但我們都知道，這是不切實際的。但我們還是很認真的評估，花了兩個多月，找了 AWS EKS (那時候 EKS 還在 Beta) 一起評估，搞了很久，但有了實際的報告與預期結果。最後結果不難猜想，是不適合的 (不是不行)，但是大家都因為這個評估過程，很有收穫。

除了技術評估，過程我也會訓練同仁 表達 能力，也就是 把複雜的技術概念，變成普羅大眾能聽懂的人話，就像是科普一樣。背後目的就是讓他試著把技術講易懂，怎樣找到適當的比喻，怎樣讓另一個人也懂的怎麼做？怎麼用？怎麼講？表達 技巧也是訓練的關鍵之一。懂技術，會用技術，但是無法讓別人知道，等於不懂。

沒有時間學習技術的管理者，也可以在這個過程，間接學到這些新技術，至少不會完全跟不上，相關參閱 管理者如何持續學習技術？, 人才發展策略地圖 (draft)

下一步：執行與落地

透過評估，滿足了所有情境，下一步才是導入。導入就是真的拿去用，解決問題，產生價值。

用之前，我通常會希望有規則，也就是 使用前請閱讀公開說明書的概念。

能 是一件事，用 另一件事。評估與 PoC 確定的是 能 的問題，用 是要用 制度、規範 解決。

制度規範就是規矩，沒有規矩，怎麼能方圓？系統要長大，線性增加，靠的是規矩、制度、章法。

更多參閱： 有效定義目標與執行、落地

Q: 怎麼讓來開會的人有暢所欲言？

我也不是很清楚算不算做到，但心裡有一些平常在做的，幾點我的套路：

1. 以身作則：我常說會議要準時，不要遲到，如果大家發現 Rick 無故遲到，請不用客氣ㄉㄧㄤ下去。
   • 除了會議，其他也是。看起來沒啥關係，只是想表達紀律，原則。
2. 承認自己能力有限：讓大家知道，我們是一個 Team ，各有各的專長，遇到問題是可以一起分擔的。一個人能力很有限，但一個團隊可以很強大。
3. 前中後的節奏：
   • 討論前，主動丟出想法
   • 討論中，一切都從白板開始，一開始就具象表達。
   • 表達的時候，盡量用生活化的例子，或者用自己當例子，或者用現場的人當作故事角色，把大家串再一起。
   • 用自己當例子是暴露自己的弱點，好惡，讓大家帶著輕鬆進入主題。
4. 平常營造討論的風氣，訓練大家表達的方法（我很強調這點）。
   • 討論的結果要可以具象化 (文件)、結構化 (還是文件)、之後可以依循 (又是文件)。
5. 大家對於討論有具體的內容，有一致的表達方法，下一個 run 就會有更具體的討論，加上前面 3) 建立的連線，4) 的具體內容 2) 弱化權力角色，1) 有紀律的團隊 … 也更容易暢所欲言… ?

更多參閱： 表達與溝通的差異、再談『為什麼寫文件？』

延伸閱讀

• 一個人的 Working Backwards
• 管理者如何持續學習技術？
• 團隊溝通的通訊協議
• 有效定義目標與執行、落地
• 表達與溝通的差異
• 再談『為什麼寫文件？』
• 問題的難與雜
• 人才發展策略地圖 (draft)