Почему IT-проект зависает на «готово на 80%» и как понять, что осталось

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

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

Почему процент готовности становится бессмысленным

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

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

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

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

Что смотреть вместо процента

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

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

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

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

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

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

Как разделить «подтверждено», «частично подтверждено» и «не подтверждено»

Чтобы остаток стал видимым, полезно развести статусы без сложных методик.

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

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

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

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

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

Какие документы действительно нужны

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

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

Нужен список сценариев приёмки или хотя бы ключевых проверок. Без них спор о готовности неизбежен: стороны проверяют разное.

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

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

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

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

Как восстановить остаток проекта

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

1. Зафиксируйте дату и состав источников: договор и приложения, актуальные требования, переписка с изменениями, трекер задач, демо-материалы, список известных дефектов, доступы к стендам.
2. Соберите единый список обязательств «на сейчас». Не идеальный юридический акт, а рабочий перечень того, без чего стороны не считают проект сданным.
3. Для каждого пункта отметьте статус: подтверждено / частично подтверждено / не подтверждено. Критерий подтверждения запишите коротко.
4. Отдельно вынесите блокеры: нет доступа, нет решения, нет данных, нет ответа смежной системы, нет среды.
5. Соберите остаток до приёмки: непроверенные сценарии, открытые дефекты, незакрытые интеграции, документы и передачи, обязательные для закрытия.
6. Оцените остаток не процентом, а объёмом работ и зависимостями. Остаток лучше описывать конкретными задачами, пакетами работ, блокерами и зависимостями. Если по ним можно получить обоснованную оценку срока — фиксировать её отдельно.
7. Согласуйте короткий ритм проверки: что подтверждаем на этой неделе, кто подтверждает, какой результат считается достаточным.
8. Только после этого обсуждайте срок и состав ближайшего релиза. Иначе даты снова сядут на ту же туманную «восьмидесятку».

Этот порядок не требует идеальной документации с первого дня. Он требует честности в статусах и дисциплины в критериях. Часто уже после шагов 2–5 стороны впервые видят один и тот же остаток.

Когда нужен независимый разбор

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

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

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

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