Read the book: «Канбан Метод. Улучшение системы управления»

Переводчики Михаил Витебский, Алексей Капанадзе

Редактор Вячеслав Ионов

Научный редактор Алексей Пименов, основатель и ведущий тренер компании RealResult

Главный редактор С. Турко

Руководитель проекта А. Василенко

Корректоры А. Кондратова, Е. Чудинова

Компьютерная верстка М. Поташкин

Дизайн обложки Ю. Буга

© Michael Burrows, 2014

© Издание на русском языке, перевод, оформление. ООО «Альпина Паблишер», 2020

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

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

⁂

Посвящается Шерон

Предисловие

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

Я поставил себе задачу рассказать о «гуманном подходе к изменениям (начните с того, что есть сейчас)» не как об инструменте для повышения производительности, а как о методе управления, построенном на прочном фундаменте ценностей – методе, который помогает организациям становиться лучше для работников, клиентов и других заинтересованных лиц.

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

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

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

Книга состоит из трех частей.

В части I я представляю Канбан Метод (или просто канбан) по-новому, через призму девяти ценностей. Впервые я написал о них в начале 2013 г., и с тех пор им отводится центральное место в моей работе. В конце части I я рассказываю о некоторых новых понятиях – трех повестках и Канбан Линзе. Повестки канбана – это плод сотрудничества с моим другом и коллегой Дэвидом Андерсоном (создателем Канбан Метода), а линза придумана самим Дэвидом.

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

Часть III рассказывает о процессе реализации Канбан Метода в организационном контексте. Дэвид называет это «Системным Подходом к Представлению канбана» (Systems Thinking Approach to Introducing Kanban – STATIK). Процесс является фундаментом нашего обучения методу на базовом уровне. Я модернизировал его, добавив информацию о девяти ценностях и повестках из части I и некоторых моделях из части II.

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

Часть I
Канбан в зеркале своих ценностей

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

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

Для удобства я присвоил четырем Фундаментальным Принципам канбана обозначения от ФП1 до ФП4:

ФП1: начните с того, что есть сейчас.

ФП2: договоритесь об эволюционном развитии.

ФП3: в качестве первого шага проявите уважение к существующим процессам, ролям, обязанностям и служебному положению.

ФП4: поощряйте проявления лидерства на всех уровнях организации – от отдельного работника до высшего руководства.

Таким же образом обозначены шесть Основных Практик:

ОП1: визуализируйте.

ОП2: ограничивайте объем незавершенной работы (Work-in-Progress – WIP).

ОП3: управляйте потоком.

ОП4: сделайте правила работы явными.

ОП5: используйте циклы обратной связи.

ОП6: улучшайте совместно, эволюционируйте через экспериментирование (используя модели и научные методы).

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

В последней главе части I девять ценностей представлены в разбивке по трем повесткам и вводится еще один полезный инструмент – Канбан Линза.

Глава 1
Прозрачность

Мы находимся на одном из верхних этажей нашего сверкающего нового офиса, выходящего на вокзал Ньюгати в Будапеште. На часах 9:30, и традиционный стендап митинг в полном разгаре. Все оживлены больше обычного в предвкушении похода через дорогу за кофе и пирожными, чтобы отпраздновать наш последний этап «обучения». Я угощаю – накануне я оставил текущую сборку программы на несколько часов без внимания, а ИТ-директор не должен так поступать.

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

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

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

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

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

Описанные события происходили в 2009–2010 гг., когда Дэвид Андерсон собирал отзывы о только что сформулированных им фундаментальных принципах и основных практиках Канбан Метода. Мы – это люди вроде меня, которые уже применяли эти идеи, – обсуждали и уточняли их в нашем групповом мейл-листе. Через несколько недель наши отклики вошли в «синюю книгу» Дэвида². У нас появился документально зафиксированный метод!

Прозрачность – главная ценность канбана. С нею связаны три из шести основных практик:

ОП1: визуализируйте;

ОП4: сделайте правила работы явными;

ОП5: используйте циклы обратной связи.

Рассмотрим их по порядку.

Основная практика 1: визуализируйте

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

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

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

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

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

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

● какая работа блокирована (в ожидании чего-либо);

● кто над чем работает;

● какие виды работ выполняются и в каком соотношении;

● какой объем работы имеется на каждом этапе выполнения.

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

Визуализация и изменения

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

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

● действие в форме изменений в системе; правильный выбор при обосновании изменения, определении его масштабов и внедрении.

Как вы будете реагировать, когда доска показывает, что не все идет как надо? Ниже перечислены несколько вариантов ответов, типичных для руководителя или наставника:

1. Не стоит волноваться, все обойдется, как обычно.

2. Я, как руководитель, приму меры и буду следить за ситуацией, пока все не уладится.

3. Я внесу изменения в систему.

4. Они понимают, что привело к такому развитию ситуации? Они хотят внести изменения в систему? Как мне им помочь?

5. Я уважаю их способности вносить необходимые изменения в такой ситуации.

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

Ответ 5 (и, в меньшей степени, ответ 4) ориентирован на еще один очень интересный аспект – на самоорганизацию.

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

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

Здесь включается механизм самоусиления:

● канбан-система организует работу;

● люди организуются вокруг работы;

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

Основная практика 4: сделайте правила работы явными

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

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

Многие правила описывают качества, которыми должны обладать рабочие элементы, входящие или покидающие столбец, например:

● Рабочие элементы в колонке «Готово» не должны задерживаться более пяти дней. В Будапеште мы называли это «правилом пяти дней», которое позже превратилось в «правило двух дней».

● Рабочие элементы не могут перемещаться в столбец «Тест» до тех пор, пока они не пройдут ревью и не будут продемонстрированы всей команде.

Наклейки на доске или рядом с ней типа «<5 дней на разработку», «Разбор программы» или «Демо!» превосходно напоминают о том, чего ждет команда в ближайшем будущем.

Правила могут иметь и более общий характер:

● Стабильность продукта имеет больший приоритет, чем устранение ошибок при тестировании; при этом и первое, и второе имеют более высокий приоритет перед новой разработкой.

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

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

Правила и изменения

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

● Более крупные рабочие элементы обычно вызывают больше трудностей по сравнению с мелкими. (Это может быть больше, чем предположение – у нас, возможно, есть факты, подтверждающие данную гипотезу.)

● В целом лучше закончить что-либо, чем начинать дополнительную работу. (К этому можно отнестись как к житейской мудрости – «Перестаньте начинать, начните заканчивать!» – или как к проверенной временем теории.)

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

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

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

Основная практика 5: используйте циклы обратной связи

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

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

Стендап митинги

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

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

Стендап митинги могут иметь разные формы:

● неформальные, неструктурированные, без определенной повестки совещания (это трудно рекомендовать);

● опрос, который проводит руководитель (когда менеджер проекта заслушивает отчет подчиненных);

● совещания в офисе, возможно в скрам-формате, когда все по очереди отвечают на вопросы: Что я делал вчера? Что я планирую делать сегодня? Какие препятствия мешают мне работать?³;

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

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

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

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

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

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

Совещания по пополнению

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

Я не буду сосредотачиваться на механике совещаний по пополнению по двум причинам:

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

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

Другие виды совещаний

Некоторые совещания являются внешними по отношению к рабочему процессу, поскольку их функция заключается в управлении изменениями. Популярная аджайл-практика, которая иногда используется совместно с Канбан Методом, предусматривает регулярные ретроспективные собрания на уровне команды. Есть варианты, когда для проведения изменений делают оперативные совещания «на месте». Мы же настоятельно рекомендуем проводить еженедельно или раз в две недели обзор сервиса (service delivery reviews) на уровне команды или подразделения (иногда такие совещания называют обзором возможностей системы – system capability reviews) и ежемесячные операционные обзоры (operations reviews) на уровне филиала. На таких совещаниях команды делятся друг с другом и (в идеале) с представителями заказчика и организации в целом информацией о своей производительности, инцидентах и произведенных усовершенствованиях.

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

Циклы обратной связи на основе метрик

График на рис. 1.2 – это моя накопительная диаграмма потока (cumulative flow diagram – CFD). Я сделал ее следующим образом:

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

2. Определял общее количество законченных рабочих элементов, чьи карточки были сняты с доски (по этой причине график называется накопительным).

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

В наши дни вы можете получить такую диаграмму бесплатно в онлайн-пространстве с помощью вашего любимого канбан-инструмента.

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

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

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

Прозрачность как ценность

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

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

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

Глава 2
Баланс

Основная практика 2: ограничивайте объем незавершенной работы

Баланс – это ценность, тесно связанная со второй основной практикой канбана:

ОП2: ограничивайте объем незавершенной работы (WIP – work-in-progress).

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

Вытягивающие системы для интеллектуальной работы

Рассмотрим столбец «Тест» на доске (рис. 2.1).

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

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

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

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

Если не устанавливать WIP-лимиты, то сигналы для перемещения карточек теряются. Перемещающийся влево поток сигналов останавливается, как только достигнет столбца, в котором отсутствует ограничение (в данном случае это столбец «Предложено» (Proposed) на левом краю доски).

Эти неограниченные (или бесконечные) очереди приобретают огромную важность, когда измеряется время, необходимое для прохождения работы через систему. Мы называем время на перемещение рабочего элемента от одного столбца без ограничения, до другого столбца без ограничения, через столбцы с WIP-лимитами временем производства канбан-системы. Оно может очень сильно отличаться от времени производства заказчика – времени выполнения заказа с точки зрения клиента⁵.

Баланс Загрузки и Возможностей

Рассмотрим ситуацию на доске (рис. 2.2) с точки зрения людей, наиболее тесно связанных с этими самыми столбцами «Тест». Они могут быть тестировщиками или теми самыми разработчиками или аналитиками, которые занимались этими участками работы на более ранних стадиях; в интересах самоорганизации на доске это не отражается. Однако доска позволяет убедиться в том, что объем работы в этой зоне не выйдет (или не должен выйти) за пределы возможностей.

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

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

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

Ограничения WIP намного полезнее воспринимать не как простые политические рычаги, а как механизм обратной связи и полноценные факторы усовершенствований в масштабах всей системы. Когда вы уменьшаете объем WIP, то делаете намного более очевидными другие проблемы (а они могут мешать еще сильнее). Решите их, и тогда объем WIP можно будет уменьшить дополнительно – он даже может уменьшиться сам собой⁶. Это еще один механизм самоусиления, причем очень мощный. Его очень успешно в течение многих десятилетий использует компания Toyota⁷.

Противоположностью этого механизма я считаю порочный круг, который возникает, когда главной заботой становится постоянная занятость людей. В этом случае первая реакция на застопорившуюся работу заключается не в решении проблемы, а в начале выполнения еще одной рабочей задачи, что приводит к увеличению объема WIP в системе. Чем больше незавершенной работы, тем больше время ожидания у тех, кто будет ее завершать, а значит, проблема только усугубляется. Задержки и одновременное выполнение множества задач оказывают негативное воздействие на качество и являются причиной – да вы и сами, наверное, догадались – ошибок и переделок, большего объема застопорившейся работы и WIP. Слишком много работы в сочетании с плохим качеством – вам нравится такая комбинация?

Другие способы ограничить WIP

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

1. Уменьшение размера пакетных транзакций – сокращение размера (в плане бюджета и продолжительности) проектов, интервалов между релизами, а также размеров спринтов, размера пакета разрабатываемого функционала и т. д.

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

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

Ситуация в Будапеште, с которой начинается глава 1, сложилась не сразу. Я пришел работать в организацию, которая просто «подсела» на WIP. Как это часто случается в молодых компаниях, им было просто очень трудно сказать «нет». Это относилось не только к взаимодействию с внешними заказчиками – не говорить «нет» превратилось в привычку и в отношениях между подразделениями компании. От одного совещания к другому списки необходимых дел (а таких списков было очень много) становились все длиннее и длиннее.

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

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

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

Баланс срочной работы и работы с привязкой к дате

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

Давайте подробно рассмотрим небольшую часть нашей доски, показанной на рис. 2.3.

Пусть вас не смущают непонятные названия трех рабочих элементов, сконцентрируйте внимание на различиях в их визуализации. Для начала возьмем две верхние задачи Tokyo gateway upgrade и Swap curve.

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

Рабочий элемент Swap curve совсем другой. Он представляет совершенно независимую функциональность. Чем скорее он будет выполнен, тем раньше начнет приносить пользу. В отличие от предыдущего примера, этот рабочий элемент не привязан к дате, он является срочным.

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

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

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

Классификация на основе рисков и классы обслуживания

Рабочий элемент Try MongoDB (оставшийся в столбце) не кажется ни привязанным к дате, ни срочным. Но разве из-за этого он становится неважным? По этому рабочему элементу судить трудно, но где мы окажемся через год или два, если не будем экспериментировать и делать неафишируемую работу, ориентированную на перспективу и расширение наших возможностей в плане платформ, продуктов, процессов или людей?

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

● Ускоренные (Expedite): рабочие элементы настолько срочные, что приходится откладывать выполнение других работ и немедленно переключаться на них.

● Привязанные к дате (с фиксированной датой) (Date-driven или Fixed Date): рабочие элементы, невыполнение которых к конкретной дате приводит к наложению существенного штрафа, несопоставимого с любой выгодой от ранней поставки. Такие риски срыва графика тщательно контролируются.

● Стандартные (Standard), или регулярные⁹ (Regular): срочные рабочие элементы, выполняемые в соответствии с порядком, согласованным с заказчиками, или в последовательности, соответствующей выбранным вами правилам. В зависимости от ситуации правила выполнения могут быть такими простыми, как «первым пришел – первым ушел» (first in, first out – FIFO), базироваться на такой экономической модели, как «стоимость задержки» (cost of delay) (глава 15), или просто на личном выборе.

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

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

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

Баланс нагрузки и возможностей

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

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

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

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

Баланс среди Заинтересованных Лиц

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

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

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

Поиск баланса

Баланс – странная вещь. Мы рады, когда он есть, но его достижение требует прогнозирования, активного внимания, усилий, а иногда и прорывов. Лично для меня именно это делает баланс таким важным – не менее важным, чем вытягивающие системы на основе WIP-лимитов.

Чтобы вам было проще найти баланс при применении основной практики 2, постарайтесь предварительно сделать следующее:

● Найдите способы уменьшения объемов незавершенной работы, используя для этого все доступные рычаги.

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

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

Глава 3
Сотрудничество

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

Основная практика 6: улучшайтесь совместно, эволюционируйте через экспериментирование

Эта практика сопровождается небольшим дополнением. Ее полная версия выглядит следующим образом:

ОП6: улучшайтесь совместно, эволюционируйте через экспериментирование (используя модели и научные методы).

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

Сотрудничество – это очень важно

На мой взгляд, очень полезно думать о сотрудничестве, как о чем-то четко определенном, вспоминая широко известные примеры. Джон Леннон и Пол Маккартни, Фрэнсис Крик и Джеймс Уотсон¹⁰, Мари и Пьер Кюри – их сотрудничество оставило глубокий след не только в областях их деятельности, но и в памяти поколений. Это не просто приятные люди, сотрудничавшие друг с другом в общем смысле. Здесь мы видим отношения, в которых целое значительно больше, чем сумма отдельных частей, где творческая энергия бьет ключом не только в творческом союзе, но и в каждом участнике процесса.

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

Улучшайтесь совместно

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

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

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

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

Поощрение сотрудничества

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

Тем не менее мы столкнулись с проблемой. Ревью могло застопориться на несколько дней (иногда даже дольше) в ожидании, пока назначенный старший разработчик найдет время для проведения этого ревью. Такие эксперты могут проводить по несколько ревью одновременно, «поскольку это более эффективно». Иногда в результате ревью приходилось вносить в программу большие изменения, что приводило к дополнительным затратам и дальнейшим задержкам. Многочисленные задержки и переделки – вот что вызывает настоящую головную боль!

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

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

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

Сосредоточьтесь на сотрудничестве

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

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

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

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

Эволюционируйте через экспериментирование

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

Канбан, как и другие системы организации производства имеют общую черту – итеративный подход к решению проблем, реализуемый в виде циклов улучшения. В теории ограничений, например, есть процесс непрерывного улучшения (process of ongoing improvement – POOGI); в системе шесть сигм – цикл DMAIC (define, measure, analyze, improve, control – определение, измерение, анализ, совершенствование, контроль). На самом деле их намного больше. Создается впечатление, что описание циклов совершенствования – это любимый способ авторов систем подчеркивать отличие друг от друга.

Сообщество канбан-практиков с удовольствием сохраняет верность «прадедушке» всех этих циклов совершенствования – каноническому варианту, который называют и циклом Деминга, и циклом Шухарта (так называл его сам Эдвардс Деминг в честь Уолтера Шухарта, идеи которого он использовал и развивал), и циклом PDCA, или просто PDCA. Эта аббревиатура означает Plan, Do, Check, Act (планирование, выполнение, проверка, воздействие); иногда встречается аббревиатура PDSA от Plan, Do, Study, Act (планирование, выполнение, изучение, воздействие).

Предостережение: слова «планирование», «выполнение», «проверка» и «воздействие» означают не то, что вы думаете – они даже могут вводить в заблуждение, если их использовать без слова «эксперимент»:

● планирование эксперимента (основанного на гипотезе);

● выполнение (проведение) эксперимента;

● проверка (или изучение) результатов эксперимента;

● воздействие на результаты, внесение изменений в гипотезу или в систему, совместное использование.

Чтобы осуществлять изменения таким образом нужна определенная дисциплина, однако понятие «нацеленность на результат» определенно приобретает новый смысл!

Они и мы

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

Все это кажется сложной проблемой, которая заложена в человеческой природе и, безусловно, не имеет отношения к сути Канбан Метода. Или все-таки имеет?

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

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

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

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

● Насколько охотно в вашей организации начали использовать такой элемент канбана, как прозрачность? Ее рассматривают как угрозу, воспринимают равнодушно или считают положительным фактором?

● Ваша организация добилась баланса? Пыталась ли она сделать это? Как дисбалансы влияют на команды и отдельных сотрудников? Сколько дисбалансов вы можете идентифицировать?

● Ваша организация в достаточной степени понимает ценность сотрудничества, чтобы способствовать его развитию и сделать базой для совершенствования?

Какие из нижеуказанных нововведений были бы наиболее полезны в вашей текущей ситуации?

● Прозрачность:

● сделать работу видимой;

● сделать правила явными;

● использовать циклы обратной связи (или улучшить использование уже существующих циклов обратной связи).

● Баланс:

● внедрение вытягивающей системы;

● внедрение классов обслуживания, базирующихся на рисках;

● поиск более правильного состава работ (по типу или временны́м горизонтам).

● Сотрудничество:

● поощрение совместного решения проблем;

● принятие мер по повышению качества взаимодействия;

● структурирование усовершенствований как экспериментов.

С чего вы начнете? Если вы не уверены, то часть III (Внедрение) подскажет кое-какие идеи.

Глава 4
Клиентоориентированность

Основная практика 3: управляйте потоком

Это не ошибка? Каким образом мы перескочили с практики «управляйте потоком» к клиентоориентированности? Будьте снисходительны, позвольте мне расширить формулировку этой основной практики, чтобы более полно выразить ее сущность:

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

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

При чем здесь клиентоориентированность?

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

На занятиях я всегда даю следующий совет:

Всегда знайте, что вы поставляете, кому и зачем.

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

Удовлетворение гарантировано

Вспомните правило из сценария, открывающего главу 1:

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

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

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

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

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

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

Обзор доски

Правило, прикрепленное (фигурально выражаясь) к крайнему правому столбцу нашей канбан-доски, стало катализатором, клиентоориентированность все же сказалась на всем процессе. Чтобы понять, как подобные трансформации можно сделать стандартными и воспроизводимыми, полезно еще раз внимательно изучить доску, задавая при этом конкретные вопросы. Рассматривая доску, мы будем двигаться справа налево, от одного столбца к другому.

● Чьи потребности исследуются на этой стадии процесса и каким образом? Чьи потребности не исследуются, и какие риски это несет?¹³

● Чему мы учимся на этой стадии из того, что не знали (или не могли знать) раньше? Каким образом работа на этой стадии помогает сфокусироваться на том, что понадобится в будущем?

● Что еще нужно изучить? Как лучше справляться с неопределенностями – двигаться вперед или сделать шаг назад?

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

Творческая интеллектуальная работа – это не то, что мы уже знаем. Это (тут я сознательно прибегаю к техническому жаргону) процесс поиска знаний. Используйте канбан-доску для того, чтобы она постоянно напоминала вам о вопросе «Что мы не знаем?».

Предваряющий канбан

Я бы хотел схематично показать один из более сложных вариантов доски, который сам использую для управления своей рабочей загрузкой (рис. 4.1). Его основной отличительной особенностью является наличие трех столбцов под шапкой «Идеи». Обратите внимание на то, что их уменьшающиеся лимиты объемов незавершенной работы наводят на мысль о последовательном исключении.

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

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

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

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

В этом варианте доски меня вдохновляет идея сита приоритетов – метод из книги «Персональный канбан»¹⁴. Мой неожиданный переход к этой теме сейчас может показаться странным (мы кратко вернемся к нему в части II), но я использую этот дизайн в качестве модели для предваряющего канбан (Upstream Kanban). Это название ввели для обозначения практики применения системы канбана до процесса поставки. Предваряющий канбан – это организация потребностей и развитие идей таким образом, чтобы всегда имелся хороший выбор по предложениям, когда появляются свободные возможности поставки.

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

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

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

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

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

● Прозрачность: система должна сделать так, чтобы мотивы трудного выбора, который предстоит сделать, были видимыми. Логическое обоснование принятия решения должно быть явным. Решения должны быть в центре циклов обратной связи (например, совещаний, посвященных приоритизации).

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

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

Теперь давайте посмотрим, что к сказанному добавляет клиентоориентированность:

● Чьим потребностям, по нашему мнению, соответствуют эти идеи?

● Достаточно ли быстро мы удовлетворяем потребности?

● Что говорят нам данные? Что говорят нам люди?

● На чем могут основываться эти потребности?

● Какие потребности могут оставаться неудовлетворенными?

● Как мы можем это проверить?

Если резюмировать сказанное: можем ли мы лучше понять, что станет нужным в будущем?

Предугадывание потребностей

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

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

…заблаговременно предугадывать потребности в мобильности отдельного человека и общества в целом.

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

Глава 5
Поток

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

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

Основная практика 3: управляйте потоком (еще раз)

Я опять обращаю внимание на мою собственную расширенную версию третьей основной практики канбана:

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

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

Плавность

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

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

В книге «Вопрос культуры»¹⁵ Даниэль Мезик напоминает, что мы можем одновременно уделять внимание только ограниченному количеству вещей и событий. Независимо от осознания этого факта при создании своих систем управления производством мы выбираем то, чему будем осознанно уделять внимание. Привнося прозрачность в поток нашей работы, мы делаем именно такой выбор. Как заметил Мезик: «Канбан уделяет явное внимание потоку».

Как выглядит поток?

Вот несколько признаков того, что работа приобретает характер потока:

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

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

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

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

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

Обзор доски (еще раз)

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

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

Какой будет наша новая линза? Когда мы уделяем более пристальное внимание потоку, то задаем применительно к каждому столбцу примерно такие вопросы:

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

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

● Каковы самые важные причины непредсказуемости – они связаны с рабочим процессом или с ожиданием? Рабочие задачи обычно ждут высвобождения внутренних ресурсов или их выполнение зависит от внешних факторов?

● Какая часть ресурсов на этой стадии ушла на переделку? Или это всего лишь жалоба¹⁶ на то, что выполненная работа не полностью удовлетворяет потребности клиента?

● Как рабочие задачи добираются до этой стадии процесса? По каким признакам мы узнаем, что они готовы к началу работы над ними?

Внимание: подобные вопросы позволяют сделать следующие предположения:

1. Процесс имеет разумные цели – удовлетворение правильных потребностей клиента.

2. Рабочий процесс имеет разумные ограничения – он начинается с правильных вопросов и заканчивается правильными результатами.

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

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

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

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

Всегда есть более широкий контекст

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

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

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

Несколько простых примеров

Ниже я привожу фрагменты списка усовершенствований, осуществленных нами в 2009–2010 гг. Некоторые из них могут показаться чересчур специфическими из-за привязанности к разработке программного обеспечения, но большая часть содержит идеи, которые можно перенести в другие сферы деятельности. Фрагменты расположены в порядке «справа налево», т. е. в обратном порядке относительно процесса поставки готового продукта клиенту.

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

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

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

● Внедрение в практику правила «демонстрируй!». Оно требует, чтобы разработчик каждой вновь написанной программы демонстрировал ее всей команде, а не только аналитику. Только после этого работа перемещается из раздела «Разработка» в раздел «Тестирование». Это предотвращает преждевременное перемещение работы из раздела в раздел и создает хорошие возможности для обмена знаниями и генерирования идей.

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

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

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

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

Поток в крупной организации

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

На рис. 5.1 показаны некоторые проблемы масштаба.

При значительных масштабах возникает масса возможностей для задержек и срывов.

● Группа, ответственная за получение запросов на выполнение работ, и группа, ответственная за выполнение работы, – это две разные группы. Использование средств коммуникации, основанных на принципе «выстрелил и забыл» (особенно электронной почты), приводит к тому, что работа остается незамеченной.

● Возникают нестыковки представлений о «Сделанном» и «Готовом» у сотрудников или команд. Эти качественные проблемы могут быть вызваны ошибками при следовании правилам или неудачным сотрудничеством, а зачастую тем и другим вместе.

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

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

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

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

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

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

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

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

● Контроль размеров порций с помощью ограничения объемов незавершенной работы и правил определения размеров рабочих задач – официальное уменьшение аппетита к принятию обязательств по поставкам в далеком будущем.

● Управление объемами незавершенных работ через функциональные границы.

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

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

● Изменение детализации видов деятельности или структур, с помощью которых происходит управление рабочими задачами (при необходимости на нескольких уровнях).

● Поэтапная реорганизация процесса с последующими функциональными изменениями при необходимости.

● Количественная оценка и передача информации о результатах удобным для клиентов способом (во многих случаях речь идет о количественной оценке потока)¹⁷.

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

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

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

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

Управление потоком ради своевременности

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

● Необходимо как можно раньше идентифицировать необычные риски и зависимости и эффективно на них реагировать.

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

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

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

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

Глава 6
Лидерство

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

ОП1: визуализируйте.

ОП2: ограничивайте объем незавершенной работы (WIP).

ОП3: управляйте потоком.

ОП4: сделайте правила работы явными.

ОП5: внедряйте циклы обратной связи.

ОП6: улучшайте совместно, эволюционируйте через экспериментирование (используя модели и научные методы).

В каждой практике имеется масса возможностей для проявления лидерства.

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

ФП1: начните с того, что есть сейчас.

ФП2: согласитесь следовать эволюционным путем.

ФП3: в качестве первого шага проявите уважение к существующим процессам, ролям, обязанностям и служебному положению.

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

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