5 причин перейти на канбан: опыт дата-центра LINX

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

Дмитрий Щегольков, руководитель инженерного отдела в LINXdatacenter, рассказал, почему он предложил команде работать по канбан-методу, как в компании поэтапно внедряли новый рабочий инструмент, объясняя его ценность команде и руководству, и какого результата удалось достичь спустя год после изменений.

Специфика деятельности LINXdatacenter

У нашей компании есть два направления деятельности:

• первое — это два центра обработки данных в Москве и Санкт-Петербурге;
• второе, новое направление, — это облака по продаже вычислительных ресурсов на базе этих двух дата-центров.

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

Первое направление, связанное с дата-центрами, существует уже более 15 лет, оно в основном связано с инженерной работой, и процессы в нем давно налажены.

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

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

Именно в этот момент я присоединился к компании в качестве руководителя клауд-команды.

От почты и необоснованных задач к структурированным канбан-процессам

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

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

Допустим, кто-то из отдела продаж решил, что определенная функция продукта будет востребована для клиента, и компания от этого получит “100500 миллионов”. Ради этого вся команда целую неделю работает над задачей. А потом оказывается, что клиенту совсем не это нужно, и он не соглашается на покупку. В итоге компания имеет упущенную прибыль и зря потраченное время, которое могло бы уйти на более полезные действия.

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

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

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

Внедряли Кайтен постепенно от отдела к отделу

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

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

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

После того как появилась конкретика по задачам, мы начали лучше формировать ожидания заказчиков. И если кто-то из коллег приносит нам идею, мы не отказываем им, а говорим: “Давайте посмотрим бэклог на доске, является ли ваша идея более приоритетной? можем ли мы ради нее что-то подвинуть?”. И тогда они могут либо обосновать ее ценность, либо согласиться выполнить ее позже. Как итог получаем меньшее количество переключений между задачами и доведение начатой работы до конца.

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

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

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

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

Как организовали разные типы процессов в Кайтене

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

• Все задачи клауд-команды мы разместили на одной доске, которая состоит из колонок “бэклог”, “в работе” и “готово”. Так мы видим, какие задачи на каком этапе находятся.
• Также мы добавили горизонтальное деление доски — на каждой дорожке находятся задачи определенного исполнителя. Это помогает адекватно оценивать, когда конкретная задача из бэклога будет взята в работу и выполнена.

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

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

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

Мы еще не осуществили эту цель, но уверенно к этому идем.

Промежуточный результат: что мы имеем на текущий момент

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

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

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

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

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

Надеюсь, что дальше все наши подразделения полностью перенесут свою работу в Кайтен, — сначала они настроят в нём свои локальные процессы, а затем мы объединим в одной системе работу всей компании.

Самое важное и ключевое – связать задачи бизнеса с финальными инженерными трудозатратами. И инструмент этому способствует.