HealthCare.gov Web应用的发布现在已经成为了Web开发及项目管理问题的一个臭名昭彰的例子。过错不在于网站上放了医疗保险，而是在软件开发周期中做出的技术决定。作为一名软件项目经理，当我第一次读到有关这次发布的事情时，我考虑了开发者、项目经理及其高管可以做出的所有的不同决策，这些决策能够避免它们经历过的Healthcare.gov技术问题。

本文识别了项目管理与开发团队碰到的关键问题，为了纠正问题做了哪些事，并对会发生什么和对使用该网站的人意味着什么进行预测。我还在通篇补充了给项目经理提供的相关建议。

HealthCare.gov在什么地方出了问题

奥巴马总统的HealthCare.gov网站的两个高级目标是简化大家比较医疗保险购买方式的手段以及让他们在网上购买优选的健康险种。比方说，2013年6月，HealthCare.gov项目决定对网站进行一次升级来为即将到来的10月1日做推广。6月份的目标是让人们对10月份发布时开始在网站订购健康险的预期做好准备。6月版的网站设计、开发与发布的时间窗口是90天。

很快这个项目就取得了政府IT项目较为罕见的成功，因为引入了私人公司专家的帮助。Development Seed开发的主页尤其成功，这家小公司为数百万美国人至今仍在使用的网站奠定了大部分的基础。该网站的开发是公开、迭代进行的，使用了项目经理和利用敏捷开发及先进开源技术的开发者。网站的6月版十分精炼、因为政府和私企的强力协作而被证明是成功的。

而10月版的网站在6月版发布时已经搭建好几年了，采用的是瀑布流方法论。尽管我找不出政府在6月版成功发布后选择坚持瀑布流的理由，但我在大型发布前3个月改成敏捷方法论可能会是一个太大的挑战，鉴于已经写了太多的代码了。

项目团队10月版发布面临的主要挑战包括要在发布前数星期修改成百上千个bug，测试员劳累不堪，以及在执行登录账号设置之类的简单任务时网站总是崩溃。还有对数据准确度的担忧。

我们都知道，在发布前修补上千个漏洞会对软件产生严重损害，还会引入无法在最终测试阶段被捕捉到的额外的漏洞。也就是说，除非你有知道如何在最后集成测试阶段扩展现有测试用例的、经验丰富的测试员才能办到这一点。

不幸的是，10月版的测试员里面有200-300名政府及保险公司员工，这些人在发布前仅仅测试了几天。加载测试似乎也是由这批人在办公桌的不同时段进行的。加上一个非常复杂的技术规范和架构设计，得到的必将是一个显然还没有为黄金时间准备好的网站。

建议

作为一名项目经理，我们应该让我们的开发者把自己发现的问题记录下来。此外，我们还必须记录下我们的主管接收到了这些问题的及时提醒。如果没有这些文档，我们的开发者会被指责缺乏必要的专业知识来做项目，工作马虎。我曾经跟很多开发者打过交道，还没有碰到过在合理的时间窗口内技能不足以写出可靠代码的。然而，他们需要时间去修补漏洞，对于最后时刻，范围变更后出现的问题是不应该背负责任的。要作一名好的项目经理就得用有力的文档保护你的开发者。

HealthCare.gov的开发者互相抱怨自己遇到的问题，但仍不清楚他们的担忧是否传到了政府当局对整个计划负责的人那里。CBS新闻曾报道说测试员从来都没有成功地浏览过那个网站，有一个不具名的来源还毫不含糊地指出网站“就测试情况来看……还没有准备好。”但是政府官员如医保与医补服务（CMS）中心的行政主管Marilyn Tavenner，仍公开声称在发布前并不知晓任何问题的存在。

政府现在做什么来帮助这个蹩脚的网站呢？自从去年10月份首次上线以来，已经修补了数百个漏洞，通过增加硬件带来了稳定性，网站也展现出显著的改善。而私企方面的资源，如Red Hat和Oracle等，现在也参与到协助提高可靠性、稳定性、可伸缩性方面，还带来了他们的敏捷专业知识。此外，为了凝聚支持力量和集思广益，去年12月份奥巴马总统还与其他关键的硅谷高管进行了会面。

在不远的将来我们可以期待看到的一个改进领域是，让开发流程变得更为敏捷，以适应更加精益更加迅速的发布周期。还有声音在讨论建立一个联邦政府的IT项目管理办公室（PMO），专门管理更大的技术项目。新的IT PMO将能有效地分担每一个政府组织在CMS（通过HealthCare.gov）之类的项目上充当自己总承包商的角色。奥巴马总统当局也敏锐地认识到快速招聘到熟练技术员工的难度，正在寻找如何减少当前招聘流程所需耗时的办法。

建议

如果你的组织是去中心化的，那么做IT项目时可以考虑把你的项目集中在PMO之下。PMO允许跨项目之间进行标准化并综合利用知识和资源。然而，还要看看PMO怎样才能把总成本降低，因为据PMI发起的一项调查来看，这种情况并非总是如此的。至于PMO团队的招聘经验，需确保应征者有能力跨平台和团队工作。因为项目经理是没有时间每次只做一个项目的。

通过近期的漏洞修补和硬件增强，再加上利用敏捷方法论，引入新的PMO部门，同时改善熟练IT人员的招聘实践，HealthCare.gov的前途还是光明的。

作为经验丰富的项目经理，我们知道，往往在我们意识到关键漏洞会影响到用户体验的情况下仍照样发布。经过灾难性的发布之后，我们迅速评估影响，然后对变更需求和漏洞修补进行优先排序，再以疯狂的速度继续，直到项目稳定、可支持且功能丰富。幸运的是，提到此前的软件发布，记忆被证明是短暂的。比方说，Medicare Part D2006年首次发布时也有着类似的推出问题。用户抱怨网站太慢，数据不准确，并且可能存在安全漏洞。听着耳熟？可是现如今，8年以后，Medicare Part D网站为老年人提供了一个流行的处方药计划。

随着媒体对HealthCare.gov技术问题的关注，以及其中的政治意义，高度熟练的资源被分配到了这个网站。本例中现在就有了硅谷顶级高管的加盟。在发布和维护日点击量上百万的网站方面这些人都是专家。HealthCare.gov要多久才能像Medicare Part D一样给你丰富、稳定且流行的体验？从我们现在看到的进展来看，当然不需要8年，但我们至少需要给项目经理和开发者留出18个月的时间来解决掉剩下的数百个漏洞，来增强安全，并确保数据准确。这不是一件简单的任务，到那时就当前考虑的这支团队而言，我们有一天将会忘记首次发布的事情，并会享受到HealthCare.gov带来的保险政策和医疗保健购买的好处。