Книга «Канбан Метод. Базовая практика»

Привет, Хаброжители!

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

• его изобрели на Тойоте;
• в нем есть доски и стикеры;
• там ограничивают количество незавершенной работы.

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

Для кого эта книга

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

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

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

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

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

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

Начинаем использовать Канбан

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

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

Введение в изучение процессов

Прежде всего разделим нашу большую задачу по изучению процессов на задачи поменьше. Для этого нам потребуется небольшая иллюстрация.

На данной иллюстрации мы видим, что у нас есть:

• клиенты, которые формируют нагрузку на наш Сервис клиентской ценности;
• сервис поставки клиентской ценности (это определение мы разобрали в главе о принципах поставки ценности), внутри которого — производственный процесс, люди, рабочее окружение и т. п.;
• поставляемая клиентская ценность, которая идет непосредственно клиентам;
• заинтересованные лица — это чаще всего руководители высшего звена, заинтересованные в эффективности нашего сервиса.

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

• Какой процент нагрузки превращается в клиентскую ценность?
• Есть ли в поставляемой клиентской ценности что-то, реально клиентскую ценность не несущее? Зачастую мы называем это «ложной нагрузкой» (Failure Demand).
• Какой процент ложной нагрузки в нагрузке?

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

Теперь переходим к деталям. Начнем с левой верхней части нашей иллюстрации и пойдем вглубь.

Цель вашего сервиса

Любые организационные изменения имеют цель. А то, что часто определяют как «наладить процессы» или «внедрить подход», и есть организационные изменения. Самое глупое, что мы с вами можем сделать в данном случае, — пытаться вслепую применить самые модные и современные подходы лишь потому, что так сейчас делают все. Подобное поведение называют эффектом присоединения к большинству (Bandwagon Effect). Его определение выглядит следующим образом.

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

Как это выглядит в реальной жизни? Компания A внедряет у себя подход X, потому что так сделали компании B, С и D. При этом внедрение подхода требует больших финансовых затрат. Компании B, C и D в случае неудачного внедрения (не получен ожидаемый эффект) не рассказывают о своих проблемах, а, наоборот, всячески пропагандируют подход X, обходя негативные последствия его использования. Компания A присоединяется к поведению B, C, D, и эффект усиливается, потому что компаний, практикующих подход X, стало больше. В дальнейшем информационный фон вокруг подхода X усиливается, заставляя входить в сообщество его практиков все больше компаний. В народе резко возрастающую популярность каких-либо действий называют словом «хайп» (hype), означающим агрессивную и навязчивую рекламу, целью которой является формирование предпочтений потребителя. Дословный перевод слова «хайп» с английского языка — надувательство, обман или трюк для привлечения внимания.

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

1. Менеджер завершил проект на грани провала — все оказалось очень плохо. С грехом пополам его удалось закрыть с большим количеством недочетов.
2. Менеджер доложил руководству о том, что проект завершен, но есть недочеты.
3. Руководство доложило еще более высокому руководству, что проект завершен с небольшими недочетами.
4. Высокое руководство доложило еще более высокому руководству, что проект завершен, а те в свою очередь рапортовали совету директоров об успешном завершении проекта.

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

Как не допустить подобных проблем? Для начала нужно понять:

• Кто является конечным бенефициаром процесса создания нашего продукта или услуги?
• Как этот человек (группа людей) понимает, что мы сделали работу хорошо?

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

• поставку не реже чем раз в 2 недели;
• время производства не более 3 месяцев;
• доступность сервиса 24 часа 7 дней в неделю;
• время первой реакции на запрос не более 1 часа.

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

Источники неудовлетворенности

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

Источники неудовлетворенности можно разделить на два типа:

• внешние;
• внутренние.

Внешними источниками неудовлетворенности мы считаем неудовлетворенности людей, сторонних для нашего сервиса, а внутренними — неудовлетворенности людей, задействованных в нашем сервисе (команда/команды).

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

Чаще всего это нечто, что мешает командам делать свою работу хорошо:

• что-то постоянно прерывающее работу и заставляющее отвлекаться;
• что-то рандомизующее (делающее непредсказуемым) рабочий процесс;
• что-то не позволяющее сделать работу вовремя и с нужным качеством.

Внешние источники неудовлетворенности чаще всего включают:

• сделано не вовремя;
• делается долго;
• делается мало;
• делается не то.

Теперь самое интересное. Если внутренних источников неудовлетворенности много и они достаточно сильные, то у команд сервиса не возникает эмпатия к заказчику и их участники не могут взять его источники неудовлетворенности в фокус. Другими словами, нужно понимать внутренние источники неудовлетворенности и устранять их до появления у команд эмпатии к источникам неудовлетворенности заказчика. Это очень важно!

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

Анализ нагрузки

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

• Кто поставляет вам запросы?
• Сколько видов таких запросов существует?
• Это люди или функциональные подразделения?
• Какова интенсивность появления запросов?
• Есть ли у запросов цикличность?
• Есть ли у запросов шаблон появления?
• Есть ли у заказчика особые ожидания по реализации запросов?

Зачастую сходу отвечают на 2–3 первых вопроса, про остальные не думают, а следовало бы.

Введем в наш лексикон новый термин — «тип рабочего элемента» (WiT, Work Item Type), который будет означать разделение рабочих элементов по источнику и природе их возникновения и/или особенностям реализации. Разные заказчики порой дают запросы разных видов. Рассмотрим пример.

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

А самое главное — все эти примеры могут существовать в разных комбинациях.

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

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

• определения того, как мы справляемся с работой;
• грамотного планирования загрузки нашего Сервиса поставки ценности.

Как подступиться к вопросу о сборе таких данных? Для этого можно выполнить следующее несложное упражнение.

Чуть больше повезло тем, кто использует какой-либо трекер задач, — обычно в нем предусмотрена типизация запросов, и вы ею, скорее всего, воспользовались. Можно оттолкнуться от этого. Если трекера задач нет, но есть несколько рабочих элементов, которые вы поставили в прошлом (например, за последний месяц/квартал/полугодие), то можно их проанализировать и попробовать разделить на типы. Тем, кто начинает с нуля, придется чуть больше задуматься и выписать все типы работ, которые наблюдаются в их производственном процессе. Очень важно отталкиваться от реально существующих рабочих элементов, иначе мы рискуем начать придумывать идеальный набор типов рабочих элементов вместо того, что есть на самом деле. Все перечисленное можно выписать на стикеры и разместить на стене.

Далее нужно выписать на стикеры все источники запросов и распределить их по типам работ (не бойтесь дублировать источники).

Затем стоит подумать на тему интенсивности появления запросов — обычно это штуки в единицу времени. Тут можно рассмотреть диапазонные значения, например 5–10 в месяц. Идеально достать эти данные из вашего трекера задач, но если его нет, то можно записать интенсивность, опираясь на собственные ощущения.

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

• раз в неделю/две недели/месяц/квартал;
• по государственным/религиозным/гендерным праздникам;
• под конец месяца/квартала/года;
• связано с событием (выставка/конференция/поставка).

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

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

Вот как это записано в примере.

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

Еще посмотрите на дефекты. Там указано, что для критических дефектов их надо реализовать в течение трех часов, но если дефект не критический, то ожиданий нет.

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

Об авторе

Алексей Пименов – главный эксперт по канбану в России. Специалист по гибким методологиям, мастер делового администрирования в области стратегического менеджмента, специалист по построению высокоэффективных команд и мотивации персонала.

Более подробно с книгой можно ознакомиться на сайте издательства:

» Оглавление
» Отрывок

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 35% по купону — Канбан