Как наша команда разработки перешла из Jira в таск-трекер MOGU

Выбор решений

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

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

Трудности перевода перехода

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

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

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

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

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

Простой, интуитивно понятный интерфейс MOGU также стал значимым аргументом в пользу перехода.

Как наша команда влюбилась в канбан

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

Затем начался полет фантазии. Первая колонка — Roadmap. Все знают, что это, и мы не будем на этом останавливаться. Далее идет колонка Ready For Dev – здесь размещаются задачи, для которых уже определены требования. Ответственному разработчику остается только перенести эту задачу к себе в колонку.

Backend, Frontend – здесь все взаимосвязано, backend-разработчик перетаскивает себе задачу из Ready For Dev, выполняет и передает ее Frontend-разработчикам. Затем переходим к этапу – Ready for Test. После завершения разработки мы проводим тестирование. Сначала проводится проверка дизайна: визуальная составляющая функции должна соответствовать макету (кнопки, расстояния, цвета). Затем вступает в игру тестировщик, который проверяет функциональность.

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

Работа над ошибками или доска с багами

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

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

Заключение

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

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