Приёмка задачи: критерии результата и границы доработок

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

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

Приёмка — это решение по обещанному результату

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

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

Пять сущностей, которые нельзя смешивать

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

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

Сначала восстановите, что именно было обещано

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

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

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

Критерий описывает результат, а не внутренний способ работы

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

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

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

Проверяйте результат в том контексте, для которого он обещан

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

1. Откройте согласованный результат и убедитесь, что это нужная версия.
2. Зафиксируйте контекст проверки: для кого и в каком состоянии оценивается результат.
3. Пройдите каждый критерий отдельно, не заменяя один успешный пример общим впечатлением.
4. Для существенных негативных или граничных состояний проверьте оговорённое поведение, если такие состояния были частью критериев.
5. К каждому выводу добавьте свидетельство, достаточное для повторной сверки.
6. Запишите решение по текущей версии результата.
7. Если требуется доработка, укажите только выявленное несоответствие и условие следующей проверки.

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

Свидетельство проверки должно относиться к той же версии

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

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

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

Решение должно объяснять, что происходит дальше

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

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

Возвращайте работу с одной понятной причиной

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

Формула возврата: «Критерий о результате X пока не подтверждён: в версии Y наблюдается Z. Для повторной приёмки нужно устранить это расхождение; при следующем просмотре перепроверяем данный критерий и зависящие от него условия».

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

Одна доработка — это ограниченный пакет исправлений, а не обещание одного цикла

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

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

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

Как отличить недостающий результат от новой хотелки

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

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

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

DoD — общая планка, критерии приёмки — условия конкретной задачи

Definition of Done уместно упоминать только как границу. В Scrum-контексте это общая характеристика состояния готового инкремента и стандарты качества, применимые шире одной конкретной задачи. Критерии приёмки относятся к конкретному результату: что именно должно быть истинно для этого элемента работы. Поэтому соответствие общей планке не доказывает выполнение конкретной цели, а выполнение конкретных критериев не отменяет общие требования качества, если команда их использует.

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

Развилки, на которых чаще всего ломается решение

Критерий оказался непроверяемым

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

Часть результата отсутствует

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

Критерий выполнен, но появилась новая просьба

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

Проверка зависит от другого человека

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

Подтверждение устарело или относится не к той версии

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

Результат технически есть, но не решает исходную задачу

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

Пример: отсутствует обещанная часть результата

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

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

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

Пример: критерии выполнены, а новая просьба появляется на приёмке

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

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

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

Минимальная воспроизводимая запись приёмки

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

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

Форма может быть любой, пока запись позволяет воспроизвести логику решения. Это особенно важно, когда результат меняется после проверки: без версии и свидетельства отметка «принято» быстро теряет смысл.

Как правильно принимать задачи без расширения границ

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

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