Возрождение из пепла

О том, как ИТ-службе компании, занимающейся медицинским страхованием в Колорадо, удалось преодолеть последствия серьезных ошибок в управлении важным проектом.

Мы теперь точно знаем, какая именно методика способна свести с ума. Роб Норрис, директор информационной службы страховой компании Pinnacol Assurance

«Я сидел на совещании и понимал, что мы не можем выполнить этот проект. Мы выбились из сил, но все катится в тартарары. Что же делается неправильно?» Ответ предательски прост: все. Потратив год на проект создания важнейшей для себя системы оплаты медицинских услуг, который предполагалось реализовать за шесть месяцев, специально сформированная с этой целью группа специалистов из Pinnacol Assurance пришла к выводу, что необходимо начать все сначала. Проект стал похож на топкое болото. Результатов никаких. Руководство в бешенстве. Сотрудники ИТ-службы впали в депрессию, а Норрис может вот-вот потерять работу.

А все началось год назад, когда Норрис, новый директор по информационным технологиям в компании, занимающейся медицинским страхованием, пришел к заключению, что закупленная незадолго до этого система оплаты счетов за медицинские услуги на базе ПК никуда не годится. Она не успевала обрабатывать огромное количество счетов, и в то же время из-за ошибок переплачивала претендентам на страховку более чем по 5 тыс. долл. в день. Компании требовалась новая система, способная преобразовывать тысячи правил, норм, расценок и принципов оплаты в 2000 предписаний к выплате страховых премий в день. Кроме того, надо было наладить индивидуальный подход к заключению соглашений. Норрис, которому уже приходилось раньше создавать сложные системы, решил, что группа из двух десятков разработчиков вполне сможет решить такую задачу. Реализация проекта MedPay началась в начале прошлого года, и предполагалось все завершить за шесть месяцев.

Но практически сразу же они совершили ряд серьезных ошибок. «Мы пали жертвой новой технологии, — подтвердил Норрис. — Мы полагали, что Oracle Forms и PL/SQL, составлявшие основу основ нашей текущей работы, не в состоянии помочь нам в решении новой задачи».

Они решили, что Forms не смогут поддерживать необходимый точный контроль над пользовательским интерфейсом. С другой стороны, любопытно было попробовать Java. Норрис и руководитель проекта Дуэйн Хитц использовали эту технологию вместе с парой нехитрых приложений электронной коммерции, и первое впечатление оказалось хорошим. Тогда Java не обладала эффективной интеграцией с базами данных и необходимой масштабируемостью, но чтобы понять это, потребовалось определенное время.

Норрис и Хитц выбрали методику быстрой совместной разработки приложений (RAD/JAD — rapid, joint application development), которая позволяла отказаться от формальной дисциплины управления проектом. Предполагалось наладить тесное сотрудничество с конечными пользователями. «Мы обговариваем конкретные вопросы, на следующий день показываем им предварительные экраны, и после их обсуждения очень быстро это реализуем», — объяснил Норрис.

Вскоре стало очевидно, что ограничения Java не позволяют в полной мере реализовать подход RAD. Вместо того чтобы вернуться к экрану на следующий день и показать его пользователям, разработчики были вынуждены «сражаться» с Java две- три недели. К моменту, когда разработчики были готовы показать пользователям новый экран, по сути, уже никто и не помнил, о чем была предыдущая договоренность. «Это действовало всем на нервы, и каждый стремился переложить вину на другого», — заметил Хитц.

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

Тяжелое признание

В то же время бизнес компании оказался под угрозой, поскольку существующая система расчетов продолжала плодить ошибки. Погруженные в этот хаос бизнес-менеджеры теряли терпение в ожидании завершения проекта, который на самом деле уже вышел из-под контроля. Ставшая очевидной ошибочность подхода RAD вызвала серьезные разногласия среди разработчиков. «Мы были близки к катастрофе, — вспоминает Хитц. — Было очень трудно даже просто заставить себя прийти на следующее совещание. Все казалось бессмысленным».

В ИТ-службе депрессия распространялась как смертоносный газ. Хитц, по собственному признанию, «чувствовал себя на краю бездны». Он растерял большую часть своих программистов и остался единственным, кто хоть что-то знал о Java. Поэтому помимо руководства проектом ему приходилось самому писать модули на Java. Он воплощал собой фатальное падение MedPay.

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

Но попытка взять эти взаимоотношения под контроль заняла еще шесть месяцев. «Нам все время приходилось вмешиваться, — рассказывает Кахун. — У нас пропадали файлы и счета. Проблемы только накапливались. Все это напоминало фильм ужасов».

И даже когда казалось, что хуже уже некуда, выяснялось, что самое страшное еще впереди.

В декабре прошлого года, спустя почти год после запуска проекта, Хитц просидел у компьютера практически 105 часов подряд, пытаясь заставить работать графический пользовательский интерфейс и связь между базой данных и Java-приложениями. И ничего у него не вышло.

«Это был один из самых трудных моментов в моей жизни, — вспоминает он. — Решение об отказе от Java потрясло практически всех. Я вспоминаю, как Роб сообщил нам об этом. Видели бы вы их глаза в тот момент».

Если в бизнес-подразделениях до этого все еще верили в разработчиков, то решение об отказе от Java убило последние надежды. «Представьте, что вы привыкли слышать дифирамбы в адрес Java, и внезапно мы принимаем решение о возврате к Oracle», — рассказывает Хитц.

Хуже всех в этой ситуации пришлось Норрису, которому «выпала честь» довести это решение до сведения своего шефа. «Генеральный директор требовал конкретных сроков, и в конце концов я вынужден был заявить, что о завершении проекта через несколько недель не может быть и речи, и нам придется начинать все сначала», — вспоминает Норрис.

Несмотря на провал MedPay, Норрис все-таки остался на своем посту, и спасли его два обстоятельства. Во-первых, понимание того, что неудачный проект был все-таки исключением из правил. Все остальные проекты в области ИТ — от киосков данных до интерактивных сервисных центров — были завершены в срок и не вышли за рамки бюджетов, более того, их пользователи были очень довольны.

Другим лучиком надежды стало зарождение новой стратегии. Норрис понял, что одни и те же люди ведут разработку, осуществляют аутсорсинг, а также решают постоянно возникающие побочные вопросы. Он отказался от управления аутсорсингом, и они сразу же почувствовали некоторое облегчение. И тогда его осенило: проект MedPay необходимо разбить на несколько небольших задач.

Они разделили MedPay почти на два десятка отдельных модулей, каждый из которых можно было вести как проект с применением технологии быстрой разработки. Эти модули не требовали формальных спецификаций и объемной документации, поскольку каждый из них представлял собой истинный проект RAD — небольшой и быстрый. Для каждого модуля был назначен ответственный программист, который работал непосредственно со специалистами в предметной области. Норрис выбрал из числа программистов тех, кто мог находить взаимопонимание с пользователями, мог работать независимо и не разочаровался после прошлых неудач.

Предельный срок

Решение о размере модулей было еще одним правильным шагом. Норрис ознакомился с результатами нескольких исследований, которые показали, что вне зависимости от размера или сложности проекты RAD практически никогда не требуют на реализацию более трех-четырех недель: «Я понял, что происходит, поэтому почти плакал, когда это читал. И понял, где надо искать решение».

Норрис решил, что каждый из модулей должен быть завершен за три недели. Это значит, что если возникает какая-то проблема, он может узнать об этом практически сразу и предпринять необходимые действия. Он ежедневно обсуждал с менеджерами, ответственными за реализацию каждого модуля, вопрос о сроках. «Как только возникала задержка, я понимал, с чем это связано», — заметил он.

Поскольку на реализацию модулей отводилось всего три недели, программисты получили разрешение не заниматься никакой иной работой. «Когда вы выполняете проект, растянутый на многие месяцы, вы расслабляетесь, — сказал Норрис. — Но когда вам дается всего три недели, и кто-то просит вас сделать что-то еще, вы, естественно, отказываетесь».

Каждый завершенный модуль сразу интегрировался в существующую систему и начинал использоваться, что называется, по максимуму. Объединением всех модулей — всем проектом в целом — руководит Норрис, который взял на себя эти обязанности, тем самым позволив Хитцу сосредоточиться на технической стороне проекта.

Чтобы успеть вовремя, в тот момент требовалось сочетать гибкость и строгое следование первоначальному плану. Цели всего проекта, определение каждого модуля и сроки окончания проекта были утверждены раз и навсегда. «Но внутри все должно было быть динамичным», — заметил Норрис.

К примеру, иногда слишком большой модуль приходилось разбивать на два, увеличивать число программистов или сокращать функциональность модуля. Как подчеркнул Норрис, суть была не в том, чтобы создать прекрасный план, а в том, чтобы постоянно корректировать тот, который вы реализуете. Они так и поступали: пересматривали план 13 раз, но сроки не менялись ни разу.

И группа начала работать лучше. Помимо обычных запланированных встреч, члены группы проводили 15-минутные совещания каждое утро для того, чтобы обсудить возникшие вопросы и синхронизировать свои действия. «Вы могли обратиться с любым вопросом непосредственно к тому, кого он касался, и встретившись на следующее утро, вы знали ответ, — подчеркнул Хитц. — Мы начали двигаться вперед».

Группа стала предлагать готовые модули практически сразу, но лишь в апреле забрезжил свет в конце туннеля.

В конце концов проект был завершен, и в июле система поступила в эксплуатацию. «Мы очень гордимся системой, которую создали», — заявил Норрис.

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

Оглядываясь назад, и программисты, и менеджеры сходятся в том, что методика, которую они выбрали с таким трудом, — лучший способ управления проектами подобного типа. «Наши первые ошибки в этом проекте стали для нас очень тяжелым, но бесценным уроком, — заметил Норрис. — Быстрая разработка приложений всегда сопровождается некоторым хаосом, но теперь мы достоверно знаем, какая именно методика может свести нас с ума».

Pinnacol Assurance

Горькие уроки