（改寫自公司內部 memo）

（Target audience: 有「專案管理」職責的人）

Hi all,

隨著愈來愈多人開始運用專案管理課堂上學到的技術來工作，帶來更高的透明度，更成熟的專業度，欣慰之餘，我也針對其中一件事「透明度」提出一點小提醒。

理想情況下，組織應該要追求專案的透明度——除非有特殊理由。

（改寫自公司內部 memo）

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

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

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

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

前六個月的選書如下：

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

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

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

（改寫自公司內部 memo）

Hi all engineers,

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

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

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

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