Read the book: «Менеджмент цифрового продукта. От идеи до идеала»

Библиотека цифровой трансформации

© Шуваев Я.А., текст, иллюстрации, 2024

© All emojis designed by OpenMoji – the open-source emoji and icon project. License: CC BY-SA4.0

© Оформление. ООО «Издательство «Эксмо», 2024

Предисловие автора

Дорогие читатели!

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

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

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

Я учился у лучших тренеров по Agile и Scrum из ScrumTrek и Unusual Concepts. В процессе погружения в мир Agile каждый день узнавал что-то новое и применял это в своей работе.

Затем меня пригласили принять активное участие в создании Ак Барс Цифровых Технологий для банковской группы Ак Барс. Здесь я занимался продуктовыми и процессными инновациями, масштабированием Agile и запуском внутренних стартапов. Компания на моих глазах выросла от нескольких Agile-команд до 350 человек. Инновационные проекты, которые мне удалось успешно запустить, такие как «Экосистема компьютерного зрения» и ИИ-ассистент для контакт-центр а, значительно улучшили эффективность банковской деятельности и обогатили мой опыт.

Страсть к улучшению пользовательского опыта и созданию цифровых продуктов привела меня к обучению в Future London Academy, где я черпал вдохновение у ведущих IT-компаний, базирующихся в Лондоне. Я продолжал совершенствоваться в области Agile, обучившись в лучших международных школах в Берлине (Agile42), Сан-Франциско (This Agile Guy) и в Нью-Йорке у самого отца-основателя Scrum Джеффа Сазерленда.

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

Затем я некоторое время управлял подразделением, занимающимся масштабированием Agile, R&D и технологическим аудитом в МТС, где довелось решать задачи управления производством цифровых продуктов в масштабе одной из самых больших технологических компаний.

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

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

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

Для кого эта книга

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

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

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

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

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

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

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

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

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

Термины и определения

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

Цифровой сервис – услуга, предоставляемая посредством цифровых каналов.

Модель монетизации цифрового сервиса – способ вознаграждения поставщика услуги. Существует несколько видов моделей монетизации:

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

➠ Подписка (recurrent payment) – периодическое вознаграждение поставщика в обмен на возможность использовать сервис в оплаченный период.

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

➠ Встроенные покупки – единоразовый платеж в процессе взаимодействия с сервисом для расширения предоставляемой функциональности или получения дополнительных возможностей.

➠ Использование в обмен на просмотр рекламы – доступ к функциональности или контенту сопровождается показами рекламных сообщений.

➠ Синтетическая модель – может совмещать в себе несколько моделей, перечисленных выше.

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

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

Продукт жизнеспособен, если:

1. Продукт операционно прибылен – доходы от монетизации покрывают расходы на поддержание продукта в работоспособном состоянии и текущие расходы на продвижение.

2. Инвестиции потенциально возвратны – текущие финансовые показатели продукта демонстрируют, что в перспективе вложенные инвестиции будут возвращены.

Минимально жизнеспособный продукт (Minimum Viable Product, MVP) – продукт, который при минимальных вложениях показывает свою жизнеспособность.

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

1. Формирование бизнес-требований.

2. Создание плана реализации.

3. Концептуальное проектирование.

4. Визуальное проектирование (UX/UI design) (для ПО с пользовательским интерфейсом).

5. Разработка плана реализации.

6. Разработка серверной части (backend).

7. Разработка внешнего интерфейса (frontend).

8. Наполнение контентом.

9. Тестирование.

10. Внедрение.

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

1. Генерация бизнес-требований к итерации.

2. Производство и внедрение.

3. Анализ результатов для последующей генерации бизнес-требований.

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

Функция – способность продукта выполнять задачи пользователя.

Функциональность¹ (functionality) – набор функций.

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

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

Введение

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

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

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

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

➠ Цикл поставки – организация непрерывного улучшения продукта. Мы рассмотрим, как создать эффективный процесс управления продуктом, который позволит вашей команде непрерывно совершенствовать продукт и реагировать на изменения рынка.

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

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

➠ Создание и масштабирование ГГ-компании – построение антихрупкой организации. Мы рассмотрим, как создать и управлять IT-компанией, которая способна расти в разы, сохраняя при этом гибкость и эффективность.

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

Глава 1
Различия между продуктовым и проектным подходами

После того как я более шести лет проработал в детской проектной парадигме, переход на продуктовый подход оказался для меня очень болезненным. Это случилось, когда я работал в Альфабанке. Мы только начали внедрять гибкий подход, многие вещи были совершенно не интуитивны и в отсутствие опыта Scrum² больше походил на Scream³. Скорее это был проектный подход, визуально замаскированный при помощи Agile-терминологии под продуктовый. Понадобилось несколько лет практики, тренингов и множество набитых шишек, чтобы осознать эффективность продуктового подхода, и теперь я с радостью готов поделиться опытом.

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

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

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

Ключевые отличительные особенности двух подходов отражены в сравнительной таблице 1.1.

Табл. 1.1. Ключевые различия продуктового и проектного подходов

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

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

1. Переход на собственную внутреннюю разработку.

2. Короткие циклы усовершенствований ПО.

3. Непрерывное инвестирование и непрерывный возврат инвестиций.

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

1.1. Переход на собственную внутреннюю разработку

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

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

2. Требуется много ресурсов для минимизации юридических и финансовых рисков при взаимодействии заказчик – подрядчик, что приводит к длительному циклу реакции на изменения. В заказной разработке преобладают два подхода: по техническому заданию и подход «Время и материалы» (Time and Material, Т&М), при котором разработчики нанимаются на выработку определенного количества часов. Первый подход требует прогнозирования всех возможных рисков и высокой экспертизы в технической реализации этапов работ. Составитель ТЗ должен смоделировать заказываемое ПО «в голове» с учетом особенностей реализации, потенциальной нагрузки и внешних изменений (изменения в стороннем ПО, законодательстве и т. д.). Часто это чревато тем, что по окончании работ формируется второе, не менее увесистое ТЗ на доработки. Предсказуемость и ритмичность вносимых изменений в ПО может значительно меняться. Т&М – более оперативный подход, разработчики практически находятся в штате у заказчика, но обходятся они как специалисты, которые на ступень выше и эффективнее (см п.1).

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

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

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

1.2. Циклы доработки по стремительно сокращаются

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

1. Культура копирования. В конкурентной борьбе участники активно копируют удачные решения. Это явление стало неотъемлемой частью процесса проектирования и разработки. Компании регулярно проводят сравнительный анализ конкурентов и исследования эффективности внедрений. Копировать лучшие решения становится обязательной практикой производства. (Подробнее о методах конкурентного анализа см. в п. 4.2.1.3.)

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

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

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

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

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

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

Табл. 1.2. Потеря актуальности планов в зависимости от сроков.

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

1.3. Непрерывное инвестирование и непрерывный возврат инвестиций

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

Рис. 1.1. Каскад цифровых инициатив

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

Жизнь цифровой инициативы можно разделить на две фазы, каждая из которых, в свою очередь, состоит из нескольких этапов:

1. Фаза открытия (discovery phase), или фаза проектирования инициативы.

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

I. сегмент потенциальных пользователей;

II. проблема пользователей, которую призвана решить инициатива;

III. совокупность решений, входящих в инициативу;

IV. источники доходов;

V. источники расходов

VI. и ряд других параметров, определяемых стейкхолдерами⁵ (заинтересованными лицами). Если стейкхолдеры видят инвестиционный потенциал в инициативе, то она переходит на следующую фазу проработки. (Подробнее о концепции цифровой инициативы см. в п. 4.2.)

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

2. Фаза поставки.

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

b. Масштабирование – этап, на котором разработка ориентирована на то, чтобы инициатива в кратчайшие сроки охватила максимальное количество пользователей (рис. 1.2).

c. Оптимизация издержек – на этом этапе разработка сфокусирована на минимизации сопутствующих издержек поддержки инициативы.

Рис. 1.2. Зависимость дохода инициативы от этапа жизненного цикла

Подробнее о фазах открытия и поставки см. в и. 2.4.

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

Эволюционно продуктовый подход к разработке ПО опирается на гибкие подходы (Agile), самые распространенные из которых во многом базируются на бережливых подходах в разработке (Lean Development).

Особую популярность бережливый подход к разработке получил благодаря книге «Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели» Эрика Риса.

Бережливый подход базируется на концепции бережливого производства (Lean Production), которая стала переосмыслением производственной системы Toyota (Toyota Production System, TPS). На рис. 2.1. представлена схема эволюционной связи производственных подходов.

Рис. 2.1. Связь производственных подходов

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

2.1. Минимизация отходов

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

В бережливом производстве выделяют семь видов отходов:

1. Потери из-за перепроизводства.

2. Потери времени из-за ожидания.

3. Потери при ненужной транспортировке.

4. Потери из-за лишних этапов обработки.

5. Потери из-за лишних запасов.

6. Потери из-за ненужных перемещений.

7. Потери из-за выпуска дефектной продукции.

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

2.1.1. Потери из-за перепроизводства

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

1. Амортизация складской инфраструктуры.

2. Оплата труда персонала.

3. Учет и инвентаризация.

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

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

Несмотря на то что в цифровом производстве нет складов, расходы на перепроизводство активно присутствуют:

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

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

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

4. Учет движения перепроизведенных «полуфабрикатов» оттягивает внимание всех участников процесса.

2.1.2. Потери времени из-за ожидания

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

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

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

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

2.1.3. Потери при ненужной транспортировке

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

1. Расходы на транспортную инфраструктуру

2. ФОТ обслуживающего персонала.

Для минимизации отходов при транспортировке сокращается пространство между производственными операциями.

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

Для минимизации таких отходов следует использовать инструменты непрерывной интеграции ⁄ доставки (CI/CD)⁸.

2.1.4. Потери из-за лишних этапов обработки

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

1. Дополнительные операции, например дополнительная полировка.

2. Дополнительное время обработки, например излишнее время закаливания.

3. Дополнительные ресурсы, например больший расход лака на покрытие.

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

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

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

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

Результаты сравниваются с другой выборкой, у которой нет данного решения. Если эффект от улучшения есть, то «полировка» продолжается. Такой способ тестирования называется А/В-тестирование. (Подробнее об этом см. в п. 4.3.8.2.)

2.1.5. Потери из-за лишних запасов

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

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

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

2.1.6. Потери из-за ненужных перемещений

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

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

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

Для минимизации таких отходов следует использовать:

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

2. Инструменты с автоматической доставкой артефактов, например плагин для экспорта графического макета в хранилище компонентов для фронтенд¹⁰-части продукта.

2.1.7. Потери из-за выпуска дефектной продукции

Потери из-за дефектной продукции включают:

1. Расходы на возврат дефектного продукта или партии.

2. Расходы на утилизацию дефектного продукта.

3. Расходы в связи со снижением спроса.

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

Подобный подход применяется и в разработке цифровых продуктов в нескольких видах:

1. Ручное тестирование, осуществляемое QA¹¹-инженерами.

2. Автоматическое тестирование – когда создается ПО, имитирующее взаимодействие с пользователями.

3. Автоматическое модульное тестирование (auto unit-test) – специальный код, создаваемый самими разработчиками для проверки созданной функциональности.

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

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

2. Прогрессивная раскатка (progressive rollout) – позволяет открывать функциональность постепенно на всю аудиторию, например по 10 % в неделю, и следить за возникающими проблемами.

3. Автоматический откат (automatic rollback) – в случае возникновения проблем функциональность приложения автоматически откатывается к предыдущей стабильной версии.

На уровне инженерных практик в процессе разработки вводятся критерии стабильности и критерии производительности для приемки разрабатываемого программного обеспечения. Например: «Время недоступности системы за последние 48 часов < 1 %», «Доля доступных функций за последние 48 часов > 99 %» и др. Более подробно критерии приемки, относящиеся к качеству разработки, мы рассмотрим в и. 3.3.

2.2. Принципы ориентации на максимальную ценность для потребителя

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

1. Value – определить ценность продукта.

2. Value Stream – определить поток ценности.

3. Flow – обеспечить свободное течение потока ценности.

4. Pull – втягивание вместо выталкивания.

5. Perfection – стремиться к совершенству.

Разберем эти принципы подробнее и проведем параллель с разработкой цифровых продуктов.

2.2.1. Определение ценности продукта

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

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

Например:

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

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

3. Использование в обмен на создание контента подразумевает, что расплачиваться будут потребители контента (например, просмотром рекламы).

Не менее важно вспомнить о сроке расплаты. То, как происходит оплата – моментально, с задержкой или, например, равными долевыми платежами, – влияет на производство.

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

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

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

Для определения ценности в классическом производстве прибегали к следующим мероприятиям:

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

2. Создание прототипа будущего продукта для сбора предзаказов.

3. Выпуск пробной партии.

4. Тестовая продажа пробной партии.

Аналогично в цифровом производстве проводятся следующие мероприятия:

1. Интервью с потенциальными пользователями. Например, по методикам Customer Development, глубинные интервью, интервью в подходе «работы, которые должны быть выполнены» и многие другие. (Подробнее об исследованиях на этом этапе см. в п. 4.2.1.2.)

2. Исследование с применением прототипов. Применяется широкий диапазон прототипов различной степени приближенности к финальному продукту:

а. Вайрфрейм¹² – эскизное описание интерфейса продукта, которое используется для объяснения будущего поведения продукта.

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

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

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

3. Закрытое бета-тестирование. Бесплатное или оплачиваемое для пользователей ограниченной группы тестирование. Позволяет выявить проблемы в пользовательском опыте¹⁴, минимизировать риски, связанные с перегрузкой инфраструктуры, информационной безопасностью и репутацией.

4. Бета-тестирование. Открытие платной версии продукта для ограниченной группы пользователей. Позволяет оценить, насколько люди готовы платить поставленную цену за предложенную ценность.

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

2.2.2. Определение потока ценности

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

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

В цифровом производстве составляется карта потока ценности, на которой создание продукта разделяется на этапы от идеации¹⁵ до производства. При этом на каждом этапе минимизируются отходы за счет внедрения практик, описанных в п. 2.1. Например, применение инструментов CI/CD (непрерывной интеграции и поставки) для автоматизации развертывания доработок в средах разработки или автоматическое модульное тестирование.

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

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

Совет по формированию потока ценности: не нужно начинать оптимизировать жизнеспособность поставки, пока не доказана жизнеспособность продукта.

2.2.3. Обеспечение свободного течения потока ценности

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

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

В цифровом производстве в зависимости от масштаба компании можно разбить процесс производства ценности на два непрерывных цикла:

1. Цикл открытия (Discovery Cycle), в котором генерируются и валидируются новые бизнес-идеи, прежде чем начать проверку боем.

2. Цикл поставки (Delivery Cycle), в котором идеи обретают плоть и становятся доступными конечному пользователю.

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

В зависимости от размера компании количество этажей может варьироваться.

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

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

2.2.4. Втягивание вместо выталкивания

Принцип втягивания означает, что производство и распространение определяются спросом, а не прогнозом спроса.

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

Сравним принципы выталкивания и втягивания (табл. 2.1).

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

Табл. 2.1. Сравнение принципов выталкивания и втягивания

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

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

– Уважаемый, почему бы вам не наточить ваш топор?

– У меня нет времени точить топор – я должен рубить! – простонал дровосек…

Стремление к совершенству (Kaizen) подразумевает непрерывную ревизию текущих процессов на предмет их улучшения.

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

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

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

Перед вами несколько примеров Kaizen-процессов:

1. Ретроспектива спринта¹⁷ – обязательное мероприятие, проводимое в конце каждой итерации, для повышения эффективности последующих. (Подробнее о ретроспективе спринта см. в п. 3.2.) Команды проводят «разбор полетов», обсуждая, например, какие проблемы помешали успеть, какие процессы нужно внедрить, чтобы избежать подобных проблем впредь, какие процессы устарели и нужно от них избавиться и идеи, что нужно попробовать.

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

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

2.3. Бережливый цикл разработки

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

Рис. 2.2. Бережливый цикл

Одна из идей, описанных в книге, – цикл бережливого стартапа (Lean startup cycle) – идеального, максимально бережливого цикла для цифрового производства (рис. 2.2).

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

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

2.3.1. Этапы цикла бережливого стартапа

Табл. 2.2. Этапы бережливого стартапа

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

2.4. Циклы открытия и поставки

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

➠ собрать идеи;

➠ оценить релевантность идеи потребностям пользователей;

➠ оценить рыночные условия;

➠ оценить идеи на предмет их инвестиционной привлекательности;

➠ определить объем работ и бюджет для запуска фазы MVP и фазы масштабирования.

Этап такого прояснения принято называть этапом открытия; также часто можно услышать «дискавери» (англ, discovery – открытие; рис. 2.3).

Рис. 2.3. Связь циклов открытия и циклов поставки

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

Если цикл поставки – это интуитивно понятная составляющая производства цифрового продукта, то цикл открытия поэтапно появляется при достижении определенной зрелости компании. Например, сначала может появиться культура проведения исследований для оценки соответствия потребностям пользователя (CustDev, глубинные интервью), потом исследования рынка (конкурентный анализ, бенчмаркинг¹⁸), а потом оценка инвестиционной привлекательности. (Подробнее о бенчмаркинге см. в п. 4.3.3.4.)

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

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

Табл. 2.3. Роли участников в разных циклах

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

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

Из хороших практик можно выделить трехэтапную модель цикла открытия:

1. Концепция. На этом этапе формируется краткое описание бизнес-идеи. Для эффективной генерации и обсуждения гипотез описание регламентируют, фиксируя его обязательные атрибуты, например: сегмент пользователей, проблема сегмента, возможные решения, поток доходов, поток расходов и прочее. За основу часто берется модель «бережливый холст» (Lean canvas) или ее предшественница «холст бизнес-модели» (Business model canvas) Александра Остервальдера. Описанные идеи обсуждаются со стейкхолдерами, и в случае веры в успех выделяются ресурсы для дальнейшей проработки концепции и превращения ее в гипотезу.

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

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

Более подробно этапы цикла открытия будут рассмотрены в главе 4.

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

Глава 3
Цикл поставки

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

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

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

Начали появляться новые подходы к разработке, такие как Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming и многие другие. Эти подходы, в свою очередь, черпали вдохновение в других быстрых практиках начиная от бережливого производства и заканчивая практиками армейской подготовки.

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

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

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

Побочным эффектом становится необходимость отслеживания всех промежуточных артефактов. На инвентаризацию уходило очень много времени, при этом было очевидно, что половина артефактов безвозвратно утратила актуальность, но они все равно мешались в бесконечных колонках Trello. Позднее мы узнали, что такой подход называется Scrum-fall: Scrum + Waterfall, и обычно он порождает массу проблем с производством и культурой – команда разделяется на этажи, каждый занят своим артефактом и не ориентирован на заботу о результате и пр. Я помню это удивительное чувство освобождения, возникшее, когда мы перешли в режим, в котором все делают все в одном спринте. Артефакты порождались и утилизировались в спринте и их не нужно было учитывать. Команда работала сообща и принимала решение о необходимости артефакта и качестве его проработки, а самое главное, от идеи до релиза проходило две недели.

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

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

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

Более подробно о гибком подходе Agile и лучшем известном способе организации цикла поставки Scrum будет рассказано подробнее в п. 3.1 и 3.2.

3.1. Agile

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

Тем не менее, как было описано ранее, молодые компании начали двигаться в сторону альтернативных подходов к разработке. Через некоторое время, на встрече 17 независимых практиков новых методик программирования 13 февраля 2001 года, был сформулирован свод общих принципов гибких подходов – манифест Agile (Agile Manifesto).

3.1.1. Agile-манифест

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

Табл. 3.1. Agile-манифест

3.1.1.1. Люди и взаимодействие важнее процессов и инструментов

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

Такая же картина и с внедряемыми инструментами. Первичная цель внедрения – это повышение эффективности, которая, в свою очередь, прочно связана с качеством опыта сотрудника (англ, employee experience, сокр. EX). Если в процессе использования инструмента создается ощущение несправедливости или пустой траты времени, то стоит задуматься о его замене или отмене.

Например, я на практике наблюдал несколько волн джирафикации и деджирафикации, иногда даже в одной команде. Под джирафикацией я имею в виду внедрение инструмента управления задачами типа Jira²³. Когда команда только запускалась, не было конкретных инструментов для отслеживания задач, команда работала, перемещая физические стикеры по Kanban-доске²⁴. Через некоторое время команда внедрила диспетчер задач, и стало уходить заметно больше времени на ежедневные стендапы²⁵, так как приходилось тратить время на настройку и оперирование инструментом. Также часть времени уходила на «нарезание» задач на спринт. Потом, после очередного тренинга, команда начала делать очень короткие спринты и дробить функциональность на небольшие элементы (пользовательские истории²⁶) размерностью менее одного дня разработки. На неделю спринта выходило 5–6 таких элементов, которые команда всем скопом каждый день доводила до релиз-кандидата²⁷. При таком подходе отсутствовала необходимость в декомпозиции задач, так как каждый день задачи порождались и утилизировались в финальном артефакте. И команда опять перешла к физическим стикерам.

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

3.1.1.2. Работающее ПО важнее подробной документации

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

1. Проектная – создается до запуска разработки для описания образа результата.

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

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

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

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

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

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

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

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

Сокращение объема технической документации

1. Автоматически генерируемая документация. Нужно отдавать предпочтение решениям, которые позволяют генерировать документацию автоматически на основе структур кода. Например, фреймворк разработки²⁸ типа FastAPI позволяет из коробки автоматически генерировать документацию для интеграции потребителями сервиса. С появлением больших языковых моделей²⁹ набирает популярность генерация документации на основе ИИ. Например, GitHub Copilot экономит время разработчиков на описание кода, отправляемого в репозиторий.

2. Pull-документация. Тут применяется принцип втягивания вместо вталкивания. Часто бывает, что документация пишется про запас, и, если сделать замеры, можно увидеть, что часть документов генерируется впустую. Принцип вытягивания подразумевает, что документация генерируется по запросу. При этом современная документация – это не обязательно текст. Более эффективно и наглядно по времени может быть записать скринкаст³⁰ с объяснением голосом. Потом такое видео добавляется в базу знаний и отправляется по запросу. Подход втягивания имеет еще и культурно-оздоравлива-ющий эффект – разработчики начинают больше общаться и помогать новичкам вливаться, что отличается от культуры выталкивания, в которой новичка могут отправить штудировать обширную базу документов о продукте. Разумеется, принцип pull-документации нельзя использовать повсеместно, например для нормативной документации, создаваемой по требованиям стандартов. Но само движение в сторону перевода генерации артефактов от выталкивания к втягиванию позволит значительно оптимизировать процесс и сделать деятельность сотрудников более содержательной и осмысленной.

3.1.1.3. Реагирование на изменения важнее следования плану

«Давайте сначала все по договору закроем, а потом начнем вносить правки», – именно так я отвечал клиенту, управляя небольшой компанией заказной разработки. Планы разработки шли тогда 3 4 квартала и уже на 1-2-м квартале накапливалось смещение сроков, и изменения в процессе – даже очевидные и существенные – были подобны смерти.

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

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

3.1.2. Пример гибкого подхода

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

➠ Проектирование, в результате которого мы получаем проект отеля на 20 номеров разной комфортности и вместимости, с открытым бассейном.

➠ Вырываем котлованы под основное здание и под бассейн.

➠ Возводим стены этаж за этажом.

➠ Ставим крышу.

➠ Проводим отделку.

➠ Строим бассейн.

➠ Запускаем постояльцев.

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

Гибкий подход позволяет возвращать инвестиции как можно раньше, постепенно наращивая объем входящего денежного потока.

Рассмотрим строительство отеля с активным применением гибкого подхода:

➠ Привозим на участок жилой блок-контейнер.

➠ Делаем рекламу и запускаем жильцов.

➠ Собираем обратную связь об их предпочтениях: например их полностью устраивает уровень комфорта блок-контейнера.

➠ Входящий денежный поток позволяет закупить в сезон еще несколько контейнеров.

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

➠ Возводим теннисный корт.

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

➠ Полученные данные о финансовой модели привлекли инвестора, который вложил деньги в еще несколько контейнеров и расширение участка.

Рис. 3.1. Сравнение водопадного и итеративного подходов

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

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

3.1.3. Область применения гибких подходов

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

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

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

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

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

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

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

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

Рис. 3.2. Квадрант операционных контекстов

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

3.1.3.1. Водопадный подход

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

Рис. 3.3. Пример диаграммы Ганта

Классическое представление водопадного плана – диаграмма Ганта, приведенная на рис. 3.3.

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

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

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

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

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

Рис. 3.4. Горизонтальная и вертикальная декомпозиция

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

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

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

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

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

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

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

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

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

3.1.3.2. Scrum

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

Для описания Scrum идеально подходит поговорка «слона нужно есть по частям». Комплексная задача разделяется на несколько поменьше, и, решая небольшие задачи, команда постепенно приобретает экспертизу и приходит к цели.

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

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

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

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

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

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

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

Из минусов можно отметить его контринтуитивность и тесную связь с культурой компании.

3.1.3.3. Контринтуитивность

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

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

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

3.1.3.4. Связь с культурой компании

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

Если среди проблем участники команды перечисляют:

➠ непонятные цели поставленных задач или беспричинную срочность;

➠ двоевластие;

➠ недоступность владельца продукта или стейкхолдеров;

➠ выработку человеко-часов важнее ценности поставки,

то, скорее всего, Scrum/Agile внедрен в компании декларативно, а за фасадом скрываются совсем другие процессы.

В этом случае Scrum может показать обратную эффективность.

3.1.3.5. Связь между Scrum и водопадом

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

3.1.3.6. Kanban

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

Изначально Kanban был создан для визуализации прохождения артефактов в процессе производства Toyota.

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

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

На рис. 3.5 представлен пример Kanban для цикла дискавери.

Рис. 3.5. Пример Kanban для управления циклом открытий

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

Еще одна важная практика Kanban – четкие критерии перехода из стадии в стадию.

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

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

3.1.3.7. Связь между Scrum и Kanban

Kanban может использоваться Scrum-командой для ежедневного отслеживания прогресса – движения элементов функциональности (пользовательской истории) от ToDo³⁴ к Done или для движения задач разработчиков в процессе выполнения одной пользовательской истории в отдельной дорожке (такой Kanban называется Scrum-доска или Scrum-борд).

Рис. 3.6. Scrum-доска (слева) и Kanban-доска статуса функциональности (справа) для управления спринтом в режиме «роения»

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

3.1.3.8. Бережливый стартап

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

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

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

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

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

Вариант 1. Гипертрофированный водопадный подход:

➠ Закупить партию велосипедов.

➠ Арендовать склад.

➠ Арендовать магазин.

➠ Заказать брендинг для компании.

➠ Заказать дизайн интерьера.

➠ Сделать ремонт в магазине.

➠ Пошить униформу.

➠ Нанять персонал.

➠ Сделать сайт с каталогом продукции.

➠ Заказать в рекламном агентстве кампанию.

Вариант 2. Гипертрофированный Lean startup подход:

➠ Дать бесплатное онлайн-объявление о том, что продается винтажный велосипед, используя фото из интернета.

➠ В случае, если кто-то откликнется, перепродать велосипед, доставив самостоятельно.

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

➠ заказ напрямую у поставщика;

➠ закупка оптом;

➠ организация собственной службы доставки;

➠ др. вариант.

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

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

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

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

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

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

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

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

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

3. Ограничение стабильности. Продукт работает стабильно только для количества пользователей, достаточного для получения репрезентативных данных^{37 36}. Применяется дешевый или бесплатный стек технологий, домашняя или грантовая³⁸ облачная инфраструктура.

4. «Волшебник страны Оз»³⁹. Человек имитирует действия системы, например изображая интеллектуального чат-бота.

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

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

7. Более дорогое решение. Если идея вашего продукта – удешевление уже существующего сервиса, то можно использовать более дорогой сервис под капотом для тестирования. Например, для тестирования приложения доставки персональной еды можно использовать существующие сервисы доставки и рестораны. Да, Юнит-экономика⁴⁰ не будет сходиться, но можно сделать выводы о востребованности продукта и готовности пользователей за него платить. С появлением больших лингвистических моделей типа ChatGPT появилась возможность использовать его для решения более простых задач, вроде проверки корректности вводимых данных. Например, указал ли клиент отчество ребенка и совпадает ли оно с именем отца. В случае удачного эксперимента можно начать использовать более дешевые специализированные алгоритмы.

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

Популярный слоган адептов – «Fake it till you make it» («Имитируй, пока не сделаешь»).

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

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

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

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

Табл. 3.2. Пример записи гипотез и контргипотез пилотного проекта

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

Рис. 3.7. Связь процессов из оперативных контекстов с циклами открытия и поставки

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

Например:

1. Проработка идей того, какие гипотезы стоит проверить, – это запутанный мир, где следует применять Kanban.

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

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

4. Если в процессе появляется ранее воспроизводимая операция, то максимальную эффективность показывает водопад.

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

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

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

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