Текст книги "Agile-трансформация. Раскрывая гибкость бизнеса"

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

ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ

Экстремальное программирование фактически становится стандартом разработки программного обеспечения, однако его может быть трудно внедрить в сферах использования процедурных языков или в средах, где разработчики незнакомы с принципами объектно-ориентированного проектирования (пять этих принципов заключены в акрониме SOLID, от англ. single responsibility – «принцип единственной ответственности», open-closed – «принцип открытости/закрытости», Liskov substitution – «принцип подстановки Барбары Лисков», interface segregation – «принцип разделения интерфейса» и dependency inversion – «принцип инверсии зависимостей»).

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

СИСТЕМАТИЗИРОВАНИЕ ПОТОКА ЦЕННОСТИ (VALUE STREAM MAPPING, VSM)

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

КАК ЭТО РАБОТАЕТ

Существует несколько способов создания VSM. Некоторые организации быстрее учатся, выполняя сложные задания: большие группы людей визуализируют свою работу с помощью иконок, представляющих мириады видов деятельности. Другие выигрывают от простых, интуитивных мастер-классов, которые улучшают понимание и позволяют найти общий язык[87]87
  Cindy Jimmerson. Value Stream Mapping for Healthcare Made Easy, Productivity Press. 2010.


[Закрыть],[88]88
  Hugh McManus. «Product Development Value Stream Mapping (PDVSM Manual)», Release 1.0, Sept 2005. Lean Advancement Initiative.


[Закрыть].

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

Обычно мои мастер-классы по VSM включают восемь шагов.

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

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

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

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

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

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

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

• Шаг 6. Назначить владельца продукта VSM. Обычно я советую выбрать владельца продукта, который «владеет» изменениями и проверяет, что мы постоянно движемся к нашей цели. В некоторых случаях, если в организации уже есть рабочая agile-группа (AWG), эти цели могут соответствовать их бэклогу. (Больше об AWG можно прочитать в главе 8 «Создание рабочей аgile-группы в организации».)

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

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

Рисунок 3.9[89]89
  https://www.ibm.com/cloud/garage/content/think/practice_value_stream_mapping/


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

Рис. 3.9. Простое систематизирование потока ценности[90]90
  Источник: https://www.ibm.com/cloud/garage/content/think/practice_value_stream_mapping/


[Закрыть]

КАК ИЗВЛЕЧЬ ИЗ ЭТОГО ПОЛЬЗУ

Важно, чтобы в систематизации потока ценности участвовали правильные люди. Во время интерактивного мастер-класса нам нужны не менеджеры высокого уровня или лидеры, а люди, которые на самом деле выполняют свою работу, чтобы воплотить карту систематизации в жизнь. Как и большинство видов деятельности, требующих повышенного уровня коммуникации и взаимодействия, создание VSM – это не то, что я стал бы делать в виртуальном пространстве. Эффективный мастер-класс по систематизации потока ценности требует взаимодействия лицом к лицу[91]91
  Mike Rother and John Shook. Learning to See. The Lean Enterprise Institute, Cambridge, MA, June 1999.


[Закрыть].

ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ

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

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

КРАТКОЕ СОДЕРЖАНИЕ ГЛАВЫ

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

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

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

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

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

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

ВОПРОСЫ И ОТВЕТЫ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЧТО ПОЧИТАТЬ ПО ТЕМЕ

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

• Александр Остервальдер, Ив Пинье. «Построение бизнес-моделей. Настольная книга стратега и новатора».

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

• Business Model Canvas Overview (видео) – https://www.youtube.com/watch?v=QoAOzMTLP5s

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

• Эрик Рис. «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели».

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

• Стивен Бланк. «Почему бережливый стартап меняет все» (Why the Lean Startup Changes Everything), статья в журнале Harvard Business Review, май 2013.

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

• Дональд Рейнертсен. «Правила разработки продукта» (The Principles of Product Development Flow).

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

• Арнольд Джошуа. Black Swan Farming (http://blackswanfarming.com/cost-of-delay/).

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

• Кеннет Рубин. «Основы Scrum. Практическое руководство по гибкой разработке ПО».

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

• Кен Швабер и Джефф Сазерленд. Scrum Guides (https://www.scrumguides.org/scrum-guide.html)

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

• Дэвид Андерсон. «Kanban: альтернативный путь в Agile».

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

• Том и Мэри Поппендик. «Бережливое производство программного обеспечения. От идеи до прибыли».

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

• Кент Бек. «Экстремальное программирование. Разработка через тестирование».

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

• Джез Хамбл и Дэвид Фарли. «Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ»[92]92
  Хамбл Дж., Фарли Д. Непрерывное развертывание ПО. Автоматизация процессов сборки, тестирования и внедрения новых версий программ. М.: Вильямс, 2016. Прим. ред.


[Закрыть].

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

• Вуди Зуилл и Кевин Медоуз. «Моб-программирование: подход всей команды» (Mob Programming: A Whole Team Approach) (https://leanpub.com/mobprogramming).

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