安否通 弱勢機構災情即時回報平台
角色 組長／提案人（2026/8，公民科技協力場提案） 類型 公民科技 ・ 政府徵案提案 團隊 兩人（產品與專案管理 ＋ 需求分析與系統測試） 負責 問題定義 ・ 流程設計 ・ 介面設計 ・ 範圍切分 ・ 期程與風險規劃 ・ 決選簡報
數位發展部「115 年全國公民科技試驗場域推廣案」，新北市政府議題四。
問題
新北市轄內的醫院、護理機構、長照與身心障礙福利機構數量繁多。依市府現行作業，地震發生後由災害應變中心人員取得名單，人工逐一撥打電話確認人員安全、建物受損與收容狀況，未接通者反覆重撥並人工記錄——全數清查預估要數小時。
災後最初 30 分鐘到數小時，是建立災情全貌與配置應變資源的關鍵階段。而在這段時間裡，市府最該用來做決策的人力，正忙於撥號。
把現況拆開來看，五個現象其實是同一個結構問題：
| 問題 | 影響 |
|---|---|
| 清查方向由市府「逐一詢問全部機構」，而非機構「主動回報異常」 | 工作量與機構總數成正比，無法隨災害規模調整 |
| 應變中心人員在最需要決策的時段執行撥號與記錄 | 決策品質下降 |
| 完整圖像須等全數清查完成才成立 | 延後資源配置決策 |
| 流程完全依賴電話 | 通訊中斷時最需要資訊，卻最拿不到 |
| 人工紀錄難以留存與比對 | 每次災害都從零開始 |
市府把有限人力平均花在「全部機構」上，而不是優先處理「尚未確認者」。
解法：把清查方向反轉
這是整個提案的主軸，其餘所有設計都服務於它。
過去：市府 → 全部機構逐一撥號。連完全沒事的那些，也要問一次。 改為：系統點名 → 機構主動回報 → 市府只把人力投在未回報的那幾家。
收斂成五個步驟：
| 步驟 | 內容 |
|---|---|
| ① | 權責人員發起點名 |
| ② | 系統批次送出一次性回報連結 |
| ③ | 機構三選一，免登入回報 |
| ④ | 未回報自動升級（重送、換通道、通知第二聯絡人） |
| ⑤ | 市府處理未回報佇列 |
反轉之後，市府的工作量從「機構總數」變成「異常數」。這不是功能設計，是作業模型的改變。
核心產品是那份清單，不是那張表單
市府端主畫面刻意不呈現全部機構列表，只呈現未回報者優先佇列，依「機構脆弱度 × 所在地災害規模 × 未回報累積時間」排序。
市府拿到的不是一份全部機構的名單，而是一份排好優先順序、可以直接派工的未回報清單。
前面四個步驟存在的意義，就是為了讓這份清單成立。
整份提案我反覆強調的一句話是：
未回報不等於沒事，也不等於有事。它只代表「尚未確認」。
正因為只代表尚未確認，需要的就是自動升級與人力投入判斷，而不是等待。已回報正常的機構不會出現在這份清單上，市府人力完全不投入。
判斷與取捨
免登入，因為災時沒人記得密碼
避難弱勢機構人員流動率高，災時的值班者未必記得帳號密碼。如果以個人帳號密碼作為唯一入口，系統會在最需要的時候把人鎖在門外。
所以回報連結是一次性、限時、限該機構範圍，點開即可回報，無須登入；權責單位是機構帳號而非個人帳號，只有查看歷史紀錄或修改機構資料時才要求正式登入。
必填只有一個動作
災後最初 30 分鐘，機構值班人員正在安置住民、確認設備、聯繫家屬。任何需要登入、需要填多欄位的設計都會失敗。
必填因此壓縮到三選一——一切正常／需要支援／嚴重受損。其餘欄位（傷亡人數、是否需疏散、水電與氧氣供應、可收容餘裕、照片）全部選填、可事後補。
設計目標是必填回報比接一通電話更快。
不做「等機構自己來填」的通報平台
災時不會有人主動開啟系統。所以是系統去點名，不是平台等人上門。
自動觸發不做，因為那不是我能決定的事
「震度多少觸發」「哪些行政區」「誰有權決定啟動」——這些是災害應變的政策判斷與權責劃分，不是技術參數。提案人無權自訂。
所以 P0 一律是權責人員手動發起；自動觸發列為 P1，且必須先經合作機關核定規則。系統只提供可設定機制並保留完整發起軌跡。
執行：先當自己的評審
送件前，我把提案當成初審委員的角度重審了一次，逐項打分（12 項共 120 分），並列出評審最可能追問的問題。
結果是 86 分，入選邊緣偏正面。而兩個最低分的項目都在意料之外：
- 使用者需求理解 5／10 — 徵件階段一場第一手訪談都沒做，所有使用者洞察都是從市府需求說明與公開文件推論出來的。
- 技術可行性 6／10 — 兩人團隊卻列了六層回報降級通道，其中語音外撥、鄰近機構代報、現地登錄、紙本補登各自都是獨立子系統。這是過度承諾。
依這份審查，送件版做了幾個實質修改：
- 功能分級 P0／P1／P2，示範期只承諾 P0 七項，期程交付內容也只綁定 P0。分級是依團隊產能反推，不是依技術可行性排列。
- 量化數字全部改為設計目標。原本寫「5 秒完成回報」「15 分鐘取得多數回報」，但那些數字沒有依據，改成「設計目標，待示範期實測建立基線」。
- 不再使用「黃金 72 小時」，改為「災後最初 30 分鐘至數小時」——後者才是這個系統真正作用的區間。
- 資安改為三段式標示：設計原則（已確立）／預計執行（尚未開始）／已完成：無。
- 在計畫書開頭主動聲明兩項限制：尚未進行第一手使用者訪談，以及政策權責、法規依據、系統介接權限均未與合作機關確認，一律標示為待確認，不自行預設答案。
第 5 點是最難下的決定。把最大的弱點寫在文件第一頁，等於主動把扣分項送到評審眼前。但我判斷，這個弱點評審一定看得出來——被抓到跟自己承認，是兩種完全不同的印象，而且承認之後，我才能把「使用者研究列為合作啟動後第一項工作、且為系統架構定案的前置條件」寫成一個可信的承諾。
結果
通過文件初審，進入 8/25 的決選現場簡報。
新北市議題四最終錄取兩組：正取是睿鍇科技，備取是我們——兩人團隊「羊肉會飛」。
沒有拿到正取。以結果論，這是一次沒有成功的提案。
反思
我把「誠實」當成策略，但誠實不能替代證據。
自我審查抓到了過度承諾，也讓文件變得可信。但它沒辦法解決真正的問題：那 5 分的使用者需求理解，缺的不是更好的寫法，是兩場訪談。
我在計畫書裡寫「使用者研究已列為合作啟動後之第一項工作」——這是誠實的，也是對的順序，卻同時暴露了一件事：所有關於機構人員災時行為的判斷，包含「值班者不記得密碼」「三選一比打電話快」這些我最有信心的洞察，全部都還是推論。而競爭對手是一家科技公司。
如果重來一次，我會在送件前就去找一家機構、聊 30 分鐘。哪怕只有一場、哪怕不具代表性，那也是第一手的。用兩週的準備時間換一份完全建立在推論上的問題模型，是我判斷失誤。
另一件學到的事是，收斂範圍會讓提案變好看，但不會讓它變強。
砍掉四層通道之後，文件的可信度確實上升了。但可信度是門檻，不是優勢——它讓提案不被扣分，不會讓提案被選上。真正該補的，還是那些我沒去問的問題。
這個判斷後來直接影響了我做產品的順序：先去問，再開始寫。