Вступление: проект «вот-вот стартует» уже три месяца
Бюджет выделен. Команда собрана. Задачи обсуждены на нескольких встречах. Все согласны, что пора начинать. Но проект не стартует — неделя за неделей.
Это одна из самых распространённых и при этом наименее очевидных проблем в управлении ИТ-проектами. Когда проект не движется по понятным причинам — нет денег, нет команды, не готова инфраструктура — ситуацию легко диагностировать и исправить. Гораздо сложнее, когда формально всё готово, но старт всё равно откладывается. В такой ситуации причины скрыты, и именно поэтому они так опасны.
Почему важно запускаться вовремя
Каждая неделя задержки на старте — это не просто потерянное время. Это реальные потери для бизнеса.
Влияние на сроки. Задержка запуска автоматически сдвигает все последующие этапы проекта. Если дата выхода продукта зафиксирована, команда будет нагонять упущенное время за счёт качества или сверхурочной работы.
Упущенные возможности. Пока проект ждёт старта, рынок не стоит на месте. Конкурент, запустивший аналогичное решение раньше, занимает позицию, которую потом придётся отвоёвывать.
Рост затрат. Команда в режиме ожидания — это расходы без отдачи. Специалисты получают оплату, встречи проводятся, ресурсы расходуются, но продукт не создаётся. Чем дольше затягивается запуск ИТ-проекта, тем выше его итоговая стоимость.
Пять скрытых причин, по которым проект не стартует
Причина первая: никто точно не понимает, что нужно сделать
Это самая частая и самая незаметная причина задержки. На встречах все кивают, что задача ясна. Но стоит перейти к конкретике — и оказывается, что у разных участников разные представления о том, каким должен быть результат.
Руководитель думает об одном, разработчики — о другом, владелец продукта — о третьем. Никто не говорит вслух о противоречиях, потому что все убеждены, что остальные понимают задачу так же, как они. В итоге команда не может начать работу, потому что нет единого понимания точки назначения.
Пока это расхождение не выявлено и не устранено, проект будет стоять на месте под видом «уточнения деталей».
Причина вторая: нет нужных специалистов
Иногда проект не стартует просто потому, что у него нет ключевых участников. Формально команда есть — есть руководитель проекта, есть разработчики. Но нет аналитика, который должен описать требования. Или нет архитектора, который должен спроектировать систему. Или все разработчики заняты на других задачах и физически не могут начать новый проект.
Нехватка специалистов на старте — одна из главных причин, по которым запуск ИТ-проекта затягивается. Это неудобная правда, которую не всегда принято признавать вслух: проект числится «в работе», хотя реальных ресурсов для его запуска нет.
Причина третья: команда перегружена текущими задачами
Даже если нужные специалисты формально есть, это не значит, что у них есть время на новый проект. Управление ИТ-проектами в условиях, когда каждый участник команды ведёт несколько направлений одновременно, превращается в постоянный выбор между срочным и важным.
Новый проект всегда проигрывает текущим обязательствам. Разработчик не начнёт работу над новой задачей, пока не закрыл старую. Аналитик не сядет за требования нового проекта, пока поддерживает действующий. Перегруженная команда — это не лень и не безответственность. Это физическая невозможность сделать больше, чем позволяет время.
Подробнее о том, как диагностировать перегруз команды и что с ним делать, мы писали в статье о признаках нехватки ресурсов в ИТ-команде.
Причина четвёртая: согласования не заканчиваются
Некоторые проекты не могут стартовать, потому что застревают в бесконечном цикле согласований. Техническое задание уходит на согласование — возвращается с правками. Правки вносятся — снова уходят на согласование. Кто-то из ключевых согласующих недоступен. Кто-то меняет позицию. Кто-то хочет учесть ещё одно мнение.
Это не злой умысел — это системная проблема в процессе принятия решений. Когда неясно, кто имеет право сказать финальное «да» и что именно нужно согласовать, а что можно решить рабочим порядком, — проект зависает в петле бесконечных уточнений.
Причина пятая: требования не проработаны
Казалось бы, все знают, что нужно описать требования до начала разработки. На практике же требования нередко существуют в виде устных договорённостей, разрозненных сообщений в переписке или презентации с тезисами на десяти слайдах. Это не требования — это намерения.
Когда команда пытается начать работу по таким «требованиям», первый же реальный вопрос — «а как именно должно работать вот это?» — показывает, что ответа нет. Работа останавливается, начинается уточнение, которое снова возвращает проект на стадию обсуждения.
К чему приводят эти причины
Каждая из перечисленных причин в отдельности уже способна затормозить проект на несколько недель. Когда они сочетаются — а это происходит чаще, чем кажется, — задержка запуска ИТ-проекта превращается в хроническую проблему.
Команда теряет мотивацию: когда проект долго не стартует, люди перестают воспринимать его всерьёз. Бюджет тает на холостом ходу. Руководство начинает сомневаться в реалистичности сроков и постепенно теряет контроль над проектом. А когда старт наконец происходит, команда уже вымотана предстартовой неразберихой и работает не с тем настроем, который нужен для успешного проекта.
Как выявить причины на раннем этапе
Большинство скрытых причин задержки можно обнаружить, если задать правильные вопросы в нужный момент.
Проверьте готовность требований. Попросите любого участника команды своими словами объяснить, что именно должно быть сделано в первом этапе и каков критерий его завершения. Если ответы расходятся — требования не готовы.
Оцените реальную загрузку команды. Посмотрите, сколько активных задач у каждого специалиста прямо сейчас. Если у ключевых участников нет свободной полосы — проект не стартует, пока что-то не будет закрыто или перераспределено.
Определите, кто принимает финальное решение. Составьте список того, что нужно согласовать перед стартом, и для каждого пункта назначьте конкретного ответственного с правом окончательного решения. Без этого согласования будут продолжаться бесконечно.
Проверьте состав команды. Есть ли все нужные специалисты? Не только формально — в списке участников — но фактически: готовы ли они приступить к работе прямо сейчас?
Как ускорить запуск проекта
Зафиксируйте задачи письменно. Любое решение, принятое на встрече, должно быть записано и разослано участникам в тот же день. Устные договорённости — главный враг точного старта.
Ограничьте круг согласующих. Определите минимально необходимый круг людей, без которых решение не может быть принято, — и исключите всех остальных из процесса согласования. Чем меньше согласующих, тем быстрее движется проект.
Подключите аналитику на старте. Системный аналитик, привлечённый в самом начале, помогает быстро структурировать требования, выявить противоречия и перевести размытые пожелания в конкретные задачи для разработки. Автоматизация бизнес-процессов начинается именно с этой работы — и без неё запуск неизбежно затянется.
Усильте команду там, где есть дефицит. Если проект не стартует из-за нехватки конкретного специалиста — аналитика, разработчика, архитектора — не ждите, пока освободится кто-то из штатной команды. Это ожидание стоит дороже, чем привлечение внешнего эксперта.
Роль аутстаффа в ускорении старта
Модель аутстаффинга создана именно для ситуаций, когда проект упирается в дефицит ресурсов. Аутстафф аналитиков или разработчиков позволяет быстро закрыть недостающую позицию — без длительного найма, без адаптационного периода в несколько месяцев.
Внешний специалист подключается к команде заказчика и работает над конкретными задачами в том ритме и с теми инструментами, которые приняты в проекте. Это не консультант, который даёт советы, и не подрядчик, которому передаётся работа целиком. Это член команды с нужной экспертизой — на нужный срок.
Команда Augment помогает компаниям быстро найти и подключить специалистов под конкретные задачи: от системных аналитиков на этапе проработки требований до разработчиков для ускорения старта проекта. Усиление команды в нужный момент — это то, что превращает затянувшееся ожидание в реальное движение.
Вывод
Задержка запуска ИТ-проекта редко бывает случайной. За ней всегда стоят конкретные причины: размытые требования, нехватка специалистов, перегруженная команда, бесконечные согласования. Каждая из этих причин устранима — если её вовремя выявить и не пытаться преодолеть волевым усилием то, что требует системного решения.
Заключение
Чем раньше выявлены причины задержки, тем меньше потерь несёт проект. Своевременное усиление команды нужными специалистами — один из самых быстрых способов сдвинуть проект с мёртвой точки и удержать контроль над сроками. Именно для таких ситуаций существует модель предоставления ИТ-специалистов: чтобы отсутствие нужного человека не становилось причиной, по которой проект месяцами ждёт своего старта.
