Предыстория

Уже несколько лет администрация Обамы проводит реформу здравоохранения в Соединенных Штатах Америки. Еще в марте 2010 года вышел закон о здравоохранении, согласно которому все граждане США должны были получить возможность к январю 2014 года иметь доступную медицинскую страховку.

Для того, чтобы реализовать это на практике, Министерство здравоохранения и социальных служб США наняло подрядчиков для создания и запуска портала Healthcare.gov, аналога онлайн-биржи для поиска, выбора и приобретения услуг медицинской страховки.

В принципе, идея была практичная. Аккредитованные страховые компании размещают на портале конкурентные предложения услуг медицинской страховки. Посетители сравнивают предложения между собой, выбирают наиболее подходящие для них. Для упрощения выбора можно заполнить анкету, и портал показывает только те предложения, которые подходят пользователю.

Но как мы знаем, теория хороша до тех пор, пока не пройдет испытания практикой. А с этим оказалось все не так радужно.

Провальное открытие портала

Контракт на создание портала получила CGI Federal, стоимость проекта оценивалась в 93,7 млн. долларов по первоначальным прогнозам. Однако за 3 года в процессе реализации проекта общие затраты достигли по различным оценкам от 300 до 400 млн. долларов. И даже при таком бюджете запуск портала 1 октября 2013 года показал, что сайт содержит существенные функциональные недоработки.

Согласно прогнозу Бюджетного Офиса Конгресса, в течении первого года после запуска сайта его услугами должны были воспользоваться около 7 миллионов жителей. Но разработчики на это явно не обратили внимание. Технический директор правительства США Тодд Парк сообщил, что сайт был рассчитан на одновременное подключение 50-60 тыс. пользователей, а уже в первые дни к сайту обращалось до 250 тыс. человек.

Неудивительно, что сразу же после открытия начались проблемы. Часть пользователей просто не могли зарегистрировать аккаунт. Те же, кто сумел это сделать и пытался пользоваться сайтом, обнаруживали то зависания страниц, то бесконечный цикл работы приложения, то даже неверные расчеты(!) страховых субсидий.

Мгновенно последовал шквал критики портала, реформы, президента Обамы и Демократической партии. Президенту пришлось лично выступить с извинениями за неработоспособность портала, и сообщил, что ведутся восстановительные работы.

Однако, буквально через неделю после выступления произошел очередной крупный инцидент с порталом, когда компания Terremark, хостер портала, не обратила внимания на повышение нагрузки от наплыва пользователей, и на некоторое время портал стал недоступен.

Ситуация усугубляется тем, что согласно закону, принятому в 2010 году, жители должны получить обязательную медицинскую страховку до марта 2014 года, после чего все, кто ее еще не имеет, будут штрафоваться на 1% от декларируемых доходов. Можете себе представить, какой критике подвергается президент, и как падает имидж Демократической партии. Поэтому в январе 2014 года администрация Обамы обратилась к крупнейшей в мире консалтинговой фирме Accenture, заключив годичный контракт на исправление ситуации с Healthcare.gov.

Основные ошибки и уроки

Несомненно, этот проект очень показателен с точки зрения уроков, которые можно извлечь. Причем эти уроки будут интересны всем уровням и направлениям – руководству, менеджерам проектов, разработчикам и поддержке.

1. Методология разработки. В июне 2013 года была запущена первая версия сайта Healthcare.gov, которая должна была прорекламировать официальный запуск в октябре и показать людям какой функционал сайта будет доступен. Июньская версия сайта была спроектирована, реализована и запущена за 90 дней, что является беспрецедентно быстрым для государственных сайтов. Такая оперативность была достигнута за счет того, что были привлечены эксперты из частного сектора.
   Сайт был разработан компанией Development Seed, маленькой фирмой, практически вживую с использованием итераций, а проектные менеджеры и разработчики использовали Agile методы разработки и новейшие open-source технологии. И июньский сайт оказался крайне успешным.
   Версия же портала, которая была запущена в октябре, разрабатывалась на протяжении нескольких лет с использованием каскадной модели (Waterfall mode). И отсутствие гибкости было одной из причин неудачного открытия портала. Согласно расследованию, за недели перед стартом исправлялись сотни ошибок, тестеры работали днем и ночью, а сайт продолжал падать на простых задачах. И все мы знаем, что исправление сотни ошибок обычно порождает новые ошибки, которые тоже надо находить и фиксить. 
2. Тестирование. Как показало расследование, тестирование в рамках проекта, конечно же, было, но тестировались отдельные элементы, а не работа приложения в целом. Лишь за 5(!) дней до запуска приложение было протестировано полностью. Разработчики и тестировщики жаловались друг другу на то, что сайт не готов и не будет готов к октябрю, но они не были услышаны руководством проекта.
   Нагрузочное тестирование, по словам подрядчиков, проводилось, однако согласно CBS News незадолго до запуска сайт падал при нагрузке в 200-300 пользователей. Да и обращение даже нескольких тысяч одинаковых ботов к веб-сайту вовсе не покажет полноценной нагрузки без реалистичных обращений к базам данным, одновременных транзакций разного типа, которые могут устроить блокировки, и т.п.
3. Красиво не означает функционально. Сайт был очень хорошо разработан с точки зрения графического дизайна и использовал Java скрипты и AJAX для красивых переходов и выполнения запросов в фоновом режиме. Однако он был очень чувствительным к ошибкам бэкэнда, что противоречит озвученной выше концепции – фоновый режим должен быть максимально толерантен к ошибкам на стороне сервера.
   Ничто так не раздражает пользователей, как необходимость начинать с начала некую последовательность действий только потому, что где-то посередине что-то не сработало, а введенные данные и состояние не запомнилось.
4. Проверка вводимых данных. Вы не поверите, но даже здесь были проблемы! Одной из самых первых проблем был тот простой факт, что в имени пользователя обязательно должна была быть минимум одна цифра. Вот только нигде об этом не было сказано – ни в инструкциях, ни в сообщениях об ошибке, которые выводятся пользователю.
   Очень важно синхронизировать между собой проверку данных на стороне клиента, сервера, информацию в инструкциях и сообщениях об ошибках, иначе можно легко получить массу неудовлетворенных, а часто – просто рассерженных пользователей.
5. Восприятие конечного пользователя. Как показывает практика, это вовсе не причуды или роскошь. Это очень практичный подход к делу, особенно когда сайт имеет множество переходов, всплывающих окон и прочих вещей. Пользователь всегда должен понимать, где он находится и что ему делать дальше. На Healthcare.gov было несколько ситуаций, когда пользователи попадали практически в ловушку, из которой не было явного выхода, и они не понимали, что им делать дальше. И тем более не могли это объяснить представителям технической поддержки сайта, даже если бы дозвонились.
   Если бы этому вопросу больше внимания уделили на этапе разработки дизайна, а также внедрили мониторинг с возможностями наблюдения за восприятием конечного пользователя, многие проблемы вскрылись бы еще до запуска в эксплуатации.
6. Колл-центр. Как оказалось, были плохо протестирован не только сам веб-портал, но и колл-центр. Пользователи, которые не могли зарегистрироваться или попадали в тысячу и одну ловушку сайта, первым делом звонили. Тем более, что было сказано, что приобрести страховку можно и по телефону.
   И, конечно же, протестировать колл-центр на работу с несколькими тысячами клиентов одновременно никто не догадался. Плохое качество и обрывы связи не позволяли колл-центру полноценно функционировать и не способствовали снижению нагрузки на портал.

Выводы.

А нужно ли еще что-либо говорить? Это очень яркий пример того, как не стоит делать проекты. Не повторяйте этих ошибок, даже если у Вас не настолько масштабные проекты. Используйте гибкие методологии разработки, полноценное нагрузочное тестирование и внедряйте мониторинг с обязательным фокусом на восприятие пользователей. В конечном итоге именно они решают, устраивает их приложение или нет.