chundev
日期：2026-05-02 對象：PM / 主管 / 想推動團隊文件品質的人 前情提要：用 PRINCE2 PBS 驅動的政府採購案文件自動化方案
把個人手藝（一套 PBS + docx-engine 文件自動化方案）變成組織能力，不能靠「教大家用工具」。實戰上要走「找 1 個盟友 → Co-pilot 共學 → 累積 pattern library → 設品質門檻 → retrospective 改進工具」的 5 階段工作流。三個關鍵設計：教材分眾、從成功案例倒推（不從教理論開始）、Retrospective 必填欄位回灌工具。
你寫好工具、寫好 spec、寫好 share-note，沒有人會自動採用。這是個獨立的工程問題。
實戰上幾種失敗模式：
| 失敗模式 | 結果 |
|---|---|
| 直接寄 share-note 給全公司 | 沒人讀完；極少數讀完的也不會行動 |
| 強推 mandate「以後新案都要用」 | 表面遵守、實際抗拒；產出垃圾 PBS 反而傷工具聲譽 |
| 從教 PRINCE2 / PBS 理論開始 | 同事覺得「又是新方法論要學」；學完忘掉 |
| 找 RD 做技術 evangelism | RD 不是文件主要使用者，價值主張錯位 |
| 一次推給全部 PM | 沒有近距離支援；出錯沒人處理；幾天內被棄用 |
真正可行的做法：把推廣本身當成一個分階段的工程，每階段有明確 entry / exit criteria。
階段 1：Seed（種子期，1-2 週）
└─ 拿成果展示 → 篩選 1 個盟友
✅ 出口：盟友答應跟你跑下個案
階段 2：Co-pilot（共學期，1 個案件）
└─ 你陪盟友跑一次 /pm-init → PBS → 文件包
✅ 出口：盟友親身體驗到省時間 / 避免客訴
階段 3：Pattern Library（標準化期，2-3 案後）
└─ 累積 examples，新案參考最像的改
✅ 出口：第 3 個案不需要你陪、盟友能獨立執行
階段 4：Quality Gate（品質期）
└─ Review checklist 加入硬性檢查、失敗即退回
✅ 出口：盟友連續 3 案通過率 ≥ 95%
階段 5：Retrospective Loop（長期）
└─ 每案結案 retrospective → 改進工具 → 下個案受益
✅ 出口：盟友自發 evangelize 給其他 PM
每階段 entry / exit 很重要。不要跳階段。Seed 沒找到盟友就跳 Co-pilot 會撞牆；Co-pilot 沒成功就推 Pattern Library 會散布有問題的範本。
不要對全部 PM 廣告。找 1 個：
| 篩選條件 | 為什麼 |
|---|---|
| 最近被 RFP 改規格搞死過 | 對工具的「省時間」價值最有感 |
| 對品質有要求 | 願意花時間學新方法 |
| 未來 4 週有可能接新案 | 工具需要實案才能 demo |
| 跟你關係 OK、會給回饋 | retrospective 的數據來源 |
⚠ 反過來，避免：
最大關鍵：用對方真正要做的下個案件。
✅ 對：對方剛收到 RFP / 草案的當天，你提議「我陪你跑一次」
❌ 錯：拿你過去做過的案做演示
差別在「切身利害」。Demo 案沒有風險、沒有截止日、沒有客戶在另一頭，學完就忘。真實案件學完隔天就能直接用。
詳細 session 流程見 Co-Pilot Session 5 步驟與品質檢核表。
Pilot PM 跑完 2-3 案後，你會有：
pbs.yamlcontent/*.ts把這些整理成 examples/ 資料夾，用案件型態分類：
pm-engine/examples/
├── procurement-hardware-renewal/ # 硬體 + 軟體續約混合
├── procurement-pure-software/ # 純軟體採購
├── maintenance/ # 維護案（v2）
└── README.md # 各 example 的特性與選用建議
新案接到後，PM 找最像的 example 改，不從零起。這個動作讓「採用工具」的 friction 降到接近零。
「文件品質不一」是主觀感受。要推廣前先變成可量化的 checklist：
詳細檢核表見 Co-Pilot Session 5 步驟與品質檢核表。
連續 3 案通過率 ≥ 95% → Pilot 結束。
每案結案 review 時填一份固定欄位：
本案踩到哪個 pitfall？ → 該補到 SKILL.md 嗎？
哪個 helper 不夠用？ → 新 helper 草案？
哪個 prompt 問得不精準？ → 改 prompts/init-questions.md 嗎？
PBS 哪一處改了 5 次以上？ → 是否該加新欄位 / 模板？
每月把 retrospective 撈出來開會，挑 top 3 進 sprint 做。這是組織學習被工程化的核心機制。
沒這個閉環，工具會被當成負擔；有這個閉環，工具跟著公司一起長。
不同受眾要看不同的東西：
| 受眾 | 形式 | 重點內容 |
|---|---|---|
| PM / 業務 | 概念篇 share-note（已寫） | 為何用、價值、好處 — 不講技術細節 |
| 管理層 | Case study 一頁紙 | ROI 對比（時間 / 客訴次數 / 邊際成本下降） |
| 新人 onboarding | 30 分鐘教學影片或圖文 | 從「接到新案的第一件事」實作演練 |
| RD 同事 | 工程篇 share-note | Helpers API、pitfall、self-verify SOP |
寫一份打天下會兩邊不討好：技術細節太多 PM 嫌煩、太少 RD 不夠看。
❌ 錯誤順序：教 PRINCE2 → 教 PBS → 教 pm-engine 工具 → 同事自己用 ✅ 正確順序：秀成果（漂亮 docx）→ 同事自己問「為什麼」→ 才講 PBS / PRINCE2
差別在 buy-in 動機。被動聽理論的人，動機是「老闆說要學」；主動問「為什麼」的人，動機是「我想要這個結果」。後者學得深、留得久。
工具不會自己變好。每次同事踩坑、抱怨、要求新功能 — 這些是 free 的 product feedback。
把每案 retrospective 的填寫變成強制流程（不填不能結案），把所有 feedback commit 進 pm-engine 的 issues/ 資料夾。每月開 retro meeting 挑 top 3 做。
執行 6 個月後，工具會比一開始好 3-5 倍 — 而且這個改進反映真實使用場景，不是 RD 自己想像的。
| 訊號 | 含義 | 行動 |
|---|---|---|
Pilot PM 從沒主動跑過 /pm-init |
工具不夠好用 / 對方不對 | 退一步檢討；不要怪她、找下一位 |
| 連續 3 個案通過率 < 80% | 工具或對方有結構性問題 | 暫停推廣；先修工具或換盟友 |
| 對方說「我直接給你 PBS 你幫我跑就好」 | 想當客戶不想當使用者 | 紅燈！這個 PM 不適合當盟友 |
| Retrospective 表填寫率 < 50% | 文化沒建立 | 要主管出來規定填寫，不然回饋斷流 |
| 6 個月後仍只有 1 個 PM 在用 | Evangelization 沒發生 | 該 PM 不適合當「種子」；找另一個型 |
推廣是另一個專案，不是工具的延伸。寫好工具不等於有人用。要把「推廣」當作獨立的多階段工程，每階段有明確 entry / exit。
找對盟友比寫好教材更重要。1 個對的盟友會 evangelize 給 10 個人；錯的盟友會把工具的口碑搞臭。篩選條件嚴格一點。
真實案件 > demo 案。Demo 案沒切身利害，學完就忘。第一次 co-pilot 就用對方下個真案。
教材分眾，不要一份打天下。PM、主管、新人、RD 各看一篇短的，比一篇長的全部 cover 更有效。
Retrospective loop 是長期 leverage。沒這個閉環工具會死；有這個閉環工具跟組織一起長。
不從教理論開始。先秀成果，等對方主動問「為什麼」，才講方法論。被動聽 vs 主動問，學習效果天差地別。
具體的 Co-pilot session 怎麼跑、品質檢核表怎麼設計，看：