AMMS Kickoff 資訊及討論內容
AMMS 專案前期已啟動；本頁用於需求規格對齊會議與後續追蹤，作為跨部門共識底稿。
定位：風險對齊＋探索型 Kickoff（問題導向，不究責），先補齊需求規格與驗收標準，再透過探索收斂假設，讓研發、外部廠商與使用單位能依同一基準推進。
現況與可用輸入
- 專案已啟動，但需求規格與驗收標準尚未定案
- 研發團隊缺乏可執行規格，無法有效展開開發
- 舊系統經驗與痛點
- Dashboard 原型頁面（可展示）
- AMMS Agent 初步方向（建議先 L1）
本次會議目的與延誤風險
- 目的：完成需求定義、驗收標準、v1 做/不做清單與責任分工。
- 若未對齊：研發排程持續空轉，外部協作與估價依據不足，時程延誤風險擴大。
- 會後輸出：PRD/SRS 負責人、交付時點、Stage 1 Gate 通過條件。
本次不是重新啟動專案，而是把「可討論」轉為「可執行、可驗收」的基準會議。
英文名詞說明（給會議參與同仁）
| 名詞 | 是什麼 | 在這次會議中的用途 |
|---|---|---|
| Kickoff | 專案啟動會 | 先對齊目標、範圍、角色與時程，不要求一次定案所有細節 |
| Dashboard | 儀表板介面 | 用來展示設備狀態、數據、告警、報表與操作流程想像 |
| Agent | AI 助理模組 | 協助問答查詢、提出建議，後續再視風險決定是否自動執行 |
| Stage-Gate | 分階段審查流程 | 每一階段有交付物與 Gate，通過後才進下一階段 |
| PRD | 產品需求文件 | 說明要解決的問題、使用者情境、功能範圍與優先序 |
| SRS | 系統需求規格 | 把需求轉成可開發、可測試、可驗收的系統規格 |
| Wireframe | 畫面線框稿 | 先確認畫面欄位、流程與操作順序 |
| API | 系統介面規格 | 定義系統、設備、平台之間如何交換資料 |
討論主軸
| 主題 | 重點 |
|---|---|
| 客戶與場景 | 優先產業、痛點、願付費能力 |
| 設備與資料 | 點位規模、歷史保存、查詢需求 |
| 告警與報表 | 級別、通知、ACK、合規與匯出 |
| 部署與整合 | On-Prem/SaaS、SCADA/MES/ERP 串接 |
Agent 規劃（建議）
| 層級 | 能力 | 時程 |
|---|---|---|
| L1 | 問答查詢，不改設定 | Phase 1 |
| L2 | 提出建議，需人工確認 | Phase 2 |
| L3 | 執行動作，需嚴格審批 | Phase 3 |
Stage-Gate 流程
- Stage 0：Kickoff 對齊（先收斂，不求定案）
- Stage 1：需求定義（PRD/SRS + Wireframe）
- Stage 2：技術設計（架構/API/資料模型）
- Stage 3：MVP 開發（Staging + Sprint）
- Stage 4：UAT/PoC 驗證（KPI 檢核）
未通過 Gate，不進下一階段。
文件與交付物
| 文件 | 用途 | 主要提供 / 協作 |
|---|---|---|
| Kickoff Package | 整理背景、目標、範圍、決議、待辦與補件責任 | PM / 業務 / 研發 |
| PRD | 定義產品價值、場景、功能範圍與優先序 | PM / 業務 / 行銷 |
| SRS | 定義系統功能、流程、限制與驗收條件 | PM / 研發 / 外部廠商 |
| Wireframe | 確認頁面與操作路徑 | PM / UIUX / 使用單位 |
| API / 資料模型 | 定義串接方式、欄位、格式與資料流 | 研發 / SI / 外部廠商 |
| Backlog | 整理功能待辦，供 Sprint 排程與估工 | PM / 研發 |
| UAT 計畫 | 定義驗收情境、角色、測試案例與 KPI | PM / 使用單位 / QA |
同仁在會議上至少要知道：每份文件是做什麼、由誰準備、何時要交，這樣後續才不會只停留在口頭討論。
開發模式
建議：外部開發 + 內部治理（研發主導、跨部門校正）。
- 不建立大規模自研團隊
- 保留需求決策、驗收、供應商管理能力
外包與維運重點
- 合約要寫清楚：原始碼、文件、帳密歸屬與交接條款
- SLA 分級：P1/P2 首響與修復時限
- 維護拆分：Run / Change / Build
- AgentOps：版本控管、失敗率、越權風險與審批紀錄