繼之前的 MTa Level 1 後 (心得見此)，上周又去上了 MTa Level 2，相較於 Level 1，這一次的活動需要更全面且快速的思考才能夠做的更好。從這次的活動中，我整理出下面幾項收穫來跟大家分享。
良好的表達是成功溝通的基礎
軟體工程師: 「程式A會去 polling，然後透過 IPMI 傳給 BMC」
韌體工程師: 「系統中不同的執行緒同時把訊號丟給 I2C 又沒有 semaphore 機制造成 protocol 錯亂。」
硬體工程師: 「SMBus 跟 PMBus 接在一起，可能會有 multi-host 的問題。」
PM: 「.......，你們可以講人話嗎？」
知識的詛咒（Curse of knowledge），在 Wikipedia上的解釋是：「一種認知偏差，形容專家常以術語交談，但是喪失與非專業人士溝通的能力。」
當我們在一個領域中花了時間許多時間讓自己越來越專業後，很容易就開始把領域內的專業知識當成理所當然，所有人都應該知道，而無法理解為什麼自己講的話別人聽不懂。或是當我們在某個課題中花了許多時間去研究後，就會誤以為某些東西是「基本常識」，在溝通交談時也都以這為前提，想當然爾，這樣下去很可能會讓對方聽的一知半解甚至完全理解錯方向。
因此，為了提升溝通的品質與效率，我們可以先確認對方的認知程度，同時也必須要有一套淺顯易懂的說明方式，去幫助對方正確的理解我們想要傳達的東西。畢竟如果對方不懂，反覆來回確認跟釐清誤解可能會耗費更多的時間。學習如何良好的表達是個重要的課題，如何針對不同的人給予不同方式的講解更是一門需要不斷練習的技術。
盲目的信任是一種天真的樂觀
「我相信你做的到。」
「他一定會答應我們的啦。」
「他說沒問題就不會有問題的。」
在科技業，產品從研發階段到工廠生產前會經過一個「驗證」的關卡，確認產品在各個面向的設計沒有問題，而在工廠生產的最後階段也會經過「品質檢驗」的關卡，確認最終出去的產品是符合品管標準的。這不是因為不信任研發單位或是生產單位，而是每個人都有盲點，為了避免這些盲點我們總是需要讓不同的人透過不同的方式去做驗證。即使是 google 這麼知名的公司，2018年在「發現漏洞」這件事上也額外發放了 340萬美元的獎金。
然而，在組織中已經很習慣這樣做的我們，為什麼還是經常的會犯下這種「天真的樂觀」的錯誤呢？背後的原因可能是「不好意思質疑別人」、「害怕別人覺得我不好相處」、「感覺時間不夠」、「這樣責任就不在我身上」甚至是「覺得麻煩，想偷懶」。但也就是這樣，就會讓最後的結果產生不穩定的狀態，好的結果也可能只是運氣好剛好沒發生問題而已。試想，一個沒有經過驗證跟品管的產品，你會安心讓它被賣到客戶手上嗎？如果答案是否定的，那為什麼在平時的團隊合作上會如此的縱容這件事的發生呢？團隊成員之間彼此的「信任」不應該是「盲目的信任」，而是在我們開口提出一個做法的時候，要「信任」對方知道你是為了團隊好，而不是針對他，反之亦然。這種「全然的信任」，才是真正的信任。
一致的目標有利於團隊的成功
如果團隊中每個人對於目標方向的認知不同，就會如同多頭馬車，消耗掉許多不必要的時間與精力。而換個方向，假設客戶的想法跟表達很抽象，而我們也就基於這個抽象的想法去把東西做出來，這樣可以直接就符合客戶想法的機率有多高？也因此，在工作上我們經常會用不同的方式來縮減這個隔閡，例如在真的設計產品功能之前先給客戶看一個「沒有功能」的網頁(我們稱之為 mockup)，讓雙方可以快速的核對認知是否有偏差。產品本身的外觀設計也會透過設計圖讓客人先確認再去做，否則很容易就會因為彼此的認知不同而浪費了時間也浪費了金錢。
很多時候，我們接到了一個有時間限制的任務，就會想在時間壓力下盡快的動手去開始做，盡快開始做並沒有錯，但如果可以在真的動手之前先快速的凝聚好團隊共識，讓大家對全貌( Whole Picture)有個明確的共識跟認知，是否可以減少未來可能產生的一些風險呢？在任務進行中總是會有很多的意外發生，沒有人敢說一定都可以順風順水的完成任務，但也就是因為這樣，我們更需要在可行的範圍內盡可能的降低風險出現的機率。
沒有完美的個人，但可能有趨近完美的團隊
「這不是我們部門負責的，別找我。」
「那不是我的問題，你去找OOO處理。」
「這是軟體的問題，跟硬體無關。」
貝爾賓將團隊分成了九種角色分別負責不同類型的工作，而一個好團隊除了「組成」上要可以互補外，在「執行」上也要願意互相補位、互相支援、互相提醒。在輪到自己分內工作的時候專注的去完成他，行有餘力的時候幫忙看前看後，而不是互踢皮球自掃門前雪，抱持著反正責任不要在我身上就好這種消極且錯誤的心態。好團隊的成員之間會互相的信任與幫助，大家朝著同一個目標前進，每個一人都擁有獨立作戰的能力，但也同時具備了協同作戰的彈性。
85分與100分的抉擇
多年前，一個早上，會議室中坐滿了高階主管，正聚精會神的聽著一份內部報告，身為業界全球龍頭的巨型企業，在日本的銷售狀況卻年復一年節節敗退，所有人都無法理解到底發生了甚麼事，日本市場很大，但他們的銷售額卻一直無法成長甚至還衰退。經過了多年的分析統計後，內部報告指出了根本原因：「日本分公司希望可以把產品做到盡可能的完美。」
所有人都很驚訝，把產品做好難道錯了嗎？報告中進一步的指出，日本分公司訂的標準是要解決97%的已知問題才能夠出貨，換句話說，扣除一些先天性限制的問題外幾乎要完全解決所有的問題。也因為這樣，他們的產品總是延遲發佈，在客人無法等待的時候就轉到了競爭對手那邊。那難道競爭對手的產品都沒有問題嗎？調查後發現，其實競爭對手的產品問題遠比他們的多，但對客戶來說，要不就是沒有用到沒影響，要不就是基於上市時間考量，為了先搶攻市占率還是先上了再說。要知道，從90分到95分所要花的力氣可是遠比80分到90分要大的多了，也就是將所有的精力都放在「追求完美」而忽略了「客戶的聲音」導致了它們的失敗。
並不是說品質不重要，差勁的品質可能會導致毀滅性的後果，一昧追求速度而不顧慮品質只是讓自己一步步邁向衰敗；但反過來說，只追求品質而絲毫不顧慮市場狀況，也會因為跟不上潮流而被拋下。因此，在時間有限的情況下，我們要盡量追求好的品質，而這個品質，至少要高過「最低可接受標準」(Minimum Quality Standards)，至於這個標準要怎麼訂呢？那就要回頭檢視一開始設定的目的來決定了。
以這次的課程內容來說，有些活動會需要鎖螺絲，在時間有限的情況下，我們可以選擇(1)把螺帽鎖上去不要掉就好，或是(2)把螺帽鎖緊。這時要怎麼選擇呢？這就要看鎖上螺絲的目的來決定了！如果目的是要確保結構穩固，那可能要鎖緊，但如果目的是卡住讓東西不要掉，那或許只要把螺帽轉進去一點不要掉就可以了。一切的決定都源自於最開頭的需求來做選擇。
缺乏監督的領導是不負責任的行為
近幾年非常流行在談主管要「放手」要「授權」，這些事本身並沒有錯，但如果一個主管只懂得一昧的「放手」，卻不知道要怎麼「監督」，那就只是一種不負責任，把問題丟給下屬的做法而已。身為主管，我們不一定要做微管理 (Micromanagement)，但一定要知道怎麼樣幫助團隊往對的方向前進，良好的分配工作並確保有照著計畫進行，有偏離軌道則及時適當的調整，而非只想當個甩手掌櫃，坐在一旁等著領錢而已。
而身為團隊的成員，必須要主動回報進度跟狀況，不是只有在出問題的時候才回報，順利的時候也應該讓主管知道一切順利，如此雙向的溝通確認，才能確保任務進行順利。
最後，關於 MTa Insights 工作坊
跟 MTa Level 1 一樣的地方是這堂課依然在「溝通」及「團隊合作」上有所著墨，在 Level 2 則又加上了一個「領導」的課題。而 MTa 核心的「檢討」則做得更深入，每個活動都從「正」「反」兩面去探討，帶出「關鍵人物」跟「具體實作的方式」，並藉由這些思考去找出可以更加優化績效的地方，也歸納出需要的「態度」跟「技能」。同時更進一步的思考這些活動與我們現實工作上的連結與應用。
這次的課程幾乎每一場活動都讓我更深刻的看到自己不足的地方，回溯之後也發現有很多地方其實應該一開始就可以做的更好，期許自己可以在一次次機會中去落實執行這些學到的東西，來幫助自己跟團隊都更進步。
良好的表達是成功溝通的基礎
軟體工程師: 「程式A會去 polling，然後透過 IPMI 傳給 BMC」
韌體工程師: 「系統中不同的執行緒同時把訊號丟給 I2C 又沒有 semaphore 機制造成 protocol 錯亂。」
硬體工程師: 「SMBus 跟 PMBus 接在一起，可能會有 multi-host 的問題。」
PM: 「.......，你們可以講人話嗎？」
知識的詛咒（Curse of knowledge），在 Wikipedia上的解釋是：「一種認知偏差，形容專家常以術語交談，但是喪失與非專業人士溝通的能力。」
當我們在一個領域中花了時間許多時間讓自己越來越專業後，很容易就開始把領域內的專業知識當成理所當然，所有人都應該知道，而無法理解為什麼自己講的話別人聽不懂。或是當我們在某個課題中花了許多時間去研究後，就會誤以為某些東西是「基本常識」，在溝通交談時也都以這為前提，想當然爾，這樣下去很可能會讓對方聽的一知半解甚至完全理解錯方向。
因此，為了提升溝通的品質與效率，我們可以先確認對方的認知程度，同時也必須要有一套淺顯易懂的說明方式，去幫助對方正確的理解我們想要傳達的東西。畢竟如果對方不懂，反覆來回確認跟釐清誤解可能會耗費更多的時間。學習如何良好的表達是個重要的課題，如何針對不同的人給予不同方式的講解更是一門需要不斷練習的技術。
盲目的信任是一種天真的樂觀
「我相信你做的到。」
「他一定會答應我們的啦。」
「他說沒問題就不會有問題的。」
在科技業，產品從研發階段到工廠生產前會經過一個「驗證」的關卡，確認產品在各個面向的設計沒有問題，而在工廠生產的最後階段也會經過「品質檢驗」的關卡，確認最終出去的產品是符合品管標準的。這不是因為不信任研發單位或是生產單位，而是每個人都有盲點，為了避免這些盲點我們總是需要讓不同的人透過不同的方式去做驗證。即使是 google 這麼知名的公司，2018年在「發現漏洞」這件事上也額外發放了 340萬美元的獎金。
然而，在組織中已經很習慣這樣做的我們，為什麼還是經常的會犯下這種「天真的樂觀」的錯誤呢？背後的原因可能是「不好意思質疑別人」、「害怕別人覺得我不好相處」、「感覺時間不夠」、「這樣責任就不在我身上」甚至是「覺得麻煩，想偷懶」。但也就是這樣，就會讓最後的結果產生不穩定的狀態，好的結果也可能只是運氣好剛好沒發生問題而已。試想，一個沒有經過驗證跟品管的產品，你會安心讓它被賣到客戶手上嗎？如果答案是否定的，那為什麼在平時的團隊合作上會如此的縱容這件事的發生呢？團隊成員之間彼此的「信任」不應該是「盲目的信任」，而是在我們開口提出一個做法的時候，要「信任」對方知道你是為了團隊好，而不是針對他，反之亦然。這種「全然的信任」，才是真正的信任。
一致的目標有利於團隊的成功
如果團隊中每個人對於目標方向的認知不同，就會如同多頭馬車，消耗掉許多不必要的時間與精力。而換個方向，假設客戶的想法跟表達很抽象，而我們也就基於這個抽象的想法去把東西做出來，這樣可以直接就符合客戶想法的機率有多高？也因此，在工作上我們經常會用不同的方式來縮減這個隔閡，例如在真的設計產品功能之前先給客戶看一個「沒有功能」的網頁(我們稱之為 mockup)，讓雙方可以快速的核對認知是否有偏差。產品本身的外觀設計也會透過設計圖讓客人先確認再去做，否則很容易就會因為彼此的認知不同而浪費了時間也浪費了金錢。
很多時候，我們接到了一個有時間限制的任務，就會想在時間壓力下盡快的動手去開始做，盡快開始做並沒有錯，但如果可以在真的動手之前先快速的凝聚好團隊共識，讓大家對全貌( Whole Picture)有個明確的共識跟認知，是否可以減少未來可能產生的一些風險呢？在任務進行中總是會有很多的意外發生，沒有人敢說一定都可以順風順水的完成任務，但也就是因為這樣，我們更需要在可行的範圍內盡可能的降低風險出現的機率。
沒有完美的個人，但可能有趨近完美的團隊
「這不是我們部門負責的，別找我。」
「那不是我的問題，你去找OOO處理。」
「這是軟體的問題，跟硬體無關。」
貝爾賓將團隊分成了九種角色分別負責不同類型的工作，而一個好團隊除了「組成」上要可以互補外，在「執行」上也要願意互相補位、互相支援、互相提醒。在輪到自己分內工作的時候專注的去完成他，行有餘力的時候幫忙看前看後，而不是互踢皮球自掃門前雪，抱持著反正責任不要在我身上就好這種消極且錯誤的心態。好團隊的成員之間會互相的信任與幫助，大家朝著同一個目標前進，每個一人都擁有獨立作戰的能力，但也同時具備了協同作戰的彈性。
85分與100分的抉擇
多年前，一個早上，會議室中坐滿了高階主管，正聚精會神的聽著一份內部報告，身為業界全球龍頭的巨型企業，在日本的銷售狀況卻年復一年節節敗退，所有人都無法理解到底發生了甚麼事，日本市場很大，但他們的銷售額卻一直無法成長甚至還衰退。經過了多年的分析統計後，內部報告指出了根本原因：「日本分公司希望可以把產品做到盡可能的完美。」
所有人都很驚訝，把產品做好難道錯了嗎？報告中進一步的指出，日本分公司訂的標準是要解決97%的已知問題才能夠出貨，換句話說，扣除一些先天性限制的問題外幾乎要完全解決所有的問題。也因為這樣，他們的產品總是延遲發佈，在客人無法等待的時候就轉到了競爭對手那邊。那難道競爭對手的產品都沒有問題嗎？調查後發現，其實競爭對手的產品問題遠比他們的多，但對客戶來說，要不就是沒有用到沒影響，要不就是基於上市時間考量，為了先搶攻市占率還是先上了再說。要知道，從90分到95分所要花的力氣可是遠比80分到90分要大的多了，也就是將所有的精力都放在「追求完美」而忽略了「客戶的聲音」導致了它們的失敗。
並不是說品質不重要，差勁的品質可能會導致毀滅性的後果，一昧追求速度而不顧慮品質只是讓自己一步步邁向衰敗；但反過來說，只追求品質而絲毫不顧慮市場狀況，也會因為跟不上潮流而被拋下。因此，在時間有限的情況下，我們要盡量追求好的品質，而這個品質，至少要高過「最低可接受標準」(Minimum Quality Standards)，至於這個標準要怎麼訂呢？那就要回頭檢視一開始設定的目的來決定了。
以這次的課程內容來說，有些活動會需要鎖螺絲，在時間有限的情況下，我們可以選擇(1)把螺帽鎖上去不要掉就好，或是(2)把螺帽鎖緊。這時要怎麼選擇呢？這就要看鎖上螺絲的目的來決定了！如果目的是要確保結構穩固，那可能要鎖緊，但如果目的是卡住讓東西不要掉，那或許只要把螺帽轉進去一點不要掉就可以了。一切的決定都源自於最開頭的需求來做選擇。
缺乏監督的領導是不負責任的行為
近幾年非常流行在談主管要「放手」要「授權」，這些事本身並沒有錯，但如果一個主管只懂得一昧的「放手」，卻不知道要怎麼「監督」，那就只是一種不負責任，把問題丟給下屬的做法而已。身為主管，我們不一定要做微管理 (Micromanagement)，但一定要知道怎麼樣幫助團隊往對的方向前進，良好的分配工作並確保有照著計畫進行，有偏離軌道則及時適當的調整，而非只想當個甩手掌櫃，坐在一旁等著領錢而已。
而身為團隊的成員，必須要主動回報進度跟狀況，不是只有在出問題的時候才回報，順利的時候也應該讓主管知道一切順利，如此雙向的溝通確認，才能確保任務進行順利。
最後，關於 MTa Insights 工作坊
跟 MTa Level 1 一樣的地方是這堂課依然在「溝通」及「團隊合作」上有所著墨，在 Level 2 則又加上了一個「領導」的課題。而 MTa 核心的「檢討」則做得更深入，每個活動都從「正」「反」兩面去探討，帶出「關鍵人物」跟「具體實作的方式」，並藉由這些思考去找出可以更加優化績效的地方，也歸納出需要的「態度」跟「技能」。同時更進一步的思考這些活動與我們現實工作上的連結與應用。
這次的課程幾乎每一場活動都讓我更深刻的看到自己不足的地方，回溯之後也發現有很多地方其實應該一開始就可以做的更好，期許自己可以在一次次機會中去落實執行這些學到的東西，來幫助自己跟團隊都更進步。
沒有留言:
張貼留言