Как пошагово внедрить Канбан и в 4 раза увеличить количество релизов

Рафаэль Аревян, деливери-менеджер в EdTech-проекте, специально для Executive.ru

Проблема, до боли знакомая каждому проджекту: заказчики недовольны тем, что вовремя не получают реакцию на свои запросы. Бизнес не видит поставки ценности, а команда фокусируется на задачах, а не на релизах. (Тут можно утереть скупую слезу).

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

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

Исходная точка: тонем в задачах и не видим результатов

В компании есть IT-департамент из 4-х команд, три из которых отвечают за определенную часть CJM пользователя.

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

Когда я пришел в компанию, процессы выглядели весьма хаотично:

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

Естественно, это сказывалось на производительности команды и отношениях с заказчиками:

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

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

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

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

Я сравнил имеющиеся решения: Jira, Яндекс Трекер, Trello, ClickUp, Kaiten. Послушал отзывы и советы профессионального сообщества и пришел к выводу, что Kaiten сильно выигрывает во многих аспектах.

Далее расскажу и покажу, как мы организовали в нем свои процессы и внедрили Канбан-инструменты. 

Визуализировали все процессы

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

Мы расположили 4 доски с разными процессами на одном пространстве.

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

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

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

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

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

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

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

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

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

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

Ввели ограничения по типу работ

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

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

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

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

Доска поделена на две дорожки для задач поддержки и развития.

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

Чтобы быстрее доводить начатые задачи до конца, а не накапливать длинные очереди из полуготовых карточек, мы установили WIP-лимиты — ограничение на количество задач, которое может одновременно находиться в работе. Правило простое: разработчик не может взять в работу новую задачу, пока не доделал предыдущие.

Таким образом мы ограничили этапы «В работе» на доске Delivery. 

И этот же инструмент помогает нам соблюдать правило 30/70. Так как ограничение можно установить отдельно для каждой дорожки. 

WIP-лимиты стоят на подэтапах «В работе» каждого большого этапа. Также есть отдельные лимиты на дорожках «Поддержка» и «Развитие».

Видим блокировки и знаем их причины

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

Для этого мы используем блокировки задач в Kaiten. В 2 клика можно повесить на карточку яркий значок-блокер и указать причину текстом или другой карточкой. 

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

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

Так выглядит график «Время разрешения блокировок» в Kaiten. Он показывает, сколько времени были заблокированы задачи и по какой причине. Его можно скачать в табличном виде.

Делаем и двигаем по доске карточки, распознаваемые заказчиком

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

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

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

Таким образом:

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

Чек-лист с подзадачами внутри карточки. На каждый пункт можно назначить срок и ответственного.

Быстро и прозрачно оцениваем приоритет задач

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

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

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

Мы прописываем оценки от 1 до 10 в соответствующих полях карточек, а потом в поле «Priority score» автоматически подсчитывается итоговое значение. Чем оно выше, тем задача приоритетнее.

Критерии для тиражирования задач записаны в специальных полях карточек.

Зафиксировали правила работы 

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

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

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

Инструкция для заказчиков «Как работает Служба поддержки» написана в Документах Kaiten и доступна всем заказчикам. 

Можем ответить на вопрос заказчиков «Когда будет готово»

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

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

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

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

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

Заказчик оставляет заявку в Telegram-боте и там же видит и отвечает на комментарии по ней. 

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

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

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

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

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

Теперь мы можем гарантировать заказчикам сроки с опорой на данные: с вероятностью 85% мы закроем их заявку за 3 дня. 

Автоматический отчет по соблюдению SLA.

Общая статистика по обработке заявок Службы поддержки.

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

Прошло всего чуть больше месяца, но результаты уже заметны:

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

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

5 советов, как внедрить Канбан «мирным путем»

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

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

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

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

Партнерский материал

Рекламодатель ООО «Кайтен Софтвер» ИНН 7714426252 Erid: 2SDnjeuGYNk

Читайте также: