Как избежать авралов и «пожаров» на ИТ-проектах. Рецепты Релэкс

Почему возникают «пожары» на проектах

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

Если проектные требования плохо задокументированы, то компания почти наверняка испытает проблемы в ходе внедрения. Трудно рассчитывать на успех и в том случае, если требования по ходу проекта меняются кардинально и слишком часто. Большой бич всех внедрений — изъяны в подборе кадров и недостаток компетенций в проектной команде. Среди частных случаев этих негативных явлений можно назвать неудачный выбор платформ и технологий, неверную оценку стоимости проекта (вдруг выясняется, что средств надо намного больше, чем планировали), плохо организованное управление командой, выделение недостаточного времени на тестирование системы и интеграционных связей, потерю ключевых специалистов по ходу проекта, завышенные ожидания по времени готовности проекта.

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

Если «пожар» произошел

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

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

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

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

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

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

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

При этом важно иметь постоянное связующее звено между приглашенной командой и бизнесом. Обычно эту роль выполняют руководители проектов и бизнес аналитики, — отмечает Роман Гаврилов, руководитель центра заказной разработки компании РЕЛЭКС. — Необходимо, чтобы команда партнёра была в состоянии провести discovery фазу, прежде чем начинать основные работы по спасению.

Тушение горящих сроков: пример из опыта РЕЛЭКС

За годы работы компании РЕЛЭКС в практике ее команд были примеры спасения проектов разной сложности. Об одном из таких проектов расскажем ниже.

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

Развитие проекта шло не по плану: по итогам промежуточного аудита готовность приложения составила всего 30%, в тестировании нарастал снежный ком багов (новые ошибки возникали быстрее, чем успевали исправить предыдущие), бэклог задач постоянно увеличивался. Руководитель проекта понял, что в команде не хватает не просто специалиста, владеющего определенными технологиями, а человека, способного выступить в роли технического лидера. Поиск подходящего профессионала на рынке занял бы несколько месяцев, а специалисты РЕЛЭКС с нужными компетенциями были заняты на других проектах. Благодаря грамотной координации и эффективным переговорам, в команду удалось привлечь нужного специалиста из числах сотрудников компании.

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

Специалисты РЕЛЭКС знают, как не допустить провала сроков по проекту и избежать результата, в корне отличающегося от ожидаемого, и уже не раз спасали своих клиентов в подобных ситуациях, — подчеркивает Роман Гаврилов.

Проектный «пожар» удалось потушить не только благодаря привлечению квалифицированного техлида, но и вследствие достижения высокого уровня мотивации команды, реализации продуктового подхода в управлении, высокой степени вовлеченности заказчика. Руководители проектов РЕЛЭКС посредством грамотных коммуникаций смогли быстро выявить проблемы и найти пути их решения. Очень важно, что удалось добиться доверия заказчика и наладить регулярную обратную связь от всех ключевых участников проекта.