Почему IT-команда Домиленд стала использовать Kaiten вместо Яндекс.Трекера

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

Технический директор Домиленд Кирилл Воронов рассказал, как ради этой аналитики все IT-команды компании перешли из Яндекс.Трекера в бесплатный аналог — Kaiten, и почему новый сервис оказался более удобным для организации рабочих процессов.

Немного о Домиленд

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

Платформа состоит из 30+ продуктов, доступных сотрудникам застройщика и управляющей компании, покупателям, дольщикам и жителям на платформах iOS и Android, десктопных версиях и голосовых поверхностях.

Партнерами Домиленд являются более 500 организаций, среди которых крупные застройщики и УК, а сам разработчик ежегодно признается лучшим на рынке PropTech.

Использовали Яндекс.Трекер, пока компания не стала масштабироваться, и понадобилось больше аналитики

У нас есть несколько продуктовых команд, которые поставляют новые фичи в продакшн. Большинство сотрудников работают с продуктами для ЖКХ, часть развивают Витрину для застройщиков и маркетплейс услуг для жителей.

В Домиленд есть также команда самой платформы, в ее состав входят сотрудники, которые отвечают за продукты для бэк-офиса, развивают Дизайн-систему Домиленд, а также DevOps и QA.

Для организации работы команд с 2017 года мы использовали Яндекс.Трекер и он нас устраивал. Однако, когда команда выросла до 50 человек, а продуктов стало более 20, появилась необходимость анализировать, соотношение затрат на каждый отдельный продукт к выручке, которую он приносит.

Набор продуктов у каждого партнера Домиленд, можно сказать, уникальный. Кто-то покупает только часть продуктов для УК, кто-то добавляет к ним технологии Smart Building, а некоторые застройщики собирают в суперапп все продуктовые решения платформы. Если мы вкладываемся в разработку какого-то продукта, но приобретают его лишь 2 управляющие организации из 500, то зачем его развивать? Чтобы понять, стоит ли игра свеч, нужно анализировать, сколько времени мы потратили на каждый конкретный продукт и сколько с его помощью мы заработали. Для этого мы используем учет времени по абсолютно каждой задаче.

Увы, в Яндекс.Трекере мы не смогли получить адекватный отчет, который бы демонстрировал: на продукт «А» затрачено 100 часов в этом месяце. Пробовали собирать данные и через стандартный конструктор отчетов, и через API – все тщетно.

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

Как реализовали эту задачу в Кайтене

В альтернативе Яндекс.Трекера Кайтене есть модуль «Учет времени». Он позволяет фиксировать, сколько времени у каждого сотрудника ушло на работу с каждой задачей, и потом собирать это в отчет.

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

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

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

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

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

Перенести остальной рабочий процесс было не сложно – все нужные для этого инструменты были в Кайтене

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

Как организовали работу продуктовых команд

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

Пространства всех команд имеют одну структуру:

Сверху находится доска с «эпиками» (Product) — это задачи, которые содержат user story, а не просто описание того, что нужно сделать. Их формулирует product, а дизайнер этой команды прикрепляет первые дизайн-макеты.

Когда эпики запланированы, проводится grooming-встреча с командой. Ребята смотрят задачи, задают вопросы, и дальше мы делим их на подзадачи — они попадают на доску «Задачи на следующий спринт» и лежат там, пока их не возьмут в спринт.

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

Отдельно есть доска “Дизайна”. Основная работа дизайнера начинается еще до начала спринта.

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

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

Разумеется, есть доска «Техдолг». С ними тоже работает дежурный разработчик в то время, когда у него нет задач на доске с инцидентами.

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

Таким образом организованы рабочие пространства всех продуктовых команд. У нас даже есть отдельное пространство-шаблон «Эталон разработки». Выводя новую команду, мы просто копируем шаблон, и команда начинает в нем работать. Очень удобно!

Работая по такой системе мы имеем два очень важных преимущества:

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

Контролируем релиз мобильных приложений с помощью чек-листов

На каждой платформе релизы устроены по-разному. На backend фичи выпускаются ежедневно, а мобильные приложения мы готовим заранее и выкладываем каждые 2-3 недели, потому что это более сложный процесс.

Подготовка релиза – отдельная большая задача в Kaiten, к которой стягиваются подзадачи из разных пространств. Дальше делается общий кросс-командный регресс — сборку смотрят QA из всех продуктовых команд.

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

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

Приоритизируем задачи с помощью пользовательских полей

Команды самой платформы (DevOps, QA, Дизайн-система), не работают по Scrum, они планируют задачи на неделю вперед из своего бэклога. При этом важно делать это в соответствии с приоритетом. У нас их четыре: низкий, средний, высокий и блокер – самый срочный.

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

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

Что мы имеем в итоге

• Я, как руководитель, получаю прозрачность работы. Это не сложно оформить в конкретные метрики, но даже по субъективным ощущениям, информация в Кайтене воспринимается проще — мне легче понимать, что происходит, глядя на удобно организованные пространства, нежели, как это было в ранее используемом трекере.
• Продуктовые команды получают отчетность по затраченному времени и могут планировать развитие продуктов, опираясь на данные.
• Финансовое подразделение Домиленд и другие руководители, видят понятную управленческую отчетность и могут углубляться до любого уровня детализации.
• Все сотрудники работают с приятным интерфейсом.

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

Сейчас, вслед за производственными командами, в Кайтен внедряются процессы и других подразделений группы компаний Домиленд.