Канбан. Альтернативный путь в Agile Андерсон Дэвид
Начало перехода на канбан
Начало работы с Канбаном не похоже на те меры, которые вы, возможно, предпринимали в прошлом. Важно заложить основания для долгосрочного успеха. Для этого нужно сначала понять цели Канбан-подхода к изменениям. Главное при переходе на Канбан – это управление изменениями. Все остальное вторично.
Культурные изменения, а не инициатива сверху
В главе 5 описано, как Канбан оптимизирует существующий процесс после ряда пошаговых эволюционных изменений. Процесс оптимизации уже существующей модели ведет к повышению зрелости организации и позволяет впоследствии провести более крупные стратегические улучшения. Поэтому маловероятно, что перехода на Канбан удастся добиться при помощи инициативы сверху – например, назначив специальную программу обучения. Это существенно отличается от планирования и управления типичным переходом к agile-методологиям. На самом деле подход к управлению изменениями, используемый при переходе на agile-методы, мало отличается от предшествовавших подобных инициатив, например, основанных на модели CMMI или предполагающих введение Rational Unified Process. Инициатива по внедрению изменений в этом случае оказывается масштабным проектом, продуманным и распланированным заранее. Это особый вид управляемых изменений, при котором сначала определяется и оценивается текущий процесс, а затем выбирается один из agile-методов из учебника. После этого планируются меры по обучению и наставничеству, которые призваны помочь команде перейти от текущего метода к вводимому agile-процессу. Когда все заканчивается и внедряется новый процесс, проводится следующая оценка, которая должна продемонстрировать принятие новых методов. С Канбаном все происходит не так. В этом случае инициатива не планируется, не проводится никаких оценок и никто не говорит в конце: «Ну вот, мы перешли на agile!» Вообще конца как такового нет. Руководство управляет непрерывным процессом, проводя пошаговые изменения. В результате команда постепенно приходит к культуре кайдзен.
Действительно, обучение необходимо. Члены команды и другие заинтересованные лица должны понимать базовые принципы – например, взаимоотношения между WIP и временем выполнения, основанные на том, что строгие WIP-лимиты повысят предсказуемость времени выполнения. Возможно, понадобится провести краткий анализ вероятных путей совершенствования – устранения бутылочных горлышек, брака и вариативности. Когда потенциал для совершенствования выявлен, можно провести обучение новым навыкам и методам. Например, если основной источник брака – это программные ошибки, то стоит обучить команду разработчиков методам, которые существенно снижают количество ошибок и повышают качество кода: непрерывной интеграции, модульному тестированию и парному программированию.
Однако не нужно тратить слишком много времени на обучение. Прежде всего добейтесь консенсуса по поводу введения Канбана и начните пользоваться этим методом. Цель этой главы – попытаться заложить основы для успешного перехода на Канбан. В ней приводятся 12 простых шагов, необходимых для того, чтобы начать.
Хотя основная цель Канбана – вносить изменения при минимуме сопротивления, могут быть и иные задачи. Но изменения ради изменений бессмысленны: эти иные задачи должны отражать подлинные нужды бизнеса – например, предсказуемое создание высококачественного товара. Цели, перечисляемые здесь, – это примеры. Конкретные цели различаются для разных организаций. Первый шаг в процессе перехода – определить, для чего вы вводите Канбан в организации.
Основная цель для нашей канбан-системы
Мы переходим на Канбан, потому что считаем, что он дает возможность лучше производить изменения. Канбан изначально стремится изменить как можно меньше. Поэтому первая цель – это изменения с минимальным сопротивлением.
Существующие процессы будут оптимизированы благодаря визуализации и ограничению числа незавершенных заданий, что стимулирует изменения. Поскольку существующие роли и степени ответственности не изменятся, сопротивление сотрудников будет минимальным.
Вторичные цели нашей канбан-системы
Мы знаем, что Канбан позволяет воплотить в жизнь все шесть элементов рецепта успеха (главу 3). Однако можно немного переформулировать цели и расширить некоторые пункты рецепта, чтобы каждый из них помогал добиться больше одной цели.
Канбан позволяет сосредоточиться на качестве, поскольку ограничивает число незавершенных заданий и дает возможность определить правила приемлемости, прежде чем единица работы будет переведена на следующий этап процесса. Эти правила могут включать критерии оценки качества. Если, например, мы строго-настрого запрещаем отправлять пользовательские истории на приемочный тест, пока не пройдут все остальные тесты и не будут устранены ошибки, мы тем самым заставляем конвейер простаивать, пока история не будет исправлена так, что можно продолжить работу. Если команда недостаточно знакома с Канбаном, то не стоит устанавливать такое жесткое правило, но какие-то критерии качества, привлекающие внимание команды к разработке хорошего кода, почти не содержащего ошибок, должны присутствовать.
Нам известно, что количество WIP непосредственно связано с временем выполнения и есть корреляция между временем выполнения и нелинейным ростом количества ошибок[9]. Поэтому имеет смысл задавать WIP-лимиты. Будет гораздо легче работать, если мы ограничим число незавершенных заданий фиксированной цифрой. Это позволит установить предсказуемое время выполнения, а число ошибок должно уменьшиться.
Хотя об удовлетворенности сотрудников часто и много говорят в большинстве компаний, она редко относится к приоритетам. Баланс работы и жизни – это не просто уравновешивание количества часов, которое человек проводит в офисе, и времени, оставшегося для семьи, друзей, хобби, пристрастий и увлечений. Это еще и вопрос надежности. Например, сотрудник, любящий искусство, хочет посещать художественные курсы в местной школе. Они проходят по средам, начинаются в половине седьмого вечера и рассчитаны на десять недель. Может ли ваша команда твердо обещать, что этот человек каждую среду будет вовремя уходить с работы и успевать на занятия?
Обеспечение оптимального баланса работы и жизни сделает вашу компанию более привлекательным работодателем на местном рынке, поможет мотивировать сотрудников и придаст членам команды дополнительную энергию, благодаря которой они на месяцы или даже на годы сохранят высокий уровень производительности. Ошибочно считать, что лучший вариант добиться высокой производительности среди работников умственного труда – это перегрузить их работой. Если строить планы на несколько ближайших дней, то это может оказаться верной тактикой, но через неделю или две все разладится. Никогда не перегружать свои команды и обеспечивать оптимальный баланс работы и жизни – это правила хорошего бизнеса.
Третий элемент рецепта успеха – баланс между требованиями и пропускной способностью – может помочь членам команды избежать перегрузки и создать для них оптимальный баланс работы и жизни. Но у него есть и побочный эффект: он формирует резервы в цепочке создания ценности. В вашей организации должно быть бутылочное горлышко.
Оно есть в каждой цепочке создания ценности. Пропускная способность всей цепочки ограничена пропускной способностью бутылочного горлышка, независимо от того, в каком месте цепочки оно находится. Поэтому, когда вы устанавливаете баланс между входящими запросами и пропускной способностью, вы сознательно создаете простои в каждой точке цепочки создания ценности, за исключением этого бутылочного горлышка.
Большинство менеджеров, услышав о времени простоя, приходят в ярость. Их учили стремиться к максимальному использованию сотрудников (или, иначе говоря, к эффективности), поэтому им кажется, что если создается простой, то необходимы изменения, сокращающие расходы. Возможно, это верно, но важно понимать значение резервов.
Резервы можно использовать, чтобы уменьшить время отклика на срочные запросы и обеспечить плацдарм для совершенствования процесса. Без резервов у членов команды не будет времени размышлять над своей работой и путями ее улучшения, обучаться новым методам, совершенствовать свои инструменты, навыки и умения. Без резервов системе недостает гибкости для реагирования на срочные запросы или последние изменения, а бизнесу – тактической гибкости.
Когда команда способна сосредоточиться на качестве, задать WIP-лимиты, часто выпускать релизы и сбалансировать нагрузку и пропускную способность, она обретет надежную, достойную доверия мощность и станет настоящей машиной по производству программ! Своего рода программным заводом, если хотите. Как только эта мощность установлена, бизнесу следует воспользоваться ею как можно лучше. Это требует такого метода расстановки приоритетов, при котором коммерческая ценность будет максимальной, а риски и расходы – минимальными. Наиболее желательна такая схема приоритетов, которая оптимизирует производительность бизнеса (или его технологического подразделения).
В области разработки программ и управления проектами схемы расстановки приоритетов развиваются с начала появления программных проектов – уже примерно 50 лет. Большинство схем просты. Например, они классифицируют приоритеты как высокие, средние и низкие. Однако для бизнеса это не имеет значения. Несколько более сложные схемы стали использоваться после появления agile-методов разработки ПО – это, например, MoSCoW (Must have – «необходимо»; Should have – «стоило бы»; Could have – «может быть»; Won’t have – «не нужно»). Другие методы, например разработка на основе функционала, пользовались упрощенной и модифицированной техникой анализа Кано, популярной среди японских компаний. Кто-то продолжал защищать строгий нумерованный порядок (1, 2, 3, 4…) на основе коммерческой ценности или технического риска. Однако эта схема часто вызывает конфликт между элементами высокого риска, которые должны оказаться в первом ряду, и элементами высокой коммерческой ценности, которые тоже должны оказаться в первом ряду.
У всех этих схем есть один основной недостаток: в ответ на изменения, вызванные рынком или развитием событий, необходимо расставлять приоритеты заново. Представьте, что у вас есть бэклог с 400 требованиями по приоритетам, расставленными в порядке от 1 до 400, и вы выпускаете пошаговые релизы, используя один из agile-методов разработки с ежемесячными итерациями. Каждый месяц вам придется заново расставлять приоритеты в бэклоге едва ли не для всех 400 элементов.
Опыт показывает, что расстановка приоритетов руководителями отделов сулит проблемы. Причины очень просты: на рынке и в деловой среде слишком много неопределенности. Трудно предсказать будущую относительную ценность элементов; непонятно, когда понадобится тот или иной элемент и какой из них важнее сделать прежде всего. Если вы просите руководителя расставить приоритеты в бэклоге технологических системных требований, то вы тем самым задаете ему слишком много вопросов, ответы на которые к тому же непонятны. А когда люди не уверены в ответе, они обычно реагируют нервно: могут действовать слишком медленно, отказаться от сотрудничества, чувствовать себя некомфортно. Они могут впасть в ступор, постоянно менять мнение, нарушать планы проекта и попусту тратить время команды, реагируя на изменения внесением поправок в ходе работ.
Необходима такая схема расстановки приоритетов, которая позволяет максимально откладывать принятие конкретных обязательств и задает простые вопросы, на которые легко ответить. Канбан делает это, предлагая руководителям отделов заполнить пустые места в очереди, твердо гарантируя время выполнения и приводя показатель доли заданий, выполненных в срок.
У нас уже есть шесть благородных и полезных целей канбан-системы. Во многих случаях этого достаточно. Однако я вместе с другими ранними последователями Канбана выяснил, что возможны и желательны две другие, еще более благородные цели.
Когда я впервые начал использовать канбан-систему, я верил в необходимость прозрачности незавершенных процессов, пропускной способности и качества, поскольку понимал, что это создает доверие клиентов и руководства. Я обеспечивал прозрачность, демонстрируя, где именно в системе находится запрос, когда он может быть выполнен и каково его качество. Прозрачности добивались и в отношении производительности команды. Мне хотелось внушить клиентам уверенность в том, что мы работаем над их запросом, и объяснить, когда он может быть выполнен. К тому же я хотел разъяснить руководству наши методы работы и вызвать доверие к себе как к менеджеру и к моей команде как к крепкой профессиональной группе разработчиков.
Эта прозрачность дала и иной, неожиданный эффект. Прозрачность в рабочих запросах и производительности – это прекрасно, но когда она распространяется и на процесс работы, это еще лучше. Она позволяет всем участникам процесса видеть результаты их действий или бездействия. В итоге люди становятся более рассудительными, готовы менять свое поведение, чтобы повысить производительность системы в целом и сотрудничать над требуемыми изменениями в правилах, персонале, уровнях кадрового состава и т. д.
Для большинства высокопоставленных руководителей бизнеса, к которым я сейчас обращаюсь, эта цель буквально воплощает их пожелания и ожидания в отношении организаций, связанных с разработкой технологий. Прежде всего они нуждаются в предсказуемости в сочетании с деловой гибкостью и хорошим управлением.
Руководители бизнеса хотят давать обещания своим коллегам по совету директоров и по исполнительному комитету, акционерам, клиентам, рынку в целом – и выполнять их. Успех на уровне высшего руководства во многом зависит от доверия, которое, в свою очередь, требует надежности. Высшие руководители стремятся минимизировать риски, чтобы выдавать предсказуемые результаты.
Вдобавок они понимают, что в современном мире изменения происходят все быстрее. Появляются новые технологии, глобализация меняет рынки труда и потребительские рынки, вызывая большие колебания спроса (на продукт) и предложения (рабочей силы). Изменяются экономические условия, конкуренты модифицируют стратегию и предложения на рынке. Вкусы рынка становятся иными, поскольку население стареет, становится богаче и приближается к среднему классу. Поэтому лидеры бизнеса хотят, чтобы он был гибким, стремятся быстро реагировать на перемены и пользоваться всеми возможностями.
И прежде всего они хотят того, что лежит в основе всего этого, – хорошего управления. Они желают демонстрировать, что средства инвесторов тратятся с умом, расходы находятся под контролем и риски, которым подвергаются инвестиционные портфели, распределяются оптимально.
Поэтому им необходимо, чтобы их организации, занимающиеся разработкой технологий, имели большую прозрачность. Они хотят понимать истинное состояние проектов и при необходимости вмешиваться, чтобы помочь. Хотят, чтобы организация управлялась более объективно и факты сопровождались данными, показателями и индикаторами, а не случайными историями и субъективными оценками.
Все эти желания соответствуют организации, действующей на том уровне, который определяется институтом SEI как четвертый или пятый уровень зрелости по пятибалльной шкале модели CMMI. Четвертый и пятый уровни этой шкалы считаются уровнями высокой зрелости. Ее достигли очень немногие независимо от того, подавали ли они заявку на формальную сертификацию SCAMPI[10]. Поэтому неудивительно, что большинство руководителей крупных технологических компаний недовольны результатами своих команд разработчиков, потому что уровень зрелости организации часто не совпадает с желаемым.
Знайте цели и формулируйте преимущества
Итак, у нас есть набор целей для канбан-системы. Нужно знать эти цели и уметь формулировать их, потому что, прежде чем начать работу с Канбаном, следует достичь соглашения с заинтересованными лицами в цепочке создания ценности. Канбан изменит тип взаимодействия с другими группами в нашей компании. Если от заинтересованных лиц требуется согласиться на предлагаемые изменения, то нам нужно уметь сформулировать преимущества, которые их ожидают.
Ниже представлено пошаговое руководство по внедрению канбан-системы для одной цепочки создания ценности в организации. Оно разработано на основе реального опыта и прошло проверку у нескольких ранних последователей Канбана – как тех, кто следовал этим шагам и преуспел, так и тех, кто осознал, что их недостаточную удачу можно было предотвратить, если бы они имели возможность воспользоваться этим руководством.
Руководство призвано, в частности, привлечь внимание к различиям между Канбаном и более ранними методами гибкой разработки. Канбан с самого начала требует вовлеченности в процесс всех участников цепочки создания ценности и менеджеров среднего и даже высшего звена. Принятие Канбана как инициативы снизу, если предварительно не была достигнута договоренность с менеджерами, напрямую не относящимися к данной команде, принесет ограниченные результаты и не даст бизнесу существенных выгод.
Некоторые считают, что такое количество шагов выглядит устрашающе и что если бы они начали с чтения руководства, то отказались бы от внедрения Канбана. Надеюсь, что в книге даны подробные объяснения этих шагов и полезные советы, выработанные на основе опыта именно в этой области.
Шаги для начала действий
1. Определите набор целей внедрения Канбана.
2. Составьте схему цепочки создания ценности (последовательности всех действий, которые предпринимает организация по разработке, чтобы удовлетворить запрос клиента или заинтересованного лица) (см. главу 6).
3. Определите точку входа, которую вы хотите сделать контрольной. Определите действия, предшествующие этой точке, и заинтересованных лиц выше по цепочке создания ценности (см. главу 6). Например, если вы хотите контролировать требования, поступающие к дизайнерам перед выпуском, то такими заинтересованными лицами могут быть менеджеры продукта.
4. Определите точку выхода, после которой вы не претендуете на контроль. Определите действия, следующие за этой точкой, и заинтересованных лиц ниже по цепочке создания ценности (см. главу 6). Возможно, вам не обязательно контролировать итоговую доставку продукта.
5. Определите типы рабочих единиц на основе типов рабочих запросов, поступающих от заинтересованных лиц выше по цепочке (см. главу 6). Есть ли разделение на типы, чувствительные и нечувствительные ко времени выполнения? Если да, то задумайтесь о введении классов обслуживания (см. главу 11).
6. Проанализируйте спрос на каждый тип рабочих единиц. Понаблюдайте за темпами их поступления и вариативностью. Чем обусловлена вариативность? Возможно, она сезонная или приурочена к каким-то событиям? Какие риски связаны со спросом подобного типа? Должна ли система справляться со средним или пиковым спросом? Насколько в этом случае важно не допустить опоздания работы или ее недостаточной надежности? Создайте профиль риска для такого типа спроса (см. главу 6).
7. Назначьте встречу с коллегами выше и ниже по цепочке создания ценности – это может быть одно большое или много мелких совещаний (подробнее – ниже в этой главе):
а) – обсудите правила, касающиеся мощности того элемента цепочки создания ценности, который вы хотите контролировать, и договоритесь о WIP-лимите (см. главу 10);
б) – обсудите и установите с партнерами выше по цепочке создания ценности механизм координации входа – например, регулярное совещание по расстановке приоритетов (см. главу 9);
в) – обсудите и установите с партнерами ниже по цепочке создания ценности механизм координации релиза – например, регулярный релиз ПО (см. главу 8);
г) – возможно, потребуется ввести разные классы обслуживания для рабочих запросов (см. главу 11);
д) – договоритесь о целевом времени выполнения для каждого класса обслуживания рабочих единиц. Такая договоренность известна как соглашение об уровне обслуживания, и о ней идет речь в главе 11.
8. Подготовьте доску (стену) карточек для отслеживания работ в цепочке создания ценности, которую вы контролируете (см. главу 6 и главу 7).
9. При желании заведите электронную систему для отслеживания и подготовки отчетов о ней же (см. главу 6 и главу 7).
10. Договоритесь с командой о проведении ежедневного стендап-совещания возле доски, пригласите на них коллег выше и ниже по цепочке создания ценности, но не поощряйте их вмешательства (см. главу 7).
11. Договоритесь о регулярном проведении ретроспективного анализа производственного процесса, пригласите на него коллег выше и ниже по цепочке создания ценности, но не поощряйте их вмешательства (см. главу 14).
12. Обучите команду работе с доской, WIP-лимитами и вытягивающей системой. Это весь набор изменений, который их коснется. Должностные обязанности останутся прежними. Действия – тоже, как и управление, и объекты. Процесс для них также не изменится, за исключением того, что им придется соблюдать WIP-лимиты и вытягивать работу на основании классов обслуживания, а не получать ее сверху.
Канбан предполагает иной тип сделки
Канбан требует от команды разработчиков заключить с деловыми партнерами сделку иного типа. Чтобы понять это, нужно сначала рассмотреть типичные и широко используемые альтернативы.
В традиционном управлении проектами обязательства принимаются на основании трех сдерживающих факторов: объема, расписания и бюджета. После определенного этапа оценки и планирования выделяется бюджет на привлечение ресурсов, затем определяется объем требований и расписание.
Agile-управление проектами, однако, не дает таких смелых и четких обещаний. Дата окончания работы – примерно через несколько месяцев – может быть определена, но общий объем никогда не устанавливается. Он может определяться приблизительно, но детали никогда не фиксируются.
Нередко заранее оговаривают бюджет (среднемесячные зарплаты), чтобы привлечь к работе фиксированные ресурсы. Agile-команда действует итеративно, предоставляя обновления функциональности за время коротких, ограниченных по времени итераций (или спринтов). Обычно они занимают от одной до четырех недель. В начале каждой из этих итераций проводят оценку и планирование, после чего берут обязательства. Часто обозначают и объем, но если команда не может выполнить обязательство в срок, то жертвуют именно объемом, а дата окончания остается неизменной. На итерационном уровне гибкая разработка похожа на традиционное управление проектами. Ключевая разница состоит в договоренности о том, что в случае форс-мажорных обстоятельств объем будет сокращен. Менеджер проекта традиционного типа имеет в этом случае возможность выбрать, чем пожертвовать – объемом или расписанием, добавить ресурсы или принять смешанное решение.
Канбан предполагает иной тип сделки. Он вообще не берет обязательств, основанных на чем-то неопределенном. Типичный вариант Канбана предполагает соглашение о регулярных релизах высококачественного работающего ПО – например, каждые две недели. Внешним заинтересованным лицам предлагается полная прозрачность рабочего процесса и, при желании, визуализация ежедневного прогресса. Кроме того, они получают возможность выбирать самые важные новые элементы для разработки.
Частота процесса выбора обычно превышает частоту выхода релизов – как правило, раз в неделю. Хотя некоторые команды достигли уровня, когда выбор производится по запросу или очень часто (ежедневно либо раз в неделю).
Команда обещает сделать все, что может, и выпустить как можно больше работающих программ, а также постоянно прилагать усилия по совершенствованию количества, частоты и времени выполнения. Помимо того, что такая команда дает бизнесу невероятную гибкость, поскольку есть возможность выбирать элементы для разработки в очень небольших количествах, дополнительная гибкость достигается в расстановке приоритетов посредством введения нескольких классов обслуживания. Эта идея подробно описана в главе 11.
Канбан не обещает выполнить определенный объем работы к назначенному дню. Он дает обязательства в соответствии с соглашениями об уровне обслуживания для каждого класса обслуживания в сочетании с обязательствами по выпуску надежных регулярных релизов, прозрачности, гибкости работы и расстановки приоритетов, а также по непрерывному совершенствованию качества, пропускной способности, частоты релизов и времени выполнения. Канбан, кроме того, дает обязательства по уровню обслуживания, минимизируя риски по сборке большого количества элементов. Тщательно продуманная канбан-система дает обещания только относительно того, что действительно имеет ценность для клиентов. В свою очередь, команда запрашивает долгосрочные обязательства от клиентов и партнеров по цепочке создания ценности: сохранять постоянные деловые отношения, при которых команда разработки неуклонно стремится повысить уровень обслуживания путем улучшения качества, пропускной способности, частоты релизов и времени выполнения. Поскольку клиент соглашается на постоянное долгосрочное сотрудничество и предпочитает оценивать общий уровень обслуживания, а не заставлять команду сосредоточиваться на четкости реализации конкретного элемента, система может работать.
Традиционный подход к принятию обязательств по масштабу, расписанию и бюджету свидетельствует о разовом характере соглашения. Он предполагает, что дальнейших отношений не будет, и показывает низкий уровень доверия.
Канбан-подход основан на предположении, что команда будет единой и продолжит поддерживать отношения с клиентом в течение долгого времени, а также на повторяемости заказов. Канбан требует высокого уровня доверия между командой разработчиков и партнерами по цепочке создания ценности. Считается, что все верят в пользу формирования долгосрочного партнерства, которое должно обладать высокой эффективностью.
Обязательства в Канбане предполагают, что все в цепочке создания ценности заботятся о производительности системы: количестве и качестве выпускаемых программ, частоте релизов и времени их выполнения. Канбан просит партнеров по цепочке создания ценности придерживаться концепции подлинной деловой гибкости и соглашаться на совместную работу по ее достижению. Это существенно отличает Канбан от более ранних agile-подходов к разработке ПО.
Установив изначально характерные для Канбана отношения с партнерами выше и ниже по цепочке создания ценности, вы берете общее обязательство по производительности на системном уровне и закладываете основы культуры непрерывного совершенствования.
Переговоры по внедрению канбана
Критический этап внедрения Канбана – успешные переговоры по достижению этого иного типа сделки. Во время таких переговоров устанавливаются правила совместной игры по разработке ПО, которых мы и собираемся придерживаться. Жизненно необходимо, чтобы партнеры по цепочке создания ценности принимали участие в их установлении, поскольку им нужно будет следовать в дальнейшем, чтобы условия были соблюдены, а исход соответствовал целям и намерениям.
Седьмой из двенадцати шагов в процессе внедрения Канбана предполагает встречу с партнерами выше (отделы маркетинга и бизнеса, откуда поступают требования) и ниже (отделы системных операций и ввода в эксплуатацию или организации по продажам и доставке) по цепочке создания ценности. Нам нужно обсудить с ними правила относительно WIP, расстановки приоритетов, релизов, классов обслуживания и времени выполнения. Набор принципов, который мы согласуем с этими партнерами, определит правила совместной игры по разработке программного обеспечения. Трудно обсуждать каждый из этих пяти элементов изолированно друг от друга, поскольку они взаимосвязаны. Поэтому, хотя мы понимаем, что нужно задать правила относительно каждого из пяти элементов, переговоры будут идти по кругу, так как участники станут постоянно предлагать новые варианты. Например, если запланированное время выполнения неприемлемо, то, возможно, удастся ввести другой класс обслуживания, который будет предлагать меньшее время выполнения для определенных типов рабочих запросов. Пять элементов – WIP, расстановка приоритетов, релизы, классы обслуживания и время выполнения – это своего рода рычаги, за которые можно дергать, чтобы повлиять на производительность системы. Суть в том, что нужно знать, как именно тянуть за эти рычаги, и обсуждать варианты, чтобы прийти к соглашению, которое будет эффективно работать.
WIP-лимиты
В Дании я познакомился с менеджером по разработке, который рассказал, что у его сотрудников в среднем одновременно находятся в работе семь с половиной задач. Это чересчур много. Сомневаюсь, чтобы кто-то приветствовал подобную многозадачность. На его месте я бы использовал этот факт для переговоров и начал бы с заявления, что в среднем члены команды вынуждены параллельно выполнять семь с половиной заданий. Я указал бы на то, какое влияние это оказывает на время выполнения и предсказуемость, и пригласил бы коллег и других заинтересованных лиц подумать над тем, каково оптимальное число заданий. Некоторые, возможно, предложили бы одно задание на человека. Вероятно, так и есть, но это слишком агрессивный выбор. Что если задание будет заблокировано? Разве не требуется возможность переключиться на альтернативу? Не исключено, что кто-то другой высказался бы за два задания одновременно или в пользу трех. Скорее всего, будут предлагаться именно варианты от одного до трех. Если в команде десять разработчиков и вы сможете договориться о двух заданиях, одновременно выполняемых одним человеком, то получаете в итоге WIP-лимит на команду, равный 20.
Есть и другие варианты. Допустим, вы хотите, чтобы в команде работали попарно. А два задания на пару при общей численности десять программистов соответствуют WIP-лимиту, равному 10. Возможно также, что вы используете метод более тесного сотрудничества – например, разработку по функционалу или функциональные бригады. В этом случае небольшие группы по пять-шесть человек работают над одной MMF, пользовательской историей или одним пакетом функций (как в FDD), то есть над тем, что также называется рабочим пакетом главного программиста (CPWP – Chief Programmer Work Package). Команда функциональных разработчиков может договориться и ограничить число CPWP тремя на команду из десяти разработчиков. (CPWP обычно оптимизируется для эффективности разработки на основании архитектурного анализа домена и содержит от 5 до 15 очень детализированных функций.)
Итак, мы поговорили с заинтересованными лицами о WIP-лимите. Мы обсудили, какой должна быть разумная многозадачность по отношению к предсказуемости релизов и ожидаемому времени выполнения. Достижение договоренности с партнерами о WIP-лимитах крайне необходимо. Хотя WIP-лимиты можно объявить и в одностороннем порядке, привлечение других заинтересованных лиц и достижение консенсуса устанавливает общие обязательства – теперь все должны придерживаться одинаковых правил. В будущем такие обязательства могут стать бесценными. Настанет день, когда партнеры попросят нас взять дополнительную работу. Они обязательно так сделают, потому что им покажется это важным и ценным. Они будут руководствоваться самыми благими намерениями. Но мы сможем ответить им, что у нас есть заранее оговоренный WIP-лимит и его надо уважать. Система к тому времени, вероятно, будет полной, и согласие взять дополнительный элемент будет означать превышение WIP-лимита. Поэтому наш ответ должен звучать так: «Мы охотно взяли бы новую работу, потому что понимаем, как она важна для вас. Но вы ведь знаете, что у нас есть заранее оговоренный WIP-лимит. Вы участвовали в этом решении и понимаете, почему мы его приняли. Мы хотим сохранить предсказуемость и своевременность обработки запросов. Чтобы взяться за ваш запрос, нам придется отложить в сторону другие. Какой из элементов, которые сейчас находятся в работе, мы, по-вашему, должны отложить, чтобы взяться за новый?»
Не включи мы партнеров в процесс принятия решения по WIP-лимиту, подобный ответ был бы невозможен. Они продолжали бы нас уговаривать. После этого вытягивающая система со всеми WIP-лимитами распалась бы и вся организация повернула бы обратно к выталкивающей системе планового производства.
Чтобы успешно взаимодействовать в Канбан-разработке ПО, правила игры должны быть установлены общим решением всех заинтересованных лиц.
Расстановка приоритетов
Мы хотим договориться и о механизме пополнения очереди. Обычно это достигается решением о проведении регулярного совещания по пополнению системы и определением механизма выбора новых элементов. Разговор можно начать так: «Если нам нужно будет спросить вас: “Какие два элемента вы хотите видеть реализованными через сорок два дня?” – то как часто вы сможете встречаться с нами, чтобы отвечать на этот вопрос? Надеемся, что такие совещания будут занимать не более получаса».
Поскольку вы предлагаете очень конкретную тему, задаете прямой вопрос и обещаете, что время совещания будет минимальным, обычно партнеры выше по цепочке быстро соглашаются на сотрудничество. Нередко удается договориться о еженедельных встречах. Более частые совещания характерны для отраслей с ускоренным темпом деятельности – например, массмедиа, где циклы релизов очень частые.
Релиз
Затем нужно договориться примерно о том же с партнерами ниже по цепочке. То, какая именно каденция релизов является целесообразной, очень зависит от отрасли или ситуации. Если речь идет о веб-программах, то их нужно поставлять на группу серверов. Реализация такой программы включает копирование файлов и, возможно, обновление схемы баз данных с последующим переносом данных с одной версии схемы на другую. Для переноса данных, вероятно, понадобится собственный код, а его выполнение может занять некоторое время. Чтобы вычислить общее время реализации, нужно учесть количество серверов и файлов для копирования, время на безопасное закрытие систем и их перезагрузку, на перенос данных и т. д. Иногда это занимает несколько минут, а порой – несколько часов или дней. В других отраслях нередко приходится создавать физические носители – DVD, упаковывать их в коробки и поставлять по физическим каналам, направляя распространителям, дилерам, розничным операторам или уже существующим корпоративным клиентам. Могут быть задействованы и другие виды деятельности – например, печать бумажных инструкций или обучение сотрудников отделов продаж и техподдержки. Иногда для этих людей нужно разрабатывать и отдельную программу обучения.
Например, в 2012 году я принимал участие в релизе первого из обновлений мобильной телефонной сети Sprint PCS. Это обновление на пути к технологии 3G называлось lxRTT. На рынок оно вышло как PCS Vision и включало выпуск примерно 15 новых аппаратов с 16 новыми функциями, которые использовали высокоскоростные возможности передачи данных новой сети. У Sprint в США была розничная сеть, где работали 17 тысяч человек. Примерно столько же было в кол-центрах, которые занимались технической поддержкой пользователей. И участники розничного канала продаж, и сотрудники техподдержки должны были пройти обучение, чтобы запуск нового сервиса стал эффективнее. Я в шутку предположил, что оптимальнее всего закрыть все на пару дней, вывезти всех на ночь в Канзас-Сити и арендовать стадион команды «Канзас-Сити Чифс», на котором и провести двухчасовую презентацию в PowerPoint на больших экранах в обоих концах стадиона. Возможно, это был самый эффективный, но, конечно, неприемлемый способ. Вряд ли клиенты одобрили бы 48-часовое отсутствие поддержки на время обучения операторов технологии следующего поколения. А двухдневное отсутствие продаж по розничному каналу явно не помогло бы годовому бюджету.
Была разработана программа обучения, проведена подготовка инструкторов. Создали также программу обучения региональных сотрудников розничных продаж и работников кол-центров. Инструкторы обучали их в течение шести недель в составе небольших групп и в нерабочее время. Расходы на это были огромными: во-первых, шесть недель – это много, а наиболее эффективно пользоваться полученными знаниями сотрудники могли тоже в течение примерно шести недель. Если бы мы не уложились в окно запуска нового сервиса, то обучение пришлось бы повторить, а запуск отложить как минимум еще на шесть недель.
Если сфера вашей деятельности – что-то вроде телефонных сетей, то вам известно, что каденция релизов в ней не очень частая. Когда операционные расходы на релиз включают шесть недель обучения, релизы с интервалом чаще чем в год противопоказаны.
Желаемый результат – это самая частая каденция релиза из осмысленных. Поэтому начните с вопроса: «Если мы предлагаем вам высококачественный код с минимумом ошибок, который выходит в адекватном виде и при этом обеспечивается прозрачность относительно его сложности, а также надежность поступления, то как часто вы сможете выводить его на рынок с точки зрения здравого смысла?» Это вызовет обсуждение использованных вами определений, и понадобится еще раз убеждать партнеров. Однако следует стремиться к результату, который приводит к наибольшей деловой гибкости и не создает излишнюю нагрузку ни на одну часть системы.
Время выполнения и классы обслуживания
Когда разговор заходит о времени выполнения, полезно привести накопленные данные по предыдущей производительности. В идеале хорошо иметь данные по времени выполнения и инженерному времени. В примере с Microsoft (глава 4) было известно, что время выполнения составляет примерно 125 дней на устранение ошибок первой степени срочности и 155 дней – на ошибки остальных степеней. Главное, что мы можем отсюда почерпнуть, – это наличие двух классов обслуживания. Ошибки первой степени в какой-то форме обрабатывались раньше. Возможно, формальных правил не было, но так уж выходило, что ошибки первой степени устранялись быстрее.
Зная это, мы можем предложить два разных класса обслуживания с самого начала. Вынесем на рассмотрение внешних заинтересованных лиц вопрос о назначении двух классов обслуживания и принятии отдельного целевого времени выполнения для каждого из них.
Также из предыдущих данных известно, что в среднем инженерная работа занимала 11 дней, а при самом высоком качестве работ – 15. Поэтому мы решили предложить 25-дневное время выполнения, считая с момента выбора элемента из входящей очереди. Больше никаких научных данных не потребовалось. А теперь представьте психологический эффект от этого: в бизнесе привыкли, что работа занимает четыре-пять месяцев, а мы предлагали 25 дней. Разница в том, что мы говорили о 25 днях как о времени выполнения, не учитывая ожидание в очереди, а 155 дней включали и его. Тем не менее это выглядело фантастическим улучшением. Неудивительно, что представители бизнеса согласились.
Есть и другие варианты. Можно взять предыдущие данные по инженерной работе и разместить их на графике статистического контроля процессов. Это даст вам верхний контрольный лимит (или 3-Sigma). Возможно, вы захотите немного буферизовать этот верхний лимит, чтобы нейтрализовать внешнюю вариативность. Но если вы так поступаете, нужно честно признаться в этом партнерам и показать, что вы провели соответствующие вычисления.
Еще одна альтернатива – спросить, в каком уровне ответной реакции нуждается бизнес. Лучше всего это сделать в контексте задания классов обслуживания. Например, если вам говорят: «Нам нужен релиз через три дня», спросите: «Все ли элементы нужно реализовать за три дня?» Чаще всего ответ будет отрицательным. Это даст возможность запросить определение типов запросов, которые должны быть реализованы в течение трех дней. После этого можно создать класс обслуживания для данного типа заданий. Повторите процесс для оставшихся заданий.
В итоге должно получиться расслоение рабочих запросов на несколько уровней, которым и будут соответствовать разные классы обслуживания. Не исключено, что на каждом уровне встретятся задания, которые потребуют примерно одинаковых издержек из-за отсрочки. Подробнее создание классов обслуживания и идея функций издержек из-за отсрочки описаны в главе 11.
Целевое время выполнения, которое вы устанавливаете для каждого класса обслуживания, должно быть именно целью, а не обещанием. Вы обещаете сделать все от вас зависящее, чтобы уложиться в целевое время и сообщить о выполнении в срок, установленный в соглашении об уровне обслуживания для каждого класса обслуживания. В некоторых ситуациях, чтобы договориться о том, что время выполнения в соглашении об уровне обслуживания – это цель, а не обязательство, может не хватить доверия. Если приходится согласиться с тем, что время выполнения в соглашении об уровне обслуживания считается обязательным, следует ради безопасности установить буфер. Это укажет на то, что низкий уровень доверия выливается в прямые экономические расходы.
Выходные критерии для обсуждений с партнерами таковы: вы добились консенсуса по WIP-лимитам по всей цепочке создания ценности, достигнуто соглашение о координации расстановки приоритетов и используемом для нее методе и такое же соглашение о координации и методах сдачи работы, имеется определение набора соглашений об уровне обслуживания, включающее целевое время выполнения для каждого класса обслуживания.
Выводы
• Можно выделить как минимум восемь целей внедрения Канбана в вашей организации.
• Улучшайте производительность, внося в процесс усовершенствования, которые будут встречены с минимальным сопротивлением.
• Сдавайте высококачественную работу.
• Время выполнения должно оставаться предсказуемым благодаря контролю числа незавершенных заданий.
• Создайте оптимальные условия для членов команды, улучшив их баланс работы и жизни.
• Внесите в систему резервы, сбалансировав нагрузку и пропускную способность.
• Обеспечьте простой механизм расстановки приоритетов, при котором обязательства откладываются, а варианты долго остаются возможными.
• Обеспечьте прозрачную схему, чтобы были видны возможности для роста. Тогда будут возможными сдвиги в сторону культуры большего сотрудничества, которые приведут к непрерывному совершенствованию.
• Боритесь за процесс, дающий предсказуемые результаты, деловую гибкость, хорошее управление и переход к тому, что Институт по разработке программного обеспечения называет организацией высокой зрелости.
• Важно определить цели и уметь формулировать преимущества введения Канбана, чтобы достичь консенсусного соглашения с другими заинтересованными лицами.
• Следуйте пошаговому 12-этапному руководству по введению Канбан-процесса.
• Канбан предполагает иной тип сделки с внешними заинтересованными лицами и владельцами бизнеса. Это сделка, основанная на долгосрочных отношениях и обязательствах по производительности на системном уровне.
• Привлечение внешних заинтересованных лиц к договору о базовых элементах канбан-системы позволяет заручиться их сотрудничеством.
• Основные правила, касающиеся WIP-лимитов, целевого времени выполнения, классов обслуживания, расстановки приоритетов и релизов, – это правила совместной игры по разработке программного обеспечения.
• Привлечение внешних заинтересованных лиц к сотрудничеству позволит рассчитывать на их помощь позже, когда система подвергнется серьезным нагрузкам.
Часть IV
Совершенствование
Глава 16
Три типа возможностей для совершенствования
Главы 6–15 рассказывают о том, как создать канбан-систему и поддерживать ее работу и как принять на вооружение Канбан-подход к управлению изменениями и совершенствованию. Оставшаяся часть этой книги описывает, как обнаружить возможности для совершенствования, что с ними делать и как выбрать между разными возможностями.
В главе 2 приводятся пять ключевых практик, которыми должна обладать организация, использующая Канбан. Пятая по счету связана с использованием моделей для определения, оценки и стимулирования возможностей по совершенствованию. Вариантов много. В этой главе речь пойдет о трех распространенных моделях и некоторых их разновидностях: о теории ограничения систем и ее пяти направляющих, об идее бережливого мышления (Lean Thinking), которая определяет ненужные действия как экономические затраты, а также о некоторых вариантах, сводящихся к определению и снижению вариативности. Возможны и другие модели. Уже проходят эксперименты с такими моделями, как теория реальных опционов и управление рисками. Ниже приводятся примеры, которые можно использовать как точку отсчета. Хотелось бы, чтобы вы взяли эти методы на вооружение, поскольку они действительно работают, а впоследствии расширяли горизонты знаний и изучали другие модели, позволяющие командам создавать усовершенствования.
Бутылочные горлышки, устранение потерь и снижение вариативности
Каждая из этих моделей совершенствования подробно исследовалась и разрабатывалась в соответствующей области знаний. В каждой из них присутствует свой стиль представлений о теории непрерывного совершенствования. В Канбане я постарался синтезировать все три школы и дать обзор того, как выявлять возможности совершенствования и реализовывать усовершенствования при внедрении каждой модели.
В каждой из трех школ, описанных выше, есть группа лидеров, конференции, собственный набор знаний и опыта, группа последователей. Любая компания может влиться в одну или сразу в несколько таких школ. Преимущество в данном случае – это умение показать, как Канбан-метод может открыть возможности совершенствования в любимом стиле вашей организации. Широкий набор парадигм для улучшения и инструментов, из которых можно выбрать, должен обеспечить высокий уровень гибкости при изменениях. Те, кто хорошо знаком с методологиями непрерывного совершенствования, могут пролистать эти страницы и перейти сразу к главе 17. А всем, кому интересен анализ доступных методов, а также сведения из литературы и истории, оставшаяся часть главы будет полезна.
Теория ограничения
Теория ограничения была разработана Элияху Голдраттом и опубликована впервые в уже упоминавшемся бизнес-романе «Цель» в 1984 году. За последние 25 лет вышло несколько редакций «Цели», в последних из которых была более четко обрисована теоретическая структура, известная как «пять направляющих шагов».
Пять направляющих шагов – основа непрерывного совершенствования в теории ограничений. Это так называемый процесс непрерывного совершенствования (POOGI, Process Of OnGoing Improvement). Теория ограничений (или TOC) вообще полна аббревиатур. Как ни странно, пять направляющих шагов – исключение. Эти названия не сокращаются до ПНШ.
В 1990-е годы в рамках теории ограничений разработан метод анализа глубинных причин и управления изменениями, известный как мыслительные процессы (он же TP, Thinking Processes). Причина в осознании консультантами, придерживающимися ТОС, того факта, что их ограниченный успех в работе с клиентами вызван сопротивлением изменениям и недостаточно умелым управлением ими.
Казалось, что пять направляющих шагов успешно работают только с проблемами потока, а многое из того, что возникает на рабочем месте, не слишком вписывается в эту парадигму. Так возникли TP. Профессиональная подготовка и программа обучения для консультантов по ТОС сместилась от использования пяти направляющих шагов и применения этой концепции (например, «барабан-буфер-канат») к использованию ТР. Поэтому многие члены сообщества, говоря о ТОС, имеют в виду ТР, а не пять направляющих шагов. Бывая на конференциях по ТОС, могу с уверенностью сказать, что использование пяти направляющих шагов кажется сейчас своего рода утраченным искусством.
Сообщество ТОС, насколько я могу судить, склоняется к принятию существующих парадигм и не ставит их под сомнение. Поэтому решение ТОС для управления проектами – критическая цепь – развилось из парадигмы тройного ограничения (объем, бюджет и сроки) и модели графика зависимостей для организации задач в проекте. Эта модель не подверглась никаким сомнениям, пока я не опубликовал свою первую книгу Agile Management for Software Engineering, где высказал критику в адрес парадигмы управления проектами и предположил, что лучше моделировать проекты как цепочку создания ценности и проблему потока, к которым применять впоследствии пять направляющих шагов. Благодаря этому стало возможно использовать все знания в области бережливого управления, основанные на понятии потока, и совместить их с представлением о бутылочных горлышках, характерном для пяти направляющих шагов. Синтез ТОС с бережливым управлением привел к улучшению производительности проектов и всей организации и заложил основания для зарождения Канбана.
Я утверждал, что любой процесс или рабочий поток, предполагающий разделение труда, можно определить как цепочку создания ценности, а любую цепочку создания ценности – как имеющую поток. Бережливое управление и производственная система Toyota по сути выстроены вокруг этого принципа. Если любая цепочка создания ценности обладает потоком, то к ней можно применить пять направляющих шагов. Таким образом, пять направляющих шагов – это вполне удовлетворительный POOGI, и TP не требуется, если не использовать его в качестве инструмента управления изменениями. У меня отношения с TP не сложились. Как видно из этой книги, управление изменениями я предпочитаю осуществлять при помощи Канбана.
Пять направляющих шагов
Пять направляющих шагов – это простая формула процесса непрерывного совершенствования. Вот они.
1. Определить ограничение.
2. Решить, как максимально использовать это ограничение системы.
3. Подчинить все остальные составляющие системы решению, принятому на шаге 2.
4. Ликвидировать ограничение.
5. Избегать инерции, определить следующее ограничение и вернуться к шагу 2.
Шаг 1 предлагает найти бутылочное горлышко в цепочке создания ценности.
Шаг 2 призывает определить потенциальную пропускную способность этого бутылочного горлышка и сравнить ее с тем, что происходит на самом деле. Как вы увидите, бутылочное горлышко редко работает на полную мощность (можно даже сказать, что этого никогда не происходит). Поэтому задайтесь вопросами: «Как максимально использовать бутылочное горлышко? Что нужно изменить, чтобы реализовать его потенциал?» Это соответствует слову «решить» на шаге 2.
Шаг 3 предлагает внести все необходимые изменения, чтобы воплотить в жизнь идеи шага 2. Это может быть связано и с изменениями где-то в другом месте цепочки создания ценности, которые тоже служат тому, чтобы извлечь максимум из бутылочного горлышка. Действия, направленные на максимальное увеличение мощности бутылочных горлышек, и называются их использованием.
Шаг 4 предполагает, что, если бутылочное горлышко работает на всю мощь, но не обеспечивает достаточной пропускной способности, нужно, чтобы ее повысить, расширить ограничение. Шаг 4 предлагает внедрить улучшения для повышения мощности и пропускной способности, чтобы существующее бутылочное горлышко было ликвидировано, а ограничение системы переместилось куда-нибудь еще по цепочке создания ценности.
Шаг 5 требует от нас терпения: нужно дать изменениям время на стабилизацию и затем определить новое бутылочное горлышко в цепочке создания ценности и повторить процесс. В результате получается система непрерывного совершенствования, в которой пропускная способность постоянно возрастает.
Если правильно внедрить пять направляющих шагов, то организация сможет развить культуру непрерывного совершенствования
О том, как определять бутылочные горлышки и работать с ними при помощи пяти направляющих шагов, читайте в главе 17.
Бережливое управление, TPS и устранение потерь
Бережливое управление – концепция, появившаяся в начале 1990-х годов благодаря книге Джеймса Вумека, Дэниела Джонса и Дэниела Руса «Машина, которая изменила мир»[11], в которой описывались принципы работы производственной системы Toyota (TPS). Поначалу литература о бережливом управлении не смогла определить, что управление вариативностью является неотъемлемой частью TPS. Это стало известно благодаря системе глубинных знаний Деминга.
Также бережливое управление пало жертвой неверных интерпретаций и упрощенчества. Многие консультанты по бережливому управлению ухватились за идею устранения потерь и обучали бережливому управлению просто как средству избежать их. Получалось, что все рабочие действия делятся на создающие и не создающие ценность. Последние, влекущие за собой потери, подразделяются на необходимые и излишние. Излишние действия предлагалось исключить, а необходимые – сократить. Хотя такое использование бережливого управления для совершенствования вполне возможно, оно может привести к недополученной прибыли и оставляет в стороне идеи ценности, цепочки создания ценности и потока, характерные для бережливого управления.
Канбан позволяет реализовать все аспекты бережливого подхода и дает инструменты для оптимизации получаемой ценности, поскольку сосредоточивается не только на устранении потерь, но и на управлении потоком.
В главе 18 рассказывается о том, как определить ведущие к потерям действия и что с ними делать.
Система деминга и «шесть сигм»
Эдвардс Деминг считается одним из трех отцов-основателей движения по контролю качества в XX веке. Однако его вклад самый существенный.
Он внес усовершенствования в статистический контроль процессов (СКП) и разработал на его основе технику управления, которую назвал системой глубинных знаний. Его система призвана не позволять менеджерам принимать плохих решений, заменяя их лучшими решениями – основанными на статистике, объективными, часто противоречащими интуиции. Деминга вполне заслуженно называют едва ли не лучшим исследователем в области менеджмента в XX веке. Его работы привели к развитию науки о менеджменте из статистического контроля процесса и контроля качества.
Деминг оказал значительное влияние на японскую философию управления, и его работы по СКП и системе глубинных знаний стали краеугольным камнем TPS.
Хотя СКП взяли на вооружение многие Канбан-команды, отличающиеся высокой зрелостью (например, в инвестиционном банке BNP Paribas в Лондоне), его обсуждение выходит за рамки этой книги. Предполагаю рассмотреть его в моей следующей работе – о продвинутых Канбан-техниках.
Однако принципы понимания вариативности систем и рабочих заданий, лежащие в основе СКП, очень полезны. Предшественник Деминга Уолтер Шухарт разделил вариативность выполнения задач на две категории: случайные причины и выявляемые причины. Впоследствии Деминг переименовал эти категории в обычные причины и особые причины, признав во втором издании своей «Новой экономики», что сделал это «в основном по педагогическим соображениям». Никакого новшества с изменением терминов не связано. Понимание вариативности и ее влияния на производительность и развитие умения распределять вариативность по двум указанным категориям – это необходимые для менеджера навыки. Научиться предпринимать соответствующие управленческие действия на основании понимания типов вариативности необходимо для программы непрерывного совершенствования. И бережливое управление, и теория ограничений высоко ценят необходимость понимания вариативности для дальнейшего совершенствования, даже если оно проходит под лозунгами управления бутылочными горлышками или устранения потерь.
В главе 19 объясняется, как распознать обычные и особые причины вариативности, предлагаются советы по соответствующим управленческим действиям. Та же тематика присутствует в главе 20. В ней описано, как научиться такому управлению проблемами, которое реагирует на вариации, вызванные выявляемыми причинами, чтобы как можно быстрее устранить подобные проблемы, сохранить ход потока и оптимизировать создаваемые ценности. Заметим, что без познаний в области управления вариативностью и концентрации на борьбе с этими вариациями работа с потоком будет неэффективной. Бережливое управление без идей Деминга – это управление без понимания вариативности, а следовательно, и без концентрации на поддержке потока. Учитывая, что в ранней литературе по бережливому управлению отсутствовали понимание вариации и любые отсылки к системе глубинных знаний Деминга, легко понять, почему в привычку вошло отношение к бережливому управлению как к процессу устранения потерь.
Идеи Деминга глубоко укоренились в Японии: TPS использует систему глубинных знаний и СКП для выявления локальных возможностей для улучшения. В США на основе идей Деминга появилась еще одна концепция – «шесть сигм». Она зародилась в Motorola, но широкую известность приобрела благодаря компании General Electric, которой руководил Джек Уэлч.
Концепция шести сигм пользуется СКП для определения вариаций с обычными и особыми причинами. Затем она применяет процесс, подобный описанному Демингом, чтобы исключить вариации с особыми причинами на глубинном уровне и воспрепятствовать их повторному возникновению, а затем сократить число вариаций с обычными причинами, чтобы сделать процесс, рабочий поток или систему более предсказуемыми.
В отличие от TPS, основанной на инициативе снизу, при которой наделенные полномочиями сотрудники делают сотни и тысячи мелких улучшений в рамках культуры кайдзен, концепция шести сигм выросла в административно-управленческий метод, предполагающий меньше доверия и возможностей для улучшения. Он обычно внедряется на стратегическом уровне и применяется к конкретным независимым проектам. Руководитель проекта носит титул обладателя черного пояса и должен иметь многолетний опыт освоения этой методологии, благодаря чему и заслужил свой статус. Поскольку Канбан использует идеи Деминга и обеспечивает инструментарий и прозрачность, необходимые для рассмотрения вариативности и ее последствий, он может быть использован для запуска как программы усовершенствования, основанной на кайдзен, так и программы, использующей концепцию шести сигм.
Совмещение канбана с культурой вашей компании
Если ваша компания управляется в соответствии с концепцией шести сигм, Канбан поможет внедрить инициативы шести сигм в программы, системы, разработку продукта или IT-организацию. Если ваша компания относится к бережливым, то Канбан идеально в нее впишется. Он поможет развить бережливую инициативу для программ, систем, разработки продукта или IT-организации. Компаниям, использующим теорию ограничений систем, Канбан поможет начать программу управления ограничениями (устранения бутылочных горлышек) для систем, разработки продукта или IT-организации. Но, возможно, вам придется перестроить вытягивающую систему в виде системы «барабан-буфер-канат», а не в виде канбан-системы. Поскольку Канбан развился из варианта системы «барабан-буфер-канат», я уверен, что это сработает. Однако разъяснения, как смоделировать цепочку создания ценности и задать WIP-лимиты для системы «барабан-буфер-канат», выходят за рамки этой книги.
Выводы
• Канбан требует привлечения моделей для определения возможностей усовершенствования.
• Канбан поддерживает как минимум три типа методов непрерывного совершенствования: управление ограничениями (устранение бутылочных горлышек), устранение потерь, управление вариативностью (а также СКП и система глубинных знаний).
• Канбан позволяет определить бутылочные горлышки и полностью воплотить пять направляющих шагов из теории ограничений.
• Канбан позволяет визуализировать приводящие к потерям действия, его можно использовать для полного разворачивания бережливой инициативы для программ, систем, разработки продукта или IT-организации.
• Канбан обеспечивает инструментарий для использования системы глубинных знаний Эдвардса Деминга и статистического контроля процессов. Он применяется для внедрения кайдзен-инициативы или инициативы в рамках концепции «шесть сигм».
Глава 17
Бутылочные горлышки и ограниченная доступность
Вашингтон SR-520 – это шоссе, которое связывает Сиэтл с его северо-восточными пригородами Кирклендом и Редмондом. Основная артерия для жителей пригородов, работающих в центре города, а также для сотрудников Microsoft и других базирующихся в этих пригородах высокотехнологичных компаний (например, AT&T, Honeywell и Nintendo), которые живут в городе и ездят на работу в обратном направлении. Каждый день в течение восьми часов дорога представляет собой бесконечную пробку – бутылочное горлышко в обоих направлениях. Если после обеда встать на мосту, который пересекает шоссе по Северо-Восточной 76-й улице в небольшом пригороде Медина (недалеко от дома Билла Гейтса на берегу озера Вашингтон), и посмотреть на восток, то видно, как пробка ползет на запад, по направлению к городу, медленно карабкаясь на холм из Бельвью, прежде чем распадается на две полосы, пересекая понтонный мост в Сиэтл. Скорость пробки, движущейся вверх по холму, составляет примерно 15 километров в час, и машины в потоке постоянно останавливаются. Если вы пересечете улицу и посмотрите на запад, на небоскребы Спейс-Нидл и Олимпик-Маунтинс в центре Сиэтла, то увидите гладкое движение со скоростью около 80 километров в час. Что за волшебство творится прямо у вас под ногами, почему скорость так резко меняется, а поток из рваного делается гладким? Дело в том, что прямо перед мостом дорога сужается с трех полос до двух – нужно пересечь озеро по понтонному мосту. Крайняя правая полоса шоссе предназначена для автомобилей с двумя и более пассажирами. Она занята общественным транспортом – автобусы ездят в город и из него – и некоторым количеством личных автомобилей. Эти машины вливаются в другой поток, чем вызывают замешательство и замедляют движение. На протяжении нескольких километров перед мостом в шоссе вливается еще несколько дорог, что увеличивает загруженность шоссе в пиковое время. В результате поток имеет рваный ритм и очень низкую скорость.
Планируя безопасность дорожного движения, специалисты беспокоятся о дистанции между машинами. В идеале она должна быть достаточной, чтобы отреагировать на изменения и при необходимости срочно и безопасно остановиться. Это расстояние зависит от скорости и времени реакции. Правила рекомендуют «дистанцию» в две секунды. На языке бережливого производства это идеальное время такта между машинами. Если у нас есть две полосы и две секунды между машинами, то максимальная пропускная способность дороги – 30 машин на полосу в минуту, то есть 60 машин в минуту. Это верно независимо от скорости машин. Не выполняются эти правила только в экстремальных случаях – для очень малых скоростей и для очень высоких, существенно превышающих ограничение в 80 километров в час, установленное на SR-520. Таким образом, пропускная способность (которая в управлении транспортными потоками называется емкостью, что приводит к некоторым недоразумениям) составляет 3600 машин в час.
Но если встать на мосту и посчитать, сколько машин проходит под ним примерно в пять вечера в рабочий день, вы заметите, что на понтонный мост в сторону Сиэтла заезжает менее 10 машин в минуту. Несмотря на высокий спрос, дорога работает менее чем на одну пятую своей потенциальной пропускной способности! Почему?
Понтонный мост через озеро Вашингтон – это бутылочное горлышко. Все мы понимаем, что это значит. От ширины бутылочного горлышка зависит скорость, с которой можно наполнить или опустошить бутылку. Из широкого горлышка вода льется быстро, но в таком случае велик риск все пролить. Если горлышко узкое, то вода льется медленнее, но точность в этом случае выше. Бутылочные горлышки ограничивают потенциальную пропускную способность – в нашем случае от 60 машин в минуту, то есть 3600 в час, до менее чем 10 машин в минуту, то есть 600 в час.
Бутылочное горлышко в потоке проекта находится в любом месте, где выстраивается очередь на обработку заданий. В случае с шоссе SR-520 эта очередь состоит из автомобилей, ждущих въезда на мост в 11 километрах к востоку. В разработке ПО это может быть любая очередь заданий, с которыми еще не начали работать, или заданий в работе: требования, ожидающие анализа, результаты анализа, которые нужно проектировать, разрабатывать и тестировать, протестированные задания, которые нужно выпускать, и т. д.
Как уже говорилось, SR-520 в пиковое время, когда оно пользуется наибольшим спросом, работает примерно на 20 % от своего потенциала. Чтобы полностью разобраться в этом, нужно понять, как максимально использовать потенциал бутылочных горлышек и каким образом на него влияет вариативность. Этому посвящена данная глава, а также глава 19.
Ресурсы ограниченной мощности
SR-520 в районе моста Северо-Восточной 76-й улицы – ресурс ограниченной мощности. Она составляет 60 автомобилей в минуту в двух полосах. Дорога, ведущая к этому отрезку, имеет три полосы, так что участники движения вынуждены перестраиваться, чтобы пересечь озеро по древнему понтонному мосту, который был спроектирован 50 лет назад и рассчитан на две полосы. В то время этого вполне хватало – никакого бутылочного горлышка не предвиделось. Восточные пригороды были небольшими поселениями, так что пересекать мост приходилось редко, притом в основном в город, а не в обратную сторону, как сейчас.
Увеличение мощности
С точки зрения ограниченности ресурсов можно провести аналогию между SR-520 и девушкой – дизайнером пользовательского интерфейса в команде по производству ПО, отвечающей за проектирование всех экранов, на которых происходит взаимодействие с пользователем. Дизайнер работает усердно, но ее мощности не хватает, чтобы покрыть все потребности проекта. Естественная реакция большинства менеджеров – нанять кого-то ей в помощь. В теории ограничений Элияху Голдратта такое решение называется «расширением ограничений»: мы добавляем мощности, и бутылочное горлышко устраняется.
В случае с SR-520 эквивалентом будет замена понтонной переправы через озеро Вашингтон новым мостом с тремя полосами движения в каждую сторону. Чтобы сохранялось равновесие, это должен быть мост с одной полосой для загруженного транспорта и велодорожкой, а также с двумя полосами для всех участников движения. Именно этим собирается заняться Министерство транспорта штата Вашингтон. Мост будет стоить сотни миллионов долларов, на его возведение понадобится около десяти лет. На момент написания этой книги строительство даже не началось.
Оказывается, увеличение мощности ограниченного ресурса – это крайний вариант. Расширение бутылочного горлышка стоит времени и денег. Если, например, нанимать второго дизайнера пользовательского интерфейса, то надо найти не только средства на его зарплату, но и бюджет на сам процесс найма, который может включать комиссионные для агентов по подбору персонала. Пока мы рассматриваем резюме и проводим собеседования с кандидатами, тормозится ход текущего проекта. А наш самый драгоценный ресурс, та самая девушка – дизайнер пользовательского интерфейса с ограниченной мощностью, будет вынуждена отрываться от работы по проекту, чтобы читать резюме, отбирать кандидатов, проводить собеседования. В результате ее возможности заниматься дизайном сокращаются, как и потенциальная пропускная способность всего проекта. Именно из-за таких ситуаций появился закон Фреда Брукса, который гласит: «Если проект не укладывается в сроки, то добавление рабочей силы только еще больше задержит его». Наблюдения Брукса были основаны на отдельных случаях, а сейчас можно дать научное объяснение этого феномена; в производстве ПО, по крайней мере, в последние 35 лет установилось понимание того, что при наборе дополнительных сотрудников проект замедляется.
Загрузка и защита
Вместо того чтобы немедленно расширять бутылочное горлышко, теряя время и деньги, замедляя процесс, лучше сначала найти возможность полностью использовать мощность этого ресурса. Например, мы выяснили, что SR-520 в пиковое время имеет пропускную способность лишь в 20 % от своего потенциала. Что нужно предпринять, чтобы ее повысить? Давайте немного пофантазируем. Если бы пропускная способность в час пик достигала своего максимума – 3600 машин в час, пришлось бы заменять существующий мост новым? А стало бы время поездки достаточно коротким, чтобы налогоплательщик штата Вашингтон предпочел видеть свои налоги потраченными на более насущные нужды, например на книги для школьных библиотек? Может быть!
Но как использовать весь потенциал дороги? Источник проблемы – это водители. Скорость их реакции и действия, которые они предпринимают, очень разнообразны. Когда машины съезжают с полосы для загруженного транспорта, автомобили в средней полосе должны притормозить и освободить место для съезжающих. Некоторые водители реагируют медленнее остальных, кто-то жмет на тормоза более яростно, а в результате движение становится непредсказуемым. Часть водителей, которых нервирует неустойчивое движение в полосе перед ними и снижение скорости по сравнению с соседней левой полосой, решают перестроиться в нее. Эффект повторяется. Все машины замедляют ход, но пропускной способности вредит не это. Самое важное – расстояние от одной машины до другой. Для равномерного движения желателен двухсекундный зазор между транспортными средствами[12]. Однако человеческий фактор означает, что машины не тормозят и не ускоряются равномерно, так что расстояния между ними расходятся. Разное время реакции отдельных людей, нажимающих на педали газа и тормоза, и время реакции двигателей, трансмиссий и коробок передач в автомобилях означает, что расстояния продолжают расширяться и создается пробка. Вариативность системы оказывает огромное влияние на пропускную способность.
Устранение этой проблемы увлекает нас в сказочную с точки зрения управления автомобилем страну, хотя некоторые немецкие производители уже проводят подобные эксперименты. Системы, которые используют радары и лазеры для оценки дистанции между автомобилями и позволяют сохранить равномерность движения, могут снять вариативность, существующую на SR-520. Такие системы способны эффективно замедлять поток автомобилей, сохраняя интервал между ними. В результате пропускная способность трассы остается высокой. Однако исключение вариативности в отношении частных автомобилей имеет свои пределы. Чтобы обеспечить низкую вариативность транспорта, нужно связать пассажирские автомобили вместе и поставить их на рельсы. Вот, собственно, причина того, почему массовый скоростной железнодорожный транспорт более эффективно, чем автомобильный, справляется с задачей быстрой перевозки большого количества людей.
Но есть и хорошая новость: в нашем случае ресурсы ограниченной мощности сталкиваются с вариативностью, с которой мы способны кое-что сделать. В этой книге много говорится о координационных усилиях и организационных расходах на работу по созданию ценности. Если у нас есть дизайнер пользовательского интерфейса с ограниченной мощностью, то мы можем поручать ей только работу, создающую ценность, минимизируя количество нецелевых и бесполезных действий.
Например, в 2003 году у меня была команда тестировщиков с ограниченной мощностью. Чтобы максимально ее использовать, я начал поиск других, резервных ресурсов и нашел их в лице бизнес-аналитиков и менеджеров проекта. Тестировщики были освобождены от бюрократической деятельности, например заполнения табеля учета рабочего времени. От них не требовалось и планирование будущих проектов. Мы дали аналитикам возможность разрабатывать планы тестирования следующих итераций и проектов, в то время как тестировщики занимались исключительно тестированием текущих заданий.
Еще лучше (хотя тогда это не пришло мне в голову) – разработать профиль риска для требований, которые должны быть протестированы только профессиональной командой тестировщиков. Требования, не соответствующие установленным критериям, могут быть протестированы сотрудниками других функциональных отраслей, которые выступают в данном случае в качестве тестировщиков-новичков. Это могут быть, например, бизнес-аналитики. Такой метод «раздвоения», использующий профиль риска, служит хорошим способом оптимизировать использование бутылочного горлышка, продолжая контролировать риски проекта.
Долгосрочным решением могут стать инвестиции в автоматизацию тестов. Ключевое слово в этом предложении – «инвестиции». Если вы говорите о них, то обычно имеете в виду расширение бутылочного горлышка. Привлечение дополнительных ресурсов – не единственный метод расширения мощности. Полезная и естественная стратегия для этого – автоматизация. Сообщество agile-программистов за последнее десятилетие многое сделало для развития автоматизации тестирования. Обычно стоит смотреть на автоматизацию как на стратегию расширения. Однако у автоматизации есть и замечательный дополнительный эффект: она снижает вариативность, поскольку повторяющиеся задания и действия воспроизводятся с цифровой точностью. Итак, автоматизация снижает вариативность процесса и может помочь оптимизировать использование мощности следующего бутылочного горлышка.
Еще один способ добиться максимального использования нашего дизайнера пользовательского интерфейса – обеспечить ей постоянный прогресс в текущей деятельности. Если дизайнер сообщает, что по каким-то причинам ее работа заблокирована, то менеджер проекта и, при необходимости, вся команда должны дружно взяться за проблему и решить ее. Таким образом, для эффективного использования бутылочных горлышек с ограниченной мощностью необходимы высокие способности организации к определению и решению проблем.
Если текущую работу блокируют сразу несколько проблем, то те из них, которые угрожают ресурсу ограниченной мощности (в нашем случае – дизайнеру пользовательского интерфейса), должны получить наивысший приоритет. Для эффективного, производительного разрешения проблем, таким образом, необходимо знать, где находится ресурс ограниченной мощности, и при необходимости давать ему приоритет.
Прозрачность канбан-системы помогает определить местонахождение ресурсов ограниченной мощности (бутылочных горлышек) и влияние проблем, препятствующих нормальному рабочему потоку в этой точке системы. Если все участники проекта будут понимать системный характер проблем в бутылочном горлышке, то вся команда с готовностью перейдет к решению проблемы. Высшее руководство и внешние заинтересованные лица, имеющие серьезные причины надеяться, что релиз выйдет вовремя, тоже охотнее выделят свое время, осознав его ценность и то влияние, которое окажет быстрое разрешение проблемы.
Развитие способности организации прозрачно отслеживать прогресс и готовить отчеты по проектам с использованием канбан-системы жизненно важно для повышения производительности. Прозрачность дает понять, каковы бутылочные горлышки и препятствия, а следовательно, ведет к оптимальному использованию доступной мощности для создания ценности благодаря общекомандной концентрации на поддержании потока.
Еще один метод, часто применяемый для обеспечения максимальной загрузки ресурса ограниченной мощности, состоит в том, чтобы убедиться: ресурс никогда не простаивает. Если вдруг ресурс ограниченной мощности оставляют без работы из-за проблемы, неожиданно возникшей выше по цепочке – например, аналитик запросов заболел, – это непозволительная трата времени и средств. Или, предположим, внезапно ограничение снимается. Либо большая часть требований отзывается заказчиком, решившим внести стратегические изменения. Пока команда ждет разработки новых требований, дизайнер пользовательского интерфейса простаивает. Что если действия выше по цепочке по своей природе крайне вариативны? Это обычная ситуация при выявлении требований и разработке. Таким образом, темпы поступления заданий оказываются неравномерными. Причин, по которым ресурс ограниченной мощности может простаивать из-за временного недостатка работы, много. Вариативность темпов поступления новых заданий в очередь (в нашем примере – к дизайнеру пользовательского интерфейса) можно нейтрализовать посредством буфера. Буферизация увеличивает общее число заведенных в системе заданий на работу. С точки зрения бережливого управления добавление буфера заданий приводит к потерям времени, поскольку увеличивает период выполнения. Однако преимущества в пропускной способности, которые обеспечивает равномерный поток работы, проходящий через ресурс ограниченной мощности, обычно ценнее. Вы сделаете больше работы, несмотря на немного удлинившееся время выполнения и слега увеличившееся число заданий в работе.
Использование буферов для защиты от простоя ресурса – бутылочного горлышка – часто называют защитой бутылочного горлышка, или просто защитой. Прежде чем задумываться о расширении бутылочного горлышка, нужно попытаться максимально его использовать и установить защиту для реализации его полного потенциала.
Наш пример в области управления движением – трасса SR-520, чья пропускная способность составляет менее 20 % от потенциальной, – достаточно заурядный для интеллектуальной деятельности, например анализа требований и разработки ПО. Часто благодаря максимальному использованию бутылочного горлышка можно добиться более чем четырехкратного увеличения пропускной способности.
В примере с Microsoft из главы 4 благодаря более правильному использованию и защите бутылочного горлышка результаты улучшились в два с половиной раза. Это устранило вариативность системы. Причем не было потрачено никаких денег, например на расширение бутылочного горлышка.
Подчинение ограничению
Как только вы решили, как использовать и защищать ресурс ограниченной мощности, может понадобиться подчинить остальные элементы этим ограничениям, чтобы система работала максимально эффективно.
Давайте вернемся к нашим фантазиям о транспортной системе будущего. Теперь мы решили не строить новый мост через озеро Вашингтон, а снабдить все машины, едущие в час пик по SR-520, новой системой управления скоростью, которая регулирует трафик на одиннадцатикилометровом участке шоссе при помощи радара и беспроводной связи. Эта новая система будет работать своего рода круиз-контролем и заменит управление педалями газа и тормоза. Стимул к установке новой системы на частные автомобили – налоговые льготы. Как только система появится на достаточном количестве автомобилей, она начнет действовать, так что машинам, не оснащенным ею, придется либо искать альтернативный маршрут, либо не ездить в час пик. Результатом станет более равномерный поток движения и возросшее использование мощности бутылочного горлышка. Предполагаю, что такая система при достаточной эффективности сможет вернуть узкому месту около 50 % утраченной мощности. Иными словами, она повысит пропускную способность шоссе SR-520 в пиковое время в два с половиной раза.
Итак, что мы сделали в этом примере? Подчинили право водителей самостоятельно определять и контролировать скорость передвижения более высокой общей цели – ускорению времени поездки благодаря повышению пропускной способности при движении через мост. В этом вся суть синхронизации: чтобы улучшить загрузку бутылочного горлышка, надо изменить что-то еще.
Читать бесплатно другие книги:
