Текст книги "Канбан Метод. Улучшение системы управления"

Я неоднократно был свидетелем того, как проводимые в разной форме экспертные проверки работы коллег приносили сильное разочарование. В банке 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 (расширенная): управляйте потоком, добивайтесь плавности, своевременности и хороших экономических результатов, предугадывая потребности клиента.

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

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

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

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

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

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

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

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

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

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


[Закрыть]) на такой уровень, который мы ранее не видели.

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

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

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

● Чьи потребности исследуются на этой стадии процесса и каким образом? Чьи потребности не исследуются, и какие риски это несет?[13]13
  Не забывайте о заинтересованных лицах внутри организации – аудиторах, службе безопасности, финансовой службе, службе поддержки и т. д. Если они обладают правом вето, то к ним надо относиться как к клиентам. См. Middleton, Peter and James Sutton. 2005. Lean Software Strategies: Proven Techniques for Managers and Developers. New York: Productivity Press.


[Закрыть]

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

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

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

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

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

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

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

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

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

В этом варианте доски меня вдохновляет идея сита приоритетов – метод из книги «Персональный канбан»[14]14
  Benson, Jim and Tonianne DeMaria Barry. 2011. Personal Kanban: Mapping Work | Navigating Life. Seattle: Modus Cooperandi.


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Глава 5
Поток

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

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