純粹留下紀錄，設想的閱讀對象是對政策的發展有興趣的朋友。例如說，你是機構的管理者，或是採購的決定人，或是單位裡面負責整體數位政策的那一位，你可能身在公部門，也可能在私部門獨當一面。面對這麼龐大的口罩供應即時查詢「需求」，要如何在如媒體所稱的號稱48小時之內，「開發」出一個即時查詢的系統？
需求是什麼？
首先是，這需求是哪裡來得？例如說，是每一個人都要能查詢口罩的即時庫存量嗎？需求的定義是很難的，也非常花時間，尤其是對大型的資訊系統而言。這時候，通常的做法是先搞清楚利益攸關者，也就是說，這個對外的資訊系統從討論、需求訪談、啟動、測試、上線和維護等，要先比較清楚的知道會有哪些「角色」會被服務到，或是會被牽扯到。這個「專案」的 “sponsor” 是誰，服務的是誰等。這種思考的路徑，無論如何緊急，最好都不要省略。模模糊糊有概念也好，不用想到很精細，尤其是這個資訊系統要服務的，是這次「口罩之亂」所引起的「需求」。
這次「口罩之亂」和即時庫存查詢需求的出現，源自於實名制的產生。實名制的新聞發布，到實際必須提供系統服務，大概只有不到72小時的作業時間。所以需求是什麼，哪些是剛性的，哪些是假性的，哪些是可以晚一點處理的，哪一些是一定會「被罵的」，哪一些是需要錢的，哪一些是可以「丟出去」的。
我們能看到的是，先有來自台南的工程師團隊，很快的利用 GCP 平台，製作出了「即時口罩地圖」。但那時衛服部主導的中央流行疫情指揮中心，照我們所得知的媒體訊息來看，一開始可能沒有這樣的想法。但在媒體的熱心報導之下，這個「即時口罩地圖」，成了第一個資源條件有限和需求定義不明的「犧牲者」。
中間我們先跳過大約50個小時，看看需求在衛福部的口罩實名制正式於2月06日上線後，遇到了什麼問題。有幾個比較明顯的：
- 對外系統全掛（web/app 端），對內系統（藥局端）保持順暢但反應緩慢
- 庫存量幾乎不可能「即時」
- 健保特約藥局有不同的營業時間
- 健保特約藥局不是只有這個業務，還有其他業務（調劑、診所等）
- 一般民眾對於「即時」的期待，包含資訊的即時性、正確性、可取得性等的需求，不可能「滿足」
這些問題在2月6日早上各系統上線後面臨了「實證」，而衛福部自己即時庫存的「網頁」，也在幾小時後不得不下線，先轉去 PDIS 手刻的展示頁面，將這個需求和負載先行過繼給「民間」。
哪些是我被授權解決的需求？
這對於外部的「民間」團隊比較沒有這方面的疑慮，但是對於政府各單位以及緊急防疫情境下的公務員，是有很大的不同限制。例如說，所謂衛福部的 app 查詢介面緩慢，到底原因是什麼？根據目前我們與 app 合作業者的採購合約限制來看，我們是否只能「加機器」以解決查詢訪問量大增的狀況？加了機器就能讓 app 查詢時間變快嗎？還是是機器對外頻寬的問題？對外頻寬要加到多少？要花多少錢？如果隔天重新上線要再加，我們能談到比較好的對外頻寬 (outbound) 價錢嗎？下決定的是誰？下決定的人跟我的關係是什麼？如果他是我健保署的上司，我大約知道這些可能發生的狀況，但老闆已經在記者會上說明，我不是這個計畫的編組人員，我該說話嗎？我甚至沒有獲得授權參加相關討論會議。這些會衍生出的需求，我該怎麼辦？
這個系統畢竟不是「媒體資訊系統」，所以在「授權」的層級會有不同的狀況。媒體資訊系統的授權，在這個年代的台灣，大概壓縮得很扁平。要服務的需求，也非常單純。例如說，授權的層級有主編、編輯、記者、設計師、工程師等。一條新聞上到網站，只要能產生足夠的 traffic。只要沒有「假消息」的疑慮，這個新聞的網址要如何被散佈，內容如何修改，大概也不會有什麼問題。一篇報導能產生到不重複 IP 數萬甚至到上百萬的訪問量。
但口罩庫存的即時查詢系統，當然不是這麼回事。衛福部有自己的授權層級，負責派送物資的郵局，也有自己的系統（這裡不是單指資訊系統而已）。然後是特約藥局和工會，藥局本身的內部。藥局本身內部還有電話和網路這兩條可能湧入需求的數位「線路」，前者是電信，後者是衛福部趕工上線必須透過 VPN 連接的內部系統，而這系統還牽涉到藥師卡等。而且即時查詢系統，需求方很多，使用系統的各個角色，來來回回比媒體資訊系統複雜許多。藥局和衛福部的內部系統可能還好，但要對外的部分，就一發不可收拾。
藥局應該沒有配置資訊人員，連鎖的藥局可能在總部有資訊團隊的編制。上面提到的幾個角色，都還不是口罩的購買人。每一個人的角色不同，被授權能解決的需求，有些是組織規制，有些是法有明定，有些是資訊系統就把授權做好了。任憑任一個人，都很難跳過授權科層，去處理其他段的問題。
再來是來購買的民眾，民眾就是產生大量的需求，他不需要被授權，而且是產生大量變動的需求。
哪些需求是一定會變動的？
以今天早上來看，可分為幾個環節：
- 衛福部：網站掛了，本來希望訊息都從我們這邊發出，但只好呈報主管說，能不能在網頁上直接連去不是衛福部的 PDIS？
- 衛福部：App 掛了，同上，但沒有 PDIS 可以連，而且軟體市集的上架，不是說要上就要上，還要審的。App 也不是自己人所開發，有合約在，要討論，這等於是當時 app 的需求書內沒寫到，要加「規格」，是需求變動。
- 藥局：臨時人調不出來，藥局有人要照顧小孩，只好中午進去再測試昨天被丟出來的教戰守策。能測得好不好還不知道，即時庫存回報跟我沒有關係，店能開起來比較重要。中華民國藥師公會全國聯合前幾天「下令」說一天要服務口罩登記和銷售兩小時，不然會建議衛福部解約。對我的店面來說，這是重大的需求變更沒錯。但我不能不開店，開店就要面臨實體 DDoS。
- PDIS：PDIS 有自己順暢和即時的對外溝通管道，看他們的發佈管道會更清楚。
這些需求的變動頻率，樣態，是不是在啟動實名制加上口罩即時庫存查詢系統前可以「預想」的？我認為很難，因為大家的專業不同，就算天縱英才，沒做過沒踩過地雷就是不會知道。踩過能不能快速修正，也取決於需求的重新定義和資源的調配。另外，一天24小時，資訊系統的負載也有高低鋒之別。
哪些需求是透過觀察才發現不是真需求？
這個在第一天各系統上線的幾個小時內，也能觀察到。首先是，透過桌機或是筆電用瀏覽器查詢衛福部或是民間各大即時口罩供應系統網站介面的使用者，很多只是去「逛逛」。打不開頁面之後，就一個一個網站去逛（點）。有些網站嵌入了圖台（地圖），讓檢索的流程有很多線可以走，大幅增加系統的負擔和系統反應的時間。有些網站則是用傳統的下拉式選單，但其設計的作法也讓使用者必須快速切換和送出檢索請求，這當然也是讓網站反應不過來。至於衛福部本身的網站，則由於前一天大肆透過網路媒體將網路連結公開發出，第一時間就大量湧入查詢請求。即使號稱都準備好了（根據媒體所述），不到兩個小時就必須改弦易撤，將資源動態調配。
很多查詢的人是「看熱鬧」的。當然我們不能直接說，這就是看熱鬧的人「壞了事」。網站的拜訪不像騎摩托車去藥局賭賭運氣，任誰都可以拿到連結就開啟網站（也包含全世界的拜訪者和網路機器人）。操作網站介面，大量重複的鍵入相同的檢索條件，這個使用者的行為是可以預期的，尤其是在兩天媒體的推波助瀾下。不過，說這不是「真需求」也不對，倒不如說這不是我們預期希望能服務的需求。
哪些需求是可以透過溝通計畫，讓資訊系統可以服務到更需要的人？
由於大型的資訊系統本來就建置不易，能夠確定需求、快速建立，成本可控可期，且能馬上服務大量訪問的網路系統，通常其服務的目的和需求都比較單一。而我們上面的簡單討論，就跑出了不同軸線，讓我們有機會進一步即時探討當下所發生的事件。為了防疫的努力 ，所有環節的角色都是辛苦的。但資訊系統畢竟不是祈禱就能運作，民眾的使用行為千奇百種，各專業的加入是很重要的。我們也不太可能要求藥局為了要讓資訊系統能即時反應口罩存量，而讓其資訊系統的商業邏輯或是人事作業邏輯做出一次性的大幅改變。或許從另外一個角度來說，從政策、資源、現實和需求考量而出發的整合溝通計畫，才是「緩解」甚至是讓這些努力得以發揮到最好效用的途徑之一。
聽聞衛福部明天系統將重新上線，我們繼續觀察。留些紀錄，讓大家的經驗和記憶能累積，讓未來可以做得更好。
補充：第二天的思考
T.H. Schee 