Жизнь после Jira: как команда из 20 человек управляет сложными digital‑проектами

Весной 2022 года мы в КЛБР практически одновременно потеряли 2 ключевых инструмента. Сначала пропал доступ в Jira, где вели все проекты, следом ушел Slack, где команда переписывалась. Новую систему нужно было внедрить быстро — без потери задач и истории проектов. После долгих поисков остановились на Kaiten.

Меня зовут Вера, я руководитель студии КЛБР. Дальше расскажу, что изменилось в работе нашей команды за последние 4 года.

Кто мы такие и чем занимаемся

КЛБР («Колибри») — студия проектной разработки. В команде 20 человек: фронтенд- и бэкенд‑разработчики, DevOps, менеджеры, аналитики, SEO‑специалисты и дизайнеры.

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

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

Формат сотрудничества при этом бывает разным. Есть задачи на поддержке с загрузкой 20–30 часов в месяц. Есть крупные проекты, где команда стабильно работает по 80–100 часов. Бывает и так, что клиент меняет бизнес и ставит развитие продукта на паузу, а мы в это время продолжаем поддерживать инфраструктуру и ждем нового этапа развития.

До Kaiten была Jira. До Jira — много попыток

За 14+ лет опыта мы перепробовали несколько систем. Сначала был Trello — на старте его хватало. Команда тогда была меньше, задач тоже немного, и простых канбан‑досок было достаточно.

Затем был Bitrix24. Но система оказалась слишком тяжелой для повседневной работы. Мы даже специально засекали время: постановка одной элементарной задачи занимала около 3,5 минут.

В итоге перешли в Jira. На тот момент это был самый удобный вариант: понятные доски, отчеты, интеграции, привычная логика работы с задачами. Параллельно использовали Slack для внутренней коммуникации. Команда спокойно прожила в этой связке несколько лет.

Но в 2022 году все резко изменилось

Сначала мы потеряли доступ к Jira. Причем произошло это раньше, чем у многих российских компаний: из‑за особенностей проектов наша команда оказалась среди первых подсанкционных клиентов. Следом перестал нормально работать Slack. Фактически нужно было заново пересобрать весь рабочий стек: от командных задач до проектной поддержки.

В итоге победил Kaiten. Во многом — из‑за мелочей, которые сильно влияют на ежедневную работу. Например, в Kaiten карточка открывается прямо поверх доски. Закрыл задачу — и сразу вернулся обратно к проекту. А в WEEEK на тот момент логика была другой: при открытии задачи приходилось переходить на отдельный белый экран, а потом заново возвращаться назад. Плюс у Kaiten уже тогда была возможность быстро мигрировать из Jira, достаточно гибкая настройка досок под разные процессы, а еще интеграция с GitLab.

Переехали быстро, потому что были среди первых

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

Как мы организовали работу в Кайтене

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

Под каждый большой проект создали отдельное пространство

Если проект небольшой, ему хватает одной доски. Если клиент крупный — внутри пространства появляется сразу несколько досок.

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

Внутри карточек не только ТЗ, но и своя логика работы

В работе используем несколько типов карточек:

1. «Проект» — это верхнеуровневая карточка.
2. «Таск» — большая задача, где описывается суть, требования, макеты, общее ТЗ и кросс‑задачная информация.
3. «Сабтаск» — когда большую задачу нужно разделить между фронтендом, бэкендом, дизайном или сборкой. Тогда каждый специалист получает свою ветку работы и трекает время именно туда.
4. «Баг» — если что‑то сломалось и нужно быстро исправить.
5. «Хот прод» — задачи, которые требуют немедленной реакции. Например, если на продакшене обнаружилась критичная ошибка или нужно срочно внести изменение, от которого зависит работа сервиса.

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

Менеджеры перестали тратить 1,5 часа утром только на планирование

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

В итоге вернулись к Кайтену и попробовали собрать приоритизацию внутри него. Получилось вот так:

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

Каждое утро проектные менеджеры пересматривают этот порядок и при необходимости обновляют его. А специалист открывает свою доску и сразу видит, за что браться в первую очередь. За счет этого нам удалось сократить дейлики с 1,5 часов до 15–20 минут.

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

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

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

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

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

Если задача связана с интерфейсом или дизайном, подключаются дизайнеры и проводят отдельный дизайн‑ревью. И уже потом задача отправляется клиенту на проверку. А когда клиент подтверждает результат, карточка уходит на прод и дальше в архив.

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

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

Со своей стороны мы тоже частично поддерживаем фонд: например, не включаем в оплату 30% часов дизайна, тестирования и менеджмента.

Что еще настроили внутри Kaiten

Вот что мы внедрили дополнительно.

Метки. В больших проектах без них быстро начинается хаос — все задачи смешиваются в один поток. Например, у «Не напрасно» через метки мы разделяем задачи между разными проектами фонда. Так мы лучше ориентируемся внутри досок, фильтруем задачи и собираем отчеты по трудозатратам.

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

Автоматизации. Сложных автоматизаций у нас немного, но базовые вещи сильно разгружают команду в ежедневной работе. Например, когда задача переходит в колонку «Проверка менеджера», Kaiten автоматически назначает ответственным менеджера проекта. Если карточка уходит в тестирование — переключает ее на тестировщика. А когда задача готова к проверке клиента, снова возвращает менеджеру.

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

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

Завели базу знаний и используем ее для быстрого погружения в проект

Со временем мы поняли, что в длинных проектах сотрудники тратят слишком много времени не на саму работу, а на поиск контекста:

• где лежат доступы;
• где документация;
• какая ссылка актуальная;
• кто вообще отвечает за этот продукт.

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

При этом чувствительные данные хранятся отдельно. Для этого у нас есть отдельное хранилище.

Добавили отчеты, чтобы заранее замечать риски

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

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

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

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

В Кайтене нам нравится многое, но без спорных моментов тоже не обошлось

1. Независимость от подрядчиков. Во многих системах даже небольшая настройка превращается в отдельный квест: нужно искать интегратора, что‑то дописывать, покупать дополнительные модули. В Кайтене большую часть процессов мы настраиваем сами под свою работу.
2. Работа техподдержки. Мы несколько раз приходили с вопросами по отчетам и настройкам в техподдержку Кайтена — и всегда получали быстрые и подробные ответы. Для B2B‑сервисов такая работа саппорта сегодня — скорее, приятное исключение.
3. Чатбот. Все уведомления по задачам сразу приходят в мессенджер: можно быстро посмотреть, что происходит, ответить в комментариях или остановить слишком бурное обсуждение, пока оно не превратилось в отдельный чат на 200 сообщений.

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

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

Но при этом некоторые новые функции действительно хорошо приживаются в ежедневной работе. Нам особенно понравилась ИИ‑расшифровка звонков. Теперь записи созвонов мы расшифровываем внутри Кайтена и сразу прикрепляем к задаче или доске.

Что мы поняли после переезда с Jira

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