Как изменить бизнес процесс в jira

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

Настройте JIRA на те пути, по которым вы ходите

Начнем с основ

В стандартной поставке JIRA поставляется один бизнес-процесс, для того чтобы быстро начать работу. Основные этапы этого рабочего процесса идеально подходят для обработки инцидентов и задач. Тем не менее, функциональность JIRA позволяет вам обучить систему всем «правилам игры» вашего предприятия.

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

Поддерживайте актуальность процессов

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

Atlassian JIRA Бизнес процесс согласования Статусы процессы

Настраивайте множество бизнес-процессов в JIRA, чтобы отразить все уникальные потребности вашей организации. Вы сможете определить свои правила работы для различных отделов, проектов и даже конкретных объектов учета — задача, документ, активность и прочее.
Вносите изменения в уже работающие бизнес-процессы не опасаясь вызвать сбои. JIRA обеспечить моментальное применение новых правил работы.
Откатывайтесь на предыдущие состояния процессов в случае отрицательных результатов внедрения новых принципов работы. Черновики бизнес-процессов в JIRA помогут вам сэкономить время на повторную настройку системы.

Заставьте бизнес-процессы работать для вас

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

Workflow проекта. Agile, Scrum, Kanban. Рабочий процесс в JIRA (реальный проект).

Обеспечьте проверку достаточности и корректности вводимых пользователем данных при выполнении им попытки перейти на другой этап обработки информации. Вы можете настроить проверку обязательных полей, типов данных, а так же фиксацию сведений о дате и авторе сделанных изменений в объектах JIRA.
Определите необходимый уровень доступа пользователей к информации на конкретном этапе бизнес-процесса. Политики безопасности JIRA помогут Вам быстро разделить пользователей на группы информационной доступности.
Наделяйте супер пользователей супер функциями. Позволяйте завершать процесс только руководителям, а создавать новые объекты учета только регистраторам. Дизайнер бизнес-процессов JIRA поможет Вам определить необходимые для каждой роли действия в рамках определенного бизнес-процесса.

Источник: www.teamlead.ru

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

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

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

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

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

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

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

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

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

Компоненты Workflow

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

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

Статусы

Статусы указывают, где задача находится в рабочем процессе, и эти статусы должны быть уникальными. В примере рабочего процесса библиотеки книга может находиться в одном из трех состояний: «в библиотеке» (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 легко настроить доску, которая показывает поток работы на протяжении жизненного цикла каждой задачи.

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

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

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

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

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

Как мы работаем над проектами в Jira

Для команд, которые разрабатывают программные продукты, Jira — идеальная среда контроля и постановки задач, особенно для удалённых команд. Расскажем, как мы работаем над проектами в системе.

Преимущества Jira

диаграмма Ганта,
диаграмма сгорания задач,
управление временем,
расстановка задач по приоритетам,
фильтры,
делегирование задач,
отслеживание объема работы в процентном соотношении,
настраиваемые scrum и kanban-доски,
и многое другое.

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

Однако кроме явных преимуществ у Jira есть один, на мой взгляд, серьёзный недостаток — её сложно настраивать. Система не подходит для работы в команде, у которой ещё не построены бизнес-процессы. Да, скрыв все функции и оставив в Jira функции, аналогичные, например, Trello — можно, но это нерациональное использование системы, притом с лишними расходами на её использование.

Если вы только начинаете бизнес по разработке, лучше выберите что-то более простое, а потом, набив шишки и выстроив все процессы, смело переходите на Jira.

Постановка задач

Epic — самая большая задача, из частей которой складывается работа над проектом. Для реализации такой задачи нужно выполнить несколько меньших задач. Эпик у нас длится спринт и больше.
Story — описание задачи без подробностей. В рамках этой задачи выполняются подзадачи, которые должны привести к результату, описанному в Story. Особенность: после закрытия задачи Story должна быть создана задача с заданием на реализацию выработанного решения.
Task — конкретная задача с четким описанием, которая требует выполнения. Длится в течение спринта.
Bug — задача, связанная с ошибкой в коде.
Easy-task — небольшая задача с упрощенным Workflow без статусов Review и Test.
Sub-task — конкретная далее неделимая задача с подробным описанием. Часть Story, Task, Bug или Easy-task.
Quick-subtask — маленькая конкретная далее неделимая задача с упрощённым Workflow без статусов Review и Test. Часть Story, Task, Bug или Easy-task.

Эти типы задач чётко контролируют наш процесс разработки и обеспечивают прозрачность процесса. Все задачи на спринт ставятся и распределяются из бэклога — доски со всеми задачами проекта по приоритетности.

Задачи Story, Task, Bug, Easy-task появляются в бэклоге. Сразу после создания задачи Jira в отдельном окне предлагает переместить её в текущий спринт

Для перемещения задачи между спринтами можно использовать поле Sprint в окне просмотра задачи