Успешный ИТ-проект — это там,где ожидания управляют работой с первого дня

Бизнес живет в режиме непрерывных перемен: регуляторика обновляется, процессы перестраиваются, цифровые продукты «переучиваются» прямо на лету. На этом фоне главный риск ИТ-проектов — вовсе не технологии, а несогласованные ожидания. О том, как превратить меняющиеся требования в управляемую рутину и почему начинать проект нужно «с конца», рассказывает Алексей Пилипчук, технический директор «Софтлайн Решения» ГК Softline.

Что для вас «успешный ИТ-проект»?

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

Частая картина: бюджет выделен, систему выбрали, проект стартовал — и начинается «хотим, чтобы все работало хорошо и быстро». Как вы с этим работаете?

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

Почему требования меняются уже по ходу реализации?

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

Как устроен ваш ритм работы по вехам?

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

Что помогает держать ожидания и ответственность на одном уровне у бизнеса и ИТ?

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

Какой эффект получает бизнес от такого подхода?

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

Что посоветуете тем, кто только готовится стартовать?

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