Почему ИТ-проекты срываются ещё до старта

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

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

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

Коротко: пять главных мыслей

Проект стартует на этапе договорённостей, потому что именно там фиксируются объём, сроки и допущения, которые потом никто не перечитывает.

Главная причина срыва — не слабые разработчики, а несовпадение картин мира: одна сторона обсуждала результат, другая получила объём работ.

Оценка без озвученных допущений — не оценка, а обещание.

Модель контракта не юридическая формальность, а способ распределить неопределённость. Фиксированная цена при плохо описанном объёме обходится дороже почасовой модели.

У заказчика есть собственные обязанности в проекте. Без владельца продукта с правом принимать решения сорвётся любой подрядчик.

Что происходит между «подписали» и «начали»

Разберём сценарий, который повторяется в разных вариациях десятки раз.

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

Обсуждалась ценность: «вы получите систему, где план продаж считается автоматически с учётом внешних факторов». Команда получила объём работ: интеграция с двумя источниками, модель расчёта, интерфейс, отчётность. Разница между этими двумя формулировками и есть будущий срыв, потому что в первой нет ответов на ключевые вопросы. Чьи это данные и в каком они состоянии. Кто согласует методику расчёта. Что делать, если исторические данные неполные. Кто принимает результат и по каким критериям.

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

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

Пять причин срыва, которые закладываются до старта

Объём описан через желаемый результат, а не через границы. «Автоматизировать планирование» — это цель, а не объём. Объём — это перечень процессов, источников данных, интеграций, роли пользователей и, что не менее важно, того, чего в проекте не будет. Раздел «вне объёма» в коммерческом предложении снимает больше будущих споров, чем любая скидка.

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

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

Не определены критерии приёмки. Если в момент подписания непонятно, что считается сделанным, приёмка превратится в переговоры. Критерии должны формулироваться на входе и звучать измеримо: отчёт формируется за определённое время на заданном объёме записей, расчёт совпадает с эталонной моделью на исторических данных. Формулировка «система работает корректно» критерием не является.

Не оценено качество данных. Самая недооценённая позиция в проектах аналитики, планирования и импортозамещения. Данные почти всегда хуже, чем предполагает заказчик: пропуски, несогласованные справочники, разные версии одной сущности в разных системах. Приведение данных в пригодное состояние может занимать значимую часть проекта, и оценивать это нужно отдельной строкой, а не «в рамках».

Десять вопросов подрядчику до подписания

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

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

Про процесс. Как проект передаётся в разработку и кто присутствует при передаче. Кто будет постоянным контактом и когда он подключается. Как заказчик узнаёт о ходе работ и в каком формате. Какие критерии приёмки предлагаются по этапам.

Про заказчика. Как и когда оценивается качество данных. Что нужно от команды заказчика и в какие сроки.

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

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

Фиксированная цена или почасовая оплата

Модель контракта — инструмент управления рисками, а не юридическая деталь. Выбор зависит от одного параметра: насколько точно описан объём.

Фиксированная цена работает при детально описанном объёме и стабильных требованиях. Риск несёт подрядчик и закладывает его в стоимость. Опасности две: экономия на качестве, если оценка оказалась оптимистичной, и спор о трактовке ТЗ при любом уточнении. Обязательное условие — полное задание и измеримые критерии приёмки.

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

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

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

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

Изменения и прозрачность: два механизма, которые снимают половину напряжения

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

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

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

Роль заказчика: без чего сорвётся любой подрядчик

Значительная часть проблемных проектов упирается не в исполнителя. Это стоит проговаривать до старта, а не в момент срыва.

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

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

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

Что делать, если проект уже идёт и уже отстаёт

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

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

Второй — переоценить остаток с допущениями. Не «сколько ещё осталось по старому плану», а новая оценка оставшегося объёма с прямым перечислением условий, при которых она верна, и рисков, которые могут её сдвинуть. Если по старому плану оценки без условий не было, здесь её нужно наконец получить.

Третий — договориться о критериях приёмки задним числом. Это неприятный разговор, но без него проект не закроется никогда: приёмка будет бесконечной, потому что предмет приёмки не определён. Формулируется он по тому же принципу — измеримо и по этапам.

Дополнительно стоит принять решение о приоритизации: почти всегда часть заявленного объёма не критична для запуска. Разделение на «нужно для запуска» и «можно после» возвращает проекту реалистичный срок быстрее любого наращивания команды.

Как этот этап должен быть устроен

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

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

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

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

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

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

Чек-лист до подписания договора

Объём и оценка. Объём описан перечнем процессов, интеграций и ролей, а не целью. Присутствует раздел «вне объёма проекта». Оценка сопровождается списком допущений. Проведена оценка качества и полноты данных.

Управление. Определён владелец продукта на стороне заказчика с правом принимать решения. Зафиксированы встречные обязательства заказчика и сроки их исполнения. Прописан порядок изменения объёма, сроков и стоимости. Согласован формат и периодичность отчётности и демонстраций.

Результат. Сформулированы измеримые критерии приёмки по каждому этапу. Требования безопасности получены и учтены в архитектуре. Урегулированы права на результат и исходный код. Определены условия поддержки и передачи знаний после сдачи.

Если больше трёх пунктов не закрыто, подписывается не проект, а намерение.

Итоги

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