MTa Insights®工作坊
每天，都要比昨天更好一點
來自業務單位的一封信，要求我幫忙設定產品的”Demo Version”(展示版本)。設定完成，對方卻說沒有生效。我問遍各單位，才發現應該設定的是”Demo State”(展示模式)，那是另一個單位負責的領域。
兩個名字很像，設定目的卻不一樣。提需求的人找錯了對象。
像這樣例子在職場上層出不窮。有些誤會澄清後就沒事了，有些卻是做錯了方向，造成資源白白浪費。
如何增進溝通的精確性？更進一步問，如何讓團隊更有效率？
在「MTa Insights®工作坊」當中，我獲得許多關於團隊合作的啟發。就從計畫、溝通、執行、檢討，四個面向來分享心得。
什麼是【MTa Insights®】
MTa Insights®是一套由英國的MTa Learning公司所開發的教具及教學方法，他們的團隊也多次在全球最權威的人才發展協會ATD發表專題講演而深受肯定，Alex老師也對於獲得他們的授權深感榮幸。
這不只是一個教你「團隊很重要」的課程，而是真的能讓你透過分析和檢討，有效提升個人能力，一步一步讓團隊運作得更好的一種訓練。 MTa Insights®不只是一個團隊建立Team building的課程，課程能延伸結合的領域既深且廣，是一堂能夠精確落實團隊合作與領導力訓練的世界級體驗式學習。(取自官網, 2021/1/15)
當天，我們共經歷五個活動。表面上看起來，是大家一起用教具組裝出各種樣品(因此被戲稱為積木課)。實際上，我們要做的是不斷檢討「在剛剛的過程中，怎麼做會更好？」
計畫：確認方案
不管在哪間公司，都常常發生這樣的情況：交辦任務時聽到「想清楚了嗎？」，要求評估時聽到「做了才知道」。
Well…(拭淚)
身為團隊一份子，很少有「我說了算」的情形，計畫有賴專業團隊的評估，這也讓人人都要機會「要求別人先想清楚」，要不就是坐等全體共識或上級指示。
然而，我們不可能得到最完整的資訊才決策，必須用有限的資訊，想透徹執行方式，從best case到worst case — 萬一只做最好的假設，事情往往就不會順利發生 。
同時，要承擔推動任務前進的責任。
問自己三個問題：
- 這個方案的執行面，已經從頭到尾想透徹了嗎？
- 真正投入資源之前，有沒有至少兩個以上的備案？
- 過程中有幾個檢核點，可以判斷下一步行動方向？
溝通：講清楚、聽明白
多少問題來自錯誤表達與誤解，更怕還不自知。任何專案/任務，我們都要在幫助團隊建立一套溝通的依據。用專案管理的名詞，就是設定”Ground Rule”
然而，做到這一步還不夠。實際上會遇到的狀況是：我們不會只跟自己專案成員溝通，我們會需要跟全公司、跨部門團隊溝通。
各單位有自己的規則、專有用詞 ，跨部門溝通的誤會必然會發生。
- 表達的訣竅：動詞、名詞優於形容詞。如果真的非要用形容詞怎麼辦？設定基準：問題發生率「很高」 — 多高？比誰高？測試基準是多少？換算成維修費用是多少？
- 思考一件事：什麼是你熟悉的，什麼是大家都熟悉的？用了別人不懂的比喻只會把事情搞得更糟。
- 不要假設你的聽眾懂 →要假設對方不懂。你天天用的專有用詞，換個單位根本聽不懂。多一次解釋、少一點錯誤。
- 傾聽：不斷確認彼此的認知，用自己的話闡述一遍，哪怕要多花一點時間，為了避免失誤造成的更多資源損失，這都是值得的。
我們要想辦法講別人聽得懂的話，而且這樣還不夠。事實是，要讓對方真的朝我們期望的方向行動 — MTa某個活動中，我曾經想到可能的發展，提醒組員要注意，卻沒有確實要求並確認執行，因此導致最後沒拿到分數。
我有想到，團隊卻沒有因此做的更好，這就是我該負起的責任。
執行 — 摸石頭過河，應變與調整
當天其中一個活動，同樣的任務執行三次，有兩次檢討與修正的機會。
第一次預估必然與實際有落差。然而，想想我們在公司實際遇到的，大家哪次不是希望一次做到位？每一次的調整都是在消耗資源跟大家的士氣。因此，第一步就要盡力想清楚，而不是拿「邊做邊修」當藉口。
如何調整：
- 以執行成果作為基準，讓下次投入的資源更精確。
- 找出關鍵的瓶頸，鬆綁。
Alex老師提到，有時候只要做對關鍵一件事就可以大幅提升整體績效。我想起《目標》一書也不斷強調，找出瓶頸，鬆綁；再找下一個瓶頸，持續。
回想起我在活動中，兩次調整都拉高預估的產量，也有做到。事後組員問我是怎麼敢大幅拉高預估產量。我回答：我認為關鍵瓶頸不在速度，而在糾正錯誤，只要改善良率就可以大幅拉高產出。
但這個說法有點美化過頭了。我當時想得很單純：組員明明就做得夠快，只要下次做對就好；身為落後組，賭一把是值得的。
檢討 — Lesson Learnt
在剛剛的過程中，怎麼做會更好？剛執行完的專案，有什麼經驗值得進化？
任務會有成功，有失敗。對團隊來說，最珍貴的資產，是將經驗轉化為成長的歷練。專案結束後的Lesson Learnt看似不影響產出，卻是團隊成長的關鍵，也是下一次專案更好的要素。
- 分類：技術問題與非技術問題
- 優化：流程解、系統解、不用解
把問題分類之後，再做排序。技術問題與非技術會有不同方向的解決方式。在我的經歷中，非技術問題的因素更加複雜，可能是策略、心態、甚至是單純的「不小心」。
導入流程來防呆會是改善方式。但也有兩個隱憂。其一：流程越多，效率越容易受到影響；其二：再多流程都百密一疏，尤其是人為疏失實難避免。透過系統、科技來輔助，也會有幫助。
也有一些問題，如果判斷是一次性，或影響層面不大。此類問題花過多心思去防呆，反而是浪費資源，降低效率。這之中的拿捏，仍要靠實際的經驗來判定。
常常，我們會遇到一些來自跨部門的問題。
「他們設計沒有考慮到我們，結果是我們suffer」這樣的心酸不只發生一次。然而，我們自己的設計影響到別人的情況，也發生過啊。
有時不免會想，自己不是負責全公司的PM，看不了這麼廣的面向。或是，「應該要有個橫向的角色來串連整間公司吧」。然而，就以「我」自己的角色，也可以做到更多、更好。
在最近一次的專案Lesson Learnt，我提出了幾個需要擴大跨單位評估範圍的案例。我相信，讓團隊成員透過案例，一起察覺到這個動作，可以增加判斷的準確性。用先期少量的資源，減低更多浪費。
最後一個問題：「我」能怎麼做，讓「我們」變得更好？
