給美國政府做外包是怎樣一種體驗
英文原文：The Secret Startup That Saved the Worst Website in America
Loren Yu 從他朋友 Kalvin Wang 處收到一份緊急求助郵件， 于是他在周末前往洛杉磯。
「如果你不拒絕， 那就讓我們越快討論這件事越好，比如明天。」 Wang 在信里寫道。
當時， Yu 在一個創建于紐約的名為 SkillShare 的教育機構工作， Yu 是 SkillShare 兩個技術人員中的一個。Wang 的提議讓他毫不猶豫地選擇了離開這家年輕的公司。一周以后， 他坐上了前去巴爾的摩的火車。
Yu 決定加入 Wang 所在的由開發人員和設計師構成的小團隊， 他們嘗試拯救 Healthcare.gov。
另一邊， 網站已經糟糕到幾乎無法支持可支付醫療法案。奧巴馬政府在「啟動世界上最大的項目，但沒人來啟動或者經營它」，奧巴馬在 2008 年大選的健康顧問大衛卡特勒在 2013 年這樣告訴華盛頓郵報。 很難想象一個說得最動聽的人能做得最好， 這是兩種不同的技能。
這個網站怎么惡評都不為過。登錄系統只有 91% 的時間是正常運行的，然而每個保險申請人都需要通過它用賬號與密碼登錄網站。假設谷歌搜索引擎每天隨機罷工 2 小時，都遠比這個奧巴馬政府引入的網站可靠。在 Healthcare.gov 運營的第一天，只有六個人成功地注冊了健康保險。
Healthcare.gov 在上線時遭到的巨大失敗造成了 Tech Surge 的誕生，這個從雜亂無章的承包商和管理無序的官僚手里拯救這個網站的硅谷開發人員團隊。那個團隊造成了U.S. Digital Service 和18F 這兩個政府代理機構開始為聯邦技術的狀態提升干活， 后者相比前者受影響較小。
我們還沒提到這個叫 Marketplace Lite 團隊的故事。
Loren Yu 在作為 MPL 總部的家里為 Healthcare.gov 工作。（Robinson Meyer / 美國大西洋月刊）
這里還有一個長到可以不看的故事：Marketplace Lite，或者簡稱為「MPL」，投入了數個月去完全重寫 Healthcare.gov 的功能，在政府內部啟動工作，用1/50 的成本替換承包商的程序。值得 MPL 團隊慶祝的是，經過近一年的準備， 第二次網站推出比第一次健壯得多。
在 16 個月時間內，MPL 團隊有三個卓越的技術成就。首先，他們像破解小組一樣懂得網站的構造， 解決一些小問題。其次， 他們構建了一個叫 App2 的保險應用，新用戶注冊所需時間少于老程序的一半。最后，他們重新設計了一個功能完善的登錄系統，替換了原來崩潰的那個， 而且廉價很多。
大部分工作是他們在馬里蘭一個不起眼的老房子里面一起完成的。
他們的工作始于大量雜亂無章的代碼，通過漏洞修復，最終為政府完成了嚴謹， 有效的基礎架構。但他們完成的理念更重要：教政府官僚考慮 2015 年如何構建網站。
在 Yu 加入 MPL 之前，28 歲，他問生活和工作的平衡將是怎樣的。「這里沒有生活， 只有工作」，他被這樣告知，「基本工作是一天 10 小時， 一周七天。」
情況就是這樣的：在與 Kalvin Wang 討論工作后幾天， Yu 離開了紐約的 SkillShare， 踏上了去巴爾的摩的火車。 Wang 在火車站接了他， 快速地吃了披薩， 就把他安排在了附近的雙樹酒店。 當天晚上，Yu 開始安裝軟件。
那是一段無休無止的寫代碼的日子。小組成員在地板上， 桌子上和酒店小小的休息室里工作。（他們住在雙樹酒店是因為他們無處可去，他們沒有真正的辦公室，因為 Healthcare.gov 的中心是在馬里蘭一座不起眼的建筑里。） 當時美國政府給 MPL 小組設立了艱巨的目標：替換掉網站中用戶用來對比健康保險計劃的那一部分。
在他進入小組的頭三天， Yu 說：「我感覺像是過去了數周」。
雖然這個小組被稱為 Markertplace Lite， 但是他們從來沒有真正建立過一個能用的精簡版市場。 這個任務如此復雜深遠。 為了避免失敗， 他們推動政府更好地理解技術。 在這段時間里， 他們試圖獲得使用亞馬遜云服務的許可， 這個技術對程序員看來很基礎， 但從未在 Healthcare.gov 上使用過。
和智能手機一起，亞馬遜運服務(AWS)是當前科技熱潮中最重要的兩個基 礎設施之一。 AWS 是一個坐落在維吉尼亞州和華盛頓州的超級計算機數據中心， 提供存儲和計算能力出租。AWS 提供了廉價的存儲空間，處理域名路由，以及更加輕松地管理大型數據庫。AWS 和同類云服務是科技公司可以快速擴展的原因。對于某類開發者來說， AWS 和同類服務的使用是理所當然的。
但是 Healthcare.gov 小組不能使用這些服務。 根據醫療保險和醫療補助服務中心（簡稱 CMS)的規定， AWS 需要通過特殊的保密審查后， 才能成為 Healthcare.gov 網站建設的一部分。
你能看到周圍的人都在沸騰
雖然項目在 2014 年初得到了批準，但有好幾個月的時間里，團隊的能力都被束縛著，導致無法做任何工作。「1 月的時候， 他們覺得項目能在 3 月啟動。 到了 3 月， 他們覺得能在 5 月啟動， 到了 5 月， 他們覺得能在 7 月啟動。」 MPL 前成員 Rohan Bhobe 說。
在開始的近 6 個月，美國公共與衛生服務部不允許 MPL 使用 AWS。
在等待的時間里，他們沒有光坐著。 他們持續地工作，投入了越來越多的時間。「你可以看到周圍的人都在沸騰。」Yu 說。
在最初的幾個月里， 他們臨時和 Tech Surge 一起工作。他們覺得把用戶瀏覽器端功能復雜的靜態網站搭建在 Akami 云服務優于部署在外部服務器上， 這個云服務已經得到了政府的許可。小組成功創建了用戶注冊頁面， 并替換掉了原來那個充滿漏洞的頁面。
到了 2014 年 3 月 31 日， Tech Surge 的工作結束， 合同到期， MPL 要決定是否單獨留在項目里。
雖然是臨時參與， MPL 還是成功地完成了一些實質性的修復內容，不管聯邦政府有沒有提供他們要求的支持，這使他們有足夠的動力讓一些成員留下來。 經過數周的休假， 成員們重新回到了這個從 Tech Surge 中脫離出來的完全獨立的團隊。許多人辭去了以前的工作，離開曾經除了請假從不缺席的公司。至少有一人來自谷歌， Yu 來自 SkillShare，小組又雇傭了一些新的成員。包括從一個叫 Experience Project 的社交網站中過來的 Bhobe。
這同樣十分有幫助， 在 2014 年 4 月重新召集之后， 團隊馬上受到了款待：他們隨著 Tech Surge 的其他成員參加了白宮會議， 得到了總統親自祝賀和感謝。這讓他們得到了前所未有的鼓舞。隨著 Tech Surge 的退出，小組成員從雙樹旅館轉移到了 CMS 辦公室，但他們還是沒有自己的辦公室。當其他職員去開會的時候，他們暫時借用下辦公室。或者蜷縮在椅子和文件柜上工作。 當主人回來時，他們就出去尋找別的空閑位置。
政府和小型開發團隊的工作開始漸入佳境。2014 年中， MPL 小組用一個叫 Hipchat 的，類似于 Slack 的聊天室軟件與聯邦政府關鍵人員，包括測試小組，建立了聯系。
用即時通訊終端代替 Yu 所說的「帶著所有這些附件的，像鏈條一樣串起來的臃腫郵件」給工作帶來了很大的改善。它也能讓 CMS 辦公室里像 Healthcare.gov 測試小組這樣的小團隊迅速發現問題并向 MPL 小組反映。
政府曾經在使用群組通訊軟件上失敗過， 但是 MPL 獲得了很大的成功。為什么？因為他們從小規模做起， 從下而上。 最初他們只在內部使用，然后擴展到政府里面有對它有興趣的部門，最后在蔓延到 CMS 里的絕大部分。這是一個有規律地發展過程，這些例子證實了為什么 Slack 強烈推薦公司使用他們的產品：從小組開始，慢慢擴展。
「CMS 可能會相信我們， 并且強制所有人使用 Hipchat，但沒人會看到這樣做的價值，他們只是把它作為另一項規則來執行。」Bhobe 說。
這表明 MPL 團隊善于利用制度的力量。 在采訪中，很多人重復著一樣的想法：以身作則， 從技術角度思考， 使人們更愿意嘗試新的方法，而不是簡單地說：「嘿， 我們都應該這樣做。」
團隊位于馬里蘭州埃里克特城的總部和家。（Robinson Meyer / 美國大西洋月刊）
隨著夏季到來，MPL 團隊開始尋找穩定的辦公室。他們在馬里蘭的郊區找到了一座看似被遺忘的房子。房子坐落在山頂一個村莊的死胡同里，緊挨著三座其他房子。
房子建于 2000 年左右的一個繁榮時期，乙烯基墻面， 硬木地板， 進口花崗巖工作臺面。街上有一座建于 1978 年的木制的穹頂建筑，除此之外， 還有一根高壓電線，一座通訊基站， 以及一些馬里蘭州愛克里特城的住宅小區。
他們在六月搬進去了。房子沒有好好裝修過。比如說沒有百葉窗，有衣柜和櫥柜，還有不能折疊的椅子。 折疊式白色塑料飯就是教堂房間里的款式。臥室通常只有一到二張半成品床， 衣柜是無門的。主要工作地點在客廳，面對前門，吊燈下面的兩排桌子上， 放置了筆記本和大屏幕，纏繞著各色線纜， 以及一些筆記。
將近一年的時間里， 這座房子提供了 MPL 團隊的起居和工作場所。（一定程度上是經濟原因：與去馬里蘭郊區工作相比，在這個大房子里可以省下 6 到 10 間旅館房間。） 但這座房子一樣提供了生活和工作基礎。最多的時候， 有 10 個人白天在這里工作， 有 6 個人把這里當作了家。
雖然 MPL 團隊像內部創業一樣運行， 但是他們的創業基于龐大的政府組織。這意味著他們要面對政府代碼團隊的壓力，雖然他們不受直接管理。根據 Bhobe 所說，「所有上層人員都在遙控管理這些開發者。」
政府開發軟件的設計策略類似于瀑布： 一個中心日歷，從頭到尾都是甘特圖表，上面有每個任務的結束日期。政府的軟件開發非常官僚主義，項目經理一級管理另一級，于是整件事搞得一團糟。
如果這些都沒完成， 我們如何從零開始?
團隊用一種「敏捷」的工作方式代替傳統方式。這種方式偏向于使用小型的交叉學科的團隊，內部溝通密切，持續高效地對產品（通常是軟件）做出改進。
政府渴望投入這項敏捷方式， 但他們并不是很理解這種方式。最初團隊試圖與政府一起實踐， 結果政府代表寫了一份 3 個月的周期計劃，包含 5 份認真的沖刺開發計劃。
「我喜歡 ，但這怎能做到敏捷呢？ 這是一份三個月的計劃，更像是三個月的每日計劃。如果你在第三周學到了一些可以改變剩余計劃的技術， 會怎樣呢？」 Yu 記得這樣問道。「他們喜歡這樣，這是剩下的計劃， 所以無法改變。」
在面對截止日期的掙扎中， 壓力越來越明顯。 MPL 團隊沒有選擇一次完全啟動 App2，他們一步一步來。 從0% 的用戶數開始，完成1%，10%，20%，直到 100% 的用戶。他們只是按照進度來，更多是他們的估計。 他們可以選擇被痛苦包圍，或者僅僅上線一個未完成品： 先上線， 然后慢慢地去改進它。
在通往0% 的目標上，MPL 團隊開始改變參數。開發人員意識到他們可以通過舍棄一個計劃中的功能來換取另一個功能的完全修復，于是他們告知政府高層他們的計劃。
「我們認為這不是一件大事」， Yu 告訴我。 但是政府回復道：「如果這些都沒完成，我們如何完成0% 的目標?」
「這些高層組織， 特別是在這些大型組織中， 他們什么都不干， 但是管理著進度，如果進度開始下滑， 他們就敲響最高的警鐘。」 Bhobe 說。
一定程度上這是一個溝通失敗：小組沒有完全理解政府對發布日的預期設想。但這也顯示了政府有多不理解敏捷，即使它懂得技術的價值（衛生和人類服務部的官員一再拒絕置評。）
這不是政府首次在 Healthcare.gov 的開發上嘗試敏捷技術。一些網站的原始合同要求承包商使用敏捷技術來更快地開發軟件。然而正是這些合同的錯誤引導， 造成了大量的成本超支。審計局聲稱發生過 CMS 在監管上失敗的事情。事實上很難知道怎樣對敏捷技術進行監管， 因為這些合同是成本加固定附加費用的。MPL 團隊的經驗表明， 即使團隊在敏捷上經驗豐富， 很多政府雇員也很難適應他們的流程。
團隊為健康保險創建了一個新的應用，取代在原應用上的繼續開發。雖然最初只是為呼叫中心設計的，但是這個應用的廣泛使用程度可以讓 CMS 為每個人生成一份詳細的用藥史。大約 65% 的新用戶會使用這個「App 2.0」。
團隊在 2014 年秋天完成了 App 2.0。 在 2014 年 11 月 15 日開放注冊，普通的美國人再次注冊參加保險。一開始迅速修復了幾個小問題后，整個流程已經與一年前那三個月完全不同了。 人們登錄系統， 輸入信息， 購買保險，網站開始運作。
App2.0 工作地非常好。 Bhobe 表示用戶完成整個流程只需要 9 分鐘，而前一個版本則需要 20 分鐘。App2.0 是響應式的，意味著它能工作在任何形式的屏幕上， 不論桌面還是移動；從開始到結束，程序的頁面精簡了很多。 前一個版本整個流程需要經過 76 個頁面，app2.0 最多使用 16 頁。 由于它的簡潔， 85% 的用戶完成了它，老版本只有 55% 的用戶完成。
Bhobe 指出在某種程度上靠的是良好的軟件設計策略。MPL 團隊的工作是明確政府對軟件的需求。然后設計滿足他們的解決方案。
「需求是這么一回事， 你不能把解決方案和需求混淆，你可以這樣說，這是一個我們需要解決的需求。你需要使用團隊的創造力和能量去找出最佳解決途徑。」他告訴我。
團隊還在繼續工作， 他們的新目標之一是在 11 月完成一個新的登錄系統，用來替代原來有問題的。
讓最初的登錄系統繼續死撐一陣子是值得的。他們用一個新的用戶信息數據庫代替老的。老的用戶信息數據庫系統完全照搬聯邦政府雇員信息。這一點都不會提升穩定性：它占用了 Healthcare.gov 的一半傳輸損耗。「這會有大量的傳輸損耗」， Yu 說。
團隊在馬里蘭州的房子的客廳， 現在是辦公室。（Robinson Meyer / 美國大西洋月刊）
這個日漸膨脹的數據庫馬上不堪重負。災難性故障變成了日常事件。有時候只是幾個組件的無通知崩潰，引發一個叫作「lost souls」的臭名昭著的錯誤，導致有些用戶成功創建賬戶卻從來收不到后續步驟的確認郵件。它粗暴地要求每個家庭成員使用不同的生日來建立索引，這意味著 雙胞胎不能同時擁有賬戶。
這個最終的開發傳奇，雖然是個最難做的產品，但在某些方面是最簡單的。政府和 MPL 更好地一起工作， 互相更清楚彼此的期待。MPL 不需要任何敏捷技術的提議， 只需要看政府畫出的甘特圖就可以了。
MPL 在 2015 年 2 月上線了非常出色的新版登錄系統。價格和速度上均優于老系統。老系統需要2-10 秒才能做出響應， 新的系統只需要平均 30 毫秒。老系統花了2。5 億美元創建， 每年需要 7000 萬美元運營費用。新的系統只花了 400 萬美元， 每年維護費低于 100 萬美元。
MPL 現在已經解散了， 但是它并沒有永久消失。在 5 月中旬，他們成立了一個叫 Nava 的公益公司。Bhobe 和 Yu 以及其他人都離開家， 搬到了華盛頓。
房子怎么樣了？ 它已經空了： 今年 4 月，剩下的 5 個居民把宜家燈籠和藍色絲絨沙發搬到了華盛頓， 或者搬回了舊金山。
MPL 團隊不是理想的勞動力： 他們曾經是轉承包的， 可能現在也是。他們沒有工會保護， 無法享受到公務員一樣的福利。這些程序員雇員們可以很迅速在整個國家范圍內搬遷。他們反映了他們所工作的巨大產業：年輕人居多，男人居多，高學歷。這種方 式不是必須的。這種不穩定的雇傭關系（有利可圖，居無定所）往往是這種毫無計劃性的編程生涯的自然結果。
相反，如果可以從 MPL 團隊的成功中為未來確認一些指導原則，它是這樣的：技術工作者（包括工程師和設計師）必須從一開始就堅持一個流程：必須從需求中得到詳細的，獨立的細節描述。另外，構建軟件的時候，小團隊往往比大團隊表現得更好。
談到 MPL 小組成員， 讓我感受最深的是， 如此多的問題只需要忠實的勞動力腳踏實地地工作就可以修復。審計局指責第一次網站的失敗一 定程度上歸結于政府的需求更改以及糟糕的風險管理，特別是敏捷過程。但是 MPL 小組的經驗給了承包商提示， 政府領導只是在模仿行業用語， 而不是實實在在的在使用敏捷方法。 小組成員發現政府其實是反對敏捷過程的， 因為他們問道：「假如有漏洞會怎樣?」 Yu 說道。
漏洞總是存在的，畢竟網站不是柜子。網站無法被拆成一片片地做出來，招聘再多的工人也無法更快地完成工作。最重要的是，政府不能命令說他們要什么，然后就等著一個完美的成品出現，否則政府會收到一個能滿足所有要求，然而并不能工作的軟件。
政府內部努力掌握技術的一個原因， 很顯然是因為18F 和 U.S. Digital Service 與 Nava 一樣重要。
Nava 希望有更大的發展。Bhobe 說公司打算實現一個更大的目標，從政府 IT 服務轉移到應用程序編程接口(又稱為 API)，可以提供給政府部門或者私人公司使用。換句話說，會有一系列不同的網站接入同一個數據庫，進而形成競爭的市場格局，破除 Healthcare.gov 在聯邦保險市場上一家獨大的局面。
Bhobe 把想象中的完成品與聯邦高速公路比較：法律規定了道路的細節和方向， 但最終私營企業在周圍做他們的生意。
這是一個荒謬的，遙遠的目標嗎？ 也許是的，但是聯邦政府已經在建設關鍵信息基礎設施，只是在紙張上按照固定格式填寫一式三份。 現在，在 Nava 和其他公司的幫助下， 他們可能會考慮如何用代碼來做。