给美国政府做外包是怎样一种体验
英文原文：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 和其他公司的帮助下， 他们可能会考虑如何用代码来做。