Jira, EvaTeam, Kaiten и другие аналоги — отличное решение для сквозного управления задачами. Но чем больше проект и число стейкхолдеров, тем сильнее чувствуешь нехватку базовой логики таск-менеджеров. Заказчик не понимает, на каком этапе задача, а разработчики — что в приоритете.
Привет! Я Антон Кружевицкий, проджект Далее и деливери одного из крупных проектов компании. В этом кейсе расскажу, как нам удалось настроить процесс в проекте в Jira, чтобы он стал максимально удобным для всех сторон, а таск-трекер сам двигал задачи: от одного ответственного к другому — без вмешательства менеджера.
Дисклеймер: Речь пойдет не про универсальное решение — схема заточена под конкретный проект. Если ваш имеет похожие конфигурации, то забирайте, был рад помочь. Если нет, то алгоритм можно взять как подход и адаптировать его под свои проектные боли.
Мы старались создать максимально прозрачный процесс, где каждому участнику понятны приоритизация и этапы работы. Но базовая настройка таск-менеджеров ограничена и не всегда дает полную картину.
В статье поделюсь нашей самой масштабной доработкой Jira, которую мы делали под специфику развития одного энтерпрайз-проекта, где:
клиент сам заводит и закрывает задачи;
у задач есть альтернативные сценарии движения;
со стороны заказчика 3 стейкхолдера: руководитель, бренд- и delivery-менеджер;
есть прод, стейдж и еще 4 стенда для разработки и тестирования;
релизы 2-3 раза в неделю.
Эволюция workflow: от хаоса к прозрачности
На старте проекта у нас был стандартный workflow (Open → In Progress → Testing → Done), который справлялся со своей задачей, но проект стал так быстро расти и развиваться, что флоу перестал отражать реальную сложность процессов в распределенной команде.
В такой системе задача могла фактически находиться в состоянии «на уточнении у клиента», «ожидает code review», или «развернута на стейдже», но визуально в Jira она оставалась в «In Progress» или «Testing» на протяжении долгого времени. Это создавало «информационный вакуум» — чтобы понять реальный статус выполнения, приходилось либо писать менеджеру/разработчикам в чат, либо вручную открывать каждую задачу и изучать комментарии.
Такой подход порождал:
— постоянные точечные пинги команды
— нулевую видимость блокеров и узких мест
— невозможность прогнозирования сроков
— токсичную культуру микроменеджмента и др.
Мы кардинально переработали workflow, где каждый статус теперь имеет четкие критерии входа/выхода, ответственных и автоматические действия. Создали новые поля, колонки и удобные переходы — с описанием процессов. Это происходило в несколько итераций и в данной статьей расскажем про последнее самое глобальное изменение, которое продолжает улучшаться.
Это дало нам:
✅ полную прозрачность — любой участник команды видит, где "застревают" его задачи;
✅ автоматизацию — уведомления, назначение ревьюверов, переход на тестирование и т.д.;
✅ самоорганизацию — исчезла необходимость постоянного ручного отслеживания
и другие неочевидные плюсы разработки.
Как подойти к проектированию нового процесса
Мы не стали сразу менять весь бизнес-процесс, чтобы его «не травмировать». Сначала определили боли и узкие места проекта, после чего отправился за решениями.
В начале я читал статьи на Хабре, изучал лучшие практики, смотрел, как устроено у нас и у соседних команд. Параллельно консультировался с ребятами из другого проекта Далее и пробовал адаптировать их наработки. Вариант был навороченным, но под наш не подошел.
В итоге мы с командой аккумулировали весь этот опыт, нарисовали схему и написали регламенты. Сейчас они расширены и лежат у нас в Outline Wiki — в открытом доступе для участников проекта. Там расписано: какой статус за что отвечает, какие поля добавлены, какой flow, как тестировать.
Предложили нашу идею бренд-менеджеру клиента и получили одобрение. После чего приступили к детализации и реализации.
Далее я перешел к Jira. Пробовал разные форматы — в том числе табличный вариант. Но он не прижился: не зашел ни клиенту, ни команде. Таблицу оставили только для отслеживания релизных задач. На ней можно сразу увидеть, кто участвует и загруженность каждого специалиста. Например, если на одном QA 6 из 10 проверок, то это сигнал, что нужно перераспределить ресурсы.
Основной же процесс в итоге перенес прямо на канбан таск-менеджера — с автоматизациями, статусами и визуализацией.
Когда клиент заводит задачу, он сразу видит привычную форму Jira — но с доработанными полями. После их заполнения нажимает Create, и карточка появляется на доске. С этого момента она движется по маршруту, который отражает реальный жизненный цикл задачи: от создания — к разработке, тестированию, ревью, стенду и релизу.
Новые поля при заведении задачи
Я был нацелен не только на прозрачность, но и на автоматизацию системы. Чтобы ее настроить и упростить движение задачи, добавили при постановке задачи поля «Разработчик» и «Тестер». Этих специалистов выбирают из списка, и потом на них можно автоматически перенаправлять тикеты.
Одна из самых полезных доработок новой формы — поле «Нужно задокументировать?». Раньше, если по ходу задачи менялась логика или появлялось новое решение, мы могли упустить описание изменения. Теперь, если поставить галочку в этом поле, задача после релиза двигается менеджером в статус Document и автоматом падает на лида аналитиков. Он видит, что нужно обновить Wiki со стороны клиента.
Еще одно важное поле — чекбокс с выбором флага. Он подсвечивает карточку в Jira: красит ее, чтобы было видно, что задача приоритетная.
Эта подсветка решает конкретную проблему, с которой мы столкнулись. Когда все карточки были белые, они ничем не отличались, кроме приоритета — критического, минорного. Но у клиента есть бизнес-задачи, которые влияют на деньги, KPI и ключевые метрики. Они стали подсвечиваться оранжевым — всегда на виду и обрабатываются в первую очередь.
Кастомные статусы с автопереходами
При переносе рабочих процессов я создал длинную цепочку, дополненную новыми статусами: от холда до «баг после QA» или «нужна информация». На первый взгляд кажется: зачем это, если есть обычный In Progress? Но как раз этих промежуточных состояний не хватало для понимания, что реально происходит с задачей.
Ниже — подробно о том, как реализовано нынешнее движение.
In Progress → Need Info
Представим, что я разработчик и взял задачу. Нажимаю Start Progress — все, она ушла в In Progress. Если по задаче появляется вопрос, я могу написать комментарий, упомянуть кого-то и перевести задачу в статус Need Info. Это значит, что ее начали делать, но дальше без уточнения двигаться нельзя. Она не на паузе, но требует ответа от менеджера или другого специалиста команды.
По регламенту ответ по такому вопросу нужно давать в течение 24 часов. Это правило закрывает одно из узких мест, не позволяя задаче долго стоять на месте.
In Progress → For QA
Когда ответ пришел, я нажимаю Reopen и снова перевожу задачу в In Progress. Сделал — хочу отправить на тестирование. И раньше разработчики не знали, куда дальше кидать задачу — на QA, менеджера или просто оставить на себе. Теперь настроена автоматизация: тестер заранее указан, и разработчику достаточно нажать To QA — задача автоматически уйдет на нужного специалиста.
For QA → Bugs After QA / Review Tasks
Тестер смотрит: если все хорошо, то нажимает QA Finished, если нет — QA Failed. При последнем исходе задача возвращается разработчику и попадает в колонку Bugs After QA. По регламенту такие задачи берутся в первую очередь, потому что они уже частично сделаны — осталось только поправить и довести до продакшна.
Когда тестер проверил и все ок, он пишет отчет и при необходимости прикладывает тест-кейс. После этого задача автоматически уходит на Back Review — к нашему тимлиду по бэку.
Тимлид проверяет: есть ошибки в коде или конфликты — нажимает Bug, и задача снова уходит к основному исполнителю. Когда разработчик все пофиксит, он вновь отсылает ее на ревью одним кликом.
Все отлично — бэк-тимлид жмет Review front, и задача идет на проверку фронта. Дальше аналогично и, если нет нареканий, последний выбирает To Merge. Это значит, что все готово к влитию в Stage.
Ready To Merge → Ready To Stage
В To Merge исполнителем становится деливери-менеджер проекта. У него на доске видны все задачи, готовые к выкатке. Он выбирает, какие из них залить в ближайший релиз, и нажимает To QA Stage. Это означает, что задача «влита в стейдж» и автоматически переходит тестеру, который ее курирует. QA должен проверить задачу на Stage.
Ready To Stage → Bugs After QA / Ready To Release → Prod / Final Test
Если специалист находит баг, то возвращает задачу обратно. Она переходит на того же разработчика, кто был указан. Все хорошо — нажимает Release. Тогда задача возвращается менеджеру, и он видит, что можно выкатывать на прод.
Дальше аналогично: To Test Prod, все ок — Resolve. Задача переходит клиенту, и он ее закрывает.
Теперь у нас стало видно все: сколько задач готово к Stage, сколько на ревью, сколько на тестировании или ждут ответа. Прозрачность выросла сильно, а участие менеджера — минимизировано.
Да, статусов много, но когда на проекте постоянная команда и повторяющиеся процессы, становится просто.
Дашборды и аналитика
После того как я выстроил флоу, стало понятно, что нужен инструмент для контроля — чтобы видеть, где задачи буксуют. Для этого настроил фильтры и панель мониторинга, которая показывает:
задачи в статусе Need Info более 24 часов;
задачи, которые висят без движения более 7 дней;
задачи на ревью более 2 дней;
список задач, помеченных как «нужно задокументировать»;
пульс команды за 24 часа и сколько времени на эти задачи потрачено.
Дашборд подсвечивает узкие места, и по регламенту мы обязаны отвечать в течение суток на задачи в Need Info. Я несколько раз в неделю делаю quick research — пробегаюсь по таблицам и смотрю, где что зависло. Если что-то заполнено неправильно, то иду к клиенту или команде, чтобы помочь. Раньше я это делал чаще, сейчас все уже привыкли и ошибок стало меньше.
Если что-то забыл, то можно обратиться к регламентам и узнать: как заполнять поля, кто за что отвечает, в каком порядке брать задачи.
Эффект от новой системы
Инструкции я презентовал команде еще до внедрения в Jira, проводил демо-дни и объяснял, как пользоваться новыми статусами. После релиза был этап притирки — где-то 1-1,5 месяца мы вносили мелкие правки по обратной связи команды и клиентов. Сейчас система стабильна.
Когда мы внедрили новый флоу, то по сравнению с предыдущим кварталом стало видно:
доля багов снизилась на 49%;
число решенных задач с типом «bug» выросло;
задачи выполняют быстрее на 20-30%;
Time to Market сократился на 50%;
процессы стали прозрачнее и для клиента, и для команды.
Несмотря на высокую частотность релизов на проекте — по 2-3 раза в неделю — статистика подтверждает устойчивую положительную динамику в качестве работы. Этот результат обеспечен внедренным workflow, усилением команды тестирования и новыми строгими регламентами. Совокупность этих мер уменьшила количество параллельно выполняемых задач и ускорила их жизненный цикл.
Клиент понимает, где находятся задачи и почему они двигаются или стоят. Менеджерам стало проще — отпала необходимость вручную перекидывать карточки между исполнителями, все делает автоматизация.
Я вижу, что раньше задачи на проекте могли замереть: кто-то не ответил, не перевел статус, не закрыл — и все, тикет висит. Теперь есть дашборд, который все подсвечивает.
Фактически мы идем к системе, которая сама себя контролирует.
Немного статистических данных:
Влияние на процессы: Внедренный в августе новый флоу позволил сократить Time to Market (время от создания задачи до ее закрытия) на ~56% по сравнению с показателями I квартала (февраль-апрель) и ~50% II квартала (май-июль) кварталов.
Итог: Совокупность этих мер привела к уменьшению количества параллельно выполняемых задач и ускорению их жизненного цикла.
Снижение количества багов в проде.
По сравнению со II кварталом доля багов сократилась примерно на 49%, что свидетельствует о значительном улучшении.
По сравнению с I кварталом снижение составило 27.5%, подтверждая устойчивую положительную динамику в качестве выпускаемого кода.
На основании данных можно сделать вывод, что бешеный ритм релизов (два-три раза в неделю) не привел к снижению качества — этот результат обеспечен внедренным workflow, усиления команды тестирования и новыми строгими регламентами.
Рекомендации для других проектов
Во-первых, нужно проанализировать боли конкретного проекта. Не берите готовую схему и не пытайтесь сразу натянуть ее на свой процесс. Изучите, где реально теряются задачи и стопорится работа.
Во-вторых — нарисуйте свою карту переходов статусов. Прямо на бумаге — как двигается задача от момента создания до релиза, кто за что отвечает, на каких шагах может застревать. И уже под это — пропишите регламенты.
Дальше — настройте дашборды, которые показывают узкие места. Например, задачи без движения более 7 дней или те, что висят в Need Info больше суток. Это сильно помогает держать процесс под контролем.
Обязательно стоит автоматизировать переход задач между ролями — через поля «разработчик», «тестер» или актуальные для вас. Это снимет лишние действия с менеджеров и уменьшит время простоя.
После этого протестируйте флоу хотя бы месяц — посмотрите, где реально работает, а где мешает. Соберите обратную связь от команды и клиентов, чтобы улучшить систему.
Не забывайте и про финансовые процессы — учитывайте этот момент на этапе создания флоу, чтобы потом не уткнуться в блокеры. Например, у нас выставление счетов напрямую связано с закрытием задач клиентом. Но есть доработки, которые вносит в документацию аналитик со стороны заказчика. В ранней итерации системы я этого не учел. Мы просто ждали, не имея возможности повлиять на внешнего специалиста. Позже — убрал этот шаг и сделал финальным этапом фактическую реализацию функционала.
В целом все. Система получилась рабочая, живая, не требует постоянного ручного вмешательства. Я вижу по людям, что им удобно, и это для меня главный показатель, что все сделано правильно.
Главное — не копировать схему бездумно. Любая Jira-процессия должна решать конкретные боли именно вашего проекта.
Делитесь в комментариях своими решениями по кастомизации таск-менеджера. В каком работает ваша команда и какие особенности есть у проектов?
