Проектирование и оценка
Эпик, фича, user story, workstream и задача: как не смешивать уровни планирования
Создано 19.07.2026
Обновлено 19.07.2026
Как различать roadmap, epic, feature, user story, workstream и backlog task: где планирование, где направление работ, а где исполнимая задача.
Короткий ответ
Epic, feature, user story, workstream и задача — это разные уровни планирования. Они помогают не смешивать крупную цель, способность продукта, поток работ и конкретное поручение исполнителю.
Практическое правило простое: чем ближе запись к разработке, тем яснее должны быть результат, владелец, границы и способ проверки. Если этого нет, запись еще не стала задачей.
Почему уровни смешиваются
Путаница появляется, когда в один backlog попадают идеи, требования, крупные этапы, дефекты, change request и технические работы. Формально все они могут быть записями в трекере, но управлять ими нужно по-разному.
Если крупный блок назвать задачей, исполнитель получает слишком широкий контекст без понятного рабочего шага. Если маленькую задачу назвать epic, команда теряет скорость и спорит о приоритете вместо результата.
Карта уровней: roadmap -> epic -> feature -> workstream -> task
Эта карта нужна не для соблюдения терминологии, а для управляемости. Она помогает понять, где сейчас находится запись и что нужно уточнить перед разработкой.
| Слой | Главный вопрос | Владелец | Что не писать туда | Следующий слой |
|---|---|---|---|---|
| Roadmap | Что идет в каком порядке и на каком горизонте? | Владелец продукта, проекта или направления. | Каждую техническую задачу и каждое внутреннее действие. | Epic или крупный блок работ. |
| Epic / крупный блок | Какой большой результат нужно получить? | Владелец результата или области поставки. | Детальный список файлов, методов и мелких исправлений. | Feature, capability или workstream. |
| Feature / capability | Что система или продукт должны уметь? | Владелец продуктового поведения или сценария. | Случайную реализацию без пользовательского или системного результата. | User story или backlog task. |
| User story | Какой сценарий нужен пользователю или роли? | Владелец сценария и приемки. | Весь roadmap или технический план команды. | Одна или несколько задач. |
| Workstream / направление работ | Какой поток связанных работ нужно вести отдельно? | Владелец направления или контура. | Один общий тикет без границ и следующего шага. | Задачи внутри направления. |
| Backlog task | Что открыть, что изменить и как проверить? | Исполнитель и reviewer. | Дальний план, неразобранные идеи и общий audit dump. | Выполнение и приемка. |
Чем отличаются epic, feature, user story, workstream и task
Epic объединяет крупный результат. Он может включать несколько возможностей, этапов или направлений работ.
Feature или capability описывает способность продукта или системы: что должно стать возможным после изменений.
User story описывает сценарий роли или пользователя. Она полезна, когда важно зафиксировать, кто получает результат и зачем.
Workstream или направление работ группирует связанные задачи по владельцу, контуру, стадии или типу работ.
Task — исполнимая единица работы. В ней уже должны быть рабочий объект, ожидаемое изменение, границы и способ проверки.
Когда крупный пункт еще не готов стать задачей
Запись еще не готова как задача, если по ней нельзя ответить, что открыть, что изменить и как проверить результат. Это не ошибка backlog: значит, запись пока находится на более верхнем уровне.
- Если есть только цель или этап, это roadmap или epic.
- Если понятно поведение продукта, но не выделены рабочие шаги, это feature или capability.
- Если есть поток связанных работ, но нет конкретного следующего результата, это workstream.
- Если есть конкретный рабочий объект, ожидаемое изменение и проверка, это backlog task.
Как связать уровень с владельцем и приемкой
У каждого уровня должен быть свой владелец смысла и свой способ проверки. У roadmap проверяют актуальность направления и очередность. У epic — достижение крупного результата. У feature — поведение продукта или системы. У задачи — конкретный outcome.
Если владелец и приемка не определены, запись лучше не отдавать в разработку. Сначала нужно уточнить источник, границы, зависимости и следующий проверяемый шаг.
Пример декомпозиции
Допустим, команда хочет запустить личный кабинет для клиентов.
| Уровень | Пример записи | Что уточнить дальше |
|---|---|---|
| Roadmap | Запуск клиентского самообслуживания во втором этапе проекта. | Какие крупные блоки входят в этап. |
| Epic | Личный кабинет клиента. | Какие возможности нужны для первого результата. |
| Feature | Клиент видит статус заявки и историю обращений. | Какие сценарии и данные нужны для проверки. |
| Workstream | Интеграция статусов заявок из внутренней системы. | Какие задачи нужны по API, данным и ошибкам. |
| Task | Показать статус заявки на экране карточки обращения и проверить ответ API. | Что открыть, что изменить, какие критерии приемки применить. |
Типовые ошибки
- Называть epic задачей. Исполнитель получает большой замысел, но не понимает следующий рабочий шаг.
- Называть задачу feature. Небольшое изменение начинает выглядеть как продуктовая способность и теряет ясную приемку.
- Делать workstream без владельца. Направление работ превращается в общий список без ответственности.
- Закрывать крупный блок без критериев. Если не понятно, что считать результатом, закрытие будет спорным.
- Смешивать source и поручение. Источник решения нужен, но первый экран задачи должен оставаться рабочим.
Что дальше
Если нужно написать конкретную задачу исполнителю, откройте страницу как ставить задачи разработчикам. Если нужно вести очередь работ, используйте backlog задач. Для проверки результата отдельно посмотрите критерии приемки задачи.
Обсудить проект
Если хотите применить этот материал к вашему проекту, напишите нам. Поможем уточнить вводные, риски и следующий шаг: оценку, discovery, разработку, интеграцию или сопровождение.
СвязатьсяПредыдущая
Backlog задачСледующая
Roadmap проекта из требованийВ этой статье
