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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что в итоге

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

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

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

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

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

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

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