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

«Лендинг готов» может означать файл дизайна, локальную страницу, закрытое превью или публичный рабочий маршрут. Для следующего участника это четыре разных состояния. Я бы записывал критерий готовности через то, что можно открыть, проверить и использовать.
Производство, выпуск и эффект
| Задача | Доказательство результата | Что не доказано |
|---|---|---|
| Текст | Согласованная версия документа | Публикация и читатели |
| Страница | Публичный URL и проверенный сценарий | Рост конверсии |
| Событие аналитики | Доставка с нужными параметрами | Наличие бизнес-эффекта |
| Кампания | Запуск по согласованным настройкам | Окупаемость |
Эта таблица не усложняет приёмку, а разделяет обещания. Команда может отвечать за выпуск и последующий анализ, но не должна объявлять результат бизнеса до накопления данных. Доступная страница и полезная страница тоже требуют разных проверок.
Как написать проверяемое условие
Слабое условие: «качественно сделать аналитику». Рабочее: «после успешной отправки формы событие приходит один раз, содержит утверждённый тип заявки, не содержит личного сообщения; повтор и ошибка проверены». Условие связывает действие, наблюдение и границу данных.
Definition of Done в Scrum Guide задаёт общее понимание завершённого состояния. Для маркетинговой задачи эту идею можно применять без внедрения всего фреймворка: команда заранее согласует, что именно считается проверенным результатом.
Пакет доказательств зависит от риска
Для исправления опечатки достаточно ссылки и readback. Для нового пути оплаты нужна проверка затронутого сценария и его ограничений. Скриншот подтверждает видимый экран, но не успешную обработку формы сервером. Зелёная сборка подтверждает компиляцию, но не чтение таблицы на телефоне.
- Версия результата или дата проверенного состояния.
- Действия проверяющего и ожидаемый исход.
- Фактический исход и ссылка на подтверждение.
- Что оставалось недоступным или не входило в проверку.
Не собирайте полный журнал технических действий ради объёма. Принимающему нужен понятный вывод и возможность проверить основание. Секреты, персональные данные и лишние клиентские записи в пакет приёмки не входят.
Условный пример приёмки формы
Форма открывается на телефоне; обязательные поля объяснены; тестовая отправка по согласованному сценарию принята; заявка дошла до разрешённого тестового получателя; ошибка сети даёт понятное сообщение; повтор не создал дубль. Если реальную доставку проверить не разрешено, статус должен так и говорить: интерфейс проверен, доставка не подтверждена.
Это честная промежуточная готовность, если она согласована. Нельзя заменить отсутствующую проверку словом «должно работать». Также нельзя создавать реальные заявки клиентам или оплаты без соответствующего разрешения.
Как закрывать задачу
Прикрепите доказательства к карточке, назовите проверяющего и получите решение по конкретной версии. Если пришло изменение, используйте версионное согласование. Старое одобрение не переносится автоматически на новые условия.
В управлении ретейнером такой критерий защищает обе стороны от разных ожиданий. Для передачи другому исполнителю пригодится короткий контекст проекта, а причины незавершённой проверки нужно вынести в карту зависимостей.
Доказательство должно соответствовать обещанному сценарию
Если задача звучит «таблица читается на телефоне», одного отсутствия горизонтального переполнения недостаточно. Колонки могли сжаться до нескольких букв. Нужен просмотр подписей и чисел в реальной ширине, а при локальной прокрутке — доступ к последним столбцам. Это пример того, как технический индикатор помогает проверке, но не подменяет пользовательский результат.
Для опубликованной страницы проверьте, что публичный маршрут показывает нужную версию. Локальное превью, успешная загрузка файла и доступность домена отдельно этого не гарантируют. Сохраните время проверки, адрес и несколько критичных наблюдений. Если есть ограничение доступа или региональная особенность, опишите её, не распространяя один успешный просмотр на все возможные условия.
Полезен короткий отрицательный сценарий: что видит человек при неверном вводе, недоступной сети или отсутствии нужных прав. Не нужно проводить опасные или неразрешённые операции ради полноты. Выберите соответствующий риску безопасный тест и назовите оставшуюся границу. Приёмка выигрывает от точности: «проверены эти действия и эти условия» понятнее общего «всё протестировано», за которым невозможно найти конкретное основание.