Как мы перешли на Kanban и не уволились в процессе

Дмитрий Щегольков, руководитель инженерного отдела в Linxdatacenter, рассказывает об опыте перехода команды на Kanban-метод, выделяет этапы, с помощью которых внедряли новый рабочий инструмент и делится промежуточными результатами.

Как мы перешли на Kanban и не уволились в процессе

Для начала пару слов о специфике деятельности Linxdatacenter. Наши основные направления деятельности: ЦОДы в Москве и Петербурге; сервисы облачной платформы LinxCloud, развернутой на их базе. Помимо этого, есть отделы, без которых ни одна компания не может существовать — бухгалтерия, юристы, HR и др.

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

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

Что мы делали, чтобы переход произошел максимально гладко и изменения «прижились».

Этап 1. От беспорядка в почте к четкой структуре

Из-за того, что все задачи приходили в команду по нескольким каналам связи, было сложно определить занятость членов команды. Мы не понимали, какой объем задач поступает в команду, кто выступает в роли заказчика, в какой день начинает сгорать дедлайн и т.д. Желание структурировать работу команды стало первой причиной «за» переход на какой-нибудь таск-трекер.

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

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

  • Упущенную прибыль.
  • Зря потраченное время.

Получается, что для эффективной работы нужно было ответить на вопросы:

  • что мы делаем;
  • для чего мы это делаем;
  • почему решили делать именно эту задачу и др.

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

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

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

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

Этап 2. Выбор инструмента

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

Так я вспомнил про Кайтен — таск-менеджер для управления проектом по методологии канбан и скрам.

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

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

Рассказал о Кайтене команде и предложил поработать в нем — ребята поддержали.

Этап 3. Постепенное внедрение Кайтена

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

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

  • бэклог,
  • в работе,
  • готово

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

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

Этап 4. Организация процессов в таск-сервисе

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

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

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

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

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

Со временем всё начало выравниваться само собой:

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

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

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

Этап 5. Первые результаты

Следом за этим стала формироваться понятная картина по производительности подразделения. Один из показателей, который мы отслеживали — среднее время по выполнению задачи.

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

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

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

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

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

Продолжение нашей истории перехода на таск-трекер следует.

Если у вас есть вопросы или идеи о переходе на канбан — приглашаю в комментарии.

Больше полезного контента об ИТ-рынке, облачной индустрии и дата-центрах в нашем телеграм-канале "Сейф для данных". Подписывайтесь!

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

1414
7 комментариев

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

1
Ответить

Сейчас каких либо корпоративных правил и требований нет. Качество ведения задач модерируется на уровне доски (сервиса) и ответственного за этот сервис (на текущий момент это тимлид команды). В этом и есть сила этой системы: она даёт все необходимые инструменты непосредственно локальному заинтересованному и он способен автономно организовать работу внутри этой ячейки максимально продуктивно, без необходимости писать ТЗ для специального подразделения на составление и настройку организационной бизнес логики.

Ответить

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

1
Ответить

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

Ответить

Софтпауэр в действии)

1
Ответить

только сегодня читал как не стоит начинать статью🤣🤣🤣

1
Ответить

Хорошая статья и отличный кейс)

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

Сконцентрировались на проектном управлении, получилось что-то между ERP и таск-трекером. Будем рады, если протестируете систему и дадите обратную связь :)

1
Ответить