ИТ-проект, на который вы возлагали большие надежды, оказался под угрозой провала. Комментарий блоггера. В оригинальном тексте мне понравилось выражение IT-Projekts ist in den Brunnen gefallen, буквально - проект упал в колодец. Конец комментария. Замаячила перспектива денежных и репутационных потерь. Может, ещё как-то можно спасти ситуацию? Ниже даются 5 практических советов по этому поводу.
ОРИГИНАЛЬНЫЙ ТЕКСТ НАХОДИТСЯЗДЕСЬ.
В последние годы все вокруг говорят об антикризисном
управлении в повседневной жизни. Уроки о том, что работает (или нет) в
глобальном масштабе, как никогда применимы к управлению ИТ-проектами. Часто
лица, столкнувшиеся с проблемой, в попытках самостоятельно решить проблему обращаются
к опыту барона Мюнхгаузена – пытаются сами себя вытащить из болота за волосы. А
ведь кризис чем-то похож на инфекцию – сначала инкубационный период, а потом
яркий фейерверк проблем.
Недостаточная культура решения проблем как питательная среда для кризисов.
Многие руководители в немецкоязычных
странах рассматривают проблемы не как возможность обучения, а часто как
собственную неудачу и не достижение целей. Ситуация становится критической,
когда эти руководители несут ответственность за проект. Ответственные за проект
хотят продемонстрировать высшему руководству, что "всё под
контролем". Симптоматично, что «Светофор проекта» показывают зеленые,
максимум желтые сигналы, вплоть до самого последнего момента. При этом иногда
на словах упоминается, что сигнал всё-таки тёмно-жёлтый. Но только не красный,
потому что за красный цвет наказывают.
На
самом деле, эта стратегия, отработанная и практикуемая годами, работает хорошо
до тех пор, пока срок сдачи или запуска программного обеспечения находится ещё
далеко в будущем, а бюджет не исчерпан. Возможности для манёвра вроде бы ещё
есть, но это иллюзия.
А
дальше начинается цепная реакция: чем хуже ситуация, тем больше проблем
пытаются замести под ковёр. Тем самым планка для объявления "красных
сигналов" становится всё выше, а сроки регулярно переносятся в надежде
выиграть достаточно времени для решения проблем. К сожалению, вскоре больше
времени уходит на оправдания и сокрытие проблем, чем на их решение.
БЛАГИМИ НАМЕРЕНИЯМИ ВЫМОЩЕНА ДОРОГА В АД.
Ситуация,
когда сроки постоянно сдвигаются, но с формальными показателями всё ОК, может
быть в корне неверно истолковано руководством: продукт вроде готов, но в
команде собрались перфекционисты, которые пока «смущаются» выходить на рынок. С
наилучшими намерениями руководство, желая, как лучше, принудительно ускоряет
запуск проекта. Комментарий блоггера. Угадайте с трёх раз, кто будет виноват,
когда получится, как всегда. Дам подсказку – уж точно не руководитель! Конец
комментария. Хотя риск и примерный масштаб катастрофы, которая
последует, предсказуемы, проектная команда не решается возразить, поскольку
первоначально небольшая "ложь во спасение" уже разрослась до огромных
размеров. В таких конфликтных ситуациях нормальной человеческой реакцией
становится выжидательная позиция. "Всё как-нибудь образуется"
превращается в мантру, а страус становится неофициальным талисманом проекта.
Ущерб может превышать затраты на проект
Для такого непрофессионализма особо
уязвимы многопользовательские ИТ-системы, поставляющиеся по схеме В2В. Эти
системы по определению очень сложны, и это часто недооценивается, что является
одной из основных причин того, что проект заходит в тупик. Следовательно, после
преждевременного запуска нерешенные проблемы скрыть от клиента нельзя. Часто
вообще становится невозможным выполнять взятые на себя обязательства. При этом
не имеет значения, является ли клиент заказчиком внутренним или внешним.
Из-за ИТ-проблем могут пойти насмарку
усилия по привлечению новых клиентов. Помимо перспектив прекращения поступления
новых клиентов, лояльные клиенты тоже делают выводы и вполне могут отвернуться
от компании. Следующая степень провала -разгневанные клиенты выражают своё
недовольство в социальных сетях, из-за чего репутационный ущерб может нанести
вред бренду компании. Последствием могут стать долгосрочные падения оборота и
прибыли.
Кто виноват и что делать?
Излишне напоминать, что правильный подход после катастрофического запуска существенно отличается от стабилизации проекта до запуска. Потому что в таких случаях не остаётся времени для выяснения, кто виноват. А для тех, кто спрашивает, что делать, хорошо зарекомендовали себя следующие шаги:
- Признайте проблему и необходимость проекта по стабилизации.
- Выразите проблему в цифрах и проработайте необходимые показатели эффективности.
- Подберите Agile-команду, ответственную за реализацию мер по стабилизации.
- Увеличьте частоту выпуска новых релизов.
- Когда добьётесь стабилизации, в спокойной обстановке выявите и устраните причины кризиса.
Хьюстон – у нас проблема! Прежде всего,
руководство должно понимать, что кризис — это больше, чем совокупность
симптомов. Важно, как можно быстрее стабилизировать неисправные системы, чтобы свести
к минимуму ущерб для клиентов. Как только руководство осознает масштаб проблем,
оно, как и следовало ожидать, часто теряет доверие к своей команде. Задействованные
специалисты также имеют свою точку зрения, отличную от мнения руководства. Необходимо
компетентное мнение со стороны, поэтому альтернативы независимой внешней
поддержке нет. Ключевой вопрос квалификация наёмного менеджера проектов, его
опыт в стабилизации критически важных ИТ-проектов. И за этим менеджером должна
стоять мощная команда экспертов по соответствующим системам, отраслям и
процессам.
Первоочередная цель анализа — как можно быстрее выяснить влияние неисправного программного обеспечения на операционную деятельность предприятия. Какие процессы не могут быть завершены и, таким образом, препятствуют движению денежных средств? В идеале на стол высшего руководства не реже раза в неделю должен ложится доклад, содержащий следующую информацию:
- Количество обращений клиентов на горячую линию, касающихся проблем с ИТ.
- Несостоявшиеся контракты и их оборот.
- Неоплаченные счета-фактуры и их сумма.
- Товары и услуги, которые не удалось продать, и их стоимость.
- Падение маржинальной прибыли с разбивкой по категориям.
Выбранные ключевые показатели эффективности должны давать максимально чёткое представление о том, что происходит с проектом. После выяснения того, что создаёт наибольшие трудности, расставляются приоритеты и более подробно рассматривается:
- Баги в коде программы.
- Какая информация повреждена в результате этих багов.
- Какое влияние это оказывает на бизнес-процессы.
- Вся эта информация должна быть доведена до руководства.
Такие команды состоят из делегатов от пользователей, ИТ-специалистов и «пришлых варягов». Их задача - выявление и исправление ошибок, к которым организация наиболее чувствительна. Идеальный вариант – когда команда подобрана исходя из специфики целевой группы. На этом этапе также рекомендуется создать специальные инструменты, которые команды смогут использовать для автоматического решения проблем с данными. Комментарий блоггера Как правило, создаются модули с запросами по базе данных, позволяющие выявить случаи некорректного ввода информации. Такие модули должны применяться регулярно, пока ещё горит зелёный свет. В противном случае рано или поздно загорится красный. Конец комментария.
Еще одним важным фактором успеха является внедрение быстрого, но надежного процесса поставки релизов программного обеспечения. Если так называемый DevOps не налажен, то надо заняться устранением этого пробела. Разработчики, которые в 4 утра в одиночку изменяют программы и данные в работающей системе, обычно создают больше проблем, чем решают.
Из-за необходимости сокращения времени циклов выпуска особого внимания требуют тестовые случаи, которые выявляют непреднамеренные взаимодействия между новым и старым кодом — так называемое регрессионное тестирование. Если компания еще не достигла высокого уровня автоматизации тестирования, необходимо быстро создать испытательные центры и укомплектовать их персоналом в ключевых местах. Они требуют строгого управления со стороны всех задействованных тестировщиков и разработчиков.
И вот долгожданный свет в конце туннеля!
Напомним ключевые условия: чёткие
показатели и руководство в курсе хода дел. При их выполнении прогресс будет
виден очень быстро. Распределяя ресурсы по приоритетам и решая важные проблемы,
можно добиться заметных улучшений в конечном итоге уже через несколько недель.
Через несколько месяцев кризис в значительной степени преодолен.
Наступает время проанализировать
фундаментальные причины проблем и разработать меры оптимизации: от навыков и
организации до процессов и гибких методов, инструментов и отчетности. Теперь
также целесообразно трезво оценить, лучше ли постепенно устранять оставшиеся
уязвимости в затронутых системах (рефакторинг) или полностью заменить системы.
И В ЗАКЛЮЧЕНИЕ БЕСПЛАТНЫЙ СОВЕТ
Объективность и опыт являются важнейшими факторами успеха в стабилизации ИТ-кризиса. По сравнению с «ценой бездействия», т.е. совокупным потерянным денежным потоком, затраты на проект стабилизации относительно невелики — в целом это хорошая инвестиция. Кстати: если вы хотите проявить инициативу, вы можете периодически проверять статус проекта с помощью «проверок выполнимости», особенно для крупных проектов с заметным зеленым светом. Таким образом, кризис можно предотвратить на ранней стадии.