Kitabı oxu: «Масштабированный скрам. Как организовать гибкую разработку в крупной компании»

Name: Масштабированный скрам. Как организовать гибкую разработку в крупной компании
ISBN: 9785961483963

Бас Водде, Крэг Ларман

Şrift:

Переводчик Ирина Евстигнеева

Редактор Алексей Воронин, эксперт в трансформациях крупных организаций, сертифицированный тренер по LeSS

Редактор Любовь Любавина

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

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

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

Художественное оформление и макет Ю. Буга

Корректоры Е. Аксёнова, Т. Редькина

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

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

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

Authorized translation from the English language edition, entitled Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum, 1st edition by Craig Larman; Bas Vodde, published by Pearson Education, Inc., publishing as Addison-Wesley professional.

* * *

Нашим клиентам,
моему другу и соавтору Басу

Предисловие

Мы благодарим вас за то, что вы решили прочитать эту книгу! Мы постарались сделать ее полезной. Дополнительные материалы и рекомендации можно найти на сайтах www.craiglarman.com. и www.odd-e.com. Пожалуйста, свяжитесь с нами, если у вас возникнут вопросы.

Условные обозначения в тексте

Момент, который нужно подчеркнуть, или не очень существенный новый термин. Важная идея или важный новый термин. [Bob67] – ссылка на библиографию.

Об авторах

Крэг Ларман – научный директор в международной консалтинговой и аутсорсинговой компании Valtech, имеющей подразделения в Европе, Азии и Северной Америке. Как консультант и коуч в области менеджмента и разработки работает с крупными и офшорными продуктовыми группами, помогая им с внедрением гибких и бережливых методологий разработки преимущественно с акцентом на встраиваемых системах. Руководил переходом на гибкую разработку (на основе скрама) в Valtech India; был автором и ведущим коучем в проекте по внедрению бережливой разработки ПО в компании Xerox. На протяжении многих лет в качестве консультанта и коуча помогал с крупномасштабным внедрением гибкой разработки и скрама в компаниях Nokia, Siemens, NSN и многих других. Родился в Канаде, с 1978 г. периодически живет в Индии. Автор книг «Гибкая и итеративная разработка: руководство для менеджера» (Agile and Iterative Development: A Manager's Guide and Applying UML) и «Применение UML 2.0 и шаблонов проектирования»¹ – самых продаваемых в мире книг по гибкой и итеративной разработке и объектно-ориентированному проектированию и дизайну (OOA/D). Также вместе с Басом Водде написал книгу «Практики масштабирования бережливой и гибкой разработки: Масштабированный скрам для больших, распределенных и офшорных продуктовых групп» (Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum).

В юности мечтал стать странствующим уличным музыкантом, но ему не хватило таланта, поэтому он получил степень бакалавра, а затем магистра компьютерных наук в ведущем канадском Университете имени Саймона Фрейзера в Ванкувере. В 1970-х гг. занимался разработкой систем на языках APL и 4GL, а в начале 1980-х заинтересовался искусственным интеллектом (вследствие недостатка собственного).

Бас Водде – независимый консультант и коуч по разработке продуктов и использованию масштабированного скрама. В течение нескольких лет руководил в Nokia Networks внедрением гибкой разработки и скрама в масштабах всей компании. Входил в руководящую команду очень крупной распределенной командой разработки (работающей в Европе и Китае), осуществлявшей переход на скрам. Работал старшим разработчиком/архитектором в области встраиваемых телекоммуникационных систем, а также менеджером по качеству. Руководил разработкой решений и коучингом в проектах разработки через тестирование (TDD) встраиваемых систем. Вместе с Крэгом Ларманом написал книгу «Практики масштабирования бережливой и гибкой разработки». Родился в Голландии, много лет жил в Китае, сейчас живет в Сингапуре.

Благодарности

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

Мы также хотим поблагодарить наших рецензентов и помощников: Питера Альфвина, Алана Атласа, Габриэль Бенефилд, Бьярте Богснес, Майка Бриа, Ларри Кая, Майка Кона, Пита Демера, Эстер Дерби, Ютту Экштейн, Кенджи Хиранабе, Клинтона Кита, Куроива-сан, Диану Ларсен, Тимо Леппянена, Эрика Линдли, Мэри Поппендик, Тома Поппендика, Кена Швабера, Маартена Смитса, Джеффа Сазерленда, Дэйва Томаса и Вилле Валтонена.

Нынешних и бывших членов команды (и рецензентов) компании Flexible, в том числе Кати Вилки, Петри Хаапио, Лассе Коскела, Пола Наги, Йоонаса Рейндерса, Габора Гунихо, Сами Лилья и Ари Тикка. И нынешних и бывших членов команды (и рецензентов) компании IPA LT, особенно Теро Пелтола и Люй И.

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

Крэг благодарит Альбертину за поддержку его писательской деятельности.

Мы также благодарим Луизу Адэр, Райну Хробак, Криса Гузиковски, Джули Нахил и Мэри Лу Нор за помощь в издании этой книги.

Глава 1
Введение

Будущее теперь уже не то, что раньше.
Йоги Берра

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

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

У людей разные шкалы того, что значит «большая» продуктовая группа². Для кого-то это 50 человек или даже меньше. Для других – в разы больше. Мы обычно работаем с однопродуктовыми группами, насчитывающими 100–500 человек (которые внедряют принципы скрама, бережливого мышления и гибкой разработки, как правило, в области программно-интенсивных встраиваемых систем). Вот наш подход: «Если собрать всю группу в одной комнате, вы сможете вспомнить имена всех ее членов? Если нет, значит, у вас большая группа». Таково наше определение «большой» продуктовой группы, основанное на фундаментальном критерии: нашей ограниченной памяти.

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

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

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

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

Инструменты мышления и организации

Когда Бас входил в руководящую команду одной большой продуктовой группы, он постоянно во время совещаний спрашивал: «Почему мы делаем это именно так? Что будет, если мы сделаем это иначе?» Через несколько месяцев один из членов команды признался Крэгу: «Первое время эти вопросы выводили меня из себя. Но потом я оценил их значение». Бас не стремился вывести людей из себя; он хотел побудить их к системному мышлению, позволяющему: 1) увидеть более глубокую динамику организационной системы в целом; 2) понять, как система стала такой, какая она есть; и 3) пересмотреть предположения, лежащие в основе существующей организации.

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

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

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

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

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

Инструменты действия

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

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

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

Эксперименты: «Попробуйте… Избегайте…»

Скрам делает упор на эмпирический контроль процесса; в процессах разработки слишком высок уровень сложности и вариабельности, чтобы использовать шаблонные подходы. Поэтому инструменты в обеих наших книгах представлены в виде советов, начинающихся со слов: «Попробуйте…» или «Избегайте…». Это всего лишь эксперименты, и некоторые из них, вероятно, не сработают в ваших конкретных обстоятельствах. Подход в скраме, как и в бережливом мышлении кайдзен, состоит в том, чтобы сначала изучить и понять существующую ситуацию (инспектировать), а затем с помощью экспериментов найти способы, как ее улучшить (адаптировать). Нацеленность на непрерывное экспериментирование – один из столпов бережливого подхода. На самом деле самый неудачный эксперимент – тот, который не был проведен. В Toyota Тайити Оно, ключевой создатель концепции бережливого подхода, шел непосредственно на место и инспектировал все документы с описанием стандартов. Если те были в буквальном или переносном смысле покрыты пылью, давно не менялись, он заставлял людей пересмотреть их. Непрерывная эволюция «стандартов» была его требованием.

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

Ограничения

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

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

● бюджетирование и финансы;

● продажи;

● маркетинг;

● разработка аппаратного обеспечения;

● разработка не-ИТ-продуктов;

● развертывание/поставка;

● сервисная поддержка.

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

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

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

Итак, поговорим об инструментах мышления.

Инструменты мышления
Глава 2
Системное мышление

Я прошел курс скорочтения и прочитал роман «Война и мир» за 20 минут. Он про Россию.
Вуди Аллен

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

Закон Вайнберга – Брукса: от действий менеджеров, основанных на неправильных моделях системы, пострадало больше проектов разработки программных продуктов, чем от всех остальных причин, вместе взятых.
Ловушка причинно-следственной связи: у каждого следствия есть причина… и мы всегда можем точно определить причину и ее следствие [Weinberg92].

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

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

Стоит ли полагаться на здравый смысл?
«Здравый смысл говорит нам…» – эту фразу часто можно услышать не только в повседневной жизни, но и на встречах скрам-команд. Но что такое здравый смысл? Эйнштейн дал ему такое определение: «Здравый смысл – это сумма предубеждений, приобретенных человеком к 18 годам».
Тайити Оно, отец производственной системы Toyota, писал: «Ошибочные представления легко превращаются в здравый смысл. Тогда споры становятся бесконечными. Каждая сторона пытается переспорить другую, и дело не движется с места. Вот почему [у нас в компании] был период, когда я постоянно говорил людям «выйти за рамки здравого смысла» и начать думать вне их. В рамках здравого смысла некоторые вещи могут казаться нам правильными, но только лишь из-за встроенных в него заблуждений. Кроме того, зачастую мы считаем необходимым руководствоваться здравым смыслом только по одной причине: потому что многолетний опыт показал, что данный образ, хотя и не несет больших преимуществ, не имеет и серьезных недостатков… Все мы – люди, а людей можно сравнить с ходячими наборами заблуждений, которые верят, что привычный способ делать вещи – лучший. И даже если вы не считаете его действительно лучшим, устоявшийся здравый смысл говорит вам: «Мы ничего не можем с этим поделать, так обстоят дела» [Ohno07].
«Здравый смысл» не самый надежный способ понять нелинейные системы, такие как крупномасштабная разработка продуктов.

В 1958 г. в журнале Harvard Business Review была опубликована новаторская статья «Индустриальная динамика: важный прорыв для принимающих решения лиц» Джея Форрестера, профессора Школы менеджмента Слоуна Массачусетского технологического института (МТИ) [Forrester58]. Эта статья положила начало преподаванию системной динамики в Школе менеджмента Слоуна, а вскоре обучение системному мышлению стало неотъемлемой частью бизнес-образования. Системная динамика иногда трактуется как синоним системного мышления, но последнее более общий термин.

В МТИ работали и другие выдающиеся исследователи в области системной динамики, например Питер Сенге⁵.

В соответствии с законом Вайнберга‒Брукса, исследование Форрестера показало, что, когда принимающим решения лицам представляли динамические модели бизнес-систем и предлагали улучшить их производительность, они обычно делали их только хуже [SKRRS94]. Исследование также показало, что большинство людей имеют слабое представление о том, как можно фундаментально улучшить системную динамику, и обычно применяют ошибочный «здравый смысл» и «быстрые решения», которые не приводят к устойчивым системным улучшениям.

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

Таким образом, основные причины неспособности понять большую систему и грамотно ею руководить включают следующие факторы (но не ограничиваются ими):

■ недостаток знаний о системной динамике, петлях обратной связи, поведении нелинейных систем и непредвиденных воздействиях в системах рабочей среды;

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

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

Короче говоря, все дело в неспособности мыслить системно⁶.

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

В качестве краткого описания системного мышления нам нравятся следующие 11 «законов», описанных в книге Питера Сенге «Пятая дисциплина»:

1. Сегодняшние проблемы вызваны вчерашними «решениями».

2. Сила воздействия на систему равняется силе ее противодействия.

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

4. Легкий путь обычно ведет назад.

5. Лечение может быть хуже болезни.

6. Тише едешь, дальше будешь.

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

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

9. Можно погнаться за двумя зайцами и поймать обоих – пусть не одновременно.

10. Разделив слона пополам, вы не получите двух маленьких слоников.

11. Не нужно искать виноватых.

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

■ Видеть системную динамику:

○ организация, занимающаяся разработкой, – это система, образованная людьми и правилами, с неявными петлями обратной связи и непреднамеренными воздействиями;

○ мы можем научиться видеть эту динамику и, следовательно, улучшать систему с помощью диаграмм причинно-следственных циклов (causal loop diagrams), создаваемых на групповых встречах.

■ Видеть ментальные модели:

○ одна из причин неоптимальных решений – ложные предположения и ошибочные выводы;

○ ментальные модели обнаруживаются с помощью диаграмм причинно-следственных циклов и метода «Пяти почему».

■ Выявлять корневые причины:

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

○ выявить корневые причины помогают диаграммы причинно-следственных циклов, метод «Пять почему» и диаграммы Исикавы.

■ Видеть локальную оптимизацию:

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

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

Учимся видеть системную динамику

Статическая сложность против динамической сложности

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

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

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

Диаграмма потоков охватывает материальные, финансовые и информационные потоки, метрики (переменные, имеющие количественные значения, такие как финансовые средства или количество дефектов), последствия решений и правил, а также причинно-следственные связи. Популярное упрощение – диаграмма причинно-следственных циклов, которая фокусируется на действующих в системе причинно-следственных отношениях и петлях обратной связи [Sterman00]. Существует несколько вариантов нотаций таких диаграмм; во всех них присутствуют метрики (количественные переменные), причинно-следственные связи и задержки (отложенные эффекты). Вайнберг [Weinberg92] называет это диаграммой влияний.

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

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

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

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

Базовые проблемы и простые удобные инструменты

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

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

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

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

«Le mieux est l'ennemi du bien» («Лучшее – враг хорошего»).

Удобство. Существует множество изощренных инструментов мышления и действия, которые так любят теоретики, но которые почему-то никак не приживаются на практике. Вместе с тем практики скрама или экстремального программирования (XP), будучи раз внедренными, становятся очень «липкими». Почему? Во-первых, они быстро приносят реальную отдачу: у них привлекательное соотношение затрат и выгод и их внедрение быстро окупается. Во-вторых, эти практики не требуют мучительных усилий; большинство людей, которые их используют, говорит, что применяет их с интересом и даже с удовольствием (и, разумеется, с пользой). Люди есть люди: они предпочитают делать то, что им нравится.

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

Диаграммы причинно-следственных циклов

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

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

Попробуйте… чертить диаграммы причинно-следственных циклов на доске вместе с коллегами

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

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

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

Нотации и примеры

Диаграммы причинно-следственных циклов содержат много элементов; вот список наиболее типичных и полезных, которые будут рассмотрены дальше в сценарии:

● переменные;

● причинно-следственные связи;

● обратные эффекты;

● ограничения;

● цели;

● реакции;

● «быстрые решения»;

● эффекты взаимодействия;

● сильные эффекты;

● отложенные эффекты;

● петли положительной обратной связи.

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

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

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

Скорость разработки

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

Природа некоторых причинно-следственных связей не всегда очевидна. Но людям свойственно делать поспешные выводы, что рост числа разработчиков ведет к ускорению разработки. Однако увеличение команды, особенно на поздних стадиях разработки, способно, наоборот, уменьшить скорость (подпункт «Закона Брукса» [Brooks95]). Кроме того, большое число плохих программистов может существенно замедлить работу, и часто бывает, что их удаление из группы хорошо сказывается на общей скорости.

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

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

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

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

Цель, подкрепленная вознаграждением, побуждает людей не только действовать, но и создавать видимость действий и достижений посредством дисфункции измерения, которая порождается предложенной системой вознаграждения. И дисфункция измерения может быть прямо пропорциональна воспринимаемой ценности вознаграждения, потому что люди мотивированы получить вознаграждение, а не улучшить систему [Austin96]. Давайте посмотрим, как вознаграждение может привести к снижению производительности системы. Системная динамика может выглядеть так:

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

Словом, нет никаких гарантий того, что введение вознаграждения обусловливает увеличение скорости разработки – или даже влияет на нее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

Учимся видеть ментальные модели

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

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

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

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

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

Ответы записывайте на доске рядом с соответствующими элементами модели, например:

Пример: динамика «быстрее – значит медленнее»

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

История Microsoft Word и секретного инструментария разработчика – классический пример динамики краткосрочного «улучшения» с последующим долгосрочным ухудшением. Речь идет о первом релизе Microsoft Word для Windows [Spolsky04]. Программа была выпущена на несколько лет позже, чем ожидалось. Почему? Потому что менеджеры старались соблюсти первоначально составленный график и давили на разработчиков, чтобы уложиться в срок.

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

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

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

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

Более глубокий анализ системной динамики, который показывает, по какой причине разработка замедлилась в долгосрочной перспективе и почему первая версия Word для Windows была выпущена на несколько лет позже ожидаемого срока, представлен на рис. 2.3.

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

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

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

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

Учимся видеть корневые причины

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

Попробуйте… выявлять корневые причины с помощью причинно-следственного моделирования, метода «Пять почему» и диаграмм Исикавы

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

1. Когда люди видят проблему, они останавливаются…

2. Анализируют ее, чтобы найти корневые причины…

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

Следующие простые инструменты помогают обсудить проблему и выявить корневые причины:

■ метод «Пять почему» (рассматривается в главе о бережливом подходе);

■ диаграммы Исикавы («Рыбья кость»).

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

Выявление корневых причин с помощью диаграмм Исикавы

Метод «Пять почему» относительно неструктурирован; его можно комбинировать с диаграммами Исикавы (диаграммами «Рыбья кость») [Ishikawa86], чтобы организовать и связать причины, лежащие в основе проблемы, например такой, как неэффективность скрам-мастеров. Шаг первый – провести мозговой штурм по причинам проблемы; мы рекомендуем брейнрайтинг, когда каждый участник записывает свои идеи по одной на листочке бумаги и кладет эти листочки на общий стол. Шаг второй – кластеризация по сходству; нужно сгруппировать причины в семейства связанных причин и дать название каждой группе (рис. 2.5). Шаг третий – нарисовать скелет диаграммы Исикавы, где в качестве «костей» используются названия групп. Шаг четвертый – применить метод «Пять почему» к каждой группе или к заслуживающим внимания подэлементам каждой группы, чтобы выявить корневые причины. Все ответы нужно заносить в диаграмму, как показано на рис. 2.6.

После анализа корневых причин: проведите корректирующие эксперименты

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

Учимся видеть (и слышать) локальную оптимизацию

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

Попробуйте… увидеть (и услышать) случаи локальной оптимизации; это бич больших продуктовых групп.

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

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

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

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

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

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

При масштабном внедрении скрама или принципов гибкой разработки большинство возникающих вопросов типа «Да, но?..» касаются именно локальной оптимизации, например: «Да, но… как насчет управленческой отчетности?» или, более обобщенно, «Да, но… как насчет <этого конкретного случая>?». В результате правила и практики меняются таким образом, чтобы удовлетворить требования отчетности или служить любой другой второстепенной цели, вместо того чтобы обеспечивать глобальную оптимизацию – улучшать общую способность системы быстро создавать ценность. Иногда можно встретить локальную оптимизацию ради редких или чрезвычайных случаев. Например, группа, отвечающая за централизованный выбор программного инструмента для всей компании, фокусируется на самых сложных и редких случаях его использования и на основе этого сценария выбирает инструмент, который подходит именно для таких случаев. В результате достигается субоптимизация для 5 % случаев – за счет простоты использования и скорости в 95 % случаев.

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

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

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

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

Заключение

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

Глава 3
Бережливый подход

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

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

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

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

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

Следите за эстафетной палочкой, а не за бегунами.

Бережливый подход: общая картина

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

○ В 2008 г. Toyota стала самым крупным автопроизводителем в мире, обогнав GM по объемам продаж автомобилей.

○ Бренды Toyota, Lexus и Scion стабильно удерживают лидирующие места в рейтингах качества J. D. Power и др.

○ Высокая прибыльность. В 2006 г. прибыль Toyota составила $13,7 млрд, в то время как GM и Ford сообщили о потерях.

○ Рыночная капитализация концерна в мае 2007 г. более чем в полтора раза превысила капитализацию GM, Ford и Daimler-Chrysler, вместе взятых.

○ Сочетание инновационности и социальной и экологической ответственности. Например, разработка гибридной технологии и автомобилей Prius.

○ Скорость разработки продуктов в два раза превышает этот показатель у некоторых конкурентов.

Короче, здесь есть чему подражать. Одна из глав книги «Экстремальная Toyota» [OST08] посвящена сравнению устойчиво высоких показателей компании с другими компаниями в отрасли. Одна оговорка: мы вовсе не хотим сказать, что система Toyota и бережливый подход – единственная модель для изучения и копирования. Toyota далека от совершенства, и в гибких подходах и других системах есть много полезного, чего нет в бережливом подходе. Тем не менее это проверенная временем, эффективная система от стабильно прибыльной и успешной компании. И, как показывает наш опыт, очень полезно понимать ее принципы, когда речь идет о крупномасштабной разработке продуктов.

Столпы бережливого подхода – это не инструменты и не методы сокращения потерь

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

Избегайте… заблуждений о бережливом подходе.

В чем суть и сила бережливого подхода Toyota?

«Когда я впервые познакомился с производственной системой Toyota (TPS)¹², я был загипнотизирован ее эффективностью [потоком единичных изделий, канбаном и другими инструментами бережливого подхода]. Но опытные менеджеры Toyota не переставали твердить мне, что эти инструменты и практики – отнюдь не основное и что главная движущая сила, стоящая за TPS, – приверженность руководства компании тому, чтобы интенсивно инвестировать в своих людей и продвигать культуру непрерывного улучшения (выделено нами. – Авт.). Я кивал головой, делая вид, будто понимаю, о чем они говорят, и продолжал изучать, как рассчитать количество канбанов и как настроить производственные ячейки для организации потока в режиме «по одному заказу». Но посвятив изучению этой системы почти 20 лет и увидев безуспешные попытки многих других компаний внедрить бережливый подход, я в конце концов в полной мере осознал, о чем говорили мне менеджеры Toyota» [Liker04].

Эксперты Toyota Вакамацу и Кондо выражают это кратко:

«Суть [системы Toyota] в том, что каждому сотруднику предоставляется возможность самостоятельно, собственными способами выявлять проблемы, находить их решения и вносить улучшения» [Hino06].

Инструменты управления – это не столпы бережливого подхода

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

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

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

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

«…Только исчерпав все прочие возможные объяснения успеха Toyota – такие как заниженный курс иены, дисциплинированная рабочая сила, японская культура, превосходная автоматизация, – американские автопроизводители в конце концов были вынуждены признать, что подлинный источник преимуществ Toyota кроется в ее способности в полной мере задействовать интеллектуальный потенциал "обычных" сотрудников» [Hamel06].

Следовательно, шесть сигм бережливого подхода¹³ рассматриваются в Toyota как необходимый инструментарий, но не как подлинные столпы бережливой системы. Как объясняет бывший управляющий заводом Toyota и директор по персоналу:

«Шесть сигм бережливого подхода – это совокупность инструментов и обучения, направленных на снижение себестоимости в рамках конкретных проектов… Подход Toyota… гораздо более глубокий и всеобъемлющий. Его отправной точкой является философия дао Toyota: уважение к людям и непрерывное улучшение. Главное в том, чтобы взращивать лучших людей, которые стремятся непрерывно улучшать процессы. При этом ответственность лежит не на специалистах с "черными поясами", а на менеджерах всех уровней, которые приводят в движение эту систему и выступают наставниками и коучами» [LH08].

Устранение потерь – это не суть бережливого подхода

Книга «Бережливое производство» Джеймса Вумека [WJ96] пользуется заслуженной популярностью, представляя некоторые идеи системы Toyota в доступной для широкой аудитории форме. Мы рекомендуем эту книгу, но с оговоркой: помните, что это всего лишь выборочный взгляд на систему Toyota. К тому же автор опирается на исследования 1980-х и начало 1990-х гг., которые фокусировались на производственной системе Toyota и предшествовали публикации «Дао Toyota 2001» – внутреннего программного документа компании, в котором подчеркивается приоритет более глубоких аспектов. Поскольку подзаголовок книги гласит: «Как избавиться от потерь и добиться процветания вашей компании», – неудивительно, что те, кто прочитал только эту книгу, часто ассоциируют бережливый подход исключительно с устранением потерь.

Хотя устранение потерь, безусловно, полезное дело, оно не является сутью бережливого подхода; в инсайдерском манифесте «Дао Toyota 2001» оно упоминается лишь как одна из составляющих системы, причем не первой значимости. Еще один минус книги «Бережливое производство» в том, что некоторые приоритетные принципы – такие как «пойди и посмотри» (генти генбуцу), которым в Toyota придается особое значение, – рассматриваются в занимательной форме на основе конкретных историй, из-за чего легко упустить их важную роль в бережливом подходе Toyota. Поэтому мы советуем вам не ограничиваться «Бережливым производством» и прочитать и другие книги из списка рекомендуемой литературы, приведенного в конце главы.

Два столпа бережливого подхода

Что же тогда является столпами бережливого подхода? Вот что говорит об этом президент Toyota Гари Конвис:

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

А по словам генерального директора Toyota Кацуаки Ватанабэ:

«Два главных столпа дао Toyota – непрерывное улучшение и уважение к людям. Уважение обязательно в работе с людьми. Под людьми мы подразумеваем сотрудников, партнеров-поставщиков и клиентов… Мы не имеем в виду только конечных потребителей; человек на следующем участке конвейера тоже является вашим клиентом. Этот принцип способствует командной работе. Это означает, что вы анализируете все, что делаете, также с точки зрения того, насколько хорошо вы обслуживаете вашего клиента, не доставляете ли ему проблем. Такое отношение вкупе с придирчивым взглядом на все помогает вам выявлять проблемы и в итоге ведет к кайдзену – непрерывному улучшению. Основа дао Toyota – быть постоянно недовольным существующим положением дел, все время задавать вопрос "почему/зачем мы это делаем?" (выделено нами. – Авт.)».
Попробуйте… поразмышлять о двух столпах бережливого подхода: уважении к людям и непрерывном улучшении.

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

Предыстория

Термин «бережливый» (англ. lean) был впервые использован исследователями из Массачусетского технологического института в книге «Машина, которая изменила мир» [WJR90], чтобы противопоставить производственную систему Toyota системе массового производства. В бережливом производстве радикально сокращаются размеры партий или рабочих пакетов, находящихся в процессе производства, а вместо попыток конкурировать за счет экономии на масштабе ставка делается на быструю адаптацию, избегание накопления запасов и работу очень небольшими партиями – то есть на те же самые принципы, на которых построены гибкие методы разработки, такие как скрам. Термин «бережливый подход» прижился и в самой компании и, в частности, был использован в ее внутреннем документе «Дао Toyota 2001».

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

В своей замечательной книге «Бережливое производство программного обеспечения» [Poppendieck03, Poppendieck06] Мэри Поппендик (внедрившая бережливый подход в компании 3М) и Том Поппендик подробно остановились на взаимодополняющих качествах и сходствах бережливого подхода с принципами гибкой разработки ПО. Создатели методологии скрама Джефф Сазерленд и Кен Швабер также изучали опыт Toyota и ее бережливую систему.

Довольно детально бережливый подход описан в книгах «Дао Toyota», «Система разработки продукции в Toyota», «Проникнуть в мышление Toyota», «Экстремальная Toyota» и «Бережливая разработка продуктов и процессов». Все они основаны на длительном изучении опыта Toyota. Книга «Дао Toyota» Лайкера [Liker04] используется в самой компании для обучения персонала наряду с внутренним манифестом «Дао Toyota 2001». В нашем описании бережливого подхода в этой главе мы опирались на все эти книги.

Дом бережливого подхода

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

1. Цель (крыша);

2. Фундамент;

3. Первый столп – уважение к людям;

4. Второй столп – непрерывное улучшение;

5. 14 принципов;

6. Бережливая разработка.

Цель бережливого подхода: создавать ценность быстро и устойчиво

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

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

Создатель производственной системы Toyota Тайити Оно так изложил эту цель:

«Все, что мы делаем, – это смотрим на промежуток времени с момента получения заказа от клиента до момента получения денег. И ищем способы сократить этот интервал за счет устранения не добавляющих ценности потерь»¹⁶ [Ohno88].

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

Toyota (и ее подразделения Lexus и Scion) не только производит автомобили, но и успешно и эффективно разрабатывает новые продукты, применяя принципы бережливого подхода в области разработки. Как Toyota достигает вышеуказанной «глобальной цели» в двух основных процессах: разработке новых продуктов и производстве?

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

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

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

Фундамент бережливого подхода: менеджеры-учителя с бережливым мышлением

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

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

■ учатся «видеть целое» [Poppendieck03];

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

■ учатся образу мышления кайдзен (непрерывное совершенствование);

■ узнают ценность основного принципа Toyota, известного как «пойди и посмотри», или гемба.

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

Мы также узнали, что менеджеры высшего звена поднялись по карьерной лестнице, имея за плечами многолетний практический опыт применения бережливого подхода и наставничества. Когда Эйдзи Тоёда был президентом, он постоянно твердил своей управленческой команде: «Я хочу, чтобы вы активно учили своих людей мыслить самостоятельно» [Hino06]. Обратите внимание, что речь идет не просто о том, чтобы дать людям такую возможность. Речь идет о культуре управления, в которой менеджеры выступают в роли учителей, развивающих у своих подопечных навыки правильного мышления. Менеджеры Toyota не только сами превосходно владеют навыками бережливого мышления, непрерывного совершенствования, анализа причинно-следственных связей, оценки вариативности и системного мышления, но и обучают этому других.

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

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

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

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

Менеджеры-учителя претворяют в жизнь внутренний девиз Toyota: «Правильное мышление, хорошие продукты». Как компания достигает этого «правильного мышления», которое лежит в основе ее успеха? Через культуру наставничества. От менеджеров ожидается, что они должны быть экспертами-практиками в своей области (как говорится, «мой босс может сделать мою работу лучше меня»), понимать и применять принципы бережливого подхода, а также целенаправленно уделять время обучению и коучингу своих людей. Как мы узнали в ходе наших бесед, в Toyota при оценке эффективности работы менеджера учитывают то, сколько времени он тратит на наставничество. Словом, менеджеры в Toyota в меньшей степени начальники и в большей – учителя, которые учат своих сотрудников принципам бережливого подхода и менталитету кайдзен. Именно так распространяется ДНК Toyota [LH08].

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

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

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

Столп первый: уважение к людям

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

11-й принцип гибкой разработки и один из элементов скрама – это самоорганизующиеся и самоуправляемые команды, которые поддерживают эту колонну «дома бережливого подхода». Более подробно мы рассмотрим тему уважениям к людям в главах «Команды» и «Организация».

Столп второй: непрерывное улучшение

Непрерывное улучшение основано на нескольких принципах:

■ «пойди и посмотри»;

■ кайдзен;

■ стремление к совершенству;

■ фокус на потоке (14 принципов).

Пойди и посмотри (своими глазами)

Идите к источнику [где делается реальная работа по созданию ценности – гемба] и соберите факты, которые позволят вам максимально быстро принять правильное решение, достичь консенсуса и выполнить задачу [Toyota01].
Попробуйте… создать культуру непрерывного улучшения с помощью принципа «пойди и посмотри», кайдзен, стремления к совершенству и фокуса на потоке.

Принцип «пойди и посмотри» не встретишь во многих управленческих культурах. Но во внутреннем манифесте «Дао Toyota 2001» этот принцип обозначен как основной фактор успеха в деле непрерывного улучшения. О нем постоянно говорят менеджеры Toyota; он занимает важное место в корпоративной культуре и традициях [LH08], а также во внутренней программе обучения дао Toyota. Его подчеркивают все японские аналитики, изучающие бережливый подход (например, [OST08]). Несмотря на это, в производных описаниях якобы «бережливого» подхода этот принцип обычно упускается из виду, поэтому многие, к сожалению, не осознают его критически важной роли.

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

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

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

В одном интервью главный инженер Toyota процитировал следующие слова Тайити Оно:

«Смотрите не только глазами, но и ногами… Люди, которые смотрят только на цифры, худшие из всех» [Hayashi08].

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

Например, на рис. 3.3 показан «офис» Крэга в Valtech India, Бангалор: маленький рабочий стол в комнате, где сидит группа разработки. Крэг работает бок о бок с разработчиками, когда они пишут код, участвует в парном программировании, присутствует на встречах по планированию и ретроспективах спринтов. Благодаря такой тесной вовлеченности в процесс он хорошо видит и понимает, что эффективно, а что нет и как это можно улучшить.

Кайдзен

Совершенствуйте ради совершенствования, бесконечно.

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

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

1. Выбрать техники, которые вы хотите попробовать с вашей командой/группой разработки, и практиковать их до тех пор, пока вы их как следует не изучите и не освоите.

2. Начать экспериментировать с этими техниками, пока вы не найдете способ их улучшить.

3. Вернуться к пункту 1 и повторить весь цикл снова (и повторять его бесконечно).

Шаг 1 – выбрать техники, которые вы хотите попробовать с вашей командой / группой разработки, и практиковать их до тех пор, пока вы их как следует не изучите и не освоите. Идея с в том, что сначала группа должна найти некие полезные (будем надеяться) базовые практики и хорошо ими овладеть. Начинающая команда, внедряющая скрам, обязательно должна использовать помощь хорошего коуча, а также строго следовать всем правилам, например выработать и соблюдать рабочие соглашения о стандартах кодирования и «критериях готовности»¹⁸. Как показывает наш опыт, чтобы овладеть методом разработки через тестирование (TDD), людям необходимо много практики, коучинга и хорошего обучения. Первый шаг кайдзена подразумевает, что в ходе трудной фазы обучения вы должны сохранять терпение и упорство и не отказываться слишком быстро от новых методов. Прежде чем двигаться дальше, людям сначала нужно сформировать надежный фундамент. Или, если пользоваться терминологией Эдварда Деминга, нужно научиться различать вариативность общего и особого характера.

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

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

Попробуйте… распространять лучшие практики, а не навязывать централизованные процессы.
«Стараться привести всех к единым стандартам – значит упускать возможности для улучшений. При этом не берется в расчет то, что ситуация постоянно меняется. Вместо этого нужно дать людям гибкость, свободу проявлять творческий подход в процессе работы… Мы не разрабатываем стандарты в штаб-квартире и не спускаем их на все заводы. Жесткие стандарты убивают кайдзен… Все лучшие практики распространяются через йокотен… Мы даем возможность людям на заводах самостоятельно решать возникающие проблемы и устранять слабые места. Никто не диктует им из штаб-квартиры, что вы должны сделать "А, Б и В", потому что это полностью противоречит подходу к решению проблем, принятому в Toyota» [LH08].

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

Шаги 2 и 3 – небольшие, инкрементальные, непрерывные улучшения во всем. Кайдзен подразумевает, что все сотрудники, включая менеджеров, в непрерывном, текущем режиме ищут способы улучшить существующие практики – обычно посредством небольших экспериментов, хотя иногда бывает необходим масштабный системный кайдзен. Фактически ни одна практика, процесс или политика не являются неприкосновенными – нужно «бросать вызов всему», как говорил президент Toyota Гари Конвис. Культура кайдзен – это не крупномасштабные формальные проекты по улучшению процессов, которые разрабатываются и управляются внешними экспертами, а постоянные самостоятельные усилия каждой команды.

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

В книге «Кайдзен» Масааки Имаи пишет:

«Суть кайдзена проста и понятна: кайдзен означает улучшение. Непрерывное улучшение, которое затрагивает каждого, включая всех менеджеров и рабочих. Философия кайдзен предполагает, что наш образ жизни во всех сферах – рабочей, социальной и личной – заслуживает постоянного улучшения» [Imai86].

В практическом смысле кайдзен отражает цикл улучшения качества PDCA (от англ. «Plan-Do-Check-Act» – планирование‒действие‒проверка‒корректировка) Уолтера Шухарта, также известный как цикл Деминга [Deming67]. На самом деле многие люди в Toyota знают о PDCA и иногда называют практику кайдзен бесконечным PDCA [LH08].

Сюхари

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

Ретроспектива спринта

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

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

Метод «Пять почему»

Метод «Пять почему» – простой и популярный инструмент, используемый и в кайдзене. Он помогает развить навыки анализа проблем и выявления их первопричин. Вы берете одну проблему или дефект и задаете вопрос «Почему?» не меньше пяти раз²⁰. Например:

Проблема: программисты не проводят рефакторинг (переработку) кода, чтобы сделать его более простым и удобным в работе.

1. Почему? Потому что от нас требуют увеличить скорость разработки.

2. Почему от нас требуют увеличить скорость разработки? Потому что у нас медленный прогресс.

3. Почему у нас медленный прогресс? Потому что код слишком сложный, с ним трудно работать.

4. И так далее.

На один вопрос может быть несколько разных или связанных между собой ответов; их можно визуализировать с помощью ветвящегося «дерева ответов» (рис. 3.5) или более структурированной диаграммы Исикавы, известной как «Рыбья кость».

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

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

Ценность и потери

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

Ценность – это все свойства продукта, за которые готов платить клиент²¹. Другими словами, это то, что является ценным в глазах внешнего клиента²². Представьте, что клиент наблюдает за работой вашей команды. В какие моменты он будет готов достать из кармана кошелек и заплатить вам деньги за то, что вы делаете? Это и есть моменты создания ценности.

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

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

Один из видов анализа в бережливом подходе – определить все моменты создания ценности и моменты потерь на всем промежутке «от идеи до прибыли»²³. Затем суммировать все время, которое тратится на создание ценности, и рассчитать:

ценностный коэффициент = общее время создания ценности / общее время создания продукта

Мы проводили такой расчет во многих группах разработки и ни разу не встречали организацию с ценностным коэффициентом выше 7 %. Другими словами, 93 % (и больше) времени в процессе разработки – это потери²⁴.

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

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

Попробуйте… улучшать систему путем устранения потерь.

Например, распространенным видом потерь в разработке ПО являются потери от перепроизводства – создание функционала, который на самом деле не нужен клиенту. Одно исследование показало, что в среднем 45 % функций в программных продуктах никогда не используются клиентами [Johnson02]. Нет смысла пытаться повысить эффективность программистов на 2 %, если те теряют массу времени на создание груды неиспользуемой функциональности.

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

■ требований, плана, уточнений;

■ утверждения;

■ когда другая команда завершит свою часть работы?

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

Попробуйте… научиться видеть и устранять не добавляющие ценности действия, такие как звенья передачи, перепроизводство и задержки.

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

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

Итак, в бережливом подходе разделяют два типа потерь:

1. Временно необходимые потери – те, что будут устранены в будущем, например, при тестировании в конце короткого цикла.

2. Чистые потери – те, что можно и нужно устранить прямо сейчас.

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

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

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

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

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

Стремление к совершенству

Это третий элемент парадигмы непрерывного улучшения в бережливом подходе.

В ходе нашего посещения Toyota мы пригласили поужинать с нами в Нагое бывшего инженера компании, теперь – пенсионера. После нескольких чашечек саке мы спросили у него: «Чего не хватает вам после увольнения? По чему вы скучаете больше всего?» «По возможности поговорить с людьми о совершенстве», – ответил он.

Когда нас приглашают в организации, которые раздумывают над внедрением гибкого или бережливого фреймворка, кто-нибудь обязательно высказывается против и приводит следующий типичный аргумент: «Мы создаем продукты, зарабатываем неплохую прибыль, наши процессы проверены и устоялись. Зачем нам что-то менять?» Не думаем, что в Toyota можно услышать что-то подобное. Да, компания еще далека от совершенства, и мы не предлагаем слепо копировать все, что она делает. Но ее культура построена на менталитете кайдзен – высоко ставить планку ожиданий для себя, для своих людей и команд, а также партнеров в отношении мастерства, качества, скорости, сокращения потерь, видения и постоянно ее повышать, бросая вызов статус-кво.

Это очень мощно!

Бесконечный процесс

В 2001 г. Toyota подготовила внутренний манифест «Дао Toyota» с описанием своих принципов бережливого подхода. Но когда ее президент Акио Тоёда услышал название, он предложил переименовать документ в «Дао Toyota 2001». Почему? Чтобы подчеркнуть, что процесс в Toyota не имеет конца (что задушило бы кайдзен), а является непрерывным процессом изменений и улучшений.

Принципы кайдзен и йокотен (горизонтальное распространение знаний) предполагают отсутствие финализированного или регламентированного «правильного» процесса, который разрабатывается центральной группой и спускается сверху для обязательного применения на местах. Да, в кайдзене есть рабочие соглашения, которые люди должны знать и соблюдать, но они передаются и развиваются через систему горизонтального распространения знаний. Вот почему бережливый подход так трудно внедрить в организациях с традиционным менталитетом, «централизованно разработать (или купить) финализированный процесс, разослать его по всей организации и требовать его неукоснительного соблюдения». Позвольте нам еще раз процитировать слова генерального директора Toyota: «Основа дао Toyota – быть постоянно недовольным существующим положением дел, все время задавать вопрос "почему/зачем мы это делаем?"». Ценности бережливого и гибкого подходов – и, разумеется, скрама – основаны на идее эмпирического процесса: на понимании того, что невозможно создать фиксированный или финализированный процесс, книгу готовых рецептов, которым можно было бы следовать с учетом реальности динамически меняющихся систем и цели непрерывного улучшения. Вместо этого скрам предполагает упорную и неустанную работу в духе кайдзен – инспектировать текущие процессы в конце каждого двухнедельного спринта и планировать эксперименты по их улучшению на следующий двухнедельный спринт. В Toyota и в скраме этот цикл повторяется бесконечно.

14 принципов

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

Как отмечает Фудзио Тё, председатель Toyota:

«Многие хорошие американские компании уважительно относятся к людям, применяют кайдзен и другие инструменты [Toyota]. Но важно то, чтобы все эти элементы практиковались как система – изо дня в день, очень последовательно» [Liker04].
Попробуйте… применять 14 принципов бережливого подхода, такие как развитие лучших людей, «остановись и исправь», выравнивание и вытягивание.

Эта более обширная система частично охватывается 14 принципами, описанными в книге «Дао Toyota», которая основана на десятилетиях непосредственного наблюдения и бесед с людьми в Toyota. Мы кратко резюмировали эти принципы в таблице 3.1 и дальше рассмотрим некоторые из них более подробно.

Поток

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

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

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

Вытягивающие системы

Вытягивание против выталкивания. Возьмем процесс производства ноутбуков. В чистой вытягивающей системе²⁶ ноутбуки производятся только при поступлении заказов от клиентов; ни один ноутбук не производится загодя и не хранится на складе. Любая работа выполняется лишь в ответ на «вытягивающий» сигнал от клиента, благодаря чему достигается идеальная цель – нулевые запасы и нулевые НЗР²⁷. В этом суть системы вытягивания: вы получаете «сигнал» от клиента и выполняете работу; в остальное время отдыхаете или совершенствуете продукт/систему. Примеры вытягивающих систем – издание книг способом «печать по требованию», приготовление блюд в ресторане.

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

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

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

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

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

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

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

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

Как вытягивающие системы применимы к разработке ПО? Давайте сравним, например, вытягивающее и выталкивающее планирование:

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

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

Остановись и исправь

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

Например, Toyota известна своей практикой «останови конвейер», когда любой рабочий, обнаружив проблему, может «дернуть стоп-кран» и остановить работу всей сборочной линии. Это первый шаг в системе реагирования, нацеленной на встроенное качество. Еще одна практика: Toyota старается использовать дружественные человеку производственные устройства, которые сами обнаруживают неисправности, автоматически останавливаются и предупреждают людей о проблеме. Эта идея восходит еще к основателю компании Сакиси Тоёда, заработавшему первоначальный капитал благодаря изобретению ткацкого станка, который автоматически обнаруживал неполадку и останавливался [Hino06]. Эта практика бережливого подхода называется дзидока²⁸.

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

Простое визуальное управление

Toyota делает упор на простые и БОЛЬШИЕ визуальные инструменты, сообщающие о проблемах, коммуникации и координации вытягивающей системы. Это большие информационные доски на стенах, яркие заметные карточки с цветовой кодировкой и другие визуальные средства, которые люди могут перемещать, изменять и т. д. Ключевые требования – возможность видеть с дальнего расстояния, физические элементы (например, карточки), цвета и простота. Конечно, это полная противоположность тому, с чем мы имеем дело при разработке ПО с ее отображением множества мелких и детальных элементов информации на небольших компьютерных экранах; но экран с пятном красного цвета, сигнализирующим о сломанной сборке, – вполне в духе визуального менеджмента.

Попробуйте… использовать средства визуального управления.

Такие информационные радиаторы для визуального управления применимы в продуктовой разработке для отображения задач, статуса сборки и т. п.; впервые они получили широкое распространение в гибком методе XP в виде практики Больших наглядных схем (Big Visible Chart / BVC) [JAH00].

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

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

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

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

Вместе с канбаном изъятия в пекарню одновременно отправляется канбан заказа (creation kanban) на выпечку еще одного пирога. Таким образом, магазин «вытягивает» по одному пирогу, вместо того чтобы заказывать сразу много пирогов и «выталкивать» их покупателям.

Разумеется, разработка ПО – это не производственный процесс наподобие выпечки пирогов, и при параллельной разработке с использованием кросс-функциональных команд и практически отсутствием передачи партий от процесса к процессу такие вытягивающие сигналы, как канбаны изъятия и заказа, не нужны. Тем не менее термины «канбан-карточки» и «канбан-доски» в среде гибкой разработки прижились, хотя и приобрели несколько другое значение [Poppendieck03, Hirinabe08]. На канбан-карточках указываются задачи или требования, которые должны быть реализованы в ходе спринта. Эти карточки размещаются на канбан-доске – большой доске задач на стене (рис. 3.7). Эта практика визуального управления также изначально родилась в экстремальном программировании [Beck99], а терминология бережливого подхода была наложена на нее уже позже.

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

Бережливая разработка продуктов

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

Люди в Toyota славятся своим мастерством в двух ключевых процессах: 1) производстве и 2) разработке новых продуктов. Исследователи из Мичиганского университета несколько лет изучали эффективность разработки продуктов в Toyota и североамериканских компаниях [LM06]. И что же они обнаружили?

Попробуйте… превзойти конкурентов в обучении.

Например, на создание пресс-формы³⁰ – от идеи до запуска в производство – у инженеров Toyota уходило в среднем пять месяцев, а у их североамериканских конкурентов – 12. И это при сохранении самого низкого соотношения НИОКР к продажам среди всех крупнейших автомобильных компаний в мире. Очень эффективный процесс разработки, согласитесь.

Как они это делают? В чем секрет бережливой разработки продуктов? Ответ:

в способности превосходить конкурентов в обучении³¹.

Например, когда Toyota разработала гибридный автомобиль Prius, что она создала?

■ Конструкцию автомобиля (и встроенное программное обеспечение).

■ Знания или информацию – о клиентах, экспериментах, альтернативах и т. д.

Бережливая разработка фокусируется на создании более полезных знаний и на более эффективном обучении, чем конкуренты. А также на более эффективном использовании этих знаний и их сохранении. (Другими словами, вы должны учиться лучше своих конкурентов и не разбазаривать плоды своих усилий, забывая то, чему научились.) На рис. 3.8 и 3.9 проиллюстрированы некоторые практики бережливой разработки; часть из них подробнее рассматривается дальше.

Попробуйте… использовать инженеров-практиков с большим опытом работы (в вашей компании).

Экономически эффективное обучение

Не все новые знания и сведения одинаково ценны; в идеале, нужно стремиться получать самую полезную информацию самым дешевым способом [Reinertsen97]. Это не так просто, потому что в любом исследовательском процессе вы иногда открываете что-то новое, а иногда – нет.

Попробуйте… увеличить ценность информации и снизить ее стоимость.

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

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

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

■ Фокусируйтесь на раннем тестировании и обратной связи. Задержка информации имеет реальную стоимость, что частично объясняет, почему тестирование только в конце длинного последовательного цикла (движимое заблуждением, будто такая локальная оптимизация уменьшает затраты на тестирование) – почти всегда очень плохой подход. Согласитесь, после 18 месяцев разработки крайне затратно обнаружить в ходе стресс-тестирования производительности, что ключевое архитектурное решение оказалось ненадежным. В бережливом подходе (и в скраме) используются короткие циклы с ранней обратной связью, что вместе с акцентом на первоочередной реализации и тестировании наименее предсказуемых элементов значительно снижает стоимость задержки информации³².

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

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

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

■ Фокусируйтесь на наставничестве, осуществляемом экспертами, и распространении знаний – чтобы сократить издержки на «изобретение велосипеда».

Каденция

Работа в регулярном темпе является важным принципом бережливого подхода как в производстве, так и в разработке [Ward06]. Это стабильное, ритмичное «сердцебиение» в бережливом производстве называется временем такта³³, а в бережливой разработке – каденциями. В скраме аналогом каденции является практика регулярных двух- или четырехнедельных циклов разработки (с регулярной поставкой результатов и регулярными встречами). Каденция очень мощный принцип, поэтому эту тему стоит рассмотреть более подробно.

Попробуйте… использовать регулярный ритм (тайм-боксы) в организации разработки.

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

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

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

Каденция и тайм-боксы

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

■ Тайм-боксы способствуют каденции.

■ В небольшой группе, разрабатывающей небольшие продукты с минимальными требованиями (например, многие веб-приложения), двух- или четырехнедельный тайм-бокс будет восприниматься как шаг назад: «Вы хотите, чтобы мы поставляли работающую систему раз в четыре недели? Да мы делаем это еженедельно!» Но возьмем группу из 300 человек, которая привыкла работать с крупными требованиями, реализация которых занимает по 18 месяцев, и выпускать продукт – встраиваемую систему с площадками в Сан-Паулу, Оксфорде и Варшаве – раз в три года. Для такой группы предложение «перейти к непрерывной реализации микротребований с непрерывной интеграцией и тестированием системы, чтобы продукт был всегда готов к поставке» – небо и земля по сравнению с привычным режимом работы. В этом контексте новый режим «поставлять работающую систему ровно каждые четыре недели» представляет собой привлекательное и достижимое улучшение и вводит в систему каденцию, которой ей так не хватало.

■ Исследовательская или разработческая деятельность часто имеет расплывчатые или слабо ограниченные рамки. Когда команда знает, что ей нужно поставить работающую функциональность через две недели к 15 марта, это задает четкие рамки, ограничивает объемы работы и усиливает фокус. По словам одной компании – разработчика игр, внедрение скрама помогло ей «вогнать» своих разработчиков игрового арта в рамки тайм-боксов, что принесло немедленные и значительные выгоды [Keith08]. Таким образом:

○ тайм-боксы (строго ограниченные по времени циклы) не дают расползаться объемам работ, ограничивают шлифовку и усиливают фокус, что является одной из ценностей скрама.

■ Тайм-боксы помогают бороться с аналитическим параличом.

■ Представьте, что вы студент, которому нужно подготовить доклад к понедельнику. Когда вы начнете? Большинство скажут: «Ближе к понедельнику». Это называется студенческим синдромом [Goldratt97], и тайм-боксы являются эффективным противовесом им.

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

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

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

■ Люди, кажется, больше чувствительны к вариативности во времени, чем в объеме работ, – «Вы задержали поставку» вызывает более негативную реакцию, чем «Вы сделали меньше, чем я ожидал». Тайм-боксы позволяют избежать такой ситуации, когда разработчики теряют доверие заинтересованных сторон, в очередной раз говоря: «Нам нужна еще неделя, чтобы все доделать».

Многократное переиспользование информации

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

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

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

Командные комнаты и визуальное управление

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

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

Ведущий инженер-предприниматель с бизнес-контролем над продуктом

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

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

Параллельное проектирование на базе альтернатив

Вам доводилось встречать такой подход к разработке?

1. Выбрать один вариант решения или дизайна (один пользовательский интерфейс, одну архитектуру и т. д.).

2. Разработать его.

3. Осуществить поставку.

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

Параллельное проектирование на базе альтернатив (Set-Based Concurrent Engineering/SBCE) – это совершенно другой подход, который используется в Toyota. Например, вместо того чтобы проектировать один вариант системы охлаждения силами одной команды, несколько команд параллельно изучают ряд альтернативных вариантов (и то же самое делается для других компонентов). По мере исследования вариантов некоторые из них отбрасываются, некоторые комбинируются, в результате чего исходный набор вариантов постепенно уменьшается, пока не остается один наиболее перспективный. Таким образом, Toyota превосходит конкурентов в обучении путем увеличения числа альтернатив и комбинаций.

В разработке ПО шагом в этом направлении является исследование как минимум двух альтернатив для нетривиальных элементов архитектуры. Например, несколько лет назад мы работали с группой, которой нужно было создать обработчик для протокола печати JDF. Вместо того чтобы сразу организовать процесс одной командой (и с одной большой доской), мы разбили группу на две подкоманды и использовали две большие доски на противоположных стенах командной комнаты. На каждой доске подкоманды рисовали диаграммы UML³⁶. Примерно каждые 45 минут они подходили к доскам друг друга, обменивались идеями и фиксировали их в диаграммах. В конце дня мы собрались всей группой, посмотрели на обе предполагаемые архитектуры (схематично изображенные на больших досках) и решили, какая из них наиболее перспективна. После этого группа приступила к ее реализации, черпая вдохновение в идеях, набросанных на доске.

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

■ двух-трех вариантов пользовательского интерфейса;

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

Могут ли уроки бережливого производства быть использованы в разработке новых продуктов?

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

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

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

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

Кейс: анализ канбан-системы

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

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

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

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

Несколько лет назад в разработке программного обеспечения стала продвигаться практика под названием «канбан-система» – метод визуального управления с использованием доски и ограниченного количества карточек с запросами на конкретные работы [Anderson07]. Обратите внимание, что это вовсе не то же самое, что концепция визуального управления канбан в вытягивающих системах.

Управление очередями – это не бережливый подход

Вот краткое описание анализируемой практики:

«Лимит для канбан-системы – 20 карточек [на стене], сгруппированных согласно разным этапам процесса, таким как системный анализ, разработка, тестирование, сборка/слияние, развертывание» [Anderson07].

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

Ограничение размера очереди запросов с помощью количества карточек – полезная, но не новая идея. Этот способ используется в экстремальном программировании [BF00], а также обсуждался в контексте бережливой разработки [Poppendieck03] и [Hirinabe07, Hirinabe08].

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

Обратите внимание, что в этом конкретном варианте «канбан-системы» карточки на стене распределяются в соответствии с отдельными этапами разработки – поддерживают модель последовательной разработки с микрокаскадными этапами, такими как системный анализ, разработка, тестирование и т. д. Но что в этом такого?

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

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

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

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

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

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

Вариативность и большие пакеты работ

Канбан-система также позволяет вводить в очередь пакеты работ разного объема:

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

Насколько это хорошая идея?

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

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

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

Кайдзен и обучение

В рассматриваемом нами примере также ставится в плюс, что канбан-система помогла уменьшить «накладные расходы»:

«Канбан-система избавила нас от управленческих накладных расходов, связанных с запуском каждой итерации как мини-проекта».

Но можно ли назвать это улучшением?

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

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

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

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

Каденция в обучении и непрерывном улучшении

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

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

Ресурсный пул против стабильных команд-долгожителей

В рассматриваемой практике предполагается привлечение людей из ресурсного пула по мере необходимости:

«Наш процесс поддержки ПО основан на плавающем доступе к пулу инженерных ресурсов; у нас нет специальных команд поддержки или сопровождения».

Но Toyota делает упор именно на стабильные долгоживущие команды в противовес ресурсному пулу [LM07]. Кроме того, исследования [Katz82] показывают, что такие команды в сфере исследований и разработки демонстрируют более высокую производительность по сравнению с временными группами людей, набранных из ресурсного пула.

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

Выводы

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

Кейс также проиллюстрировал следующие важные моменты:

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

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

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

■ Toyota использует стабильные долгоживущие команды.

Заключение

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

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

Бережливый подход – намного больше, чем просто инструменты вроде канбана, визуального менеджмента или управления очередями, и это не только устранение потерь. Как можно увидеть на примере Toyota, это система организации всей жизнедеятельности компании, которая основана на вкладе бережливо мыслящих менеджеров-учителей и опирается на такие столпы, как уважение к людям и непрерывное улучшение. Ее успешное внедрение может занять годы и требовать широкомасштабного обучения и коучинга. Еще раз процитируем слова Фудзио Те, президента Toyota:

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

1.Ларман К. Применение UML 2.0 и шаблонов проектирования: Введение в объектно-ориентированный анализ, проектирование и итеративную разработку. – Киев: Диалектика, 2019.

2.Методология скрама (и эта книга) применима к разработке продуктов как для внешнего рынка, так и для внутреннего пользования.

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

4.Термин «инструменты мышления» был популяризирован в [Reinertsen97].

5.Сенге написал книгу «Пятая дисциплина», посвященную системному мышлению и обучающимся организациям, которую журнал Harvard Business Review назвал одной из основополагающих книг по менеджменту за последние 75 лет. См. [Senge94].

6.Еще одна причина – вера в возможность большего контроля, чем это возможно на самом деле. Наука о комплексных системах показывает существование фундаментальных ограничений в прогнозировании и управлении полухаотическими социальными системами [Stacey07]. Это довольно большой ящик Пандоры, который мы не будем открывать в этой книге.

7.Среди исключений – макроэкономика, психология, социология и биология.

8.«Базовая» не означает простая или неважная. Например, мотивация и качество – это базовые, но далеко не простые и не пустяковые проблемы.

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

10.Очень традиционные – небережливые – принципы разработки продуктов можно обнаружить, например, у PRTM [McGrath96, McGrath04].

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

12.Производственная система Toyota (TPS) предшествовала дао Toyota [Оно88].

13.Шесть сигм бережливого подхода – набор инструментов, продвигаемый в рамках методологии «Шесть сигм» [George02].

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

15.См. [Poppendieck06].

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

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

18.Критерии готовности в скраме – одно из важнейших рабочих соглашений.

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

20.Пять – не магическое число; это просто означает копать как можно глубже.

21.Имеется в виду идеализированный абстрактный клиент.

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

23.См. метод картирования потока создания ценности в бережливом подходе [RS99].

24.Это соответствует наблюдениям других исследователей; например, Уорд [Ward06] оценивает ценностный коэффициент в разработке продуктов в среднем в 5 %.

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

26.Принцип вытягивания связан с системой «Точно в срок».

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

28.Это слово трудно перевести на другой язык, иногда его значение определяют как «автоматизация с участием человека».

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

30.Шаблон для создания металлических или пластиковых деталей.

31.По определению исследователя в области разработки продуктов д-ра Аллена Уорда.

32.Обратите внимание, что снижение стоимости задержки информации при разработке продукта почти всегда требует сборки и тестирования.

33.Такт – единица ритмического движения.

34.В книге «Человеческий фактор» [DL99] авторы рекомендовали отдельные кабинеты для программистов, но для индивидуальной работы (вне команды). Позже авторы пересмотрели этот совет и теперь рекомендуют использовать «оперативные пункты»: «Я все больше прихожу к мысли, что проект, который не требует "оперативного пункта", вообще не стоит того, чтобы за него браться» [DeMarco08]. Почему? Исследования показывают, что нахождение команды в одной комнате коррелирует с более высокой производительностью [TCKO00].

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

36.UML (унифицированный язык моделирования) – графический язык для составления диаграмм.

37.Разумеется, мы не говорим об абсолютном отсутствии этапности. Обычно существует как минимум два этапа – разработка и развертывание.

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

Pulsuz fraqment bitdi.