«ЛАДА Цифра» — это стартап «Лада-Имидж», одной из дочерних компаний группы «АвтоВАЗ». А еще это уникальный микс из талантов разных людей, которые приняли вызов создать цифровое будущее в автомобильной индустрии. Команда успела поработать в крупных проектах и знает про IT не из учебников. 

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

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

Привет, меня зовут Юрий Москалев, я руководитель разработки в «ЛАДА Цифра». Расскажу, как мы внедрили Kaiten и организовали цикл разработки с его помощью.

Выбрали Kaiten среди 20+ сервисов

Наши коллеги из «Лада-Имидж» пользовались Яндекс Трекером. Но для IT-команд он не всегда подходит: разработка состоит из множества сложных процессов, а в сервисе, на момент старта работы, не было встроенных инструментов отчетности. Мы не могли выгрузить отчеты о выполненных задачах и по другим метрикам, которые используем.

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

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

Мы перебрали около 20 инструментов и протестировали каждый. В итоге осталось два финалиста — Kaiten и EvaProject. Выбрали первый — скорость работы у него оказалась выше. Перешли в Kaiten в марте 2024 года.

Миграция и адаптация в Kaiten происходили непросто. Логика его работы построена на основе Канбан-досок и во многом отличается от Jirа, привычной для айтишников. Когда мы только начинали, я мыслил в парадигме Jira и пытался выстроить в Kaiten похожие сценарии. Но потом понял: нужно отталкиваться не от того, как функционируют уже знакомые нам таск-трекеры, а от устройства и задач бизнеса, которые необходимо отобразить. И уже их облекать в парадигму конкретного сервиса. Тогда это будет работать.

Настроили воркфлоу на основе цикла разработки ПО и фреймворка Scrum

Цикл разработки программного обеспечения состоит из шести этапов: анализ требований → планирование → проектирование и дизайн → поставка фичи → тестирование → развертывание.

Мы работаем по Scrum: работа делится на двухнедельные спринты, в течение которых мы выполняем определенный объем задач. Чтобы управлять потоком задач, мы ввели в работу два стандарта:

• Definition of Ready — стандарт, по которому должна быть описана любая поступающая к разработчикам задача.

• Definition of Done — стандарт, по которому команда разработки выдает готовые задачи.

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

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

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

• Спринт-ревью — команда разработки защищает реализацию перед продактом. Процесс замыкается.

Визуализировали спринт

Задачи текущего спринта находятся в пространстве «Разработка». В нем три основные доски: «Бэклог», «Цели спринта» и «Спринт».

«Цели спринта». Здесь собраны главные направления спринта, чтобы они всегда были перед глазами у команды. Мы настроили правила автоматизации в Kaiten таким образом, что при перемещении любой дочерней карточки в бэклог спринта родительская карточка помещается на доску «Цели спринта».

«Спринт». Мы работаем стандартными двухнедельными спринтами, в названии доски прописываем номер и даты текущего спринта. Столбцы на доске соответствуют принципам Канбан и этапам спринта по Scrum: «Бэклог», «В ожидании», «В работе», «Ревью», «Готов к релизу». Так мы наглядно видим, на какой стадии находится каждая задача и как продвигается работа.

Здесь мы также применили правила автоматизации. Когда первая дочерняя карточка попадает в колонку «В работе», родительская карточка также перемещается на доске целей в колонку «В работе». Если все дочерние карточки прошли этап тестирования, родительская карточка автоматически перемещается в колонку «Готово».

Создали воронку бэклогов

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

Карточки, которые прошли этап Discovery и готовы к передаче в команду разработки, попадают в пространство «Воронка бэклогов». Оно разбито на два этапа, у каждого своя колонка.

Сначала продакт-менеджер помещает карточку в первый столбец — «В рефайн». На отдельной встрече продакт-менеджера с командой разработки происходит обсуждение каждой задачи в этом столбце. Команда разработчиков принимает решение, достаточно ли информации и материалов по каждой из задач и готова ли команда взять эту задачу в декомпозицию и оценку. Если все прошло хорошо, команда разработки забирает ее в столбец «В оценку», чтобы декомпозировать задачу с помощью инструмента «Дочерние карточки», выставить оценку в часах для декомпозированных дочерних задач. Так, перед тем как попасть в спринт, задача становится максимально подробной — можно работать над ней в нескольких параллельных потоках.

Оцененные и декомпозированные задачи переходят в столбец «В разработку». Продакт-менеджер еще раз приоритезирует задачи и передает на доску Delivery.

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

В Kaiten есть функция дублирования досок, когда одна доска одновременно отображается в разных пространствах. Если внести на ней изменения в одном пространстве, они автоматически отобразятся в другом. У нас доска Delivery дублируется в пространстве «Разработка». Именно там разработчики видят оцененные по времени задачи и забирают их в текущий спринт.

В карточке задачи настроили поля, чтобы получать максимально точное описание задачи

Каждая карточка в Kaiten — это задача, ей присваивается один из типов: Task для задач, Feature для запуска новых фич, Bug для сообщений о проблемах или EPIC для группировки нескольких задач по одной теме. Мы проставляем тип, чтобы сразу видеть, к какой категории относится задача, и задавать условия для автоматизации. Кроме типа, в карточке мы предусмотрели следующие поля:

• Метки — например, Frontend и Backend.

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

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

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

• Размер — количество Story Points, то есть условных единиц, которые используют при оценке задачи по фреймворку Scrum. Позволяет прикинуть, сколько ресурсов на нее уйдет.

• DoR — критерии, которые определяют, готова ли карточка к разработке.

• DoD — признаки, по которым мы понимаем, завершена ли задача.

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

Используем два отчета — пока больше не нужно

По каждому спринту мы отслеживаем работу с помощью двух основных отчетов: «Скорость команды» и «График сгорания».

«Скорость команды». Оцениваем нашу производительность: какой объем задач взяли в спринт и сколько из них выполнили.

Параметры оцениваются по количеству Story Points в поле «Размер карточки». На графике в отчете два столбца. Левый показывает сумму оценок по задачам, которые в начале спринта находились в колонках «Очередь» и «В работе». Правый — в колонке «Готово» в конце периода.

«График сгорания». Отслеживаем прогресс спринта. Так мы контролируем, выполняется ли план по работе, а если есть задержки — вовремя выявляем их.

На графике две линии. Голубая показывает идеальный ход работы, оранжевая — актуальный.

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

Согласовываем релизы через модуль «Служба поддержки»

Перед выпуском релиза мы согласовываем его с другими подразделениями — это сводит к минимуму риск ошибок. Чтобы упростить процесс согласования, мы используем в Kaiten модуль «Служба поддержки» (Service Desk). В нем можно настроить форму, в которой пользователь будет оставлять заявку, и она в виде карточки задачи будет попадать в Kaiten. 

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

Поэтому, когда заканчиваем работу над фичей, в форме модуля Service Desk мы создаем «Запрос на изменения», а в нем заявку со следующими полями:

• название и описание — суть фичи;

• вид релиза — например, продуктовый, операционный или технический;

• список систем и сервисов — в каких системах выпускаем релиз: набор опций зависит от вида, который выбрали на предыдущем этапе;

• дата релиза.

Заполненная заявка в виде карточки попадает в отдельное пространство Request for Changes, и к ней автоматически добавляется ответственный. В пространстве несколько треков, а для перемещения карточек задач между ними у нас настроены автоматизации.

Main. Это доска, на которую карточка заявки попадает в первую очередь, — основной трек, на котором отслеживаются релизы. Изначально карточка находится в столбце «Очередь». Сотрудник, который назначен ответственным за задачу, двигает карточку в следующий столбец «В работе». Начинается процесс согласований.

«Согласования». Здесь отслеживаем, согласован ли релиз. Как только карточка задачи на доске Main оказывается в работе, на доске согласований в первом столбце «Очередь» формируется список дочерних карточек задач для разных согласующих. Они могут быть разными в зависимости от типа релиза. Согласующие перемещают дочерние задачи по колонкам «Требует уточнения» и «Согласовано». 

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

«Этапы релиза». Трек показывает, на какой стадии находится релиз: «Запланирован», «В работе» или «Готово». Сюда карточка задачи попадает автоматически после согласования, когда на треке Main ее передвинули в столбец «На исполнении». 

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

Применяем OKR-подход

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

В Kaiten мы создали отдельное пространство для этого. На нем есть доска «Карта целей» со столбцами «Новая», «В работе» и «Завершено». В них находятся цели, которые ставят продуктовые лидеры. Так мы понимаем, на какой стадии исполнения находится каждая цель.

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

Переводим в Kaiten вторую компанию

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

Сейчас в планах организовать в Kaiten работу двух компаний: «ЛАДА Цифра» и «Лада-Имидж». Второе подразделение уже подключено в аккаунте, мы начинаем иерархически разводить их с первым, чтобы у каждого были свои пространства.

Чтобы мы в «ЛАДА Цифра» могли реализовывать все более трендовые и экологичные продукты, нам нужна топовая команда. Часть уже есть, но мы продолжаем активно развиваться и искать наших сотрудников. Все актуальные позиции можно найти на нашем сайте ladadigit.ru.