5 вредных советов: как провалить ИТ-проект

Меня зовут Юрий Пересторонин, я управляющий партнер сегментов «ТНП, ритейл, строительство» группы компаний IBS. За годы практики в ИТ-консалтинге я разбирал столько загубленных проектов, что иногда казалось — некоторые команды специально добиваются провала.

Самое интересное — в этом есть доля истины. Чаще всего причиной неудач становится не случайность, а система, построенная на иллюзиях, полуправде и страхе сказать: «Мы движемся не туда». С позиции специалиста, который устранял последствия таких просчетов, я подобрал пять советов, как точно провалить ИТ-проект.

Забудьте о точных показателях, сроках и измеримых результатах — достаточно просто поручить подрядчику «улучшить юзабилити» или «повысить эффективность». Тогда у каждой стороны будет свой взгляд на цель проекта, а в конце можно будет сказать: «Мы не об этом договаривались!»

Пример из жизни

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

Не тратьте время на оценки и расчеты — скажите, что работа над проектом займет пару недель, даже если не знаете, в чем именно она заключается. Если команда не успеет, можно будет просто обвинить ее в медлительности.

Пример из жизни

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

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

Пример из жизни

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

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

Примеры из жизни

Руководитель одной команды разработчиков так боялся потерять контроль, что требовал отчеты каждый час. Сотрудникам приходилось тратить на них 60% времени, и в результате проект остановился. Встречались и ситуации, когда команда сообщала о критически важных проблемах, а руководители обещали разобраться с ними потом, пока не становилось слишком поздно.

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

Примеры из жизни

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

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