Зачем нужен Канбан-метод руководителю? Не просто стикеры и доски

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

Представьте обычный день руководителя IT-отдела или команды разработки.

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

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

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

А еще бывает, когда прилетает срочная задача от техподдержки, потому что, например, что-то сломалось в механизме приема платежей, или баннеры перестали «крутиться», или у какого-то значимого клиента что-то не работает и нужно это скорее исправить. Когда по-настоящему «горит», то техподдержка звонит напрямую разработчику и говорит что-то вроде: «Вы что! Там у вас все сломалось! Срочно берите в работу тикет такой-то!».

Все это называется «текучкой»: каждый день какой-то вал внеплановых задач валится на сотрудников и непосредственный руководитель во все это часто и не вникает.

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

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

Такая ситуация может привести к двум основным трудностям для менеджмента:

• Невидимая работа. Сотрудник в течение дня переключается с задачи на задачу текучки, а плановые задачи делает урывками, в свободные от текучки «окна». Его менеджер (руководитель) может ругаться на то, что плановые задачи делаются долго, но пока не проявлена вся загрузка сотрудника, как-то исправить ситуацию почти невозможно.
• Качество и ценность. Из-за множества переключений сотрудника между задачами, он лишь поверхностно понимает потребности заказчиков и делает «как написано», зачастую не включая здравый смысл. В условиях дефицита времени сделать хорошо часто просто невозможно, и поэтому задачи делаются быстро, но абы как в расчете на то, что потом будет время переделать «как надо». Проблема в том, что это «потом» никогда не наступает из-за каждодневного вала новых задач.

Пример из жизни: сотруднику поступает звонок от недовольного заказчика, у которого работа встала из-за дефекта. Естественно, что сотрудник под таким давлением начинает тут же исправлять этот дефект.

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

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

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

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

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

Наверное, многие видели такую смешную картинку из Интернета:

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

Полезные материалы, видео, рекомендации и обучение, для тех, кто хочет в деталях разобраться с Канбан-методом

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

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

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

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

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

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

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

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

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

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

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

— Колонки обозначают разные этапы работы над ПО. В то же время нам может быть интересно визуализировать информацию об уровне срочности, специалистах, которые делают задачи, или проектах и так далее. Чтобы быстро понять эти срезы информации, мы можем использовать горизонтальные «беговые дорожки», группирующие задачи по этим срезам.

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

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

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

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

Автор: Василий Савунов, Agile-коуч и эксперт ScrumTrek