chundev
日期：2026-05-02 對象：要帶 1 個 PM 同事跑第一次 PBS 文件自動化方案的人 前情提要：把 PBS 文件方案推廣到團隊：5 階段工作流
帶 1 個 PM 同事跑第一次 PBS 文件方案的具體 playbook：Show → 對齊痛點 → 實作 → Review → 退場5 步驟，每步有對話範本、紅燈訊號、應對常見質疑的話術。退場後用 6 大類品質檢核表（A-F）量化 pilot PM 的成果，連續 3 案通過率 ≥ 95% 即可獨立執行。
| 項目 | 動作 |
|---|---|
| 挑時段 | 對方有 1 小時不被打斷的時段；最好是她剛收到新 RFP / 草案的當天 |
| 挑案件 | ⚠ 對方真正要做的下個案件（不是過去的、不是 demo 的） |
| 資料就位 | RFP / 草案 .docx / .pdf 放進 working/<客>/<案>/ |
| 空間 | 同坐螢幕前；避免你電腦她看不到 |
| 心理準備 | 你是 navigator，不是 driver。讓她講話，你打字 |
最大原則：用對方真正要做的案件。Demo 案沒有切身利害、沒有截止日、沒有客戶在另一頭 — 學完就忘。
不要先講 PRINCE2、不要先講 PBS、不要先講工具是什麼。
直接秀東西：打開過去做過的成果文件包（履約期程規劃書、應交付項目一覽表、完工測試表、驗收報告等）。
對話範本：
「這幾份文件是同一個案件的，你看視覺、術語、表格框線是不是完全一致？」 「不是 PM 自律或 reviewer 把關，是工具自動的。」 「我帶你跑一次，看看你下個案能不能也這樣。」
判斷：
讓她自己講出來為什麼她需要這個。
問題範本（挑 1-2 題就好，不要全問）：
| 問題 | 想引出的痛點 |
|---|---|
| 「最近一次客戶看到你交的文件，最讓你不爽的反應是什麼？」 | 視覺差、被退、被質疑 |
| 「驗收會議上有沒有過『客戶說要 X 文件，但你沒準備』？」 | 應交付項目沒提前對齊 |
| 「上一個案結案後，你花多少時間整理文件包？」 | 結案慢、文件散落 |
| 「每接新案，文件部分你最痛的是哪一塊？」 | 開放性，看她自己講 |
連結到工具：
「對，這個方案主要就是治這個。等下你會看到怎麼治。」
⚠ 不要解釋怎麼治、不要展示原理。直接做。
cd ~/projects/working/<客>/<案>/
# 啟動 Claude Code 跑 /pm-init
規則：
對話範本（當工具問判斷題時，引導她回答）：
| 工具問什麼 | 你怎麼引導她 |
|---|---|
| 客戶要的成功是什麼？（CQE） | 「客戶在驗收日當天會說哪句話算成功？」 |
| 驗收準則 ≥ 3 條？ | 「客戶會看哪幾份文件 + 哪幾項東西？」 |
| 關鍵驗收人？ | 「最終簽收的人是誰？採購會還是承辦科？」 |
| 已知風險？ | 「上次類似案踩到什麼坑？」 |
30 分鐘到 → PBS 出來 → 自動展開文件包。
「OK，我們現在有 PBS 規劃表。要不要看看自動產出的文件？」
打開生成的 docx 給她看，讓她自己評：
| 對比點 | 對話範本 |
|---|---|
| 履約期程規劃書 | 「這份比你過去手寫的整齊嗎？」「Gantt 圖是不是省了你畫圖的時間？」 |
| 應交付項目一覽表 | 「這份拿去給承辦科對齊驗收項目，你會不會比較放心？」 |
| 完工測試表 | 「30 站每站一份這麼多，工具自動出，你還用 copy 改嗎？」 |
| 規格符合履約紀錄表 | 「規格條文是從 PBS 帶的，下次客戶改規格你只改 PBS、文件自動跟著重生。」 |
判斷：
留下三樣東西：
最後一句話：
「不要追求一次到位。先用一個案件試試，覺得卡再找我。」
判斷：
| 對方說 | 你怎麼回 |
|---|---|
| 「我已經有自己的 Word 模板了」 | 「你的模板維護成本誰扛？換一個專案類型還能用嗎？」 |
| 「這套要學新東西、好麻煩」 | 「你只要會用 Word 開檔填內容。其他工具自動。」 |
| 「不同案件結構差很多，這套會 cover 不了」 | 「對，所以我們累積 examples，下個案參考最像的改。」 |
| 「萬一工具壞了怎麼辦？」 | 「PBS 是純文字，工具壞了你還是有結構化的案件規劃。」 |
| 「PRINCE2 好像很大套要學？」 | 「不用學整套。你只要會填 PBS（拆案件成產品），其他工具吃下去。」 |
| 🔴「我直接給你 PBS 你幫我跑就好」 | 紅燈！ 她想當客戶不想當使用者。委婉拒絕，找下個 PM |
✅ 她說了這些話的其中之一：
❌ 她從沒主動跑過工具：
Pilot PM 跑出文件包後，你 review 用。每份 docx 約 5 分鐘，整套案件約 30-45 分鐘。
原則：每項打勾或勾「XX 提供透明」（給對方看哪裡可以再調整）。把「文件品質不一」這個主觀痛點變成 measurable。
acceptance.criteria ≥ 3 條，且具體可驗證（不是「品質好」這種抽象詞）depends_on 邏輯通（NAS 安裝服務 depends on NAS 硬體 + 零信任授權）composition 有實際內容（不是空陣列）對每份對外文件跑：
soffice --headless --convert-to pdf --outdir /tmp <docx>
pdftotext -layout /tmp/<file>.pdf - | \
grep -nE "P-[A-Z]|M-[A-Z]|/pm-|PBS|Specialist|quality_|fallback"
~ → ～、: → ：、( → （）對完工測試表、安裝紀錄表、勘查報告等：
對報價人天估算書、決策紀錄、風險登錄冊等：
對所有 docx：
最後一道，讀過去看順不順：
| 通過率 | 等級 | 行動 |
|---|---|---|
| ≥ 95% | 🟢 該 PM 可獨立執行 | Pilot 結束，可推薦其他 PM 找她學 |
| 80-94% | 🟡 還在學習中 | 把不通過的項目寫成「下次重點」 |
| < 80% | 🔴 工具或對方有問題 | 退一步檢討：是工具不夠好？還是對方不適合？ |
| 案件 | 通過率 | 備註 |
|---|---|---|
| 第 1 案（pilot） | __% | |
| 第 2 案 | __% | |
| 第 3 案 | __% |
連續 3 案 ≥ 95% → 該 PM 可以帶下一位新 PM 跑 co-pilot session。
| 不通過項 | 警示 |
|---|---|
| B1（內部術語殘留）反覆出現 | helpers 不夠擋；要去工具加自動脫除邏輯 |
| B2（半形符號）反覆出現 | 對方手寫內容沒檢查；加 sed 自動替換到 build 腳本 |
| C1（相片區缺） | helper 沒被 import；檢查 case project 的 content |
| D1（內部標註缺） | 對方分不清文件屬性；加強 onboarding 教育 |
| E1（跨頁重複） | rowSpan 又被誤用；直接 ping 工具維護者修 helper |
每案 review 完，把不通過項目記到工具 repo 的 issues 資料夾：
~/projects/<tool>/issues/2026-05-XX_pilot-feedback-<案>.md
* 不通過項：B2 反覆出現
* 根因：對方手動加註解時打半形 ~
* 改進：建議把 sed 替換加進 generate.ts 後處理
* 優先級：中（不阻擋 ship，但累積成 backlog）
每月把 issues/ 撈出來開 retrospective meeting，挑 top 3 進 sprint 做。
真實案件大於 demo 案。Pilot session 一定要用對方下個真案，不要拿自己過去做過的展示。
她講話、你打字。Co-pilot session 你是 navigator 不是 driver。對方有 ownership 才會自己採用。
退場時別追求完美。「先用一個案件試試，覺得卡再找我」比「我教你所有細節」更有效。
品質檢核表把主觀變客觀。「文件品質不一」是感覺；6 大類 30+ 條 checklist 是事實。Pilot PM 自己看到通過率變化，比你說「你做得不錯」更有力。
失敗模式要分類解讀。某項反覆不通過 = 工具不夠好；某項偶發不通過 = 教育不夠。修對地方。
紅燈訊號要嚴格。「我直接給你 PBS 你幫我跑就好」這種要當下中止 pilot — 她不是要學工具，她是要外包。