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

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

• формирование проектных команд из сотрудников разных направлений;

• работа с отпусками и командировками;

• проведение мероприятий внутри компании;

• согласование обучения сотрудников;

• отправка посылок.

Для переноса процессов в Jira мы разработали специальный механизм, о котором пойдет речь ниже. Ранее мы рассказывали, как работать с данными Jira без плагинов и минимизировать расходы на обслуживание. А эта статья будет полезна всем, кто администрирует внутренние процессы компании и хочет перенести их в Jira для улучшения управления, сбора статистики и контроля над выполнением задач.

Дисклеймер: В марте 2022 года компания Atlassian прекратила сотрудничество с российскими юридическими лицами. Однако это не распространяется на уже купленные экземпляры Jira (не по подписке), а также на юридические лица, зарегистрированные вне РФ. Так или иначе, многие нашли выход, который позволил им дальше пользоваться привычным инструментом.  

Почему именно Jira?

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

Но давайте немного пофилософствуем. Jira можно сравнить с материальным инструментом – например, карандашом или кистью. Но они не пришли к нам в готовом виде. Только со временем, с накоплением опыта их использования, эти приспособления стали удобными.

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

Как все происходит?

Мы делим перенос процесса на этапы и на каждом шаге назначаем ответственного специалиста:

Этап 1. Сбор информации – аналитик; ревью документа – QA с опытом администрирования Jira.

Этап 2. Технический анализ – администратор Jira.

Этап 3. Настройка – администратор Jira.

Этап 4. Внедрение и сопровождение – служба поддержки или администратор Jira.

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

Практическое применение

Изучить основные принципы настроек и работы Jira можно во многих источниках. Основной – база знаний Atlassian.

В этой статье мы сделаем практический разбор на примере переноса процесса строительства небольших частных домов – от момента получения участка до сдачи под ключ. Для удобства чтения практическую часть выделим заголовком «Практика».

Такой пример позволяет показать, что в Jira можно перенести почти любой процесс, даже не относящийся к IT-сфере. Хотя, согласитесь, процесс строительства дома очень похож на создание приложения.

Этап 1. Сбор информации

Результат этапа – техническое задание в виде документа со схемами, описанием с точки зрения пользователей и user stories по работе с процессом. Цель ТЗ – определить основные шаги и выяснить требования к настройкам проекта и задач.

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

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

• картирование: составление блок-схемы, диаграммы процесса или его частей, описание в виде отчета.

• оценка и ревью: проведение первоначального ревью собранных требований – часто с привлечением QA и/или администратора. Уточнение недостающих моментов у заинтересованных лиц.

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

Практика по этапу 1

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

Обобщенно процесс строительства дома включает следующие этапы:

1. Земляные работы

2. Фундамент

3. Капитальные стены

4. Перекрытия

5. Кровля

6. Окна, двери

7. Внутренняя планировка и отделка

8. Благоустройство участка

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

Структура «команды»:

– Инженер: контролирует весь процесс строительства, ставит задачи для прораба, занимается закупкой материалов.

– Прораб: контролирует и участвует в строительстве на каждом этапе, осуществляет заказ и получение материалов.

– Специалисты, рабочие, разнорабочие: исполнители.

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

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

Этап 2. Технический анализ

Этапы 1 и 2 плавно переходят друг в друга и даже совместимы при наличии первичной информации. Во время ревью администратор может начать технический анализ, во время которого нередко всплывают недоработки, необходимость в изменении ТЗ (в части описания работы процесса в Jira) и добавлении информации по автоматизации.

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

Ниже – основные элементы будущего проекта в Jira. Их настройки определяются на этапе технического анализа:

• название проекта;

• типы задач;

• workflow для каждого типа задач;

• поля и экраны;

• права доступа и уровни безопасности;

• уведомления;

•  доски проекта и дашборды.

Каждому новому процессу соответствует отдельный проект – базовая единица Jira: без привязки к нему другие сущности останутся неактивными и невидимыми.

Типы задач в проекте

Все типы задач в Jira вертикально разделены на три уровня: Epic, Task, Sub-Task. При этом в проекте допускается только один тип задачи уровня Epic, а задач других уровней может быть столько, сколько потребуется по процессу.

Многим знакомы стандартные типы: Story, Bug, Task. При необходимости можно создать задачи со своим названием и собственной иконкой. То же самое относится к уровню Sub-Task.

Для удобства работы между всеми уровнями может существовать как вертикальная связь parent-child, так и горизонтальная через связь запросов.

Подробнее – в базе знаний Atlassian.

Workflow для каждого типа задач

Каждый бизнес-процесс в Jira состоит из статусов и переходов между ними.

Статус – статическое состояние задачи, в котором она может находиться столько времени, сколько потребуется. В Jira принято разделение статусов по типам:

• К выполнению (серая заливка)

• В работе (синяя заливка)

• Выполнено (зеленая заливка)

Переход – это изменение статуса задачи в данный момент времени. Переход отображается в виде кнопки при просмотре задачи, нажатие на которую запускает процесс изменения статуса.

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

Основные параметры любого перехода:

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

Валидаторы – срабатывают во время перехода. Обычно используются для проверки определенных условий, например, заполнения обязательных полей. Если они не выполнены, то переход не состоится, а пользователь увидит предупреждающее сообщение.

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

Списки условий, валидаторов и постфункций можно дополнить через кнопку «Добавить» на экране изменения перехода. При техническом анализе администратор описывает все настройки переходов, их названия и перечень статусов. Подробнее – в базе знаний Atlassian.

Поля и экраны

Экраны задач – это наборы системных и кастомных полей, которые будет видеть пользователь в заданном порядке.

Основные (экран создания, экран просмотра и экран редактирования задачи) и дополнительные (экраны переходов) экраны определяются в настройках проекта. Обязательность полей и дополнительное описание к ним можно настроить отдельно на каждый тип задачи. Подробнее – в базе знаний Atlassian.

Права доступа и уровни безопасности

Для ограничения доступа к проекту или к задачам выполняются настройки схемы прав доступа (к проекту) и схемы безопасности задач.

Ограничения в Jira представляют собой определенную иерархию. Есть три уровня разрешений:

1. Глобальные разрешения – настраиваются администратором Jira и влияют на права во всей системе.

2. Схема прав доступа – настраивается для проекта и влияет на разрешение тех или иных действий пользователей.

3. Безопасность задач – схема настраивается для конкретного проекта. Фактически ограничивает доступ к задаче и ее видимость путем заполнения поля «Уровень безопасности».

Разрешения настраиваются по группам, ролям и по наличию имени пользователя в специальных типах полей. 

Схема прав доступа определяет работу с проектом и всеми задачами в нем, например:

• Просмотр проекта: указанные пользователи будут видеть проект в списке проектов и смогут зайти в него.

• Назначаемые пользователи / Назначение запросов: в первом случае пользователя можно назначить исполнителем, во втором – пользователи смогут назначать других исполнителей. 

• Для работы с задачами нужны категории прав: «Создание запросов», «Редактирование запросов», «Переходы запросов» (право перевода задач по статусам). Дополнительно настраиваются права на закрытие запроса и на создание связи между запросами (link). 

• Есть отдельные события, на которые также требуется настройка прав доступа: работа с вложениями (создание/удаление), комментирование (создание/редактирование/удаление), списание времени.

Сторонние плагины могут добавлять свои разрешения на разных уровнях. Например, плагин для ведения ворклогов Tempo дает права «Видеть рабочие журналы других», в разделе «Глобальные разрешения – «Администраторы Tempo». Подробнее – в базе знаний Atlassian.

Уведомления

Отправка уведомлений в Jira основана на вызове разных событий при работе пользователя с задачей: создание, обновление значения полей, комментирование, переходы по статусам и списание времени. Настройка – в схеме уведомлений для проекта.

При необходимости можно добавить свои события, но выбор шаблона производится из стандартного списка: 

Подробнее – в базе знаний Atlassian.

Доска проекта и дашборд (рабочий стол)

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

Основные настраиваемые элементы на доске:

• Список собираемых задач – регулируется jql-фильтром. При этом на отображение задач для разных пользователей влияет уровень безопасности задач в проекте.

• Колонки – вертикальное разделение по статусам задач. 

• Фильтры – раздел над колонками в виде линк-кнопок, который формируется на основе jql-запросов. Нажатие на фильтр на доске отображает подходящие под него задачи.

• Карточка задачи. Поля «Приоритет», «Тема задачи», «Исполнитель», «Тип задачи» выводятся по умолчанию. Дополнительно можно добавить отображение значений из трех полей.

• Свимлайны (дорожки) – горизонтальное разделение карточек по категориям. Например, можно сделать отображение по исполнителям задач, по эпику или jql-фильтру.

Подробнее — в базе знаний Atlassian.

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

Практика по этапу 2

После проведения технического анализа принято решение о создании MVP-версии проекта с минимальной автоматизацией. Ниже – выжимка из документа по будущим настройкам проекта.

Для нашего проекта созданы роли:

• Рабочий

• Специалист

• Прораб

• Контроль

• Управление

Типы задач

Тип задачи – Epic. Каждый эпик в итоге станет отдельным заказом на строительство дома.

Отдельные типы задач с кастомными наименованиями – этапы строительства, которые мы выделили на этапе сбора информации. Через системное поле Epic Link задачи можно прилинковывать к родительскому эпику – дому. 

Список типов задач для проекта:

• Подготовительные работы (task) – сюда входят все согласования, подготовка участка для начала работы, земляные работы.

• Капитальное строительство (task) – работы, связанные с устройством капитальных конструкций: фундамент, внешние стены, перекрытия, кровля, заполнение проемов (окна, двери).

• Коммуникации (task) – для работ, связанных с проведением, разводкой и подключением коммуникаций.

• Отделочные работы (task) – работы по устройству некапитальных конструкций (например, стены между комнатами), внутренняя отделка, установка дверей и приборов для коммуникаций. 

• Благоустройство (task) – работы по благоустройству придомового участка. 

Дополнительно добавлены запросы уровня sub-task:

• Материалы (sub-task) – подзадача для составления заявок на поставку материалов и контроля их выполнения.

• Доп.работы (sub-task) – подзадача для работ, которые не учтены существующей схемой и настройкой бизнес-процесса. Возникают редко.

Бизнес-процессы

Для эпиков создается короткий бизнес-процесс из статусов:

• Заказ – вновь созданный объект.

• В работе – проведение работ по объекту. При переводе в этот статус отображается экран с обязательными полями «Планируемая дата сдачи», «Ответственный». Перевести в статус могут только пользователи с ролью «Управление».

• Завершено – объект сдан. При переходе есть обязательные поля «Дата сдачи», «Ответственный». Перевод осуществляют пользователи с ролями «Контроль», «Управление».

• Заморожено – строительство заморожено. При переходе есть обязательные поля «Дата заморозки», «Причина заморозки объекта», «Ответственный». Переход осуществляет пользователь с ролью «Управление».

• Отменено – При переходе есть обязательные поля «Дата отмены», «Причина отмены строительства», «Ответственный». Переход осуществляет пользователь с ролью «Управление».

Для MVP-версии оставили возможность перевода во все статусы из всех статусов.

Для обычных задач и подзадач в бизнес-процессе учтены статусы проведения работ: 

1. Подготовка – статус, обозначающий период подготовительных работ для начала производства работ: заказ и получение материалов, подготовка инструмента, первичной документации и прочее, что не входит в строительно-монтажные работы (далее – СМР). 

2. Выполнение СМР – статус, обозначающий период строительных и монтажных работ. Например, копка котлована или строительство стен, укладка кровли или благоустройство.

3. Проверка СМР – статус, обозначающий этап проверки выполненных работ прорабом.

4. Документация – статус, обозначающий этап подготовки рабочей документации — например, различных актов скрытых работ и т.п.

5. Стройконтроль – статус, обозначающий этап сдачи выполненных работ ответственному инженеру.

Все переходы между статусами настроены с экраном перехода, где есть поля «Исполнитель», «Комментарий».

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

Ограничение: перевод из статуса «Стройконтроль» в «Завершено» разрешено только представителям технадзора.

Экраны задач

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

В Epic добавлено поле Epic Name, в задачах и подзадачах – поле Epic Link для удобства линковки всех категорий работ к определенному объекту (Epic). 

Добавлено поле типа «Множественный выбор пользователей из списка» с названием «Доступно для» – для настройки точечных доступов к задаче.

Схема прав доступа

Настройка схемы прав доступа запланирована через определенные роли для всех пользователей, которые будут работать с задачами в проекте:

• Рабочий – просмотр задач, комментирование, создание вложений и заполнение ворклогов. Пользователя с этой ролью могут назначить исполнителем задачи.

• Специалист – более расширенные права в отличие от рабочего. Дополнительно он может редактировать задачи, перемещать по статусам, назначать исполнителей. 

• Прораб – права как у «Специалиста». Он может редактировать ворклоги подчиненных. 

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

Схема безопасности

В проекте предусмотрена необходимость ограничения видимости задач по объектам строительства и «командам». Для гибкости и стабильной работы планируется настройка по ролям и выполняемым функциям.

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

Схема уведомлений

Для MVP запланирована настройка схемы уведомлений по всем событиям для автора, исполнителя и наблюдателей.

Доски в проекте

В первой версии проекта запланировано две доски типа Kanban: 

• Рабочие задачи – настраивается для работы специалистами и рабочими.

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

Причина такого разделения – описанные в ТЗ пользовательские сценарии, которые уточняли на этапе сбора информации: 

• рабочим и специалистам было критично важно видеть, над чем они работают и что у  них запланировано – со сроками. И информация о том, к какому объекту принадлежит работа, – на втором месте.

• для контролирующих на первом месте указано разделение по объектам и только потом – сроки и исполнители. При этом им важно видеть каждый статус и этап строительства для удобства проверки совпадения с планом строительства.

Этап 3. Настройка

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

Для создания проекта и настройки всех описанных схем необходимы права глобального администратора Jira.

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

Порядок создания и настройки похож на список, по которому проводится и заполняется документ по техническому анализу. В Jira есть подсказка порядка настроек в разделе «Администрирование» – «Задачи» и в настройках проекта.

Практика по этапу 3

В результате проведенного технического анализа и подготовленного документа администратор Jira настраивает проект. 

В практической части мы немного приоткроем завесу тайны некоторых настроек, которые выглядят как автоматизация, но не требуют привлечения разработки:

– Ограничения для работы с эпиками были настроены через «Условия» на переходах по роли пользователя.

– Ограничения для создания эпиков – через настройки воркфлоу и изменение стандартных настроек в валидаторе.

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

– Установили постфункцию автоматического назначения исполнителя для перехода задач в статус «Стройконтроль», так как в организации заказчика строительным контролем занимался только один человек. 

– Ограничения для досок сделаны на уровне фильтра. В доступе были указаны роли «Управление», «Контроль» проекта. Свимлайны настроили по эпикам.

– На все переходы установлен экран перехода, чтобы исключить случайное нажатие кнопки. Мы часто сталкиваемся с такими кейсами на практике, и появление экрана с полем «Комментарий» может остановить пользователя и будет сделан более осознанный переход. На некоторых экранах мы дополнительно добавили поля, заполнение которых планировалось для передачи задачи далее по процессу. 

– Ограничения для перехода из «Стройконтроль» в «Завершено» реализовано через условие по исполнителю.

Этап 4. Сопровождение

Собрали информацию, оформили в ТЗ и провели технический анализ, перенесли все настройки процесса в Jira и сделали MVP проекта. Далее – этап внедрения и сопровождения процесса. Цель любого переноса – облегчение работы по процессу и его автоматизация при помощи Jira. 

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

В большой компании, как наша, силами одних только администраторов Jira было бы тяжело внедрять масштабные процессы. Поэтому мы делим внедрение на этапы и привлекаем разных специалистов:

1. Инструкции для пользователей: подготовка регламентов, инструкций со скринами и FAQ с описанием основных кейсов.

2. Фокус-группа: приглашаем от каждого отдела одного-двух специалистов, которых знакомим с процессом в Jira и даем необходимые инструкции. После этого собираем обратную связь.

3. Анализируем обратную связь от фокус-группы, по возможности донастраиваем процесс, дополняем инструкции и FAQ.

4. Проведение обучающих встреч: приглашаем руководителей отделов, рассказываем о процессе от начала до конца. Дополнительно записываем видеоинструкции.

5. Внедрение процесса на всех специалистов: при помощи знакомых с процессом руководителей и фокус-группы рассказываем о процессе всем заинтересованным лицам, отдаем обычные и видеоинструкции.

6. Сопровождение: после полного внедрения администраторы Jira отвечают на вопросы и стараются оперативно дорабатывать настройки процесса с учетом работы всей компании.

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

Послесловие

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

За последние 3 года мы постепенно перенесли и автоматизировали множество процессов компании. Вот некоторые из них: 

• формирование проектных команд с учетом навыков каждого сотрудника и его занятости; 

• контроль навыков специалистов и их развитие;

• обучение сотрудников и онбординг: программы адаптации новичков, менторство и поддержка на коммерческих проектах;

• формирование бюджетов на обучение и повышение квалификации специалистов;

• организация мероприятий и командировок;

• согласование и контроль отпусков;

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

• согласование и выдача доступов;

• сбор метрик и статистики по всем процессам.

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

А какими рабочими процессами управляете вы с помощью Jira?

Больше полезных материалов – в наших ВК и Telegram