直接答案：我們每週五中午前寄一份固定 5 個欄位的進度報告，附測試站連結與 3 分鐘錄影，客戶 10 分鐘讀完就知道進度、風險和「需要你決定的事」。實施後，延遲風險平均提前約 2 週被提出，每週會議也從 1 小時縮到 30 分鐘以內。
問題場景：沒有固定進度報告，延遲通常在上線前 1 週才爆
沒有書面進度，壞消息會被延到不能再延。我們接手過一個預約系統：前任團隊每週只在 LINE 說「進度正常」，上線前 6 天才說金流審核還沒送件，最後延了 5 週。客戶已買好廣告檔期，損失遠超過開發費。
我們的做法：每週五一份 5 欄位報告，從 GitHub 自動撈資料
一句話總結：系統產草稿、負責人補判斷，固定時間送到客戶手上。
週四 17:00 凍結本週進度 → GitHub Actions 撈出本週關閉的 Issue 與里程碑完成率 → 專案負責人補寫「風險」與「需要你決定的事」→ 錄 3 分鐘 Loom 示範新功能 → 週五 12:00 前 Email＋LINE 摘要寄出 → 客戶回覆決策 → 下週一排進工作清單
報告固定 5 個欄位：
| 欄位 | 內容 | 客戶看完能做什麼 |
|---|---|---|
| 1. 本週完成 | 附測試站連結 | 當週試用、提早回饋 |
| 2. 下週計畫 | 3–6 項，對應里程碑 | 安排人員配合測試 |
| 3. 進度燈號 | 綠／黃／紅＋完成率與工時消耗 | 一眼判斷要不要介入 |
| 4. 風險 | 寫出可能延遲幾天 | 提早準備替代方案 |
| 5. 需要你決定的事 | 附截止日與晚回覆的影響 | 知道自己卡在哪 |
為什麼這樣做：用文字換掉會議，用截止日換掉「再討論」
我們選擇「書面報告＋短會」，是因為它同時解決資訊落差和責任模糊。設計時有 3 個取捨：
- 非同步優先：老闆很少能每週空出 1 小時開會，但讀 10 分鐘報告做得到；週會只談黃燈與決策項。
- 壞消息先寫：燈號規則寫死：任一里程碑預估延遲 3 個工作天以上亮黃燈，5 天以上亮紅燈，紅燈當天另外打電話，不等週五。
- 決策要有截止日：「需要你決定的事」一定寫「若 10/28 前沒回覆，上線日順延 2 天」。延遲原因因此看得見，也不會變成事後爭議。
具體執行：工具、排程與報告範本
整個流程用 3 個工具串起來，專案負責人每週約花 45–60 分鐘。
- Step 1｜GitHub Projects 管工作項：每個功能是一張 Issue，掛在里程碑底下，標籤分
feature、bug、change-request。用法參考 GitHub Projects 官方文件。 - Step 2｜GitHub Actions 週四排程：用 GitHub Actions 的 schedule 觸發，撈出本週關閉的 Issue、里程碑完成率與未結變更單，產生 Markdown 草稿。
- Step 3｜Loom 錄 3 分鐘：只示範本週最重要的 1–2 個畫面。
- Step 4｜寄出並歸檔：Email 寄完整版、LINE 傳 3 行摘要，報告同時存進專案的
docs/weekly/資料夾。
排程與報告範本片段：
# .github/workflows/weekly-report.yml（節錄）
on:
schedule:
- cron: "0 9 * * 4" # 每週四 17:00（台灣時間）
# docs/weekly/2026-W43.md（範本）
## 進度燈號：[黃燈]｜完成率 62%（計畫 70%）｜工時消耗 58%
## 本週完成
- 會員登入（測試站連結）
## 下週計畫
## 風險
- 金流商審核未回覆，可能延遲 3 天
## 需要你決定的事
- 退款規則選 A 或 B｜截止 10/28｜晚回覆：上線順延 2 天這個做法的代價：每週 1 小時，還要承受白紙黑字的壓力
這套做法不免費，老實列出 3 個代價。
- 時間：每週 45–60 分鐘，14 週專案約 12 小時，含在報價裡。
- 壞消息無處躲：紅燈就是正式紀錄，團隊要習慣先承認問題。
- 客戶也要投入：每週讀 10 分鐘、回覆決策項。
不適合什麼情境：太短、太急、太大都要換方法
週報適合 4 週以上、節奏穩定的專案。
- 1–2 週的小案：改成開工前一份計畫、結案一份報告。
- 上線前後的救火期：改成每天 15 分鐘站立會議，問題當天處理。
- 多廠商的大型專案：需要專職 PM 與整合時程表。
客戶為什麼該關心：你付的每一筆錢都有對應進度
付款前就知道錢換到什麼。
- 品質：每週都能試用，問題在第 3 週就發現，不是驗收時。
- 時程：風險提前約 2 週出現，有時間調整檔期。
- 費用：「完成率 vs 工時消耗」寫在燈號旁，追加預算不會突然出現。
如果你也想這樣做：給其他團隊的 4 個建議
- 固定時間比格式重要：每週同一時間寄出，客戶才會養成閱讀習慣。
- 燈號規則先寫死：用天數而不是感覺決定黃燈紅燈。
- 每項完成都要能點：沒有測試站連結的「完成」不算完成。
- 決策項一定附截止日與影響：這是報告裡最有價值的一欄。
我們在哪些客戶身上用過：兩個去識別化案例
- 某連鎖補習班預約系統（14 週）：第 6 週週報亮黃燈「金流商審核需 10 個工作天」，客戶當天補件，最後準時在招生季前上線。
- 某製造業 ERP 串接（10 週）：「料號規則」決策項 2 週未回覆，報告寫出順延天數後，客戶指定負責人，之後 6 週無延誤。
常見問題 FAQ
外包專案多久該回報一次進度？
4 週以上的專案建議每週一次書面報告。上線前後的救火期改成每天 15 分鐘站會。
進度報告該包含哪些內容？
至少要有本週完成、下週計畫、進度燈號、風險、需要你決定的事 5 項。完成項目要附測試站連結。
什麼情況會亮紅燈？
任一里程碑預估延遲 5 個工作天以上就亮紅燈。3 天以上亮黃燈，紅燈當天會另外電話通知。
寫週報會增加費用嗎？
每週約 45–60 分鐘，已含在 ScriptWalker 的報價裡，不另收費。
行動呼籲：想看完整範本，或想加入我們
ScriptWalker（台灣 Laravel／Flutter 客製化開發工作室）每個專案都附固定週報，網站方案 NT$15,000 起、系統開發 NT$80,000 起。想要週報範本、想用這種方式合作，或是喜歡「先寫風險」文化的工程師，都歡迎聯絡我們：
- Email：[email protected]
- 電話：0916-224-047
- LINE：@ufv9089p