Issue types в Jira: что делать, чтобы команда не путалась в задачах и всегда доводила проект до конца

Речь пойдет о базовых принципах работы в Jira: проектах (epic), задачах (task) и подзадачах (sub-task). Разберем этапы планирования проектов на доступных примерах. Считаем, это полезно знать при работе не только с Jira, но и со всеми другими таск-трекерами, CRM и планировщиками. Увы, менеджеры часто забывают с чего начать постановку задачи, чтобы ее потом довели до конца.

Jira — мощный таск-менеджер. Для простых проектов часто слишком мощный. Зато в нем можно сделать все, что вам нужно. А если разберетесь в основах, поймете, что работать в нем просто. К сожалению, часто мы наблюдаем такую картину:

• Менеджер видит огромный функционал.

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

Чтобы этого не допустить, достаточно на старте правильно описать работу компании. Разобраться, с какими типами задач вы сталкиваетесь. Создать и настроить 5-10 процессов, которые смогут закрыть все потребности бизнеса. Все станет прозрачно и понятно для руководителя, менеджера проектов и всех сотрудников.

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

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

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

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

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

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

Правильное определение горизонтов планирования — большая тема. Если нужно, сделаем по ней отдельную статью.

Главная основополагающая сущность Jira — Issue (в переводе «проблема»). Можно сказать, что Issue — это любая работа, которую нам предстоит сделать.

Чтобы упорядочить все «проблемы», в Jira предусмотрена многоуровневая настройка интерфейса. Выделим три базовых типа Issue Type:

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

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

Эпиками в Jira называют относительно большие объемы работ, которые состоят из нескольких задач.

Когда начинаем работать, мы представляем себе общую цель проекта (эпика). Но детально планируем только первое целевое состояние (первый видимый результат). Именно от этого отталкиваемся в дальнейшей работе. Если потребуется, можем корректировать последующие шаги. Такой способ планирования называется гибким подходом. Он позволяет достигать целей, не зная наперед все этапы проекта, своевременно реагировать на изменившиеся обстоятельства и избежать глобального краха проекта. Вернемся к примерам.

Таск — это простая задача — конкретная и конечная, время выполнения которой можно спланировать.

Протестировать форму, отрендерить изображение, испечь бисквит — это все таски.

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

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

Сабтаск (или подзадача) — это только часть задачи, которую предстоит выполнить. Сабтаск не может быть самостоятельной сущностью и создается всегда, как часть существующего таска.

Обычно так делают, когда одну задачу нужно разделить на несколько маленьких. По умолчанию сабтаски включены в Jira, но их можно выключить. Например, мы не используем подзадачи, так не видим в них необходимости.

Таск и эпик — это самые универсальные сущности. На простых проектах их достаточно. Но в Jira существуют и другие стандартные типы «проблем»:

• Story
• Bug

Кроме этого можно делать сколько угодно собственных Issue. При этом учитывайте, что большое количество сущностей чаще создает сложности, чем помогает в работе. Особенно когда их создают неосознанно.

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

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

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

Мы рассказали лишь о базовых принципах работы над проектами в Jira.

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

Процессы могут быть очень простыми:

Бывают процессы сложнее:

Или можно описывать все максимально подробно:

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

Тема выстраивания процессов большая, интересная и заслуживает отдельной статьи. Хотите узнать о чем-то подробнее, пишите вопросы в комментариях. На простые сразу ответим, а более сложные возьмем на заметку и раскроем в новой публикации.