（改寫自公司內部 memo）

（Target audience: 上過【專案管理第一次就上手】的同仁）

很高興看到二月及四月上過【專案管理第一次就上手】的同仁們，開始在工作上運用課堂所學，尤其是「專案管理問題清單」開始被廣泛運用在大大小小專案的 kick-off meeting 上面，這是非常好的現象。

這份 memo，我針對 kick-off meeting 的定位及前置作業多做一些補充，算是這陣子貼身觀察的小小心得。

2022 年一月起，我開始每個月一次，每次兩小時的【職涯躍升書系導讀會】，讓公司同仁自由報名，希望藉由這種草根性的軟性活動，另闢一條 bottom-up 的改革路徑。畢竟，深遠持久的影響，不能少掉「喚醒基層意識」這環節。

前六個月的選書如下：

月前看到君婷老師提的這則重大發現：「當你沒辦法 convince 對方的時候，那就想辦法 confuse 他。」

對於「塞一大堆無關緊要，但看起來好像很認真整理過的資料」這件事，我是感同身受的——尤其是職場的會議簡報。

職場的會議簡報，下焉者，塞一大堆原始數據；中焉者，把數據整理為樸素的統計圖表；上焉者，會針對圖表的洞見予以錘鍊。¹ 上焉者的境界，可能需要一段時間訓練與即時回饋，恐非短期可奏效；但我發現，只要掌握一個逆向工作法的小訣竅，就能找到改善中焉者表現的線索。

（改寫自公司內部 memo）

Hi all engineers,

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

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

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

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

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

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

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

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

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

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

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

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

這是大哉問。

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