AMMS Kickoff 資訊及討論內容
本頁用於 Kickoff 會議與後續追蹤，作為跨部門共識底稿。
定位：探索型 Kickoff（可先從舊系統 + Dashboard + Agent 初步方向啟動）
現況與可用輸入
- 舊系統經驗與痛點
- Dashboard 原型頁面（可展示）
- AMMS Agent 初步方向（建議先 L1）
英文名詞說明（給會議參與同仁）
| 名詞 | 是什麼 | 在這次會議中的用途 |
|---|---|---|
| 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：版本控管、失敗率、越權風險與審批紀錄