前言

本篇內容可以說是排班工具在訪談系列的最後一篇，我會進行最後的 PRD 檢查並修改，與 ChatGPT 的討論過程會分享在內文，接下來就請大家看下去～

內文

完成訪談後，我做了簡單的整理，同時也與 ChatGPT 簡單討論一下 PRD 的完整性

我想請你與我一起完善 PRD，PRD會提供給 cursor 製作出工具 以下是PRD內容，若有資訊不夠完善處，請告訴我

我針對他提問的內容補齊以下資訊，為什麼我選擇這些問題給予解答呢？這邊分享我使用 ChatGPT 提問的一些習慣：

1. 考慮到 ChatGPT 習慣順著我的話回覆，因此在講求得到「正確回覆」的提問，我會加上「若資訊不夠完善，請告訴我」，如此一來我就能得到他認為資訊有所遺漏之處
2. 排班工具是一套滿講求規則的工具，因此有些在需要完善良好的 PRD，身為一般人的我是很可能會遺漏一些重要的線索。在得到 ChatGPT 的建議後，我閱覽過也發覺確實是重要且關鍵的資訊需要補足
3. 不能完全依賴 ChatGPT，有時候他提到的回覆是不見得要照單全收，例如他會考量到完整性，而提供了像是：納入夜間上班、未成年工讀等相關條件的討論，但由於我期望先取得最小可行性成果（MVP），因此經考量後，我會暫時將較不需要在第一階段討論的內容先擺一邊，等下一階段再討論。

兩段班時間與休息規則（每段起迄 & 標準休息）。沒有強制兩段班，但有用餐高峰期(稱餐期) 10-14點和18-22點，標準休息為2小時，但如果當天因客人太多，會視情況減少休息時間，多餘的工時視為加班

連續上班上限與日/週工時上下限（正職/PT 分別）。正職每日上班無上限，工時超過8小時即視為加班；PT則是8小時，每天不得超過10小時 -崗位清單與班段最低人數（例如：早班收銀≥1、外場≥2…）。崗位基本上一人負責

打卡系統匯入規格（API？CSV 欄位？檔名規則？編碼？）。暫不討論，先以csv規格

紙本班表範例檔（現行 Excel/紙本樣式，供版型對版）。

是否納入夜間/加班/未成年工讀等法律限制於首版（或先排除）。先排除不討論

最後得到以下完整的 PRD

排班工具 PRD（v1.3）

1. 簡介與目標
   1. 現況痛點：Excel/紙本/LINE 分散；審核常卡在外場主管；最終還要重複 Key in 打卡系統。
   2. 產品目標
   3. 一處完成蒐集→編排→審核→發布→匯出。
   4. 自動輸出紙本版型，逐步取代 Excel。
   5. 內建工時/假別/崗位檢核與防呆。
   6. 提供審核逾時自動通過（向上管理）。
2. 使用者需求整理
   1. 期望：一鍵輸出制式班表、審核逾時自動前進、自動檢核（連班、工時、崗位）。
   2. 範圍（首版）：單一店鋪外場。
   3. 排班規則（商業邏輯）
   4. 以餐期為核心：10:00–14:00、18:00–22:00。不強制兩段班。
   5. 標準休息：每日 120 分。如因客流減少休息 → 差額計入加班。
   6. 正職：每日工時 > 8h 視為加班（允許）；連續上班上限 5 天（>5 阻擋）。
   7. PT：目標 8h／日；上限 10h／日（>10 阻擋）。
   8. 隔日最短休息間隔：無限制（不檢核）。
   9. 崗位：原則「一人負責一個崗位」。每餐期每崗位至少 1 人（可調）。
   10. 法律延伸（夜間/未成年/加班細則）：首版排除。
   11. 審核 SLA（Service Level Agreement）
   12. 外場主管：24h；區經理：24h。
   13. 逾時動作：自動核可並通知下一關與排班負責人。
3. 角色與權限
   1. 負責人（Editor）／外場主管（Approver1）／區經理（Approver2）／同仁（Viewer：看個人班表）／Admin（設定）。
   2. 權限記錄：所有審核與修改需留 modified_by / modified_at / diff。
4. To-Be 流程
   1. 需求蒐集（手機端）：休假、可上時段、偏好班別/崗位。
   2. 自動算量：營收→8h 單位→正職最低量→PT 補缺。
   3. 自動排草案＋違規即時提示→排班負責人微調。
   4. 外場主管審 24h（逾時自動核可）。
   5. 區經理審 24h（逾時自動核可）→發布（LINE/連結/QR、PDF）。
   6. 匯出：CSV（打卡匯入用；暫不接 API）。
   7. 看板：本週班表、缺口、連班風險、休假餘額。
5. 規則引擎（可參數化）
   1. 餐期：AM=10–14、PM=18–22；跨餐期自動切分兩筆指派。
   2. 人力：每餐期每崗位 ≥1（預設，可於店鋪層調整）。
   3. 工時計算：work_minutes = end - start - break；regular_hours = min(work_minutes/60, 8)；overtime_hours = max(work_minutes/60 - 8, 0)。
   4. 阻擋條件：
   5. PT 日工時 >10h；
   6. 正職連續上班 >5 天；
   7. 與已核定休假衝突；
   8. 餐期/崗位未滿編。
   9. 警示（允許提交）：當日休息 <120 分 → 計入加班並標示。
   10. 公平性（輕量）：連續晚餐期/週末班加權輪替。
6. 數據模型
   1. Stores(id, name, business_hours, area_manager_id, …)
   2. Employees(id, name, type{fulltime,pt}, role_primary{cashier/server/kitchen/support}, skills[], store_id, …)
   3. TimeOffRequests(id, employee_id, date, type, status, notes)
   4. DemandForecasts(store_id, week_start, expected_revenue, hour_units)
   5. Shifts(id, store_id, date, slot{AM,PM}, min_cashier, min_server, min_kitchen, min_support)
   6. Assignments(id, shift_id, employee_id, role, start_time, end_time, break_minutes=120, regular_hours, overtime_hours, consec_days, locked, notes)
   7. Schedules(id, store_id, week_start, status{draft,review1,review2,published}, sla_deadline_at)
   8. Reviews(id, schedule_id, stage{supervisor,area_manager}, status{pending,approved,rejected}, comment, decided_at)
   9. Exports(id, schedule_id, type{pdf,csv}, url, status)
7. 系統整合與匯出
   1. 打卡系統：首版採 CSV；API 後續評估。
   2. CSV 欄位（定稿）
   3. emp_no,date,start_time,end_time,break_minutes,role,store_id,is_peak,regular_hours,overtime_hours,consec_days,notes
   4. is_peak: AM/PM（跨餐期切兩筆）。
   5. regular_hours 上限 8；超出入 overtime_hours。
   6. CSV 檔名規則：{storeId}{weekStart}{ver}.csv（UTF-8），例：KS-TC-01_2025-10-14_v1.csv。
   7. 通知：LINE（PDF/連結）；可選 Email/Teams。
8. 介面與輸出
   1. 需求收集頁：行事曆＋偏好表單（手機優先）。
   2. 排班畫布：週檢視（人×日×AM/PM），拖拉指派，違規即時標註。
   3. 審核頁：差異高亮、SLA 倒數、一鍵通過/退回。
   4. 匯出頁：一鍵 PDF（紙本版型）／CSV。
   5. 紙本版型：依現行 Excel 樣式對版（不使用符號，以時段數字與備註呈現）；下方保留「各時段上工人數」統計列。
9. 非功能性
   1. 可用性：手機端順暢；草稿離線暫存。
   2. 可維護：規則引擎參數化（店鋪層設定）。
   3. 稽核性：Log 全紀錄；版本對比。

10 API 介面（Cursor 開發用）

• POST /schedules/:id/autoplan → 產生草案 {scheduleId, warnings[]}
• POST /schedules/:id/submit?stage=supervisor|area_manager
• POST /reviews/:id/decision {status, comment}
• POST /exports/:id/pdf、POST /exports/:id/csv
• 逾時排程：監看 Schedules.sla_deadline_at → 自動核可＋通知。

1. 驗收標準
   1. 排班時間 ↓50%。
   2. 版本反覆（LINE 改版次數）↓60%。
   3. 違規導致事後更動 ↓70%。
   4. 排班負責人 1 週內可獨立完成一次完整週期。
   5. CSV 匯入一次成功率 ≥95%。
2. 風險與對策
   1. 外場主管逾時後仍反對 → 提供「發布後修訂」與「變更通知」。
   2. 打卡系統 API 不可用 → 持續以 CSV；預留 API 介面。
   3. 規則複雜度上升 → 首版聚焦餐期/工時/連班與崗位最低量，其餘分期。