Мы уже разобрали главную сущность Jira Software Atlassian — Issue и рассмотрели различные типы задач (тикетов, тасков). В статье рассказываем о настройке рабочих процессов Jira Workflow. Если правильно выстроить сценарии достижения цели, все этапы работы бизнеса становятся прозрачными и предсказуемыми.
Почему это важно
Компоненты Workflow
— Статусы
— Переходы
— Исполнитель
— Решения
Распространенные ошибки
Как выстроить работу
— Упростите процесс
— Настройте переходы
— Условия
— Валидаторы
— Постфункции
— Свойства
Как не запутаться в компонентах
Как настроить статусы
Почему для бизнеса важна настройка рабочих процессов
Любая цель становится результатом какого-либо процесса. Любой такой процесс в подавляющем большинстве случаев состоит из последовательности шагов: подготовки, планирования, принятия окончательного решения о реализации или отмене идеи. Финальные шаги обычно — воплощение идеи в жизнь и наслаждение результатом.
Понятный и наглядный пример процесса — отслеживание заказа в службе доставки. Обычно мы можем контролировать его по шагам: наш заказ приняли в работу, его готовят к отправке, курьер везет его нам.
Если мы заказываем посылку, можем отслеживать все статусы ее доставки: с главного склада в региональный, затем в наш город, район и, наконец, в местный пункт выдачи. Все происходит наглядно в режиме онлайн. Мы видим, где посылка и что с ней. Это называется статусом, то есть состоянием на данный момент. Поэтому не обрываем телефоны службы поддержки, уточняя, долго ли еще ждать и не потерялся ли наш заказ.
Как видите, все процессы состоят из статусов. Они позволяют нам ориентироваться, сколько еще ждать результат, не задавая этот вопрос каждый час.
Информацию о состоянии дел в компании можно очень быстро передавать всем заинтересованным лицам. Для этого нужно формализовать, визуализировать и выделить основные поворотные точки в процессах: рабочих, технологических, финансовых и т.д. Это решает сразу несколько частых проблем:
- Каждый знает свое место и задачу в процессе в контексте других этапов производства. Исполнитель четко видит, после какого этапа продукт поступает к нему, что он должен делать на своем этапе и что будут делать с его продуктом дальше.
- Информация о том, что закончен один этап и пора начинать следующий, транслируется всей команде, а не изолирована только между двумя людьми (руководителем и исполнителем). Не нужно дозваниваться, писать личные мейлы или просить кого-то передать исполнителю, что пора браться за работу. Достаточно озвучить новый статус в общем рабочем пространстве (доске в таск-трекере, общей табличке в Google Docs и т.д.).
- При ретроспективном анализе всегда можно обнаружить проблемное место в процессе. При оптимизации бросить все силы не наугад, а именно туда, где это действительно требуется.
Визуализировать процессы помогают таск-трекеры. В Jira Software Atlassian такие процессы называются Workflow. Это пути, по которым следуют задачи во время работы — от постановки до сдачи.
Компоненты Workflow
Рабочий процесс (воркфлоу) состоит из четырех компонентов:
- статусы (Statuses);
- переходы между статусами (Transitions);
- исполнители (Assignees);
- решения (резолюшны или Resolutions).
Чтобы наглядно проиллюстрировать компоненты, разберем рабочий процесс на примере отслеживания книг в обычной библиотеке. Каждая библиотечная книга — это аналог задачи нашего производства.
Статусы
Статусы указывают, где задача находится в рабочем процессе, и эти статусы должны быть уникальными. В примере рабочего процесса библиотеки книга может находиться в одном из трех состояний: «в библиотеке» (at library), «у читателя» (with customer) или «снята с учета» (retired). Если вы настроите свои переходы как двунаправленные, любая задача сможет проходить через один и тот же статус несколько раз (подробнее об этом чуть ниже).
Статусы бывают двух видов: нерешенные — unresolved (открытые) и решенные — resolved (закрытые). Статус «снята с учета» — закрытый, а «в библиотеке» и «у читателя» — открытые.
В качестве других распространенных открытых статусов часто используют:
- «Открыто».
- «В работе».
- «На проверке».
- «В планировании».
- «Ожидает анализа» и т.д.
Примеры типовых закрытых статусов:
- «Отправлено».
- «Опубликовано».
- «Закрыто».
- «Сдано».
- «Принято» и т.д.
Переходы
Переходы отражают предпринимаемые действия и определяют способ движения задачи от статуса к статусу. Они вроде дороги, соединяющей два города, — могут быть односторонними или двунаправленными. Можно разрешить задачам переходить из одного статуса в несколько других (на выбор). Это позволяет разрабатывать Workflow для свободно текущих процессов, в которых есть несколько возможных последующих шагов для решения проблемы.
Можно настроить переходы так, чтобы задачи шли по строго определенному пути. Это позволяет отразить более регламентированные процессы.
В примере нашего рабочего процесса библиотечная книга не может быть снята с учета, пока она находится у читателя. Сначала книге должны присвоить статус «в библиотеке».
Кроме этого, Jira поддерживает ограничения рабочего процесса (передавать задачу могут только определенные люди). Например, книги выдают библиотекари, берут и возвращают читатели, списывают другие сотрудники библиотеки. Читатели не могут оценить, подходит ли книга для инвентаризации — это должны решать только сотрудники библиотеки. У каждого свои полномочия.
Исполнитель
Исполнитель — это ответственный за задачу. В примере с библиотекой мы бы назначали исполнителем читателя каждый раз, когда ему выдают книгу во временное пользование. Благодаря этому библиотекари знают, у кого из читателей сейчас находится эта книга.
Решения (резолюшны)
В решениях объясняется, почему проблема перешла из открытого статуса в закрытый. При выводе книги из обращения ее удаляют из инвентаря — переводят в закрытый статус «снята с учета». Таким образом выносят решение (резолюшн) по этой книге. Могут быть другие решения: «повреждено», «устарело» или «потеряно».
Распространенные ошибки в работе с Workflow
Распространенная ошибка при настройке рабочих процессов в Jira — путать статус и решение (резолюшн). Статус описывает, где находится элемент в рабочем процессе, а решение (резолюшн) объясняет, почему задача больше не находится в процессе.
Устанавливать резолюшн лучше тогда, когда задача переходит из нерешенного состояния в решенное. Если задача снова переходит в нерешенное состояние, необходимо удалить решение. Например, библиотекарь решает вернуть книгу в обращение — перенести ее из статуса «снята с учета» в статус «в библиотеке» через переход «восстановить». В этом случае ему необходимо удалить резолюшн из книги. В Jira можно настроить автоматическое выполнение этой операции с помощью постфункции перехода (об этом чуть ниже).
Как выстроить работу при настройке рабочих процессов
Для начала определите всех участников рабочего процесса. Поговорите с каждой заинтересованной стороной о том, что важно при выполнении работы. Нарисуйте черновики рабочего процесса и соберите отзывы.
Рабочие процессы болезненны, потому что они выявляют, как действительно люди работают. Но они обеспечивают предсказуемость и прозрачность работы: все члены команды знают свое место в процессе, видят информацию о продвижении проекта, своевременно выявляют проблемы и решают их точечно, а не наугад.
Делайте рабочий процесс в Jira простым
Часто руководители и сотрудники хотят иметь статусы для каждой части рабочего процесса. Это хорошо, но помните, что каждый статус добавляет больше переходов и усложняет Workflow. Лучше стремитесь к простоте и масштабируемости.
Каждый раз при добавлении нового статуса в рабочий процесс убедитесь, что у вас нет другого выбора. Посмотрите примеры:
- Менеджер по разработке хочет добавить особый статус под названием Code Review. Делает это, чтобы команде было ясно, какие проблемы находятся в активной разработке, а какие закончены и ожидают проверки. Просмотр кода существенно отличается от написания, поэтому имеет смысл добавить новое состояние.
- В библиотеке нельзя выдавать читателям на руки книги, которые ждут проверки перед списанием. Поэтому статус «в библиотеке» для них не подходит. Но и в статус «списана» переводить их тоже нельзя, так как книгу еще не осмотрел работник библиотеки. В этом случае для накопления книг разумно добавить новый статус — «на ревизии».
- Для всех проблем, которые не проходят проверку, менеджер по контролю качества хочет добавить новый статус — Failed Verification. Но он не решает задачу, а только усложняет Workflow. Подобные проблемы инженеры по тестированию просто могут отправлять в предыдущее состояние, например, «в процессе» или «в разработке».
- Аналогичная с предыдущей ситуация и с библиотечным процессом. Не нужно делать отдельный статус «отреставрирована» для книг, прошедших ревизию и не отправленных на списание. Отреставрированной книге можно сразу присвоить статус «в библиотеке» и выдать ее читателю.
Настройте переходы
В Jira есть ряд параметров, которыми администраторы могут воспользоваться при настройке переходов между статусами.
Условия
Условия определяют, кто может выполнять переход между статусами. Например, только определенный сотрудник в библиотеке может исключить книгу из инвентаря (перевести в статус «снята с учета»). У всех остальных возможность передвинуть задачу в этот статус даже не будет отображаться.
Валидаторы
Валидаторы гарантируют, что переход происходит только при соблюдении определенных критериев для задачи. Например, бывают книги, которые подлежат изъятию из-за того, что «предположительно повреждены». Валидатор в этом случае настраиваем так, чтобы переход в статус «снята с учета» был невозможен без проверки целостности книги. Если задача не соответствует критериям валидатора, переход будет прерван.
Постфункции
Постфункции выполняют дополнительные действия для задач (по триггеру на переход в другой статус). Они отвечают за то, что происходит после смены определенного статуса. Самая распространенная постфункция — очистить решение (резолюшн) при переводе задачи обратно в нерешенное состояние.
Можно настроить Jira так, чтобы поле «исполнитель» снова принимало значение «не назначено», когда читатель возвращает книгу в библиотеку.
Когда происходит переход в новый статус, это часто означает, что у задачи появился новый исполнитель. В этом случае с помощью постфункции можно автоматически изменить исполнителя или отобразить экран перехода, где человек, передающий задачу, выбирает, кому ее передать.
Свойства
Jira распознает некоторые свойства при переходах. Самое распространенное свойство — ограничение решений, отображаемых пользователю при данном переходе. Например, мы можем захотеть, чтобы решение «порвано» отображалось при списании только журналов, но не при изъятии книг. Это удобно, когда у нас есть разные типы задач. В случае с библиотекой это будут, например, книги и журналы.
Как не запутаться при настройке рабочего процесса для вашей команды
Возвращаясь к примеру с библиотекой, книги регистрируются и выгружаются до тех пор, пока не истечет срок их службы, а затем выбывают из обращения. Так и ошибки в коде: регистрируются, проверяются, исправляются, снова проверяются и затем закрываются. Результат — успешная реализация проекта.
При организации рабочего процесса важно корректно настроить все компоненты Workflow. Чтобы не запутаться, запомните простые вопросы, на которые отвечает каждый из них.
| Компонент Workflow | На какой вопрос отвечает |
|---|---|
| Статус | Где |
| Исполнитель | Кто |
| Решение | Почему |
| Переход | Куда |
Как настроить статусы в Workflow
Каждый статус в рабочем процессе — это отдельный этап или шаг в жизненном цикле проблемы (Issue). С Jira Software Atlassian легко настроить доску, которая показывает поток работы на протяжении жизненного цикла каждой задачи.
Представим обычную ситуацию. Команда программистов работает с потоком задач. Просчитали загрузку и составили месячный план. Кажется, что все были заняты, но часть задач до результата так и не довели. А руководитель до финального отчета вообще не понимал, что сделано, а что нет.
Чтобы исключить такие сценарии, достаточно правильно организовать работу в Jira. В этом случае на доске мы видим каждый этап проекта и сколько задач в нем содержится.
Бывает тимлид не успевает все проверять или не понимает, как расставить приоритеты. На каком-то этапе проекта в статусе «проверка кода» скапливается слишком много задач — стопорится работа.
Оптимизировать такой поток задач просто. Для статуса «проверка кода» устанавливаем лимит незавершенной работы. Тимлид видит проблемные места и своевременно все решает. Так можно устранить любые «узкие» места в бизнес-процессах.
Для руководителя можно настроить отдельную доску. На ней в одном столбце будут статусы, например, «в разработке» и «проверка кода». Ведь оба статуса для него сообщают, что задача еще в работе. Руководитель в реальном времени видит, что действительно сделано, а что нет.
Мы рассмотрели лишь частный случай оптимизации Workflow в Jira. Ситуации могут быть разными. Но всегда есть возможность сделать рабочие процессы простыми и управляемыми. Если вам нужна консультация по работе с Jira, напишите нам.
В следующей статье мы расскажем, как работать в Jira по спринтам. Это принцип гибкой методологии. Он помогает достигать нужного результата, когда все задачи проекта заранее спрогнозировать невозможно. Ведь в процессе работы многое может измениться. Благодаря работе по спринтам, вы будете к этому готовы и все равно придете к нужному результату.
