Как ставить задачи разработчикам: структура, критерии приемки и границы задачи

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

Jira, YouTrack, Trello или другой backlog помогают зафиксировать задачу, но не исправляют слабую постановку. Если в задаче нет результата, границ и проверки, она останется неуправляемой даже в хорошем трекере.

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

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

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

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

Практическое правило простое: требование объясняет, какое свойство результата нужно получить; задача объясняет, какое изменение сейчас нужно сделать, чтобы к этому результату приблизиться.

Хорошая задача не обязана быть длинной. Важно, чтобы в ней были видны результат, границы и проверка.

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

Полезно проверять три слоя:

• Основной outcome. Что пользователь, система или интеграция сможет сделать после изменения.
• Negative cases. Что произойдет при ошибке, отсутствии настройки, запрете политики, недоступности внешнего сервиса или неверных данных.
• Способ проверки. Где и как подтвердить результат: сценарий в интерфейсе, API-ответ, лог, тест, документ, акт приемки.

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

Acceptance criteria не должны подменять техническую реализацию. Они фиксируют, какой результат принимается, а не диктуют каждую строку кода.

Подробный разбор с шаблоном и примерами вынесен отдельно: критерии приемки задачи.

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

Обычно стоит разделять:

• модель данных и миграцию данных;
• интерфейс и поведение API;
• интеграционный контракт и реализацию провайдера;
• политику доступа и экранные состояния;
• исследование варианта и implementation task;
• текущий scope и будущие улучшения.

Если работа начинается с неопределенности, лучше оформить отдельную исследовательскую задачу. Spike или research task должен завершаться не словами “изучили”, а decision output: варианты, риски, рекомендация и список последующих задач на реализацию.

Definition of Ready можно объяснять по-русски как готовность задачи к разработке. Это не формальная галочка перед спринтом, а проверка, что задачу уже можно оценивать и брать в работу.

Задача готова, если:

• понятен ожидаемый результат;
• есть границы и out of scope;
• известны зависимости, доступы, данные и окружения;
• есть владелец смысла задачи и человек, который примет результат;
• критерии приемки проверяемы;
• негативные состояния описаны явно, если они влияют на поведение системы;
• в задаче нет секретов, токенов, production endpoints и значений, которые должны жить только в окружении.

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

У задачи есть несколько разных проверок готовности, и их лучше не смешивать. Definition of Ready помогает понять, можно ли задачу уже оценивать и брать в разработку. Acceptance Criteria описывают, какой конкретный результат нужно принять в этой задаче. Definition of Done, или DoD, фиксирует общий стандарт команды: при каком качестве работа считается завершенной и может быть показана, передана дальше или включена в поставку.

DoD не заменяет критерии приемки. Критерии приемки говорят, что должно работать в конкретной задаче. Definition of Done добавляет общий слой качества: как команда понимает слово «готово» для любой задачи этого типа.

Для разработки DoD обычно включает несколько проверок:

• код прошел review или другую принятую командой проверку;
• автоматические и ручные проверки, которые нужны для этой задачи, выполнены или явно объяснено, почему они недоступны;
• acceptance criteria закрыты и проверяются понятным способом;
• документация, changelog или release notes обновлены, если изменение влияет на пользователей, эксплуатацию или приемку;
• нет известных блокирующих дефектов и незакрытых решений, которые мешают показать результат;
• результат можно продемонстрировать, передать в следующий этап или включить в поставку без скрытых оговорок.

Слишком сильный DoD, который команда постоянно игнорирует, не помогает управлению. Лучше иметь короткий и выполнимый стандарт, чем формальный список, который не используется при оценке, разработке и приемке.

Такой шаблон можно перенести в Jira, YouTrack, Trello, Notion или другой backlog. Названия полей можно менять под процесс команды, но смысл лучше сохранить.

Summary
Короткое действие и результат.

Context
Почему задача нужна, с каким требованием, сценарием или проблемой связана.

Expected result
Что должно измениться для пользователя, системы, интеграции или команды.

Scope
Что входит в текущую задачу.

Out of scope
Что не входит и не должно учитываться при приемке этой задачи.

Acceptance criteria
1. Проверяемый основной результат.
2. Негативный сценарий или ограничение.
3. Способ проверки результата.

Dependencies
Доступы, данные, API, макеты, решения, окружения, внешние владельцы.

How to check
Где и как проверить результат: тестовый контур, сценарий, API, лог, документ, акт.

Для маленькой задачи часть полей может занимать одну строку. Для задачи подрядчику или задачи перед оценкой лучше не сокращать блоки про scope, out of scope, acceptance criteria и зависимости.

• Описывать область работ вместо результата. Формулировка “заняться личным кабинетом” не показывает, что должно измениться.
• Повторять название продукта или epic в summary. Заголовок должен назвать действие и результат.
• Не фиксировать out of scope. Тогда будущие идеи легко превращаются в ожидание текущей поставки.
• Писать acceptance criteria как пожелания. Критерий должен быть проверяемым.
• Смешивать несколько ownership layers. UI, storage, provider, migration, policy и integration contract часто требуют разных владельцев и разных проверок.
• Оставлять research task без решения. Исследование должно завершаться вариантом, рекомендацией и последующими implementation tasks.
• Хранить секреты в задаче. Токены, пароли, production endpoints и environment-only значения не должны попадать в Jira или backlog.

Если задач еще много и они не связаны между собой, начните со страницы как собрать требования к ИТ-проекту перед оценкой разработки. Если нужно разложить требования по этапам, используйте roadmap проекта из требований.

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

Для работы с AI coding agents пригодится отдельная страница как работать с Codex в репозитории: там те же принципы применяются к задаче, которую получает агент в рабочем репозитории.