Справа налево - Барроуз

Справа налево:
Руководство цифрового лидера по Lean и Agile
Майк Барроуз, 2019
2
Right to Left:
The digital leader’s guide to Lean and Agile
Mike Burrows
Foreword by John Buck
Published by New Generation Publishing in 2019
Copyright© Mike Burrows 2019
First Edition
The author asserts the moral right under the Copyright, Designs and Patents Act 1988 to be
identified as the author of this work.
All Rights reserved. No part of this publication may be reproduced, stored in a retrieval
system or transmitted, in any form or by any means without the prior consent of the author,
nor be otherwise circulated in any form of binding or cover other than that which it is
published and without a similar condition being imposed on the subsequent purchaser.
Paperback:978-1-78955-531-8
Ebook: 978-1-78955-532-5
www.newgeneration-publishing.com
To Martin Burns (1968-2019)
3
Оглавление
Предисловие
Введение
Справа налево
Цифровизация, Lean, Agile и Lean-Agile
Обзор глав
Связанные публикации
Глава 1. Справа налево в материальном мире
Что только что произошло?
Понимание потока ценности, справа налево
Пойди и посмотри
Варианты Lean
Принципы Lean
7 типов потерь
Восьмой тип
Размышления
Глава 2. Справа налево в цифровом пространстве
Какой именно вид Lean-Agile?
Неэффективность потока
Управлять потоком, справа налево
Улучшать поток, справа налево
Винить систему, брать ответственность
Глава 3. Паттерны и фреймворки
Паттерн 1. Итеративная самоорганизация вокруг целей: Scrum
4
Паттерн 2. Явное внимание к потоку: Канбан
Паттерн 3. Люди, процессы и технологии: XP и DevOps
Паттерн 4. Изучение возможностей: User Story Mapping, Jobs to be Done, и BDD
Паттерн 5. Совместное создание с клиентами: Сервис-дизайн мышление
Паттерн 6. Систематическое управление узкими местами: Теория ограничений
Паттерн 7. Бизнес-эксперимент, основанный на гипотезах: Lean Startup
Справа налево: Теория большого объединения для Lean-Agile.
Глава 4. Жизнеспособное масштабирование
Модель Spotify: отряды, кланы, отделы и гильдии...
Масштабируемые Agile фреймворки
Минимальная конфигурация SAFe
Модели вовлеченности и проблемы, связанные с переменами
У организаций тоже есть потребности
Глава 5. Снаружи внутрь
Что происходит?
Обзор сервиса поставки “снаружи-внутрь”

(The outside-in Service Delivery Review, OI-SDR)
Обзор стратегии “снаружи-внутрь”

(The outside-in Strategy Review, OI-SR)
Искренняя организация
Организационный устав NOBL
Wardley Mapping
Снаружи внутрь и снова наружу
Глава 6. Снизу вверх
Лидерство через служение
Переворачивая пирамиду
Переворачивая контроль
Вовлеченное управление
5
Структурированное участие в масштабировании
Содействие гибкости в перевернутой организации
Запуск или оживление трансформации
Приложение А. Объединенные размышления из каждой главы
Приложение Б. Мой вариант…
Материалы
Благодарности
Об авторе
6
Предисловие
Майк Барроуз начинает книгу "Справа налево" с указания на привычку воспринимать
производственные процессы наших компаний как линейную последовательность.
Чаще всего ее изображают в виде схемы, движение по которой происходит слева
направо. Сначала идут вводные, дальше происходят некие преобразования и в
результате появляются выходы в форме продуктов или услуг. Управление такими
процессами обычно происходит с помощью «проталкивающих» методов. Затем Майк
предлагает взглянуть на процесс в обратном направлении (начиная с конца) и
описывает «вытягивающий» процесс, в котором потребности и результаты
определяют продукты и услуги, которые в свою очередь задают входы. На текущий
момент этот Lean подход уже долгое время приносит выгоду компаниям с
материальным производственным процессом за счет намного более эффективного
потока работы цепочек поставок.
Это, на первый взгляд, простое изменение направления с фокусом на потребностях и

результатах имеет важные последствия и для цифровых компаний, принося пользу
сотрудникам этих компаний, процессам разработки и поставки продуктов и сервисов.
Сотрудничество между разными специальностями становится проще, когда они
работают в активно развивающихся кросс-функциональных командах. Этот подход,
основанный на стремлении к достижению цели, также упрощает взаимодействие
(«интеграцию») разных и, возможно, конфликтующих управленческих подходов. Майк
замечательно демонстрирует это с помощью историй. В нескольких главах он
объединяет впечатляющий список методов из области Lean-Agile и не только, включая
Скрам, Канбан, Lean, Agile, SAFe, XP, DevOps, Теорию ограничений, Wardley mapping,
Социократию и Технологию открытого пространства.
Переворот «Справа Налево» предлагает и другие важные изменения. Одним из таких

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

результатах: реализации потребностей настоящих и вдохновляющих лидеров,
потребностей, включающих сниженный уровень стресса, глубокое сотрудничество и
поддержку от своей команды. Когда будете читать эту книгу, будьте готовы, что
некоторые из ваших любимых ментальных фреймворков будут восхитительно
опровергнуты!
Джон Бак, Президент GovernanceAlive LLC Silver Spring, MD, USA
7
Введение
Знали ли вы, что существует два вида Agile? Первый может увлечь в обмен опытом
по созданию выигрышных результатов для клиентов. И второй, с которым можно
добиться лишь скромных улучшений в производительности и создавать продукты,
которые, кажется, никого не радуют. Вместо энтузиазма и вовлеченности первого
типа, второй вызывает разочарование неудачными результатами и раздражением от
того, что непривычные методы работы принесли так мало выгод.
Настолько яркое различие позволяет предположить, что причина заключается в

чем-то фундаментальном. Даже если вы недолго состоите в Agile-сообществе, вы
могли услышать, как люди жалуются на это; возможно, в первую очередь вы замечали
подобные мысли за собой. Многие считают, что вследствие своей популярности Agile
становится жертвой своего же успеха, поскольку заметен неизбежный и, похоже,
необратимый процесс снижения эффективности подхода. Однако я нахожу это
объяснение бесполезным – не потому что оно неправильное или пессимистичное (я
оптимист по натуре), – но потому, что такая позиция не предлагает каких-либо
практических рекомендаций.
Позвольте предложить более полное и полезное объяснение. Тот первый вид Agile –
вызывающий энтузиазм, характеризуется общей сфокусированностью на результатах.
Второй вид – порождающий разочарование, характеризуется сфокусированностью на
выполнении, с методами и практиками и объемом работы, определенными заранее,
часто с минимальным вовлечением людей, которые будут выполнять поставленные
задачи. Совсем не гибко, по большинству осмысленных определений “гибкости”.
Исследование различий между этими двумя видами привело меня к формуле

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

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

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

фундаментальный уход от проектного стиля управления XX века?
2. Какое описание встречается чаще?
9
Вот незадача! Мое сообщение сообществу практиков: каждый раз, когда Agile
начинается слева, он серьезно подрывает свой главный посыл, и возможные будущие
последствия пугают меня. Иногда вред наносится сразу же; подробнее об этом в
главе 4, которая содержит сравнение подходов к применению Agile слева направо и
справа налево.
Так что же означает «Справа налево» с практической точки зрения? На текущем этапе
воспринимайте это как область знаний скорее о результатах (которых существует
несколько видов), чем о решениях; скорее о цели, чем о средствах; скорее о видении,
чем о деталях; скорее о «почему», чем о «что»; скорее о «что», чем о «как» и так
далее. Также эта фраза может означать рассмотрение в первую очередь выходов
процесса, а не его входов, но в каждом случае результаты важнее выходов.
По мере того, как мы погружаемся глубже в эту тему, как с правого, так и с левого
конца процесса, все чаще будет появляться пара терминов:
1. Потребность. Справа, самые значимые результаты – те, которые позволяют с

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

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

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

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

если вы ответили «да» на эти вопросы, вы – тот, кого в этой книге мы называем
цифровым лидером. Если вы уже цифровой лидер, стремитесь им стать или думаете,
1
Мой намеренно провокационный вариант критерия готовности: “Удовлетворена чья-то
потребность” (http://agendashift.com/done).
10
что когда-нибудь в скором времени вам может понадобиться им стать, то эта книга
для вас.
Или, возможно, вы здесь, чтобы в первую очередь удовлетворить интерес к темам

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

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

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

и на наборе более широких свойств, таких как общий опыт использования,
скорость развития продукта и будущий потенциал.
Любой из этих очень реальных сложностей достаточно для того, чтобы серьезно
поставить под сомнение старую, линейную модель. Принимая это, мы пришли к
пониманию, что должно быть нечто изначально запутанное2 в нашей работе.
2
Когда в этой книге появляются слова запутанность или запутанный (комплексный), они
используются в понимании различных школ теории запутанности, из которых наиболее
известным в Lean-Agile сообщества является Cynefin фреймворк
(http://en.wikipedia.org/wiki/Cynefin_framework). Короче говоря, запутанные системы не просто
сложны – как вещи, которые можно разобрать и собрать, но их поведение проявляется и
развивается с течением времени через отношения и взаимодействия. Петли обратной связи,
задержки, исторические данные и так далее делают запутанные системы очень сложными для
прогнозирования. Эти эффекты становятся наглядны, когда в дело вступает человеческий
фактор, например в таких социальных системах как организации и экономика.
11
Обращение к запутанности в таком плане – не хвастовство. Мы не утверждаем,
например, что теперь сможем решать проблемы более трудные, чем те, для которых
применялись традиционные ИТ-проекты. Скорее, это скромное признание, что мы не
держим будущее под полным контролем и вера в обратное означает приближение
неудачи.
Это может выглядеть как плохие новости, но необходимо воспринимать вещи именно
таким образом. Это однозначно серьезная угроза для организаций, все еще
склоняющихся к убеждению, что единственный способ создать цифровой продукт –
это тратить много времени и большие суммы до того как выйти из тени и запустить
готовый продукт на ничего не подозревающий рынок. Но это отличные новости для
организаций, которые готовы понять, что цифровые продукты и услуги представляют
прекрасную возможность взаимодействовать и учиться у внешнего мира. Приняв это,
они настраиваются на стимулирование и внедрение этого обучения на постоянной
основе – начиная не с законченного продукта, но с тестов на его жизнеспособность,
добавляя улучшения и проводя доработки с течением времени, отталкиваясь от
наблюдений за реальным миром.
Этот итеративный, развивающийся, основанный на эксперименте подход хорош не

только для «гаражных стартапов» или техно-гигантов типа Google, Amazon и Netflix.
Например, я имел честь быть свидетелем некоторых значительных изменений,
происходящих в госсекторе Великобритании3. Изменения были заметны даже
гражданам-пользователям цифровых государственных услуг, и это впечатляет. С
огромным уважением к их достижениям я утверждаю, что если государственные
службы смогли сделать это, то любая организация может. И ваша организация тоже!
Но чтобы сделать что-то новое, нужно лидерство. Цифровое лидерство может

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

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

развития, продукт или услуга получает тот тип технической реализации,
который необходим, поддержание технического видения.
Это творческое сотрудничество, и знак того, что оно работает – синергия. Не просто
сумма составляющих частей, а нечто большее, не просто производство вещей,
которые могли быть созданы автономно, но достижение того, о чем мы даже не
задумались бы. В этом смысле это замечательная модель для других партнерских
рабочих взаимоотношений. Этот принцип можно расширить на взаимоотношения с
3
Британская газета The Guardian описывала Государственные цифровые услуги (GDS) как
“революционное изменение взаимодействия 62 миллионов граждан с более чем 700
сервисами” и “открытием примера как крупные комплексные корпорации изобретают себя
заново” см. “Government Digital Service: the best startup in Europe we can't invest in”, Saul Klein,
http://www.theguardian.com/technology/2013/nov/15/government-digital-service-beststartup-europe-i
nvest (theguardian.com, 2013)
12
потребителем, типом сотрудничества настолько жизненно важным, что он специально
упоминается в основополагающем документе agile-движения – Agile-манифесте4.
Другие лидерские функции в таких областях, как проектирование, управление

поставками, процессные и организационные изменения, становятся все более
важными по мере того, как увеличивается размер команд. Они могут использовать
внешних экспертов (или “практиков"); если вы один из них, эта книга и для вас тоже, и
я надеюсь, что вы найдете в ней что-то новое и интересное.
В любом реальном бизнесе будут, конечно, и другие типы лидеров, включая людей в
традиционных лидерских ролях в продажах, маркетинге, управлении персоналом и
управлении финансами. В этой книге меньше говорится о таких типах лидеров, но
если вы находитесь в подобной роли и ваша организация готовится предпринять
что-то в области цифровизации, я надеюсь, что вы тоже найдете эту книгу ценной.
Цифровизация, Lean, Agile и Lean-Agile

Том Лузмор, автор первой стратегии цифровизации правительства Великобритании и
экс-заместитель директора Цифровой службы Правительства Великобритании
(Government Digital Service, GDS), определяет цифровизацию следующим образом:
Цифровизация – применение культуры, процессов, бизнес-моделей и технологий

эры Интернета для соответствия повышенным ожиданиям людей5.
Когда далее по тексту я буду использовать это слово, вы можете быть уверены, что я
подразумеваю именно такое его значение. Понимание того, что цифровизация – это
больше, чем технологии, неочевидно. Но это действительно история про то, чтобы
быть частью динамической социальной системы, которая меняется у нас на глазах.
В этой области могут замечательно помочь Lean и Agile подходы. Мы затронем самые
актуальные концепции в главах 1 и 2, но перед этим поместим их в исторический
контекст.
● Lean обязан своими основополагающими принципами компании по

производству автомобилей Toyota и ее системе менеджмента,
Производственной системе Toyota (Toyota Production System, TPS). Именно из
Lean мы получили термины «точно вовремя», «остановка конвейера» и
«канбан», которые относятся к управлению и улучшению потока6, созданию
4
Agile-манифест или полное название “Agile-манифест разработки программного
обеспечения” доступен на http://agilemanifesto.org. Цитата, которую я подразумевал в данном
контексте: “Сотрудничество с заказчиком важнее согласования условий контракта”.
5
Определение цифровизации, http://definitionofdigital.com
6
Я выделяю поток, потому что это очень важная концепция. Будьте уверены, эта метафора
настолько сильна, что вы можете и должны доверять своему интуитивному пониманию слова.
Если привести пример из природы, на протяжении большой реки вы можете увидеть разные
виды потока: плавный поток (выразительный в своем спокойствии), пенные перекаты
(огромное количество энергии, но большая ее часть теряется)^ водовороты (в которых часть
движения направлена назад) и заводи (в которых сложно заметить хоть какое-то движение).
Для каждого из этих примеров легко найти аналогии в бизнесе. Они могут иметь различные
названия, но наш опыт взаимодействия с ними будет очень схожим.
13
максимальной ценности для потребителя с минимальными задержками,
помехами или доработками.
● Agile ворвался в жизнь с публикацией Манифеста гибкой разработки

программного обеспечения, широко известном сегодня как Agile-манифест.
Это результат работы группы практиков, которые встретились в 2001 году на
горном курорте Сноуберд, штат Юта, США. Люди, утвердившие этот документ,
представляли собой сторонников так называемых «легковесных» методов
разработки программного обеспечения. Манифест сформулирован в виде
набора ценностей и принципов, которые объединили развивающиеся подходы
и объяснили, что отличает их от общепринятого представления.
Комбинация Lean и Agile – «Lean-Agile» не так хорошо определена, но мне близко

именно сочетание этих подходов. В своей второй книге, «Agendashift», я описал
Lean-Agile следующей фразой: «признавать полезность Lean и Agile, как вместе,
так и по отдельности». Это определение сработало достаточно хорошо, подойдет и
теперь. Более формальное определение мы дадим в главе 2.
В главах 3 и 4 мы представим несколько брендированных фреймворков, которые

дополняют или сочетаются с Lean, Agile и Lean-Agile. Их так много, что я не мог
упомянуть все. Если я опустил один из ваших любимых фреймворков, пожалуйста,
поймите, что у меня не было намерений проигнорировать его. Некоторые из
известных фреймворков допускают толкование как справа налево, так и слева
направо. Этот факт указывает на то, что способ их применения и адаптации имеет
большое значение, иногда даже большее, чем выбор фреймворка! Мы вернемся к
этой потенциально провокационной мысли в главе 4.
Обзор глав
Эта книга состоит из шести глав, первые четыре из которых посвящены
исключительно теме «справа налево»:
1. Справа налево в материальном мире: введение в Lean,

стратегическое стремление к потоку.
2. Справа налево в цифровом пространстве: введение в Agile и

Lean-Agile.
3. Паттерны и фреймворки: популярные фреймворки в области Lean,

Agile и Lean-Agile, как они сочетаются и дополняют друг друга..
4. Жизнеспособное масштабирование: фреймворки масштабирования

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

“искренней” организации.
6. Снизу вверх: Лидерство через служение и его связь с сотрудничеством
и адаптивностью в организации поддерживающей, “целеустремленной”,
сфокусированной на потребителе.
Начиная с главы 2 и далее мы будем смотреть на примеры из жизни «Springboard

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

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

некоторых неофициальных определений, которые особенно подходят этой книге.
Каждое из них применимо в контексте цифрового лидерства и большинство из них
также полезны в более широком контексте.
Связанные публикации
Вам не нужно читать какие-либо из моих предыдущих книг, чтобы получить
удовольствие от «Справа Налево». Они написаны для разных аудиторий, даже если
пересекаются по содержанию. Моя первая книга, «Канбан Метод: Улучшение
системы управления», была опубликована в 2014 году и представляла собой первое
осмысление Канбана, основанное на ценностях. Речь в ней идет как о Канбан методе,
так и об инструменте, по которому метод получил свое название. «Agendashift:
Ориентированные на результат изменения и непрерывная трансформация», моя
книга 2018 года, описывает подход «справа налево» для изменений и
15
трансформации. Во время работы над ней я уже думал о «Справа налево», и многие
читатели могут считать самую последнюю книгу наиболее доступной стартовой точкой
для всех трех. Оглядываясь назад, мое путешествие от ценностей через результаты к
«Справа налево» определенно имеет смысл. Но я понятия не имел, что меня ждет,
когда в новогодние каникулы 2013 года сделал первый шаг – опубликовал пост в
блоге, который в итоге изменил мою карьеру!7
Перед тем, как перейти к главе 1, еще пара рекомендаций, которые не хотелось бы
откладывать до конца книги:
● У этой книги есть страница в Интернете: http://agendashift.com/right-to-left.

Если у вас есть желание дать любую обратную связь, это можно сделать там.
На этой странице вы также найдете ссылки на источники, рекомендуемые
материалы (наиболее важные из ссылок, которые даны в конце каждой главы)
и блог.
● Вас ожидает теплый прием в канале #right-to-left в Slack

(http://agendashift.com/slack).
● Если вам нравится то, что вы читаете, вы также можете высказаться в

Твиттере, отметив @asplake (меня), @Right2LeftGuide (эту книгу), или
использовав хэштег #Right2LeftGuide. Это будет очень ценно, спасибо.
А теперь, приятного чтения!
7
Представляя Канбан через его ценности,
http://blog.agendashift.com/2013/01/03/introducing-kanban-through-its-values/
16
Катастрофа! Для завершения домашнего проекта осталось сделать лишь одно
отверстие, но электрическая дрель сломалась. Работа зашла в тупик и ее
невозможно продолжить, пока вы не найдете замену.
Глубокий вдох... Не такая уж и катастрофа. Поиск в телефоне выдает именно ту

дрель, что вам нужна, в ближайшем магазине "Сделай сам". Вы делаете заказ с
немедленным самовывозом, прыгаете в машину, и скоро домашний проект будет
спасен. Здорово!

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

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

производитель за последние недели усовершенствовал свои
производственные системы, чтобы эффективнее собрать эту новую модель.
● Рука об руку с производителем, поставщики отреагировали на новые

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

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

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

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

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

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

Что мы знаем? Для начала, есть результат потока ценности – нужная вам дрель,
которую вы забрали в магазине “Сделай сам”. Результаты, неизвестные магазину
(разве что они спросят вас о причине покупки): ваше последнее просверленное
отверстие – удовлетворенная срочная потребность – и ваш законченный проект, суть
всего этого (Рисунок 2):
Рисунок 2. Окончание процесса, его выход и результаты.
Что еще мы знаем (или хотя бы можем догадаться)? Мы можем обоснованно

предположить, что какая-то система распределения доставила дрель в ваш магазин
(Рисунок 3):
Рисунок 3. Дистрибуция
Ваша дрель была собрана производителем (рис. 4):
18
Рисунок 4. Производитель
Производитель получал детали и сырье от своих поставщиков8 (рис. 5):
Рисунок 5. Поставщики
Производитель, его поставщики, и другие научно-исследовательские центры,

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

т.д., потенциально не просто прямой поток, а целую сеть ценности9. Однако мы
остановимся на этом.
Мы настолько привыкли, особенно в западном мире, видеть карты потоков ценности и

другие карты процессов, нарисованные стрелками слева направо, что легко
пропустить тот факт, что они часто строятся справа налево. Если не учить этому явно,
то специалисты, занимающиеся построением карт потоков ценности, вскоре
самостоятельно обнаружат, что эта тактика почти всегда самая эффективная.
Нетрудно понять, почему: привязка процесса к ключевому моменту создания
ценности и последующее отслеживание его вверх по потоку (upstream) сохраняет
карту сфокусированной на вещах, которые имеют значение. На каждом этапе
процесса необходимо устанавливать только эти три вещи:
1. Операции на этом этапе.
2. Ресурсы, необходимые для успешного осуществления этих операций.
3. Источник появления этих ресурсов – следующие места, где нужно искать.
8
Вы заметите, что некоторые из наших вставок описывают скорее организационные единицы,
нежели деятельность. Небрежно!
Когда вы работаете с такой высокой степенью детализации, иногда лучше выбрать наиболее
очевидные имена для вещей, имена, с которыми люди будут себя идентифицировать. По мере
того, как Вы будете углубляться в детали, важно точно идентифицировать действия, чтобы
карта показывала, что на самом деле делается. Организационные границы всегда можно
провести позже.
9
Этот термин изобрел Клейтон Кристенсен в своей книге о революционных инновациях 1997
года "Дилемма инноватора: когда новые технологии приводят к провалу великих фирм"
Clayton M. Christensen (Harvard Business Review Press, reprint edition 2013).
19
Если бы вы начали слева – с сырья и других основных материалов, вам было бы
гораздо сложнее рисовать карту. Вы обнаружите любое количество действий, которые
можно с ними сделать, и все места, куда их можно направить после, и очень быстро
диапазон возможностей переполнится. Даже если предположить, что вы выбрали
наилучшую точку старта, поиск пути к интересующему вас результату будет
неэффективным.
Наша первая карта потока ценности очень высокоуровневая, и составлена (я легко
это признаю) не на основе исчерпывающих исследований. Для следующей карты мы
собираемся сделать некоторые настоящие исследования «в поле». Для
использования популярной Lean идиомы, целью которой является предостережение
от кабинетного руководства, мы пойдем и посмотрим10.
В частности, давайте посмотрим, как работает опция самовывоза в магазине “Сделай

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

передает вам дрель вместе с квитанцией, которая уже распечатана. Готово!
Майк: Это просто! Что происходит перед этим, чтобы все получилось? Откуда все
взялось?
Кара: Когда вы размещаете заказ, он становится виден на экране вот здесь.
(Когда она указывает на экран, новый заказ, не мой – всплывает ярко-розовым

текстом)
Кара: Тот, кто здесь дежурит, нажимает на заказ, распечатывает квитанцию клиента,
наши документы и этикетку, которая помогает нам быстро найти ваши товары,
когда вы приедете. Затем он собирает ваш заказ из мест хранения – с полок,
из запираемого шкафа (для такого дорогого предмета, как ваша дрель) или со
склада.
(Мы идем в отдел электроинструментов)
10
В кругах Lean вы также можете услышать японский вариант для "пойди и посмотри": genchi
genbutsu. Полуанглицизированные термины, с которыми Вы также можете столкнуться: "идите
в гембу", что означает "идите в настоящее место". Место, о котором идет речь в главе, как
правило, в магазине, и «гемба прогулка», что является Lean указанием "идите в настоящее
место и ходите вокруг, в поисках возможностей для улучшения". См.:
https://en.wikipedia.org/wiki/Gemba
20
Майк: Я вижу, часть инструментов выставлена на витрину, часть в коробках, а
некоторые заперты, как вы описали. Как вы можете быть уверены, что у вас
есть товар, который я заказал?
Кара: IT-система следит за необходимым количеством на складе, но реальная

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

сигнала от последующих этапов. Эти последующие этапы мы называем английским
словом “downstream”, что дословно означает "нисходящий поток", то есть ближе ко
мне, к конечному покупателю:
● Мой заказ уведомляет центральную IT-систему о моем намерении в

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

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

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

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

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

непосредственно перед тем, как они нужны для сборки в конечный продукт, а не
заранее. Ограниченное количество более базовых материалов хранится на каждом
рабочем месте в маленьких контейнерах, пополняемых по мере того, как они близки к
исчерпанию.
Сигнал о том, что рабочая станция нуждается в каком-то виде пополнения, часто
подается в виде карты, известной как канбан11 в Японии, а теперь и на Западе. В
типичной заводской канбан-системе (мы увидим другой вид в главе 3), канбан
посылается вверх по потоку (upstream) с рабочей станции, сталкивающейся с
потенциальным дефицитом; требуемые пополнения ответно поступают вниз по потоку
11
Японское слово kanban не имеет множественного числа и не изменяется, идет ли речь об
одной сигнальной карте или о нескольких.
21
(downstream), прибывая, когда это необходимо. Таким образом можно соединить
несколько рабочих станций по всему заводу-изготовителю.
По всему потоку ценности, вместо больших буферных запасов, длительных

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

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

Production System).
2. Набор инструментов, многие из которых имеют японские названия или

неясные аббревиатуры.
3. Подход, основанный на сокращении расходов, "делать больше с меньшими

затратами".
4. Фреймворк для постоянных улучшений.
К сожалению, несмотря на то, что в каждом из вышеперечисленных пунктов есть доля

правды, ни один из них не является исчерпывающим определением термина "Lean"
(Бережливость). Подводя итог, можно сказать, что каждый из них имеет серьезные
проблемы:
● Определения 1 и 2, сфокусированные на системах и инструментах Toyota,

делают ошибку, путая современный Lean с историей его происхождения.
Несомненно, практики Toyota были лучше относительно обычных для того
12
Технически, под эффективностью использования ресурсов понимается доля времени, в
течение которой ресурс занят, известная также как «утилизация ресурса». Обычно это
выражается в процентах, 100% утилизация описывает ресурс, который всегда занят, никогда
не простаивает.
13
Технически, эффективность потока измеряет долю (в процентах) времени, которое продукт
активно обрабатывается для придания ему дополнительной ценности, по отношению к
общему времени, прошедшему через систему.
Эффективность потока в 100% подразумевает идеально гладкий поток, при этом ценность
добавляется к продукту в течение всего времени его движения через процесс.
22
времени, но они и мир движутся дальше, и наша работа заключается не в том,
чтобы закрепить практики, которым уже десятки лет.
● Определение 3, сосредоточенное на сокращении расходов, ограничивает Lean

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

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

правильно: история Toyota замечательна, ее стоит изучить, и сама компания щедро
содействовала ее изучению. TPS является жизненно важной частью этой истории, так
же как и ее инструменты. Но слепое копирование не работает, Toyota сама описывает
такое поведение как неадекватное! Большинство из нас не работает на
автопроизводителей, а если бы и работало, то к моменту завершения внедрения
наши более умные конкуренты уже давно бы опередили нас. Если кто-то решился
попробовать, он бы не только скопировал инструменты прошлого, но и делал это, не
зная их реальной эффективности в его конкретном контексте. Неверное понимание
приводит к ужасным результатам.
Адекватно ли выражение "больше с меньшими затратами" описывает подъем Toyota

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

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

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

правда в том, что непрерывное улучшение не самоподдерживаемо. Да, в
14
Японский термин, наиболее часто используемый для непрерывного улучшения: кайдзен,
буквально "изменение к лучшему".
23
учебниках улучшение описывается как цикличное15, но это не тот случай, когда
одно улучшение должно неизбежно приводить к другому.
2. К неудовольствию ленивого менеджера, непрерывное улучшение не является

заменой стратегии. Недостаточно просто решить проблемы, нужно решить
правильные проблемы. Для того чтобы правильные проблемы выявлялись и
решались непрерывно, должно быть общее понимание результатов, которые
должны быть достигнуты, и осознание препятствий, которые стоят на пути этих
результатов.
Если в этой книге есть что-то вроде Lean, то что же это такое? Для того, чтобы понять
Lean как в историческом контексте, так и для успешного применения в наше время,
необходимо признать два основных инсайта:
● Инсайт 1: Улучшение потока отвечает взаимным интересам как клиентов, так и

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

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

лежат и препятствия, и возможности.
○ Лидерство – направление и продолжение путешествия, даже когда

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

следующее поколение продолжит путешествие, точное место которого
не может быть известно сегодня.
Toyota была первой, кто усвоил эти инсайты. В дистиллированной форме они
инкапсулированы в два "столпа"16 Точно вовремя (JIT, Just in time) и Уважение к
людям (Respect for people), которые формируют TPS. К сожалению, всеобщее
внимание в первую очередь привлекли не инсайты, а лишь некоторые из
инструментов, которые Toyota разработала на их основе, наиболее заметные в то
время для сторонних наблюдателей.
15
См. https://en.wikipedia.org/wiki/PDCA для знакомства с дедушкой всех циклов
усовершенствования. Зовите меня еретиком, но я уже давно принял решение прекратить
преподавание циклов усовершенствования, предпочитая вместо этого преподавать
обрамление усовершенствований как эксперименты и организацию непрерывной работы,
связанной с усовершенствованием, как две разные концепции. Описание чето-то как цикл не
означает, что оно будет самоподдерживающимся автоматически!
16
Это отсылка к традиционной визуализации принципов TPS (прим. переводчика).
24
В книге This is Lean17 – написанной в 21 веке, достаточно недавно, чтобы не повторять
ошибок прошлого – авторы Niklas Modig и Pär Åhlström описывают Lean просто как
"стратегию эффективности потока". Это, конечно же, намного лучше по
сравнению с описаниями, предлагаемыми в начале этого раздела. Вдохновленный их
описанием, но стремясь сделать его менее зависимым от технического термина, я
предлагаю такое определение:
Lean:
Стратегическое стремление к потоку, целенаправленный процесс

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

организационной сложности:
Lean:
Стремление к потоку как стратегической необходимости, открытое и

управляемое предназначением старание, которое постоянно и целенаправленно
вовлекает людей на каждом уровне организации в процесс обучения
Lean проходит все тесты хорошей стратегии18: она выявляет реальные вызовы,
обеспечивает четкую основу для принятия решений, а создаваемые ею действия, как
правило, усиливают друг друга. Очевидно, это стратегия на долгосрочную
перспективу: Toyota привержена ей уже несколько десятилетий, и её история еще не
закончена.
Для успешной реализации этой стратегии требуется несколько видов лидерства:
● Продуктовое лидерство, разработка и развитие продуктов, которые

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

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

спросом.
● Процессное лидерство, нахождение более эффективных способов

эксплуатации и управления процессом поставки.
● Лидерство в изменениях, стимулирование изменений посредством

спонсорства, экспериментов, содействия, наставничества и координации.
17
This is Lean: Resolving the Efficiency Paradox, Niklas Modig & Pär Åhlström (Rheologica
Publishing, 2014)
18
Good Strategy/Bad Strategy: The difference and why it matters, Richard Rumelt (Profile Books,
2011)
25
● Лидерство в выполнении, устранение структурных препятствий,
обеспечение единства организации сейчас и в будущем.
Все эти виды редко можно найти полностью развитыми и в идеальном балансе в
одном человеке. Поэтому Lean – это очень командный вид спорта, даже на уровне
руководства.
В завершении этой главы, рассмотрим два важных компонента Свода знаний Lean
(Lean body of knowledge): описание процесса улучшения Lean в форме «принципов
Lean» и модель видов препятствий (или "потерь"), с которыми, как правило,
приходится сталкиваться в процессе улучшения Lean.
Принципы Lean
Пять принципов Lean были определены еще в 1991 году в книге «The Machine That
Changed the World» (Womack, Jones, & Roos), которая выдвинула на первый план
термин Бережливое производство19 (Lean production). По мере их представления,
обратите внимание на то, насколько они соответствуют принципу "справа налево":
Принцип 1: Определите ценность

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

отверстие и завершить домашний проект.
Вы не сможете определить ценность, глядя только на процесс производства. Для

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

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

Поощряйте бесперебойную работу на протяжении всего процесса по направлению к
клиенту так, чтобы каждый рабочий элемент проходил без задержек по каждой
19
Право на изобретение терминов Lean и Lean production имеет Джон Крафчик, чья статья
Triumph of the lean production system была опубликована в журнале Sloan Management Review
в 1988 году.
20
“Муда” по-японски, буквально "тщетность" или "бесполезность".
26
операции и между операциями. Если вы еще этого не сделали, то сейчас также самое
время начать измерения производительности системы, устанавливая базовую точку
отсчета, с которой можно будет сравнивать будущую производительность.
Принцип 4: Установите вытягивание

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

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

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

новая работа не повлечет за собой дальнейших задержек со стороны той части
системы, которая уже перегружена
Когда несколько вытягивающих систем соединены вместе, мы видим, что эти сигналы
запроса быстро каскадируются справа налево. Для завершения своей работы
рабочие ячейки, расположенные близко к клиенту – вниз по потоку (downstream) или
справа – запрашивают все необходимые им предметы из ячеек, расположенных вверх
по потоку (upstream), слева от них. Эти ячейки, в свою очередь, запрашивают то, что
им нужно, из следующего этапа вверх по потоку (upstream), и таким образом они
продолжают вверх по процессу, справа налево. Работа сама по себе движется слева
направо, плавно проходя через виды деятельности, которые непрерывно работают в
безопасных и эффективных пределах нагрузки.
21
Остерегайтесь того, что Уильям. Эдвардс Деминг назвал вмешательством, мер с
недостаточным знанием воздействия. См.
http://curiouscat.com/management/deming/tampering
27
Рисунок 7. Система канбан, охватывающая несколько рабочих ячеек.
Описанные в этой главе канбан системы представляют собой важный класс

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

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

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

улучшать поток, справа налево":
● Понять процесс поставки, начиная с правой стороны, где удовлетворяются

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

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

технологиям, не только как преднамеренная тактика, но и в виде укоренившихся
привычек.
7 типов потерь
Семь потерь Lean помогают классифицировать различные препятствия для потока
при его реализации в физическом мире:
● Потеря 1: Транспортировка – перемещение материала из пункта А в пункт В

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

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

Инструменты и материалы не организованы или недоступны, неудобны и даже
небезопасны на рабочем месте.
● Потеря 4: Ожидание – задержка работы из-за других работ (см. Запасы выше)
или из-за неспособности поставок или других необходимых ресурсов прибыть
вовремя.
● Потеря 5: Перепроизводство – производство чего-либо до того, как оно

необходимо. Действие, которое может показаться безобидным, но часто
является коренной причиной избыточных запасов и связанных с ними проблем.
● Потеря 6: Чрезмерная обработка – выполнение деятельности, которая

является излишне сложной, трудоемкой или дорогостоящей, с использованием
оборудования сложнее необходимого.
● Потеря 7: Дефекты – двойное, тройное или четверное проклятье! Усилия

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

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

излишки должны оказаться расточительными.
● Дефекты настолько коварны, что заслуживают "остановки конвейера"23 и

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

взаимосвязи, законе Литтла24. Усредненное по подходящим периодам времени (и с
удивительно малым количеством других математических предостережений):
Время производства = Запасы / пропускная способность
Где:
● Время производства – это время, необходимое для прохождения через

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

через систему за единицу времени.
Как только вы осознаете закон Литтла, явная одержимость запасами в Lean

оказывается л разумной! Если вы можете сократить запасы без неоправданного
влияния на пропускную способность, время производства также должно сократиться.
Если вы можете устранить задержки, вы увидите сокращение запасов или увеличение
пропускной способности (а возможно, и то, и другое).
22
Чтобы отдать необходимое должное: Lean Software Development: An Agile Toolkit, Mary
Poppendieck & Tom Poppendieck (Addison-Wesley Professional, 2003) действительно углубились
в 7 потерь и стали важной вехой в моем собственном Lean-Agile путешествии.
23
«Остановка линии» – ссылка на практику Toyota, которая дает работникам возможность дать
сигнал к остановке процесса, если они заподозрят какую-либо проблему. На производственной
линии это делается посредством физического натяжения шнура «андон».
24
https://en.wikipedia.org/wiki/Little%27s_law
30
Не вошедшие в 7 типов потерь, но важные сами по себе категории:25
● Вариативность – несоответствие, непредсказуемость, неравномерность или

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

полную силу, в результате избыточных запасов, неожиданного спроса, сбоя в
управлении или по какой-либо другой причине.
Во главе со сторонниками Lean Six Sigma26 и великим У. Эдвардсом Демингом27,

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

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

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

устойчиво" не всегда выигрывает гонку!
Ключом к этому является распознавание и использование ценных форм

вариативности одновременно со стремлением устранить остальные. Toyota
представляет собой мощный пример, казалось бы, ошибочного выбора в пользу
создания ряда различных продуктов на одной и той же производственной линии
кажущимися невозможными маленькими партиями. Чтобы справиться с
непредсказуемостью и задержками введенными этой тактикой, они заставили себя
применить новые техники, такие как быстрая переналадка и быстрая смена
25
На японском вариативность и перегрузка звучат как мура и мури. «Неравномерность» – это
более буквальный перевод мура, который иногда используется в Lean литературе; здесь мы
следуем за Демингом и используем "вариативность". Муда, мура и мури часто появляются
вместе, называемые в совокупности «моделью 3М» (не путайте с компанией с таким
названием).
26
https://en.wikipedia.org/wiki/Lean_Six_Sigma
27
https://en.wikipedia.org/wiki/W._Edwards_Deming, и я очень рекомендую его книгу The New
Economics (MIT Press, 2nd Edition, 2000)
31
пресс-форм28. Столкнувшись с очевидным компромиссом между предсказуемостью и
возможностью, они выбрали путь гибкости, достигнув наилучшей из обеих целей.
Восьмой тип
Термин "7 типов потерь", похоже, стал устойчивым, но существует широко
признанный восьмой тип, часто называемый неиспользованной креативностью и
нереализованным человеческим потенциалом. В отличие от первых 7 типов
потерь, это более позднее добавление, в глазах некоторых практиков бережливого
производства, считается довольно неуместным в этом списке.
Независимо от того, принадлежит она другим или нет, она раскрывает некоторые
замыслы, стоящие за Уважением к людям, и говорит о других глубоких инсайтах
Toyota. Выравнивание интересов в погоне за потоком основано не только на
экономике:
● Успех зависит от людей, которые поднимаются и опускаются по потоку

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

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

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

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

будут стараться изо всех сил, если боятся, что это приведет к негативным
последствиям. Команды никогда не достигнут своего полного потенциала, если их
участники ожидают осуждения новых идей. Немногие будут пытаться сделать
что-нибудь сложное, если провал повсеместно рассматривается как нечто, чего стоит
опасаться. Психологическая безопасность – это во многом командный феномен, но
28
https://en.wikipedia.org/wiki/Single-minute_exchange_of_die
29
См. https://en.wikipedia.org/wiki/Psychological_safety и знаковое исследование Google «What
makes a Google team effective»,
https://rework.withgoogle.com/blog/fi-keys-to-a-successful-google-team/. Подсказка:
психологическая безопасность была определена как фактор №1.
32
это тот феномен, в котором лидеры подают сильный пример. Если у вашей команды
нет психологической безопасности, и вы хотите увидеть улучшения, начните с нее.
1. Как вы понимаете те "ключевые моменты создания ценности", которые
происходят "справа", возникая в результате взаимодействия между вашей
организацией и вашими клиентами?
2. Работая справа налево, как вы понимаете потоки ценности вашего бизнеса –

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

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

координируется со своими контрагентами вверх по потоку, чтобы их
потребности были удовлетворены вовремя?
5. Как бы выглядела "стратегия эффективности потока" для вашей

организации? Что бы ее поддерживало?
6. Где и как 7 потерь Lean – транспорт, запасы, движение, ожидание, чрезмерная

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

управляются запасы, пропускная способность и/или время производства?
8. Как в ваших командах взращивается психологическая безопасность?
33
Мы находимся в офисе компании «Springboard DIY», онлайн-ритейлера,
предлагающего товары для дома и ремонта. Алекса, старший разработчик, только что
встретила в коридоре менеджера продукта Роуэна. Алекса видит, что Роуэн
собирается уезжать на внешнюю встречу.
Алекса: Как хорошо, что ты еще не уехал. Мы собирались сделать изменения в

разделе электроинструменты, но есть пара моментов, которые я сначала
хотела уточнить у тебя. Мы можем это обсудить?
Роуэн: Конечно! А что, есть повод для беспокойства? Все данные, которые я
видел после релиза, выглядят отлично – на эти страницы переходит
больше пользователей, они попадают туда быстрее и совершают больше
покупок!
Алекса: Не волнуйся, я тоже это вижу. Я только никак не могу отделаться от мысли,
что здесь есть и другая возможность, которую мы упускаем. Возможно,
имеет смысл разобраться с этим, пока мы не забыли.
Роуэн: Заинтриговала! Сейчас мне надо бежать, давайте встретимся сегодня часа
в два? К этому времени я уже вернусь в офис.

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

внешнее (в особенности, с клиентами);
● Непрерывные поставки: работающий продукт (или работающие продукты и

сервисы), которые уже удовлетворяют чьи-то потребности и продолжают
улучшаться при помощи последовательности небольших, быстрых
инкрементных (добавляющих ценность) улучшений и итеративного
(повторяющегося) совершенствования30. К этому пункту также относится
инфраструктура, позволяющая эффективно достигать подобной скорости
изменений31.
30
См. публикацию “Инкрементно и итеративно”
http://blog.agendashift.com/2018/02/22/incremental-and-iterative/ и страничку в вики “История
итеративно-инкрементной разработки”, http://wiki.c2.com/?HistoryOfIterative
31
Рекомендовано к прочтению "Continuous Delivery: Reliable Software Releases through Build,
Test, and Deployment Automation" от авторов Jez Humble и David Farley.
34
● Адаптивность: не просто гибкость по отношению к приоритетам и планам, но
и возможность изменять дизайн продукта, процесса или организации в
качестве ответной реакции или в преддверии изменяющихся обстоятельств и
новых знаний, в частности, знаний, полученных в процессе поставки.
В окружении разработки одновременно происходят три процесса:
1. Относительно предсказуемая работа по поставке понятных изменений в

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

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

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

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

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

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

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

В Главе 1 мы рассмотрели несколько разных способов понимания Lean. Прежде чем
мы перейдем к Lean-Agile, позвольте мне описать разновидность Agile, которая
должна быть вам уже знакома:
Agile:
Люди сотрудничают для быстрого развития работающего программного

обеспечения, которое уже начинает удовлетворять потребности.
Немного расширим:
Agile:
Люди применяют различные навыки для быстрого развития рабочего ПО, уже
удовлетворяющего потребности, и работают в командах, придающих большое
значение сотрудничеству и адаптации.
Это моя очень сжатая интерпретация Agile манифеста (http://agilemanifesto.org)

"справа" , сформулированная так, чтобы описать "идеальное место" для цифровых
технологий. Если вы хотите узнать, что такое Agile, вам следует начать с манифеста.
Agile – это не определенный процесс, метод или структура; Agile означает принятие
ценностей манифеста – ценностей сотрудничества, работающего программного
обеспечения и адаптивности.
Движение Agile существует потому, что ценности манифеста нашли отклик у многих
людей. Они видят проявления ценностей в содержательных беседах, в возможности
создавать вещи, которые действительно помогают людям, и в возможности постоянно
улучшать рабочую среду к взаимной выгоде разработчиков, клиентов и организации.
Другими словами, они затрагивают некоторые базовые человеческие потребности,
которые удовлетворяет не каждый работодатель.
Чтобы система ценностей была чем-то большим, чем просто выдача желаемого за
действительное, должна существовать четкая взаимосвязь между ценностями,
ожидаемым поведением и предположениями в основе этого поведения. В случае с
Agile эти предположения хорошо документированы – не в последнюю очередь самим
манифестом, и вполне конкретно описывают ожидаемое поведение:
● предположение 1: Прямое, постоянное сотрудничество с клиентами

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

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

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

итераций, кажется, предполагает нечто похожее на поток. Действительно, популярный
жаргонный термин Agile – "поток ценности". Означает ли это, что Agile – это не что
иное, как "стратегическое стремление к потоку", ничем не отличающееся от Lean из
Главы 1? Это спорный вопрос; люди, которых я уважаю, отвечали на него как
положительно, так и отрицательно:
● Да – как может быть иначе?
● Нет – Agile ставит некоторые вещи выше потока (делая лучше или хуже, в
зависимости от вашей точки зрения).
Переопределение Agile в терминах Lean не только оставило бы этот вопрос без

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

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

первое из которых было дано в главе 1, а второе – в начале этого раздела:
Lean:
Стремление к потоку как к стратегической необходимости, бессрочное и

целеустремленное начинание, которое постоянно вовлекает людей на каждом
уровне организации в процесс обучения.
32
См. Закон Галла, http://en.wikipedia.org/wiki/John_Gall_(author)#Gall’s_law, и книгу Джона
Галла Systemantics: How Systems Work and Especially How They Fail (Pocket Books, 1978)
37
Agile:
Часть последователей Agile без труда примут все три этих определения и согласуют
их со своим пониманием Agile. Другие займут вполне оправданную позицию, что Agile
в основном про команды или про программное обеспечение, и отмахнутся от такой
идеи. Однако, если отступить от этой перспективы на уровне команды, возникает еще
больше вопросов:
● Учитывая, что организации живут и содержат сложную среду – конкурентные

ландшафты, социальные системы и т.д., не должны ли все они стремиться
быть Agile в каком-то смысле?
● Возможно ли заставить Agile работать не только на уровне команд

разработчиков, но и в масштабах организации? Другими словами, возможно ли
масштабировать Agile?
В некотором смысле, эта книга посвящена тому, чтобы серьезно подойти к этим
вопросам. Для этого мы начнем с рабочей системы, которая уже удовлетворяет
потребности – цифрового подразделения “Springboard DIY”, и изучим виды моделей,
методов, инструментов и паттернов, которые помогают как внедрить ее, так и
поддерживать ее дальнейшее развитие. Вы можете оценить самостоятельно, что
было приобретено или потеряно на этом пути.
Итак, давайте вернемся к “Springboard DIY” и посмотрим, как выглядит быстрый и
плавный поток. А пока мы смотрим, набросаем карту потока создания ценности.
Естественно, мы начнем справа. Но с чего именно? С точки зрения какого-то из

клиентов Spingboard, нам стоило бы начать с момента совершения онлайн-платежа. К
сожалению, у этого выбора есть две проблемы:
● Клиенты часто посещают интернет-магазин “Springboard DIY” не только для

покупок.
● Персонал Springboard не закрепляется за каждой конкретной покупкой. Это

делает бизнес-процесс неинтересным для наших текущих целей, даже если он
может быть интересен клиентским опытом и технической архитектурой.
Есть еще один важный вид ценности, который цифровые услуги особенно хорошо
улавливают. Огромную пользу бизнесу приносит понимание того, чего хотят клиенты и
как они предпочитают взаимодействовать. Когда процессы поставки или разработки
завершаются явным этапом валидации, предназначенным для обратной связи
предшествующему процессу, мы называем этот процесс валидированным обучением
(термин из Lean Startup, который мы рассмотрим в следующей главе). Результатом
38
валидации является поток инсайтов: когда мы усваиваем новые знания и применяем
их, то получаем очень важный результат – обучение.
Рисунок 8. Валидация
Приверженность Springboard к валидированному обучению объясняет разговор между

Алексой и Роуэном в начале этой главы. Они проводили эксперимент, проверяя на
практике некоторые изменения в разделе электроинструментов на своем сайте.
Используя технику, называемую A/B тестированием, эти изменения не внедрили
немедленно, а выпустили для небольшой части пользователей, затем постепенно
распространяли по мере подтверждения эффекта. Для подобных экспериментов
заранее определяются метрики – индикаторы успеха или неудачи изменений. В
масштабах крупной розничной компании статистическая значимость может быть
достигнута за несколько часов или дней, а изменения становятся постоянными, если
они признаны полезными, или сворачиваются в противном случае.
Поскольку команда Springboard работает подобным образом уже долгое время,

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

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

не прошедшие тестирования. Поэтому специалисты по контролю качества не
проводят почти все время за ручным тестированием или согласованиями; к тому
времени, когда большинство изменений доходит до них, функциональное и
интеграционное тестирование уже не только завершены, но и автоматизированы, так
что регрессионные ошибки будут немедленно обнаружены. Вместо этого они в
основном сотрудничают с разработчиками по задачам на начальных этапах
разработки, занимаются исследовательским тестированием, измеряют
производительность системы, проверяют функции для пользователей с
ограниченными возможностями и так далее – следят за тем, чтобы весь путь онлайн
40
пользователя был последовательным и соответствовал его ожиданиям. Когда у них
нет реальных клиентов, они могут попытаться встать на их место.
Рисунок 11. Разработка
Разработка в Springboard DIY – это междисциплинарная деятельность, включающая в

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

персонализированные рекомендации, что при правильном подходе идет на пользу
клиентам. Однако использовать данные нужно очень осторожно.
Конфиденциальность и информационная безопасность заложены не только в
онлайн-предложения Springboard на техническом уровне, но и в политику,
определяющую как они проектируются, создаются и эксплуатируются. Уважение к
людям распространяется за рамки организации!
41
Рисунок 12. Восходящий поток Upstream
Я использовал понятия "пользователь" и "клиент" как взаимозаменяемые, но важно

помнить, что пользователи продукта не обязательно являются теми, кто за него
платит. Клиенты, спонсоры и другие заинтересованные стороны отвечают за
финансирование, цели, различные организационные политики и ограничения, но
часто они плохо разбираются в том, что действительно нужно пользователям. В
случае с “Springboard DIY”, розничные клиенты тратят деньги через онлайн сайт, а за
сам сайт они платят лишь косвенно. При этом Springboard не питает иллюзий:
возвращаться будут только довольные пользователи. Это, в свою очередь, означает,
что разработчики тесно сотрудничают с исследователями пользователей (часть
продуктовой команды) и UX-специалистами (которые в Springboard считаются
принадлежащими как продуктовому лагерю, так и к технологическому). Короче говоря,
если у разработчиков нет реального клиента под рукой, у них есть подходящий
запасной вариант.
Разработку подпитывает целый ряд активностей, которые настолько переплетены

между собой, что любое их линейное представление было бы весьма обманчивым.
Это и исследования пользователей, и выдача идей, и анализ, прототипирование,
дизайн и так далее – виды деятельности, которые когда-то управлялись отдельно, но
теперь рассматриваются как различные грани процесса с единственной целью:
убедиться, что последующие активности (все, что справа от них) всегда обеспечены
достаточным объемом работы с максимально возможной ценностью. Отсюда такие
названия, как Fuzzy front end33 и Upstream (деятельность выше по потоку
относительно этапа разработки). Оба термина не являются общепринятыми; для
удобства я буду использовать последний, более короткий термин.
Фокус Upstream на ценности в значительной степени объясняет его нелинейную и

многогранную природу. Забегая вперед, скажу, что на заключительном этапе проверки
многое зависит от гипотезы и ее предположений о количестве пользователей, их
потребностях, потенциальных изменениях в их поведении, технических проблемах и
так далее. Многие из этих предположений могут быть проверены задолго до создания
полноценных решений, что помогает организации учиться гораздо быстрее и
максимизировать влияние проделанной работы. И нет лучшего способа проверить
предположения о пользователях, чем пойти и поговорить с людьми, поговорить с
пользователями напрямую, а также с теми, кто с ними регулярно взаимодействует.
Группы клиентов, тестовые лаборатории, полевые исследования и служба поддержки
клиентов – все они вносят свой вклад. Они предоставляют различные возможности
для проверки идей, прототипов и работы на разных стадиях выполнения. Таким
33
http://en.wikipedia.org/wiki/Front_end_innovation
42
образом, в Upstream потенциально могут участвовать люди всех специальностей, и
команда Springboard придерживается такой политики, когда каждый действительно
регулярно получал возможность внести свой вклад.
Springboard научилась думать о Upstream иначе, чем о фазе, разбитой на этапы с

контрольными точками между ними. Теперь они понимают Upstream как управление
портфелем возможностей для получения наибольшей выгоды. Лучшие идеи будут
реализованы быстро, возможно, даже до того, как будут полностью сформированы –
удачный момент заслуживает привлечения дополнительных глаз и рук. Некоторые
идеи требуют более длительного времени для созревания: отношение затрат к
выгодам достаточно хорошо, чтобы несколько раундов прототипирования и
пользовательского тестирования могли избавить команду от зря потраченных
вложений в будущем. Наименее перспективные идеи потомятся какое-то время и
будут отвергнуты. Никто не сожалеет об отклоненном варианте; каждый такой случай
это выход сухим из воды, возможность избежать потери.
Неэффективность потока
Вот простая классификация видов препятствий потоку, обычно встречающихся в
цифровой работе, взамен 7 потерь Lean:
● Препятствия, которые влияют на отдельные рабочие элементы – части

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

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

двух состояний:
● Блокировка – рабочий элемент считается заблокированным, когда в нем

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

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

на людей и системы:
43
● Перегрузка – Мы видели это в первой главе: люди и системы перегружены и
перенапряжены, не в состоянии работать наилучшим образом из-за
превышения спроса над возможностями. Помимо человеческих издержек,
перегрузка оказывает разрушительное воздействие на качество и
предсказуемость, и все еще действует закон Литтла (математику не одолеть,
как ни старайся).
● “Голодание”- так же, как люди не любят, когда их перегружают, они не любят,
когда им отказывают в возможности заниматься осмысленной работой.
“Голодание” обычно возникает ниже бутылочного горлышка34, которое либо
ведет себя непредсказуемо (возможно, перегружено слишком большим
количеством рабочих элементов или задыхается от чего-то чрезмерно
крупного), либо само узкое место подверглось голоданию. “Голодание”
обходится особенно дорого, когда оно происходит в критическом месте.
Прежде чем мы перейдем к последнему набору препятствий, обратите внимание на

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

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

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

двойной, тройной или четверной удар! Сначала усилия тратятся на
производство дефектной работы, затем на обнаружение и устранение
проблемы, и, наконец, на устранение любых последствий. Чем раньше они
будут обнаружены, тем лучше: с одной стороны, “дефекты”, найденные
разработчиком, выполняющим тесты на новом и еще не отгруженном коде,
вообще не считаются дефектами – неудачные тесты лучше рассматривать как
маркеры незавершенных задач, которые еще предстоит доделать. С другой
стороны – дефекты, дошедшие до пользователя, требующие вмешательства,
или даже компенсации за неправильную работу.
34
Технически, "бутылочным горлышком" процесса является деятельность, которая
ограничивает пропускную способность, скорость поставки рабочих элементов. См. также
Теорию ограничений, один из фреймворков, представленных в главе 3.
44
● Ошибочное требование – концепция, зародившаяся в сфере предоставления
услуг в государственном секторе35, ошибочные требования не обязательно
подразумевают дефекты в обычном смысле, когда работа была выполнена не
так, как было указано. Скорее, результат удовлетворяет потребности клиента
настолько неадекватно, что требует полной переделки, и это приводит к
дополнительному требованию. На первый взгляд, ошибочное требование и
неудачные эксперименты могут показаться похожими, но эксперименты
проводятся для эффективного обучения при неопределенности результатов, в
то время как ошибочные требования – в основном потери, которых можно
избежать.
● Нереализованные возможности – экономические потери, возникающие в

результате неправильного выбора объема и последовательности работ.
Например, очень важный рабочий элемент застрял в очереди за менее
ценными задачами (возможно, потому что последние были взяты в работу
одной большой партией). Либо возник перекос между различными видами
работ, источниками работ или классами обслуживания (если не хватает
мастерства в балансировании работ с фиксированной датой, разной срочности
и протяженности, например, планового обслуживания и развития). Ни одна
команда не обладает абсолютной информацией о будущем, но лучшие
команды понимают экономическую основу своей работы в целом, хорошо
чувствуют вероятную стоимость задержки36, связанную с отдельными видами
работ, и поэтому способны принимать правильные решения на местах.
Если рассматривать все препятствия в целом, должно прийти понимание, что поток –
это нечто большее, чем просто обеспечение занятости людей. "Занятость" может
быть даже плохим признаком! Lean-Agile означает 1) управление потоком с учетом его
потребительской ценности и 2) правильные действия в интересах людей в системе,
причем одновременно.
Управлять потоком, справа налево

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

работающих и запущенных совсем недавно?
● Что мы надеемся узнать в ближайшее время, и настроены ли наши системы и

эксперименты на получение необходимой информации?
● Что у нас готово к внедрению? Когда и как это будет развернуто?
35
См. книгу Freedom from Command and Control: A Better Way to Make the Work Work, John
Seddon (Vanguard Publishing Limited, 2003)
36
См. книгу Principles of Product Development Flow: Second Generation Lean Product
Development, Donald G. Reinertsen (Celeritas Pub, 2009)
45
● Что необходимо протестировать? Как, кем, в какой среде и по каким
критериям?
● Что находится в разработке? Кто над чем работает? Что мы делаем, чтобы
избавиться от блокирующих факторов?
● Ясно ли нам, что мы будем делать дальше? (Последний вопрос можно не

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

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

Чтобы даже один рабочий элемент гладко прошел через систему, очень многое
должно работать правильно! Приведенные выше вопросы призваны предупредить
некоторые из наиболее важных причин, по которым что-то может пойти не так:
● Работа завершена, но не получено новых знаний. Либо потому, что ее

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

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

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

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

стоило начинать в первую очередь
● В разработке или на стадии подготовки не хватает ценной работы.
Как лидер должен реагировать в таких ситуациях? Хорошая реакция работает на трех
уровнях:
1. Решение текущей проблемы, ее последствий и непосредственных причин.
46
2. Устранение системных причин – того факта, что система допускает появление
этих проблем.
3. Работа с тем, что недостаток системы не предвидели до того, как эти

проблемы стали видны.
Ответственность лидера возрастает по порядку этих уровней. Команде, способной

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

Вы, несомненно, слышали это выражение: "Не вините человека, вините систему!"
Уильям Эдвардс Деминг взял этот совет на вооружение и откалибровал его:
94% проблем или дефектов в организации вызваны "системой".
Деминг говорил на языке статистики. По его мнению, остающиеся на людей 6% были

"почти незначительными". Иногда он повышал долю ответственности системы до
95%; тогда доля людей становилась "статистически незначительной".
Чтобы сделать этот общий совет более конкретным и умерить автоматическую

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

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

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

разочарования в отделе, которым я когда-то руководил. Если бы автор и
рецензент рассматриваемого кода в каждом случае сотрудничали должным
образом до и во время разработки, анализ кода принес бы мало сюрпризов.
Если бы они работали достаточно тесно (возможно, практикуя парное
программирование, как это делала моя следующая команда), формальный
этап ревью мог бы вообще не понадобиться! Как только мы распознали эту
проблему как ошибку в сотрудничестве, быстро последовали улучшения.
47
2. Несколько лет спустя, временно исполняя обязанности менеджера поставки, я
обнаружил, что работа часто поступала на тестирование без четкого плана
последующих действий. Хуже того, когда тестирование все-таки начиналось,
никто не мог предположить, сколько времени оно займет.
Удивительно эффективное решение – быстрый разговор "трех амигос":
представители бизнеса, разработки и тестирования проводят короткое
обсуждение каждой работы непосредственно перед началом ее разработки.
Мы не только предотвратили досадные задержки в тестировании, но и создали
условия для сотрудничества на протяжении всего процесса.
Подобные изменения можно легко и быстро применить, они не требуют большого

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

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

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

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

разработке продукта?
6. Насколько правее закреплена валидация вашего потока создания ценности

при разработке продукта? Какие формы принимает эта валидация?
7. Какие “upstream” активности обеспечивают процесс разработки продукта

работой с высокой ценностью? Как лучшие идеи попадают в начало очереди?
8. Как вы управляете работой вне (а не внутри) процесса разработки продукта?
48
9. Как вы распознаете, смягчаете и устраняете "неэффективности потока":
блокировку работы; застой работы; перегрузку или недостаток высокоценной
работы у людей, команд или систем; дефекты; ошибочные требования;
нереализованные возможности?
10. Проходя справа налево по нынешнему потоку создания стоимости вашей

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

сотрудничества"? Как такая формулировка может вам помочь?
49
Давайте подведем итоги. Мы описали:
● Lean как стратегическое стремление к потоку, процесс организационного

обучения.
● Agile как сотрудничества людей над быстрой эволюцией работающего

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

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

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

иллюстрируют:
1. Итеративная самоорганизация вокруг целей, и ее пример – Scrum.
2. Явное внимание к потоку, и его пример – Kanban.
3. Люди, процессы и технологии, на примере XP и DevOps.
4. Изучение вариантов, например с помощью User Story Mapping, Jobs to be

Done, и BDD.
5. Совместное создание клиента, представленный Service Design Thinking.
6. Систематическое управление узкими местами, и его пример – Теория

Ограничений.
7. Бизнес-эксперименты, основанные на гипотезах, на примере Lean Startup.
Для удобства я буду называть эти разнообразные своды знаний «фреймворками»,

словом, имеющим несколько значений. Некоторые из них, в особенности Scrum и
Lean Startup, это фреймворки в том смысле, что они обеспечивают минимальную
структуру, в которую можно вводить конкретные практики. Остальные – например,
DevOps и Design Thinking – представляют собой фреймворки в ином смысле,
обеспечивая особый взгляд на организационные проблемы и набор методов, с
помощью которых можно их решить.
50
Описанные здесь фреймворки, вместе с масштабируемыми фреймворками из
следующей главы, формируют одни из наиболее важных и легко узнаваемых
особенностей Lean-Agile ландшафта. Эта глава содержит довольно много деталей, и
тем не менее, она поверхностна. О каждой упомянутой теме уже написаны целые
книги! В момент знакомства с каждым из фреймворков, имейте в виду следующее:
● Если вам кажется, что фреймворк решает ряд проблем, которых у вас просто
нет, это вполне нормально. Будьте благодарны (и бдительны).
● Если вы осознаете, что один из фреймворков стал линзой, через которую вы

видите других, поэкспериментируйте с противоположной точкой зрения и
сделайте акцент на том, как меняется ваше понимание. Многое можно
получить, объединяя модели, воспроизводя одну модель по мотиву другой или
бросая их в Большой Коллайдер Моделей, смотря за тем, что выскочит в ответ
– инновации часто появляются таким образом.
Глава заканчивается кратким обзором, напоминанием о том, как взгляд справа налево
и его неустанный акцент на потребностях и результатах помогает объединить все
рассматриваемые фреймворки.
Паттерн 1. Итеративная самоорганизация вокруг целей: Scrum

Scrum – это простой процессный фреймворк, который отлично подходит для
продуктовой разработки, обеспечивая некоторую базовую структуру, в которую могут
быть внедрены конкретные практики. Я опишу его двумя противоположными
способами, оба из которых полностью совместимы с официальным описанием Scrum,
Scrum Guide™, которое можно прочитать или скачать на www.scrumguides.org.
Во-первых, позвольте мне представить Scrum как “итеративную самоорганизацию

вокруг целей”. Это мое выражение, и оно обобщает описание справа налево:
● Scrum Команда движется вперед, цель за целью.
● В течение ограниченного временного интервала, называемого Спринт, команда

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

индикатором для понимания объема работ, который необходимо выполнить
команде для достижения текущей Цели Спринта; Опционы для будущих
Спринтов содержатся в Продуктовом Бэклоге, отражении стратегии развития и
зоны ответственности Владельца Продукта.
Если вы новичок в Scrum, добро пожаловать! C другой стороны, если вы уже знакомы
с ним, вы можете подумать, что это описание Scrum справа налево совершенно не
похоже на то, что вы читали ранее.
51
Вот гораздо более традиционное описание, которое начинается слева:
● Процесс начинается с Бэклога Продукта, за который несет ответственность

единолично Владелец Продукта.
● На мероприятии Планирования Спринта в начале каждого Спринта команда

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

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

результат Спринта – Потенциально пригодный к Поставке Инкремент –
проверяется всеми заинтересованными сторонами, а команда выявляет
возможности для обучения.
Итак, какое из этих двух очень разных описаний правильное? Как я уже говорил, оба
полностью совместимы со Scrum Guide. Тем не менее, первая версия Scrum,
написанная справа налево, гораздо лучше описывает скелет процесса “разработки,
поставки и поддержки сложных продуктов” (цитируя первую строчку Scrum Guide),
чем вторая, версия слева направо. Последняя может легко описать линейный,
управляемый планом процесс, который дает мало возможностей для совместного
развития продукта и его среды каким-либо значимым (и создающим ценность)
способом.
У вас может возникнуть соблазн подумать, что вытягивание разделяет эти две
версии, но будьте осторожны: технически в основу обеих заложена вытягивающая
система. Независимо от того, выражается ли это в терминах рабочих элементов или
целей, для каждого Бэклога Спринта выбирается не больше, чем позволяет сам
Спринт, остальное остается без обязательств к поставке, в Бэклоге Продукта.
Тем не менее, вполне реальный риск при использовании Scrum слева направо
состоит в том, Бэклог Продукта рассматривается как подробный план, с большим
количеством предварительно принятых или предполагаемых обязательств, и в
системе начинает преобладать менталитет проталкивания. Проталкивание при
отсутствии особого контроля приводит к чрезмерным обязательствам в спринте.
Спринты с чрезмерным количеством обязательств приводят к перегруженности
команд, а как мы знаем, перегрузка приводит к ряду серьезных последствий.
Даже если Спринты не перегружены, но полностью заполнены обязательствами, в

них почти не остается места для экспериментов или для действий на основании
обратной связи. Это, так же как и любой технический аспект проектирования
процессов, ограничивает гибкость. Очевидная контрмера состоит в том, чтобы
учитывать время, необходимое для сбора и действий для доказательства того, что
значимые цели действительно достигаются. Это по умолчанию выполняет Scrum
команда, работающая по принципу "справа налево".
Я надеюсь, что я достаточно ясно показал контраст между двумя видами Scrum.
Вызывает сожаление тот факт, что часто, при объяснении того как работает Scrum,
52
упускается возможность занять более верную позицию “справа налево”, что имеет
существенные последствия для его принятия и применения. C другой стороны,
решения как именно вы внедряете такой фреймворк как Scrum, и заставляете его
работать на вас в вашем контексте, могут иметь такое же значение как ваш
первоначальный выбор – использовать именно его. Мы вернемся к этому важному
вопросу в следующей главе.
Scrum и Лидерство
Учитывая популярность Scrum и его сильный акцент на самоорганизации, важно
понимать роль лидерства как внутри структуры Scrum, так и снаружи. Чтобы Scrum
преуспел и в своем и в организационном контекстах, должны присутствовать четыре
важные вещи:
1. Четкое понимание предназначения, которое в продуктовом измерении

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

способность помогать формулировать и анализировать результаты становится
ключевым лидерским навыком, особенно там, где необходимо поощрять
самоорганизацию и инновации. Для Scrum, Цель Спринта является своего
рода результатом, который придает смысл Спринту. Работая в обратном
направлении, важно отражать долгосрочные планы, такие как дорожные карты
продуктов и технологий, в одинаковых терминах, избегая ненужных деталей и
преждевременных спецификаций. Это создает пространство для
37
своевременного творческого сотрудничества.
2. Правильный размер команды, с достаточной обособленностью, с учетом

цели команды. Эти два требования несколько противоречат друг другу; лишь
немногие команды полностью самодостаточны, и чем меньше команда (Scrum
рекомендует команды от 3 до 9 человек), тем меньше вероятность того, что
она обладает полным набором навыков, что увеличивает ее зависимость от
других людей за пределами команды. Хорошая самоорганизующаяся команда
выявит и устранит пробелы или уязвимости в коллективном наборе навыков
для создания кросс-функциональной команды, но это требует времени; между
тем они должны научиться эффективно управлять своими внешними
37
См. Inspired: How to Create Tech Products Customers Love, Marty Cagan (John Wiley & Sons,
2nd edition, 2018). Автор подчеркивает использование результатов в дорожных картах; он
также откровенно описывает менеджера продукта как лидера, занимающего роль гораздо
большего масштаба, чем та, что определена для роли владельца продукта в Scrum. Это
сделано не для того, чтобы принизить роль PO, а скорее для того, чтобы объяснить, что роль,
ориентированная на рамки, которую преподают "по книге", не соответствует требовательной
лидерской позиции. Я бы добавил, что "служение процессу" – это ловушка, которую все
лидеры должны стараться избегать.
53
зависимостями. Очевидно, что правильный выбор в отношении кадров и
правильные инвестиции в навыки могут дать плоды.
3. Доверьтесь процессу. Если ваша организационная культура основана на

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

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

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

В канбан-системах на производстве, описанных в главе 1, сигнальные карты (канбан)
отправляются вверх по потоку (upstream) с такой скоростью, чтобы поставить готовую
продукцию, узлы или материалы по мере необходимости, точно в срок, при этом
инвентарные запасы сводятся к минимуму. Простая, но удивительно эффективная
сигнальная система справа налево обеспечивает плавный поток слева направо.
Вдали от фабрик, канбан системы часто выглядят совсем иначе, как правило, в
форме стикеров или карточек, которые перемещаются по какой-нибудь доске, стене
или электронному экрану – канбан доске. Однако, цель одна и та же: явное и
постоянное внимание к потоку38, как ради самого потока, так и для более широкого
38
Daniel Mezick описал Канбан как “исключительное внимание к потоку” в The Culture Game:
Tools for the Agile Manager (2012, FreeStanding Press). Можно сказать, что ваша система
получает то, на что она обращает особое внимание.
54
воздействия, которое он может оказать на структуру организации в долгосрочной
перспективе.
Рисунок 13. Простая канбан доска
Этот новый тип канбан системы имеет три ключевых элемента:
1. Визуальное представление рабочего процесса на подходящем уровне

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

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

частях. Таким образом контролируют объем незавершенного производства
(Work in progress, WIP). Наиболее важными из этих правил являются объемы
незавершенного производства (WIP лимиты): простые числа, которые
определяют максимальное количество рабочих элементов, разрешенное в
соответствующих столбцах (или, в более общем случае, в определенных
местах доски).
Если все эти три условия соблюдаются, у нас есть вытягивающая система: работа
втягивается в систему (или ее части), только если позволяет емкость.
39
Поскольку Канбан система нужна для помощи в улучшении процесса, считается чем-то
вроде антипаттерна называть колонки в честь ролей или подразделений, которые обычно
труднее изменить, чем состояния рабочих элементов или виды деятельности.
55
Перегруженность моментально уменьшается, а уменьшение WIP дает больше
возможностей для сотрудничества. Многие из команд, с которыми я работал в
последние годы, держат в работе меньшее количество рабочих элементов, чем у них
есть людей, предполагая, что какое-то сотрудничество должно происходить большую
часть времени (и это так).40
В одном очень практическом смысле, канбан доска является воплощением мышления

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

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

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

появится в ближайшее время, понимаем ли мы, какую работу выбрать
следующей и почему?
Рисунок 14. Доска проверяется справа налево
От этой манеры управления повседневной работой справа налево, остается лишь

небольшой шаг к стилю улучшения процесса справа налево. Менеджерам и командам
нужно лишь небольшое количество подсказок (точнее, подсказка – сама канбан
доска), чтобы быстро распознавать и устранять все, что мешает работе выйти из
40
Если вы сами не сталкивались с этой взаимосвязью между WIP и сотрудничеством,
ознакомьтесь с нашими играми-симуляторами Featureban и Changeban на сайтах
http://agendashift.com/featureban и http://agendashift.com/changeban.
56
системы. Всякий раз, когда препятствием является какой-либо аспект, вызываемый
визуализацией или правилом канбан системы, её дизайн меняется, и процесс
изменяется в одно мгновение! В конце концов, когда работа начинает проходить через
систему более плавно, любые вопросы по поводу качества работы, поступающей в
систему, приобретают все большее значение, и внимание обращается вверх по
потоку.
Канбан Метод (то как его систематизировал Дэвид Дж. Андерсон и описал в своей
«синей книге»41 2011 года, и позднее представленная трактовка, основанная на
ценностях, в моей первой книге42) очень четко описывает не процесс разработки, а
подход к улучшению. Он характеризуется преднамеренным отказом от предписаний в
отношении деталей реализации и имеет в своей основе Lean-подобное стремление к
потоку. По сравнению с традиционным Lean подходом, описанным в главе 1, есть
несколько примечательных отличий:
1. Это эволюционный подход “начни с того, что ты делаешь сейчас” –

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

спектру возможных позитивных шагов: наиболее очевидными являются
визуализация и контроль WIP, а также дизайн петель обратной связи,
использование метрик и практика изменений через гипотезы (подробнее об
этом далее в этой главе).
Scrum и Канбан
Книга «Канбан Метод: Улучшение системы управления» вышла в 2014 году. Я
упомянул год, потому что в то время я был готов сделать непопулярный шаг и
включить доброжелательную главу про Скрам в книгу о Канбане. Сейчас, всего
несколько лет спустя, эра постов “Scrum против Kanban” в блогах еще не умерла, но
от новых статей обычно сразу открещиваются оба лагеря.
По правде говоря, единственное реальное соревнование между ними – это доллары
за тренинги; достаточно начального понимания этих двух фреймворков для
осознания, что они являются скорее взаимодополняющими, чем конфликтующими.
Более того, отдельной рекомендации заслуживает комбинация Scrum и Канбан
(иногда называемая Scrumban).
Нетрудно заметить, что они должны дополнять друг друга:
● Scrum описывает процесс поставки на уровне команды, очень подходящий для

разработки продукта; Канбан работает с широким спектром существующих
процессов на различных масштабах – например, на персональном и
41
Kanban: Successful evolutionary change for your technology business, David J. Anderson (2011,
Blue Hole Press)
Перевод на русском языке: Канбан. Альтернативный путь в Agile, Дэвид Андерсон (2017, МИФ)
42
Kanban from the Inside, Mike Burrows (2014, Blue Hole Press)
57
командном, потоке создания ценности и портфеле проектов – что позволяет
ему работать как внутри Спринта, так и вокруг него.
● Scrum определяет роли (Владелец Продукта, Скрам Мастер, Команда); Канбан

не делает этого.
● Бэклог Спринта в Scrum обеспечивает ограничение незавершенной работы

(WIP) и четкую сфокусированность на Спринте (Цель Спринта); Канбан
позволяет применять различные инструменты управления к тем частям
процесса, которые принесут наибольшую пользу.
● В дополнение друг к другу, оба ориентированы на результат – в Scrum через

Цель Спринта и все последующие действия вверх по потоку (upstream),
которые способствуют ее выявлению, а в Канбане – через долгосрочное
стремление к соответствию предназначению (fitness for purpose).
В практическом плане не существует единственной комбинации Scrum и Канбан;

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

что плохо подходит для Scrum, например работу по поддержке и срочные
улучшения43.
2. Канбан используется для управления задачами Скрам Команды – например,

задачами разработки или задачами тестирования – с помощью простой
структуры “Сделать / Делается / Готово” или более детальной, подходящей
конкретному процессу в команде.
3. Поскольку “нельзя просто так взять и сделать задачу” (немного

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

применяется снаружи и вокруг Скрам процесса для управления
определенными темами или партиями работ – бизнес-инициативами,
длительными продуктовыми экспериментами, эпиками45 и т. д. – из которых
генерируются и тестируются идеи для улучшений.
Теперь должно быть понятно, что Scrum и Канбан выполняют две совершенно разные
роли: Scrum – бьющееся сердце процесса разработки, Канбан – мощный
43
К сожалению, продвижение Kanban как тактики работы, которая не совместима со Scrum,
привело к появлению мифа о том, что Kanban не подходит для разработки. Хуже того, когда
Kanban используется только для управления работой, не подходящей для Scrum, это шаг к
укреплению неправильных границ команды.
44
Еще один миф: поставка должна быть один и только один раз за Спринт.
45
В Agile эпики это просто большие “истории”, названные так относительно “пользовательских
историй” – фрагменты работы больше обычно проходящих через систему, что предполагает
их разбиение на более мелкие части.
58
координационный механизм как внутри Скрам процесса, так и за рамками Спринта и
между организационных границ. При удачном сочетании они объединяются, чтобы
способствовать потоку, самоорганизации, адаптации и обучению.
Паттерн 3. Люди, процессы и технологии: XP и DevOps

Более десяти лет отделяют экстремальное программирование (XP) и DevOps друг от
друга, но они имеют много общего. XP предшествовал Agile-манифесту и остается
источником вдохновения для многих технических практик, которыми сегодня
пользуются команды разработчиков. DevOps должен был решить организационную
проблему, но при этом стал катализатором быстрого прогресса как в процессе, так и в
технологии. Вместе они обеспечивают техническую основу современного процесса
разработки программного обеспечения, особенно цифровых технологий, где скорость
и обратная связь имеют первостепенное значение.
XP
В авторитетной статье 2009 года Flaccid Scrum46 один из создателей Agile Manifesto
Мартин Фаулер использовал такие слова, как «беспорядок» и «разрушительный»,
чтобы описать, что происходит, когда команды внедряют Scrum (рассматриваемый в
то время как де факто Agile-процесс), не внедряя одновременно технические
практики, выдвинутые на первый план в XP. Такие команды обнаружили, что их
производительность резко упала, потому что их код становился все более сложным в
поддержке. Вот вам и приверженность манифесту о работающем программном
обеспечении!
Сейчас, когда опытные команды разработчиков ссылаются на Scrum, они часто имеют
ввиду Scrum + XP, или, по крайней мере, Scrum плюс множество технических практик
из XP. Это означает, что:
● Кодовая база команды развивается небольшими, протестированными

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

интеграция автоматически запускает полный набор тестов.
● Разработчики, просматривают код друг друга (проводят code review), на

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

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

накладные расходы; они очень просто отражают (даже сейчас, 20 или более лет
спустя) наше лучшее понимание того, как команды людей могут стабильно
разрабатывать программное обеспечение. Можно сказать, что неспособность
46
Flaccid Scrum, Martin Fowler (2009), http://martinfowler.com/bliki/FlaccidScrum.html
59
постоянно тестировать, интегрировать, анализировать или рефакторить накапливает
будущие проблемы; ХР ловко переворачивает это с помощью мантры «Если больно,
делай это раньше и чаще».
Для эффективности этого подхода необходимо взаимно усиливающее сочетание

людей, процессов и технологий:
● Люди, стремящиеся к “устойчивой разработке”, которая подразумевает

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

качество и способствует быстрому и широкому обмену знаниями.
● Технологии, включающие необходимый минимум:
○ Общие репозитории с кодом, в которых фиксируются все изменения.
○ Фреймворки для тестирования – кодовые библиотеки, которые

облегчают написание автоматических тестов в идиоматическом стиле,
понятном любому разработчику в команде, часто для облегчения
разработки через тестирование (Test Driven Development, TDD).
○ системы непрерывной интеграции (Continuous Intergarion, CI),

соединяющие работу разработчиков и запускающие наборы тестов и
другие автоматизированные проверки качества.
Чем раньше это будет внедрено, тем проще это сделать, и тем больше будет польза.
Сегодня инструменты настолько повсеместно распространены – доступны на основе
открытого исходного кода на всех основных платформах, – что единственные
реальные барьеры для входа это организационные. И подумайте: не будет ли
немного досадно, если ваша техническая команда страдает от недостатка технологий,
которые по сути бесплатны?
Мышление “быстрее и чаще” из XP имеет свои аналоги вне разработки, особенно это
заметно в сообществе по обеспечению качества (Quality Assurance, QA) и в движении
DevOps. В случае с QA, ценность «Тестируй рано и тестируй часто» была давно
очевидна. Некоторые QA сообщества идут дальше в этом направлении, поощряя
«Сдвиг влево» в ответственности за качество (их фраза, а не моя), и роль QA –
перейти от работы на последней фазе на что-то, что работает как с качеством, так и с
общим процессом.
47
http://en.wikipedia.org/wiki/Software_craftsmanship
60
DevOps
DevOps гораздо моложе XP, ему всего с десяток лет. Это не столько процесс, сколько
движение, его целью является интеграция разработки программного обеспечения и
IT-эксплуатации. Преимущества устранения функциональных колодцев очевидны:
● Благодаря конструктивному кросс-функциональному взаимодействию,

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

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

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

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

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

ощущаются выше по потоку (upstream). Благодаря виртуализации серверов и сетей,
можно делать произвольными не только развертывания. Можно создавать,
уничтожать, масштабировать или сокращать целые среды и окружения по мере
необходимости, как часть процесса построения непрерывной интеграции. А благодаря
контейнеризации однократно построенные сервисы могут работать без изменений в
любом окружении, будь то ноутбук разработчика, тестовый сервер или продуктивное
окружение.
61
Паттерн 4. Изучение возможностей: User Story Mapping,
Jobs to be Done, и BDD
Прежде чем мы продолжим работу над паттерном № 5 и Мышлением проектирования
сервиса, стоит сделать паузу, чтобы представить некоторые из инструментов
управления продуктом, наиболее заметные на границе производства, в точке
принятия обязательств (между upstream и downstream).
Популярный и эффективный инструмент организации фич для последующего

разработки это Story Map, сокращение от User Story Map48 (карта историй
пользователя). Визуально карту историй (story map) легко перепутать с канбан доской,
но вместо названий столбцов, описывающих этапы процесса поставки или состояния
рабочих элементов, заголовки – костяк карты историй, – описывают
высокоуровневое путешествие пользователя по разрабатываемой системе. Под этими
заголовками "истории" (подробнее об этом чуть дальше) расставляются по вертикали;
когда приходит время выбирать работу для разработки, элементы берутся сверху
одной или нескольких колонок, выбранных в соответствии с текущим фокусом
команды.
Простой пример из жизни: когда я временно исполнял обязанности менеджера

поставки для цифрового сервиса "Найти стажировку", у нас была 5-столбцовая
карта историй с такими заголовками:
1. Поиск (для доступных вакансий стажировки)
2. Подать заявку (на конкретную вакансию)
3. Управление моими заявками (отслеживание статуса заявок, отмена заявок и

т.д.)
4. Управление моим аккаунтом (изменение профиля кандидата, изменение

пароля, удаление аккаунта и т.д.)
5. Поддержка кандидатов (функций для внешних консультантов по вопросам

карьеры или внутренних операционных сотрудников)
48
User Story Mapping: Discover the Whole Story, Build the Right Product, Jeff Patton and Peter
Economy (2014, O’Reilly Media)
62
Рисунок 15. Карта историй пользователя
Во время моего участия на ранних стадиях разработки сервиса большинство функций

и улучшений, ориентированных на пользователя, нашли бы место в одной из этих
пяти колонок. Позже, по мере роста сервиса, ориентированного на кандидатов, мы
смогли выделить больше возможностей для развития под потребности работодателей
и поставщиков образовательных услуг, и карта истории (story map) менялась в
соответствии с ними. Среди этих изменений была визуализация зависимостей и
других реальных или потенциальных блокеров. Визуализация стимулировала нас
проактивно управлять ими и тщательно приоритизировать изменения. Не начинайте
то, что не сможете закончить!
Пользовательские истории (User story), которые дают карте историй (Story map) свое
название, вкратце описывают фичи или их части. По словам их изобретателя Кента
Бека, пользовательские истории – это просто "поводы для беседы". Часто такие
разговоры начинаются с намеренно стереотипных вещей, соответствующих шаблону
истории пользователя, подобному этому, известному как шаблон Connextra,
названному в честь его источника:
● Как <персона>, я хочу <цель/желание>, чтобы <выгода>
К сожалению, нередки случаи, когда пользовательские истории на самом деле не

описывать потребности пользователей. Как будто истории пользователей сводятся к
этому:
● Как продуктовая команда мы хотим <требование>, чтобы <бизнес

обоснование>
И мы знаем, что происходит, когда мы начинаем бороздить списки требований:

посредственные продукты!
Один из важных приемов, чтобы избежать этой тенденции – это создание фич через
сценарии – "случаи реальной потребности", как мне нравится их описывать – в
63
которых фичи становятся важными для кого-то. Как лидеры, вы можете просто
спросить:
● Когда это необходимо? Можете ли вы описать случай реальной потребности

для этой функции?
В тех случаях, когда полезно зафиксировать ответ, рассмотрите короткий формат job
story и длинный формат Behaviour Driven Development (BDD).
Шаблон job story выглядит следующим образом:
● Когда <настоящая необходимость>, я хочу <действие>, чтобы я мог

<достигнутый результат>
Job story основываются на Работе, которую нужно выполнить49 (JTBD). Один из их

классических примеров заимствован у профессора Гарвардской бизнес-школы
Теодора Левитта:
"Люди не хотят сверло в четверть дюйма, они хотят отверстие в четверть

дюйма"
Теперь вы знаете, что вдохновило историю, открывающую главу 1! Здесь в одном

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

тестов (см. XP выше) и завоевавший популярность у бизнес-аналитиков и
тестировщиков. В BDD пользовательские истории дополняются множеством
сценариев, описанных в структуре из трех частей Given/When/Then, часть Given,
охватывает начальные условия сценария, часть When, идентифицирует событие,
вызывающее реакцию системы, часть Then, описывает ожидаемые результаты (с
достигнутым результатом и удовлетворенной потребностью).
Например:
История: Поиск на основе местоположения.
Как кандидат, я хочу видеть вакансии рядом со мной, чтобы мои

расходы на проезд были низкими.
Сценарий: Кандидат предоставляет корректный почтовый индекс
(Given) При наличии действительного почтового индекса
(When) Когда кандидат ищет вакансию
(Then) Наиболее географически близкие результаты должны быть

показаны первыми.
49
Know Your Customers’ “Jobs to Be Done”, Clayton M. Christensen, Taddy Hall, Karen Dillon, and
David S. Duncan (Harvard Business Review, September 2016 issue),
http://hbr.org/2016/09/know-your-customers-jobs-to-be-done
64
Сценарий: Кандидат предоставляет недействительный почтовый
индекс.
и т.д.
Ряд инструментов автоматизированного тестирования поддерживает спецификации в

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

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

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

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

ожидаемые результаты; выявляя основные риски, зависимости и краевые
случаи.
● Не слишком много – заботясь о том, чтобы не углубиться в детали, которые

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

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

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

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

необходимости? Или, что личность пользовательской истории репрезентативна для
использования? На самом деле, есть только один способ убедиться – нужно пойти и
посмотреть. Это один из способов, при котором Сервис-дизайн мышление (Service
Design Thinking) может стать всерьез многопрофильным, с потенциальным
привлечением исследователей пользователей, и даже антропологов или этнографов
(например, чтобы понять потенциальных пользователей в их социальной и культурной
среде). Не то чтобы наличие таких специалистов должно исключать технологов или
“работу в поле” для исполнителей, на самом деле – наоборот! Из личного опыта и
наблюдая как члены команды по очереди проходят через исследования
пользователей, я знаю, что рост эмпатии к пользователям напрямую зависит от
количества вовлеченных ленов команды. Чем больше вовлечено членов команды,
тем больше эмпатии они испытывают к своим пользователям и тем сильнее они
мотивированы на поиск хороших решений проблем, которые они выявляют.
Эти примеры из сервиса Найди Стажировку иллюстрируют важность контекста:
● 16-летний, который говорит нам: "Но я бы не делал этого на своем

компьютере, я бы вытащил свой телефон во время урока, под партой,
подальше от взора преподавателя!"
● 18-летний, который рассматривает стажировку взамен университетского

образования (такая альтернатива – относительно недавний феномен в
Соединенном Королевстве).
● Кандидат, который будет рассматривать "все подряд, пока еду в автобусе"

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

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

Некоторые потребности особенно важны: они помогают определить, что представляет
собой продукт или услуга. Как мы увидим в Главе 5, некоторые из них могут быть
даже описаны как "стратегические потребности" – потребности, которые помогают
определить миссию организации и придать форму продуктам и услугам.
66
Например, объединение кандидатов и работодателей для прохождения стажировки
является стратегической потребностью, удовлетворяемой Агентством по
Финансированию Профессиональных Навыков, как впоследствии было названо
соответствующее правительственное агентство Великобритании50. Это не
единственная его функция, но, безусловно, ключевая часть его миссии.
Как и многие другие фасилитируемые процессы, Дизайн Мышление характеризуется

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

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

тестирование или иными способами.
Рисунок 16. Дивергентные и Конвергентные фазы
Дизайнерское Мышление отличается не только использованием инструментов,

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

испытываем наши идеи на реальных людях и тестируем их через беседы,
визуализации (например, раскадровки в киношном стиле), бумажные прототипы,
прототипы экранов и так далее. За счет отказа от реализации полноценных
технических решений, итерации могут быть выполнены на удивление быстро (и я был
свидетелем множества итераций дизайна, выполненных за один вечер). Опять же, в
игру вступают несколько дисциплин: дизайн сервиса, дизайн взаимодействия, дизайн
пользовательского интерфейса (UX), визуальный дизайн, контент-дизайн и так далее.
50
С расширением полномочий Агентство по финансированию профессиональных навыков
Великобритании стало Агентством по финансированию образования и профессиональных
навыков (http://www.gov.uk/government/organisations/education-and-skills-funding-agency)
67
Сочетание различных точек зрения в совокупности повышают привлекательность
сервиса и его общее качество, как с точки зрения внешнего, так и с точки зрения
внутреннего опыта.
Решающий фактор успеха любого нового продукта – обеспечить изучение должным

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

Книга Marc Stickdorn и Jakob Schneider This is Service Design Thinking52 представляет
пять принципов эффективного сервис-дизайна, которые они обобщают как
“клиенто-центричный, соавторский, последовательный, доказательный и целостный”.
В заключение этого раздела позвольте мне немного переосмыслить эти принципы как
акты цифрового лидерства:
1. Начните с потребностей пользователя53, если мы не соответствуем потребности,

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

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

когда вовлечены различные части организации, важно, чтобы каждый понимал, как на
самом деле работает сервис. Такие визуализации, как user journey maps и service
51
See Beyond Software Architecture: Creating and Sustaining Winning Solutions, Luke Hohmann
(2003, Addison Wesley Professional)
52
This is Service Design Thinking: Basics-Tools-Cases, Marc Stickdorn and Jakob Schneider (BIS
Publishers, 2010)
53
Правительственная цифровая служба Великобритании (GDS) в качестве принципа
проектирования №1 использует "Начните с потребностей пользователя" – см.
http://www.gov.uk/guidance/government-design-principles. Для большей выразительности этот
принцип иногда расширяют до "Начните с потребностей – потребностей пользователя, а не
правительства".
68
blueprints, действительно помогают воплотить их в жизнь, показывая
последовательность событий, действий и взаимодействий, в совокупности
позволяющих достичь желаемых результатов для всех заинтересованных сторон.
Новые разработки можно протестировать на бумаге (буквально!); инструменты
визуального проектирования могут способствовать быстрому прогрессу в
проектировании сервиса при квалифицированной фасилитации и правильных людях
в комнате, создавая общее понимание и уверенность в процессе. После этого можно
выставлять созданные артефакты на обозрение по всему рабочему пространству, не
только для справки или украшения, но и как фокусные точки для актуальных
обсуждений.
4. Сделайте сервис осязаемым. Каким образом Ваши пользователи узнают, что вы

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

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

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

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

(положительное и отрицательное) сервиса и его бизнес-среды, уделяя особое
внимание тому, как со временем могут развиваться ключевые отношения. Среди
более очевидных вещей, на которые следует обратить внимание: давление со
стороны внешней конкуренции и внутренний аппетит к текущим инвестициям; менее
очевидными, возможно, являются такие вещи, как прием на работу и повышение
квалификации персонала (перемещение целей по мере взросления сервиса),
внутренняя конкуренция, синергетический эффект и регуляторная среда. Не все
можно контролировать, но не стоит недооценивать свое влияние!
69
Паттерн 6. Систематическое управление узкими местами:
Теория ограничений
Управленческий фреймворк Теория Ограничений (Theory of Constraints, ТОС)
привлекла к себе внимание мировой общественности в 1984 году в необычной форме
делового романа, бестселлера, Цель (The Goal)54, написанного создателем ТОС,
Элияху (Эли) Голдраттом. Как и у Lean, корни TOC в производстве, она много говорит
об улучшении, и широко применима за пределами своей первоначальной области. И
фреймворк, и книга до сих пор остаются очень влиятельными, этот факт признан в
еще одном деловом романе, прорывной книге движения DevOps, Проект Феникс (The
Phoenix Project).55
В основе TOC лежит цикл под названием Процесс непрерывного совершенствования

(Process of Ongoing Improvement, POOGI) и его 5 фокусирующих шагов. Вот
современный взгляд на эту модель, описанный в блестящей короткой книге Clarke
Ching The Bottleneck Rules56, основанной на мнемонике FOCCCUS.
FOCCCUS означает Искать (Find), Оптимизировать (Optimise), Координировать

(Coordinate), Сотрудничать (Collaborate), Курировать (Curate), Модернизировать
(Upgrade) и Начать заново (стратегически) (Start again (strategically)). Если
кажется, что это много, чтобы помнить, думайте об этом как о 'FOCUS', с 'C', разбитый
на три, вот так:
1. В начале мы должны Искать узкое место, деятельность, которая определяет

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

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

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

отдачу от работы с "узким местом". В каждый момент должно быть ясно, над какими
наиболее важными вещами вокруг “узкого места” необходимо работать в первую
54
The Goal, Eliyahu M. Goldratt and Jeff Cox (Routledge, 3rd edition 2004)
55
The Phoenix Project, Gene Kim, Kevin Behr, and George Spafford (IT Revolution Press, 3rd
edition 2018)
56
The Bottleneck Rules: How to Get More Done (When Working Harder isn't Working), Clarke Ching
(Independently published, 2018)
70
очередь. Часто полезно поддерживать небольшой буфер из дорогостоящих
элементов, который поддерживается непосредственно перед "узким местом", чтобы
он никогда не заканчивался.
И только после:
6. Модернизируйте узкое место, инвестируя в увеличение его пропускной

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

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

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

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

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

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

местом часто становится не что-то техническое, а отсутствие в очереди
высококачественных идей, часто сопровождающееся разочаровывающими
задержками в принятии решений. Проблема заключается не в трате времени
на анализ (часто это можно компенсировать на следующих этапах), а в
недостатке усилий, затраченных на обнаружение и создание возможностей.
57
Опыт учит, что выражение "как только у вас это появится, вы пожалеете, что не сделали
этого с самого начала" применимо практически к любой возможности XP или DevOps.
71
“Проектные" организации, как правило, усваивают эти уроки болезненно медленно.
Одна из причин – работа большими партиями, выполнение которых занимает на
порядки больше времени. Это довольно плохо, но есть и другие причины:
1. Они, как правило, откладывают инвестиции связанные с возможностями

развертывания и эксплуатации возможностям до последнего ответственного
момента (или даже позже), отказывая себе в возможности практиковать новые
способы работы с высокой обратной связью. Когда иронично названная
"усвоенными уроками” (lessons learned) встреча наконец-то происходит, уже
слишком поздно.
2. После определения границ проекта, часто отвергаются простые предложения

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

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

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

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

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

средств в период жесткой экономии, смогли внести эти смелые изменения, какое
оправдание есть у вашей организации?
72
Паттерн 7. Бизнес-эксперимент, основанный на гипотезах:
Lean Startup
"Все, что я видел в данных с момента выхода этого релиза, пока выглядит
великолепно", – сказал Роуэн в начале предыдущей главы. На какие данные будет
смотреть продакт-менеджер? Чтобы ответить на этот вопрос, необходимо вернуться
еще на несколько дней назад во времени. Алекса, разработчик, участвующий в этом
разговоре, делится идеей.
Алекса: я проходила мимо листовок проектов ”Сделай сам” рядом с выходом из

магазина и задалась вопросом: "А что если бы они тоже были в онлайне?", и
это заставило меня задуматься. Я даже остановила пару покупателей,
чтобы спросить, будут ли они их использовать! Я знаю, что нельзя верить
всему, что люди говорят в интервью, но даже тогда я думаю, что это было
бы здорово!
Роуэн: Я вижу, что ты взволнована! Предположим, мы возьмем это в работу, как бы

это могло выглядеть?
Алекса: Ну, мы бы переделали все эти листовки в веб-страницы и сделали бы так,

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

отличная поисковая оптимизация…
Алекса: Точно – и мы бы добавили ссылки на них в верхней части соответствующих

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

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

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

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

построй-измерь-учись из Lean Startup.
1. Постройте что-то, что позволит быстро и дешево проверить гипотезу.
2. Измерьте влияние этого шага, обычно через поведение покупателей –

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

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

Viable Product, MVP) – собственного теста на соответствие продукта рынку – и при
необходимости готовится к смене направления (или развороту), а не чрезмерному
инвестированию в идею, в большие гипотезы, которые нельзя подтвердить.
Короче говоря, Lean Startup описывает дисциплину бизнес экспериментов,

основанных на гипотезах. Если (и это несовершенная аналогия) DevOps это Agile,
переосмысленный инженерами, знакомыми с теорией ограничений, то Lean Startup –
это то же самое, но с менеджерами продукта и предпринимателями,
заинтересованными в Lean. Он сфокусирован на валидированном обучении, и,
пожалуй, наиболее направлен “cправа налево” среди всех фреймворков,
рассматриваемых в этой главе.
Несмотря на то, что он ассоциируется со стилем бизнеса 21 века – не всегда

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

виде гипотезы, в стиле Lean Startup:
Мы верим, что страницы проектов ”Сделай сам”, снабженные гиперссылками,

приведут к увеличению продаж продукции.
58
см. http://en.wikipedia.org/wiki/PDCA. Также см. мою статью On not teaching PDCA,
http://blog.agendashift.com/2016/03/01/on-not-teaching-pdca/.
74
В случае успеха мы можем рассчитывать на:
● Потенциальных покупателей, приходящих на эти новые страницы.
● Существующих пользователей, переходящих на эти новые страницы с других

страниц сайта.
● Дальнейшие переходы к родственным товарам.
● Покупки товаров, как прямой или косвенный результат этих новых просмотров
страниц.
Это довольно хорошо описывает цели как предложения Алексы по реализации

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

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

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

вводятся в область управления продуктом. Одно из естественных решений это
Дизайн Мышление; вы можете сказать, что Lean Startup + Дизайн Мышление дают
вам Непрерывные Открытия (и многое другое). Еще один отличный вариант – Kanban,
часто используемый для управления экспериментами, которые могут потребовать
непредсказуемых периодов времени, чтобы добиться значимых результатов (и
поэтому не так легко сочетаются с ритмами спринта).
Вот дизайн канбан доски для моей симуляции "Lean Startup", игры Changeban (рис.
17):
75
Рисунок 17. Доска Changeban
Кроме разделения правого столбца для нужд игры (оно спроектировано для удобства
подсчета очков), это – стереотипная доска для управления экспериментом. Она имеет
приятное соответствие с классической диаграммой Венна (Venn diagram), Ценное,
Возможное, Используемое (рис. 18).
Рисунок 18. Ценное, Возможное, Используемое
76
Чтобы идея прошла весь путь от столбца "Соглашение о срочности" до "Принята", она
должна быть:
1. Наиболее ценной относительно всех остальных обсуждаемых вариантов.
2. Как технически возможной, так и организационно приемлемой.
3. Пригодной для использования, поощряя желаемое поведение пользователей.
4. И опять же ценной, с подтвержденными преимуществами, на которые мы

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

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

мы, возможно, обнаружили бы это
<раньше, дешевле, и / или более безопасно>
Ретроспектива это замечательная вещь, но сколько неудач могли дать урок раньше,
дешевле, и/или безопаснее с лучшим планом эксперимента? Что, если мы бы всегда
рассматривали наши неудачи с этой стороны? Регулярная возможность это делать
описана в главе 5.
Справа налево: Теория большого объединения для

Lean-Agile.
В этой главе было много подробностей. Давайте в этом резюме посмотрим, как наши
непрерывные, ориентированные на результат, основанные на вытягивании, и на
взгляде “справа налево” фреймворки действительно помогают объяснить, каким
образом они поддерживают друг друга:
1. Scrum, непрерывно итерируясь и самоорганизуясь вокруг целей (краткосрочных

результатов) для достижения более долгосрочных результатов – продуктового
видения, миссии команды, целей организации и так далее.
77
2. Канбан, делая прогресс достижения результатов видимым, концентрируя усилия на
результатах с наибольшей значимостью, способствуя сосредоточению внимания на
завершении, и делая стремление к соответствию предназначению более осязаемым.
3. XP и DevOps, прямо связывая процессы разработки и эксплуатации, обеспечивая

инфраструктуру процесса, практики и технологии, необходимые для ускорения
обратной связи о поставке результатов.
4. User Story Mapping (создание карт пользовательских историй), Jobs to be Done

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

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

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

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

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

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

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

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

управляемости, но с необходимым для самостоятельности набором навыков и
возможностей?
5. Каким образом механизмы управления на уровне команды взаимодействуют с

управлением на уровне организации?
6. Какими конкретными способами вы поддерживаете внимание на потоке во всей

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

высокой обратной связью?
8. Как вы обнаруживаете, идентифицируйте, исследуете, схватываете,

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

снижающие общую эффективность процесса развития вашего продукта?
10. Как ваша организация добивается соответствия продукта рынку? Какими

механизмами она поощряет эксперименты и обучение?
79
В Springboard DIY только что узнали об организации консорциума поставщиков,
который настаивает на быстрой интеграции розничных торговцев с новой общей
системой.
Не то, чтобы он реально мог на этом настаивать, но немногие ритейлеры могут

позволить себе отказаться от такого предложения. Роуэн, менеджер продукта,
находится на совещании по обсуждению этого вопроса в офисе Ники, директора по
информационным технологиям (Chief Information Officer (CIO)).
Ники: Роуэн, ты выглядишь обеспокоенным!
Роуэн: Я не столько обеспокоен, сколько расстроен. У нас было столько планов, а

теперь это!
Ники: Но...
Роуэн: Но я убежден, что нам необходимо это сделать. Откладывание в дальний

ящик обойдется нам слишком дорого.
Ники: Именно. Ты выразил мои мысли!
Роуэн: И ситуация теперь иная, чем 5 лет назад, когда такие проекты чуть нас не
угробили. Тогда формирование команды утонуло бы в бесконечных битвах
между отделами, мы бы целую вечность выясняли что надо сделать! И не
заставляйте вспоминать о том, как тяжело тогда было запускать
производство, когда, наконец, мы начали что-то создавать. А если возникали
какие-то внешние зависимости… я содрогаюсь от одной мысли об этом.
Серьезно, интересно, как мы выжили?
Ники: И теперь ты часть отличной команды, и никто не сомневается, что вы

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

начнем!
К лучшему или к худшему, ни одна книга о Lean-Agile ландшафте не будет полной без
упоминания масштабирования и фреймворков масштабирования. Масштабирование
ведет речь о "большем", будь то команды или отделы больше, чем одна Scrum
команда, или больше систем, больше проектов, больше временных горизонтов, и так
далее.
Я должен сразу же упомянуть, что вопрос “должны ли счастливо сосуществовать Agile

и “большее”, считается в сообществе практиков достаточно спорным. Еще более
80
спорный вопрос – должен ли ответ приходить в виде предопределенных
фреймворков.
Я не буду склоняться к какой-то из сторон данной дискуссии, но это не значит, что я

уклоняюсь от этого вопроса. Речь о более важных вещах! Но давайте не будем
забегать вперед. Для начала мы рассмотрим эти фреймворки, начиная с слегка
вводящей в заблуждение модели Spotify – скорее структурной модели
организационного дизайна. За ней последуют образцы процессных фреймворков,
наиболее известный из них, SAFe.
После представления фреймворков мы вернемся к вопросу, поднятому в нашем

сравнении оттенков Scrum “Слева – Направо” и “Справа – Налево”: вопросу о том, как
должно проходить внедрение конкретных фреймворков или в целом Lean, Agile, или
Lean-Agile. Придерживаясь темы масштабирования в этой главе, мы рассмотрим
последствия не только для затрагиваемых команд, но и для всей организации.
Модель Spotify: отряды, кланы, отделы и гильдии...

Модель Spotify часто представляют как структуру организации. Однако ее лучше
понимать не как решение, а как конкретный пример реакции Spotify на уникальную
ситуацию – период настолько впечатляющего роста, что компания рисковала
потерпеть неудачу, если бы не уделила достаточного внимания поддержке и усилению
ключевых аспектов своей культуры.
Модель была описана в статье Henrik Kniberg и Anders Ivarsson в 2012 году59. Как и
все модели, она упрощение более запутанной реальности и ее трудно
переиспользовать без искажений. Упомяните ее и часто сможете услышать "Даже
Spotify на самом деле не использует модель Spotify", иногда даже от людей, которые
там работают! Тем не менее, это интересный пример и важная модель, успешно
внедрившая некоторую терминологию, понятную достаточно широкому кругу, что
облегчает обращение к некоторым культурным идеям. Кроме того, она дает крупным
консультантам что-то такое, что можно порекомендовать очень не-Spotify-ным
клиентам (простите, если я слишком циничен в этом последнем замечании).
Давайте построим модель снизу вверх, объясняя намерения Spotify по ходу дела. Ее
наиболее атомарная организационная единица – это отряд (squad), автономная,
долгоживущая, многофункциональная команда, с собственным выделенным
владельцем продукта (Product owner, PO).
59
Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, Henrik Kniberg and Anders
Ivarsson (2012), http://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf
81
Рисунок 19. Отряд
Размер отряда примерно как у Scrum команды, но отряды могут развивать свои
собственные процессы, будь они на основе Scrum, Kanban, комбинации обоих, или
чего-то совершенно иного.
Поскольку отряды долговечны, они не являются проектными командами в

традиционном смысле этого слова. Скорее, они формируются вокруг долгосрочной
миссии, с набором целей и временем для развития прочных рабочих отношений и
отличных навыков. К ним относятся технология массового масштабирования, которая
обслуживает миллионы абонентов Spotify, и способность поддерживать быстрые
темпы изменений во всей технологической цепочке.
С помощью этой модели компания Spotify пытается привить своим отрядам ощущение
Lean Startup. Для усиления этого предпринимательского духа эти "стартапы"
"инкубируются" в сплоченные Кланы (Tribe) численностью до 100 человек, в которых
все они работают над связанными вещами и находятся в непосредственной близости
друг от друга. Следует отметить, что в Spotify пришли к выводу, что совместное
размещение необходимо для здоровья клана; даже они сочли свою модель сложной
для реализации, если она не поддерживается в правильной обстановке физического
окружения.
82
Рисунок 20. Клан
Общение между отрядами – внутри одного клана, между союзами родственных

кланов или между кланами в целом, происходит в основном самоорганизованно,
спонтанно, по потребности. Только для необычайно больших или сложных проектов
необходимо проводить регулярные и официальные встречи для управления
зависимостями. Они также могут быть самоорганизованы; самоорганизация и
автономия высоко ценятся и на них можно положиться. Однако это не является
обязательным; владельцы продуктов сотрудничают в рамках "дорожных карт"60, к
которым привязаны бэклоги отрядов.
Вам может быть интересно, как сотни разработчиков могут работать так
самоорганизованно, не спотыкаясь друг об друга. Часть ответа, конечно, лежит в
практике DevOps – это было бы невозможно без эффективных и надежных систем
поставки, которые дают мгновенную обратную связь всякий раз, когда изменения в
коде не могут хорошо пройти интеграцию. Другой жизненно важный элемент
заключается в системной архитектуре, построенной из небольших, независимых
компонентов, которые можно развертывать и изменять независимо друг от друга.
60
Дорожные карты Spotify, несомненно, основаны на результатах. Принимая во внимание
уровень неопределенности, результаты могут быть представлены как ставки. Чем больше
ожидаемый эффект и чем меньше зависимость от непроверенных
предположений, тем лучше ставка.
83
Техническое отступление: эта идея не нова. В середине 90-х я работал в
инвестиционных банках, и в высококонкурентной среде того времени ведущие
банки разделили свои фронт-офисные торговые системы на распределенные
компоненты, их системы мидл-офиса61 быстро заняли нишу и начали
проникать в бэк-офисные системы. Эти компоненты обменивались
“self-describing messages”, которые асинхронно передавались через
"промежуточное ПО". Такая архитектура позволяла каждой системе
развиваться с наиболее подходящей для ее пользователей скоростью (сроки
разработки измерялись от нескольких часов до нескольких месяцев в
зависимости от характера деловой активности), позволяла масштабировать
системы в глобальном масштабе (глобальное управление рисками в режиме
реального времени было ключевым конкурентным преимуществом в то время),
а также давала значительные преимущества с точки зрения
производительности, устойчивости и доступности системы.
Чтобы проиллюстрировать влияние, которое такая архитектура может оказать

на организационную культуру, я вспомню, как разработчик фронт-офиса взял
на себя ведущую роль в многомесячном, проекте нескольких банков, который
внес значительные изменения в способ управления торговлей стоимостью в
миллиарды фунтов стерлингов. В нашем банке несколько команд
разработчиков были вовлечены в проект "наоборот". В нем несколько
менеджеров проектов работали не для того, чтобы координировать или
держать в тонусе нас, а чтобы управлять отношениями с коллегами в других
банках и с Банком Англии; все остальное мы делали сами. Это был мощный
урок того, чего может достичь маленькая самоорганизация в условиях
высокого доверия!
За четверть века технология продвинулась вперед, но принципы сохранились.

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

больше не являются прерогативой организаций с “глубокими карманами”,
архитектура остается важной дисциплиной. Скорость эволюции системы, а
также уровни производительности, отказоустойчивости, масштабируемости,
безопасности и адаптируемости – все это зависит от того, как организованы
компоненты и как они взаимодействуют (совсем как в человеческой
61
Мидл-офис в системной архитектуре – совокупность информационных систем, включая
базы данных и справочники, направленных на автоматизацию бизнес-процессов, связанных с
подготовкой и принятием решений.
84
организации!). Выбор технологий, возможно, менее критичен, чем когда-то, но
способ их использования по-прежнему имеет большое значение.
Итак, у нас есть отряды – небольшие, автономные, долгоживущие команды, каждая

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

со схожими навыками из отрядов одного клана. Лидер отдела – линейный менеджер
для членов отдела; он, в свою очередь, отчитывается перед лидером клана.
Рисунок 21. Отделы
Конечно, отделы нужны не только (или даже не в основном) ради структуры

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

модели Spotify. Они охватывают несколько кланов, соединяя людей, объединенных
общими интересами, укрепляя и распространяя культуру Spotify. Членство в гильдиях
85
несколько коррелирует с принадлежностью к отделам, но люди могут свободно
присоединяться к любой гильдии. Координаторы гильдий отвечают за то, чтобы их
гильдии служили потребностям ее членов и всей организации, в соответствии с их
сферой деятельности.
Рисунок 22. Гильдии
На диаграмме не показаны еще три роли, проявляющие приверженность компании

Spotify к совершенству инженерного дела и улучшению процессов:
● Владельцы систем – ответственные за архитектурную целостность каждой из

основных систем компании Spotify (отряды могут вносить изменения в
несколько систем).
● Главный архитектор – координирует архитектурные работы в нескольких

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

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

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

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

Термин "масштабируемые Agile фреймворки" описывает несколько брендированных
фреймворков, которые появились примерно за последнее десятилетие и
предназначены для помощи в масштабировании командно-ориентированного
процесса в одном или нескольких измерениях. Возьмем небольшой, но характерный
набор:
- Nexus™62, выделяющий единый бэклог продукта, одного владельца продукта,

несколько команд Scrum и интеграционную команда. Это модель горизонтального
масштабирования, способ для организации с основанной на Scrum поставкой
поддерживать устойчивые внешние отношения, даже если изменяется емкость
команд внутри организации.
- Scrum@Scale®63, который масштабируется "вверх" через механизм Scrum of Scrums

для создания иерархии Scrum команд.
- Scaled Agile Framework® (SAFe®)64, который делает акцент на периодическое

планирование на уровне проектных программ, иерархическую структуру работ, а
также скоординированные команды, работающие в объединении под названием Agile
Release Train (ART).
Матрица сравнения для гораздо более длинного списка фреймворков (почти все они
основаны на Scrum) поддерживается на сайте http://agilescaling.com. В этой книге
достаточно места для описания только одного фреймворка и я выбираю SAFe, не
потому, что я выделяю лучший из них, а по этим трем причинам:
1. Он широко известен и хорошо поддерживается.
2. По мере своего развития, он стал менее настойчивым в использовании Scrum

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

исследовал, этот наиболее явно предлагает интерпретацию «справа-налево».
Минимальная конфигурация SAFe

Опуская некоторые детали, я опишу основной процесс SAFe двумя способами,
придерживаясь взглядов “слева направо” и “справа налево”, которые я использовал
62
The Nexus™ Guide, http://www.scrum.org/resources/nexus-guide
63
Scrum@Scale®, http://www.scrumatscale.com/
64
Scaled Agile Framework® (SAFe®), http://www.scaledagile.com/
87
для Scrum в предыдущей главе. Первая версия – “слева направо” (или как не стоит
описывать SAFe, если вы хотите ему помочь):
● n уровней бэклога, где параметр n пропорционален высоте вашего плаката

SAFe65.
● Различные планирования событий переносят работу с одного уровня бэклога

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

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

явно поддерживая альтернативную интерпретацию “справа налево”66. Мое описание
ниже основано на модели итерационной самоорганизации вокруг целей, которую мы
использовали для Scrum в предыдущей главе:
● Команды продвигаются к цели от одной задачи к другой.
● Команды объединяются вокруг своих задач в циклах заранее определенной

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

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

предписания на использование Scrum в командах. Официально этот термин
называется "итерации".
Этот довольно обобщенный процесс окончательно превращают в SAFe эти два

элемента:
65
Я, конечно, шучу. Плакаты SAFe с многочисленными комментариями можно скачать с
http://scaledagileframework.com/posters/
66
Для ясности: я не предполагаю, что другие фреймворки не могут описываться справа
налево, только то, что они не демонстрируют это явно. Изменения в этой части, несомненно,
приветствуются.
88
1. Agile Release Train (ART), команда команд (как правило, состоящая из 50+
человек), которые имеют общее видение, систему поставки и
синхронизированные ритмы планирования, фасилитируемые Release Train
Engineer (RTE). Более крупные реализации SAFe могут иметь несколько ART с
координацией между ними на более высоком уровне.
2. Program Increment (PI) Planning, регулярный фасилитируемый воркшоп по

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

самый базовый вариант SAFe с очень Scrum-подобным двухуровневым бэклогом.
Более крупные версии SAFe добавляют уровни "Большого решения" и "Портфолио"
(здесь немного вводит в заблуждение термин "добавляют"; правильнее сказать, что
меньшие версии появились как урезанные варианты полной модели).
Откуда возникает критика? Большинство возражений относится к одной из пяти

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

окажется достаточно смелой или с достаточно “глубокими карманами” для
поддержки регулярного PI планирования.
2. Обеспокоенность по поводу сложности более крупных версий SAFe. Объем

справочного руководства SAFe 4.567 – 816 страниц, и даже его сокращенная
версия содержит 416 страниц68.
3. Обеспокоенность по поводу роста индустрии услуг, построенной для

поддержки этой сложности. Например, на момент написания книги, существует
не менее 10 сертификаций от Scaled Agile Inc, с глобальной сетью тренеров,
квалифицированных для проведения сертификационных тренингов, а над
ними – процесс обучения тренеров (Train the Trainer).
4. Озабоченность по поводу применимости – насколько кто-либо может быть

уверен в том, что внедрение SAFe действительно улучшит ситуацию?
5. Озабоченность по поводу того, как SAFe продается и внедряется, с

некоторыми подтверждениями неэтичного поведения.
Мои оставшиеся замечания я затрону в основном в связи с возражениями 4 и 5.

Разбираясь с вопросами применимости и внедрения я также затрону вопросы,
касающиеся практики и сложности – возражения 1 и 2. Что касается возражения 3, то
коммерческий успех дает определенное положительное подтверждение, но если
бизнес-модель сертификации по ролям позволяет SAFe доминировать на рынке
таким же образом, как Scrum доминирует в Agile для команд, то инновации неизбежно
страдают.
67
SAFe 4.5 Reference Guide: Scaled Agile Framework for Lean Enterprises, Dean Leffingwell
(Addison Wesley, 2018)
68
SAFe 4.5 Distilled: Applying the Scaled Agile Framework for Lean Software and Systems
Engineering, Richard Knaster and Dean Leffingwell (Addison Wesley, 2018)
89
Некоторые разногласия одновременно разрешаются и подпитываются девятью
принципами SAFe:
1. Смотрите с экономической точки зрения.
2. Применяйте системное мышление69.
3. Предполагайте изменчивость; оставляйте место для маневра.
4. Создавайте итеративно, со встроенными быстрыми циклами обучения.
5. Устанавливайте вехи на основе объективной оценки работоспособных систем.
6. Визуализируйте и ограничивайте WIP, уменьшайте размеры партий и

управляйте длиной очереди.
7. Применяйте каденции, синхронизируйтесь с кросс-доменным планированием.
8. Задействуйте внутреннюю мотивацию сотрудников.
9. Децентрализуйте принятие решений.
Это неплохой список; с небольшими оговорками я согласен со всеми пунктами. На

самом деле, достоверно известно, что многие из этих принципов принадлежат книге
Don Reinertsen, Principles of Product Development Flow70, широко известной в
Lean-Agile сообществе. Но, учитывая множество способов применения этих
принципов, вопрос, является ли SAFe хорошим выбором, имеет ответ только в
контексте.
SAFe, вероятно, будет плохим выбором, если применимо хотя бы одно из этих
условий:
1. Эти принципы уже применяются в некоторой разумной степени, и внедрение

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

достижения наибольшего влияния этих принципов в нынешней ситуации.
Эти критерии уже сами по себе должны заставить многих потенциальных покупателей
задуматься. Следовательно, часть противоречий проистекает из страха
(оправданного или нет), что SAFe будет продан в ситуации, когда он не принесет
пользы. Если лекарство не окажется хуже болезни, то вряд ли будет лучше некоторых
из доступных альтернатив. Тем не менее, остается значительный рынок
корпоративных клиентов, которые с удовольствием платят за энтерпрайз-решение
своих застарелых проблем. Размер этого рынка достаточен, чтобы объяснять
существование SAFe, не говоря уже о ее нескольких подражателях и конкурентах.
69
Thinking in Systems: A Primer, Donella Meadows (White River Junction, 2008)
70
The Principles of Product Development Flow: Second Generation Lean Product Development,
Donald G. Reinertsen (2009, Celeritas Pub)
90
Модели вовлеченности и проблемы, связанные с
переменами
Вы правы, если считаете, что я балансирую, стараясь не склоняться к одной из
сторон. Но, откровенно говоря, выбор конкретного фреймворка имеет гораздо
меньшее значение, чем подход организации к их принятию. Как мы видели в примере
с поставкой, к изменениям также можно подойти “слева направо” и “справа налево”.
Для начала, традиционный подход 20-го века к управляемым изменениям, “слева

направо”, управляемый готовыми решениями и ориентированный на внедрение:
● Выбирается решение – SAFe, в данном случае.
● Авторитетом или любым другим образом, создается обоснование срочности

применения.
● Решение развертывается согласно плану, наперекор сопротивлению

изменениям.
● Итог: разочарование в результатах, разобщение коллектива и осознание того,

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

Как может выглядеть подход к изменениям, основанный на подходе “справа налево”,
на потребностях и на результатах? Вот один возможный ответ – Agendashift71 с
ароматом SAFe:
● Установите общее представление о курсе, исследуя цель, задачи и ключевые

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

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

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

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

экспериментов (выбирая подход в зависимости от уровня неопределенности и
риска) начинайте относиться к изменению как к настоящей работе: отслеживая
71
Agendashift: Outcome-oriented change and continuous transformation, Mike Burrows (New
Generation Publishing, 2018); http://agendashift.com
91
его, подтверждая его воздействие и размышляя над ним так же, как
относились бы к работе над продуктом.
То, что я набросал в общих чертах – два очень контрастных вида модели
вовлеченности, две модели работы агентов изменений. Для эффективности в
пространстве организационных изменений, модель вовлеченности должна делать три
вещи:
1. Помогать в структурировании работы агентов изменений – фасилитаторов,

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

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

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

персонала. Наихудшие имеют обратный эффект – разобщение, и это реальная
проблема для Agile. В частности, большая часть негативного внимания направлена на
SAFe именно по этим причинам:
1. Модели вовлеченности некоторых крупных консалтинговых компаний

сосредоточены в основном на руководителях, которым по умолчанию
предлагают решение Spotify + SAFe, не обращая большого внимания на их
применимость и альтернативы. Некоторые из этих консультантов оставляют
работу по внедрению другим фирмам, таким образом избегая «ставить свою
шкуру на кон».
2. Когда консультанты предлагают полное сопровождение внедрения, все равно,

нормой считаются модели развертывания “слева направо”. Более того, такие
модели включены в тренинги SAFe для лидеров как основные, хотя и не
обязательные к прямому применению.
3. Вероятность что преобразованная производственная система останется

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

фреймворки. Если мой отказ рассматривать их как образцы для внедрения делает
меня диверсантом, что ж, это я переживу.
Более позитивен видимый сейчас расцвет того, что было прозвано Технологиями
Open Social (https://ru.wikipedia.org/wiki/OpenSocial). Это гораздо более широкий, более
разнообразный, но взаимодополняющий массив фреймворков, которые решают
92
целый ряд организационных проблем такими способами, которые недоступны
процессным фреймворкам. Они открыты во многих отношениях:
1. Они не только хорошо документированы, но и распространяются через

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

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

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

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

полномочиями по принятию решений, формируя социальный капитал вверх, вниз, по
всей организации и за ее пределами. Это описание как их непосредственного
использования, так и того организационного наследия, которое они, как правило,
оставляют после себя.
В частности, для моделей вовлеченности, эта внутренняя согласованность является
явной проектной целью, которая резко контрастирует с диссонансом и
разъединением, слишком легко провоцируемыми традиционными подходами к
изменениям.
Небольшой выбор соответствующих фреймворков, демонстрирующих эти свойства:
● Модели вовлеченности Agendashift и OpenSpace Agility™ (OSA) 73
72
"Основные или улучшенные" – отсылка к одному из “обязательств” из Основных протоколов
(Core Protocols (Jim McCarthy and Michelle McCarthy, www.mccarthyshow.com/online): “Я буду
придерживаться Основных протоколов (или лучших) в ситуациях, когда они применимы.”
73
Посмотрите вебсайт http://openspaceagility.com и книгу The OpenSpace Agility Handbook,
Daniel Mezick, Mark Sheffield, Deborah Pontes, Harold Shinsato, Louise Kold-Taylor, and Mark
Sheffield (Freestanding Press, edition 2.2, 2015)
93
● Чистый язык (Clean Language, Глава 5), который через Agendashift74 или сам по
себе ценится рядом участников сообщества Lean-Agile как протокол коучинга.
Его достояние, однако, связано с психотерапией – мощной демонстрацией
реакции на контекст, описанный в пункте 3 выше!
● Освобождающие структуры (Глава 6), библиотека фасилитационных

шаблонов, на которые также ссылается Agendashift.
● Крупномасштабный фреймворк Open Space Technology (OST, глава 6)
У организаций тоже есть потребности

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

организации-клиента, находящихся в процессе сознательного изменения, с
остальной организацией, для процветания всех сторон.
На прояснение того, что необходимо для процветания организаций и всех их частей,

ушли десятилетия исследований. Ключевые элементы включают в себя:
● Чувство идентичности и цели, обнаруженное, сохраненное и

подтвержденное.
● Стратегические процессы, определяющие будущие направления и цели, а

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

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

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

жизнеспособной системной модели (Viable System Model, VSM75), разработанной
Stafford Beer в 1960-х и 1970-х годах. Он искал универсальную модель
жизнеспособности и хотел избежать использования терминологии, которая могла бы
ввести в заблуждение. Он ссылался на вышеперечисленные процессы не по
общеизвестным названиям, по пронумерованным "системам" (Система 1, Система 2 и
т.д.). Его намерения были замечательны, но, к сожалению, сделали эту важную
модель весьма непрозрачной для посторонних. Поэтому, если вы хотите глубже
погрузиться в эту совокупность знаний, я бы направил вас в сторону чего-то
74
Модель вовлечения и открытый фасилитационный фреймворк, см.
https://www.agendashift.com/framework
75
Эту VSM, Viable System Model, не следует путать с VSM, которую мы видели в главе 1, Value
Stream Mapping.
94
доступного, и могу от всего сердца порекомендовать книгу Patrick Hoverstadt "The
Fractal Organization".76
Ключевой особенностью VSM является ее рекурсивная или фрактальная природа.

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

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

худшее из всех вариантов. Функциональные структуры имеют тенденцию:
● Распределять продуктовую и сервисную ответственность по нескольким

функциям.
● Скорее увеличивать, а не уменьшать трение с точки зрения клиента, продукта

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

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

стабильности. Когда организации, созданные по принципам разделения, пытаются
найти что-то новое или увеличить темпы развития, они быстро обнаруживают, что
организационные границы препятствуют потоку не только в процессах поставки, но и
в стратегии, решении проблем, а также в процессах инновации78. При наличии более
76
The Fractal Organization: Creating Sustainable Organizations with the Viable System Model,
Patrick Hoverstadt (John Wiley & Sons, 2008)
77
Мотивом для моего упоминания о разнообразии является мощная концепция кибернетика
Росса Эшби, а именно необходимое разнообразие. Неформально (без математики): “Чтобы
правильно решать разнообразные проблемы, которые мир бросает на вас, вам необходим
репертуар ответов, который (по крайней мере) столь же разнообразен, как и проблемы, с
которыми вы сталкиваетесь”. Источник: What is requisite variety, Dan Lockton,
http://requisitevariety.co.uk/what-is-requisite-variety/
78
The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail, Clayton M.
Christensen (Harvard Business School Press, 1997).
Оглядываясь назад, эта книга оказалась не только намного опережающей свое время, но и
катализатором нового мышления об инновациях.
95
гибкой конкуренции и, возможно, невидимых подрывных сил, кажущаяся сильной
структура может оказаться потенциально фатальным недостатком.
При этом, перестройка, какой бы необходимой она ни была, не панацея. Например,

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

которая хороша на бумаге, и организацией, которая действительно процветает. Это
активная, двусторонняя вещь: команды должны синхронизироваться с целями более
высокого уровня и иметь возможность участвовать в их создании. Во времена
быстрых изменений это еще важнее, когда применения Agile направлены только
внутрь и не в состоянии построить доверие извне, часто проявляется не только
сохранение существующих проблем, но и проявление новых потенциально серьезных
вопросов, по мере изменения взаимодействий, отношений и идентичности.
Конечно же, неверно обвинять организацию и ее менеджеров в том, что они начали
не с того места. Можно простить командно-ориентированным или ориентированным
на программное обеспечение Agile процессам недостаток предложений для компании
целиком (не говоря уже об адекватной теории для этого), но вы как цифровой лидер
не имеете такой роскоши. По мере того как вы решаете сложные вопросы, небольшая
трансграничная эмпатия может сильно развиться. Она поможет вам как в поиске
взаимопонимания, так и в поиске взаимовыгодных решений79’80.
Для конкретики и практичности, в следующей главе представлены некоторые

инструменты, умышленно ориентированные на внешние связи. Два из них в форме
циклов обратной связи, которые вы можете внедрить для дополнения, перезарядки
или замены некоторых ваших стратегий и процессов мониторинга. Оба инструмента
многоуровневые и не привязаны к конкретным фреймворкам. Вы можете
использовать их в выбранном вами фреймворке, сквозь границу вашего Agile контура
(если у вас она есть), или за его пределами.
79
Небольшие, но непропорционально громкие голоса части Agile сообщества имеют довольно
неловкие отношения с чем-нибудь, связанные с управлением. Их бесполезная, но стандартная
позиция -- обвинять менеджеров и их организацию в том, что они начали не с того места (и,
что еще хуже, предполагая плохие мотивы).
80
В своей книге "Сознательный капитализм" (о которой полностью говорится в следующей
главе) Джон Мэкки и Радж Сисода отмечают взаимосвязь между эмоциональным интеллектом,
системным интеллектом и духовным интеллектом. Без сомнения, эмпатия и системное
мышление (http://en.wikipedia.org/wiki/Systems_theory) могут взаимно дополнять друг друга
мощным образом; любое из них, практикуемое сознательно, может привести к другому. См.
также изученный оптимизм позитивной психологии
(http://en.wikipedia.org/wiki/Positive_psychology).
96
1. Как вы поддерживаете архитектурную целостность ваших ключевых систем в
условиях быстрых изменений? Аналогично, как вы поддерживаете
увлекательный и последовательный пользовательский опыт для пользователей
вашей продукции?
2. Как вы воспитываете в своих командах чувство предпринимательства?
3. Как вы поддерживаете уровень культурной согласованности во всей вашей

организации, соответствующий автономии каждого организационного
подразделения?
4. Как вы поддерживаете "итеративную самоорганизацию вокруг целей" за

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

в вашей организации?
6. Какие средства поощряют сотрудников к значимому участию в работе,

связанной с изменениями?
7. Что поддерживает конструктивное взаимодействие значительно изменяемых

частей организации с остальной ее частью во время изменений?
8. Каковы ваши организационные структуры и как они помогают клиентам и

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

Это важный день для Чандры, технического руководителя нашей команды в
“Springboard DIY”. Пришла ее очередь участвовать в ежеквартальном брифинге по
продуктовой стратегии компании, встрече, на которой она бывала раньше, но никогда
не выступала. Ее задача – дать стратегическое представление продуктовой области
своей команды.
Обычно это работа Роуэна, менеджера по продукту. Однако Чандра уверена в себе;
она и Роуэн – коллеги и они упорно работают сообща, чтобы каждый член команды
имел возможность внести свой вклад в стратегию, которая охватывает и объединяет
техническую и продуктовую области. Устная часть доклада не вызывает
беспокойства, так как большинство продуктовых совещаний проводятся по хорошо
отработанной схеме, которой она с удовольствием следует:
1. Клиент: обзор ключевых клиентских сегментов в продуктовой области,

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

миссией и стратегией Springboard, объясняющее влияние (намеренное или
нет) недавних, текущих и планируемых корпоративных инициатив.
3. Продукт: недавние, текущие и планируемые изменения в области продукта,

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

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

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

работает. Если она сможет сделать свое выступление последовательным и
убедительным, это добавит уверенности всем. И у нее это получится!
Что происходит?
После четырех глав, посвященных мышлению “справа налево”, в этой предпоследней
главе вводится концепция обзора “снаружи-внутрь” (и мы рассмотрим несколько
видов таких обзоров). Что происходит? Зачем нужна новая метафора?
В предыдущих главах речь шла о том, чтобы привнести в процесс реализации взгляд
“справа налево”, основанный на потребностях и ориентированный на результат –
естественный взгляд для Lean, здравый взгляд для Agile и признанную модель для
цифровых технологий. В двух последних главах мы отступаем от процесса
реализации и вводим две дополнительные и взаимодополняющие точки зрения,
которые меньше касаются процесса и больше – организации. Обе они тесно связаны
с темами, потребностями и результатами этой книги.
В этой главе «Снаружи внутрь», вместо того, чтобы прокладывать себе путь вверх по
потоку от ключевых моментов создания ценности, мы начинаем извне организации,
создавая целостное представление о потребностях, вызовах и ожидаемых
результатах. Затем мы углубимся на различные уровни, продвигаясь к сути этих
действий. На этом пути должны проявить себя любые организационные перекосы.
Мы затронем:
1. Обзор сервиса поставки “снаружи-внутрь” (Outside-In Service Delivery Review,

OI-SDR).
2. Обзор стратегии “снаружи-внутрь” (Outside-in Strategy Review, OI-SR).
98
3. Организационный устав NOBL.
4. Wardley Mapping.
Я выбрал эти инструменты (и разработал первые два) не потому, что они наиболее
известны, а потому, что они наиболее ясно демонстрируют точку зрения “снаружи
внутрь”. В сообществе Lean-Agile более известны Шаблон Бизнес-модели (Business
Model Canvas)81 и Шаблон Lean (Lean Canvas)82. Возможно, в свете этой главы, вы
захотите попробовать или заново оценить их.
Обзор сервиса поставки “снаружи-внутрь”

(The outside-in Service Delivery Review, OI-SDR)
В той или иной форме на протяжении нескольких лет я участвовал и проводил Обзор
сервиса поставки. Эта встреча прочно утвердилась в традиционных ИТ сервисах83 а
также, в основном благодаря сообществу Kanban, получает признание в кругах
разработчиков. С точки зрения системы, она поддерживает мониторинг и контроль, а
при правильном участии – управление и предвидение.
Вот как идея "снаружи внутрь" работает в этом окружении:
1. Клиент: что мы слышим от наших клиентов, через службу поддержки,

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

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

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

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

укомплектованность штата и эффективность процесса поставки.
81
78 The Business Model Canvas, www.strategyzer.com/canvas/business-model-canvas
82
79 The Lean Canvas, leanstack.com/leancanvas
83
Фреймворк управления IT сервисами ITIL (www.axelos.com/best-practice-solutions/itil)
называет эту встречу “Обзор сервиса”.
99
Такая структура может показаться несколько нетрадиционной, но позвольте мне
выступить в ее защиту с шестью заголовками: контекст, согласование, участие,
данные, обучение и выполнение:
Причина 1: Контекст
Поскольку он начинается за пределами организации, все, что происходит внутри ее
границ, рассматривается в правильном контексте. Значительно снижается риск
субоптимизации (технический термин для локальной оптимизации в ущерб целому).
Причина 2: Выравнивание
Любые противоречия, путаница, рассогласование или напряжение между "слоями" –
например, между клиентом и организацией или между продуктом и платформой будут
выставлены на всеобщее обозрение. Это может быть неприятно для
заинтересованных лиц, но процесс разрешения противоречий может стать
источником реального прогресса. Открытое принятие трудных решений может быть
весьма поучительным. Если политика становится прозрачнее, решения будет легче
принимать и, возможно, даже делегировать.
Причина 3: Участие
Каждый пункт повестки ведет человек или люди, лучше всего представляющие
текущую деятельность и знания в этой области. Например:
● Клиент: менеджер продукта или владелец продукта, исследователь

пользователей, дизайнер UX.
● Организация: руководитель высокого уровня и, возможно, другие

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

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

представители команд управления персоналом, если это соответствует
масштабу обзора.
OI-SDR не обязательно должен быть большим собранием. В моем первом собрании

участвовало всего шесть человек за небольшим столом в неформальной зоне для
встреч. Однако обратите внимание на возможность тесного взаимодействия между
людьми, представляющими не только несколько дисциплин, но и несколько
организационных уровней, включая тех, кого вы не ожидаете увидеть, скажем,
на ретроспективе команды или совещании команды руководителей. Я настолько
100
оценил этот аспект, что теперь специально ищу и планирую его – подробнее об этом в
главе 6.
Причина 4: Данные
Представители приносят данные в виде отдельных фактов (открытий, недавних
событий и так далее) и обобщенных метрик. Вместо того чтобы гнаться за
ограниченным набором "гарантирующих показателей", которые сами по себе дают
мало реального понимания, структура встречи предлагает широкий спектр:
● Клиент: Индекс потребительской лояльности (Net Promoter Score, NPS) или

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

соответствующих организационных целей и т.д.
● Продукт: Аналитика использования продукта; показатели воронки; сравнение

рынков.
● Платформа: Показатели производительности и мощности системы (наряду с

планами по поддержанию мощности на уровне, опережающем ожидаемый
спрос – еще одна веская причина для анализа со стороны); новые и уже
прорабатываемые возможности.
● Команда: Колебания времени производства (Lead time), производительности и

объема незавершенной работы (WIP) в любой комбинации (помните о законе
Литтла!); метрики качества (например, дефекты, дошедшие до клиентов);
данные о блокировках и их влиянии; уровень компетенций персонала;
распределение и развитие навыков.
Для некоторых участников OI-SDR может стать первым опытом сбора, интерпретации
и представления метрик. Поначалу он может показаться сложным, но это полезный
навык, который позволит отследить в метриках действия команды в ходе
последующих встреч. И это ключевой момент: здесь метрики не являются основой
систем вознаграждения или контроля (они почти неизбежно приводят к дисфункции,
если основаны на метриках84), а собираются и распространяются
самоорганизующимися командами в поддержку их собственной работы.
Хороший набор метрик сделает несколько вещей:
● Откроет окно в сервис эксплуатации и заблаговременно предупредит о

потенциальных проблемах.
● Даст исполнимые открытия (метрики, которые никогда не побуждают к

действиям, вряд ли стоят затрат на их подготовку).
84
см. книгу Measuring and Managing Performance in Organizations, Robert D. Austin (John Wiley &
Sons, 1996) – которая больше описание контроля здоровья организации, чем руководство по
дизайну!
101
● Покажет, как поведение системы меняется со временем – как в ответ на
вмешательство, так и на факторы, находящиеся вне непосредственного
контроля команды.
● Предупредит, когда погоня за какой-либо метрикой нанесет неприемлемый

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

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

за соответствие общего набора метрик потребностям всех участников. Это может
создать ценные возможности для коучинга при первом внедрении OI-SDR и при
появлении новых участников.
Причина 5: Обучение
OI-SDR предоставляет идеальную возможность для отслеживания хода
экспериментов. Открытия, полученные в результате краткосрочных экспериментов,
можно распространять сразу после их завершения; долгосрочные эксперименты
могут отслеживаться от собрания к собранию. Обзор экспериментов как часть каждого
пункта повестки дает эффект нормализации экспериментов, улучшений и инноваций,
делая их естественными аспектами ведения бизнеса. Устойчивые изменения через
подкрепленные системой ожидания это часть продуманного организационного
дизайна, и также это мощный сигнал о ценностях организации. Помните: в циклах
изменений нет ничего неизбежного – их нужно проектировать!
Очень легко поделиться открытием, полученным после эксперимента, и при этом

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

отвергнута идея продукта или улучшения:
Мы верили в <гипотезу>
но в ходе <активности> обнаружили.
что <понимание, открытие>
и отвергли эту идею.
Если бы мы попробовали <x>,

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

показывает существование несколько уровней обучения: одни сосредоточены на
выбранном предмете эксперимента, другие – на процессах, с помощью которых
85
http://en.wikipedia.org/wiki/Double-loop_learning
102
достигается понимание. Выполнение эксперимента в реальности помогает укрепить
идею о том, что каждый неудачный эксперимент или отвергнутая идея дают полезное
решение при условии эффективного управления – концепция, которую организациям,
избегающим риска, часто трудно принять.
Причина 6: Выполнение
В моем описании обзора сервиса поставки вы, возможно, заметили повторяющийся
паттерн: "недавний, текущий и запланированный". Это верно: OI-SDR работает не
только снаружи внутрь, но и справа налево! Вместо того чтобы рассматривать
действия или эксперименты в том порядке, в котором они были впервые озвучены
(классический рецепт бесконечно долгих и неэффективных встреч), мы фокусируемся
сначала на недавно выполненной работе (с фиксацией результатов и обратной
связи), а затем на работе, которую мы можем сделать в ближайшее время.
Приоритеты для предстоящей работы определяются в последнюю очередь, и всегда с
учетом возможностей.
При выборе отдельных вопросов или частей работы для обсуждения требуется
определенная дисциплина со стороны фасилитатора (и/или секретаря) и участников
встречи. Целью данного совещания не является рассмотрение каждого фрагмента
работы, но разумно ожидать перенос не обсужденных вопросов на последующие
совещания, если только не оговорено иное. Как правило, в повестку следует вносить
любой вопрос или рабочий элемент, который может растянуться на несколько встреч.
Именно эти элементы больше всего подвержены риску сбиться с пути. Согласовав
такие основные правила, вы вскоре выработаете эффективную схему, которая
позволит быстро охватить важные вопросы и довести их до окончательного
завершения.
Частота проведения таких встреч зависит от контекста. Мой собственный опыт

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

(The outside-in Strategy Review, OI-SR)
Идея подхода к стратегии “снаружи-внутрь” не нова. Вот, например, статья сотрудника
Forbes Wendy Tanaka в 2010 году "Ценность стратегии "снаружи-внутрь"86:
Предпосылка заключается в том, что постоянно успешные компании

начинают с ориентации на внешний рынок и бдительно изучают тенденции
клиентов для разработки своей стратегии. Это называется "внешним
86
The Value Of An 'Outside-In' Strategy, Wendy Tanaka,
http://www.forbes.com/sites/ciocentral/2010/12/01/the-value-of-an-outside-in-strategy/
103
мышлением", когда потребительские тенденции используются как
ориентир для разработки продуктов и услуг.
И наоборот, стратегия "изнутри наружу" – это стратегия, которая

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

стратегия без внимания к происходящему снаружи рискует оказаться провальной.
Наш вид обзора стратегии “снаружи-внутрь” (Outside-In Strategy Review, OI-SR) имеет
все преимущества OI-SDR – контекст, согласование и участие, но эти два обзора
следует рассматривать не как альтернативы, а как дополнение друг друга. OI-SR
задает иной набор вопросов. Как семинар, он имеет следующую структуру из 5
сессий:
1. Договоренность о времени.
2. Вопросы “снаружи-внутрь”.
3. От препятствий к результатам (From Obstacles to Outcomes, FOTO).
4. Структурирование плана.
5. Проработка вариантов.
Сессия 1. Договоренность о времени

Это легко – просто спросите! Сколько времени нам нужно, чтобы достичь чего-то
стоящего?
Этот же вопрос задается в Celebration-5W87 – упражнении, которое я часто использую

в качестве стартового на семинарах Agendashift. В двух словах: работая в группах за
столом, участники описывают Кто, Что, Когда, Где и Почему (“5 почему” журналистики)
празднует после применения стратегии:
● Кто мы, и кто еще будет праздновать вместе с нами.
● Что мы празднуем – достижения, которые принесет наша стратегия.
● Когда мы празднуем – сколько времени нам потребуется для достижения

чего-то действительно достойного празднования.
● Где мы празднуем – место, которое говорит о том, кто мы и чего мы достигли.
87
Celebration-5W доступен под лицензией Creative Commons Attribution-ShareAlike 4.0
International License; материалы расположены на http://agendashift.com/celebration-5w
104
● Почему мы празднуем – суть того, что делает все эти усилия стоящими.
Очевидно, что на вопрос "Сколько нам нужно времени?" отвечает часть "Когда", а
остальные части помогают подтвердить ответ.
Для этого упражнения не обязательно нужен причудливый шаблон – достаточно

простых заголовков на странице, но очень хорошо работает вариант, разработанный
моим другом Mike Haber (рис. 23). На этом шаблоне нужно начать с "Когда" (внизу
справа) и работать против часовой стрелки; чтение заполненного отчета читатели,
естественно, начнут слева вверху с "Кто" или в середине с "Почему".
Рисунок 23. Шаблон для Celebration-5W
Иногда спонсор стратегической сессии дает мне горизонт планирования заранее, как
часть вводных данных. Обычно мы соглашаемся, что было бы интересно услышать
мнение других, и все равно начинаем с упражнения Celebration-5W. Я не требую,
чтобы группы синхронизировали свои ответы после того, как поделятся своими
работами во время разбора после упражнения; работа в разных временных рамках
вносит дополнительное разнообразие, и это неплохо.
Сессия 2. Вопросы “снаружи-внутрь”

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

их стратегические потребности?
2. Организация: как устроена наша организация, какого она типа, когда мы

удовлетворяем эти стратегические потребности?
3. Продукт: с помощью каких продуктов и услуг мы удовлетворяем эти

стратегические потребности?
4. Платформа: когда мы являемся организацией такого типа, удовлетворяем эти

стратегические потребности, предоставляем эти продукты и услуги, каковы
определяющие/критические возможности, которые делают все это возможным?
5. Команда/команды: когда мы достигаем всего вышеперечисленного, какой тип

команды или несколько типов команд мы представляем?
Возможно, вы узнаете стиль этих вопросов. Это не совсем канонические вопросы

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

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

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

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

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

претендую на то, что это новейший прием в стратегии, основанной на
маневрировании, но это начало! Если вы заинтересованы в дальнейшем изучении
этой концепции, я рекомендую вам книгу "Patterns of Strategy", написанную в
соавторстве с моим другом и соавтором Patrick Hoverstadt88.
Оставшиеся вопросы можно просто рассматривать как есть, но для более

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

обществом и окружающей средой? (Эти важные темы будут вновь упомянуты в
главе 6 в связи с руководством через служение; см. также "Сознательный
капитализм"89)
● Какой организацией мы являемся в наших отношениях с деловыми,

экономическими и нормативными экосистемами, в которых мы работаем?
● Если взять эти вопросы вместе с нашими предыдущими ответами, то какой

организацией мы являемся?
Сессия 3. От препятствий к результатам (From Obstacles to

Outcomes, FOTO)
Вы нарисовали широкую картину того, куда бы вы хотели попасть; теперь вы должны
вернуться в текущую реальность и подумать о том, как двигаться дальше. Это
88
Patterns of Strategy, Patrick Hoverstadt and Lucy Loh (Routledge, 2017)
89
Conscious Capitalism: Liberating the Heroic Spirit of Business, John Mackey & Raj Sisoda
(Harvard Business Review Press, 2014)
107
классическая территория коучинга – рассмотрим, например, классическую модель
коучинга Джона Уитмора, GROW90:
● Цель (Goal): Чего вы хотели бы достичь, куда вы хотели бы попасть, как вы

хотели бы, чтобы все было.
● Реальность (Reality): как обстоят дела на самом деле?
● Варианты (Options): Как вы можете продвинуться дальше?
● Желание (или Действия) (Will or Way forward): Что вы обязуетесь сделать?
Перенося подобную структуру из персонального коучинга в фасилитацию семинаров,

мы используем 15-минутную коучинговую игру FOTO91, вдохновленную "Чистым
языком", FOTO – это сокращение от "От препятствий к результатам" (From Obstacles
to Outcomes). Очень кратко:
1. Группы за столами готовят и приоритизируют список препятствий, которые

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

Коуча, Записывающего и Наблюдателя. Клиент выбирает препятствие из
подготовленного списка, а коуч, используя Чистые вопросы из карты подсказок
(рис. 24), ведет беседу, исследуя мысленный ландшафт препятствий и
результатов клиента. коуч внимательно следит за тем, чтобы клиент говорил
своими словами, а записывающий записывает "все, что звучит похожим на
желаемый результат", при этом планка остается намеренно низкой, чтобы не
выбросить что-то преждевременно. Наблюдатель выступает в роли сотрудника
безопасности и следит за тем, чтобы разговор не отклонялся от курса, был
сосредоточен в основном на результатах, а не на непродуктивном копании в
препятствиях.
90
John Whitmore, Coaching for Performance: GROWing Human Potential and Purpose: The
Principles and Practice of Coaching and Leadership (Nicholas Brealey Publishing, 4th ed., 2010).
91
15-минутная FOTO: http://agendashift.com/15-minute-foto и Глава 1 книги Agendashift.
108
Рисунок 24. 15-минутная сигнальная карта FOTO
Какой бы подход к фасилитации вы ни выбрали, на этом этапе я настоятельно

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

Сессия 3 выдает много материалов; цель сессии 4 – организовать их для понимания и
реагирования другими людьми. Форматы могут варьироваться в зависимости от
количества полученных деталей, но вот подборка инструментов, которые я использую
чаще всего:
● Родственные группировки и голосование точками: Поместите все отдельные

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

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

структуру, в которой возникающие темы или пять слоев повестки дня "снаружи
внутрь" обозначены строками, а три временных горизонта – колонками. Наши
онлайн-ресурсы включают общедоступный шаблон92 (Рисунок 25):
Рисунок 25. Шаблон OI-SR
Сессия 5. Проработка вариантов

Последняя сессия – это возможность отработать некоторые шаги, которые будут
повторяться снова и снова по мере реализации стратегии (или, скорее,
развертывания – развертывание стратегии является темой для последней главы).
Здесь я кратко описываю четырехэтапный процесс, более подробно описанный в
главе 4 книги Agendashift, главе "Проработка":
Шаг 1. Выберите результат для проработки
92
Шаблон Обзора стратегии “снаружи-внутрь”(OI-SDR) доступен под лицензией Creative
Commons Attribution-ShareAlike 4.0 International License; материалы расположены на
http://agendashift.com/oi-sr-template.
110
Естественно, мы используем подход "точно в срок" и выбираем результат (или один
результат на группу столов), который мы хотим получить в ближайшее время;
остальные лучше оставить до тех пор, пока не придет их время. В основном для
наглядности мы просим участников ограничиться теми результатами, которые
открыты для нескольких возможных действий; мы знаем, что в таких случаях очень
уместен подход, основанный на гипотезах.93
Шаг 2: Придумайте несколько вариантов
Каждый участник самостоятельно (молча) генерирует два-три варианта – конкретные

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

по сравнению с ними и по отношению требуемых инвестиций? "Что должно
оказаться верным, чтобы этот вариант выглядел великолепно" 94
Шаг 4: Сформулируйте гипотезу
В этом шаблоне вариант формулируется как гипотеза:
Мы считаем, что <практические изменения>

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

предоставить по крайней мере три вида наблюдаемого воздействия – доказательства
того, что идея работает, как и ожидалось, в направлении выбранного результата.
Подсказки:
● Какие первые признаки вы могли бы увидеть?
● Что вам нужно увидеть, прежде чем вы скажете, что идея успешна?
Шаг 5: Разработать эксперимент
93
Мы исследуем вопрос целесообразности главе 2 книги Agendashift, черпая вдохновение и
фантастическое упражнение для воркшопа из модели Cynefin,
http://en.wikipedia.org/wiki/Cynefin_framework.
Если вы можете представить, что опрос пяти экспертов может легко породить десять идей, ни
одна из которых не будет полностью гарантировать ваш результат, то нетрудно понять, что вам
лучше использовать итеративный, основанный на экспериментах подход, вместо линейного
подхода, в котором единственное решение определено заранее..
94
Playing to Win: How Strategy Really Works, A.G. Lafley and Roger L. Martin (Harvard Business
Review Press, 2013)
111
Наконец, гипотеза перерастает в эксперимент, охватывая:
● Риски: возможное нежелательное воздействие.
● Потенциальные выгоды (или положительные риски): вещи, которые мы

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

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

листе бумаги формата А3. В мире столько же шаблонов А3, сколько и консультантов
по Lean, и вот мой, с местами для всех вышеперечисленных элементов:
Рисунок 26. Шаблон А3
112
Его можно скачать на страницах наших ресурсов95.
После того, как вы заполнили свой A3, полезно провести быструю перекрестную
проверку, которая поможет выявить пробелы. Проанализируйте различные
воздействия вашего эксперимента, представьте, какие выводы вы хотели бы получить
в (для них тоже есть место, хотя вы пока не можете его заполнять), а затем оцените
вашу уверенность, что пилотные эксперименты способны их обеспечить.
После того, как у вас есть приличный первый черновик, ваш следующий шаг –
показать его определенной вами репрезентативной выборке людей. Они будут
ожидать от вас четкого изложения ваших идей; в свою очередь, они помогут
проверить ваши мысли. В этом и заключается суть А3.
Искренняя организация
Два описанных мною обзора "снаружи внутрь" играют совершенно разные роли: один
помогает поддерживать прогресс в реализации стратегии, а другой намеренно
открывает ее для вызовов, и вместе с ней, возможно, и статус-кво. Один из важных
аспектов таких вызовов прекрасно сформулирован известным архитектором
Кристофером Александером:
"Целостность вещи зависит от того, насколько она свободна от

внутренних противоречий. Когда она находится в состоянии войны с самой
собой и порождает силы, стремящиеся разрушить ее, она нецелостна. Чем
более она свободна от внутренних противоречий, тем более целостной,
здоровой и искренней она становится"96.
Мне нравится идея того, что как лидеры и доверенные советники мы можем выбрать
деятельность, помогающую организациям быть более искренними – меньше воевать
с самими собой, выявлять и осознавать свои противоречия, чтобы их можно было
разрешить каким-то удовлетворительным способом. По аналогии, если мы улучшаем
наши процессы поставки, устраняя препятствия для потока, то наши организации мы
улучшаем, устраняя препятствия для выравнивания. Обзоры «снаружи внутрь»
специально разработаны именно с этой достойной целью, чтобы вывести на
поверхность несоответствия, препятствия и противоречия.
Однако, мы не должны принимать как должное, что это выравнивание будет хорошо
направлено. По сути, жизнеспособность любого организационного подразделения –
на любом уровне, от команды до всей организации – зависит от эффективности его
процессов (i) принятия решений о том, что важно, и (ii) обеспечения того, чтобы
работа подразделения была сосредоточена на правильных вещах. Если ваши
процессы недостаточно хороши (а это встречается гораздо чаще, чем вы думаете),
попробуйте использовать наши формы обзора стратегии и предоставления услуг
«снаружи внутрь» – сначала в качестве проверки или освежающего изменения
95
Шаблон Agendashift A3 доступен под лицензией Creative Commons Attribution-ShareAlike 4.0
International License; материалы расположены на http://agendashift.com/a3-template.
96
The Timeless Way of Building, Christopher Alexander (OUP USA, 1980). Несмотря на то, что эта
книга посвящена архитектуре и строительной среде, она стала ключевым источником
вдохновения для движения паттернов в программном обеспечении (а оттуда и для главы 3
этой книги) – см. http://en.wikipedia.org/wiki/Software_design_pattern.
113
перспективы, а затем для усиления или замены существующих совещаний по
вопросам управления.
Мы начинаем снаружи, чтобы создать возможность заново открыть и подтвердить

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

В завершении этой главы – краткое введение еще в два инструмента, которые можно
охарактеризовать как "снаружи внутрь". Первый из них разработан NOBL
(произносится "но-белл"), консалтинговой компанией, специализирующейся на
организационном дизайне, что для них означает применение Дизайн мышления к
организациям. Второй – Wardley Mapping, визуальный подход к стратегии,
разработанный Simon Wardley.
Организационный устав NOBL имеет следующую высокоуровневую структуру:
1. Цель: причина, по которой мы решили работать вместе неопределенное

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

наших стратегий.
4. Системы: инструменты, необходимые для согласования поведения в рамках

наших структур.
Очень похоже на наш Обзор стратегии снаружи внутрь. Очевидно, что каждый
элемент этой структуры связан со своими предшественниками. Также это означает,
что очень важно начать с правильного места. Здесь мы начинаем с цели, которую
NOBL любит раскрывать с помощью этих двух вопросов:
1. Что мы хотим изменить в мире и почему?
2. Как мы можем использовать наши коллективные навыки для осуществления

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

скачивания и руководство по его использованию можно найти в разделе "Как мы
описываем организацию",
http://academy.nobl.io/how-to-define-and-describe-an-organization/.
114
Wardley Mapping
Wardley Mapping97 – это всего лишь один инструмент из набора стратегических
инструментов, разработанных и открытых Simon Wardley. Идея очень проста, первые
два шага имеют много общего с подходом к построению карты потока создания
ценности, который мы рассмотрели в Главе 1:
1. Начните с потребности пользователя.
2. Работая в обратном направлении, нарисуйте цепочку создания ценности –

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

важными аспектами:
1. В отличие от потока ценности, основанного на деятельности, который мы

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

слева направо, мы строим ее сверху вниз. В верхней части цепочки
указывается потребность пользователя; под ней рисуется сеть зависимых
компонентов, элементы располагаются вертикально в зависимости от того,
насколько они видны пользователю – чем менее они видны, тем ниже на
странице они располагаются.
97
источник: Simon Wardley, An introduction to Wardley (Value Chain) Mapping,
http://blog.gardeviance.org/2015/02/an-introduction-to-wardley-value-chain.html, опубликован в
2015 году под лицензией Creative Commons 3.0 ShareAlike.
115
Рисунок 27. Цепочка создания стоимости для типового цифрового продукта98
Далее, сохраняя вертикальное положение, компоненты переставляются по

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

возможных решений.
3. Продукт (и аренда) – компоненты можно купить, продать, сдать в аренду или

взять в аренду; различные реализации сильно отличаются.
4. Товар (и обслуживание) – реализация очень легко доступна и

взаимозаменяема.
98
Рисунки 27 и 28 взяты с небольшими изменениями из статьи 2019 года Chris Adams, Plotting
a path to a greener web with Wardley mapping,
http://www.thegreenwebfoundation.org/news/plotting-a-path-to-a-greener-web-with-wardley-mapping
/. Статья описывает работу, проведенную в Green Web Foundation при поддержке German
Prototype Fund и опубликована под лицензией Creative Commons Attribution.
116
Рисунок 28. Карта Wardley Mapping для типового цифрового продукта
Например, в Springboard DIY электродрель – это товар, который нужно продать; их

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

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

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

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

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

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

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

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

становимся".
1. Как вам удается удерживать свои оперативные обзоры в надлежащем
контексте, соответствующем клиенту и организации?
2. Как вы поддерживаете соответствие между возможностями и перспективами

вашего организационного подразделения? Кто участвует в этом процессе?
Какие данные они приносят?
3. Что заставляет вашу организацию помнить о необходимости экспериментов?

Как она обеспечивает фиксацию и обмен опытом?
4. Как вы решаете, что отслеживать? Что обсуждается в первую очередь?
118
5. Вопросы "снаружи внутрь для периода вашего выбора в будущем:
1. Клиент: Что происходит, когда мы достигаем целевых клиентов,

удовлетворяя их стратегические потребности? (И: Кто эти
правильные клиенты, каковы их стратегические потребности, и
почему именно мы?)
2. Организация: как устроена наша организация, какого она типа, когда

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

стратегические потребности?
4. Платформа: Когда мы являемся организацией такого типа,

удовлетворяем эти стратегические потребности, предоставляем
эти продукты и услуги, каковы определяющие/критические
возможности, которые делают все это возможным?
5. Команда (команды): Когда мы достигаем всего вышеперечисленного,

какой тип команды (команд) мы представляем?
6. Как решаются внутренние противоречия вашей организации – между слоями

вопросов "снаружи-внутрь" или внутри них? С какими противоречиями вы
сталкиваетесь сейчас?
7. Какова цель вашей организации? Исследуйте это с помощью вопросов NOBL:
2. Как мы можем использовать наши коллективные навыки для

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

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

Роуэн и Чандра вернулись в офис Ники потрясенными. Чандра первая нарушила
продолжительное молчание:
Чандра: Совместное управление?
Ники: Вот именно!
Чандра: Но это так сложно!
119
Ники: Вовсе нет. Команды клиентского сервиса, которые сейчас отчитываются
мне, будут совместно отчитываться и вам. Все процессы управления
остаются прежними, и я настоятельно рекомендую ничего не менять в их
структуре, пока мы не увидим результаты. Суть в том, чтобы все могли
увидеть, что без вас двоих ничего не происходит в Цифровых системах, и,
если честно, вы сможете предложить коллегам много больше в своих
областях, чем я сейчас.
Роуан: А что насчет тебя?
Ники: Обо мне не переживайте! У меня останется еще много задач, в первую
очередь обеспечить вас всем необходимым для успешной работы. Честно,
это многое проясняет, и каждый, с кем я обсуждал этот вопрос, думает так
же. Мы говорим о более тесной интеграции с бизнесом, и благодаря ей у вас
появится возможность принять полноценное участие в обсуждениях.
Чандра: Мы должны договориться прямо сейчас?
Ники: Лучше это не откладывать, но сперва вам стоит обсудить это между собой.
Было бы здорово услышать ваше мнение о совместных приоритетах. Если
вы, конечно, на это согласитесь! Вам хорошо известны приоритеты
Springboard, но, полагаю, вы сможете их освежить.
Лидерство через служение

В пояснении к позиции Скрам Мастера, Скрам гайд дает косвенную отсылку к
Лидерству через служение: “лидер-слуга для Скрам Команды”, и далее перечисляет
различные, в основном специфичные для Scrum, способы, которыми Скрам Мастер
может служить Владельцу Продукта, Команде Разработки и Организации.
Но что же значит Лидерство через служение? Можем начать с интуитивных ответов,

например:
● “Служение людям” или “служение команде”.
● “Руководство через пример, правильную модель поведения”99.
● “Снятие всех блокеров и помощь в преодолении препятствий”.
Замечательные трактовки, но как определения лидерства они оставляют больше

вопросов, чем ответов. Поэтому мы обратимся к наиболее уважаемому источнику, по
совместительству моей самой любимой книге – Слуга в роли лидера Роберта К.
Гринлифа100. Название намекает на амбициозность, но одновременно это очень
99
Servant leadership: A path to high performance, Edward D. Hess, washingtonpost.com, April 28th
2013,
http://www.washingtonpost.com/business/capitalbusiness/servant-leadership-a-path-to-high-perform
ance/2013/04/26/435e58b2-a7b8-11e2-8302-3c7e0ea97057_story.html
100
Servant Leadership: A Journey into the Nature of Legitimate Power and Greatness, Robert K.
Greenleaf (Paulist Press, 25th Anniversary edition, 2002)
120
скромная книга, описывающая опыт практикующего квакера, который работал
поверенным в нескольких международных организациях.
Вот ее начало:
● Скоро люди перестанут посвящать всю жизнь одной компании и начнут

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

успеха, устраняя помехи и удовлетворяя базовые потребности.
2. Чтобы сохранить вовлеченность людей, Лидер-Слуга должен помочь другим

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

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

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

Лидер-слуга в первую очередь слуга, и только во вторую – лидер (оригинальный
термин звучит как Servant Leader, “Слуга Лидер” – прим. переводчика). Если лидер
не удовлетворяет потребности, его авторитет и легитимность его власти будут
слабеть, пока, в итоге, он не лишится всех последователей.
В своей замечательной книге Смелый Нью-Йорк101 Аарон Дигнан трактует Лидерство

через служение через понятия “позитив к людям” и “внимание к сложностям”:
● Позитив к людям, потому что необходимо фокусировать позитивное

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

организация может открыть себя и стать такой, какой ей нужно стать, не как
единовременный проект, а как бесконечное путешествие.
101
Brave New Work: Are You Ready to Reinvent Your Organization?, Aaron Dignan (Portfolio
Penguin, 2019)
121
Взглянуть на типы лидерства под углом Лидерства через служение, описанные в
Главе 1 – непростая, но стоящая задача. Перечислю их еще раз, чтобы облегчить
работу:
● Продуктовое лидерство, разработка и развитие продуктов, которые

попадают в ожидания целевых клиентов.
● Техническое лидерство, проектирование продуктов, которые могут

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

спросом.
● Процессное лидерство, нахождение более эффективных способов

эксплуатации и управления процессом поставки.
● Лидерство в изменениях, стимулирование изменений посредством

спонсорства, экспериментов, содействия, наставничества и координации.
● Лидерство в выполнении, устранение структурных препятствий,

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

препятствий вы обнаружите в “лучших практиках” 20 века, внедренных в управлении
HR, финансами, снабжением, в менеджменте юридических и проектных направлений
– практиках, несмотря на все заявления об обратном, будто специально созданных
для укоренения краткосрочных и индивидуалистических целей, подавления
стремления к инновациям и обучению.
И хотя они действительно создают серьезные преграды на пути Лидерства через

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

называемые “культурные вызовы” вашей организации отдельно от ее целей, надеясь
122
разобраться с ними позже – скорее всего, у вас ничего не выйдет. Вся эта книга и суть
Лидерства через служение говорят о том, что культуру и цели лучше разрабатывать
вместе и непрерывно.
Переворачивая пирамиду
Организационная диаграмма Хеншоу и МакКаллума 1855 года, отражающая структуру
управления железной дорогой “Нью-Йорк и Эри”, представляет собой непривычно
красивый артефакт, особенно на контрасте с типичными современными схемами. По
современным стандартам это как раз диаграмма “снизу вверх”, где внизу расположен
Совет директоров – “фонтанирующий источник силы” (я цитирую), – а из него
вырастает древо-подобная организация.102
В том, что сегодня метафора перевернутой пирамиды103 обладает мощным

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

обслуживает ее клиентов.
Визуально (Рисунок 29) СЕО изображается на нижней вершине треугольника, а

сверху, на его основании – персонал, работающий с клиентами. Любая структура,
размещенная между вершиной и основанием, имеет целью поддерживать верхние
уровни – те, что находятся ближе всего к клиенту.
Рисунок 29. Перевернутая пирамида
102
http://en.wikipedia.org/wiki/George_Holt_Henshaw#First_organization_chart
103
Или “перевернутая иерархия”, другое название перевернутой пирамиды. См.
https://en.wikipedia.org/wiki/Reverse_hierarchy
123
Мне очень нравится эта метафора, так что я поиграю с ней на Рисунке 30. Чтобы
сделать схему масштабируемой и применимой на любом уровне, я заменю СЕО на
процесс, Миссию, а взаимодействие с клиентами – на Поставку. Между этими двумя
процессами будет находиться Возможность. Ее цель – обеспечить этап Поставки как
индивидуальными возможностями, так и уровнем возможностей, необходимых для
выполнения его миссии. Наконец, добавлю немного привкуса Lean-Agile – три
организационных процесса, от Обнаружения до Подтверждения. Поскольку знания,
получаемые в ходе Обнаружения и Подтверждения, могут быть полезны для любого
процесса, я изображу их проходящими через все три слоя пирамиды.
Рисунок 30. Перевернутая пирамида (расширенная)
Обсудим подробнее:
● Поставка заключается в постоянном удовлетворении потребностей

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

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

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

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

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

(Глава 4), соответствующей определению Lean-Agile из Главы 2: стремление к
поддержанию потока, средства, чтобы справиться со сложностью, сотрудничество,
124
непрерывное обнаружение, поставка и обучение. Но модель не проясняет следующие
моменты:
1. Откуда берется адаптивность?
2. Возможно ли сотрудничество только в поставках?
Первый вопрос мы рассмотрим ниже – о том, как адаптивность следует из

конкретного поведения лидера. Такое поведение также способствует развитию
сотрудничества, но для ответа на второй вопрос мы вернемся к Главе 5, где мы
начали (но не закончили) рассматривать вопрос: кто участвует в каждом событии
принятия решений?
Переворачивая контроль
Поиск организационной адаптивности – не новое веяние. Наверняка вам знакомо
выражение “Ни один план действий не выдерживает встречи с противником”. Это
сокращенная версия, а вот полная цитата: “Ни один план действий не может с
какой-либо степенью определенности выходить за пределы первого столкновения
с главными силами противника”. Эти слова были написаны в 1871 году Хельмутом
фон Мольтке Старшим, генералом-фельдмаршалом прусской армии.
Фон Мольтке ухватил самую суть этой фундаментальной проблемы – как может
организация быть успешной, если предварительное планирование такое хрупкое? Он
нашел решение в подготовке лидеров на каждом уровне, чтобы минимизировать
слепое следование детальным инструкциям, которые, практически гарантированно,
быстро потеряли бы смысл. Наоборот, команды формулировались как заявления о
намерениях и описания ожидаемых результатов, к которым должны стремиться
подчиненные. Благодаря этой совершенно новой военной доктрине, получившей
название “децентрализация командования”, Фон Мольтке добился немыслимого
ранее примирения: согласования общих целей с автономией на местах. Эта
комбинация выручала людей даже в самых экстремальных обстоятельствах104.
Перенесемся вперед на 150 лет и предположим, что намерения транслируются не

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

через служение. Полномочия явно передаются той части организации, которая
обладает релевантной информацией, никаким образом не лишая при этом старших
104
The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results, Stephen
Bungay (Nicholas Brealey Publishing, 2011). Автор – одновременно управленческий консультант
и военный историк, его работа широко известна в Lean-Agile сообществе..
125
руководителей их обязанностей. В то же время персоналу и экипажу (Д. Марке был
капитаном подводной лодки ВМФ США) предлагается высказаться о своих
намерениях, что является явным стимулом для самоуправления и самоорганизации
на индивидуальном и командном уровнях. Со временем появляется привычка
“работать вслух”, почти непрерывный поток заявлений “Я намерен сделать…”,
которым уже не нужен вспомогательный вопрос “Что вы собираетесь сделать?”.
Самоорганизованность развивается спонтанно, в ответ на поставленные цели и
адаптируясь к новым обстоятельствам105 106.
Короче говоря: адаптивность это функция легкости и частоты самоорганизации. Ее

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

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

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

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

что значительно упрощает ее применение в менее иерархической обстановке. Все,
что требуется, – это осознанная коммуникация. К примеру, вопрос “Что вы
собираетесь сделать?” работает в разных коучинговых ситуациях – это классический
способ подвести итог коучинговой сессии. Если говорить о цифровом контексте,
осознанная коммуникация выглядит так:
105
Turn the Ship Around! A True Story of Turning Followers into Leaders L. David Marquet (Portfolio,
2013)
Русскоязычный перевод: Разверните ваш корабль. Жесткий менеджмент от капитана
лучшей подводной лодки США, Дэвид Марке (Манн, Иванов и Фербер, 2013)
106
Модель “лидер-лидер” можно встретить как представление Лидерства через
служение в том что менеджмент называет “выгодной сделкой”. Очевидно, что для
менеджеров бесполезно (или вредно) ставить цель без разумного учета ресурсов,
необходимых для ее достижения. Так же расточительно игнорирование возможности
автономии и роста .
126
● Продуктовая стратегия описывается языком потребностей и результатов
(прежде всего потребностей и результатов клиентов), не прописывая детали до
последнего момента готовности ее раскрытия “точно в срок”.
● Технологическая стратегия формулируется аналогичным образом, через

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

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

последовательных и привычных выражениях намерений, достаточных для того,
чтобы:
1. Коллеги могли поддерживать, направлять, проверять, отвечать и реагировать и

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

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

предыдущей главы. Напомню, на повестке нашей OI-SDR встречи было пять пунктов
– Клиент, Организация, Продукт, Платформа и Команда. Далее, в качестве
фасилитатора этой встречи, я искал тех, кто наиболее подготовлен, чтобы взять на
себя по одному из этих пунктов. Вот как распределились аспекты и роли людей,
принявших участие в той встрече:
● Клиент: Владелец продукта и UX-исследователь.
● Организация: Менеджер сервиса.
● Продукт: Владелец продукта (снова).
● Платформа: Технический руководитель и Руководитель технической

поддержки.
● Команда: Менеджер поставки (я).
Всего шесть человек, один из них – Владелец продукта – появляется дважды. Должен
заметить, что UX-исследователь отчитывается Владельцу продукта, Руководитель
технической поддержки – Техническому руководителю, а самое старшее звание из
127
перечисленных было у Менеджера поставки (гибридная роль на стыке бизнеса и
технологий, встречающаяся во многих государственных компаниях Великобритании).
Из этого и других успешных кейсов я сформулировал “Правило Трех” – эмпирически

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

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

появляются доказательства! Информация быстрее передается, а качество решений,
принимаемых на ее основании, повышается. Никто не ищет виновного, информация
не искажается, участники получают возможность оставаться верными фактам и
самим себе.
Если взглянуть на эту OI-SDR встречу через модель Spotify, можно увидеть сразу
несколько отделов – как правило с вовлечением руководителей отделов и небольшим
количеством других сотрудников. Можно предположить, что представители отделов
также представляли свои Гильдии (на самом деле так зачастую и было, хотя мы
зовем их сообществом заинтересованных сторон, и эти сообщества выходили за
пределы нашего государственного учреждения, работая с другими учреждениями и
ведомствами107).
Интересный факт – существует более старая, но менее известная организационная

модель управления, с помощью которой я смог лучше формализовать свою:
Социократия, идея 19 века, испытанная и получившая дальнейшее развитие в
общественных и корпоративных условиях, начиная с середины 20 века108.
Социократия основывается на четырех принципах:
1. Информированное согласие: Решения принимаются не путем навязывания,

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

группа людей с общей миссией и ответственностью за область, которая
107
Смотрите Building Successful Communities of Practice: Discover How Connecting People Makes
Better Organisations, Emily Webber (Blurb, 2018). В прошлом, Эмили была Head of Agile Delivery
в “Глобальной системе бронирований” (GDS).
108
We the people: Consenting to a Deeper Democracy, John Jr. Buck, Sharon Villenes
(Sociocracy.info Press, second edition, 2019)
128
является предметом интереса для бизнеса. Круги могут создавать новые круги,
более низкого уровня, для управления узкой поддоменной областью, или
более высокие стратегические круги. Важно отметить, что люди могут
принадлежать сразу к нескольким кругам.
3. Двойная связь: Круги связаны друг с другом (Рисунок 31), в идеале, как
минимум, через двух людей, один из которых является оперативным
руководителем нижестоящего круга, выбранным вышестоящим кругом, а
другой или другие – представители нижестоящего круга, избранные чтобы
представлять их в вышестоящем круге.
4. Выборы по согласию: Принцип информированного согласия применяется к

процессам вступления людей в круги и к процессу создания новых кругов; в
конечном итоге, каждый человек находится в своих кругах по своему согласию.
Рисунок 31. Двойная связь
В случае с OI-SDR мы не пытались построить Социократию, но результат оказался

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

Владельцем продукта во главе.
2. Технический круг включал разработчиков и UX-исследователя (также

входившего в Продуктовый круг), Технического руководителя и Руководителя
технической поддержки.
129
3. Круг по обзору Сервиса поставки выступал в роли стратегического круга для
наших объединенных команд и всего Сервиса в целом; я как Менеджер
поставки был в нем фасилитатором, официально его возглавлял
Сервис-Менеджер.
4. Цифровой круг охватывал не только наш сервис, но и несколько других.

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

практиков.
Все круги имели двойную связь друг с другом, за исключением, возможно, сообществ
практиков. И хотя мы тогда не знали о правиле двойной связи, мне кажется разумным
утверждать, что это был тот механизм, с помощью которого было соблюдено мое
“Правило Трех”.
Рисунок 32. OS-SDR в интерпретации социократической модели управления
Но три – не предел! Во времена управления международным департаментом из сотни

человек моей основной рутинной деятельностью был ежедневный производственный
звонок в удобное для Европы и США время (Азия, Австралия и небольшое количество
участников из Европы созванивались отдельно). Обычно на связь выходило не
меньше трети сотрудников департамента – представителей четырех уровней
иерархии (международный, региональный, руководители и участники команд). Для
соблюдения процедуры нам было достаточно и меньшего числа, но многие регулярно
принимали участие по собственному желанию или эпизодически, если вопросы
касались их прямых интересов.
130
В третий и последний раз обращусь за примерами к военной тематике: генерал
Стэнли МакКристал в книге “Команда команд”109 описывает ежедневные
военно-оперативные встречи во время кампании против Аль Каиды в Ираке.
Радикально прозрачные для своего времени, эти встречи включали не только
представителей нескольких видов вооруженных сил, но также разведки и
дипломатических корпусов разных стран. Во время видеозвонка на сотни человек
генерал по имени обращался ко всем участникам, которых представлял или
благодарил, даже если человек был на восемь рангов ниже его самого, что было
крайне непривычно для окружающих. В ходе совещания обсуждали и подвергали
перекрестной проверке данные разведки, координировали работу автономных групп.
Структурированное участие в масштабировании

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

организационному обучению, – это внедрение стратегии (известная также под
японским термином "hoshin kanri"), проведение различного рода семинаров и
"Открытое пространство" (или "Технология открытого пространства", ТОП).
Рассмотрим их по очереди.
Структура 1. Внедрение стратегии.

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

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

смежным кругам, так передавая его дальше до операционных кругов.
109
Team of Teams: New Rules of Engagement for a Complex World, General Stanley McChristal,
with David Silverman, Tantum Collins, Chris Fussell (Portfolio Penguin, 2015)
131
● Ответы возвращаются не только в форме планов действий, но и в виде нового
осознания проблемы, что потенциально может привести к ее переосмыслению.
Чем больше кругов накладываются друг на друга и чем быстрее проходят итерации
внешнего и внутреннего сотрудничества, тем быстрее развивается стратегия и тем
ближе к ней выстраивается работа каждого. Адаптируемость в масштабе развивается
не строго "сверху вниз" и не "снизу вверх". Направление зависит от правильных
выборов, которые происходят на правильном уровне в нужное время, для которых
постоянно создаются возможности во взаимодействии внутри кругов и между ними,
основываясь на том, как они работают, как они управляют собой, как они
совершенствуются и как они взаимодействуют.
Структура 2. Воркшопы
Предположение, что проблему можно решить с помощью воркшопа, не всегда
приветствуется. Безусловно, плохо организованные воркшопы могут быть
некомфортными и непродуктивными для всех участников. Однако, на практике они
могут быть и приятными, и высокоэффективными.
Хорошие впечатления от воркшопов – следствие хорошей к ним подготовки. Работа

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

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

смысле, что одна и та же модель может быть перенесена из одного контекста в
другой, решать разные наборы проблем, и достаточно надежно производить
радикально отличающиеся, но настолько же ценные результаты. Для
110
The Surprising Power of Liberating Structures: Simple Rules to Unleash A Culture of Innovation,
Keith McCandless & Henri Lipmanowicz (2014, Liberating Structures Press); также смотрите
http://www.liberatingstructures.com
111
Facilitator's Guide to Participatory Decision-Making, Sam Kaner, (Jossey-bass Business &
Management Series, 3rd edition, 2014).
Русскоязычное издание: Руководство фасилитатора. Как привести группу к принятию
совместного решения, Сэм Кейнер (Издательство Дмитрия Лазарева, 2018)
132
специалистов-практиков после повторяемости приходит передаваемость, при которой
способность фасилитировать повторяющиеся воркшопы передается другим людям,
распространяя использование их в рамках организации или сообщества практиков на
пользу гораздо большего числа людей. Успешная передача это демонстрация
индивидуальной и межличностной компетентности и лидерства; для организации это
возможность быстрого распространения культурных, технических и стратегических
идей.
После передаваемости появляется воспроизводимость – особенность, упомянутая в

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

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

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

Открытое пространство, а точнее – Технология открытого пространства, была
описана в 1980-х годах Харрисоном Оуэном115. Она черпает вдохновение из
разговоров в кулуарах, которые часто могут стать изюминкой конференции; из этого
появляется метафора крупномасштабного семинара, который ненавязчиво, но
осознанно фасилитируется.
112
Design Sprint: A Practical Guidebook for Building Great Digital Products, Richard Banfield, C.
Todd Lombardo & Trace Wax (O'Reilly Media, 2015)
113
See Sprint: How to solve big problems and test new ideas in just five days, Jake Knapp, John
Zeratsky, Braden Kowitz (Bantam Press, 2016); эта книга описывает использование Дизайн
спринтов для стартапов в портфолио Google Ventures.
114
http://en.wikipedia.org/wiki/Replication_crisis
115
Open Space Technology: A User’s Guide, Harrison Owen (Berrett-Koehler Publishers, 3rd edition,
2008)
133
При правильном применении Открытое пространство подразумевает гораздо больше,
чем размещение нескольких одиноких флипчартов в свободной аудитории (довольно
разочаровывающая реальность на некоторых конференциях). Оно подразумевает:
1. Определение контекста – возможно, бизнес-задачи.
2. Фасилитирование зарождения программы, дающее участникам возможность

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

или в опубликованных материалах.
Фасилитаторов и участников направляют определенные ключевые принципы:
1. Кто бы ни пришел – это нужные люди.
2. Когда бы ни началось – это нужное время.
3. Где бы ни началось – началось в нужном месте.
4. Что бы ни случилось – это единственное, что могло бы случиться, будьте

готовы удивляться.
5. Когда все закончится, все закончится (в этой сессии).
И последнее, но не менее важное: Открытое пространство действует в соответствии с

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

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

В работе, иногда называемой "книгой Agile BOSSAnova"116, Ютта Экштейн и Джон Бак
используют Открытое пространство, само по себе построенное на метафоре, как
способ понять Agile в максимально широком организационном контексте.
Аналогичным образом, Лидерство через служение и Open Space могут быть
объединены, чтобы описать возможности для упрощения работы в перевернутой
организации, которая также отличается высокой степенью сотрудничества и
адаптивности:
116
Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy: Survive & Thrive on
Disruption, Jutta Eckstein и John Buck (CreateSpace Independent Publishing Platform, 2018)
134
1. Помогать другим быть успешными, устраняя препятствия для
сотрудничества "нужных людей, в нужное время, в нужном месте". Чтобы
максимизировать возможности для эффективного внутреннего и
межгруппового сотрудничества, лидеры обращают внимание на определенные
стимулирующие ограничения, такие как планы встреч (которые всегда
остаются открытыми для экспериментов), временные рамки и
организационные границы (уважаемые по причинам идентичности и
согласованности, но все же проницаемые ради пользы и всегда открытые для
адаптации).
2. Помогать другим обрести самостоятельность и смысл в своей работе,

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

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

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

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

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

собрал вопросы из Размышлений каждой главы в Приложении А, а также на сайте
http://agendashift.com/surveys/right-to-left.
Включая заключительный набор вопросов для данной главы, получилось 50

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

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

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

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

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

работала в своей лучшей форме?117
2. Чем это отличается от того, что происходит сейчас?
3. Какие препятствия стоят на пути?
4. Что бы вы хотели, чтобы случилось?
5. Что произойдет потом?
6. Снова (и, возможно, еще раз), что произойдет потом?
С помощью этого процесса – упрощенной формы 15-минутной FOTO (Глава 5) вы

сможете получить некоторые результаты. Возможно, одни легко достигаемые, другие
– труднее. Теперь представьте, что вы повторите весь этот процесс, начиная с анкеты,
но на этот раз совместно с другими участниками, так что согласие по результатам
может стать основой для реальных изменений.
117
Фраза "работать в лучшей форме" вдохновлена книгой From Contempt to Curiosity: Creating
the Conditions for Groups to Collaborate Using Clean Language and Systemic Modelling, Caitlin
Walker (Clean Publishing, 2014); см. также Agendashift True North http://agendashift.com/true-north
136
Будете ли вы координатором этого процесса или кто-то еще, я надеюсь, что
перспектива окажется для вас захватывающей!
1. Как лидеры всех видов в вашей организации:
1. Помогают другим быть успешными?
2. Помогать другим обрести самостоятельность и смысл в работе?
3. Помогают развивать эти лидерские качества у других?
2. В какой степени вашу организацию можно охарактеризовать как

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

направлениях?
4. Как ваша организация поддерживает достоверность в своей деятельности по

управлению?
5. Как ваша организация поощряет участие в разработке стратегии?
Приложение А. Объединенные размышления

из каждой главы
Как написано в разделе “Запуск или оживление трансформации” Главы 6, здесь
собраны все 50 вопросов из окончаний каждой главы книги. Также они доступны в
форме онлайн-опроса по адресу http://agendashift.com/surveys/right-to-left.
Повторю рекомендации из Главы 6:
● Проход по списку не должен занять много времени – вместо попытки ответа на

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

организации отвечать на эти вопросы и качеству ответов. После завершения
шести разделов (по одному для каждой главы) у вас будет возможность
просмотреть полный набор и выделить все вопросы, которые вы хотели бы
отметить как приоритетные для последующего рассмотрения.
137
Lean как “Стратегическое стремление к потоку, целенаправленный процесс
организационного обучения”:
1. Как вы понимаете те "ключевые моменты создания ценности", которые

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

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

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

координируется со своими контрагентами вверх по потоку, чтобы их
потребности были удовлетворены вовремя?
5. Как бы выглядела "стратегия эффективности потока" для вашей

организации? Что бы ее поддерживало?
6. Где и как 7 потерь Lean – транспорт, запасы, движение, ожидание, чрезмерная

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

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

Lean-Agile как “Стратегическое стремление к потоку в запутанной (Complex)
среде. Организация, придающая большое значение сотрудничеству, непрерывной
поставке, адаптации и обучению”:
1. Как ваша организация по разработке продуктов способствует сотрудничеству,

как внутреннему (внутри и между командами), так и внешнему (в первую
очередь с клиентами)?
2. Что ваша организация по разработке продуктов понимает под термином

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

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

разработке продукта?
6. Насколько правее закреплена валидация вашего потока создания ценности

при разработке продукта? Какие формы принимает эта валидация?
7. Какие “upstream” активности обеспечивают процесс разработки продукта

работой с высокой ценностью? Как лучшие идеи попадают в начало очереди?
8. Как вы управляете работой вне (а не внутри) процесса разработки продукта?
9. Как вы распознаете, смягчаете и устраняете "неэффективности потока":

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

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

сотрудничества"? Как такая формулировка может вам помочь?

Фреймворки, “важные и легко распознаваемые особенности ландшафта Lean-Agile”
– как “сочетающиеся шаблоны для интересных комбинаций”:
1. Как вы мобилизуете самоорганизацию и сотрудничество вокруг цели? Как вы

заставляете этот процесс надежно повторяться для достижения более
долгосрочных целей?
2. Как вы предотвращаете тенденции “слева направо” (ожидания линейных и

принудительно внедряемых процессов, с заранее принятыми
обязательствами) от доминирования в контекстах, где был бы более уместен
подход “справа налево” (ориентированный на результат, итеративный и
своевременный)?
3. Как вы убеждаетесь в том, что команды сохраняют ясное ощущение цели?
139
4. Как вы удерживаете размеры команд достаточно небольшими для
управляемости, но с необходимым для самостоятельности набором навыков и
возможностей?
5. Каким образом механизмы управления на уровне команды взаимодействуют с

управлением на уровне организации?
6. Какими конкретными способами вы поддерживаете внимание на потоке во всей

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

высокой обратной связью?
8. Как вы обнаруживаете, идентифицируйте, исследуете, схватываете,

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

снижающие общую эффективность процесса развития вашего продукта?
10. Как ваша организация добивается соответствия продукта рынку? Какими

механизмами она поощряет эксперименты и обучение?

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

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

организации, соответствующий автономии каждого организационного
подразделения?
4. Как вы поддерживаете "итеративную самоорганизацию вокруг целей" за

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

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

частей организации с остальной ее частью во время изменений?
8. Каковы ваши организационные структуры и как они помогают клиентам и

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

Обзоры сервиса поставки “снаружи-внутрь” (OI-SDR) и стратегии “снаружи-внутрь”
(OI-SR); прочие инструменты, такие как Организационный устав NOBL и Wardley
Mapping:
1. Как вам удается удерживать свои оперативные обзоры в надлежащем

контексте, соответствующем клиенту и организации?
2. Как вы поддерживаете соответствие между возможностями и перспективами

вашего организационного подразделения? Кто участвует в этом процессе?
Какие данные они приносят?
3. Что заставляет вашу организацию помнить о необходимости экспериментов?

Как она обеспечивает фиксацию и обмен опытом?
4. Как вы решаете, что отслеживать? Что обсуждается в первую очередь?
5. Вопросы "снаружи внутрь для периода вашего выбора в будущем:
1. Клиент: Что происходит, когда мы достигаем целевых клиентов,

удовлетворяя их стратегические потребности? (И: Кто эти
правильные клиенты, каковы их стратегические потребности, и
почему именно мы?)
2. Организация: как устроена наша организация, какого она типа,

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

эти стратегические потребности?
4. Платформа: Когда мы являемся организацией такого типа,

удовлетворяем эти стратегические потребности, предоставляем
эти продукты и услуги, каковы определяющие/критические
возможности, которые делают все это возможным?
5. Команда (команды): Когда мы достигаем всего вышеперечисленного,

какой тип команды (команд) мы представляем?
141
6. Как решаются внутренние противоречия вашей организации – между слоями
вопросов "снаружи-внутрь" или внутри них? С какими противоречиями вы
сталкиваетесь сейчас?
7. Какова цель вашей организации? Исследуйте это с помощью вопросов NOBL:
2. Как мы можем использовать наши коллективные навыки для

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

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

Лидерство через служение, перевернутая организация и участие:
1. Как лидеры всех видов в вашей организации:
1. Помогают другим быть успешными?
2. Помогать другим обрести самостоятельность и смысл в работе?
3. Помогают развивать эти лидерские качества у других?
2. В какой степени вашу организацию можно охарактеризовать как

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

направлениях?
4. Как ваша организация поддерживает достоверность в своей деятельности по

управлению?
5. Как ваша организация поощряет участие в разработке стратегии?
Как только вы просмотрите весь список и отберете несколько наиболее актуальных

вопросов, возвращайтесь к разделу "Двигаясь дальше" главы 6.
Приложение Б. Мой вариант…

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

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

удовлетворения возросших ожиданий людей.
~ Tom Loosemore, Definition of Digital, http://definitionofdigital.com
Цифровой лидер:
Любой, кто видит в цифровых технологиях возможность лучше обслуживать своих

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

консультантов, тренеров или сотрудников, в сферу компетенции которых
входит стимулирование изменений.
2. Помогать организации-клиенту целенаправленно вовлекать своих сотрудников

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

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

обучения
(Modig & Åhlström’s This is Lean and its “a strategy of flow efficiency”)
Lean (более длинная версия):
Стремление к потоку как стратегической необходимости, открытое и управляемое

предназначением старание, которое постоянно и целенаправленно вовлекает людей
на каждом уровне организации в процесс обучения.
143
Lean-Agile:
Стратегическое стремление к потоку в запутанной (Complex) среде. Организация,

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

работая внутри организации сквозь её уровни возможности. Для создания и
поддержания согласованности предназначены соответственно внешний обзор
стратегии (OI-SR, Outside-In Strategy Review) и внешний обзор предоставления услуг
(OI-SDR, Outside-In Service Delivery Review).
“Справа налево”:
Сосредоточение всего процесса на потребностях и результатах в сочетании с

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

before means), видения до деталей, "почему" перед "что", "что" перед "как" и так
далее. It can also mean considering outputs before inputs, but give me outcomes over
outputs, every time..
Правило трех:
"Устройте свои совещания по стратегии и управлению так, чтобы они предполагали

активное участие по крайней мере трех уровней руководства. Включайте
представителей различных дисциплин, которые ставят шкуру на кон и которых
уважают за непосредственное знание ситуации".
“Вверх ногами”:
Лидерство через служение в перевернутых иерархиях:
● Организация существует для поддержки тех, кто обслуживает ее клиентов.
● Полномочия по принятию решений перешли к тем, кто обладает наиболее

значимой информацией (Дэвид Марке).
Как описано в главе 6 и у Robert K. Greenleaf, легитимность лидера-слуги зависит от

этих трех видов деятельности:
1. Помогать другим быть успешными.
2. Помогать другим обрести самостоятельность и смысл в своей работе.
3. Помогать другим развить в себе Лидерство через служение.
144
Искренний:
"Я предпочитаю помогать организациям быть более искренними – меньше воевать с

самими собой, выявить и признать свои противоречия, чтобы справиться с ними
приемлемым способом. По аналогии, если мы улучшаем наши процессы доставки,
устраняя препятствия для потока, то мы улучшаем наши организации, устраняя
препятствия для выравнивания".
Как выясняется в главе 5, искренность вдохновлена цитатой из книги The timeless way
of building, Christopher Alexander.
145
Материалы
Как отмечено во Введении:
● Домашняя страница этой книги: http://agendashift.com/right-to-left. Если вы

хотите дать обратную связь любого вида, вы легко можете найти мой контакт
на этой странице.
● Канал #right-to-left в Agendashift Slack http://agendashift.com/slack; все читатели

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

для меня (@asplake), @Right2LeftGuide (эта книга), и/или с хэштегом
#Right2LeftGuide.
На странице https://agendashift.com/right-to-left вы сможете найти ссылки:
● https://agendashift.com/right-to-left/recommended-reading – рекомендованная к
прочтению литература, сгруппированная по главам выборка книг и статей, на
которые я ссылаюсь в книге.
● https://agendashift.com/surveys/right-to-left – вопросы из разделов

“Размышления” в форме онлайн-опроса, как описано в конце главы 6.
● https://blog.agendashift.com/tag/right-to-left – блог со статьями на тематику

“справа налево” и связанными с ней. Я пишу в него несколько раз в месяц.
● https://agendashift.com/resources – материалы. Почти все из них

распространяются под лицензией Creative Commons license, включая
Changeban (главы 3 и 5), Шаблон обзора стратегии “снаружи внутрь” (OI-SR)
(глава 4), Celebration-5W (глава 5), 15-минутный FOTO (глава 5), Шаблон A3
(глава 5) и страницы для моих определений Definition of Done, “Правила трех” и
“Истинного пути”.
● https://agendashift.com/subscribe – можно подписаться на списки рассылок

новостей, рабочих групп (личных и онлайн) и добавление либо обновление
материалов.
146
Благодарности
Особая благодарность тем, кто любезно разрешил мне включить некоторые из своих
работ (непосредственно, открыв доступ к своим работам, или и то, и другое): Tom
Loosemore (Введение), Clarke Ching (глава 3), Jakob Schneider и Marc Stickdorn (глава
3), Niels Pflaeging (глава 4), Dan Lockton (глава 4), Bud Caddell (глава 5) и Simon
Wardley (глава 5). Большое спасибо также Cara Steele и сотрудникам магазина Wickes
в Честерфилде (именно их я посетил в главе 1).
Следом идут члены группы рецензентов, благодаря отзывам которых эта книга стала
намного лучше, чем все, что я мог бы сделать самостоятельно: Heidi Araya, John Buck,
Martin Burns, Andrea Chiou, Emma Collingridge, Sharon Dale, Jutta Eckstein, Ray Edgar,
Charlie Foote, Kjell Tore Guttormsen, Mike Haber, Patrick Hoverstadt, Craig Lucia, Steven
Mackenzie, Angie Main, Alex Pukinskis, Karl Scotland, и Thorbjørn Sigberg. Из них я
должен выделить Charlie и Steven за самые сильные комментарии – не один раз, а на
несколько черновиков; я благодарен им за честность и надеюсь, что готовый
результат будет достойной наградой за их значительные усилия.
За пределами групп рецензентов есть и другие люди, чей вклад, поддержку или
поощрение я хотел бы отметить: Phil Bowker, John Coleman, Rolf Götz, Parag Gogate,
Philippe Guenet, Mo Hagar, Johnny Hermann, Adrian Howard, Sergiy Ivashyn, Jon
Jorgensen, Liz Keogh, Mike Leber, Ben Linders, Daniel Mezick, Harry Nieboer, Johan
Nordin, Alex Papanastassiou, Darwin Peltan, André Ribeiro, Johann Tambayah, Christophe
Thibault, Vincent van der Lubbe, и Emily Webber.
Не секрет, что я не смог бы этого сделать без постоянной поддержки и ободрения

моей жены Sharon. Поскольку две книги были опубликованы быстро, кажется, что я
писал непрерывно в течение большей части трех лет; для меня это не трудно, но это
много часов, проведенных за чем-то всепоглощающим. Ее участие тоже было
значительным, и за это я ей безмерно благодарен. Sharon, ты потрясающая!
Посвящается Martin Burns

За короткий промежуток времени между подачей окончательного варианта рукописи
для публикации и сдачей ее в печать мы узнали о внезапной и неожиданной кончине
одного из членов нашей группы рецензентов, Martin Burns. Это стало шоком не только
для меня и команды рецензентов, но и для многих людей в мировом сообществе
Lean-Agile, которые считали Мартина своим другом, слышали его выступления,
общались с ним в Интернете или просто читали то, что он написал.
Выше он указан как рецензент, но здесь я должен рассказать о его конкретном вкладе
в главу 4. Именно эту главу, которая, скорее всего, вызовет споры, я больше всего
хотел сделать правильной. Мартин был одним из нескольких членов сообщества
SAFe, которые смогли подтвердить в этом контексте то, что я уже знал о Scrum, а
именно, очень реальное напряжение между перспективами "слева направо" и "справа
налево", сформулированными в этой главе и предыдущей. Более того, он
поддерживал как публично, так и частным образом (в том числе в своих клиентских
147
встречах) ориентацию на результат в целом и Agendashift в частности. Мартин, как
никто другой, дал мне уверенность в том, что я смогу довести эту главу до конца.
Те, кто его знал, не удивились бы его активной поддержке двух систем, которые на
первый взгляд могут показаться противоположными. Страстные дебаты были в его
натуре; оптимистичное отношение к людям тоже – он был необычайно "позитивен к
людям", если воспользоваться фразой Aaron Dignan (из главы 6). Он не только умел
отделять убедительно аргументированные технические достоинства концепции от
стратегии внедрения (разделение проблем, которое не удается слишком многим так
называемым экспертам), но и верил, что люди смогут совершить великие дела, если
им дать возможность самим найти путь вперед.
Объявляя о выходе этой книги в блоге, я закончил ее такими словами:
Такие люди, как Мартин, встречаются не каждый день, и поэтому хорошо сказать
спасибо, когда они встречаются. Мартин, это для тебя".
Остальные почести в адрес Мартина связаны с моими, которые вы можете прочитать

на https://blog.agendashift.com/2019/05/27/martin-this-ones-for-you/.
148
Об авторе
Майк известен в сообществах Agile и Lean-Agile как автор книг "Kanban изнутри"
(Kanban from the Inside, Blue Hole Press, 2014) и Agendashift (New Generation
Publishing, 2018), создатель симуляционных игр Featureban и Changeban, основной
докладчик на конференциях по всему миру, а также как консультант, тренер и
преподаватель.
До основания Agendashift он был исполнительным директором и менеджером по

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

Matlock Bath в Derbyshire, на краю Peak District, первого национального парка
Великобритании. Сейчас он живет в нескольких милях к северу в городе Честерфилд
с женой Шэрон и дочерью Флоренс. У Шэрон и Майка двое взрослых сыновей, Мэтью
и Саймон.
149

Справа налево - Барроуз

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Справа налево - Барроуз

Загружено:

Авторское право:

Доступные форматы

Справа налево:

Руководство цифрового лидера по Lean и Agile

Майк Барроуз, 2019

Foreword by John Buck

Published by New Generation Publishing in 2019

Copyright© Mike Burrows 2019

To Martin Burns (1968-2019)

Руководство цифрового лидера по Lean и Agile

Цифровизация, Lean, Agile и Lean-Agile

Глава 1. Справа налево в материальном мире

Что только что произошло?

Понимание потока ценности, справа налево

Глава 2. Справа налево в цифровом пространстве

Что только что произошло?

Какой именно вид Lean-Agile?

Управлять потоком, справа налево

Улучшать поток, справа налево

Винить систему, брать ответственность

Глава 3. Паттерны и фреймворки

Паттерн 1. Итеративная самоорганизация вокруг целей: Scrum

Паттерн 3. Люди, процессы и технологии: XP и DevOps

Паттерн 4. Изучение возможностей: User Story Mapping, Jobs to be Done, и BDD

Паттерн 5. Совместное создание с клиентами: Сервис-дизайн мышление

Паттерн 6. Систематическое управление узкими местами: Теория ограничений

Паттерн 7. Бизнес-эксперимент, основанный на гипотезах: Lean Startup

Справа налево: Теория большого объединения для Lean-Agile.

Глава 4. Жизнеспособное масштабирование

Модель Spotify: отряды, кланы, отделы и гильдии...

Масштабируемые Agile фреймворки

Минимальная конфигурация SAFe

Модели вовлеченности и проблемы, связанные с переменами

У организаций тоже есть потребности

Глава 5. Снаружи внутрь

Обзор сервиса поставки “снаружи-внутрь”

Обзор стратегии “снаружи-внутрь”

Организационный устав NOBL

Снаружи внутрь и снова наружу

Глава 6. Снизу вверх

Лидерство через служение

Содействие гибкости в перевернутой организации

Запуск или оживление трансформации

Приложение А. Объединенные размышления из каждой главы

Глава 1. Справа налево в материальном мире

Глава 2. Справа налево в цифровом пространстве

Глава 3. Паттерны и фреймворки

Глава 4. Жизнеспособное масштабирование

Глава 5. Снаружи внутрь

Глава 6. Снизу вверх

Приложение Б. Мой вариант…

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

Переворот «Справа Налево» предлагает и другие важные изменения. Одним из таких

А главное, книга Майка появилась в результате его концентрации на других

Джон Бак, Президент GovernanceAlive LLC Silver Spring, MD, USA

Настолько яркое различие позволяет предположить, что причина заключается в

Исследование различий между этими двумя видами привело меня к формуле

1. «Слева», рассказывая о тоннах пластика, прибывающих на склад фабрики

2. «Справа», рассказывая о детях, играющих с готовым конструктором?

● Слева, с бэклогов, мероприятий по планированию и так далее?

● Справа, с людей и их сотрудничества над быстрым развитием работающего

1. Какое из них, по вашему мнению, лучше описывает Agile как

2. Какое описание встречается чаще?

1. Потребность. Справа, самые значимые результаты – те, которые позволяют с

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