Как продакту ставить задачи команде

Почему задачи теряются

Главный признак плохо поставленной задачи — спустя неделю выясняется, что команда сделала «не то». Не потому что они плохие, а потому что в задаче не хватало деталей, и они достроили картину сами. Это нормально: если контекста нет, мозг его придумывает.

Боль выглядит так: продакт пишет в Jira «Сделать фильтр на странице каталога», ставит срок, идёт дальше. Через спринт получает фильтр, который выпадает справа сверху, фильтрует по одному параметру, не сохраняет состояние, не работает на мобиле. Команда сделала, что поняла. Продакт хотел вообще другое.

Хорошая постановка — это не бюрократия и не «сейчас распишу на 15 страниц». Это базовый набор: контекст, что должно получиться, критерии, приоритет. Без этих четырёх элементов задача — это лотерея.

Контекст: зачем мы это делаем

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

Что должно быть в контексте:

• Какая боль у пользователя. Не «нам нужен фильтр», а «юзеры тратят много времени на поиск товара в каталоге, конверсия в покупку 1.2%».
• Кто именно болит. Сегмент, объём, важность для бизнеса.
• Какая метрика будет двигаться. Чтобы команда понимала, на что они работают.
• Что уже пробовали и не сработало. Если такая попытка уже была — расскажите.
• Стратегический контекст. Это часть какого квартального ока, какого продуктового направления.

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

Что должно получиться

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

Хорошая структура:

1. Высокоуровневое описание: что делаем, кому показываем, какой ожидаемый эффект.
2. Юзер-стори: «Как [роль], я хочу [действие], чтобы [результат]».
3. Список основных сценариев.
4. Ссылки на дизайн, исследования, данные.
5. Что НЕ входит в скоуп. Это часто важнее того, что входит.

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

Длина задачи — оптимально 1–2 экрана. Если получается 5 страниц — задача слишком крупная, дробите.

Критерии приёмки

Критерии — это то, что отличает «работа сделана» от «работа кажется сделанной». Без критериев QA, разработка и продакт могут понимать готовность по-разному.

Хорошие критерии:

• Проверяемые. Не «должно быть удобно», а «при нажатии на фильтр открывается панель за 200 мс».
• Покрывают негативные сценарии. Что при пустых данных, при ошибке сети, при отсутствии прав.
• Включают аналитику. Какие события уходят, с какими параметрами.
• Учитывают платформы и состояния, если они отличаются.

Шаблон Given-When-Then работает почти всегда:

Дано: пользователь на странице каталога с 100+ товаров.
Когда: он применяет фильтр по цене.
Тогда: показываются только товары в диапазоне, URL обновляется,
       событие filter_applied отправлено в аналитику с параметром тип_фильтра.

Критерии пишет продакт, обсуждает с QA и тимлидом ДО разработки. Не после.

Приоритет и сроки

Каждая задача должна иметь приоритет и понимание срочности. Без этого команда не знает, что брать первым.

Приоритеты обычно делятся на 3–4 уровня:

• P0 / Critical — блокирует бизнес, чинить сейчас.
• P1 / High — важно для квартала, в этом спринте.
• P2 / Medium — нужно, но без жёсткого срока.
• P3 / Low — было бы неплохо, не критично.

Сроки лучше ставить через размер спринтов, а не точные даты: «первый спринт октября», «к концу квартала». Точные даты («к 17-му октября») имеют смысл только для завязок на внешние события — выставка, релиз партнёра, маркетинговая акция.

Что не работает:

• Все задачи P1. Если у вас 80% задач высокого приоритета — у вас нет приоритета.
• Сроки задним числом. «Это нужно было неделю назад» — не аргумент, это плохое планирование.
• Менять приоритеты каждый день. Команда не может работать в режиме «переключайтесь».

Частые ошибки

• Ставить задачу в чате одной строкой. «Поправь шапку» в Slack — это не задача, это разговор. Перенесите в трекер.
• Описывать решение, а не проблему. «Сделай выпадающий список» — лишает команду возможности предложить лучшее решение.
• Менять задачу в середине спринта. Если изменилось — отмените, согласуйте, заведите новую.
• Не указывать аналитику. Фича без событий — слепая фича. Через месяц нечего обсуждать.
• Не указывать платформу. Если работа только на iOS — пишите. Иначе сделают везде, потеряете время.
• Скрывать неуверенность. Если сами не знаете, как должно быть — лучше сказать «давайте обсудим», чем выдумать и потом переделывать.
• Не указывать связанные задачи. Если фича зависит от другой команды — это должно быть видно с первого взгляда.
• Игнорировать оценки. Если разработчик оценил в три недели — серьёзно подумайте, точно ли это нужно сейчас.

Связанные темы

• Как продакту работать с разработчиками
• Как продакту работать с дизайнером
• Как продакту работать с QA
• Как продакту разрешать конфликты в команде

FAQ

Где ставить задачи — в Jira, Linear или Notion?

Зависит от команды. В трекере (Jira/Linear/YouTrack), не в Notion. Notion — для контекста и документов. Если задача в Notion, она потеряется.

Как сформулировать приоритет, если все задачи кажутся важными?

Используйте фреймворки: RICE (reach × impact × confidence / effort), MoSCoW, ICE. Они заставляют сравнивать задачи между собой, а не по абсолютной шкале.

Должен ли продакт писать тест-кейсы?

Нет, это работа QA. Продакт пишет критерии приёмки, QA из них собирает кейсы.

Как часто менять приоритеты?

Обычно раз в спринт на планировании. Внутри спринта — только в форс-мажоре.

Что делать, если стейкхолдер требует срочную задачу вне приоритетов?

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

Как объяснить, почему задача в P3, если стейкхолдеру очень хочется?

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

---

Готовьтесь к собесу на продакта — откройте тренажёр с 1500+ вопросами по аналитике и продукту.