Короткий ответ
Перед оплатой этапа web/digital-разработки нужно проверять не процент готовности и не уверенность подрядчика, а проверяемые артефакты: что входило в этап, что реально сделано, где это можно увидеть, какие критерии приёмки закрыты, какие ошибки остались, готов ли релиз, переданы ли документы и какие риски переходят в следующий этап.
Оплата этапа - это управленческое решение. Оно должно отвечать на три вопроса:
- можно ли принять результат как выполненный;
- что нужно исправить до оплаты или сразу после неё;
- не создаёт ли оплата риск для следующего этапа, бюджета, релиза или передачи проекта.
Если подрядчик даёт факты, решение обычно принимается спокойно. Если вместо фактов есть только “почти готово”, “остались мелочи” или “после оплаты доделаем”, лучше сначала провести технический контроль подрядчика или пройти чек-лист контроля подрядчика.
Почему оплату этапа нельзя привязывать только к словам
В сложной разработке этап может выглядеть готовым на презентации, но оставаться рискованным внутри. Интерфейс может открываться, а интеграции - работать нестабильно. Основной сценарий может проходить, а права доступа, ошибки, документы и релизный процесс - быть не готовыми.
Проблема начинается, когда бизнес оплачивает этап, не понимая:
- какие задачи входили в состав этапа;
- какие работы фактически завершены;
- что не вошло в релиз;
- какие ошибки известны подрядчику;
- какие документы должны быть переданы;
- какие решения повлияют на следующий бюджет;
- можно ли передать проект другой команде, если ситуация ухудшится.
Это не юридическая оценка договора. Это техническая и управленческая проверка: соответствует ли результат тому, что бизнес считает выполненным этапом.
Что проверить до оплаты
| Зона проверки | Что запросить | Зачем это нужно |
|---|---|---|
| Состав этапа | Список задач, которые должны были войти в этап | Понять, что именно оплачивается |
| Демонстрация | Доступ к рабочему или тестовому окружению и показ ключевых сценариев | Проверить результат, а не только отчёт |
| Критерии приёмки | Что считается готовым по каждой крупной функции | Не спорить после оплаты о смысле “готово” |
| Ошибки и ограничения | Список известных дефектов, переносов и временных решений | Увидеть, что остаётся в проекте |
| Релиз | Состав поставки, план проверки, план отката | Не запускать рискованный релиз вслепую |
| Документация | Что обновлено по логике, интеграциям, окружениям и доступам | Снизить зависимость от подрядчика |
| Риски следующего этапа | Что может увеличить срок, бюджет или сложность дальше | Не переносить скрытые проблемы в новый бюджет |
Если хотя бы по двум-трём зонам подрядчик не может дать проверяемые ответы, оплату лучше не рассматривать как формальность.
Что нельзя принимать как готовый результат
Некоторые артефакты могут быть полезны, но сами по себе не доказывают готовность этапа.
Не стоит принимать как полноценное подтверждение:
- скриншоты без доступа к окружению;
- видео без возможности проверить сценарий самостоятельно;
- отчёт о выполненных задачах без демонстрации результата;
- общий процент готовности без списка незакрытых работ;
- фразу “остались только мелочи” без перечня этих мелочей;
- релиз без критериев проверки и плана отката;
- обещание передать документацию позже;
- новый счёт без объяснения, что изменилось в объёме, оценке или рисках.
Это не значит, что подрядчик обязательно работает плохо. Но это значит, что бизнес пока не видит достаточной картины для решения об оплате.
Порядок проверки перед оплатой
1. Зафиксировать состав этапа
Начните с простого вопроса: что именно входит в оплачиваемый этап?
Попросите подрядчика дать:
- список задач этапа;
- статус по каждой крупной задаче;
- что было добавлено или исключено по ходу работы;
- какие решения были согласованы отдельно;
- какие задачи предлагается перенести.
Если состав этапа нельзя восстановить, спор об оплате почти неизбежно станет спором об ожиданиях.
2. Посмотреть результат в рабочем окружении
Демонстрация должна показывать не только красивые экраны, а реальные пользовательские сценарии.
Проверьте:
- можно ли зайти в тестовое или рабочее окружение;
- проходит ли основной сценарий от начала до конца;
- видны ли роли пользователей и права доступа;
- работают ли интеграции, если они входили в этап;
- можно ли повторить демонстрацию без участия разработчика;
- есть ли список известных ошибок.
Если подрядчик показывает только скриншоты или запись, попросите доступ к окружению и короткий сценарий проверки.
3. Проверить критерии приёмки
Критерии приёмки отвечают на вопрос: по каким признакам бизнес считает работу выполненной.
Для важной функции должны быть понятны:
- какой пользовательский сценарий закрывается;
- какие роли участвуют;
- какие данные создаются или меняются;
- какие исключения обработаны;
- какие интеграции затронуты;
- кто принимает результат со стороны бизнеса.
Если критериев не было до старта, их всё равно нужно сформулировать перед оплатой. Иначе следующий этап унаследует неясность.
4. Разобрать открытые ошибки
Ошибки бывают разными. Одни не мешают принять этап, другие делают оплату рискованной.
Попросите разделить:
- критичные ошибки, которые блокируют основной сценарий;
- ошибки, которые можно исправить после оплаты;
- ограничения, о которых должен знать бизнес;
- временные решения, которые нужно заменить;
- дефекты, которые могут повлиять на следующий релиз.
Оплачивать этап можно только тогда, когда понятно, какие ошибки остаются и кто несёт ответственность за их закрытие.
5. Проверить релиз и план отката
Если этап должен перейти в релиз, важно понять, как именно это произойдёт.
Проверьте:
- что входит в релиз;
- когда и где он выкатывается;
- какие сценарии проверяются до запуска;
- кто принимает решение о публикации;
- что делать, если после релиза появится критичная ошибка;
- как быстро можно откатить изменения;
- какие системы и интеграции затронуты.
Без этого оплата может закрепить ситуацию, где результат формально сдан, но запуск остаётся рискованным.
6. Запросить документацию и доступы
Документация перед оплатой нужна не для бюрократии. Она показывает, можно ли поддерживать и развивать результат дальше.
Минимум:
- актуальный backlog и статус задач;
- инструкция по проверке результата;
- список доступов и владельцев сервисов;
- карта затронутых модулей и интеграций;
- изменения в бизнес-логике;
- инструкция по релизу или деплою, если она изменилась;
- список известных технических рисков.
Если документация снова откладывается “на следующий этап”, это отдельный риск. Особенно если проект может перейти к другой команде.
7. Оценить риски следующего этапа
Перед оплатой важно спросить не только “что сделано”, но и “что это меняет дальше”.
Полезные вопросы:
- какие решения усложнят будущие доработки;
- какие задачи нельзя оценить без исследования;
- какие риски уже видны по архитектуре;
- какие интеграции требуют отдельной проверки;
- что может увеличить следующий бюджет;
- что нужно решить бизнесу до старта следующего этапа.
Если подрядчик отвечает конкретно, это хороший сигнал. Если риски не показываются, новый этап может начаться с тех же проблем.
Три возможных решения
| Решение | Когда подходит | Что зафиксировать |
|---|---|---|
| Оплатить этап | Результат показан, критерии приёмки закрыты, риски понятны | Акт, список переданных материалов, условия следующего этапа |
| Оплатить после исправлений | Основная часть готова, но есть блокирующие дефекты или недостающие документы | Список исправлений, сроки, ответственные, повторная проверка |
| Сначала провести технический контроль | Статус размытый, релиз рискованный, документации нет, ответы общие | Вопросы подрядчику, карта рисков, рекомендация по оплате или паузе |
Задача не в том, чтобы задерживать оплату любой ценой. Задача - не оплачивать неопределённость как готовый результат.
Вопросы подрядчику перед оплатой
- Какие задачи этапа полностью готовы и где их можно проверить?
- Какие задачи не готовы, но предлагаются к переносу?
- Какие критерии приёмки закрыты по каждой крупной функции?
- Какие ошибки известны на момент оплаты?
- Какие сценарии проверялись перед демонстрацией?
- Что входит в ближайший релиз и что остаётся за его пределами?
- Какие документы обновлены по итогам этапа?
- Какие доступы, окружения и инструкции передаются бизнесу?
- Какие технические решения повлияют на следующий этап?
- Какие риски нужно знать до оплаты и старта новых работ?
Эти вопросы лучше задавать письменно. Так проще отделить факты от общих объяснений.
Когда достаточно внутренней проверки
Внутренней проверки может хватить, если:
- этап небольшой;
- результат можно проверить по понятным сценариям;
- нет сложных интеграций;
- документация передана;
- подрядчик показывает список задач и дефектов;
- релиз не влияет на критичные процессы;
- внутри компании есть человек, который понимает бизнес-логику и принимает результат.
В этом случае можно использовать чек-лист контроля подрядчика и зафиксировать решение внутри команды.
Когда нужен технический контроль
Технический контроль нужен, если:
- подрядчик не даёт проверяемый статус;
- этап дорогой или влияет на критичный процесс;
- релиз может затронуть CRM, 1C, личный кабинет, портал или внешние API;
- есть спор по объёму работ;
- оценки и сроки изменились без понятной причины;
- нет документации или доступов;
- бизнес не понимает, можно ли принимать результат;
- есть риск, что после оплаты придётся менять подрядчика.
В таком формате внешний эксперт помогает проверить артефакты, сформулировать вопросы подрядчику и дать руководителю понятный вывод: оплачивать, оплатить после исправлений, остановить спорные работы или готовить передачу.
Практический вывод
Проверка перед оплатой этапа должна быть спокойной и предметной. Не нужно спорить о доверии, если можно запросить факты: состав работ, демонстрацию, критерии приёмки, список ошибок, план релиза, документацию и риски следующего этапа.
Если факты есть, оплату можно принимать как рабочее управленческое решение. Если фактов нет, сначала стоит разобраться, почему подрядчик не показывает готовность. Для этого подойдут технический контроль подрядчика, статья если подрядчик не даёт прозрачности и чек-лист контроля подрядчика.
Если вопрос уже связан с переносом релиза, новым сроком или просьбой увеличить бюджет, смотрите страницу подрядчик затягивает разработку и статью как контролировать сроки разработки.
Материалы по теме
| Материал | Когда смотреть |
|---|---|
| Как понять, что подрядчик не справляется с разработкой | Если перед оплатой нужно понять, это нормальная сложность или подрядчик теряет управляемость |
| Технический контроль подрядчика | Если нужно проверить готовность этапа, релиз, документацию и риски до оплаты |
| Чек-лист контроля подрядчика | Если нужен список вопросов для самостоятельной проверки |
| Если подрядчик не даёт прозрачности | Если статусы, сроки и релизы остаются непроверяемыми |
| Как читать технический отчёт подрядчика | Если отчёт есть, но непонятно, можно ли доверять плану |
| Как контролировать сроки разработки | Если оплата связана с переносом сроков |
| Подрядчик затягивает разработку | Если подрядчик просит новый срок или бюджет после задержки |
| Продолжать, контролировать или менять подрядчика | Если после проверки нужно выбрать следующий управленческий сценарий |
