Сложные ИТ-проекты без хаоса: как управлять рисками и соблюсти сроки

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

О том, как выстроить единый механизм управления, где все контуры синхронизированы, а риски под контролем, говорит генеральный директор «Запуск Групп» Алексей Равинский.

Почему срываются проекты

За последние месяцы до 90% ИТ-проектов не дошло до стадии реализации: их либо закрывали из-за экономической нецелесообразности, либо существенно переделывали. И только оставшиеся 10% прошло полный цикл внедрения.

Сложные IT-проекты чаще всего срываются из-за несогласованности между ключевыми контурами проекта – ИТ, строительством, инженерной инфраструктурой, поставщиками, финансированием и регуляторными процедурами. Каждое направление живет в своей логике сроков и ограничений.

Сроки получения технических условий на подключение к электрическим сетям в среднем занимают от 3 до 9 месяцев, а в крупных городах могут доходить до трех лет из-за дефицита мощностей. При этом сроки поставки серверного и сетевого оборудования варьируются от 8 до 24 недель из-за зависимости на 80% от иностранных компонентов и резкого подорожания оборудования на фоне ИИ-бума.

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

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

Как построить рабочую модель управления

Эффективная модель начинается с декомпозиции проекта и распределения зон ответственности по каждой задаче.

Зона ответственности включает не только исполнение задач, но и полную подготовку результата для перехода на следующий этап. Например, недостаточно просто установить серверное оборудование – нужно, чтобы оно было подключено, протестировано и готово к нагрузке.

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

Для этого есть 6 шагов:

1. определите внешние ограничения. Ключевыми становятся задачи вне контроля команды: получение технических условий, разрешений, согласования с регуляторами, поставка оборудования и подключение к смежным системам. Эти точки с высокой вероятностью будут тормозить проект;

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

3. не перегружайте контролем выполнение рядовых задач. Их задержка в пределах резерва не влияет на сроки проекта. Сосредоточьтесь на отслеживании ограничений: внешних поставок, разрешений и сроков подключений, вместо ежедневных отчетов от IT-команды;

4. стройте расписание от критического пути, а не желаемой даты. Рассчитайте длительность критического пути с учетом внешних ограничений, добавьте резерв – и получите реальную дату завершения;

5. пересчитывайте критический путь при любом изменении. Сдвиг критической задачи меняет логику всего проекта. Либо ищите более короткий альтернативный путь, либо сообщайте о переносе даты запуска;

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

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

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

Центр управления должен быть один

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

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

Чтобы единый центр заработал, нужно выполнить несколько ключевых условий:

• во-первых, закрепить полномочия центра на уровне заказчика или инвестиционного комитета, чтобы решения всех контуров подчинялись его регламенту;

• во-вторых, назначить ответственного интегрированного плана с возможностями перераспределить ресурсы, сместить приоритеты, инициировать изменения и определить критические ограничения;

• в-третьих, внедрить единый цифровой инструмент планирования и контроля, который объединяет все графики, статусы и ресурсы в одной версии, обязательной для всех команд.

Когда все работают по одному плану, проект становится предсказуемым: проблемные участки фиксируют сразу, критические зависимости под контролем, а запуск идет по графику.