«Клиенты видят, как мы работаем, и их лояльность повышается»: почему студия разработки сменила Яндекс Трекер и Планфикс на Kaiten

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

Amiga — агентство продуктовой заказной разработки полного цикла: мы занимаемся аналитикой, бэкенд- и фронтенд-разработкой, дизайном, тестированием. Клиент приходит с запросом, а уходит с готовым результатом — вплоть до релиза. Например, мы с нуля создавали для металлургической компании LMS-систему, а еще работаем с SOKOLOV, Сбером, ВТБ и другими крупными клиентами. Одно из наших приложений попало в рейтинг Forbes.

Студия была основана в 2021 году. С того времени мы выросли до штата в 70 человек и сменили несколько таск-трекеров. Когда в команде было 5–10 сотрудников, пользовались Яндекс Трекером. Он стал отправной точкой в управлении задачами, но вскоре мы поняли, что в сервисе неудобно организовывать работу нескольких подразделений.

Команда расширялась, и мы перешли на Планфикс. Это гибкий сервис с большим набором функций, но он оказался слишком сложным. Многие сотрудники не понимали, как в нем смотреть актуальные задачи, пользоваться фильтрами и другими возможностями. А еще каждый менеджер вел проекты по-своему: не было единых стандартов управления задачами. Когда сотрудники переходили из одного проекта в другой, им каждый раз приходилось с нуля погружаться в особенности управления.

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

Мы провели анализ рынка и выбрали Kaiten. Понравилось, что в нем уже настроены все функции, метрики и отчеты, которые были нам нужны.

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

Мы планировали работать в Kaiten по методологии канбан. Она делает процессы прозрачными: на досках видно статус и этап каждой задачи. Это нагляднее, чем таблица или список. Но в итоге разработали свою методологию — AmigaBan. Она почти не отличается от обычного канбана, но некоторые процессы настроены под нас. Что мы сделали:

Выделили под каждый проект свое пространство

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

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

На каждой доске несколько колонок — вертикальных областей, которые делят процесс работы на этапы. Например, на Features их структура соответствует циклу разработки: To Do → Development → Code Review → Ready for Test → Test → To Release → Done. Также есть колонка «Отмена» для задач, которые потеряли актуальность.

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

Еще одна особенность AmigaBan — с документами на доске Requirements мы работаем с помощью свимлайнов, или параллельных дорожек для группировки карточек. Техническое задание при разработке проходит несколько этапов: например, написание, согласование с несколькими командами клиента. Если оно соответствует изначальным требованиям, остается на одной дорожке. Но если клиент меняет требования уже в процессе, переносим документ на следующий свимлайн. Мы видим, что чем выше и правее находится техническое задание, тем больше ресурсов в него вложили, а значит, его нужно как можно скорее закрыть.

Собрали финансовые документы в одном пространстве

Помимо клиентских проектов, у нас есть внутреннее пространство для договоров, актов и других документов. Здесь используем ограничения: например, акт нельзя отправить на оплату без согласования от финансового отдела. Для этого настраиваем две зависимости — по атрибутам и по пути карточки.

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

Используем разные типы задач

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

Чтобы оценить готовность задачи к старту, используем чек-листы. Когда менеджер формулирует задачу, он проверяет, соответствует ли она нашим требованиям, среди которых, например, формализованность, измеримость, понятность для исполнителя. Берем в работу только карточки, в которых заполнены все пункты чек-листа. То же самое с готовыми задачами: например, перед сдачей макета исполнитель проверяет, есть ли у него все адаптивы. Это помогает понять, можно ли брать задачу в работу или отдавать ее на проверку.

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

Анализируем семь основных метрик

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

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

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

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

А какие таск-трекеры предпочитаете вы? Те, в которых нужно всё настраивать с нуля, или готовые к работе сервисы?