Цель — задача, которая читается за 2–3 минуты: разработчик начинает работу без уточняющих вопросов, QA получает готовый чек-лист проверки.
Главный принцип
Задача описывает поведение продукта глазами пользователя, а не способ реализации.
Что пользователь видит, нажимает и получает — да. Как это устроено внутри — нет: никаких рекомендаций по архитектуре, структуре данных, полям, названиям параметров, контрактам между фронтом и бэком, выбору библиотек — если задача сама не посвящена конкретной библиотеке или SDK. Это решения разработчиков — в постановке они устаревают при первом же ревью и связывают руки.
Когда технику писать можноФакты о внешних сервисах: как работает чужой API, что умеет провайдер, какие у него ограничения. Например: «Spark позволяет подключать несколько reusable-пакетов на одну eSIM с конфигурацией зон». Разработчик не выведет это сам — такие факты фиксировать нужно.
Задача сама про конкретную библиотеку или SDK: «Подключить Chatwoot SDK в Android-приложение» — здесь название SDK и есть суть задачи, без него постановка теряет смысл.
Требования (безопасность, регуляторика) — уместны, но именно как требования («обмен токена — только на сервере»), а не как инструкции по реализации.
Структура задачи
Семь секций, в этом порядке
Заголовок[BE] или [FE] + суть. «[FE] Открытие чата поддержки по тапу на пуш», а не «Доработки по пушам».
ЗачемБизнес-проблема в 2–3 предложениях: что сейчас плохо для пользователя или бизнеса. Начинать именно с «Зачем», не с «Что сделать».
Что хотимОжидаемое поведение, короткими абзацами.
КонкретикаСписком: платформы, точные тексты кнопок и сообщений (RU и EN), правила, граничные случаи. Всё, что нельзя «додумать».
Что проверяемТестируемый чек-лист: каждый пункт можно выполнить и ответить «да / нет». Это критерии приёмки для QA.
Нужно согласоватьОткрытые вопросы — обязательно с предложенным вариантом: «предлагаю X, решение за продуктом».
Не входит в задачуЧто сознательно не делаем. Снимает половину вопросов на ревью.
Секции 6–7 опциональны: нечего писать — не выдумывать. У задачи, выросшей из большого ТЗ, первым блоком идёт «Контекст и ссылки»: исходное ТЗ, дизайн, парная задача.
Разбивка
Как резать большие фичи
[BE]
Серверная часть. Поведение системы: правила, конфликты, что и когда создаётся. Делается первой.
→
[FE]
Интерфейс. Что видит и нажимает пользователь: кнопки, модалки, тексты. Ставится зависимостью от [BE].
Фича с серверной и интерфейсной работой → две задачи. Не подзадачи и не одна задача «на всех».
Взаимные ссылки: в [FE] пишем «серверная часть — задача [BE] …», и наоборот.
Контракт между фронтом и бэком в задачах не описываем — точный формат данных исполнители согласуют между собой. В [FE] фиксируем только принцип: «логику считает бэк, фронт отображает».
Каждая задача самостоятельно тестируема: у [BE] проверки про поведение системы, у [FE] — про то, что видит пользователь.
Задача длиннее полутора экранов — почти наверняка две задачи. Режьте.
Большое ТЗ (как TonMobile One) не переписываем: оно остаётся исходным документом, для разработки заводятся [BE] и [FE], а в ТЗ добавляется комментарий со ссылками на них.
Не только фичи
Исследования и баги
Не каждая задача — про новое поведение продукта. У исследований и багов свои форматы; общая структура из семи секций им не нужна.
Исследование · «Проанализировать…», «Оценить…», «Проверить возможность…»
Вопросы — списком. Выпишите явно, на какие вопросы нужен ответ. Задача завершена, когда на каждый есть ответ с обоснованием — это и есть её «Что проверяем».
Известное — отдельно. Уже найденные факты, ссылки на документацию и скрины — блоком «Что уже известно», не вперемешку с вопросами.
Итог — комментарием в самой задаче, а не сообщением в личке или чате: знание должно остаться рядом с вопросом, иначе через месяц анализ придётся повторять.
Следующий шаг — назван. Что происходит по итогам: кто и какую задачу заводит при каждом варианте ответа.
Разбивка на [BE]/[FE] исследованию не нужна.
Баг
Заголовок — что сломано и где: «[iOS] Пуш не открывает чат поддержки», а не «Проблема с пушами».
Шаги воспроизведения — нумерованным списком, с самого начала (с какого экрана, под каким пользователем).
Ожидаемое и фактическое поведение — двумя отдельными строками.
Окружение: платформа, версия приложения или сборки, тип аккаунта.
Частота: всегда или иногда (сколько раз из скольких попыток), плюс скрин или видео, если есть.
Антипаттерны
Типовые ошибки — все из реальных задач
Простыня «всё в одном»Цель, сценарии, ошибки и реализация в одном описании. Не читается и не тестируется.
Шаги реализации вместо поведения«Находится пользователь по ID в БД, создаётся сессия» — это псевдокод, а не постановка.
Архитектура и поля в постановкеМодель данных, названия полей API, блокировки, идемпотентность, выбор библиотек — работа разработчиков. Исключения: факты о внешних сервисах и задачи, которые сами посвящены конкретной библиотеке или SDK (см. «Главный принцип»).
«Должно работать» без чек-листаЕсли нельзя проверить — не написано.
Markdown-таблицы и моноширинный текстAsana их не рендерит. Только заголовки, жирный, списки и ссылки.
Открытый вопрос без предложения«Что делать при X?» повисает. «При X предлагаю Y, решение за продуктом» — решается за минуту.
На живых примерах
До / после
Пример 1 · сценарий («Авторизация через Яндекс»)
БЫЛО
Существующий пользователь
Пользователь нажимает Войти с Яндекс ID
Находится пользователь по Yandex ID в БД
Выполняется OAuth-процесс с использованием
login_hint=<логин или email>
Создается сессия
Пользователь попадает в приложение
СТАЛО
КонкретикаПервый вход создаёт ровно один аккаунт; повторные входы всегда ведут в тот же аккаунт, дубликаты не создаются.
Что проверяемПовторный вход после выхода ведёт в тот же аккаунт, дубликат не создаётся.
Слева — пять шагов реализации: БД, login_hint, сессия. Непонятно, что проверять, а login_hint может вообще не понадобиться. Справа — одна строка поведения и одна строка проверки.
Пример 2 · секция «Зачем» («Авторизация через Яндекс»)
БЫЛО
Цель
Реализовать регистрацию и авторизацию
пользователей сервиса через Яндекс ID
с использованием OAuth 2.0 на веб-аппе
и в приложениях iOS и Android.
СТАЛО
У заметной части аудитории есть Яндекс-аккаунт, а Google и Apple доступны не всем. Вход через Яндекс ID поднимает конверсию входа и даёт пользователю запасной способ не потерять аккаунт.
Слева — «что сделать», мотивации нет. Справа — понятно, зачем задача в спринте и чем нельзя жертвовать.
Пример 3 · архитектура в ТЗ («TonMobile One»)
БЫЛО
Plan instance (пакет): profile_id, order_id,
provider_bundle_id, location_zone_size,
priority_index, status (active/inactive/
depleted/expired), starts_at, expires_at…
При добавлении пакета — lock на пару
profile_id + добавляемый пакет…
API / ответы для frontend: по каждому
пакету is_active_now,
covers_current_location, priority_index
СТАЛО
Что хотимПользователь видит все свои пакеты, понимает, какой работает прямо сейчас, а какие ждут своей страны. Логику пакетов считает бэк — фронт её только отображает.
КонтекстТочный формат данных фронт и бэк согласуют между собой.
Слева аналитик спроектировал модель данных, блокировки и поля API — это работа разработчиков. Справа — поведение и граница ответственности; контракт остаётся за исполнителями. А вот факт о внешнем сервисе — «Spark позволяет подключать несколько reusable-пакетов на одну eSIM» — в задаче оставлен: его разработчик сам не выведет.
Пример 4 · критерии приёмки («Авторизация через Яндекс»)
БЫЛО
Пользователь должен иметь возможность:
войти в сервис через аккаунт Яндекса;
автоматически зарегистрироваться
при первом входе;
авторизоваться при повторных входах,
если он сделал log out;
привязать Яндекс-аккаунт к своему user_id
СТАЛО
Что проверяемОтмена на странице Яндекса возвращает на экран входа, аккаунт не создаётся.
При недоступности Яндекса — понятное сообщение об ошибке, другие способы входа работают.
Слева — пожелания: «должен иметь возможность» нельзя проверить и неясно, когда задача выполнена. Справа — чек-лист, который QA проходит руками пункт за пунктом, включая негативные сценарии (отмена, недоступность сервиса), о которых список возможностей молчит.
Пример 5 · открытый вопрос («Безопасность при авторизации»)
Нужно согласоватьОтзывать ли токен у Яндекса при logout. Предложение: не отзывать, чистить только свою сессию; отзыв — только при отвязке аккаунта. Решение за продуктом.
Слева решение «повисло»: непонятно, решено оно или нет, кто и когда его примет. Справа вопрос вынесен явно и с готовым вариантом по умолчанию — продукту остаётся согласиться или поправить, задача не блокируется.
Пример 6 · исследование («Проанализировать механизм обхода ATT»)
БЫЛО
Об итогах анализа сообщить <ссылка
на профиль> в телеге, чтобы она
сформулировала задачу на дизайн,
если мы можем смещать этап, на котором
мы просим это разрешение
СТАЛО
Результат — комментарий в этой задаче1. Можно ли запрашивать разрешение после первой авторизации, не теряя событие регистрации для рекламных кабинетов? 2. При каких условиях это работает, какие ограничения? 3. Рекомендация: переносим запрос или нет.
ДальшеЕсли переносим — Анастасия заводит задачу на дизайн экрана-объяснения со ссылкой на этот анализ.
Слева итог анализа уходит сообщением в личку — знание теряется, а сами вопросы приходится выуживать из текста. Справа вопросы выписаны (готовый критерий завершённости), ответ остаётся в задаче, следующий шаг назначен на оба исхода.