20150925 更新: 美國政府最近更發布了官方網站設計指南，相關中文報導。

2013年10月，美國政府的HealthCare.gov網站上線，目的是讓沒有自行營運網站的各州，其居民能夠輸入資料、搜尋配對適合自己的醫療保險公司以及相關補助，也是俗稱Obamacare健保政策的一部分。結果這個花了五百萬美金打造的網站，竟無法應付龐大的流量，上線後的一週內只有1%的人能夠完成他們的查詢及送件，且就算資料送到了後端，很多醫療保險公司反應收到的資料並不齊全，更不用說網路上數百個假健保網站橫行，媒體還報導網站本身會將民眾個資分享給廣告公司，總之這個網站是個大災難，最後請了一位在google工作八年的可靠度工程師Mikey Dickerson來解決，而事後評估整個網站的成本高達17億美金，此事件詳情可參照維基百科。

有了這個慘痛的教訓後，2014年8月，美國政府啟動了國家數位服務小組（U. S. Digital Service），由Mikey Dickerson領導，讓其他政府部門在數位服務設計的初期就能要求諮詢，以免HealthCare.gov的災難重演。同時白宮也釋出了一本「數位服務最佳實務（U.S. Digital Service Playbook）」，內容包含了打造數位服務的13個最佳實務，每一項都附有觀念說明、檢核項目（checklist）與關鍵問題（key questions），可說是內外功兼備，非常值得我們政府及資訊人員參考。

「數位服務就是以數位渠道（digital channel）與民眾互動，例如透過網站、Email、App提供的服務。…今日，我們有太多的數位服務差強人意、時程延遲或超出預算。…透過遵循以下13個來自業界與政府的最佳實踐（Best Practice），將幫助政府創建更有效的數位服務。」

了解使用者需求（Understand what people need）

專案必須永遠緊跟使用者需求 – 使用者真正需要的是什麼，服務要以什麼方式融入使用者的生活。無論使用者是民眾或是政府雇員，他們必須在專案初期就加入，且在開發過程中持續測試你的產品，以確保我們知道專案真正的重點是什麼。記住，永遠讓使用者需求 – 而非組織架構或閉門造車 – 決定專案的技術與設計

• 在專案初期就花時間了解目前跟未來的使用者
• 使用一系列的量化跟質化方法了解使用者的目標、需要跟行為
• 讓使用者試用各種解決方案的雛形，可能的話盡可能貼近其使用情境
• 把挖掘到的使用者目標、需要跟行為記錄下來，並與團隊及大老闆分享（以後的團隊要去哪裡找這些文件）
• 建立具有優先順序的使用者情境腳本清單，以簡短描述使用者目標
• 專案開發過程中，定期讓使用者試用以確保符合其需要

聚焦使用者的整體經驗（Address the whole experience, from start to finish）

雖然我們做的是數位服務，但必須了解：民眾取得服務的方式不僅有一種，甚至不是數位的。不管是上網、透過App、打電話，甚至親自跑一趟，都必須確保民眾每一次不論透過什麼方式，都能一步步接近他需要的結果。

• 了解民眾會在什麼流程點透過什麼方式取得服務 - 無論是不是線上（數位）的
• 辨認民眾在使用目前的服務時最痛苦的地方是什麼，優先改進這個地方
• 設計數位服務時，必須與實體服務流程整合，使服務一體化
• 在服務的各個步驟設計評估指標，評量該步驟是否符合使用者需要

簡單直覺（Make it simple and intuitive）

政府服務不應該讓人有壓力、困惑或懼怕，我們的工作是讓服務夠簡單及直覺到使用者第一次使用且沒有人幫助的情況下就能上手。

• 使用已知、簡單且彈性的設計樣式；相關服務的樣式要一致（甚至要考慮與其他政府服務在視覺上的關聯）
• 清楚地告訴使用者：他們目前進行到服務的哪個階段或流程；當使用者需要時如何取得協助；要怎麼中離，中離後怎麼繼續未完的流程
• 遵循可用性的最佳實踐（Accessibility best practices）以確保所有人都能使用服務
• 用淺顯易懂的語言，並在所有地方（不論是數位或實體）保持語言跟設計的一致性（淺顯易懂的語言可參考美國直白書寫法案）

敏捷與迭代的開發方式（Build the service using agile and iterative practices）

敏捷跟迭代是打造數位服務的最佳開發方法。要讓專案成功跟符合使用者需求最好的方式就是快速產出雛形，盡快讓使用者試用，並據以調整專案。能夠做到這件事的關鍵能力就是自動化測試跟部署，才能讓新功能可以很輕易地更新。

• 專案開始後三個月內就要產出會動的產品（可以掛上beta字樣，直到真正完成為止），目標是先解決使用者最核心的需求。經常進行易用性測試（Usability test），並取得使用者回饋以改進專案。
• 每個月有多次的版本更新跟 bug 修正
• 用 issue tracker 管理跟排序你的需求跟 bugs，導入版本控制跟 code review
• 保持小規模且專注的開發團隊，並限制團隊的組織層級，團隊成員可使用戰情室、每日立會（站著開會）、群聊工具等頻繁且緊密的溝通。

適當的合約書與預算結構（Structure budgets and contracts to support delivery）

大多數專案都是外包，外包必須依照合約執行，且使用政府預算付款，因此有經驗的承辦人、好的合約範本以及有彈性的預算執行方式，都是打造數位服務不可或缺的助力。例如使用者需求探索、雛型產出、其他開源專案評估、需求修改、專案里程碑、雲端運算資源採購等項目，都是合約書內要考量的內容。美國政府有另外一本指南（The TechFAR Handbook）專文探討。

• 專案預算必須包含需求或技術研究及雛型產出（註：凹廠商作白工嚐到苦果的總是機關自己）

合約書要注意的內容有：

• 要求廠商負責頻繁的產出成品（或雛型），而非好幾個月才檢查一次的里程碑
• 成品演進過程中，甲方有調整需求順序的權利
• 考量技術選項時要把開源解決方案納入評估
• 產出的軟體及資料必須要在甲方控制之下，能夠依照適當的法律規定重複使用及釋出給公眾
• 若採用廠商的服務或工具，確保有不同的計價方式，如固定計價或依需求計價
• 效能指標，如系統反應時間、系統正常服務時間、不同優先權的需求/錯誤處理時間等
• 註明保固期，保固期內發現的bug應免費修正
• 合約包含系統或服務的日出及日落條款（服務轉移期）

以我接觸過的國內政府現況來說，以上這些內容大部分都有，但合約範本還是偏向傳統waterfall模型，因此在專案彈性上，例如需求順序調整、雛型產出週期、開源方案的評估方面都不足。另外系統開發前的使用者需求探索及使用者的參與也不夠，這會導致專案需求一改再改，廠商被一凹再凹，弄得甲乙雙方都很累…

一人當責（Assign one leader and hold that person accountable）

每個專案都要有一個人負責產品的成敗，並賦予其相應的權力（而非只講義務），專案的各項行政及技術決定由他說了算，他的終極責任就是確保產品符合使用者需求，並且以此來評估負責人的績效。

• 所有利害關係人都同意專案負責人有專案項目功能及工作分派的最終決定權。
• 專案負責人要有專案管理跟技術背景，才能評估各技術選項及工作難度以便工作分派。
• 專案負責人要會估預算，知道錢能從哪來，且與乙方保持良好關係。

這大概是目前政府專案欠缺的部分。首先擁有專案生殺大權的一定是最高的官，但高官往往沒有專案管理跟技術背景，或早已生疏，對預算細節及乙方底細也不是很清楚；符合後面兩點的可能是中階主管如科長級，但科長級又往往只被要求盡義務不被賦予權力，所以專案成敗＝層層負責＝沒人負責，你懂的…

（待續）