14+ лет истории без потерь: как КЛБР переехала из Jira в Kaiten за один выходной

Кайтен

Управляйте задачами, проектами и командой в одном месте

Попробовать бесплатно

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

В КЛБР эта задача особенно актуальна: с некоторыми заказчиками студия работает больше 10 лет. Поэтому вынужденный уход из Jira был для команды не обычной сменой таск-трекера, а операцией по спасению накопленных знаний.

О том, как прошла миграция в Kaiten и во что выросла новая система управления проектами за 4 года, рассказала Вера Ясюкевич, CEO студии КЛБР.

О компании

КЛБР, или «Колибри», — студия проектной разработки, которая создает и развивает сложные digital-продукты с 2012 года. В команде 20 человек: frontend- и backend-разработчики, DevOps-инженеры, менеджеры, аналитики, дизайнеры и SEO-специалисты.

За время работы команда получила несколько профессиональных наград, среди которых первое место в Рейтинге Рунета в категории «СМИ, издательства» за проект «Код.ру». В портфолио КЛБР также есть награды Tagline Awards и первые места премии Ruward в номинациях «Агентство года» и «Техническая поддержка». 

Сами проекты при этом могут быть разного масштаба и на разных стадиях жизненного цикла. Например, на некоторые из них уходит по 20–30 часов в месяц, а на другие — 80–100. Иногда случаются ситуации, когда заказчик временно приостанавливает развитие продукта, но студия продолжает поддерживать его инфраструктуру.

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

Поэтому вести задачи в таск-трекерах команда начала почти сразу. За 14+ лет КЛБР сменила несколько систем — требования к ним росли вместе с количеством и сложностью проектов.

От Trello к Jira: как команда искала рабочий инструмент

Первым таск-трекером в компании стал Trello. Пока команда была небольшой, простых канбан-досок вполне хватало: на них размещали задачи и отслеживали, как они движутся между этапами.

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

В поисках следующего решения в КЛБР протестировали Битрикс24. По набору функций сервис подходил, но для ежедневной работы оказался слишком громоздким. Однажды команда даже провела эксперимент и измерила скорость создания типичной задачи: на одну карточку уходило в среднем 3,5 минуты. При десятках новых задач в день эти минуты складывались в часы потраченного впустую времени, поэтому от системы решили отказаться.

Подходящим решением на тот момент стала Jira. Там была и знакомая IT-специалистам логика работы, и гибкие доски, и интеграции с необходимыми отчетами. Все обсуждения по задачам при этом вели в Slack.

Несколько лет связка Jira и Slack закрывала основные потребности студии. Менять ее в КЛБР не планировали, но 4 года назад доступ к обоим сервисам оказался под угрозой.

Два рабочих инструмента перестали работать почти одновременно

Из-за специфики проектов КЛБР оказалась среди первых российских пользователей, которые потеряли доступ к Jira. Вскоре проблемы начались и со Slack.

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

• возможность перенести задачи вместе с историей;
• интеграцию с GitLab;
• гибкую настройку досок под разные процессы;
• понятный интерфейс для ежедневной работы;
• возможность использовать российское решение без риска внезапной блокировки.

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

Например, в Kaiten карточка открывалась поверх доски: после закрытия задачи сотрудник сразу возвращался в проект и не терял контекст. А в WEEEK на тот момент задача открывалась на отдельном экране, из-за чего приходилось постоянно переключаться между вкладками.

В пользу Kaiten также сыграли готовый механизм миграции из Jira, интеграция с GitLab и возможность настраивать отдельные доски под разные маршруты задач. По совокупности этих критериев команда остановилась на нем.

Миграцию провели за несколько часов

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

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

Успешные компании уже используют Кайтен Попробуйте расширенный функционал на своем проекте бесплатно

Попробовать

Для каждого большого проекта создали отдельное пространство

Сейчас в Kaiten сосредоточена почти вся операционная работа КЛБР: клиентские задачи, проектная документация, инструкции и внутренние процессы.

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

• разработка;
• техническая поддержка;
• баги;
• API;
• дизайн-ревью;
• задачи на продакшене.

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

Тип карточки определяет маршрут задачи

В КЛБР используют 5 основных типов карточек:

• «Проект» — верхнеуровневая карточка, которая объединяет связанные направления работы.
• «Таск» — крупная задача с требованиями, техническим заданием, макетами, ссылками и информацией, общей для нескольких исполнителей.
• «Сабтаск» — отдельная часть большой задачи. Сабтаски создают, когда работу нужно разделить между frontend-, backend-разработкой, дизайном или сборкой.
• «Баг» — ошибка, которую необходимо исправить.
• «Хот прод» — критичная задача, требующая немедленной реакции. Такой тип используют, например, при сбое на продакшене или срочном изменении, от которого зависит работа сервиса.

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

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

Как команда сократила дейлики с 1,5 часов до 15–20 минут

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

Сначала приоритеты пытались вести в Notion, Yonote и других сервисах. Получилась неудобная схема: сами задачи находились в Kaiten, а порядок их выполнения — в другом инструменте. Сотрудникам приходилось постоянно переключаться между системами и сверять данные.

В результате приоритизацию тоже перенесли в Kaiten. Для этого в карточки добавили пользовательское поле «Размер» со значениями от 1 до 5. Название осталось техническим, но фактически цифра показывает место задачи в очереди на день.

Каждое утро менеджеры проверяют последовательность и при необходимости меняют значения. 

Как задача проходит путь от клиента до продакшена

После того как менеджеры расставили приоритеты, каждая карточка начинает двигаться по своему рабочему маршруту. Этот процесс рассмотрим на примере проекта фонда медицинских решений «Не напрасно», с которым КЛБР сотрудничает уже много лет. Фонд помогает жителям России получать доступ к качественному лечению и одновременно развивает несколько digital-проектов.

Задачи клиента ведутся в WEEEK. Там заказчик описывает новую функцию, доработку, баг или обращение в поддержку. Затем менеджер КЛБР переносит запрос в Kaiten и создает карточку для внутренней команды, куда добавляет всю необходимую информацию:

• описание задачи;
• требования и техническое задание;
• макеты;
• ссылки;
• комментарии клиента;
• связанные карточки.

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

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

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

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

Следующий этап — тестирование. Если изменения затрагивают интерфейс, команда также проводит дизайн-ревью. Только после внутренних проверок результат передают клиенту. 

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

Как команда учитывает время и ресурсы 

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

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

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

Отчеты помогают вовремя заметить зависшие задачи и перерасход

Для отслеживания трудозатрат в КЛБР используют встроенный отчет «Учет времени». Специалисты фиксируют часы в карточках, а менеджеры ежемесячно смотрят, над какими задачами работала команда, сколько времени ушло на каждого клиента и где фактические затраты превысили оценку.

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

КЛБР также тестировала ресурсное планирование, но в текущей структуре оно не прижилось. Проекты находятся в разных пространствах и устроены по-разному, поэтому единый отчет получался перегруженным и не давал компании полезной картины. 

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

Теперь новые участники быстрее погружаются в проекты

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

• краткую информацию о проекте;
• документацию и полезные ссылки;
• описание рабочих процессов;
• контакты ответственных;
• инструкции для новых участников.

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

Что команда оценила и с какими сложностями столкнулась

Ниже — список функций, которые помогают КЛБР в ежедневной работе: 

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

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

Уведомления в мессенджере. Чат-бот сообщает о новых комментариях и изменениях в задачах. Сотрудник может быстро подключиться к обсуждению задачи прямо из мессенджера. 

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

Привыкания требовали и заметные изменения интерфейса. Например, после того как кнопку Kaiten AI перенесли на место поиска, некоторые сотрудники еще несколько недель по привычке открывали не тот раздел.

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

Переезд из Jira стал поводом пересобрать процессы

Весной 2022 года перед КЛБР стояла конкретная задача: перенести проекты в новую систему, не потерять накопленную историю и не остановить работу команды. Однако миграция не ограничилась переносом данных.

За 4+ года в Kaiten команда:

• разделила разработку, техническую поддержку, баги и другие типы работы по отдельным доскам;
• стандартизировала постановку задач с помощью типов карточек и шаблонов;
• перенесла приоритизацию в Kaiten и сократила дейлики с 1,5 часов до 15–20 минут;
• автоматизировала назначение ответственных при переходе между этапами;
• собрала проектную документацию в базе знаний;
• настроила учет времени и отчеты по зависшим задачам и переработкам;
• сохранила историю долгосрочных проектов в одном рабочем пространстве.

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