Как понять реальное состояние IT-проекта, когда заказчик и подрядчик видят его по-разному

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

Со стороны заказчика это выглядит как потеря управляемости. Вопрос «где мы сейчас?» перестаёт иметь общий ответ. Дальше начинается спор о формулировках, вине и мотивах, хотя сначала не хватает простого: единого набора фактов, с которым можно работать.

Эта статья не про метрику «готово на N%». Речь о другом: как собрать согласованную картину проекта, когда источники противоречат друг другу.

Почему у сторон появляются разные версии одного проекта

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

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

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

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

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

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

Какие источники считать фактами

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

Обычно полезны несколько слоёв.

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

Заявленное исполнение. Планы, статусы, отчёты, закрытые задачи, презентации демо. Это отвечает на вопрос: что сторона считает выполненным.

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

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

Для управленческого решения полезно сопоставить связку: обязательство → заявленный статус → фактическое состояние / проверка → остающийся разрыв. Документ сам по себе может быть фактическим подтверждением; важно другое — одного источника обычно недостаточно, чтобы описать текущее состояние проекта целиком.

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

Как собрать единый реестр обязательств

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

Формулировка обязательства. Что должно быть сделано, без внутренних жаргонных сокращений.

Источник. Откуда взялось: договор, ТЗ, изменение, протокол, переписка. Если источников несколько и они противоречат — это тоже нужно видеть.

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

Текущий статус. Например: подтверждено / частично / не подтверждено. Важно, чтобы статус опирался на проверку, а не на ощущение.

Подтверждение. Ссылка на стенд, демо, задачу, протокол проверки, артефакт или другой проверяемый источник. Без этого статус снова станет мнением.

Владелец следующего шага. Кто должен сделать движение: подрядчик, заказчик, смежная команда.

Блокер. Если движение невозможно — почему именно.

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

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

Почему спор о виноватых мешает восстановить проект

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

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

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

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

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

Что делать после восстановления фактов

Когда единый реестр появился, работа не заканчивается. Меняется качество решений.

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

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

Отдельно решите, что делать с противоречиями источников. Где-то нужно явное изменение объёма. Где-то — уточнение критерия. Где-то — признание, что пункт больше не актуален. Главное — не оставлять противоречие «висящим»: оно снова породит две версии проекта.

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

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

Пример: когда единый источник фактов оказался первым шагом

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

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

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

Если нужно помочь собрать такую картину по текущему проекту, можно оставить запрос.