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

Глава 2. Гибкость бизнеса

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

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

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

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

ОПРЕДЕЛЕНИЕ ГИБКОСТИ БИЗНЕСА

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

Мы знаем, как agile-компании выглядят снаружи, но как можно определить бизнес-гибкость так, чтобы помочь организациям принять этот сравнительно новый способ работы изнутри?

Многие пытались дать определение гибкого предприятия. Теперь моя очередь.

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

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

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

Menlo Innovations, инновационная компания, разрабатывающая программное обеспечение, практикует непрогнозируемые встречи и открытую коммуникацию среди своих сотрудников. Даже у СЕО нет собственного офиса. Ричард Шеридан поясняет: «Несмотря на то что мое рабочее место перемещается в зависимости от потребностей организации, обычно я сижу где-то посередине основного пространства разработки. Я обнаружил, что быть рядом с теми, кто действительно выполняет работу, очень важно – как еще я пойму, что на самом деле происходит, и буду полезен?»[38]38
  Ричард Шеридан, беседа с автором, 2016.


[Закрыть]

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

Разработчики Intuit в процессе разработки продукта часто «приглядывали» за некоторыми потребителями, когда те пользовались их продуктами. Вместо того чтобы задавать потребителям множество вопросов, разработчики просто наблюдали за использованием ПО в естественных условиях. Разочарования, смешные моменты, чистая радость клиентов позволили Intuit оценить, как ПО приносит ценность потребителям, гораздо лучше, чем любая фокус-группа, технические требования к продукту или пожелания пользователей[39]39
  https://www.forbes.com/sites/bruceupbin/2012/09/04/intuit-the-30-year-old-startup/2/#a39c49272b07


[Закрыть].

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

В своем ключевом выступлении на конференции Agile-2010 Майк Кон, один из основателей Agile Alliance и Scrum Alliance, признанный лидер мнений в agile-сообществе, объяснил этот момент: «Цель не в том, чтобы стать гибким, а в том, чтобы понимать, как стать более гибким». Точка зрения Кона ясна: гибкость – это результат мировоззрения, а не процесс. Компания никогда не сможет закончить «становление гибкости», потому что всегда есть способы улучшить свою работу.

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

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

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

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

HERE, компания цифровой картографии, принадлежавшая изначально Mercedes-Benz, Volkswagen и BMW, понимала это. Когда HERE только начала преобразование в более гибкую agile-организацию, руководители представили стратегию, в которой было особо подчеркнуто: организация начинает многолетнюю кампанию, ведущую к фундаментальным изменениям в корпоративной культуре. «Мы не знали точно, чем мы станем, но знали, что не будем тем, чем были в начале пути, – сказал Аллен Рутцен, старший менеджер программы agile-управления. – В этом и была суть».

РАЗРАБОТКА ГИБКОСТИ БИЗНЕСА: БАЛАНС ТРЕХ ВАЖНЫХ РЫЧАГОВ

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

Рисунок 2.1 показывает, как выражается гибкость в организационном контексте.

Рис. 2.1. Бизнес-гибкость в организационном контексте

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

СОЗДАНИЕ ПРАВИЛЬНОГО ПРОДУКТА (ЦЕННОСТЬ)

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

Со стратегической точки зрения нам нужно обратиться к тому, что Нассим Талеб, автор «Черного лебедя» и успешный трейдер опционами, называл «стратегией расширения»: часть нашего портфеля продуктов сосредоточена на «известных известных» (традиционном продуктовом менеджменте, который на рисунке 2.2 обозначен как эксплуатация), в то время как другая часть портфеля сосредоточена на «неизвестных неизвестных» (исследование), которые влекут за собой постоянные эксперименты, проверку правильности и поиск новых дизайнов продуктов и бизнес-моделей[40]40
  Нассим Николас Талеб. Черный лебедь. Под знаком непредсказуемости. М.: КоЛибри, 2021.


[Закрыть].

Рис. 2.2. Портфель аgile-предприятия, направленный на проверенные бизнес-возможности одновременно с активным принятием изменений и неопределенности как части стратегии, оптимизированной для VUCA

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

Рисунок 2.2 изображает стратегию расширения Талеба в контексте предприятия. Большая часть ресурсов корпорации направлена на проверенные занятия с низким риском для бизнеса, в то время как значительная, но меньшая часть всего портфеля сосредоточена на более рискованных и более инновационных начинаниях[41]41
  https://www.investopedia.com/articles/investing/013114/barbell-investment-strategy.asp#ixzz585ruOPF6


[Закрыть].

ЭКСПЛУАТАЦИЯ: РАЗРАБОТКА ПРОДУКТА

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

Рис. 2.3. Традиционные стадии запуска продукта

1. Стадия идеи/концепта: на этой стадии определена возможность и написан первый набросок бизнес-плана. Анализ SWOT (аббревиатура от англ. strengths – «сильные стороны», weaknesses – «слабости», opportunities – «возможности», threats – «угрозы») уже готов, высокоуровневые бюджеты очерчены, и представлена ожидаемая окупаемость инвестиций. Идея вместе с финансовой моделью представлена старшему руководству, которое решает, пропустить проект или нет. Если дан зеленый свет и бюджет выделен, гонка начинается.

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

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

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

Эту модель разработки продукта обычно преподают в бизнес-школах. Сегодня она известна как общепринятый способ разработки продуктов. Большинство открытых предприятий подстраивают под себя вариации этой модели, у некоторых это неплохо получается. Однако, несмотря на ее популярность, в течение первого года намного больше запусков проваливается, чем преуспевает. Согласно статистике одной из лидирующих компаний, исследующих рынок, около 75 % запусков новых продуктов не может заработать даже 7,5 млн долл. за первый год[42]42
  https://hbr.org/2011/04/why-most-product-launches-fail


[Закрыть].

Чего же не хватает? В своей фундаментальной работе «Четыре шага к озарению»[43]43
  Бланк С. Четыре шага к озарению. М.: Альпина Диджитал, 2014.


[Закрыть] уважаемый в Кремниевой долине венчурный инвестор Стив Бланк обратил внимание на модель разработки продукта и заметил несколько значительных недостатков.

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

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

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

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

5. Высокие потери при неудаче продукта. Требуется много времени, чтобы продукт добрался до рынка. Из-за огромного размера организаций, которые строятся вокруг продукта, и недостатка обучения в процессе неудачи по запуску нового продукта становятся дорогостоящими.

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

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

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

АНАЛИЗ КЕЙСА: COMES WITH MUSIC

В начале 2000-х, до того как Pandora, Spotify и Apple Music захватили мир, Nokia выступила с замечательной идеей: включить услугу бесплатной подписки на музыку в каждый телефон Nokia. Сервис, названный Comes with Music, действительно опередил время и был положительно оценен фокус-группами: в комплекте со специальными версиями телефонов Nokia пользователи получали целый год музыки абсолютно бесплатно[44]44
  https://www.cnet.com/news/nokias-comes-with-music-initiative/


[Закрыть].

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

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

Что пошло не так? Почему крупнейшие мировые рынки так негативно ответили на услугу, которую с такой готовностью приняли фокус-группы?

Ответ кроется в том, как люди понимают бесплатную музыку, и в дополнительных расходах, сопутствующих получению услуги, особенно на развивающихся рынках. Так получилось, что Comes with Music технически был бесплатным, а на самом деле – нет. Чтобы договориться со звукозаписывающими компаниями и быстро составить привлекательный каталог музыки, Nokia согласилась прикрепить музыку к каждому устройству с помощью так называемой технологии DRM (Digital Rights Manager, менеджер цифровых авторских прав), подтверждая, что песни не могут быть переданы на другие устройства. Это означало, что, если люди захотят послушать мелодии через что-то, кроме телефона, им придется пройти серию сложных шагов, чтобы обойти меры защиты авторских прав. И все это, чтобы послушать песни, которыми они, на первый взгляд, владели!

Вдобавок сервис требовал объемных загрузок и было необходимо иметь тарифный план, который поддерживал такую передачу данных. Тарифные планы передачи данных на формирующихся рынках вроде Индии печально известны своей дороговизной, и сервис Comes with Music фактически требовал подписки на планы, стоившие во много раз больше, чем сам телефон. Люди быстро все поняли и избегали этой услуги как чумы. Кто захочет телефон, которым так дорого пользоваться?

Comes with Music – пример продукта, который попал в яблочко с точки зрения предполагаемой ценности и целевой аудитории. К сожалению, Nokia не знала прочих предпочтений потребителей и экономики, лежащей в основе предложения. Из-за того что услуга могла быть использована только на одном устройстве и требовала расширенных тарифных планов передачи данных, она оказалась непривлекательной и недоступной для крупнейших мировых рынков. В результате Comes with Music была отключена менее чем через год после запуска[45]45
  https://www.techdirt.com/blog/wireless/articles/20110119/05025612726/death-nokias-comes-with-music-shows-that-free-with-drm-is-losing-proposition.shtml#comments


[Закрыть].

ИССЛЕДОВАНИЕ: РАЗВИТИЕ КЛИЕНТА

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

Бланк называет этот процесс развитием клиента. Он состоит из четырех важных шагов, изображенных на рисунке 2.4 и описанных далее[46]46
  Steve Blank. The Four Steps to the Epiphany. Self-published: Cafepress.com. 2005.


[Закрыть].

Рис. 2.4. Модель развития клиента Стива Бланка фокусируется на определении важной потребности потенциального покупателя, затем на подтверждении того, что продукт или услуга, которую мы создаем, удовлетворяет эту потребность. Только после этого мы инвестируем деньги в действия по выстраиванию компании

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

2. Верификация потребителей: проверьте свои предположения. Ваш предполагаемый продукт решает проблему, с которой столкнулся потенциальный покупатель? Для начала – нужно ли решать эту проблему? За несколько итераций вы узнаете ответы на эти вопросы. Если вы понимаете, что ваши предположения неверны (часто бывает именно так), то меняете направление, чтобы убедиться, что отвечаете потребностям покупателей.

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

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

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

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

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

ВОПЛОЩАЕМ В ЖИЗНЬ: LEAN STARTUP

Lean Startup («бережливый стартап») – методология, предложенная в 2008 году Эриком Рисом, одним из студентов Стива Бланка в Стэнфорде. Вдохновили его три источника: работа Бланка, научный метод и характерное для Lean внимание к оптимизации потребительской ценности[47]47
  Эрик Рис. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели. М.: Альпина Паблишер, 2018.


[Закрыть].

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

Что это значит: вместо того чтобы полагать, будто мы обладаем знаниями о том, что и для кого создаем, стоит создать гипотезу, которая проверит наши предположения с помощью выпуска MVP (Minimum Viable Product, минимально жизнеспособный продукт); затем нужно убедиться, правильны ли наши предположения, и развивать продукт, основываясь на эмпирических данных, а не на пространных (и гипотетических) бизнес-планах. Другими словами, эмпиризм управляет, а подтвержденные данные движут теорию[48]48
  Ash Maurya. Running Lean. Self-published. Iterate from Plan A to Plan That Works. O’Reilly Media, 2012.


[Закрыть].

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

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

Несмотря на то что Бланк и Рис подходят к проблеме с точки зрения стартапов (отсюда и название книги Риса – «Бизнес с нуля»), концепцию можно применить и к более крупным организациям – таким компаниям, как Nordstrom и GE, отдельные подразделения которых используют Lean Startup как часть процесса разработки продукта. Lean Startup помогает компаниям постоянно придумывать, исследовать и проверять новые идеи в дополнение к работе по проверенным уже моделям.

Компания Intuit стала одним из первых последователей этого способа работы. Основатель Intuit Скотт Кук считает модель Lean Startup естественным способом ведения бизнеса в мире VUCA и предупреждает, что прошлые успехи могут сослужить плохую службу в прогнозировании будущего. «Успех – могущественная вещь, но он способен отуплять компании, делая их все менее и менее инновационными»[49]49
  https://hbswk.hbs.edu/item/lean-strategy-not-just-for-start-ups


[Закрыть].

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

ПРАВИЛЬНОЕ СОЗДАНИЕ ПРОДУКТА (КАЧЕСТВО)

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

УПРАВЛЕНИЕ ТЕХНИЧЕСКИМ ДОЛГОМ

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

В своем блоге C2.com Каннингем распространяет метафору долга, объясняя, что команды вынуждены либо платить замедляющие их «проценты», либо погасить долг полностью, переписав код так, как он должен был быть написан изначально. Если осознанно подходить к написанию кода, не позволяя долгу расти, в долгосрочной перспективе можно справляться с периодическими изменениями кода, держа под контролем дизайн продукта[50]50
  Ward Cunningham. «Technical Debt». http://wiki.c2.com/?TechnicalDebt


[Закрыть].

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

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

Рис. 2.6. Контроль технического долга с помощью учета того, что берется, и своевременного погашения[51]51
  Henrik Kniberg. «Good and Bad Technical Debt». https://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt


[Закрыть]

ОСМЫСЛЕННАЯ РАЗРАБОТКА ПРОДУКТА

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

Джеймс Греннинг, один из подписантов Agile-манифеста и опытный программист, считает, что разработка продукта – это и творчество, и наука. «В своей основе программирование ПО связано с решением проблем, – утверждает Греннинг. – Поддержание успешной работы программы, понимание выраженных в каждой строке кода проблем и способов их решения – научная часть разработки программного обеспечения. Создание программы не только функциональной, но и привлекательной, красивой, легкой для понимания и поддержки таким образом, чтобы другие люди могли создавать что-то свое на ее основе, – творческая деятельность»[52]52
  Джеймс Греннинг, беседа с автором, август 2017-го.


[Закрыть].

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

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

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

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

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