政府標案的成敗，取決於能否把龐大而模糊的需求，控制成一連串看得見、驗得過的節點。任一查核點延遲，都可能導致撥款失敗。
專案管理 · Lens 01
把一年，拆成 26 個驗收節點
用 WBS 把籠統的「系統開發」拆成 26 個可量化的驗收查核點，分三階段交付，每項都明確定義交付型態與查核標準。
示意一年期專案拆解為三階段、26 個查核點的里程碑結構。
實錄驗收查核點規劃：逐項定義交付內容、數量、型態與期限。
專案管理 · Lens 02
撥款依「權重」，不是時間
政府撥款的依據是權重而非單純時間。以甘特圖定義關鍵路徑、優先投放人力，並為高技術門檻的 API 串接預留緩衝。
示意以權重驅動資源調度：營運系統 55% 為重心，API 串接預留 Buffer。
專案管理 · Lens 03
v16 的版控紀律
針對需求變更頻繁的企劃書，建立嚴格版本編號（如 v14–v16），完整保留每次修訂歷程，並系統化歸檔公文與會議紀錄，為結案請款備妥佐證。
實錄提案企劃書版本控管：完整保留修訂歷程（示意 v14–v16）。
本專案需把企業複雜的資產負債表與損益表，移植到 LINE@ 手機版。最大痛點：直接縮放電腦版表格，財務顧問根本讀不了。
產品設計 · Lens 04
不縮小資訊，改變閱讀行為
堅持不犧牲資訊密度，改設計一鍵「轉向」的橫式閱讀模式，用手機長邊呈現完整報表，解決數據擁擠。
示意橫式閱讀模式：一鍵轉向，用手機長邊看完整財務報表。
產品設計 · Lens 05
用原型驗證邏輯，而不是等開發完才發現
以 Axure RP 繪製高保真互動原型，在開發前先驗證後台權限邏輯與自動化通知觸發條件（如預約取消時同步推播給顧問與用戶）。
產品設計 · Lens 06
把規格鎖死在 PRD 裡
精確定義每個欄位屬性與 RBAC 分級權限，建立標準化 Data Schema，並提供 JPG（業主預覽）與 CSV（顧問分析）分眾輸出。
示意RBAC 分級權限與標準化資料定義。
實錄視覺化開發月報：把進度對照 UI 截圖，讓業主看得見成果。
要整合線上 LINE@ 與線下實體論壇的 OMO 體驗，並在有限時間內從零建立會員基數、串聯線上線下數據。
成長行銷 · Lens 07
先算清楚每個好友的來路與成本
從財務視角規劃預算：以彈性係數估算各通路觸及與獲客單價，反推 30,000 好友目標，把預算花在刀口上。
示意各通路觸及推估與 30,000 好友目標的反推邏輯。
實錄推廣費用粗估：以彈性係數推估各通路觸及、反推好友目標。
成長行銷 · Lens 08
無痛的 Onboarding 動線
用圖文選單（Rich Menu）把用戶分流至「線上申請」「資格試算」「客服諮詢」，並把文字選項轉為 Icon 按鈕提升點擊率。
實錄LINE@ 引導介面與 Rich Menu 分眾動線。
成長行銷 · Lens 09
知識型內容 × 模組化系統
把生硬政策轉譯成手機易讀的懶人包圖卡，靠內容價值驅動自然分享；並以高內聚、低耦合的模組化架構支撐多場次活動與擴展。
上列為專案規劃與 KPI 目標值；實際達成之會員數與轉換數據以結案報表為準。
