Jira Workflow: настройка рабочих процессов — сценарии достижения целей бизнеса

Мы уже разобрали главную сущность Jira Software Atlassian — Issue и рассмотрели различные типы задач (тикетов, тасков). В статье рассказываем о настройке рабочих процессов Jira Workflow. Если правильно выстроить сценарии достижения цели, все этапы работы бизнеса становятся прозрачными и предсказуемыми.

Почему это важно
Компоненты Workflow
— Статусы
— Переходы
— Исполнитель
— Решения
Распространенные ошибки
Как выстроить работу
— Упростите процесс
— Настройте переходы
— Условия
— Валидаторы
— Постфункции
— Свойства
Как не запутаться в компонентах
Как настроить статусы

Почему для бизнеса важна настройка рабочих процессов

Любая цель становится результатом какого-либо процесса. Любой такой процесс в подавляющем большинстве случаев состоит из последовательности шагов: подготовки, планирования, принятия окончательного решения о реализации или отмене идеи. Финальные шаги обычно — воплощение идеи в жизнь и наслаждение результатом.

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

Если мы заказываем посылку, можем отслеживать все статусы ее доставки: с главного склада в региональный, затем в наш город, район и, наконец, в местный пункт выдачи. Все происходит наглядно в режиме онлайн. Мы видим, где посылка и что с ней. Это называется статусом, то есть состоянием на данный момент. Поэтому не обрываем телефоны службы поддержки, уточняя, долго ли еще ждать и не потерялся ли наш заказ.

Как видите, все процессы состоят из статусов. Они позволяют нам ориентироваться, сколько еще ждать результат, не задавая этот вопрос каждый час.

Информацию о состоянии дел в компании можно очень быстро передавать всем заинтересованным лицам. Для этого нужно формализовать, визуализировать и выделить основные поворотные точки в процессах: рабочих, технологических, финансовых и т.д. Это решает сразу несколько частых проблем:

1. Каждый знает свое место и задачу в процессе в контексте других этапов производства. Исполнитель четко видит, после какого этапа продукт поступает к нему, что он должен делать на своем этапе и что будут делать с его продуктом дальше.
2. Информация о том, что закончен один этап и пора начинать следующий, транслируется всей команде, а не изолирована только между двумя людьми (руководителем и исполнителем). Не нужно дозваниваться, писать личные мейлы или просить кого-то передать исполнителю, что пора браться за работу. Достаточно озвучить новый статус в общем рабочем пространстве (доске в таск-трекере, общей табличке в Google Docs и т.д.).
3. При ретроспективном анализе всегда можно обнаружить проблемное место в процессе. При оптимизации бросить все силы не наугад, а именно туда, где это действительно требуется.

Визуализировать процессы помогают таск-трекеры. В Jira Software такие процессы называются Workflow. Это пути, по которым следуют задачи во время работы — от постановки до сдачи.

Компоненты Workflow

Рабочий процесс (воркфлоу) состоит из четырех компонентов:

• статусы (Statuses);
• переходы между статусами (Transitions);
• исполнители (Assignees);
• решения (резолюшны или Resolutions).

Чтобы наглядно проиллюстрировать компоненты, разберем рабочий процесс на примере отслеживания книг в обычной библиотеке. Каждая библиотечная книга — это аналог задачи нашего производства.

Статусы

Статусы указывают, где задача находится в рабочем процессе, и эти статусы должны быть уникальными. В примере рабочего процесса библиотеки книга может находиться в одном из трех состояний: «в библиотеке» (at library), «у читателя» (with customer) или «снята с учета» (retired). Если вы настроите свои переходы как двунаправленные, любая задача сможет проходить через один и тот же статус несколько раз (подробнее об этом чуть ниже).

Статусы бывают двух видов: нерешенные — unresolved (открытые) и решенные — resolved (закрытые). Статус «снята с учета» — закрытый, а «в библиотеке» и «у читателя» — открытые.

В качестве других распространенных открытых статусов часто используют:

• «Открыто».
• «В работе».
• «На проверке».
• «В планировании».
• «Ожидает анализа» и т.д.

Примеры типовых закрытых статусов:

• «Отправлено».
• «Опубликовано».
• «Закрыто».
• «Сдано».
• «Принято» и т.д.

Переходы

Переходы отражают предпринимаемые действия и определяют способ движения задачи от статуса к статусу. Они вроде дороги, соединяющей два города, — могут быть односторонними или двунаправленными. Можно разрешить задачам переходить из одного статуса в несколько других (на выбор). Это позволяет разрабатывать Workflow для свободно текущих процессов, в которых есть несколько возможных последующих шагов для решения проблемы.

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

В примере нашего рабочего процесса библиотечная книга не может быть снята с учета, пока она находится у читателя. Сначала книге должны присвоить статус «в библиотеке».

Кроме этого, Jira поддерживает ограничения рабочего процесса (передавать задачу могут только определенные люди). Например, книги выдают библиотекари, берут и возвращают читатели, списывают другие сотрудники библиотеки. Читатели не могут оценить, подходит ли книга для инвентаризации — это должны решать только сотрудники библиотеки. У каждого свои полномочия.

Исполнитель

Исполнитель — это ответственный за задачу. В примере с библиотекой мы бы назначали исполнителем читателя каждый раз, когда ему выдают книгу во временное пользование. Благодаря этому библиотекари знают, у кого из читателей сейчас находится эта книга.

Решения (резолюшны)

В решениях объясняется, почему проблема перешла из открытого статуса в закрытый. При выводе книги из обращения ее удаляют из инвентаря — переводят в закрытый статус «снята с учета». Таким образом выносят решение (резолюшн) по этой книге. Могут быть другие решения: «повреждено», «устарело» или «потеряно».

Распространенные ошибки в работе с Workflow

Распространенная ошибка при настройке рабочих процессов в Jira — путать статус и решение (резолюшн). Статус описывает, где находится элемент в рабочем процессе, а решение (резолюшн) объясняет, почему задача больше не находится в процессе.

Устанавливать резолюшн лучше тогда, когда задача переходит из нерешенного состояния в решенное. Если задача снова переходит в нерешенное состояние, необходимо удалить решение. Например, библиотекарь решает вернуть книгу в обращение — перенести ее из статуса «снята с учета» в статус «в библиотеке» через переход «восстановить». В этом случае ему необходимо удалить резолюшн из книги. В Jira можно настроить автоматическое выполнение этой операции с помощью постфункции перехода (об этом чуть ниже).

Как выстроить работу при настройке рабочих процессов

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

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

Делайте рабочий процесс в Jira простым

Часто руководители и сотрудники хотят иметь статусы для каждой части рабочего процесса. Это хорошо, но помните, что каждый статус добавляет больше переходов и усложняет Workflow. Лучше стремитесь к простоте и масштабируемости.

Каждый раз при добавлении нового статуса в рабочий процесс убедитесь, что у вас нет другого выбора. Посмотрите примеры:

1. Менеджер по разработке хочет добавить особый статус под названием Code Review. Делает это, чтобы команде было ясно, какие проблемы находятся в активной разработке, а какие закончены и ожидают проверки. Просмотр кода существенно отличается от написания, поэтому имеет смысл добавить новое состояние.
2. В библиотеке нельзя выдавать читателям на руки книги, которые ждут проверки перед списанием. Поэтому статус «в библиотеке» для них не подходит. Но и в статус «списана» переводить их тоже нельзя, так как книгу еще не осмотрел работник библиотеки. В этом случае для накопления книг разумно добавить новый статус — «на ревизии».
3. Для всех проблем, которые не проходят проверку, менеджер по контролю качества хочет добавить новый статус — Failed Verification. Но он не решает задачу, а только усложняет Workflow. Подобные проблемы инженеры по тестированию просто могут отправлять в предыдущее состояние, например, «в процессе» или «в разработке».
4. Аналогичная с предыдущей ситуация и с библиотечным процессом. Не нужно делать отдельный статус «отреставрирована» для книг, прошедших ревизию и не отправленных на списание. Отреставрированной книге можно сразу присвоить статус «в библиотеке» и выдать ее читателю.

Настройте переходы

В Jira есть ряд параметров, которыми администраторы могут воспользоваться при настройке переходов между статусами.

Условия

Условия определяют, кто может выполнять переход между статусами. Например, только определенный сотрудник в библиотеке может исключить книгу из инвентаря (перевести в статус «снята с учета»). У всех остальных возможность передвинуть задачу в этот статус даже не будет отображаться.

Валидаторы

Валидаторы гарантируют, что переход происходит только при соблюдении определенных критериев для задачи. Например, бывают книги, которые подлежат изъятию из-за того, что «предположительно повреждены». Валидатор в этом случае настраиваем так, чтобы переход в статус «снята с учета» был невозможен без проверки целостности книги. Если задача не соответствует критериям валидатора, переход будет прерван.

Постфункции

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

Можно настроить Jira так, чтобы поле «исполнитель» снова принимало значение «не назначено», когда читатель возвращает книгу в библиотеку.

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

Свойства

Jira распознает некоторые свойства при переходах. Самое распространенное свойство — ограничение решений, отображаемых пользователю при данном переходе. Например, мы можем захотеть, чтобы решение «порвано» отображалось при списании только журналов, но не при изъятии книг. Это удобно, когда у нас есть разные типы задач. В случае с библиотекой это будут, например, книги и журналы.

Как не запутаться при настройке рабочего процесса для вашей команды

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

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

Компонент Workflow	На какой вопрос отвечает
Статус	Где
Исполнитель	Кто
Решение	Почему
Переход	Куда

Как настроить статусы в Workflow

Каждый статус в рабочем процессе — это отдельный этап или шаг в жизненном цикле проблемы (Issue). С Jira Software легко настроить доску, которая показывает поток работы на протяжении жизненного цикла каждой задачи.

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

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

Бывает тимлид не успевает все проверять или не понимает, как расставить приоритеты. На каком-то этапе проекта в статусе «проверка кода» скапливается слишком много задач — стопорится работа.

Оптимизировать такой поток задач просто. Для статуса «проверка кода» устанавливаем лимит незавершенной работы. Тимлид видит проблемные места и своевременно все решает. Так можно устранить любые «узкие» места в бизнес-процессах.

Для руководителя можно настроить отдельную доску. На ней в одном столбце будут статусы, например, «в разработке» и «проверка кода». Ведь оба статуса для него сообщают, что задача еще в работе. Руководитель в реальном времени видит, что действительно сделано, а что нет.

Мы рассмотрели лишь частный случай оптимизации Workflow в Jira. Ситуации могут быть разными. Но всегда есть возможность сделать рабочие процессы простыми и управляемыми. Если вам нужна консультация по работе с Jira, напишите нам.

В следующей статье мы расскажем, как работать в Jira по спринтам. Это принцип гибкой методологии. Он помогает достигать нужного результата, когда все задачи проекта заранее спрогнозировать невозможно. Ведь в процессе работы многое может измениться. Благодаря работе по спринтам, вы будете к этому готовы и все равно придете к нужному результату.