За последние 8 лет я настроил и оптимизировал workflow в десятках Jira-инстансов. Видел и простые процессы из трёх статусов, и сложные с 20+ переходами. Опыт показал: большинство проблем с workflow возникают не из-за сложности бизнес-процессов, а из-за типичных ошибок в конфигурации. В этой статье разберу, как избежать этих ошибок.
Почему workflow становятся проблемой
Workflow в Jira — это не просто набор статусов и переходов. Это отражение бизнес-процессов, и когда процессы меняются, workflow должен меняться вместе с ними. Часто этого не происходит, и в результате накапливается технический долг.
Я видел инстансы, где за 5 лет работы накопилось 47 разных workflow схем, многие из которых были созданы "на скорую руку" и потом забыты. В результате найти нужный workflow или понять, как работает процесс, становится практически невозможно.
Типичная ситуация: workflow-спагетти
На одном проекте я столкнулся с workflow, который имел 18 статусов и 42 перехода. При этом использовался он всего в одном проекте с 50 активными задачами. Пользователи постоянно путались, какие переходы использовать, администраторы не могли понять логику процесса.
После анализа выяснилось, что изначально workflow был простым (5 статусов), но за два года в него добавляли новые статусы "на всякий случай", не удаляя старые. В результате получилась каша, которую пришлось полностью переделывать.
Принципы проектирования workflow
Есть несколько принципов, которые я всегда соблюдаю при проектировании workflow. Они помогают избежать большинства проблем.
Принцип 1: Минимум статусов, максимум ясности
Каждый статус должен иметь чёткое значение и использоваться в реальном процессе. Если статус существует "на всякий случай" — удалите его. Если два статуса означают примерно одно и то же — объедините их.
В большинстве случаев достаточно 4-6 статусов:
- To Do — задача создана, но не начата
- In Progress — работа ведётся
- In Review — на проверке (опционально)
- Done — выполнено
Дополнительные статусы добавляйте только если они реально нужны для отчётности, автоматизации или разделения ответственности.
Принцип 2: Понятные названия
Названия статусов должны быть понятны любому пользователю без дополнительных объяснений. Избегайте аббревиатур, технических терминов и внутреннего жаргона.
Плохо: "DEV_IN_PROG", "QA_PENDING", "PM_REVIEW"
Хорошо: "В разработке", "На проверке", "На согласовании"
Принцип 3: Логичная структура переходов
Переходы должны отражать реальный процесс. Если в реальности нельзя перейти из статуса A в статус C минуя B, то и в workflow этого быть не должно (если только это не специальный переход для исправления ошибок).
Избегайте "перекрёстных" переходов между статусами, которые не связаны логически. Это путает пользователей и усложняет поддержку.
Типичные ошибки и как их избежать
За годы работы я собрал коллекцию ошибок, которые повторяются снова и снова. Вот самые частые.
Ошибка 1: Слишком много переходов из одного статуса
Если из статуса "In Progress" можно перейти в 8 разных статусов, пользователи будут путаться. Ограничьте количество переходов из каждого статуса до 2-4 максимум.
Если логически нужно больше переходов, возможно, стоит пересмотреть структуру статусов. Иногда лучше разделить один статус на несколько, чем создавать множество переходов.
Ошибка 2: Отсутствие валидаторов
Валидаторы — это правила, которые проверяют возможность перехода. Например, нельзя перевести задачу в "Done", если не заполнено обязательное поле "Решение".
Без валидаторов пользователи могут переводить задачи в неправильные статусы, пропуская обязательные шаги процесса. Это приводит к проблемам с отчётностью и контролем качества.
Всегда добавляйте валидаторы на критичных переходах. Особенно важны проверки обязательных полей при переводе в финальные статусы.
Ошибка 3: Игнорирование постов-функций
Пост-функции автоматически выполняют действия при переходе: назначают исполнителя, обновляют поля, отправляют уведомления. Правильно настроенные посты-функции значительно упрощают работу пользователей.
Например, при переводе задачи в статус "In Review" можно автоматически назначить её на конкретного ревьюера или группу. При переводе в "Done" — автоматически заполнить поле "Дата завершения".
Ошибка 4: Отсутствие переходов для отката
В реальной жизни часто нужно вернуть задачу в предыдущий статус. Если в workflow нет таких переходов, пользователи либо будут просить администраторов делать это вручную, либо просто создавать новые задачи.
Добавьте переходы типа "Reopen" или "Return to Previous Status" для основных статусов. Можно ограничить их правами доступа, чтобы использовать их могли только определённые роли.
Работа с условными переходами
Условные переходы — мощный инструмент, который позволяет показывать разные переходы в зависимости от условий. Но использовать их нужно аккуратно.
Когда использовать условия
Условия полезны, когда:
- Нужно показывать разные переходы для разных типов задач (например, баг vs задача)
- Переход доступен только для определённых проектов
- Нужно скрыть технические переходы от обычных пользователей
Не используйте условия просто для того, чтобы сократить количество переходов в интерфейсе. Если логика сложная, лучше создать отдельные workflow схемы.
Пример: условный переход для разных типов задач
Допустим, у вас есть workflow, где баги должны проходить дополнительный статус "На тестировании", а обычные задачи — нет. Можно создать два перехода из "In Progress":
- "Отправить на тестирование" — условие: тип задачи = Bug, переход в "Testing"
- "Готово к ревью" — условие: тип задачи ≠ Bug, переход в "Review"
Но лучше использовать один переход с условием на стороне пост-функции, чтобы не усложнять интерфейс.
Workflow для разных типов проектов
Разные типы проектов требуют разных подходов к workflow.
Scrum проекты
Для Scrum обычно достаточно простого workflow: To Do → In Progress → Done. Дополнительные статусы типа "In Review" или "Blocked" можно добавить, но они не обязательны.
Важно: в Scrum workflow должен быть одинаковым для всех типов задач. Не создавайте отдельные workflow для Story, Bug, Task — это усложнит отчётность и планирование.
Kanban проекты
В Kanban workflow должен отражать реальные этапы работы команды. Обычно это доска с колонками, где каждая колонка — статус в workflow.
Особенность Kanban: ограничения WIP (Work In Progress). В Jira это можно настроить через настройки доски, но важно, чтобы статусы в workflow соответствовали колонкам доски.
Проекты с согласованиями
Если в процессе есть этапы согласования, создайте отдельные статусы для них: "На согласовании у менеджера", "На согласовании у клиента" и т.д.
Используйте валидаторы, чтобы нельзя было перейти дальше без одобрения. Настройте уведомления, чтобы согласующие знали о новых запросах.
Миграция и обновление workflow
Рано или поздно workflow нужно будет изменить. Это критичная операция, которую нужно выполнять очень осторожно.
Подготовка к изменению
Перед изменением workflow:
- Создайте резервную копию текущей схемы
- Протестируйте изменения на тестовом проекте
- Убедитесь, что все переходы имеют валидаторы и пост-функции
- Подготовьте инструкцию для пользователей, если процесс значительно изменился
Работа с активными задачами
При изменении workflow задачи, которые находятся в статусах, изменённых или удалённых, могут оказаться в невалидном состоянии. Jira попытается автоматически перевести их, но лучше сделать это вручную заранее.
Используйте JQL для поиска задач в проблемных статусах:
project = PROJ AND status IN ("Старый статус 1", "Старый статус 2")Затем массово переведите их в новые статусы через Bulk Operations.
Автоматизация через workflow
Workflow может быть точкой входа для автоматизации. Но не перегружайте его сложной логикой.
Что можно автоматизировать
- Назначение исполнителей — на основе полей, групп, ротации
- Обновление полей — автоматическое заполнение дат, приоритетов
- Создание связанных задач — например, создание подзадачи при переходе в статус
- Уведомления — отправка email, создание комментариев
Что лучше делать вне workflow
Сложную логику (например, расчёт SLA, сложные проверки, интеграции с внешними системами) лучше выносить в ScriptRunner или другие инструменты автоматизации. Workflow должен оставаться простым и понятным.
Мониторинг и оптимизация
После настройки workflow важно отслеживать, как он работает на практике.
Метрики для отслеживания
- Время в каждом статусе — помогает найти узкие места
- Частота использования переходов — неиспользуемые переходы можно удалить
- Количество задач в каждом статусе — показывает загрузку команды
- Частота откатов — если задачи часто возвращаются, возможно, процесс неправильный
Используйте встроенные отчёты Jira (например, "Time in Status") или создавайте кастомные через JQL и аналитику.
Выводы
Хороший workflow — это баланс между простотой и функциональностью. Начинайте с простого, добавляйте сложность только когда это действительно необходимо.
Помните: workflow должен служить процессу, а не наоборот. Если процесс не работает, не пытайтесь "починить" его через workflow — измените процесс.
Регулярно ревьюируйте workflow: удаляйте неиспользуемые статусы и переходы, упрощайте логику, собирайте обратную связь от пользователей.
Если нужна помощь с настройкой или оптимизацией workflow — обращайтесь.