Многие функции застревают ещё до разработки: проблема описана расплывчато, решение выбрано слишком рано, а команда понимает задачу по-разному. Процесс «Идея → PRD → Dev Kickoff» помогает согласовать проблему, ожидаемый результат и границы работы до того, как задача попадёт в разработку.

Содержание

  1. Целевое состояние процесса
  2. Фаза 1. Идея
  3. Фаза 2. PRD
  4. Фаза 3. Рабочая сессия перед разработкой (Dev Kickoff)
  5. Чеклист быстрой проверки
  6. Частые ошибки
  7. Как адаптировать процесс под команду
  8. Эталонный шаблон
  9. Источники

Целевое состояние процесса

К началу разработки команда должна одинаково понимать:

  • какую пользовательскую проблему она решает;
  • для кого эта проблема существенна;
  • почему работу имеет смысл делать сейчас;
  • по каким признакам будет оцениваться результат;
  • что входит в текущий объём, а что остаётся за его пределами;
  • какие вопросы, ограничения и риски ещё открыты;
  • кто отвечает за следующие действия.
flowchart LR
    A[Проблема или возможность] --> B[Краткое описание проблемы и возможности]
    B --> C{Идея готова к PRD?}
    C -->|Нет| D[Отложить или уточнить]
    C -->|Да| E[PRD]
    E --> F[Dev Kickoff]
    F --> G{Команда готова начать?}
    G -->|Нет| H[Закрыть вопросы и риски]
    H --> F
    G -->|Да| I[Работа в разработке]

Фазу завершает готовый артефакт и согласованность команды. Само проведение встречи ещё не означает готовности.

Фаза 1. Идея

Идея — гипотеза о способе решить проблему или использовать возможность. В официальной документации Atlassian о типах идей, проверенной 8 сентября 2026 года, Jira Product Discovery описывает идею как единицу работы. В системе можно создавать типы идей, например пользовательскую проблему, возможность или решение. К идее можно добавить поля для целей, команды, приоритета и влияния, связать идеи между собой и прикрепить подтверждающие материалы, например заметки интервью или обращения в поддержку.

Перед детализацией решения ответьте на четыре вопроса:

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

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

Результат фазы: короткий документ с формулировкой проблемы и возможности (opportunity brief) объёмом примерно в полстраницы.

Критерий перехода: проблема и целевая аудитория описаны, ценность работы понятна, а идея получила решение о дальнейшей проработке. В Jira Product Discovery идеи связывают с рабочими элементами Jira, когда инженерная команда готова активно работать над ними.

Фаза 2. PRD

Документ с продуктовыми требованиями (PRD, Product Requirements Document) фиксирует, что нужно получить, для кого и зачем. Техническое решение команда обсуждает совместно; если деталей много, их можно вынести в отдельный технический документ.

Минимальная структура PRD

  • Контекст: проблема, аудитория, доказательства и связь с целью.
  • Цели и метрики успеха: ожидаемый результат и способ измерения.
  • Что не является целью: результаты, которых команда не пытается достичь этой работой.
  • Пользовательские сценарии: основные действия пользователя и ожидаемый результат.
  • Требования: обязательное поведение продукта и значимые нефункциональные ограничения.
  • Границы текущей версии: что входит в объём и что явно остаётся за его пределами.
  • Открытые вопросы: неизвестные, предположения и решения, которые ещё нужно принять.
  • Риски и зависимости: технические, продуктовые, организационные и внешние ограничения.

В сценарии Atlassian для встречи перед разработкой функции (feature kick-off), проверенном 8 сентября 2026 года, рекомендуется заранее подготовить проработанную концепцию, пользовательский путь и предварительное понимание показателей успеха. Спецификация при этом остаётся открытой для изменений после обратной связи команды.

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

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

Подробный разбор документа: PRD — что это и как его правильно писать.

Фаза 3. Рабочая сессия перед разработкой (Dev Kickoff)

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

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

Что подготовить заранее

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

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

Повестка встречи

  1. Контекст и цель. Автор задачи объясняет проблему, аудиторию, ценность и связь с более широкой целью.
  2. Проверка общего понимания. Участники формулируют, что должна дать функция и чего они опасаются.
  3. Разбор пользовательского пути. Команда проходит сценарий от начала до конца и отмечает пробелы.
  4. Критика и альтернативы. Участники обсуждают ограничения, способы отказа, вопросы безопасности, удобства и технической реализуемости.
  5. Решения и дальнейшие действия. Команда фиксирует принятые решения, владельцев открытых вопросов и сроки ответа.

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

Что должно остаться после встречи

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

Чеклист быстрой проверки

Перед передачей задачи в разработку проверьте:

Проблема описана через наблюдаемое поведение или результат.
Указана конкретная аудитория.
Есть подтверждающие данные или честно обозначено их отсутствие.
Понятна связь работы с целью, риском или метрикой.
Успех можно проверить после выпуска.
Пользовательский сценарий описан от начала до результата.
Границы текущей версии зафиксированы.
То, что команда сознательно не делает, перечислено отдельно.
Значимые ограничения, зависимости и риски записаны.
Открытые вопросы видны всем участникам.
У каждого незакрытого вопроса есть владелец и срок.
Команда понимает критерии завершения работы.
Решение о переходе в разработку принято явно.

Если на несколько пунктов нельзя ответить уверенно, задачу лучше вернуть на уточнение.

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

Решение появляется раньше проблемы

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

PRD пишется в одиночку и передаётся как приказ

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

Открытые вопросы прячут ради быстрого старта

Неизвестное допустимо. Опасно оставлять его без записи, владельца и срока ответа. Atlassian рекомендует фиксировать вопросы и решения письменно, а неотвеченные вопросы назначать конкретным участникам.

Kickoff превращается в презентацию

Последовательный пересказ PRD без обратной связи не проверяет понимание. Оставьте время на критику пользовательского пути и альтернативные решения.

Документ разрастается без пользы

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

Срок называют до обсуждения рисков

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

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

  • Команда из 1–3 человек: opportunity brief и одностраничный PRD; kickoff можно провести в переписке с явной фиксацией решений.
  • Команда из 3–10 человек: единый PRD со ссылками на дизайн, аналитику и пользовательские данные; отдельная сессия для спорных вопросов.
  • Большая или распределённая команда: заранее опубликованные материалы, отдельная повестка, запись решений и назначенные владельцы вопросов. Для участников из разных часовых поясов предусмотрите асинхронную обратную связь.

Адаптируйте длительность и формат, сохраняя общий контекст, возможность обратной связи и письменную фиксацию решений.

Эталонный шаблон

# Название инициативы

## Идея
- Проблема:
- Целевая аудитория:
- Подтверждающие данные:
- Почему сейчас:
- Ожидаемый результат:

## PRD
### Контекст

### Цели и метрики успеха

### Что не является целью

### Пользовательские сценарии

### Требования

### Границы текущей версии

### Риски и зависимости

### Открытые вопросы
- Вопрос:
- Владелец:
- Срок ответа:

## Dev Kickoff
- Участники:
- Принятые решения:
- Отклонённые альтернативы:
- Изменения в объёме:
- Критерии завершения:
- Следующие действия:
- Решение о переходе в разработку:

Источники

Следующий шаг

Если нужно перейти от процесса к конкретной структуре документа, изучите PRD — что это и как его правильно писать.

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

Если захотите обсудить, как это применить у себя или в команде — пишите в Telegram @pimenov