Репозиторий проблем клиента в JIRA

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

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

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

Интересно, что компания Atlassian тоже думала об этом и в 2023 году выпустила JIRA Product Discovery. У меня не было возможности его сразу изучить, потому что он совместим только с cloud JIRA, а мы работали с серверной версией. Недавно я смогла ознакомиться с продуктом и обнаружила, что мы мыслили очень похоже. Компания Atlassian берет плату за каждое место в JIRA Product Discovery и она совместима только с cloud JIRA. Мой репозиторий могут использовать все сотрудники компании, у которых есть доступ в JIRA, нужно только его настроить.

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

Для дедупликации я создала специальное поле "Проверка заполнения пройдена", которое могут использовать только модераторы.

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

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

Следующим этапом стало добавление возможности приоритизации проблем клиента. Я добавил поля Impact, Effort и Score, что казалось очень логичным. Теперь я знаю, что Atlassian в продукте JIRA Product Discovery сделали то же самое.

Но самое главное: возможность добавления “Задачи на решение” - эпика или таска в JIRA, в рамках которого решается проблема. Добавление “задачи на решение” сразу переводит проблему в репозитории в статус “in progress”, а завершение “задачи на решение” переводит проблему в репозитории в статус “done”. И все, больше не нужно автоматически обновлять статусы. Мои товарищи по разуму из компании Atlassian тоже сделали такую настройку со статусами.

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

Недостатки:

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

Теперь я работаю над следующим этапов эволюции в JIRA Product Discovery с крутым напарником, и это будет еще одна история.