«Заказчики были недовольны»: внедрили Kaiten и за 1 месяц увеличили количество релизов в 4 раза

Всем привет! Меня зовут Рафаэль Аревян, я деливери-менеджер в EdTech-проекте, который специализируется на поддержке внутренних пользователей. Хочу рассказать, как мы перешли в Kaiten и повысили производительность выполняемой работы в 4 раза.

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

Тfк было и в IT-компании известного EdTech-проекта, в которую я пришел несколько месяцев назад. Моей основной задачей было навести порядок в рабочих процессах внутри команды и наладить коммуникацию между заказчиком и исполнителем.

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

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

В нашей компании есть IT-департамент, который состоит из 4 команд. Моя команда отвечает за конверсию в покупку. Также мы отвечаем за развитие CRM-системы, платежного кабинета и баз данных — помогаем менеджерам быстрей и удобней переводить лидов в партнеров. Моя основная задача состояла в том, чтобы внести порядок в рабочие процессы команды и улучшить взаимодействие между заказчиком и исполнителем.

До внедрения Kaiten наши рабочие процессы были весьма бессистемными:

  • наша компания работает с Битриксом, но параллельно каждая команда использует свои таск-трекеры для фиксирования задач;
  • ребята из моей команды пользовались ClickUp, но им он не нравился, потому что движение по воронке было запутанным, а корректировки мог вносить только тимлид во время ежедневных встреч;
  • ежедневные встречи затягивались, могли длиться по 1,5 часа, и на них могли обсуждаться довольно узконаправленные темы;
  • мы использовали термин «спринты», но на самом деле не применяли никакой инкрементальной разработки, отсутствовали петли обратной связи, ретроспективы, грумминги и другие практики, связанные с методологией Scrum.

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

  • часто заказчик не получал даже первичной реакции на свой запрос, потому что большая часть заявок терялась в разных таск-трекерах;
  • мы не могли проанализировать время нахождения проекта в работе и ответить на вопрос «Сколько времени займет?»;
  • мы выпускали от 1 до 3 релизов за квартал, несмотря на большую нагрузку задач;
  • у нас не было четкой приоритизации задач.

Мне повезло: команда хотела перемен

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

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

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

Поделитесь своим опытом работы в Kaiten
Если хотите рассказать о своем кейсе, управленческом опыте или стать соавтором статьи, напишите нашему редактору d.lebedeva@kaiten.io

Начали с визуализации всех процессов

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

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

Доска Службы поддержки

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

Доска Дискавери и две очереди бэклога

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

Небольшой фрагмент доски Деливери. На ней больше этапов, но на одном скриншоте будет неудобно их просмотреть

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

Доска для внешних исполнителей. Мы разделили ее на две дорожки. Это позволяет легко определить, кто именно отвечает за выполнение конкретной задачи

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

Распределили фокус работы

Как я писал выше — у нас есть два основных направления в работе. Договорились, что разделим командный ресурс работы в отношении 70/30:

  • 70% ресурсов отводится на развитие продукта и тестирование новых функций;
  • 30% наших усилий отводится на поддержку и устранение ошибок, чтобы обеспечить стабильную работу продукта.
Доска Деливери, поделенная на две дорожки — развитие и поддержка

Попробуйте модуль «Служба поддержки» на своем проекте бесплатно — пробный период для тарифов Standard и Pro на 14 дней

Попробовать

Установили ограничения по количеству задач

В Kaiten есть возможность ограничить число задач, которые могут находиться в работе, их называют WIP-лимиты. Работает по правилу — исполнитель не может взять в работу новую задачу, пока не закроет начатую. Очень удобная функция, которую мы начали активно использовать, чтобы не копить очередь из полуготовых задач и быстрее доводить работу до конца. Если задач в работе будет больше, чем установлен лимит, — карточка и значок подсветятся красным. Наглядно изображено на скрине ниже:

Лимиты установлены в колонке «В работе» для каждого большого этапа. Еще ограничения установлены на дорожках «Поддержка» и «Развитие»

Если видим блокировки — можем их решить

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

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

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

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

Структурировали работу в карточках и добавили чек-листы

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

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

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

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

Карточка проекта с чек-листом в Kaiten

Решили проблему с приоритизацией

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

Решили, что у нас будет 3 критерия, которые определяют приоритет выполнения:

  • сложность выполнения;
  • влияние на бизнес-цели;
  • влияние на удовлетворенность аудитории.

Стали оценивать эти критерии по 10-балльной шкале, а потом, с помощью автоматизации, в поле «Priority score» отображался конечный результат. Чем больше значение, тем задача приоритетней.

Поля с критериями для оценки приоритизации в Kaiten

Начали создавать свою базу знаний

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

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

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

Инструкция по составлению заявки, которая доступна всем заказчикам

Можем ответить на вопрос от заказчиков «Сколько времени займет?»

Наша целевая аудитория — отдел продаж, который оставляет заявки, а мы их реализовываем.

Раньше мы получали заявки из Telegram-чата, где было 70 человек. Представьте, вы открываете полотно сообщений, где в одном месте есть задача, где-то ниже — комментарии по ней. Было очень неудобно:

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

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

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

Чат-бот в Telegram, через который заказчик общается с исполнителем
Команда из службы поддержки видит заявки на доске в Kaiten и работает с ними как с обычными карточками

Когда задача берется на исполнение — заказчик получает уведомление о смене статуса его заявки. А если исполнитель напишет комментарий по задаче в карточке, то бот продублирует его в чате с заказчиком.

Установили SLA и договорились, что первая реакция на заявку должна быть отправлена в течение 1 часа. Это помогло нам наладить коммуникацию с заказчиками, потому что реакции показывают, что над их заявку обработали и начали вести работу.

У нас есть 2 линии поддержки, которые работают с входящими заявками:

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

После установленных договоренностей начала появляться статистика. По ней мы увидели, что 76% заявок укладывается в SLA 1 час, а 85% запросов закрывается в первые 3 дня. Для нас это большой прорыв, потому что теперь мы можем рассчитать сроки выполнения задач и, опираясь на метрики, гарантировать заказчикам, что с вероятностью 85% решим задачу за 3 дня.

Автоматизированный отчет по SLA в Kaiten
Статистика работы службы поддержки

Что в итоге

Мы поработали в Kaiten 1 месяц, и уже видны первые результаты:

  • Мы стали закрывать все задачи, которые взяли в работу. Если раньше у нас часто накапливалась очередь из нерешенных задач или заявки оставались без решения. Теперь, чтобы оставить задачу незакрытой — нужна веская причина.
  • У нас значительно выросло количество релизов. Если раньше за квартал мы закрывали 1-3 задачи, то теперь делаем столько же за 2 недели.
  • У нас уходит меньше времени на устранение проблем, потому что, анализируя блокировки,нам удается системно решать причины.
  • Мы избавились от ненужных встреч и обсуждений в чатах. Благодаря единому пространству в Kaiten нам не нужно искать информацию о задачах, поэтому мы меньше отвлекаем друг друга в чатах и можем фокусироваться на работе.

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

5 советов, которые помогут плавно внедрить Канбан-метод в компанию

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

  1. Согласуйте идею со своим руководством, рассказав о всех плюсах перехода на новое пространство. Я начал с выгоды для компании — показал руководству, что переход в Kaiten дешевле, чем сервис, которым пользовались ранее. И объяснил, в чем его ценность для моей команды.
  2. Предложите альтернативу. Мы начали с бесплатного пробного периода и договорились, что, если не получится адаптироваться — вернемся к прежнему сервису. В итоге, когда стали работать по-новому, оценили все удобства и функциональность Kaiten — никто не захотел возвращаться.
  3. Дайте команде время, чтобы освоиться. Я 2 недели просто наблюдал за тем, как команда работает. Затем поделился своими наблюдениями — какие вижу проблемы и пути их решения. И, когда поправки были приняты командой, я сказал, что это и есть Канбан.
  4. Позвольте команде быть более самостоятельной. Мы собрались отделом на воркшоп, чтобы кастомизировать и оптимизировать Канбан-систему специально для нас. На нем каждый желающий мог внести свои правки и предложения, в  конце я лишь немного скорректировал.
  5. Воспринимайте ошибки от команды с пониманием. Во время адаптации абсолютно нормально допускать ошибки — путаться в колонках или не соблюдать SLA. Когда в моей команде были сложности — мы обсуждали проблемы в рамках встречи 1:1 или поднимали вопрос на общем собрании, где без критики и обвинений обсуждали наши ошибки.

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

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

Попробовать