Текст книги "Канбан Метод. Базовая практика"

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

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

Время нахождения рабочего элемента в работе

Если вспоминать наш пример с Заказчиком, Руководителем и Инженером, то это время с момента, когда Руководитель ввел работу в производственную систему, до текущего момента. Конечно, мы рассматриваем незавершенные рабочие элементы. Такое время можно визуализировать на тикете, на нашей доске, в виде числа или какого-то количества меток (например, точек).

Это знакомая нам визуализация, в которой для удобства идентификации каждый рабочий элемент обозначен буквой латинского алфавита, а количество дней, которое он находится в колонках «План» и «В работе», – черными точками. Например, рабочий элемент F находится в производственном процессе уже четыре дня, а рабочий элемент I – всего три.

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

• В текущий момент времени наиболее приоритетным для Инженера рабочим элементом будет тот, который дольше всего находится в колонке «В работе» (на текущей иллюстрации – рабочий элемент G).

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

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

Категоризация работы

А у вас есть работа, которая требует больше внимания, чем другая? Или работа, которая должна обгонять другую работу? Как вы ее идентифицируете для принятия ежедневных решений о том, на что обращать больше внимания и на чем фокусироваться?

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

Категоризировать работу можно по:

• природе возникновения (что является ее источником);

• срочности;

• важности;

• ожидаемому эффекту.

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

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

Возьмем другой пример. Может появляться работа, которая требует большего внимания, чем другая. Скажем, по правилу «бросай все и делай ее» (вы наверняка сталкивались с таким паттерном прилетов сверхсрочных заказов).

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

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

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

Выявление точки старта

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

Очевидно, что выполнение этой работы позже указанной даты не имеет смысла, но есть ли смысл делать ее раньше? Ответ однозначный: «Нет!» По двум причинам:

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

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

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

• знать дату поставки (Desired Delivery Date, DDD);

• знать время, в течение которого можно реализовать запрос.

Имея в своем распоряжении два данных параметра, можно из первого вычесть второй и получить момент времени, который называют последним ответственным моментом, или LRM (Last Responsible Moment). Это точка на шкале времени, когда нужно начинать работу над запросом с фиксированной датой поставки. Понимание данного момента, умение его считать и мониторить дает возможность более грамотно управлять потоком.

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

Аномия вызывает у людей фрустрацию, поведение сотрудников становится хаотичным и бессмысленным, а главное, в таком состоянии люди не могут войти в состояние потока – состояние, в котором индивид может свободно направлять свое внимание на достижение целей[5]5
  Чиксентмихайи М. Поток: Психология оптимального переживания.


[Закрыть].

Для борьбы с состоянием аномии необходимо сделать так, чтобы правила:

• существовали;

• были формализованы;

• были доступны.

Возникает резонный вопрос: что это за правила и как их формализовать и сделать доступными?

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

О каких правилах идет речь? Это могут быть:

• правила проведения статусных собраний, на которых отслеживается то, как идет движение к цели и принимаются оперативные решения;

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

• правила заполнения доски;

• правила, по которым можно считать, что работа достойна того, чтобы перейти из одного этапа на другой, вперед (часто встречается название «DoD-этап»; в данном контексте аббревиатура DoD расшифровывается как Definition of Done, что, по сути, означает набор критериев, по которым делается вывод, что работа на данном этапе закончена);

• правила, по которым можно делать выбор в пользу одного из нескольких рабочих элементов в определенной колонке для дальнейшего движения по потоку (часто встречается название Pull Criteria – критерий, по которому делается вывод, что именно этот рабочий элемент должен быть взят в дальнейшую работу).

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

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

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

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

Общие сведения о петлях обратной связи

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

Например, перед вам стоит задача – наполнить чашку чаем наполовину. У вас есть чайник с этим самым чаем. Доступное действие – поднести чайник к чашке и наклонить его так, чтобы чай через носик лился в чашку. Регулируемый параметр – угол наклона чайника. Если наклонить чайник сильнее, то чай в чашку будет литься быстрее, а если угол наклона меньше – медленнее. Я думаю, при таких условиях вам не составит труда налить полчашки чая, но чтобы разобраться, как все происходит, стоит попробовать сделать то же самое, закрыв глаза. Очень высока вероятность, что тогда у вас ничего не получится. А что, собственно, произошло? Разрыв петли обратной связи.

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

Петли обратной связи в менеджменте

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

Вариантов получить обратную связь может быть много. Рассмотрим типовые:

• устное общение двух персон;

• пересылка данных (например, отчетов);

• информационные панели – формат отчетов, доступный онлайн и непрерывно обновляющийся;

• собрания.

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

Пример 1

У нас есть команда, которая работает над развитием какого-то продукта. В работе находится некоторое количество клиентских запросов, по которым надо уложиться в определенные сроки. Периодически появляются корректировки для этих запросов, корректировки приоритетов и задачи сверх плана, поэтому команде приходится принимать управленческие решения по изменению рабочего фокуса (каким задачам уделить больше внимания, каким – меньше) и смотреть, что получается в итоге принятых решений, добились ли мы ожидаемого эффекта.

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

Пример 2

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

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

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

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

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

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

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

• моделирование – строим некоторую модель, описывающую похожий на наш производственный процесс, вносим в нее изменения и смотрим, как модель на него отреагирует;

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

Так или иначе мы используем научный подход – способ исследования, систематизации и корректировки новых или уже известных знаний. Умозаключения и выводы делаются с помощью рассуждений на основе эмпирических (наблюдаемых и измеряемых) данных об объекте исследования. Базой получения данных здесь являются наблюдения и эксперименты. Для объяснения наблюдаемых фактов выдвигаются гипотезы и строятся теории, на основании которых, в свою очередь, строится модель изучаемого объекта.

Говоря языком мемов и аналогий, сначала мы экспериментируем «на кошках». Здесь хочется сделать для читателя отсылку к старому замечательному фильму «Операция “Ы” и другие приключения Шурика».

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

Мы верим в то, что если сделаем: <действие>

То получим: <результат>

И мы поймем, что результат получен, если: <критерии успешности>

Если результат будет получен, мы: <действия в случае успешности>

Если ожидаемый результат не будет получен, мы: <действия в случае неуспешности>

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

«План – ничто, планирование – всё».

Дуайт Эйзенхауэр

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

Подытожим

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

Раздел 3
Начинаем использовать канбан

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

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