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

• CEO хочет доску, где будет видеть задачи из разных проектов, которые будут у него в фокусе внимания, а также их дочерние задачи.

• Служба безопасности хочет видеть все задачи из разных проектов, в которых есть потенциальный риск.

• На долю Project Manager выпал проект, в котором участвует четверть бизнеса, около 20 команд — ему нужно им как-то рулить.

• В департаменте «Y» задумались о том, что им нужен отдельный проект, по которому будут идти высокоуровневые задачи всех 5-ти команд департамента.

Мы знаем, что это вполне естественное направление развития — читали Rethinking Agile Клауса Леопольда и знакомы с концепцией уровней полёта, а некоторые менеджеры даже знакомы с фреймворками масштабирования. Но вот как это всё организовать непосредственно в Jira?

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

В подавляющем большинстве наших команд доски выглядит примерно так (только в Jira, а не в Miro):

Как вы можете заметить, сверху вниз у нас идут классы обслуживания или приоритеты. Чем выше — тем важнее задача. Также есть возможность отфильтровать задачи по исполнителям. Вдруг на Васе сразу 5 задач, и их стоит перераспределить? Примерно такой же способ организации оставался для досок департаментов. Просто по нему, например, идут Epic'ки, а не стори, с разделением по классам обслуживания.

Однако такой подход при создании координационных досок нам не подошёл, поэтому мы переделали свимлейны по типам задач. Получилось примерно вот так:

Можно обратить внимание, что вместо фильтров по отдельным исполнителям мы фильтруем задачи по командам/Jira-проектам, в которых они исполняются. На такой доске мы можем и лимиты настроить по командам.

На ней также ничто не мешает проводить синки на всех уровнях. Включил Quick Filter «команда A» и пошёл на синк этой команды задавать вопросы — что нужно сделать, чтобы задачи, в которых они участвуют, подвинулась вправо.

А можно встретиться с руководством и дать ему OverView, как продвигается проект, какой остаётся бэклог, запустить прогноз по Monte Carlo (смотри в прошлой статье), ведь он строится по доске.

Но дизайн доски — это полдела, ещё нужно обеспечить попадание ВСЕХ задач проекта на эту доску. Тут мы нашли несколько решений:

Навешаем лейблов

Это оказалось самым простым способом собрать кучу разрозненных задач из всех возможных проектов в единую кучу и показать их все в каком-то общем представлении. Установить лейбл — дело пары секунд, но что если задач тысяча? Плюс постоянно появляются новые, а какие-то задачи то включаются, то исключаются из проекта через связи?

Элементарно, Ватсон! Нужно автоматизировать навешивание лейблов. Такой способ мы придумали для кейса лейбла CEO, чтобы наш генеральный мог просто повесить лейбл на одну задачу, и всё, что нужно, уже автоматически проставилось и подтянулось бы на его доску. Для этого мы реализовали пару глобальных автоматизаций.

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

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

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

JQL-запрос, для формирования доски, предельно простой:

labels in (ceo, CEO)

Связь issue linked

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

issue in linkedIssues(ABC-123)

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

issueFunction in linkedIssuesOfRecursive("issue = ABC-123", "is parent of")

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

Такие ухищрения позволили нам декомпозировать, запланировать и затащить пару ОЧЕНЬ КРУПНЫХ проектов, которые затрагивали от четверти до половины всего бизнеса. И при этом сделать это, ну если не точно в срок, то с учётом классической "Ошибки планирования".

Как вы понимаете, это всё про координационное управление тем, по чему уже приняты решения, и всё отдано в поставку. Для планирования и определения скоупа работ этот инструмент не очень подходит, поэтому Product Owner’ы некоторое время оставались неудовлетворенными.

"Сделайте мне Ёлочку! ©Директор по процессам (Маша, привет)

То есть нужно задать некую иерархию задач, в рамках которой эти задачи можно будет визуализировать, и чтобы время исполнения родительской задачи было суммарным временем исполнения всех её дочерних задач. Страшно? А вот и нет, ведь для этого есть готовый инструмент.

Jira Plans / Jira Advanced Roadmaps. Раньше он был доступен в виде отдельного плагина. Теперь, если я ничего не путаю, он входит в состав пакета Jira Software. Подробнее про него и его возможности можно прочитать вот тут.

Я же расскажу, как его начали использовать мы:

Иерархия задач

Долгое время у нас существовала классическая Jira иерархия вида Epic → Story / Standard Task → Sub-task. Когда у нас ещё не было этого инструмента, а сложная структура уже была — стори и другие типы задач становились дочерними к сторям через связь linked issues.

Этот инструмент использует связь parent / child, такую же, как в sub-task. В итоге получилась вот такая иерархия:

Как вы видите, мы оставляем буквально неизменной базовую иерархию epic → story → sub-task и добавляем два уровня сверху. Когда мы идейно прорабатывали эту иерархию, то ориентировались на практики из SAFe.

Portfolio — в нашем случае это, как правило, либо просто папка для проектов и крупных бизнес инициатив, или какой-то продукт, или некий strategy item, вроде "обойти конкурента Х по метрики Y на Z %".

Портфолио обычно живут в проектах уровня «отдел/департамент». Например, наш отдел, занимающийся процессами на всю компанию,  владеет такими портфолио как «Автоматизация бизнес процессов», «Жизненный цикл сотрудника», и так далее.

Ниже уровнем живут несколько типов задач — это сервисы, проекты, бизнес-инициативы. Чтобы определиться, какой тип задачи того или иного уровня создавать, я бы рекомендовал использовать Cynefin FrameWork. Но у нас в конкретных спейсах живут конкретные сущности, в зависимости от того, чем занимается тот или иной департамент/отдел.

На выходе мы получаем возможность делать ту самую «ёлочку» или иерархичное представление задач на диаграмме Ганта.

Окей, а нафига оно нужно? Как на практике это используется?

Гант

В командах/департаментах это используется для структуризации «своего» бэклога. Мол, смотри дорогой бизнес, у нас сейчас есть 4 портфолио, в них лежат суммарно 15 проектов, в каждом из которых около 10-ти эпиков. Давайте определимся с приоритетами — что в каком квартале/году мы планируем делать, для поддержания порядка и долгосрочного планирования. Однако таким образом у нас его используют редко. Только в тех частях бизнеса, где мало хаоса и высокий уровень осознанности.

Гораздо чаще этот инструмент используется на проекте, когда у человека, который его ведёт, 100500 задач в разных командах и проектах, и ему нужно уложить их все в некое единое пространство. Тут становится сильно удобнее и структурней, чем делать это на kanban доске. Настолько, что можно буквально за 1 синк передать проект другому менеджеру и спокойно уйти в отпуск, не волнуясь о том, что он что-то потеряет, и всё зафакапится.

Граф зависимостей

Это, пожалуй, самое ценное, что умеет делать инструмент.

Во-первых, он покажет зависимости для каждой конкретной задачи, на которую мы наведём курсор, непосредственно на Ганте. Если переключить его из стандартного режима в режим показа зависимостей, сверху справа, это будет выглядеть примерно вот так:

Но гораздо круче — чистый граф по всему плану/роадмапу. Он будет выглядеть примерно так:

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

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

У этого инструмента есть возможность формировать команды из Jira пользователей, указывать их capacity и заниматься через него capacity планированием, но эта функциональность пока что откровенно сырая, и мы её не используем, предпочитая для этого другие решения.

В облачной Jira они идут сразу в комплекте. Для Jira DC они ставятся в виде отдельного аддона — Automations for Jira.

Выше я уже чуть-чуть их упоминал, но там очень узкая специфика. На момент написания этой статьи мы реализовали более 700 самых разных автоматизаций. Я точно не смогу описать их все, но расскажу про несколько самых важных концептов, которые мы используем:

Самое великое колдунство.

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

Межкомандные автоматизации

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

Это взаимодействие можно было бы визуализировать вот так:

В реальной жизни конечно всё гораздо сложнее, но смысл, думаю, ясен.

Как это работает, когда не автоматизировано? Когда в команде A заканчивают свою часть работы, они тыкают кнопку создать задачу, выбирают проект команды B, заполняют бриф и связывают задачи. Спустя некоторое время идут в соседнюю команду заниматься чайко-менеджментом: «Что там, ребята, с нашей задачей?»

Как это работает, когда автоматизировано? Когда в команде А заканчивают свою часть работы, они двигают задачу в следующий статус, где обычно появляется маленькая форма, в которой можно указать самую важную инфу: ссылку на результаты работы, дедлайн, комментарий. И всё, соседняя команда уже получила новую задачу со всей необходимой информацией и правильно установленными связями между задачами. Более того, она помечена специальным лейблом/компонентом. Поэтому, когда задача команды B дойдёт до статуса «done», задача команды A подвинется в следующую колонку самостоятельно.

Немножко визуала:

Для понимания принципа работы этого костыля — все данные, которые надо передать в автоматически созданную задачу, пользователи сначала добавляют в оригинальную задачу, но они, как правило, не показываются в ней и не добавляются ни в какие скрины, кроме скрина перехода задачи в статус. При клонирование задачи нужные данные подставляются через smart-values.

Полностью автоматические WorkFlow

Посмотрев на это, вы подумаете и скажете, что, в зависимости от действий пользователей, можно двигать задачи автоматически и таким образом автоматизировать 100% движения задачи по бизнес-процессу. И да, вы будете правы, это возможно. Мы периодически именно такие процессы и реализуем.

Дочерние задачи на каждом статусе.

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

Как понять что все задачи сделаны, если их много? Через Branch Rule зайти в родительскую задачу из автоматизации и проверить по JQL, есть ли дочерние задачи, у которых Resolution = Unresolved. Если нет — смело двигаем задачу далее по процессу.

Синхронизация / подтягивание статусов.

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

Внешние взаимодействия.

Так случается, что иногда некоторая деятельность, имеющая статус в Jira, выполняется где-то за пределами Jira. Причём она может исполняться автоматически, по API, с получением некоторого ответа о результате своего выполнения. Давайте рассмотрим самый простой и универсальный пример.

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

В ручном режиме уже попробовали — практика рабочая, обратная связь ценная, хотим автоматизировать этот процесс. Jira может отправлять внешние HTTP запросы из автоматизаций как со всеми данными задачи, так и с конкретно составленным JSON'ом. Технически отправить запрос куда-нибудь на API endpoint несложно, но вот формировать этот JSON может быть неудобно. Ещё сложнее в Jira автоматизациях заниматься обработкой ответов, поэтому мы развернули отдельную no-code тулзу для взаимодействия с внешним миром и для межсервисных интеграций.

n8n.io — https://n8n.io/

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

1. Задача переводится в некий нужный статус, как правило, автоматически.

2. Jira отправляет запрос в n8n, меняет assignee на бота.

3. n8n обрабатывает запрос, выбирает нужные данные, переводит задачу в нужный статус.

4. Совершает целевое действие с внешней системой.

5. Происходит проверка ответа от внешней системы:

   1. Если ответ успешный — n8n отправляет запрос в Jira на перевод задачи в Completed. Отправляет отбивку в 1 Slack канал.

   2. Если ответ неуспешный — n8n отправляет запрос в Jira на перевод задачи в статус ToDo, назначает на живого человека, пишет комментарий в задаче об ошибке и отправляет алерт в специальный Slack канал.

Вот, как это выглядит наглядно:

Это автоматизация на стороне Jira, которая отправляет запрос в n8n.

А вот это уже автоматизация на стороне n8n.

Автоматизация коммуникации.

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

АЛЯРМА! Первое, что мы сделали — автоматизацию, которая «выбивает личку с ноги» с криками о том, что что-то упало и именно ты, дорогой username, назначен ответственным за решение этой проблемы.

На самое важное обращает внимание стрелочка. Чтобы это работало так, убедитесь, что username в Jira & Slack у всех ваших сотрудников идентичны, иначе работать не будет, и нужно будет придумывать костыли — ставить доп. плагины для хранения данных в сущности пользователя в Jira и вот это вот всё.

Мы сделали твою задачу.

У вас каждый член команды решает по 5-10 задач в день, но задача не считается выполненной без приёмки со стороны заказчика? Отлично, автоматизируйте отправку уведомлений: «Мы сделали твою задачу, иди проверяй». Кстати, оставлять автоматические комментарии, а не выламывать личку в Slack, тоже бывает хорошо.

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

Кто-то всё таки засох и уже неделю не показывается в твоей задаче — нет смысла тратить своё время, когда можно настроить автоматизацию.

Ну, и да: в некоторых проектах мы закрываем задачи автоматически, при бездействии заказчика на стадии приёмки в течение двух недель. Метрики на самого «не принимающего заказчика» пока не собираем, а могли бы.

Кастомные метрики.

А вот метрика, которую мы собираем — сколько раз новая задача отправлялась заказчику на уточнение требований. У нас есть команды, для которых получение точного брифа очень важно, так как они несут риск денежных затрат в случае, если придётся «переделывать, потому что это не то...». Каждый раз, когда менеджер понимает, что ему принесли не ТЗ, а ХЗ, он смело жмёт transition FeedBack — и где-то под капотом Jira отщёлкивает Increment у кастомного поля.

Потом дело техники показать распределение на DashBoard в виде Pie Chart.

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

К моменту, когда у нас появились выделенные позиции тимлида, Jira-администраторов и knowledge-менеджера, это перешло в отдельную от PMO структуру. Однако админские права у коллег из PMO оставались, и они ими даже иногда пользовались, чтобы оперативно настраивать всякое для команд разработки.

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

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

• Экзаменация. Права выдаются в случае прохождения экзамена. Экзамен представляет из себя реализацию полноценного бизнес-процесса с полным обвесом по билету. 

Пример такого билета:

???? Книжное издательство

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

Какие бывают заказы?

- Издание новой книги.

- Доп.тираж популярной книги.

- Производство аудиокниги.

- Переиздание книги по правам на интеллектуальную собственность.

- Издание за счёт заказчика.

- Этапы производства.

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

- Первичная вычитка и оценка — требуется только для новых книг, и на основе неё может быть отказано в издании книги.

- Корректура — когда приняли решение издавать книгу, то нужно в любом случае проверить её на ошибки и опечатки.

- Оформление и дизайн обложки (аутсорс).

- Вёрстка книги для печати.

- Предрелизный маркетинг.

- Печать.

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

Директор хочет видеть прогресс наглядно — кто чем занят, и своевременно получать информирование, если какая-то из функций перегружена или простаивает.

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

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

Мы тестируем скоринг по конкретным настройкам и ставим баллы, но конечное решение всё равно субъективное.

Обучение.

На этот раз мы полностью сфокусировались на видеоматериалах. Они у нас делятся на два основных типа — теоретические и практические.

Теоретические — это лекции на 40-60 минут, где рассказывается о какой-то крупной области знания. Например, лекция «Метрики и отчёты в Jira». На ней можно узнать, что такое Control Chart & Cumulative Flow Diagram, как они строятся, как с них читать данные, для чего использовать.

Практические — это небольшие ролики на 5-12 минут, в которых описывается решение конкретной задачи: как сделать новый Workflow, как добавить новое поле в существующую форму, и так далее.

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

Сдача и защита.

Ради обучения мы увеличили жизненный цикл тестового окружения на неделю. Желающий сдать экзамен уведомляет нас. Мы сигнализируем ему: с какого числа он может начать и до какого закончить.

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

Права.

Для всех, прошедших экзаменацию, мы даём членство в кастомной группе с урезанными глобальными правами — jira-editors. У этой группы нет Global Permission "Jira System Administrators", и данная группа не добавляется по умолчанию на роль admin во всевозможные проекты в jira. Она вообще никакие роли в проекты не добавляет. Группа НИКАК не изменяет область видимости задач, а соответственно и доступ к чувствительной информации. Сюда же мы добавляем джира админов на время испытательного срока.

Ок. А в чём профит?

Возможности.

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

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

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

Поняв наш вектор в целом и ознакомившись с концепцией внутренней Jira-гильдии, вы, возможно, спросите:

А за счёт чего всё это выстроенное нами великолепие снова не скатится к состоянию "Бухта Вонючий П..."?

Каждый новоявленный jira-editor или админ проекта начнёт тащить одеяло в свою сторону и делать так, как хочется. В итоге всё превратится в хаос.

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

Каждый стандарт — по сути документ, который описывает, как делать хорошо, а как — не хорошо. Примерно как CodeStyle Guide для разработчиков или «Дизайн Система» для дизайнеров. А у нас стандарты по конфигурации Jira.

Является ли всё, что в нём написано, незыблемым правилом? Нет, конечно: каждый случай уникален, и потому всё, что написано в стандартах, не всегда применимо, бывают исключения.

Но для подавляющего большинства задач и процессов там всё по делу.

Мы сейчас в начале пути по стандартизации: есть один финальный, остальные — в состоянии зарождения и обсуждения в гильдии.

Какая в них основная суть?

Стандарт по формам и полям.

Ключевые тезисы:

• Все формы в Jira должны быть схожими. Пользователи смогут привыкнуть к ним  и работать с ними быстрой системой, а не медленной (по Канеману).

• Чем меньше пользователю надо заполнять полей, тем лучше.

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

• Не плодите кастомные поля, если не будете обращаться к ним через автоматизации или по API. Если вы просто хотите что-то записать в задачу, то используйте описание — оно резиновое.

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

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

• Создавая новые кастомные поля, проверьте, нет ли кастомного поля с таким же названием. Тем, кто создал аналогичное, будем руки отрывать :).

• Рекомендации по неймингу и описанию кастомных полей.

Вот так мы сами соблюдаем свой формат.
Шаблон, название, описание и вложения. Всё. Это все поля, которые нужно заполнить для нашей команды.

Стандарт по WorkFlow

Ключевые тезисы:

• Статус в процессе должен отражать, что происходит с работой. Отвечая на вопрос: «Она (работа/фича/сторя/проект) в каком состоянии?» — In Progress, In Review, Ready for Testing, Testing...

• Если нужен «жёсткий» процесс с последовательными переходами — следует предусмотреть переход из любого статуса в любой для админов и автоматизаций.

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

• Для хаотичных и комплексных сред (по Cynefin) рекомендуем строить процесс как систему накопления знаний. Нужно написать код на этапе поиска ценности инициативы? Это норма!

• Для complicated&obvious сред (по Cynefin) для исполнителей процесс должен отражать действительность, а не быть абстракцией. Статья сначала добавляется в контент план, потом пишется, редактируется, проверяется, переводится. Тут нет творческого поиска решения для бизнес заказа, мы просто визуализируем реальность в Jira.

• Разделяйте типы статусов «в ожидании»/«в работе» не по ответственности команды, а потому работает ли кто-то над задачей, или она копит ожидания. Без этого мы не сможем мерить эффективность потока.

• Старайтесь проектировать процессы так, чтобы работа не возвращалась назад по процессу, а если «правки после review» настолько масштабные, что их нельзя внести в статусе review, то собирайте метрики (автоматически) на такие возвраты (это плохой звоночек).

Стандарт по Доскам
Ключевые тезисы:

• Сделайте максимально простой и широкий фильтр, по которому задачи попадают на доску (в идеале: по проекту, по лейблу, по связям). Если в вашем фильтре 4 AND и 1 OR, то, скорее всего, вы делаете что-то не так. Если какие-то из этих задач вам в моменте на доске не нужны — отфильтруйте их.

• Лучше иметь одну общую доску, разделённую квик фильтрами и свимлейнами, чем засорять проекты десятками мини-досок, которыми через месяц все перестают пользоваться.

• Если вам нужно собрать аналитику по проекту, и вы не член команды — сделайте для этого отдельную аналитическую доску, с указанием автора. Например, Ruby Analytics Maks.F (Макс, привет).

• Если в одной колонке у вас больше 1 статуса — добавьте отображение статуса в карточку.

• Если у вас есть дедлайны — обозначайте близость дедлайна цветами карточки.

• Если у вас есть SLA — обозначайте близость истечения SLA цветами карточки.

• Если вы следите за LT — обозначайте выход за пределы нормы цветами.

• Если у вас используются не стандартные поля — не забудьте добавить их в Detail View.

• Изменяйте Detail view так, чтобы вам было удобно проводить синки по доске.

• Если процесс слишком большой — разбейте его на две доски (UpStream / DownStream).

• Для коммуникаций с заказчиками и представителями бизнеса можно и стоит делать «обобщённую доску», где все ваши производственные статусы будут объединены в одной колонке — Delivery, и т.д.

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

• На активность (testing), её буфер (ready for testing), или выходной буфер (testing done) правильно делать сгруппированный WIP лимит.

Скажем прямо, обо всём этом мы давно договорились, и видение у нас примерно одинаковое. Стандарт по полям и формам мы быстренько подготовили, когда у нас некоторые коллеги начали попытки возведения китайских стен — имею в виду комплекс мер, чтобы поставить задачу в их Jira-проект было МАКСИМАЛЬНО СЛОЖНО! Стандарт нам очень помог справиться с этими ситуациями. В остальном их формализация — своего рода технический долг.

Итак, вот уже процессами в Jira занимается не только наша команда, но и целое внутреннее сообщество, даже есть некие стандарты.

Но как менять майндсет массового пользователя и Project Lead'ов многочисленных проектов? Главное — относитесь к ним по-людски. Jira для них — инструмент, который должен помогать делать работу. Если им неудобно — это, логичным образом, будет вызывать боль. Если они несут дичь — значит, у них нет знаний и понимания. Помогайте им расширять свой кругозор и устраняйте болевые точки.

Вот, что мы начали делать.

DDD — Documentation Driven Development.

Если тот или иной Project Lead обращается к нам за новой автоматизацией, изменением WorkFlow или форм, то мы начинаем задаваться вопросом, а есть ли у него документация? А если найдём? Нет? Как жалко, давай мы тебе поможем ею обзавестись и сначала задокументируем твой текущий процесс, со всякими нюансами и автоматизациями на единой доске в Miro. А потом уже сядем и будем смотреть, чего и как в нём будем менять.

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

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

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

Поэтому мы сделали несколько инструментов и выложили их в доступ на всю компанию.

Конструктор форм

Этот инструмент как раз помог нам спасти Jira от китайских стен.

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

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

Пользователю остаётся скопировать нужные ему поля и перенести их на область формы. Использование этого конструктора выглядит следующим образом:

Конструктор WorkFlow

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

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

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

В эту же доску включаются скриншоты автоматизаций, чьи действия описываются в карточках. Текст оборачивается в ссылку на редактирование автоматизации, поэтому вы можете не открывать Jira → Проект → Настройка → Автоматизации → №512, а сразу из документации открыть нужную автоматизацию.

Автоматизации, которые отрабатывают по крону или редактированию, а не по transition, просто выносятся в независимый блок рядом с процессом.

Вот, например, более сложный процесс в более крупном отделе:

Стрелочка 1 — указывает на скриншот кода из ScriptRunner. У этого процесса нетривиальный behavior. Он ограничивает типы задач, которые могут ставить внешние заказчики. Во многих командах есть типы задач для ведения реестра гипотез по улучшению процессов, а также тех.декомпозиция. Такие типы задач могут ставить только члены команды. В соответствующей этому ограничению карточке есть ссылка на редактирование скрипта, чтобы не искать behaviour в списке ScriptRunnera.

Стрелочка 2 — указывает на скриншот Automated WorkFlow из n8n, который создаёт задачи через обработку событий, происходящих во внешнем сервисе (в данном случае AirTable). И там, конечно, также есть ссылки на редактирование.

Стрелочка 3 — указывает на автоматизации, которые работают не по Transitions. Сейчас мы стремимся к тому, чтобы подобная документация была по каждому проекту в нашей Jira, но отдаём себе отчёт в том, что это будет не скоро. Поэтому просто придерживаемся принципа: если что-то меняем, то сначала документируем.

Самообслуживание

Раньше мы старались выполнить любой запрос, который попадает в команду или сыпется в чат, своими силами. Теперь, прежде чем засучить рукава, обязательно задаёмся вопросом, может ли заказчик сделать это сам. Если ответ положительный, то мы стараемся задавать вопрос: "Что тебе мешает сделать это самостоятельно?"

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

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