（改寫自公司內部 memo）

Hi all engineers,

上完一整天單元測試課程之後，有同事問我：「有沒有標準來決定要不要寫單元測試？」

剛讀完劉潤《底層邏輯》的我，對於這類疑似「注射器」的問句格外敏感。雖然我可以瀟灑引述 Working Effectively with Legacy Code 的說法「我毫無疑問地將『遺留程式碼』定義為『沒有編寫測試的程式碼』」：

沒有編寫測試的程式碼是糟糕的程式碼——不管我們多麼細心地編寫它們，不管它們有多漂亮、物件導向或封裝良好。有了測試，我們就能夠迅速、可驗證地修改程式碼的行為。沒有測試，我們就不知道修改後的程式碼，實際上是變得更好還是更糟。

但當下我還是決定先展開一場對話。

在發出內部 memo 〈請珍惜你們學到的通關密語〉之後，收到這樣的來信：

上周假日也花了點時間，將您從去年 11 月起寫給大家的每一封信都讀了一遍，雖然還不是全部內容都完全吸收和理解，但仍然覺得受益匪淺，真的非常感謝您願意無私的分享您過去許多很棒的經驗和想法。

我很喜歡您用「通關密語」來形容這些語彙，突然覺得他們不再是死板板的方法論，而像是賦予了它們魔力，雖然不至於天真到認為知道這些詞彙和正確的應用，就能馬上變成具有超能力的 superman，但至少能讓我在規劃專案時更自信和從容。

溢美之詞就摘錄到此。以下是正題：

同時，我雖然也很認同這些詞彙確實是「通關密語」，畢竟清楚和正確的定義可以有效減少許多溝通時的落差和模糊地帶，更快的凝聚共識，但前提是和具有同為專業的人溝通，我想這也是您迫切希望大家能盡快建立起這些基本常識的原因吧~

但經驗豐富如您，一定也有許多，甚至是多數時候，都是在和沒有這些基本常識的人溝通吧！過去我就有許多這樣的經驗，不管面對公司主管或是面對客戶時，要求我產出一個四不像等情況。

通常這種時候我的作法會是，不再堅持使用這些專業詞彙，而是解釋我產出的每個圖表的目的、用途和邏輯，但不幸的是還是有很多時候是無法被理解的，通常結局就是我需要照著對方的邏輯和方法，做出一個我自己無法認同的東西，但因為這才是利害關係人們可以接受的作法，所以為了可以溝通和讓專案順利進行，我還是會做。

所以很想問問 William 您是否有類似的經驗呢？那您是怎麼面對和解決的呢?

這是大哉問。

大體上，我會根據幾個角度迅速評估一下這整件事。

好友進了台灣前百大公司，最近有感而發：

請問與麥肯錫有關的書籍，你會推薦哪些？

在這間公司辛苦摸索幾個月，我才意識到，大家在使用的術語都來自麥肯錫。譬如：MECE、Story Line、論述 (Issue)⋯⋯等等。

突然被洽詢這問題，其實有點心虛，畢竟我沒待過麥肯錫這類頂尖的管理顧問公司，不太有資格回答。不過，既然自己去年曾經系統閱讀過相關書籍（見〈2021 個人回顧〉一文），半年以來也一直運用書本裡的方法來推動改革，對於這些方法算是小有心得，因此，野人獻曝一下也無妨。

（改寫自公司內部 memo）

Dear all 夥伴，

過去三個月，我根據自己的職場經驗，以及我對大家的專業要求，安排許多課程及講座。從一系列 1:1 訪談中得知，不只是主管們動了起來，連小夥伴也開始試著實踐。我很欣慰。

譬如說，送你們這群中階主管及資深工作者去接受專案管理培訓之後，我終於可以在大大小小會議上公然用專案管理語彙進行詢問與討論了，不必拐彎抹角替這些對我來說已經是「系統一」的管理切入點逐一解釋或比喻。

The bar has been raised，這才像專業場域。

[課程推薦文] 高效產出：突破資源限制的敏捷管理術

在商業世界，「敏捷」又變成流行語了。許多人風聞敏捷兩大流派 Scrum 及 Kanban 勾勒出來的美麗新世界，聽起來也頭頭是道，便以為敏捷轉型是輕而易舉、隨插即用、立竿見影的事。

不過，真實世界不必然會像宣傳的那麼單純。等到真正開始嘗試時，遇到已知或未知的障礙，才開始懷疑人生，心生退轉。「敏捷轉型」這條路，怎麼走起來並沒有那麼敏捷呀？

其實，「敏捷」這道處方未必有錯，錯的可能是病患未先接受過合適的衛教。