Как мы внедрили Канбан в своем digital-агентстве

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

С чего все начиналось

Изначально все наши процессы находились в Битрикс 24, его использовали для управления задачами всех отделов (оптимизация, разработка, продажи, маркетинг), как CRM и для некоторых внутренних бизнес-процессов компании.

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

Схема процесса Darvin Digital

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

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

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

На поддержания этой системы не просто уходило колоссальное количество когнитивных усилий, все эти усилия давали минимальный профит, поток задач очень большой, без учета возврата в пул это порядка 20 запросов в день разного происхождения (внутренние и внешние), с возвратами их было в разы больше. Дело усугублялось плохо налаженной коммуникацией между отделами, часть внутренних заказчиков даже не говорила по русски (наши коллеги из зарубежного офиса продаж), наладить логистику так, как было бы удобно команде не удавалось, никто точно не мог представить всей картины процесса из за высокой его вариативности, решения принимались “на лету”.

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

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

Внедрение Канбан-метода

Наткнувшись на одну статью в блоге Skillbox (попалась первой) с описанием основ метода у меня закралось впечатление, что я зря не уделил ему должного внимания. Далее пошли еще статьи, я дошел до STATIK.

STATIK - это системное мышление при внедрении Канбан-метода в работу. Он подразумевает 8 шагов, которые помогут внедрить метод и спроектировать канбан-систему для любого процесса создания ценности. Шаги помогают осознать кто вы и какие ценности производите, каково значение того что вы делаете для клиента, подводит к пониманию кто ваш клиент и что для него важно, поможет найти точки недовольства как внутри процесса так и у клиента (что его не устраивает в вашем сервисе). Вы сможете ответить на вопросы STATIK и будете представлять точку с которой вы входите в Канбан-метод, это позволит проще определить курс развития, уже на этом этапе выявляется часть проблем процесса.

“У этого метода даже есть своя инструкция по внедрению”, подумал я, и начал составлять план по внедрению.

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

Мне начало казаться что я не совсем понял суть метода, и пошел искать информацию дальше, но уже не в статьях а в комьюнити. Так я набрел на Российское сообщество Канбан-практиков и их чат в Телеграмме. Я обратился к обитателем со своим кейсом и просьбой помочь нащупать верный путь. Многие откликнулись, особенно хочу отметить Павла Ахметчанова(@controlchart), который несколько часов разбирал со мной мой же процесс по косточкам, провел еще раз по STATIK и в итоге у меня сложилась в голове картинка. Процесс все еще был сложным, но уже обрел материальную форму на этот момент. Там же я узнал о Kaiten, как о подходящем инструменте для реализации метода и куда более сильную альтернативу Trello (сначала я рассматривал его как основной вариант для переезда туда процесса разработки). Я не стал искать альтернативу и взял триал, чтобы посмотреть как все будет.

Визуализируем процесс “как есть”

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

Доска для анализа задач

Вторая собственно сам процесс разработки:

Доска процесса разработки

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

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

На сбор доски ушло минут 30 (в kaiten это очень просто, есть уже готовые шаблоны которые подходят для большинства процессов) и около часа на то, чтобы наполнить их задачами из Битрикс. Пока это были пустые карточки, информация была только на фасаде, я раскидал их по колонкам согласно этапам процесса, на котором они находились. Это было уже что то. Kaiten универсальный инструмент, я сразу взял модуль Канбан и Учета времени, так как знал что именно мне нужно от системы. Разобраться с основами можно посмотрев 3 приветственных видео, в чате поддержка отвечает в течение 10-15 минут, так что скоро я немного подправил доску и она была готова к старту работ.

“Дорогая, мы переезжаем”

Настал момент 8-го шага STATIK - презентация идеи моей команде. На мой взгляд самый тяжелый из всех. Я планировал потратить 40 минут, введя в основы метода и на следующей презентации уже показать доску и рассказать как будем теперь работать, но что то пошло не так и команда захотела увидеть инструмент сразу. Вместо 40 минут ушло 3 часа, вопросов было море и столько же энтузиазма, мы договорились о дате переезда и определили алгоритм действий. Неожиданно для меня другие подразделения тоже захотели перенести процессы и сделать свои пространства с досками. О внедрении Канбана никто пока не думал, хотелось просто съехать с Битрикса.

Теперь мы приобрели полную прозрачности процесса. Могли видеть состояние всего отдела в любой момент времени, распределение нагрузки, проблемы в задачах. Это могли видеть и менеджеры. В комплекте ко всему этому Kaiten дал нам быстрый доступ к важным метрикам процесса: Кумулятивная и спектральная диаграммы, контрольные графики, скорость выполнение, пропускная способность отдела. У этой “горящей колесницы” перестали гореть колеса и появился руль.

В процессе переезда в назначенный день сразу начали вскрываться проблемы, кто то набрал задач, не успел их выполнить, проблемы в каких то давно разрешились но о них забыли и тд. К концу переноса и распределения задач по этапам мы имели всю картину процесса во всей красе - 64 задачи в ToDo и около 40 в процессе работы. Стал виден большой объем накопленной работы. Нужно было быстро исправлять ситуацию, клиенты ждут свои задачи и мы, конечно, хотим их доставить им скорее.

Первая неделя на новом месте

Целую неделю мы разгребали задачи, снимали блокировки, выстраивали процесс. На этом этапе выявилось и решилось множество внутренних проблем процесса, как мелких, так и не очень. Чтобы привыкнуть к методу и инструменту было решено эту неделю провести без лимитов на завершенные работы, единственный лимит что я использовал - это лимит на очередь, чтобы новые задачи не поступали в отдел, пока ребята не доделают старые. Но хоть лимитов и не было, это не значит что мы отказались и от других принципов Канбана, успешно внедрили ежедневные митинги сутра, для координации работ на день, старались ускорять задачи что уже в процессе и не брать новых в работу. Это дало ощутимый результат почти сразу, ребята начали сосредотачиваться сами на проблемных местах, решать блокировки, наладилась коммуникация между отделами при работе над комбинированными задачами (те, где нужны специалисты разного профиля). Было интересно наблюдать как быстро рос социальный капитал в отделе, налаживались связи со смежными структурами.

Уже к концу недели мы существенно зачистили задолженности по задачам.

Накопительная (Кумулятивная) диаграмма потока (первая неделя)

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

Три задачи одновременно начнешь, ни одну в срок не успеешь

Неделя вторая, настало время добавить “вишенку на торте” - WIP лимиты (рекомендация на ограниченное количество одновременно выполняемых задач, work in progress limits). Любой, кто знает что такое Канбан-метод, ответит вам что без лимитов вряд ли получите полный профит от метода. Да и полноценной канбан-системой нельзя считать систему без оных. Kaiten любезно предоставил мне отчет о выработке по задачам за каждый день и решено было установить лимит на задачи в основной колонке процесса на 7 (это против свыше 40 задач что было ранее!). Если вы внимательно смотрели диаграмму выше (и если знаете куда там смотреть :-)) то вы могли заметить что она довольно пологая, несмотря на то что количество задач в работе и ожидании уменьшалось, время задачи в процессе все еще было где то за горизонтом.

Лимиты дали свой эффект уже через 2 дня:

Накопительная (Кумулятивная) диаграмма потока (вторая неделя)

Диаграмма стала “подниматься”, это значит, что задачи стали доделывать намного быстрее. Ну и “зависших” задач в принципе не осталось. Очень хорошо этот подъем видно если совместить отчеты за 2 недели:

Накопительная (Кумулятивная) диаграмма потока (первая неделя + вторая неделя)

Ушли скачки в поставках, они стали более равномерны, исчезло ограничение на очередь задач, введенное мной на раннем этапе. Задачи начали поступать каждые 3-4 дня пакетами. Лимиты позволили команде также сосредоточится на доведении задач до конца, у них появилось время пойти и ускорить задачу в процессе (лимит кончался, нелзья барть новый задачи в работу, но есть блокировки в старых). Процесс встал на путь к прогнозируемому процессу, но все равно работы было еще очень и очень много.

Борды претерпели и другие изменения.

Модифицированная доска процесса спустя 2 недели

Слева направо, появилась колонка очереди для входящих задач. Kaiten позволяет размещать у себя на пространстве доски с других пространств, где ты участник. Смежные отделы просто притягивают эту колонку себе и пишут сюда задачи для отдела разработки. Далее они проверяются, при необходимости дополняются или рассчитываются по стоимости и уходят в лист ожидания поставки. Появилась колонка Supply(Поставка) которая заполняется на каденции по поставке, где мы обсуждаем что идет в работу следующим. Процесс тоже претерпел изменения, дизайн переехал в отдельную колонку, как этап создания ценности, предшествующий остальным. Также очень удобно что в кайтене можно связать карточки, если одна мешает продвижению другой. Даже если эта карточки с чужого пространства, что с того? Это дополнительный стимул быстрее сделать такую задачу, чтобы работа смежных подразделений не стояла долго. Индикаторы “возраста” показывают сколько задача уже “живет” на доске, в совокупности с другими маркерами это позволяет сотруднику принять верное решение, что он возьмет в работу следующим, какую задачу нужно ускорить на данный момент, если несколько ждут помощи.

Что дальше?

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

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

Сложности, с которыми мы столкнулись

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

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

Также разработчикам было сложно перестать менять контекст (быть “многозадачными”), люди привыкли быть “привязанными” к задаче, если где то вдруг она “блокировалась”, они бросали текущую задачу и шли проталкивать проблемную. Никто не брал в расчет своих коллег по цеху, которые могут помочь задаче дойти до конца.

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

Резюме

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

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