В ИТ «проект» часто стал означать не временную инициативу, а постоянное направление или продукт. А то, что раньше называли проектом — большую ограниченную по смыслу работу с результатом — внутри Agile начали называть эпиком.
В ИТ (особенно в Agile/Scrum) «Проект», «Эпик» и «Задача» — это уровни декомпозиции работы. Которые могут удивить тех кто знаком с классическими понятиями из старых индустриальных практик, и первых версий PMBoK.
В мире ИТ эти понятия в основном помогают структурировать большие инициативы и распределять работу по направлениям, определить ответственность по исполнителям.
Проект (рабочая группа)
Проект — это контейнер для всей работы по направлению (отделу, продукту, большой инициативе и т. д.). В нём живут эпики, задачи, баги, спринты и т. д.
То что сегодня в ИТ называют Проектом — раньше называлось направлением, подразделением, рабочей группой или командой.
Что характерно:
- может состоять из нескольких под проектов — Эпиков;
- часто соответствует отдельному продукту, сайту, сервису или интеграции.
Пример: «Проект: редизайн сайта» — в нём будет всё, что касается редизайна: аналитика, макеты, верстка, бэкенд, тестирование, запуск.
Эпик (Epic)
Эпик — это крупная пользовательская цель или большая функциональность, которую нельзя сделать за один подход или итерацию, но надо уложить в сроки. Эпик разбивают на задачи.
Для знатоков традиционной терминологии тут может быть взрыв мозга — потому что именно это понятие раньше и считалось Проектом )
Что характерно:
- формулируется в терминах ценности для пользователя/бизнеса;
- срок обычно называется — 1-2 месяца или 3-4 квартал года (реже через точную дату)
- в трекере может иметь свою оценку и приоритет.
Примеры:
- «Эпик: личный кабинет пользователя на сайте 2026»;
- «Эпик: интеграция с CRM».
Внутри эпика будут десятки задач: «сделать форму регистрации», «добавить историю заказов», «настроить вебхуки в CRM» и т. п.
Задача (Task)
Задача — это конкретная, понятная, атомарная работа, которую можно оценить и выполнить за относительно короткое время (1-2 дня, 1-2 недели, иногда даже до 1 месяца тоже считаются задачами).
Что характерно:
- чёткое описание: «что сделать», критерии готовности (DoD), иногда оценка в часах/сторипоинтах;
- у задачи есть исполнитель и желательно оценка;
- задача не должна быть «большой идеей» — она про действие.
Примеры задач:
- «Настроить редиректы 301 для старых URL в Bitrix»;
- «Добавить валидацию поля email на форме регистрации (JS + бэкенд)»;
- «Написать автотест для страницы корзины».
Как они связаны между собой
Иерархия обычно такая:
Проект → Эпик → Задача.
В реальной работе это выглядит так:
- Есть проект «Редизайн сайта».
- В нём есть эпик «Корзина и оформление заказа».
- Внутри эпика — задачи: «верстка корзины», «логика расчёта скидки», «интеграция с платёжным шлюзом», «тесты корзины».
Нюансы и частые ошибки
- Не делать «эпиком» всё подряд. Если эпик можно сделать за 1–2 дня, это, скорее всего, просто задача.
- Задача не должна быть расплывчатой. «Сделать корзину» — это не задача, а мини‑эпик. Задача: «реализовать отображение списка товаров в корзине (фронт + API)».
- Разные команды могут по‑разному трактовать термины. В Jira «Story» (пользовательская история) часто ставят между эпиком и задачей, но суть иерархии остаётся той же: от крупного к мелкому.
Почему так получилось что в мире ИТ направления начали называть проектами, а проекты эпиками?
Так получилось из-за смешения двух разных традиций управления: классического проектного менеджмента и Agile/IT-практик.
В классическом управлении проект — это временная инициатива с понятной целью, сроком, бюджетом и результатом. Например: «внедрить CRM», «запустить новый сайт», «построить складскую систему». Проект начинается, выполняется и заканчивается.
Но в ИТ многие продукты и системы не заканчиваются. Сайт, CRM, личный кабинет, мобильное приложение или внутренняя платформа постоянно развиваются: появляются новые функции, баги, интеграции, улучшения, технический долг. Поэтому командам понадобился постоянный контейнер для всей работы по продукту или направлению.
Так в трекерах вроде Jira, YouTrack, Linear и других слово «проект» стало использоваться не столько как «временная инициатива», сколько как рабочее пространство команды или продукта. То есть «Проект: сайт компании» может существовать годами, хотя внутри него будут десятки настоящих проектов в классическом смысле.
А для крупных временных инициатив внутри такого постоянного «проекта» понадобился другой термин. В Agile для этого закрепилось слово эпик.
Эпик стал обозначать большую цель или крупную функциональность, которую нельзя сделать одной задачей: «новый личный кабинет», «интеграция с CRM», «редизайн корзины», «переезд на новую архитектуру». По сути, во многих случаях эпик — это именно то, что в классическом менеджменте назвали бы проектом.
Получилась такая подмена терминов:
- Проект в классическом смысле → временная инициатива с результатом.
- Проект в ИТ-трекере → постоянное направление, продукт или рабочее пространство.
- Эпик в ИТ → большая инициатива внутри проекта, часто аналог классического проекта.
- Задача → конкретная работа, которую можно взять в исполнение.
Главная причина — ИТ перешёл от логики «сделали проект и завершили» к логике постоянного развития продукта. Поэтому «проект» стал контейнером для непрерывной работы, а «эпик» — контейнером для крупных изменений внутри этой работы.
Отдельный фрактал — это название должностей и ролей
Появились разного типа Руководители ИТ проектов, Руководители продуктов, Продуктовнеры, Деливери менеджеры, Аккаунт менеджеры, Скрам мастеры и т. д.
По факту это создает размытие ответственности и ведет к дезорганизации (иногда даже к колоссальному хаосу).
По сути если брать любую мини команду от 3 до 9 человек, то там просто должно быть 3 роли:
- дискавери лид
- тот кто отвечает за бизнес направления и приоритеты
- должности могут называться по разному — руководитель проекта, руководитель продукта, продуктовнер, аналитик или даже иногда старший разработчик
- тут человек в основном общается с бизнесом, заготовкой спецификаций, согласованием планов и ожиданий, может коорденировать несколько команд согласно паровозу ценности
- деливери лид
- тот кто отвечает за реализацию и результаты
- запланированные эпики должны доехать в прод согласно дорожной карте
- должности также могут зваться по разному: тех лид, тим лид, скрам мастер, деливери менеджер и т д
- ключевая фишка — это уметь видеть и убирать блокеры на пути команды — и тогда команда становится максимально продуктивной — функция деливери выходит на максимум
- тим лид
- в зависимости от особенностей команды — кто то должен взять ответственность за всю команду и ее результаты в целом, а также право последнего слова
- в каких то командах роль тим лида берет на себя деливери лид, но иногда это может быть и дискавери лид, а деливери лид фокусируется на технических аспектах (в таких командах часто звучит термин — тех лид)
Отдельно еще бывает роль — элайнмент лид — это если есть некий проектный офис, который в целом отвечает за весь портфель направлений. То от этого офиса должен быть кто то, кто курирует команду и помогает ей оставаться согласованной со всем портфелем проектов (направлений).
Выводы
В ИТ термины «проект», «эпик» и «задача» часто используются иначе, чем в классическом менеджменте. Проект в трекере обычно означает постоянное рабочее пространство команды или продукта, эпик — крупную инициативу внутри этого пространства, а задача — конкретную выполнимую работу. Главная практическая польза такой иерархии — снизить хаос, договориться о масштабе работ и закрепить зоны ответственности.
Ключевые идеи
- «Проект» в ИТ-трекере = рабочее пространство, продукт или постоянное направление. «Проект» в классическом менеджменте = временная инициатива с конкретным результатом.
- «Эпик» = крупная цель или функциональность, которую нужно разбить на задачи.
- «Задача» = конкретное действие с понятными критериями готовности.
- Базовая иерархия: Проект → Эпик → Задача.
- Если «эпик» можно сделать за 1–2 дня, это, скорее всего, задача.
- Если формулировка расплывчата вроде «сделать корзину», её нужно дробить на конкретные задачи.
- Одинаковые слова в разных командах могут означать разное, поэтому важно заранее договориться о словаре.
- Путаница терминов и ролей приводит к размытию ответственности.
- Мини-команде обычно достаточно трёх зон ответственности: discovery, delivery и team leadership.
- Когда продукт постоянно развивается и «не заканчивается», команде нужен постоянный контейнер для работы — отсюда и появляется подмена терминов.
