Дмитрий Щегольков, руководитель инженерного отдела в Linxdatacenter, рассказывает об опыте перехода команды на Kanban-метод, выделяет этапы, с помощью которых внедряли новый рабочий инструмент и делится промежуточными результатами.
Для начала пару слов о специфике деятельности Linxdatacenter. Наши основные направления деятельности: ЦОДы в Москве и Петербурге; сервисы облачной платформы LinxCloud, развернутой на их базе. Помимо этого, есть отделы, без которых ни одна компания не может существовать — бухгалтерия, юристы, HR и др.
Чтобы оценить фронт работ команд, помочь сотрудникам стать эффективнее, а руководителю — управлять работой подразделений, было принято командное решение перейти на канбан и ввести новый инструмент для команды — таск-менеджер.
Сложности перехода заключались в том, что компания существует более десяти лет, а значит все ее бизнес-процессы были давно выстроены и налажены. Коммуникация между командами велась «по старинке»: через письма и сообщения в мессенджерах. И отучить сотрудников от такого формата — задача не из простых.
Что мы делали, чтобы переход произошел максимально гладко и изменения «прижились».
Этап 1. От беспорядка в почте к четкой структуре
Из-за того, что все задачи приходили в команду по нескольким каналам связи, было сложно определить занятость членов команды. Мы не понимали, какой объем задач поступает в команду, кто выступает в роли заказчика, в какой день начинает сгорать дедлайн и т.д. Желание структурировать работу команды стало первой причиной «за» переход на какой-нибудь таск-трекер.
Помимо беспорядка в потоке входящих задач, нужно было «причесать» задачи изнутри.
Приведу небольшой пример. Допустим, кто-то из менеджеров решил, что продукту нужна новая фишка, потому что: этого нет у конкурентов → мы становимся уникальными → можем заработать сто-тысяч-миллионов. В команду прилетает срочная задача, ребята вкладывают в реализацию огромные силы, но… В результате эта фишка просто не нужна клиенту и покупки не происходит. Что компания имеет в итоге?
- Упущенную прибыль.
- Зря потраченное время.
Получается, что для эффективной работы нужно было ответить на вопросы:
- что мы делаем;
- для чего мы это делаем;
- почему решили делать именно эту задачу и др.
Из-за всего этого большая часть времени уходила на вещи, которые не приносили долгосрочной ценности. И подобных задач «в никуда» было достаточно много — они сменяли одна другую. Нам нужна была единая система, которая позволила бы увидеть всю картину целиком.
Было необходимо, чтобы вся команда четко понимала, над созданием каких продуктов и услуг она работает в определенный момент. Также канбан был полезен для внедрения новых продуктов. Прежде чем начать создавать что-то новое, команда могла бы оценить востребованность продукта, собрать статистику и сделать кастдев:
- Понимаем, что игра стоит свеч → берем задачу в работу.
- Понимаем, что задача не актуальна для рынка → не тратим на нее время.
Именно по результатам подобной аналитики мы сможем получать продукт, который легко поддерживать и масштабировать, который принесет прибыль.
Этап 2. Выбор инструмента
В прошлом я активно изучал канбан и знал несколько таск-менеджеров. На момент внедрения нового инструмента в работу ситуация на рынке была нестабильной — зарубежные сервисы могли в любой день уйти с рынка. Поэтому командой приняли решение искать инструмент от российских разработчиков.
Так я вспомнил про Кайтен — таск-менеджер для управления проектом по методологии канбан и скрам.
В интерфейсе все интуитивно понятно. Основа сервиса — это канбан-доски, визуально отображающие весь рабочий процесс. Пространство команды можно менять, как конструктор лего: добавлять колонки, столбцы или новые доски. Но главная фишка в том, что можно расположить несколько досок на одном пространстве или продублировать доску в нескольких рабочих пространствах.
Еще один плюс в том, что разные сотрудники имеют различный возможности доступа. Например, члены нашей клауд-команды могли редактировать доску, а коллеги из других команд, выступающие в роли заказчика, имели возможность только создавать карточки.
Рассказал о Кайтене команде и предложил поработать в нем — ребята поддержали.
Этап 3. Постепенное внедрение Кайтена
Решение использовать новый инструмент было на уровне нашей технической команды, а не компании. Мы с ребятами собрали бэклог (очередь) задач и попытались перенести всё это на доски.
Первое время, конечно же, мы меняли доску, добавляли и убирали дорожки, столбцы. Изначально доска выглядела максимально просто. Было три основных столбца:
- бэклог,
- в работе,
- готово
В процессе работы мы столкнулись с небольшой проблемой — задачи накапливались в общей очереди, потому что каждый специалист отвечал за определенный тип задачи. Получается, что карточка просто ждала своего исполнителя.
В качестве решения мы начали классифицировать карточки по ответственному, а на доске выделили дорожки с именами сотрудников. Так было проще оценивать, когда конкретная задача пройдет все этапы до попадания в «Готово».
Этап 4. Организация процессов в таск-сервисе
Когда наша тех-команда освоилась в Кайтене, предложили поработать в этом инструменте продуктологам. Ведь они выступают в роли наших внутренних заказчиков. Ребята постепенно начали осваивать новый инструмент.
Важно отметить, что мы не навязывали коллегам работу в новом сервисе. Никто не ставил никаких ультиматумов в духе «либо в Кайтен, либо увольняйтесь».
Сотрудники переходили в инструмент исключительно из-за желания упорядочить задачи и упростить рабочие процессы. Для желающих мы проводили обучение и вебинары по работе в сервисе без глубокого погружения в канбан.
Здесь тоже все происходило через метод проб и ошибок. К примеру, изначально в карточки ставили достаточно крупные задачи-проекты где-то на 2 месяца работы. Из-за этого оценить продуктивность и скорость выполнения задач было достаточно тяжело.
Но мы не навязывали жесткие правила, чтобы люди могли постепенно адаптироваться к новому инструменту и сами приходили к более оптимальным решениям.
Со временем всё начало выравниваться само собой:
- задачи стали уменьшаться,
- коллеги стали понимать, как их лучше декомпозировать.
В итоге карточки перестали висеть на доске месяцами, а прогресс стал намного понятнее.
Можно сказать, что в наших двух командах появилась культура ведения задач.
Этап 5. Первые результаты
Следом за этим стала формироваться понятная картина по производительности подразделения. Один из показателей, который мы отслеживали — среднее время по выполнению задачи.
Используя показатель о скорости решения задач, мы планируем установить вип-лимиты — ограничения на входящий поток задач относительно нашей производительности. С их помощью мы сможем принимать от заказчиков ровно столько работы, сколько точно успеем выполнить в срок.
На сегодняшний день мы работаем в Кайтене и прокачиваемся в канбан-практиках уже 11 месяцев. Работа нашей команды стала прозрачной, мы имеем понятное окружение работы. Если посмотреть на доску, то видны все задачи, их дедлайны, чем занят конкретный сотрудник, и когда его работа с карточкой будет завершена.
Взаимодействие с коллегами также стало более прозрачным и комфортным. Сотрудников не перегружают бесконечным потоком, а все цели и приоритеты — понятны. Например, если на доску прилетает срочная задача, мы совместно решаем, какую задачу сможет подвинуть в очереди.
Работу с инструментом подхватили и другие команды, благодаря чему у нас появилось единое пространство для коммуникаций с хранением всей важной информации: от переписки до файлов, загруженных в карточку. И никакой больше простыни в чате.
Но самое главное, что руководство заметило наши усилия и сформулировало потребность в таком инструменте на уровне всей компании. Надеюсь, что дальше все наши подразделения полностью перенесут работу в Кайтен.
Продолжение нашей истории перехода на таск-трекер следует.
Если у вас есть вопросы или идеи о переходе на канбан — приглашаю в комментарии.
Больше полезного контента об ИТ-рынке, облачной индустрии и дата-центрах в нашем телеграм-канале "Сейф для данных". Подписывайтесь!
Интересно будет почитать, как в итоге прижился инструмент. Задокументирована ли обязанность его использовать и как проходит контроль, потому что вносить задачки куда-то - это ещё одна рутина, которую не всегда хочешь делать, легче по-старинке в телегу коллеге написать
Сейчас каких либо корпоративных правил и требований нет. Качество ведения задач модерируется на уровне доски (сервиса) и ответственного за этот сервис (на текущий момент это тимлид команды). В этом и есть сила этой системы: она даёт все необходимые инструменты непосредственно локальному заинтересованному и он способен автономно организовать работу внутри этой ячейки максимально продуктивно, без необходимости писать ТЗ для специального подразделения на составление и настройку организационной бизнес логики.
Прибавилось ли рутины по заполнению всей этой прекрасной системы? Она же не сама по себе ведётся, нужно обладать дисциплиной, чтобы её вести
Коллеги отнеслись с пониманием к новому инструменту, а потом возникло привыкание)
Софтпауэр в действии)
только сегодня читал как не стоит начинать статью🤣🤣🤣
Хорошая статья и отличный кейс)
Мы тоже разрабатываем систему для корпоративного управления. Уже целых 7 лет, подумать только...
Сконцентрировались на проектном управлении, получилось что-то между ERP и таск-трекером. Будем рады, если протестируете систему и дадите обратную связь :)