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

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

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

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

И вот почему всё идет не так

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Метод «черного ящика»

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

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

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

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

Откуда брать данные для анализа черного ящика

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

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

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

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

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

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

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

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

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

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

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

Задать вопросы автору вы можете в Телеграм-канале «Данные в дейSTвии»