🎯 什麼情境該想到我

分工:即用版(原書九條中的第 8、9 條在此合併為一步)。九條原則的原書案例、每一條在 code review 中的用法,以及書中「真誠」與「給好名聲」之間的張力 → 不引起反感地改變他人的九種方法。

當你「身為主管要糾正下屬、身為家長要指正孩子、或要退回一份不合格的稿子」的時候。

⚙️ 怎麼用(步驟 / 公式)

  1. 先真誠讚美,再點出問題。
  2. 間接指出對方的過錯,不正面攻擊他的自尊。
  3. 先承認自己的錯,再指出對方的錯。
  4. 用提問代替命令:「你覺得這樣是不是會更好?」
  5. 顧全對方的面子。
  6. 稱讚每一個微小的進步。
  7. 給他一個美名去保全(讓他為了維持這個名聲而努力)。
  8. 讓改正這件事看起來很容易做到,並讓他樂意去做。

★ 在工作中的樣子:一則 code review 意見

  • ✗ 「這裡有 race condition,改掉。」
  • ✓ 「錯誤處理寫得很完整(真誠讚美)。我之前也在類似的地方踩過坑(先說自己的錯)——如果兩個請求同時更新同一筆訂單,這裡會發生什麼?(用提問代替命令)用 SELECT ... FOR UPDATE 或條件更新應該幾行就能解決(讓錯誤看似容易改)。」

注意:這不是每次都要套滿四步的公式。嚴重的問題(安全漏洞、會造成事故的 bug)要直接、清楚地說,暗示太隱晦,對方可能根本沒聽懂。

🧪 我實際套用的紀錄

  • 佐證:司華伯看到工人在禁菸區抽菸,不加斥責,反而遞上雪茄說「你們到外面去抽,我會更高興」。

⚠️ 注意 / 什麼時候不適用

  • 讚美要真;緊接著一句「但是」會讓它變成明顯的套路。
  • 核心是真心想幫對方變好,而不是包裝過的控制。

🔗 相關工具