美國數位服務腳本

美國人希望能透過數位管道,像是網站、電子郵件或行動應用來和政府互動。透過建立更好的數位服務,來滿足使用這些服務的民眾需求,可以更有效的傳達政府政策和計畫。

今日,我們有太多數位服務計畫運作不良,交付延遲,或超出預算。為了增進計畫成功率,美國政府需要新的作法。因此我們設計了這個包含十三項關鍵腳本的手冊,列出成功公私兩方實踐的最佳方式,如果依此進行,便能協助政府建立更有效的數位服務。

PLAY 1

了解人們需要什麼

我們必須透過探索來確立服務使用者的需求,以及了解該服務將如何融入他們生活,來啟動一項數位計畫。無論使用者是公眾還是政府雇員,政策制定者需在一開始便將真正參與者納入設計過程中。技術與設計決定應該取決於人們的需求,而不是受政府筒倉式的結構(譯註:指一個個獨立而互不相關的單位)所限。我們需要以真實的人持續測試建立出來的成品,讓我們誠實面對最重要的事物。

檢查表

  1. 在計畫初期,花時間和現在與可能服務用戶討論
  2. 使用各種定性與定量用戶研究方法來決定人們的目標、需求和行為。注意所花費的時間成本
  3. 與真實的人測試各種可能解法的原型,若可能的話,在真實的情境進行
  4. 紀錄所發現的使用者目標、需求、行為和偏好
  5. 將發現與團隊或機構分享
  6. 創造使用者故事優先清單,那是一項對使用者試圖完成的目標設想而寫出的簡短敘述
  7. 當數位服務建立後,以潛在用戶對這項服務進行規律測試,以確保它將會符合未來的需求

關鍵問題

PLAY 2

從開始到完成,傳達完整經驗

我們建立數位服務時,必須了解個人和服務互動的各種方式。這包括他們的線上活動、藉由行動應用、電話、或是親自拜訪。每次的接觸,無論是線上還是線下,都應該讓使用者更接近預期的結果。

檢查表

  1. 了解人們與服務互動時的各種差異點 — 包括線上和親自拜訪。
  2. 確認現在使用者與服務互動時的痛苦點,並且依照使用者需求排出優先順序
  3. 設計服務的數位部分,讓這些能和使用者與服務互動的線下接觸點整合在一起
  4. 在服務的每一個步驟中,都要發展能夠衡量服務如何滿足使用者需求的指標

關鍵問題

PLAY 3

讓事情簡單、直覺

使用政府服務不該是充滿壓力、疑惑或者讓人卻步 — 建立一個簡單又直覺的服務是我們的責任,要讓使用者在初次使用時,不需任何協助就能達到目的。

檢查表

  1. 為此項服務創造或使用一個現有的簡單、具彈性的設計風格指南
  2. 在相關數位服務上使用相同的設計風格指南
  3. 提供使用者清楚的資訊,讓他們在使用服務時,能了解自己位在服務中的哪個步驟
  4. 採用最好的無障礙實務典範,確保所有人都能使用這項服務
  5. 提供使用者能夠暫時離開、並在稍候完成服務步驟的途徑
  6. 使用對使用者來說熟悉且容易理解的語言
  7. 在服務中使用一致的語言和設計,包括人們和服務互動的所有線上與線下(非數位)接觸點

關鍵問題

PLAY 4

採用敏捷、遞迴方式以開發服務

我們必須用一個漸進、快速的軟體開發形式來降低失敗風險,這是藉著讓軟體快速到達使用者的手上、以及頻繁的提供機會讓交付任務團隊能調整需求,並根據對人們使用原型和實際軟體的觀察,來修訂開發計畫。關鍵能力是自動化測試與服務配置,讓新功能可以經常加入並且輕易投入產品中。採用敏捷方式,已經證實是建立數位服務的最佳實踐,這也將讓我們更有能力建立有效吻合使用者需求的服務。

檢查表

  1. 儘快提供一個能正常運作最低可行產品以解決服務核心用戶需求,時間需在任何新數位計畫開始的三個月內。需要的話,設定Beta測試期
  2. 經常進行可用度測試,來檢視服務對用戶來說是否運作良好,以及確認應作哪些改善
  3. 確保建立服務的成員間彼此保持密切聯繫,包括使用像是作戰情報室、每日站立會議還有群組聊天工具等技巧
  4. 保持一個小而專注的交付團隊;減少區隔團隊與業主間的組織層級
  5. 每個月多次釋出功能和改善
  6. 建立功能與臭蟲的優先順序清單,這通常又稱作 "未完成功能清單" 以及 "未清除臭蟲清單"
  7. 使用項目追蹤工具將功能與臭蟲編目
  8. 使用源碼版本管理工具
  9. 確保整個團隊都能存取項目追蹤和版本管理工具
  10. 進行代碼審查來確保品質

關鍵問題

PLAY 5

框定預算和合約以支持交付

為增進委外開發工作的成功率,需要有經驗的預算官與訂約官共同參與。如果需要由第三方來協助架設服務,完整合約能夠促成良好開發作法,像是進行研究與建立原型階段、當服務架設後持續改善產品需求、評估開源選擇、確保能時常達成里程碑,以及提供購買雲端運算資源的彈性。

聯邦科技採購規定 (譯註:目前尚為英文版,待譯) 詳細解釋了原聯邦採購規定中的彈性,可幫助機構將本遊戲 (譯註:Playbook)落實。

檢查表

  1. 預算包含研究、發現與建立原型等活動
  2. 合約架構需能要求時常交付標的,而不是數個月長的里程碑
  3. 合約架構需能讓供應商對交付標的負責
  4. 合約需讓政府交付團隊在計畫發展時,仍保有修改功能優先順序的彈性
  5. 合約中保證在做技術選擇時,將一併評估開源解決方案和商業方案
  6. 合約需指出第三方產出的軟體和資料維持在政府控制下,且能酌情並依法重複利用並釋出給公眾
  7. 合約需讓政府使用來自供應商的工具、服務與托管時,確保其提供多樣定價模式,包括固定價格以及各式各樣以服務為主的定價方式,如使用時付費制
  8. 合約需指明保證期,讓公眾發現的缺陷能由供應商負責處理,政府不需另外支出
  9. 合約包含服務過渡期以及其後的轉換計畫

關鍵問題

PLAY 6

指派一位領導者,並且要求其負責

在組內必須有一位產品負責人有權並負責指派任務與工作項目、作業務、產品以及技術決策、以及對整個服務的成敗負全責。這個負責人將對服務如何能吻合使用者需求負有完全責任,吻合使用者需求也應是評估服務的方式。產品負責人有責任確保功能均有建立,並管理功能和臭蟲清單。

檢查表

  1. 已經認定一位產品負責人
  2. 所有利害關係人均同意產品負責人有權指派任務並對功能及技術實行細節作決定
  3. 產品負責人具有產品管理背景,以及技術經驗來評估替代方案與衡量其取捨
  4. 產品負責人手上有工作計畫,包括預算估計以及確認過的資金來源
  5. 產品負責人與他/她的訂約官保持穩健的合作關係

關鍵問題

PLAY 7

導入有經驗的團隊

我們需要有才能、有創造現代數位服務經驗的人在政府內工作。這包括導入有經驗的產品經理、工程師以及設計師。當需要外部協助時,我們團隊應與訂約官 (contracting officer) 合作,他了解該如何評估第三方技術能力,所以團隊能和擅長建立與交付有效率數位服務的承包商配對。團隊的組成與經驗需求將因計畫的範圍而異。

檢查表

  1. 團隊成員具有建立受歡迎、大流量數位服務的經驗
  2. 團隊成員具有設計行動與網路應用的經驗
  3. 團隊成員具有使用自動化測試架構的經驗
  4. 團隊成員具有現代開發與營運技術 (DevOps)的經驗,如持續整合與佈署
  5. 團隊成員具有數位服務資訊安全的經驗
  6. 如果由第三方負責開發,內部團隊需有一位聯邦訂約官
  7. 一位聯邦預算官在內部團隊或是作為合夥人
  8. 部門或機關的合理隱私、公民自由以及/或法律顧問是團隊的合夥人
PLAY 8

選擇現代的技術堆棧

我們所作的技術決策必須讓開發團隊的工作更有效率,並且讓服務能輕易聚焦並符合成本效益。我們選擇的託管架構、資料庫、軟體架構、程式語言以及其他技術堆棧,需設法避免鎖在同一提供者,並符合成功現代消費者與企業級軟體公司會做出的選擇。尤其,數位服務團隊應考慮使用開放源碼、基於雲端、以及大宗商品解決方案的技術堆棧,因為這些解決方案不但有廣泛應用,也有來自大多數成功的私人企業用戶與企業軟體技術公司的採用與支援。

檢查表

  1. 選擇私人公司常用的軟體框架來創造類似服務
  2. 為了保持實際,確保軟體可以部署在多樣的大宗硬體類型上
  3. 確保每個計畫都有易懂的本地開發環境安裝說明,以及計畫中能快速新增或移除團隊成員
  4. 考慮在堆棧的所有層面都使用開源軟體方案。

關鍵問題

PLAY 9

佈署在彈性的托管環境

我們的服務必須佈署在彈性的架構下,讓資源可以即時提供,以因應使用者需求的變化。當數位服務托管主機位於"雲端"資料中心,但事實上我們得自己管理並維護硬體時,這便顯得寸步難行。這種過時的作法不但浪費時間,削弱災害回復計畫,也會需要花費更高的成本。

檢查表

  1. 資源是根據需求來提供
  2. 基於即時使用者需求調整資源規模
  3. 資源藉由API提供
  4. 各區域都有這項資源
  5. 用多少、付多少
  6. 固態資源以內容傳遞網路提供
  7. 應用托管在以商用硬體上

關鍵問題

PLAY 10

自動化測試和佈署

今日,開發者使用自動化程序,在幾分鐘內認證數以千計的情境,然後一天內多次將更新後的程式碼佈署在產出環境中。以自動性能測試,能夠模擬突然增加的流量來確認系統性能的瓶頸。當手動測試和品質管控依舊是必要時,自動化測試對不經意的回歸測試提供穩定且可靠的防護,也可以讓開發者有信心的對服務釋出多次更新。

檢查表

  1. 創立自動化測試來確認所有面向使用者的功能
  2. 創立單元與整合測試來確認模組與其元件
  3. 讓執行自動測試成為整個建構過程的一部分
  4. 以佈署程序來自動化佈署、連續交付服務,或者使用其他類似的技巧
  5. 規律地實施載入與性能測試,包括正式對外上線前。

關鍵問題

PLAY 11

以可重複使用的程序來管理安全與隱私

我們的數位服務的一大關鍵,是必須保護敏感資料並維持系統安全。這通常會透過一連串的審查和改進來達成,而這些必須建構在服務開發與維護中。在設計一項新服務或特徵時,組長需要讓合適的隱私、安全或法律官員參與,討論這會收集哪些資訊、如何保證安全,以及資訊將會如何使用及分享。保持隱私專家的參與,能確保個人資料能適當的管理。除此之外,建構安全服務的一項關鍵步驟是徹底的測試並認證每一層技術堆棧中的元件裡,有哪些安全漏洞,以及重複使用這些已認證後的元件在多項其他服務中。

以下檢查表只是起頭,但各組應和組內的隱私專家與安全工程師密切合作,來滿足特定服務的需求。

檢查表

  1. 聯繫該部門或單位合適的隱私或法律官員,來決定是否需要紀錄系統通報(譯註:System of Records Notice,指單位取用個人姓名時,需在聯邦公報公開告知,詳細規範內容見美國隱私法 Privacy Act of 1974)、隱私影響評估或是其他審查。
  2. 諮詢紀錄官員,來決定會收集哪些資料、將如何使用或分享、如何存放並保持安全,以及將會保存多久。
  3. 諮詢隱私專家,來決定是否要告知、如何告知使用者個人資料會被收集並使用,包括是否需要隱私權政策、會出現在哪個地方,以及使用者在安全漏洞事件中將會如何被告知。
  4. 考慮是否需讓使用者有權從服務中取得、刪除或移除他們的資訊。
  5. 以聯邦風險與授權管理程序 FedRAMP(Federal Risk and Authorization Management Program)預先認證此計劃將使用的託管架構。
  6. 使用佈署程序來確保產品環境組態維持一致,而且在掌控之中。

關鍵問題

PLAY 12

運用資料決策

在數位計畫的所有階段,都應以衡量服務是否確實為使用者所用。這包括即時量測系統表現,與使用者如何與系統互動。團隊與部門領導人應謹慎關注這些指標,及早發現問題,並辨識哪些改良需列為優先。除了監控工具以外,也應設有回饋機制,讓人們可以直接回報問題。

檢查表

  1. 即時監控系統層次的資源使用
  2. 即時監控系統表現,量測反應時間、延遲、傳輸量與錯誤率
  3. 確保監控時能一併量測位於中位數、第95與98百分位的表現
  4. 建立以此監控為基礎的自動警告機制
  5. 即時追蹤同時線上使用者,並監控整體使用者行為,來確認系統如何滿足用戶需求
  6. 對內公布指標
  7. 對外公布指標
  8. 在產品生產時使用支持多變數檢測的實驗工具

關鍵問題

PLAY 13

預設就是開放

當我們對公眾開放發布資料時,就能透過合作一起改善政府運作。藉由建立服務來促進開放與發布開放資料,簡化公眾取得政府服務與資訊的過程,讓公眾更容易提供解決方案與貢獻,也能讓創業者、非營利組織、其他單位和公眾重複利用資料。

檢查表

  1. 提供使用者回報臭蟲和問題的機制,並且對這些報告做出回應
  2. 提供資料給公眾使用時,讓資料可以整組下載及以應用程式介面(API)取得
  3. 確保服務提供的資料明確屬於公眾領域,藉由世界性公眾領域貢獻宣告,像是CC0(Creative Common Zero)來放棄其權利。
  4. 將資料編目在該單位的組織資料存貨清單上,並將每一個公眾資料集加進組織的公眾資料列表中
  5. 確保我們能保有對所有第三方開發的資料,都同樣能讓公眾以無償方式釋出與重複使用的權利
  6. 確保我們在合約中能保有對所有第三方開發的客製軟體,都同樣能發布與重複使用的權利
  7. 在合適情況下,線上發布計畫的原始碼或元件
  8. 在合適情況下,公開分享開發過程與近況

關鍵問題