Ярослав Шуваев

Менеджмент цифрового продукта. От идеи до идеала

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

© Шуваев Я.А., текст, иллюстрации, 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. Анализ результатов для последующей генерации бизнес-требований.

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

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

Глава 1

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

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

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

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

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

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

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

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

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

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. и ряд других параметров, определяемых стейкхолдерами[5] (заинтересованными лицами). Если стейкхолдеры видят инвестиционный потенциал в инициативе, то она переходит на следующую фазу проработки. (Подробнее о концепции цифровой инициативы см. в п. 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. Кросс-функциональность разработчиков. Знания в смежных предметных областях позволяют приступить к разработке, не дожидаясь бутылочного горлышка[6] – участия узкоспециализированного эксперта. (Подробнее об этом см. в п. 3.2.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Исследование с применением прототипов. Применяется широкий диапазон прототипов различной степени приближенности к финальному продукту:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Ретроспектива спринта[17] – обязательное мероприятие, проводимое в конце каждой итерации, для повышения эффективности последующих. (Подробнее о ретроспективе спринта см. в п. 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, глубинные интервью), потом исследования рынка (конкурентный анализ, бенчмаркинг[18]), а потом оценка инвестиционной привлекательности. (Подробнее о бенчмаркинге см. в п. 4.3.3.4.)

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

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

Табл. 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 (англ, гибкость[20]). Основная идея этой концепции – короткие циклы поставки. Важно обратить внимание, что ключевое слово здесь «поставки». Подразумевается, что не реже чем раз в месяц жизнь пользователей становится лучше.

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

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

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

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

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

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

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

3.1. Agile

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

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

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

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

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

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

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

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

Например, я на практике наблюдал несколько волн джирафикации и деджирафикации, иногда даже в одной команде. Под джирафикацией я имею в виду внедрение инструмента управления задачами типа Jira[23]. Когда команда только запускалась, не было конкретных инструментов для отслеживания задач, команда работала, перемещая физические стикеры по Kanban-доске[24]. Через некоторое время команда внедрила диспетчер задач, и стало уходить заметно больше времени на ежедневные стендапы[25], так как приходилось тратить время на настройку и оперирование инструментом. Также часть времени уходила на «нарезание» задач на спринт. Потом, после очередного тренинга, команда начала делать очень короткие спринты и дробить функциональность на небольшие элементы (пользовательские истории[26]) размерностью менее одного дня разработки. На неделю спринта выходило 5–6 таких элементов, которые команда всем скопом каждый день доводила до релиз-кандидата[27]. При таком подходе отсутствовала необходимость в декомпозиции задач, так как каждый день задачи порождались и утилизировались в финальном артефакте. И команда опять перешла к физическим стикерам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2. Pull-документация. Тут применяется принцип втягивания вместо вталкивания. Часто бывает, что документация пишется про запас, и, если сделать замеры, можно увидеть, что часть документов генерируется впустую. Принцип вытягивания подразумевает, что документация генерируется по запросу. При этом современная документация – это не обязательно текст. Более эффективно и наглядно по времени может быть записать скринкаст[30] с объяснением голосом. Потом такое видео добавляется в базу знаний и отправляется по запросу. Подход втягивания имеет еще и культурно-оздоравлива-ющий эффект – разработчики начинают больше общаться и помогать новичкам вливаться, что отличается от культуры выталкивания, в которой новичка могут отправить штудировать обширную базу документов о продукте. Разумеется, принцип 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. Горизонтальная и вертикальная декомпозиция

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

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

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

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

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

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

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

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

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

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[33]). Подобный подход не дает возможности сфокусироваться на одной работе за раз и, не накапливая промежуточные артефакты, доводить дело до конца.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Например:

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

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

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

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

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

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

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

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

3.2. Scrum

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

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

Наиболее полное представление о Scrum можно получить из книги Джефа Сазерленда «Scrum: The Art of Doing Twice the Work in Half the Time» (дословно: «Scrum: искусство сделать вдвое больше за половину времени). Официальное название книги в России – «Scrum: Революционный метод управления проектами», однако, несмотря на возможную коммерческую эффективность, этот перевод содержит ряд неточностей: Scrum HE революционный HE метод HE управления HE проектами.

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

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

➠ Scrum НЕ для управления проектами. Как уже говорилось ранее, Scrum ориентирован на продуктовый подход; он следует итеративной, адаптивной инкрементальной поставке ценности.

Scrum является эмпирическим процессом управления, что означает, что знания и понимание развиваются на основе опыта и наблюдений. Этот подход основывается на трех основных столпах: прозрачности (transparency), инспектировании (inspection) и адаптации (adaptation).

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

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

➠ Адаптация означает изменение подхода или процесса на основе этих наблюдений для оптимизации результатов.

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

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

3.2.1. Роли в Scrum

В Scrum три роли:

➠ Scrum-мастер (Scrum master, SM)

➠ Владелец продукта (Product owner, РО)

➠ Команда разработки (Development team, DT), вся команда – одна роль.

Вместе они составляют Scrum-команду (Scrum team, ST).

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

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

Рис. 3.8. Классический треугольник компромиссов

Рис. 3.9. Треугольник компромиссов, адаптированный для Scrum

Команда разработки (DT) фокусируется на качестве. Владелец продукта (РО) – на возвратности инвестиций (Return of Investments, ROI). Так как продуктовый процесс не ограничен во времени, нет фиксированного бюджета и РО нужно следить, чтобы каждый спринт был максимально эффективным вложением.

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

3.2.1.1. Scrum-команда

Scrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.

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

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

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

Scrum-команда полностью самостоятельна и наделена полной властью для достижения целей спринта, а следовательно, самостоятельно несет ответственность за взаимодействие со стейкхолдерами, сопровождение, операционную деятельность, исследования, R&D и все остальное, что может понадобиться в процессе.

ST наделена всеми полномочиями на управление собственной структурой и процессами.

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

3.2.1.2. Лучшие практики организации Scrum-команд

Самостоятельность

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

➠ Ждем, пока юристы согласуют формулировку.

➠ Ждем, пока другая команда развернет обновление API.

➠ Ждем, пока Scrum-мастер перенесет истории из продуктового бэклога в бэклог спринта и т. д.

Несколько практик по работе с внешними зависимостями:

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

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

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

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

Вертикальная интеграция

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

➠ Бизнес-блок. Компания подразделяется на несколько бизнес-блоков. Каждый из них автономен с точки зрения внутренней экономики, имеет обособленный P&L, за который отвечает руководитель блока.

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

➠ Отряд – минимальная автономная команда (например, Scrum-команда), разрабатывающая продукт или компонент. Владелец продукта отвечает за возврат инвестиций в разработку продукта.

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

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

Хороший подход, когда продуктовая команда самостоятельно отвечает за качество на уровне определения завершенности (Definition of Done, DoD).

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

Помимо таких достаточно простых примеров, есть менее очевидные, например команда, образованная вокруг систем, заново используемых другими продуктами, таких как единая точка входа (single sign-on, SSO), рекомендательная система или система мониторинга.

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

Коллективное владение системой

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

Практика коллективного владения системой основана на практике коллективного владения кодом из экстремального программирования (extreme programming, ХР).

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

Рис. 3.10. Виртуальная команда

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

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

Табл. 3.3. Сравнение коллективного и централизованного владения системами

* Дашборд (англ, dashboard) – это интерактивная панель, на которой отображаются все метрики из гипотез жизнеспособности продукта в режиме реального времени.

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

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

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

3.2.1.2. Команда разработки

Команда разработки (development team, DT), или разработчики – это часть Scrum-команды, которая берет на себя обязательство поставлять полезный инкремент каждый спринт. Команда обладает всеми необходимыми навыками в операционном домене[41] и отвечает за:

➠ формирование бэклога спринта и плана достижения целей спринта;

➠ развитие качества путем соблюдения и дополнения определения завершенности (DoD);

➠ ежедневную адаптацию плана для достижения цели спринта;

➠ профессионализм друг перед другом.

3.2.2. Лучшие практики

3.2.2.1. Т-образные специалисты

Т-образные (англ. T-shaped, в форме буквы «Т») специалисты названы так по способу формирования компетенций и представляют собой комбинацию специалистов широкого профиля (dash-shape, или тиреобразные) и узких специалистов глубокого профиля (I-shape, или 1-образные). Т-образные специалисты глубоко разбираются в одной экспертизе, но при этом на базовом уровне разбираются в смежных (рис. 3.11).

Рис. 3.11. Способы формирования компетенций. Т-, I- и «-»-образные специалисты

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

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

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

Рис. 3.12. Звездная карта

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

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

Сейчас, с развитием Agile, растет потребность в фулстек-разработчиках (от англ, full stack, полный стек[43]), и вакансий с каждым годом становится все больше.

3.2.2.2. Минимальная команда

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

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

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

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

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

3.2.2.3. Долгое время вместе

Изменение состава команды нарушает внутренние равновесие и перезапускает процесс ее формирования.

Рис. 3.13. Стадии формирования групп по Брюсу Такману

Брюс Такман в 1961 году предложил модель групповой динамики, согласно которой команда проходит четыре стадии формирования (рис. 3.13):

➠ формирование (forming),

➠ шторм (storming),

➠ нормирование (norming),

➠ производительность (performing).

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

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

3.2.2.4. Владелец продукта

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

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

➠ разработку и детальное донесение цели продукта;

➠ разработку и ясное донесение элементов продуктового бэк-лога;

➠ приоритизацию элементов продуктового бэклога;

➠ обеспечение доступности, прозрачности и понятности продуктового бэклога.

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

Плохо, когда владелец продукта:

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

➠ Перегружен работой: будет терять контекст.

➠ Совмещает: не будет нести ответственность в трудной ситуации.

➠ Работает удаленно: будет недоступен в срочной ситуации и часто неправильно понят.

➠ Прокси: будет задерживать и искажать сигнал от реального РО.

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

➠ Комитет: решения будут затягиваться.

➠ Не заинтересован: команда будет демотивирована бесполезным трудом.

➠ Боится: страх парализует и заставляет имитировать работу.

3.2.2.5. Scrum-мастер

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

➠ развивает команду в сторону самоорганизации и кросс-функциональности;

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

➠ убирает препятствия в прогрессе команды;

➠ фасилитирует события Scrum для регулярного увеличения их эффективности.

Scrum-мастер помогает владельцу продукта ⁄ Scrum-команде:

➠ внедрить эффективные процессы определения цели продукта и управления бэклогом продукта;

➠ эффективно действовать в комплексном мире (см. п. З.1.З.);

➠ поддерживать ясное понимание элементов продуктового бэклога;

➠ организовать взаимодействие со стейкхолдерами, фасилитировать встречи.

На уровне организации Scrum-мастер:

➠ возглавляет и активно участвует во внедрении Scrum;

➠ участвует в планировании мероприятий по внедрению;

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

➠ убирает препятствия между стейкхолдерами и Scrum-командой.

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

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

Плохо, если Scrum-мастер:

➠ Проджект-менеджер: это противоречие на уровне операционных окружений по модели «Киневин», рассмотренной в п. 3.1.3.

➠ Прокси: чью бы волю ни выполнял – РО, СТО, SH[45], – в команде образуется несправедливый перекос;

➠ Частичный: SM, который работает на две и более команды, по-настоящему не болеет ни за одну из них;

➠ Нянька: потакая капризам команды, убивает в них самостоятельность;

➠ Трусливый: боится настоять на правильном процессе, из-за чего Scrum превратиться в Scream.

3.2.3. События Scrum

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

Табл. 3.4. Краткое описание событий и процессов Scrum

Создатели Scrum выявили все обязательные типы событий, необходимых для разработки, и определили рекомендованную нормативную длительность (табл. 3.4).

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

3.2.3.1. Краткое описание событий Scrum

Для начала давайте рассмотрим «скелет» событий Scrum (рис. 3.14).

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

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

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

➠ В конце спринта Scrum-команда собирается для обзора. Владелец продукта инспектирует инкремент продукта и определяет готовность, согласно определению завершенности.

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

Затем все повторяется.

Рис. 3.14. Scrum: схема процесса

3.2.3.2. Лучшие практики организации расписания событий Scrum

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

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

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

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

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

3.2.3.3. Планирование спринта

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

На планировании нужно закрыть несколько тем.

Тема 1. Почему этот спринт важен?

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

Тема 2. Что будет сделано во время спринта?

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

Тема 3. Как это будет сделано?

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

3.2.3.4. Лучшие практики планирования

➠ Не менять длину спринта. У команды вырабатывается определенный ритм и определенные внутренние ритуалы. Фиксированная длина спринта позволяет эффективно оценивать его объем и собирать статистику.

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

➠ Учитывать отпуска и болезни. Это влияет на то, какие истории и в каком объеме могут быть взяты в спринт.

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

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

➠ Чрезвычайный буфер (emergency buffer). Если почти каждый спринт из-за чрезвычайных ситуаций запланированный объем выполняется не в полной мере, нужно зарезервировать несколько единиц объема под такие работы и делать поправку при планировании.

3.2.3.5. Ежедневный Scrum

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

Цель ежедневного Scrum – обменяться статусами, планами и определить препятствия к достижению цели спринта.

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

➠ что было сделано вчера;

➠ что запланировано на сегодня;

➠ какие препятствия могут помешать выполнить запланированный объем в срок.

Часто для визуализации используется Scrum-доска (см. п. 3.1.3.6.). В этом случае каждый участник передвигает свои задачи по Kanban-доске для изменения статуса (рис. 3.7).

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

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

3.2.3.6. Обзор спринта

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

3.2.3.7. Лучшие практики обзора спринта

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

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

➠ Выставочное демо (trade show demo). По аналогии с выставкой для каждого реализованного элемента создается «выставочный павильон». Реальные пользователи, стейкхолдеры и другие участники проходят через все павильоны и тестируют функциональность, а представители команды в каждом павильоне фиксируют озарения для улучшений в продукте. Такой подход позволяет протестировать инкремент сразу на нескольких пользователях за ограниченное время.

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

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

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

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

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

Важно, чтобы каждый член команды мог высказаться.

3.2.3.9. Лучшие практики ретроспективы

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

➠ Обсуждение положительных моментов в формате благодарения (thanksgiving retro). Участники говорят спасибо за положительные моменты, которые помогали. Это сплачивает и настраивает на позитивную коммуникацию.

➠ Последовательность «коуч – наставник – учитель». Паттерн для Scrum-мастера, который позволяет генерировать проблемы максимально эффективно:

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

➠ если это не приносит результатов, всем предлагается вспомнить лучшие практики из опыта (наставник);

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

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

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

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

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

3.2.3.10. Прояснение бэклога

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

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

Сессии прояснения бэклога позволяют минимизировать неопределенность перед планированием и планировать максимально эффективно.

Руководство по Scrum не регламентирует, какими должны быть элементы продуктового бэклога (product backlog items, или PBI), но без сомнений можно сказать, что самый популярный тип – это пользовательская история. Вторым по популярности можно считать Spike, появившийся впервые в экстремальном программировании. Впоследствии популярный фреймворк масштабирования Agile, SAFe (Scaled Agile Framework), внес Spike в состав более широкого класса сущностей – энейблеров. Они бывают нескольких размерностей – от энейблер-эпик (enabler epic) до энейблер-истории (enabler story). Так как далее в нашем контексте мы будем обсуждать размеренность уровня истории, то для краткости будем использовать термин «энейблер» в отношении «энейблер-история».

Типы элементов продуктового бэклога представлены в табл. 3.5.

Табл. 3.5. Элементы продуктового бэклога

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

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

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

Табл. 3.6. Пример продуктового бэклога и горизонты планирования и декомпозиции

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

В табл. 3.6 приведен пример бэклога. Команда быстро может набрать истории в спринт, ориентируясь на прошлые показатели. Остается запас оцененных историй на 1–2 спринта, благодаря чему команда может планировать спринты самостоятельно, в исключительной ситуации, когда владелец продукта не смог участвовать. Также запас позволяет варьировать скоуп[47] спринта, и лучше его заполнять. В табл. 3.6 владелец продукта понизил приоритет одной из историй во время планирования для более эффективного заполнения объема спринта.

Для эффективной подготовки элементов к планированию, по аналогии с определением завершенности (DoD), вводят понятие определение готовности (Definition of Ready, DoR).

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

По аналогии с DoD, DoR формируется командой самостоятельно в процессе работы.

Табл. 3.7. Акроним INVEST как основа для определения завершенности

Для старта подойдет популярная группа критериев, названная INVEST по первым буквам (табл. 3.7).

Помимо INVEST, в DoR могу входить и другие критерии в зависимости от домена, например, «описание соответствует шаблону юзерстори», «готов дизайн-макет» или «написан тест-кейс».

3.2.3.11. Декомпозиция элементов продуктового бэклога

История, которая не умещается в один спринт и обычно занимает до одного квартала разработки, называется эпик (epic story). Для декомпозиции эпиков используются инструменты декомпозиции, такие как картирование пользовательской истории (user story mapping). Далее, если история недостаточно маленькая, ее разбивают снова, используя шаблоны декомпозиции.

3.2.3.12. Картирование пользовательских историй

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

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

Такой подход позволяет собрать все идеи реализации, отсортировать их и распределить по релизам.

В сторимэпе выделяется четыре слоя:

➠ Роль – смена ролей в процессе взаимодействия; иногда их может быть несколько.

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

➠ Шаг – атомарный элемент пользовательского путешествия.

➠ Особенности – идеи того, как может быть реализован шаг.

Рис. 3.15. Пример карты пользовательской истории

Процесс картирования пользовательской истории

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

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

3. В процессе размещаются новые активности и роли.

4. После этого для каждого шага описывается особенности – то, как он может быть реализован.

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

6. Особенности распределяются по релизам.

7. В первый релиз выделяют то, без чего действительно невозможно обойтись (минимально жизнеспособный релиз).

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

3.2.3.13. Связь карты пользовательской истории и бэклога продукта

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

Табл. 3.8. Пример бэклога для одного релиза, сформированного на основе карты пользовательской истории (рис. 3.6)

3.2.3.14. Шаблоны декомпозиции

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

Разбиение по «и/или»

Если в описании истории используется «И/ИЛИ», значит, можно разделить прямо по этим союзам. Это относится и к спискам, разделенным запятыми.

Пример:

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

Можно разделить на:

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

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

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

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

Разбиение на операции

Известный представитель такого типа шаблонов – CRUD. Название шаблона – это аббревиатура из первых букв действий, которые можно совершать со списком: Create, Read, Update, Delete (Создать, Прочитать, Обновить, Удалить).

Историю «Я как пользователь могу редактировать список разделов» люжно разделить на:

Я как пользователь могу создать раздел.

Я как пользователь могу видеть список разделов.

Я как пользователь могу редактировать раздел.

Я как пользователь могу удалить раздел.

Разделение по этапам процесса

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

Я как контент-менеджер могу публиковать материал напрямую на сайте.

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

Я как корректор могу проверить материал перед отправкой.

Я как редактор могу проверить материал перед отправкой.

Если внимательно приглядеться, история «Я как пользователь могу ввести e-mail, чтобы зарегистрироваться» может быть разбита на три атомарных этапа:

Я как пользователь могу просто ввести e-mail.

Я как пользователь могу увидеть, что e-mail не соответствует шаблону name @domain.zone.

Я как пользователь могу увидеть, что введенный e-mail уже существует.

Разделение по производительности

Историю «Я как пользователь могу получать изображение в реальном времени» можно разбить на варианты «заставить работать» и «работать быстро»:

Я как пользователь могу получать изображение.

Я как пользователь могу получать изображение менее чем за 5 секунд.

Я как пользователь могу получать изображение менее чем за 1 секунду.

Этот шаблон может быть применим для:

➠ времени выполнения;

➠ времени доступности;

➠ качества контента и пр.

Разделение по сегментам пользователей

Историю «Я как пользователь могу распознать текст на фото» можно разделить на:

Я как пользователь iOS версии выше 17 могу распознать текст на фото.

Я как пользователь Android версии выше 13 могу распознать текст на фото.

Этот шаблон может быть применим для:

➠ типов устройств – настольные, мобильные;

➠ операционных систем и их версий – iOS, Android;

➠ лояльности – сотрудник компании, друзья и родственники, бета-тестер, постоянные клиенты, члены команды;

➠ сегментов обслуживания – премиальные, массовые.

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

3.2.3.15. Оценка элементов продуктового бэклога

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

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

Давайте проследим эволюцию способов оценки.

Индивидуальная оценка личного вклада в человеко-часах

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

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

Минусы:

➠ требует много времени;

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

➠ перестраховка при новых задачах;

➠ пессимизм в оценке других;

➠ подгонка срока под оценку.

Оценка тимлидами в человеко-часах

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

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

Минусы:

➠ сложность учета параллельности и взаимопомощи;

➠ исполнители не отвечают за срок.

Рубашечная оценка тимлидами (XS, S, M, L, X, XL)

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

Этот подход получил название «рубашечная оценка» по аналогии с размерами рубашек – XS, S, M, L, XL (рис. 3.16). Нагрузка на тимлидов при оценке значительно снизилась при сопоставимой точности.

Минусы:

➠ исполнители не отвечают за срок;

➠ сложно почувствовать разницу между размерами рубашек.

Рис. 3.16. Название размеров неочевидно связано с физическими размерами футболок, что затрудняет оценку

Рубашечная оценка командой

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

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

Минусы:

➠ сложно почувствовать разницу между размерами рубашек;

➠ конформизм.

Покерная рубашечная оценка командой

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

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

Минусы:

➠ сложно почувствовать разницу между размерами.

Покерная усредненная оценка в относительных единицах

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

Рис. 3.17. Командная оценка в относительных единицах дает хороший баланс интуитивности, скорости и качества

Минусы:

➠ не заметны крайние значения;

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

Покерная усредненная оценка в относительных единицах Фибоначчи

Следующий шаг эволюции, когда оценки возрастают не линейно, а по ряду Фибоначчи: 1, 2, 3, 5, 8, 13, 21… Это делает краевые значения очень заметными, но усугубляет проблему влияния экстремальных оценок на среднее.

Минусы:

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

Покерная медианная оценка в относительных единицах Фибоначчи

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

Например, для оценок 1, 2, 3, 2, 1, 15 медиана будет равна 2, а среднее – 4 (рис. 3.18).

Рис. 3.18. Медианная оценка позволяет избежать влияния выбросов

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

Рассмотрим пример того, как происходит оценка.

Scrum-мастер (SM): Следующая история из бэклога для оценки: «Я как пользователь могу согласиться с правилами сервиса».

SM: Все готовы оценить?

Команда разработки (Ш):Да!)

SM: Прошу проставить оценки.

SM: Все поставили оценки?

DT.-Да!)

SM: Вскрываемся. Получились следующие оценки: 1, 2, 3, 2, 1, 15, медиана равна 2. Все согласны на оценку 2?

Backend (BE): Я не согласен.

SM: Почему ты считаешь, что это больше, чем история на 2?

BE: Нужно сохранять статус согласия на бэке.

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

SM: Разобьем историю на несколько: «Я как пользователь могу согласиться с правилами без повторного запроса на все время браузерной сессии» и «Я как пользователь могу согласиться с правилами без повторного запроса на разных устройствах».

3.2.3.16. Отмена спринта

Бывают такие ситуации, когда нет смысла продолжать спринт. В этом случае Scrum-команда договаривается остановить спринт (рис. 3.19).

Рис. 3.19. Схема разделения одного спринта на два при выполнении остановки спринта

В день остановки проводятся завершающие события спринта – демо и ретро.

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

3.2.4. Артефакты Scrum

Артефакты Scrum созданы для фиксации обязательств и прозрачности:

➠ Бэклог продукта – обязательства по цели продукта.

➠ Бэклог спринта – обязательства по цели спринта.

➠ Инкремент – обязательства в соответствии с определением завершенности.

3.2.4.1. Бэклог продукта

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

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

Обязательство: цель продукта

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

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

Scrum-команда работает в направлении достижения цели продукта. (Подробнее о том, как эффективно описывать цель продукта, см. в п. 4.3.6.)

Типы элементов бэклога

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

Пользовательская история

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

Наибольшую популярность получил шаблон, описанный Майком Коном (рис. 3.20).

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

Энейблер

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

Рис. 3.20. Шаблон пользовательской истории, описанный Майком Коном

В руководстве по фреймворкам масштабирования Agile SAFe выделяют четыре вида энейблеров:

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

➠ Архитектурный (architectural). Работы по повышению эффективности разработки и поддержки, например настройка CI/CD.

➠ Инфрастуктурный (infrastructural). Работы, направленные на оптимизацию инфраструктуры. Например, снижение стоимости владения или митигация рисков стабильности.

➠ Комплаенс (compliance). Работы по аудиту и приведению системы в соответствие стандартам, спецификациям, внешним и внутренним требованиям, например, приведение хранилища платежных данных в соответствие стандарту PCI DSS.

Критерии приемки

Обязательная часть пользовательской истории – критерии приемки (Acceptance Criteria, АС). Это описание того, в каких условиях будет тестироваться функциональность и какой ожидается результат.

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

Примеры связки US и АС можно увидеть в табл. 3.9.

Используется одна и та же формулировка US, но разные АС.

Табл. 3.9. Пример бэклога с разными критериями приемки

3.2.4.2. Бэклог спринта

Бэклог спринта (sprint backlog) – это план спринта для разработчиков. Прозрачная картина того, что было сделано для достижения цели спринта, актуализируемая каждый день на ежедневном Scrum.

Обязательство: цель спринта

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

Лучшие практики управление бэклогом спринта

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

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

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

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

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

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

Например: в начале разработки дизайнер и фронт-разработчик совместно рисуют схему расположения элементов, фокусируясь при этом на уже существующих компонентах. Фронт-разработчик и бэк-разработчик прописывают контракты[48] взаимодействия. QA (quality assurance, инженер, отвечающий за тестирование) создает моки[49] (mock) – тестовые данные, которые позволят фронту и бэку отлаживать базовые сценарии взаимодействия. В середине пути дизайнер создает макет более стильного и удобного интерфейса. Фронтенд элемент за элементом улучшает интерфейс согласно макету.

Бэкенд постепенно заменяет моковые методы на настоящие, a QA в реальном времени тестирует эти методы, адаптируя тест-кейсы. Бывает, что не все идеи дизайнера получается воплотить; в этом случае команда находит компромиссное решение (рис. 3.22).

Рис. 3.22 Управление качеством артефакта в процессе спринта

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

3.2.4.3. Инкремент продукта

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

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

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

Обязательство: определение завершенности

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

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

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

Пример определения завершенности

Часто бывает, что на старте члены Scrum-команды по-разному понимают значение Done (Выполнено). Владелец продукта ожидает, что функциональностью можно пользоваться реальным пользователям. Для разработчиков Done может значить, что код написан и ждет тестирования. DoD позволяет выравнивать ожидания.

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

Как уже стало заметно, DoD – мощнейший инструмент для управления требованиями к:

➠ производительности;

➠ архитектуре;

➠ безопасности;

➠ развертыванию;

➠ качеству кода;

➠ сбору аналитических данных;

➠ сравнительным экспериментам;

➠ дизайну;

➠ документации;

➠ инфраструктуре;

➠ ролям;

➠ процессам;

➠ требованиям;

➠ обслуживанию;

➠ автоматизации тестирования;

➠ процессам тестирования.

Табл. 3.10. Пример определения завершенности (DoD)

Важно как можно раньше начинать развивать DoD для подготовки к фазе масштабирования.

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

3.3. Управление качеством программного обеспечения

Качество программного обеспечения – это соответствие функциональным и не функциональным требованиям.

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

Нефункциональные требования (non-functional requirements, NFR) описывают, как будет работать система. Как правило, это перечень атрибутов и критериев их соответствия, в большинстве случаев говорят про атрибуты качества.

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

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

3.3.1. Запланированное улучшение качества системы

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

Владелец продукта предоставляет данные финансовой модели, по которым определяются атрибуты и критерии на горизонте 3–6 месяцев. Например:

➠ Количество активных пользователей в день – от 10 тыс. до 100 тыс. человек.

➠ Объем хранимых данных на пользователя – от 3 до 6 мб.

➠ Раздача видео потока на одного пользователя – до 100 мб/мес.

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

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

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

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

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

3.3.2. Незапланированное улучшение качества системы

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

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

При необходимости добавляются сессии прояснения бэклога.

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

3.3.3. Запланированное ухудшение качества системы

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

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

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

Табл. 3.11. Пример планирования ухудшения качества в бэклоге

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

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

Лучшие практики по работе с запланированным ухудшением качества

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

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

➠ Оперативно устранять известные запланированные ухудшения в системе.

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

➠ Выделить в бэклоге спринта определенный буфер под работы по устранению техдолга.

3.3.4. Незапланированное ухудшение качества системы (дефекты)

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

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

Лучшие практики по работе с дефектами

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

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

➠ В бэклоге спринта выделяется определенный буфер под работы по устранению дефектов.

3.3.5. Масштабирование гибких подходов

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

Масштабирование гибких подходов происходит в двух случаях: масштабирование в процессе роста и масштабирование внутри уже существующей компании.

3.3.5.1. Масштабирование в процессе роста

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

3.3.5.2. Масштабирование в уже существующей компании

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

Рис. 3.23. Горизонтально интегрированная компания

Если в компании полностью отсутствует гибкая культура, то ее называют горизонтально интегрированной (рис. 3.23). В такой компании подразделения объединены вокруг функций. Например, юридический департамент, финансовый, проектный офис, департамент информационной безопасности, департамент информационных технологий и т. д. Каждый из них работает по принципу конвейера и имеет свой норматив прохождения артефактов, как правило, документов. Например, много лет назад в одном банке норматив времени на рассмотрение документов юристами составлял две недели, при этом не было точной уверенности, что после этого не придется отправлять документ на повторное рассмотрение. Функциональные департаменты не заинтересованы в бизнес-результате, а следовательно, сотрудники не хотят рисковать ради него репутацией. Люди скорее склонны творчески выявлять риски, чем их творчески устранять. В результате на каждом этаже происходит значительная задержка. Трансформация идеи в ценность для клиента может происходить так долго, что теряется актуальность, и выпущенный продукт на старте уже нуждается в значительной доработке. Стоит ли говорить, что доработка тоже может потерять актуальность, пройдя через этажи. Горизонтально интегрированные организации очень негибки к внезапным изменениям.

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

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

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

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

Рис. 3.24. Частично-вертикальная компания

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

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

Рис. 3.25. Вертикально интегрированная компания

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

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

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

3.3.6. Понятие и цели масштабирования гибких подходов

Когда мы только запускали Ак Барс Цифровые Технологии, в компании было около 14 разработчиков, а когда я уходил, она насчитывала 350 человек. Мы организовали и запустили несколько Agile-команд, потом их количество увеличивалось, появились трайбы, с внедрением SAFe образовалась практика квартального планирования с привлечением руководителей бизнес-блоков. И вот из горизонтально-интегрированной компания пришла к высокой степени вертикальной интеграции. Если гибкий подход внедрен правильно, с соответствующей культурой и принятием на уровне ценностей всей компанией, то при наличии быстрых видимых побед процесс масштабирования гибких подходов будет проходить естественно и органично.

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

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

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

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

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

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

3.3.7. Основные принципы и практики масштабирования гибких подходов

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

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

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

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

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

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

3.3.8. Основные фреймворки и модели масштабирования гибких подходов

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

3.3.8.1. Модель Spotify

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

Без сомнения, модель Spotify – одна из самых часто упоминаемых в процессе масштабирования гибких подходов. Многие элементы, упомянутые в их обучающем видео Spotify Engineering Culture в 2014 году, входят в состав проприетарных Agile-фреймворков[50] крупнейших компаний.

Рис. 3.26. Модель Spotify

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

➠ Отделение (chapter, часто говорят «чаптер») – это группа людей с одинаковым набором навыков или функций, например фронтенд-разработчики, тестировщики, дизайнеры и т. д. Отделение формируется внутри племени, которое представляет собой большую группу людей, работающих над одним продуктом или доменом. Цель отделения – развивать навыки его членов и поддерживать обмен информацией и последовательность. Отделение возглавляет лидер (также известный как чаптерлид), который является линейным руководителем членов отделения и поддерживает их в личностном росте и решении конкретных задач. Отделение регулярно собирается для обсуждения лучших практик, стандартов и общих проблем. Часто отделения называют центрами практик или центрами компетенции[51].

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

Еще один компонент, который нельзя не упомянуть, – это механизм поезда поставок (release train). Он позволяет нескольким командам работать над одним продуктом, чтобы при слиянии инкремент одной команды не ломал инкременты других. Производится ритмичное тестирование поставки релиз-кандидата по расписанию, по аналогии с поездом, который отходит в определенное время. Если инкремент не успевает на поезд, то не вливается в поставку, а если не проходит тестирование (ломает другие инкременты), то не вливается в поставку или вливается с отключенным feature-toggle (в отключенном состоянии при помощи механизма feature-toggling, описанном в 2.1.7).

3.3.8.2. Scaled Agile Framework

Scaled Agile Framework (SAFe)[52] – это гибкий фреймворк для разработки и поставки продуктов и решений, который позволяет масштабировать Agile-подходы на уровне предприятия. SAFe основан на принципах Lean и Agile, а также включает в себя четыре уровня: командный, программный, большого решения и портфельный. SAFe предлагает ряд ролей, артефактов и процессов, которые помогают координировать и синхронизировать работу множества команд, работающих над одним или несколькими продуктами или решениями. Он также поддерживает различные конфигурации в зависимости от размера и сложности организации и продукта.

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

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

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

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

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

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

Многие считают SAFe противоположностью LeSS из-за фокуса второго на минимальность управляющих ролей.

3.3.8.3. Scrum@Scale

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

До определенного уровня новые роли не выделяются, и ответственность за вопросы масштаба ложится на Scrum-мастеров и владельцев продукта. Одна из идей – выстраивание организации по фрактальному принципу. Каждые пять команд объединяются в Scrum of Scrums (SoS), которые, в свою очередь, могут соединяться в SoSoS. В каждом SoS появляются свои события, например масштабированный дневной Scrum (scaled daily Scrum), на котором присутствуют представители команд для синхронизации.

Рис. 3.27. Модель Scrum@Scale

Согласно некоторым исследованиям, Scrum@Scale занимает пятое место в мире по популярности, но не очень распространен в России. Хотя практика Scrum of Scrums, согласно исследованиям, в России достаточно распространена.

Помимо перечисленных, существует много других популярных фреймворков, таких как Nexus и Disciplined Agile (DA), которые имеет смысл изучить, внедряя масштабирование гибких подходов в организации.

Глава 4

Цикл открытия

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

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

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

4.1. Основные принципы управления портфелем инициатив

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

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

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

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

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

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

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

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

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

➠ Создание нового продукта.

➠ Доработка существующего продукта.

➠ Рекламная кампания по привлечению пользователей в новый продукт.

➠ PR-кампания для запуска новых фич в продукте.

➠ Миграция на облачное решение.

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

Жизненный цикл инициативы можно разделить на несколько этапов:

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

Рис. 4.1. Опережающие метрики позволяют заранее определить прибыльность

➠ Приоритизация концепций инициатив. Стейкхолдеры на основании презентации владельца продукта приоритизируют список концепций.

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

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

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

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

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

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

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

4.1.1. Организация конвейера открытий

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

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

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

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

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

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

Процесс управления инициативами в цикле открытия может называться по-разному в зависимости от организации.

➠ Продуктовый конвейер (product pipeline). Обычно все инициативы проходят через продуктовый комитет, на котором рассматриваются изменения статусов инициатив и их приоритизация.

➠ Конвейер перспективных разработок (R&D pipeline). Через цикл открытий идут только инициативы, связанные с новыми сегментами или новыми потребностями, а инициативы типа «существующий продукт для существующего сегмента»

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

➠ Инновационный конвейер (innovation pipeline). Через цикл открытий идут только инициативы типа «новая потребность нового сегмента», а остальные могут идти по упрощенным схемам.

Подробнее о разделении инициатив по типам стратегических целей «потребность – сегмент» см. в п. 4.2.1.1.

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

4.1.1.1. Практики ускорения прохождения конвейера открытий

Быстрый трек (fast track). В компании определяется бюджет на MVP, которые могут проходить без комитетов. Для этого владелец продукта должен заполнить форму с атрибутами гипотезы инициативы. При этом ограничивается одновременное количество пилотных проектов в фазе мониторинга.

Система ставок, описанная в книге Э. Мейера и Р. Хастингса «Никаких правил. Уникальная культура Netflix», – это система, в которой владельцу продукта предоставляется определенный бюджет на эксперименты, который увеличивается в случае, если ставка сыграла.

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

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

4.1.2. Портфель инициатив

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

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

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

Портфель инициатив может включать разные типы инициатив, такие как:

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

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

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

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

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

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

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

➠ Увеличение стоимости подписки – увеличивает доход на пользователя в месяц.

Рис. 4.4. От перестановки инициатив в портфеле его доходность может меняться

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

Для качественного прогнозирования инвестиционных показателей портфеля и приоритизации инициатив применяется финансовое моделирование[53], про которое поговорим в п. 4.3.3.

Далее мы подробно рассмотрим этапы жизненного цикла инициатив.

4.2. Концепция цифровой инициативы

4.2.1. Формулирование концепции инициативы

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

Рис. 4.5. Квадрант типов стратегических целей

4.2.1.1. Анализ стратегических целей компании

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

Существуют четыре типа стратегических целей по этому квадранту (рис. 4.5):

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

• Исследование клиентского путешествия и последующее картирование (Customer Journey Mapping, CJM).

• Получение откровений (insight, инсайт) из интерфейсной аналитики.

• Опросы и интервью существующих клиентов.

• Встроенные опросы NPS (рассмотрим в п. 4.3.1.1) и оценки.

• Исследование клиентского путешествия в продуктах-конкурентах.

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

• Проблемные интервью – глубинные интервью по выявлению и уточнению потребности.

• Решенческие интервью – интервью по выявлению возможных решений и их востребованности.

• Конкурентный анализ – анализ того, как проблему решают другие организации.

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

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

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

4.2.1.2. Исследование клиентов и их потребностей

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

Картирование клиентского путешествия

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

Рис. 4.6. Карта клиентского путешествия (CJM)

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

Не существует единого стандарта CJM. Как правило, в процессе построения карты совмещаются несколько видов исследований для экономии времени.

Наиболее распространенные слои:

➠ Действия. Описание действий, которые совершает пользователь.

➠ Эмоции. Фиксация эмоций (обычно в виде emoji). Может быть автоматизировано при помощи систем распознавания лиц и эмоций.

➠ Мысли вслух (think-aloud). Фиксация того, как респондент проговаривает мысли, возникающие в процессе перехода с шага на шаг. Для автоматизации применяются инструменты транскрибации.

➠ Точки касания (touchpoints). Фиксация переходов между устройствами или приложениями в процессе взаимодействия с продуктом.

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

Пример регламента проведения картирования клиентского путешествия:

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

➠ Каждому респонденту предлагается протестировать одну или несколько функций продукта.

➠ Модератор объясняет респонденту контекст – ситуацию, в которой осуществляется использование продукта.

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

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

➠ Модератор включается в следующих случаях:

• Если пользователь зашел в тупик и не может двигаться дальше.

• Если респондент использует стоп-слова («не понятно», «дорого» и т. п.), останавливает и спрашивает, с чем респондент сравнивает.

• Если грустная эмоция не проговаривается, останавливает и спрашивает, что не понравилось респонденту и где он видел лучшую реализацию шага.

Рис. 4.7. Карта клиентского путешествия «как должно быть» (to be CJM) с приоритизацией доработок как в user story mapping

Одна и та же функциональность может быть протестирована для нескольких респондентов. В результате для каждой функции создается карта клиентского путешествия «как есть» (as is CJM). На основании карт «как есть» создается карта идеального путешествия «как должно быть» (to be CJM), которая содержит оптимальное количество шагов и их последовательность. Для каждого нового шага инсайты собираются, приоритизируются и группируются по аналогии с подходом, применяемым в user story mapping, рассмотренном ранее в п. 3.2.2.7. Пример to be CJM с приоритетом инсайтов для шагов можно увидеть на рис. 4.7.

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

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

Анализ интерфейсной аналитики

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

Системы интересной аналитики, такие как Yandex Metrica и Google Analytics, дают мощнейшие инструменты для поиска откровений на основе статистических данных о поведении пользователей.

В частности, такие инструменты, как Web Visor в Yandex Metrica, позволяют непосредственно наблюдать за поведением пользователей в записи. Это дает возможность строить CJM, основываясь на данных, но без комментариев пользователей.

Ключевыми источниками откровений являются цепочки конверсий[54] и показатели времени, затрачиваемые на шаг (рис. 4.8).

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

Рис. 4.8. Пример воронки конверсий

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

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

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

Подробнее о продуктовых метриках см. в п. 4.3.1.1.

Проблемные интервью

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

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

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

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

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

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

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

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

Пожалуй, самые актуальные практики проведения глубинных интервью можно встретить в подходе «работы к выполнению» (jobs to be done, JTBD).

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

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

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

➠ Осознает ли он, что такая потребность может существовать?

➠ Актуальна ли потребность для данного респондента?

➠ Определение интенсивности потребности.

Пример опросника проблемного интервью

Рассмотрим пример построения опросника проблемного интервью.

Возьмем стратегическую цель банка: продажа небанковских сервисов для малого и среднего бизнеса (МСБ). Формулируем потребность в виде работы. Для формулировки работы используем шаблон глагол + объект + контекст (опционально). Получилось следующее: «Получать небанковские бизнес-сервисы в мобильном приложении для бизнеса». Начинаем конструировать опросник.

Группа вопросов про осознание существования потребности

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

➠ Сталкивались вы с тем, что кому-то могут потребоваться небанковские бизнес-сервисы в мобильном приложении банка?

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

➠ Расскажите, как вы это видите?

Важно уточнить, что респондент понимает, о чем идет речь.

➠ Как давно это было?

Возможно, опыт уже не релевантен.

➠ Как часто возникает потребность?

Возможно, респондент не репрезентативен.

➠ Расскажите самую интересную историю, связанную с этим.

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

Группа вопросов про актуальность потребности для респондента

На этом этапе проясняется актуальность потребности для самого респондента. Добавляется обязательная триада вопросов на прояснение актуальности.

➠ Знакома ли вам потребность в небанковских сервисах? В чем это выражалось?

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

➠ Как давно возникала такая потребность?

➠ Как часто возникает такая потребность?

➠ Расскажите самую интересную историю, связанную с этим.

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

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

Группа вопросов по определению интенсивности потребности

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

➠ Насколько сильно вы ощущаете потребность в небанковских сервисах?

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

➠ В каких ситуациях потребность ощущается острее?

Уточнение контекста для определения наиболее подходящего решения.

➠ Опишите тех, для кого эта потребность стоит острее.

Уточнение свойств целевого клиентского сегмента.

➠ Опишите тех, для кого эта потребность менее значима.

Уточнение свойств нецелевого клиентского сегмента.

Решенческие интервью

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

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

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

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

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

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

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

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

➠ Подать налоговую декларацию.

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

➠ Составить типовой договор и т. д.

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

Для получения большего количества озарений можно воспользоваться методикой четырех сил, часто применяемой в одноименном подходе. Суть методики – определить барьеры и драйверы, которые заставят пользователя нанять[55] новое решение или остаться со старым.

Рис. 4.9. Четыре мотивационные силы

Выделяется четыре группы мотивационных сил (рис. 4.9):

➠ Толкает (push). Что подтолкнет к новому решению?

➠ Притягивает (pull). Что притягательного в новом решении?

➠ Удерживает (inertia). Что удерживает от использования нового решения?

➠ Тревожит (anxieties). Что тревожит в новом решении?

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

Составление опросника для решенческого интервью

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

➠ Как удовлетворяет потребность сейчас?

➠ Как удовлетворял раньше?

➠ Как хотел бы удовлетворять в будущем?

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

➠ Какое решение нанимает для выполнения работы?

➠ Какое решение нанимал до этого?

➠ Какие мотивационные силы повлияли на выбор решения?

➠ Знаком ли с новым решением?

➠ Какие мотивационные силы повлияли на выбор нового решения?

Пример опросника решенческого интервью

Продолжим пример про небанковские сервисы.

Блок вопросов для самостоятельной генерации решений:

➠ Какими небанковскими бизнес-сервисами вы пользуетесь?

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

➠ Как давно?

➠ Как часто?

➠ Расскажите интересную историю.

➠ Какими небанковскими бизнес-сервисами вы пользовались до этого?

➠ Что побудило перейти на новый сервис?

Далее повторяющийся блок вопросов для каждого потенциального решения, например, ИИ-бухгалтер (решение) для подачи налоговой декларации (работа):

➠ Как сейчас подаете налоговую декларацию?

➠ Что применяли для подачи налоговой декларации до этого?

➠ Что привлекло в новом способе подачи?

➠ Может, что-то заставило?

➠ Какие привычки удерживали от перехода на новый способ?

➠ Что беспокоило в новом способе?

➠ Знаете ли вы, что теперь И И-бухгалтер может подавать налоговую декларацию?

➠ Что бы побудило перейти на новый сервис?

Можно задать сразу два вопроса про драйверы в одном:

➠ Какие привычки или тревоги удержали бы от перехода на новый сервис?

Оценка востребованности инициатив

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

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

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

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

➠ Линейные (one-dimensional). Атрибуты, которые также являются основными, но в отличие от необходимых здесь удовлетворенность зависит от функциональности атрибута. Удовлетворенность может увеличиваться или уменьшаться. Вернемся к разговору о банковском мобильном приложении: быстрая скорость работы приложения будет положительно влиять на удовлетворенность клиентов, а высокая комиссия за переводы, наоборот, снижать ее.

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

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

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

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

➠ Функциональный: «Как вы относитесь к тому, что в банковском мобильном приложении можно создавать шаблоны платежей?»

➠ Дисфункциональный: «Как вы относитесь к тому, что в банковском мобильном приложении нельзя создавать шаблоны платежей?»

На каждый вопрос предлагается пять вариантов ответа:

➠ Нравится

➠ Ожидаю

➠ Все равно

➠ Потерплю

➠ Не нравится

Ответы обрабатываются при помощи матрицы Кано.

Каждой паре ответов респондента соответствует одно отношение к атрибуту:

➠ M – необходимые;

➠ L – линейные;

➠ A – привлекательные;

➠ I – безразличные;

➠ R – отталкивающие;

➠ Q – спорные – указывают на ошибку в ответах респондентов или в интерпретации.

Соответствие отношений и пар ответов приведены в табл. 4.10. Затем для каждого атрибута выбирается самое популярное отношение.

Табл. 4.10. Матрица интерпретации ответов на опрос по модели Кано

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

4.2.1.3. Анализ внешней среды

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

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

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

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

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

➠ Матрица сравнения функциональности (feature comparison matrix). Метод анализа микросреды, который позволяет сравнить наличие или отсутствие особенностей у конкурентов (табл. 4.1).

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

Табл. 4.1. Матрица сравнения функциональности

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

В связи с этим важно обратить внимание на два типа решений:

➠ Дифференциаторы. Привлекательные решения в вашем продукте, которые отсутствуют у конкурентов.

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

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

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

4.2.1.4. Описание концепции инициативы

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

Продуктовое видение

Одним из лучших инструментов для фиксации описания концепции инициативы можно считать шаблон продуктового видения (product vision statement), описанного Джеффри Муром в книге «Преодоление пропасти».

Использование шаблона продуктового видения:

➠ помогает сформулировать суть и ценность продукта или услуги в одном или двух предложениях, которые легко запомнить и передать другим людям;

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

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

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

Шаблон продуктового видения: «Для [Клиентский Сегмент], кто испытывает [Потребность], [Решение] [Категория или описание], дает возможность [Ключевые выгоды]. В отличие от [Основной конкурент], наше решение [Основное отличие]».

Пример формулировки: «Для МСБ-клиентов[56], кому нужно отправлять налоговую декларацию, И И-бухгалтер – небанковский бизнес-сервис – дает возможность сформировать и отправить декларацию автоматически. В отличие от аутсорс-бухгалтера, наше решение доступно 24/7».

Бережливый холст

Помимо шаблона продуктового видения существует еще один удобный инструмент для описания концепций инициатив – бережливый холст (lean canvas).

Бережливый холст – это одностраничный шаблон, который помогает декомпозировать идею в ее основные предпосылки и создать бизнес-модель, оптимизированную для бережливого стартапа (lean startup). Бережливый холст был разработан Ашем Маурьей (Ash Maurya) на основе холста бизнес-модели (business model canvas) Александра Остервальдера (Alexander Osterwalder).

Бережливый холст позволяет:

➠ сфокусироваться на самых важных и рискованных аспектах инициативы, а не на деталях и технических решениях;

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

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

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

Бережливый холст состоит из девяти блоков, которые отражают следующие элементы бизнес-модели:

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

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

➠ Уникальное ценностное предложение. Какое уникальное решение вы предлагаете своим клиентам, какое выгодное отличие вы имеете от конкурентов, какое обещание вы даете своим клиентам.

➠ «Нечестное» преимущество. Почему именно наша компания справится лучше, чем остальные.

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

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

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

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

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

В табл. 4.2 приведен пример заполненного бережливого холста.

Табл. 4.2. Пример заполненного бережливого холста

4.2.1.5. Оценка ресурсов

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

Помимо тех атрибутов инициативы, которые были сформулированы на этапе концепции, понадобятся следующие:

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

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

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

➠ Перечень гипотез жизнеспособности. Список метрик их значений, при достижении которых продукт можно считать жизнеспособным.

Создание перечисленных артефактов требует следующих трудозатрат:

➠ Декомпозиция решения и оценка трудозатрат на разработку.

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

➠ Анализ объема рынка и покупательской активности.

➠ Анализ данных продукта.

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

➠ Финансовое моделирование.

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

4.2.1.6. Составление презентации концепции инициативы

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

Рис. 4.11. Шаблоны презентации концепции

4.2.2. Приоритизация концепций инициатив

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

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

4.2.2.1. RICE

RICE – это аббревиатура от четырех факторов, которые предлагается использовать для оценки каждой идеи проекта: охват (reach), влияние (impact), уверенность (confidence) и усилия (effort).

Что означает каждый из параметров и как его можно оценить количественно:

➠ Охват: сколько пользователей затронет идея за определенный период? Пример: пользователей в квартал, транзакций в месяц.

➠ Влияние: какое влияние идея окажет на пользователя? 3 – огромное, 2 – высокое, 1 – среднее, 0,5 – слабое. Пример: насколько идея повлияет на коэффициент конверсии?

➠ Уверенность: насколько мы можем быть уверены в своей оценке параметров reach и impact? Как много данных у нас есть, чтобы подтвердить свою оценку? 100 % – высокая достоверность, 80 % – средняя, 50 % – низкая.

➠ Усилие: сколько времени потребуется инвестировать в идею (продукт, дизайн, разработку)? Параметр оценивается в человеко-месяцах.

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

4.2.2.2. MoSCoW

MoSCoW – это метод приоритизации, который основан на разделении идей на четыре категории по степени их важности: must have (обязательно реализовать), should have (желательно реализовать), could have (можно реализовать, если останется время и ресурсы), won’t have (не будут реализованы в ближайшее время). Что означает каждая из категорий?

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

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

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

➠ Won’t have: идеи, которые не соответствуют текущей стратегии продукта или не приносят достаточно ценности для пользователей или бизнеса. Это низкоприоритетные функции, которые не будут реализованы в ближайшее время. Пример: для интернет-магазина это возможность играть в онлайн-игры, слушать музыку или смотреть видео на сайте.

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

4.2.2.3. Точечное голосование

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

Количество точек может быть разным в зависимости от целей и контекста голосования. Например, можно использовать формулу N/3, где N – количество идей. Таким образом, каждый участник сможет проголосовать за треть идей. Или можно использовать фиксированное количество точек, например 10 или 100, и позволить участникам распределять их по своему усмотрению.

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

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

4.2.2.4. Процесс приоритизации

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

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

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

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

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

4.3. Гипотеза инициативы

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

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

4.3.1. Метрики продукта

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

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

➠ Метрики качества опыта показывают, насколько удобным, полезным и интересным является продукт для пользователей. Они помогают измерить и улучшить удовлетворенность, лояльность, вовлеченность и поведение пользователей. Примеры таких метрик: DAU, MAU, WAU, Retention Rate, Churn Rate, Session Duration и т. д.

➠ Метрики управленческого учета показывают, насколько эффективно и экономично управляется продукт. Они помогают контролировать и оптимизировать затраты, ресурсы, процессы и качество продукта. Примеры таких метрик: САС (customer acquisition cost), LTV (lifetime value), ARPU (average revenue per user), CRR (cost revenue ratio), NPS (net promoter score) и т. д.

➠ Инвестиционные метрики показывают, насколько привлекательным и рискованным является продукт с точки зрения инвесторов и стейкхолдеров. Они помогают оценить стоимость, доходность, рентабельность и неопределенность продукта. Примеры таких метрик: ROI (return on investment), NPV (net present value), IRR (internal rate of return), CAPM (capital assets pricing model) и т. д.

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

Рис. 4.12. Дерево метрик

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

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

4.3.1.1. Метрики качества опыта

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

Метрики удовлетворенности

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

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

➠ NPS (Net Promoter Score) – индекс лояльности клиентов; это метрика, которая показывает, насколько клиенты склонны рекомендовать продукт, услугу или компанию другим людям. Она измеряется с помощью опросов, в которых клиентам задается вопрос, например: «Насколько вероятно, что вы порекомендуете [продукт] своим друзьям или коллегам?» Предлагается оценить свой ответ по десятибалльной шкале (от «совсем невероятно» до «очень вероятно»). Затем клиенты делятся на три группы: промоутеры (ответили 9 или 10), пассивы (ответили 7 или 8) и детракторы (ответили от 0 до 6). Средний NPS рассчитывается как разность между процентом промоутеров и процентом детракторов.

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

➠ SUS (System Usability Scale) – шкала удобства использования системы; это метрика, которая показывает, насколько удобен, прост и эффективен продукт или система для пользователей. Она измеряется с помощью опросов, в которых пользователей просят согласиться или не согласиться с десятью утверждениями, касающимися различных аспектов удобства использования, по пятибалльной шкале (от «совершенно не согласен» до «совершенно согласен»). Средний SUS рассчитывается как сумма баллов за каждое утверждение, умноженная на 2,5 и выраженная в процентах.

➠ CES (Customer Effort Score) – индекс затрат клиента; это метрика, которая показывает, насколько легко или трудно для клиентов получить желаемый результат или решить свою проблему с помощью продукта, услуги или взаимодействия с компанией. Она измеряется с помощью опросов, в которых клиентам задается вопрос, например: «Как много усилий вам пришлось приложить, чтобы [действие]?» Предлагается оценить свой ответ по семибалльной шкале (от «очень много усилий» до «очень мало усилий»). Средний CES рассчитывается как среднее арифметическое всех ответов.

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

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

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

➠ Session duration – продолжительность сессии – это время, которое пользователь проводит в продукте за одно взаимодействие. Метрика показывает, насколько продукт захватывает и мотивирует пользователей и каких целей они достигают с помощью продукта.

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

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

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

4.3.1.2. Метрики управленческого учета

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

Одна из важных метрик – LTV (Lifetime Value) – пожизненная ценность клиента. Это показатель, который позволяет оценить, какую прибыль получает компания с одного клиента за весь период сотрудничества с ним. LTV зависит от двух других метрик: ARPU (average revenue per user) – средней выручки от одного пользователя и оттока (churn) – доли клиентов, которые прекращают пользоваться услугами компании.

Существует формула, которая связывает эти три метрики:

LTV = ARPU ⁄ Churn

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

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

Он утверждает, что для успешного бизнеса необходимо, чтобы С AC (Customer Acquisition Cost) – стоимость привлечения одного клиента – была меньше, чем LTV.

САС < LTV

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

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

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

Краткое описание популярных метрик управленческого учета:

➠ САС (Customer Acquisition Cost) – стоимость привлечения клиента; это сумма затрат, которые компания выделяет на привлечение одного нового клиента. Метрика показывает, насколько эффективны и экономичны маркетинговые и продажные усилия компании и как они влияют на прибыльность бизнеса.

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

➠ ARPU (Average Revenue Per User) – средний доход с пользователя; это сумма доходов, которые компания получает от одного пользователя за определенный период времени (например, месяц, квартал, год). Метрика показывает, насколько продукт или услуга ценен и востребован для пользователей и как он генерирует доходы для компании.

➠ CCR (Customer Churn Rate, Churn) – коэффициент оттока; это процент клиентов, переставших пользоваться услугой после определенного периода времени (например, месяц, квартал, год). Метрика показывает, насколько продукт или услуга удовлетворяет клиентов и делает их более лояльными и как он создает ценность для них.

➠ CRR (Customer Retention Rate) – коэффициент удержания клиентов; это процент клиентов, которые продолжают пользоваться продуктом или услугой компании после определенного периода времени (например, месяц, квартал, год). Метрика показывает, насколько продукт или услуга удовлетворяет клиентов, делает их лояльными и как он создает для них ценность.

4.3.1.3. Инвестиционные метрики

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

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

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

➠ Доходность за период (ROI) – относительный показатель, который демонстрирует, какую прибыль получил инвестор от владения активом за определенный период времени. Она рассчитывается как отношение прироста стоимости актива к его начальной стоимости. Например, если инвестор купил акцию за 100 рублей и продал ее через год за 120 рублей, то его доходность на период составит 20 %. Период доходности наступает после периода прибыльности.

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

Рис. 4.13. Точки прибыльности и окупаемости, отклонение графика

NPV от накопленного денежного потока

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

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

➠ Дисконтирование денежного потока – это метод оценки стоимости будущих денег. Он учитывает факт, что деньги со временем обесцениваются из-за инфляции, рисков и возможности получать доход от них. Дисконтирование позволяет сравнивать денежные потоки, которые поступают или уходят в разные периоды времени, и определять, сколько нужно инвестировать сейчас, чтобы получить желаемую сумму в будущем. Для дисконтирования используется специальный коэффициент, называемый ставкой дисконта, который отражает ожидаемые инфляцию и риск. Чем выше ставка дисконта, тем меньше стоимость будущих денег. Например, если перед инвестором стоит выбор получить миллион сейчас или через год, он предпочтет сейчас, так как этот миллион можно положить на депозит по ставке 10 % годовых. Следовательно, один миллион, полученный через год, обесценится для инвестора на размер дисконта и будет стоить как 1 млн / (1 + 10 %) = 909 091 руб.

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

где CFt — денежный поток за период t,

r — ставка дисконтирования,

n — количество периодов,

IC — начальная инвестиция.

Популярные инвестиционные метрики:

➠ ROI (Return on Investment) – отдача от инвестиций, показывает, какой процент от вложенных средств инвестор получил в виде прибыли. Рассчитывается как отношение прибыли к инвестициям. Например, если инвестор вложил 100 тыс. рублей в продукт и получил 120 тыс. рублей, то его ROI составит 20 %.

➠ NPV (Net Present Value) – чистая текущая стоимость, показывает, насколько выгоден продукт в сравнении с альтернативными вариантами инвестирования.

➠ IRR (Internal Rate of Return) – внутренняя норма доходности, показывает, какая доходность будет получена от продукта при условии, что все доходы и расходы по нему будут реинвестированы в него же. Рассчитывается как ставка дисконтирования, при которой NPV продукта равен нулю.

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

4.3.2. Юнит-экономика

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

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

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

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

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

Для расчета юнит-экономики необходимо знать два основных показателя: доход на юните (Revenue per Unit, RPU) и расход на юните (Cost per Unit, CPU). Доход на юните – это сумма денег, которую компания получает с каждого юнита. Расход на юните – это сумма денег, которую компания тратит на создание и продажу каждого юнита. Разность между доходом и расходом на юните называется прибылью на юните (Profit per Unit, PPU). Формулы для расчета этих показателей выглядят так:

RPU = общий доход ⁄ количество юнитов

CPU = общий расход ⁄ количество юнитов

PPU = RPU – CPU

Если PPU < 0, значит, бизнес не прибылен.

Пример расчета:

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

➠ Количество активных пользователей в месяц. Пусть это будет 100 тыс. человек.

➠ Средний чек одного заказа. Пусть это будет 300 рублей.

➠ Среднее количество заказов на одного активного пользователя в месяц. Пусть это будет пять заказов.

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

➠ Стоимость привлечения одного активного пользователя (САС). Пусть это будет 500 рублей.

➠ Стоимость поддержки одного активного пользователя (Customer Support, CS). Пусть это будет 100 рублей в месяц. Теперь мы можем рассчитать доход, расход и прибыль на одного активного пользователя в месяц по формулам:

RPU = средний чек х среднее количество заказов х комиссия приложения

CPU = САС + CS

PPU = RPU – CPU

Подставляя данные в формулы, получаем:

RPU = 300 х 5 х 0,2 = 300 рублей

CPU = 500 + 100 = 600 рублей

PPU = 300–600 = -300 рублей

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

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

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

В следующем пункте мы детально увидим, как оценить окупаемость инициативы.

4.3.3. Финансовое моделирование

Финансовое моделирование – это процесс построения абстрактного представления (финансовой модели) реальной или предполагаемой финансовой ситуации.

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

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

4.3.3.1. Пример финансовой модели для цифрового продукта

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

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

➠ Пользователи приходят и уходят в течение времени, поэтому важно учитывать показатели притока (influx) и оттока (churn) пользователей.

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

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

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

➠ Приток пользователей растет линейно на 5 % каждый месяц.

➠ Отток пользователей составляет 10 % от общего количества пользователей в месяц.

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

➠ Себестоимость продукта составляет 20 % от выручки.

➠ Постоянные затраты на инициативу (аренда, зарплата, налоги и т. д.) равны одному миллиону рублей в месяц.

➠ Переменные затраты на инициативу (реклама, хостинг, комиссии и т. д.) составляют 10 % от выручки.

➠ Ставка дисконтирования равна 12 % годовых.

Рис. 4.14. Пример финансовой модели

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

Для удобства таблица приведена с формулами табличного редактора типа Excel.

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

Рис. 4.15. График NPV

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

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

Табл. 4.3. Пример продуктовых гипотез, построенных на основе финансовой модели

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

4.3.3.2. Выбор метрик для гипотез жизнеспособности

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

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

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

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

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

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

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

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

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

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

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

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

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

4.3.3.3. Выбор значений для метрик гипотез жизнеспособности

Как уже говорилось ранее, гипотеза жизнеспособности состоит из трех составляющих: метрики, ее значения и знака отношения (>, <, = и др.).

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

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

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

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

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

➠ Стандарты инвестирования. У стейкхолдеров может быть выработан и даже регламентирован набор критериев, по которым они оценивают инвестиционный потенциал и принимают решение инвестировать или нет. Например, не инвестировать, если период окупаемости более 36 месяцев или доходность менее 100 % через 24 месяца. Такие стандарты накладывают дополнительные ограничения на выбор значения метрики.

Рис. 4.16. Определение рекомендуемого диапазона значений для метрик гипотез жизнеспособности

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

4.3.3.4. Отраслевой бенчмаркинг

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

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

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

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

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

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

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

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

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

Пример расчета бенчмарка

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

Пусть ваша компания имеет следующие показатели за последний год:

➠ Выручка от продаж: 100 млн руб.

➠ Прибыль от продаж: 10 млн руб.

Тогда рентабельность продаж составляет:

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

➠ Компания А: 15 %

➠ Компания Б: 12 %

➠ Компания В: 8 %

Тогда средняя рентабельность продаж по отрасли составляет:

Средняя рентабельность продаж по отрасли = (Сумма рентабельности продаж лидеров)/(Количество лидеров) = (15 + 12 + 8)/3 = 11,67%

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

Лучшие практики по бенчмаркингу

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

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

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

4.3.3.5. Модель дохода от роста конверсии

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

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

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

Один из подходов, который может помочь разъяснить процесс, – метод «Было» и «Стало».

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

Путем сравнения двух моделей мы можем выявить разностный поток – изменение в денежном потоке между состояниями «Было» и «Стало».

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

Предположим, что сервис ежемесячно посещают 10 тыс. пользователей; отток визитеров – 70 %; отток подписчиков – 10 %; доход от одного подписчика – 300 рублей.

Расходы на визитера и подписчика – 1 рубль и 10 рублей соответственно.

Текущая конверсия в подписчика – 2 %.

Благодаря внедрению новой системы регистрации ожидается увеличение конверсии в подписчики с 2 до 3 %.

Расходы на разработку – один миллион рублей.

Ставка дисконтирования – 12 % в год.

С расчетом можно ознакомиться в табл. 4.4.

В примере из табл. 4.4 для расчета накопленного дисконтированного потока используется встроенная функция NPV.

Как видно из расчетов, окупаемость для инвестора наступает на восьмой месяц после старта. Доходность за 12 мес. (ROI) составила 1 014 372/1 000 000×100 % = 101 %

Табл. 4.4. Пример расчета модели от роста конверсии

4.3.3.6. Модель дохода от роста удержания

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

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

В этом случае можно применить подход «Было-Стало», построив две модели.

Пример:

В сервис ежемесячно приходят 10 тыс. пользователей, через месяц остаются 60 % (отток составляет 40 %), доход на пользователя составляет 300 руб./мес.

В результате внедрения инициативы планируется увеличить удержание до 70 % (отток составит 30 %).

Табл. 4.5. Пример расчета модели от роста удержания

Расход на разработку инициативы – один миллион руб.

Ставка дисконтирования денежного потока – 12 %.

В примере из табл. 4.5 срок окупаемости составил восемь месяцев, доходность на 12 мес. с учетом дисконтирования – 68,8 %.

4.3.3.7. Комплексные финансовые модели

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

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

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

Пример расчета

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

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

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

До внедрения инициатив наш сервис имеет следующие параметры:

➠ Доход на пользователя составляет 300 рублей в месяц.

➠ Количество пользователей на старте составляет 10 тыс. человек.

➠ Приток пользователей составляет тысячу человек в месяц.

➠ Отток пользователей составляет 40 % в месяц.

В табл. 4.6 для краткости приведен расчет модели без формул.

С формулами расчета можно ознакомиться в Приложении.

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

Табл.4.6. Пример расчета комплексной модели

Рис. 4.17. Синергия инициатив. Эффект двух инициатив выше, чем сумма их эффектов по отдельности

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

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

Представим, что в банке есть две команды: одна отвечает за разработку мобильного банка, другая – за выдачу кредитов. Команда мобильного банка затратила ресурсы и разработала баннер, который увеличил объем ежемесячно выдаваемых кредитов. Если команда выдачи кредитов не поделится частью прибыли с командой мобильного банка, то может показаться, что инициатива по разработке баннера убыточна для команды мобильного банка. Пускай команда мобильного банка не получит физических денег, но она по крайней мере должна рассчитывать, что заработает для банка в целом часть дополнительного дохода. Такая часть прибылей/убытков, которые виртуально зачисляются на счет одного из подразделений, называется теневой прибылью и убытками (shadow P&L).

Теневые прибыли и убытки

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

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

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

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

Аллокация P&L между инициативами может происходить разными методами, в зависимости от целей, данных и модели компании. Вот некоторые из возможных вариантов:

➠ Метод пропорционального распределения: часть P&L одной инициативы распределяется между другими инициативами пропорционально их вкладу в общий результат. Например, если инициатива А приносит тысячу рублей прибыли, а инициатива Б влияет на 20 % этой прибыли, то 200 рублей из P&L инициативы А переходят в P&L инициативы Б.

➠ Метод инкрементального распределения: часть P&L одной инициативы распределяется между другими на основе их инкрементального эффекта на общий результат. Например, если инициатива А приносит тысячу рублей прибыли, а инициатива Б увеличивает эту прибыль на 10 %, то 100 рублей из P&L инициативы А переходят в P&L инициативы Б.

➠ Метод совместного распределения: часть P&L одной инициативы распределяется между другими на основе их совместного влияния на общий результат. Например, если инициатива А приносит 1000 рублей прибыли, а инициатива Б приносит 500 рублей прибыли, но вместе они приносят 2000 рублей прибыли, то 250 рублей из P&L инициативы А и 250 рублей из P&L инициативы Б переходят в P&L совместной инициативы А + Б.

4.3.3.8. Финансовая модель портфеля инициатив

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

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

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

➠ Оценить общую финансовую эффективность и рентабельность портфеля инициатив, а также каждой инициативы в отдельности.

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

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

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

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

Табл. 4.7. Пример портфеля инициатив

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

На этапе старта для управления портфелем можно использовать комплексную модель в редакторе типа Google Sheets, но с увеличением сложности может понадобиться специальное программное обеспечение, например, Finix.biz, Anaplan или Solver.

В табл. 4.7 изображен пример выгрузки снэпшота модели портфеля на более чем 20 инициатив из Finix.biz, с которым можно подробнее ознакомиться в приложении.

4.3.4. Выявление присущих рисков инициативы

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

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

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

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

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

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

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

4.3.4.1. Как оценивается объем рисков

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

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

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

Пример расчета объема риска

После обновления приложения 100 тыс. пользователей (владельцев старых устройств) не смогут столкнуться с потерей функциональности приложения. На восстановление работоспособности понадобится один месяц. Накопленная статистика показывает, что за это время от использования приложения могут отказаться 10 % пользователей. Средний доход на пользователя в месяц – 500 руб.

Объем риска: величина потерь – 10 тыс. пользователей, вероятность возникновения потерь – 0,1.

Объем риска =10 тыс. пользователей × 0,1 = 1000 пользователей.

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

4.3.4.2. Выставление порога риска для проекта

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

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

Например, компания может выработать следующие стандарты принятия рисков:

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

➠ Приостановить или откатить инициативу, если объем ущерба в результате реализации рисков составляют более 10 % от годового дохода инициативы.

4.3.5. Оценка трудозатрат на разработку

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

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

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

В этой главе мы рассмотрим два способа, которые подходят для быстрой оценки сущностей размером в квартал, то есть тех, которые требуют от трех до шести месяцев для реализации. Эти способы называются оценкой по «ведрам» (bucket system estimation) и оценкой по сходству (affinity estimation).

4.3.5.1. Ретроспективная оценка трудозатрат

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

Для наглядности можно построить таблицу, где:

➠ Эпик – это название эпика, который был выполнен командой.

➠ Сторипоинты – это сумма всех сторипоинтов, затраченных на эпик с момента старта команды.

➠ Юзерстори – это сумма всех юзерстори, выполненных по эпику с момента старта команды.

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

Табл. 4.8. Пример таблицы с расчетом количества затраченных дней

В табл. 4.8 предполагается, что команда выполнила 200 сторипоинтов за 40 рабочих дней. Тогда, например, для эпика «Внедрение дизайн-системы» оценка трудозатрат в днях команды будет равна:

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

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

4.3.5.2. Оценка по «ведрам»

Далее можно прибегнуть к оценке по «ведрам». Это метод, при котором сущности распределяются по группам («ведрам») в зависимости от их сложности или затрат времени. Каждое «ведро» имеет свое значение, которое может быть выражено в сторипоинтах, часах, днях или других единицах измерения. Значения «ведер» обычно выбираются так, чтобы они отражали нелинейный рост сложности сущностей. Например, «ведра» могут иметь значения 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 и т. д. Для примера, приведенного выше, можно присвоить значения в юзерстори или в сторипоинтах с шагом 0, 10, 20 и т. д.

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

1. Разместить карточки со значениями «ведер» на столе или на стене в порядке возрастания.

2. Расположить карточки с уже оцененными эпиками из табл. 4.7, сформованные ранее, по «ведрам» в соответствии с размером.

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

4. Посмотреть на распределение сущностей по «ведрам» и обсудить с командой, есть ли какие-то несоответствия, противоречия или сомнения. Перемещать сущности между «ведрами», пока не будет достигнуто согласие по всем сущностям.

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

4.3.5.3. Оценка по сходству

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

1. Сначала участники индивидуально сортируют карточки-эпики от самых простых до самых сложных.

2. Затем на основе индивидуальных рейтингов формируется групповой рейтинг (сумма рейтингов участников для каждого эпика).

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

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

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

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

4.3.6. Составление презентации гипотезы инициативы

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

Рис. 4.18. Шаблоны презентации гипотезы инициативы

4.3.7. Приоритизация гипотез инициатив

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

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

4.3.7.1. Стоимость задержки

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

Однажды нам нужно было разместить продукт в витрине агрегата. На момент планируемого запуска мы были пятыми, следовательно, могли рассчитывать на 20 % трафика. В связи с задержкой в 6 месяцев мы стали 13-ми (7 %); это значит, что каждый месяц задержки инициатива все дольше выходит на прибыльность и окупаемость.

Рис. 4.19. Изменение срока окупаемости в зависимости от задержки

Рис. 4.29. График стоимости задержки

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

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

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

Если в компании пока не внедрено моделирование портфеля, есть и другие варианты приоритизации, например WSJF (Weighted Shortest Job First – сначала самая важная и короткая работа).

4.3.7.2. Приоритизация по WSJF

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

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

Табл. 4.9. Пример расчета WSJ F для четырех инициатив с упрощенной моделью CoD

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

По формуле

получаем следующие значения:

➠ WSJF(A) = (5 + 3 + 2)/3 = 3.33

➠ WSJF(B) = (3 + 5 + 3) ⁄ 5 = 2.2

➠ WSJF(C) = (2 + 2 + 1) ⁄ 2 = 2.5

➠ WSJF(D) = (1 + 1 + 1) /1=3

Сортируя инициативы по убыванию WSJF, получаем следующий приоритетный список:

➠ А (3.33)

➠ D (3)

➠ С (2.5)

➠ В (2.2)

Таким образом, инициатива А имеет наибольший приоритет, так как она имеет наибольшую стоимость задержки и наименьший размер работы. Инициатива В имеет наименьший приоритет, так как она имеет наименьшую стоимость задержки и наибольший размер работы.

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

4.3.7.3. Игра «Купи фичу»

Еще один упрощенный подход, который учитывает бюджет разработки инициатив и побуждает группу оценщиков к активному обсуждению, описан в книге Л. Хоманна Innovation Game — это игра «Купи фичу» (Buy a feature game).

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

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

Табл. 4.10. Пример таблицы для игры «Купи фичу»

* Соцсеть признана экстремистской и запрещена на территории РФ.

** Соцсеть признана экстремистской и запрещена на территории РФ.

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

Табл. 4.11. Результат игры «Купи фичу»

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

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

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

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

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

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

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

4.3.8. Мониторинг внедрения

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

Для проведения мониторинга внедрения необходимо выполнить следующие шаги:

➠ Подготовка к этапу мониторинга

➠ Подтверждение гипотезы жизнеспособности

➠ Анализ результатов и формирование выводов

➠ Корректировка финансовой модели инициативы и модели портфеля инициатив

4.3.8.1. Подготовка к мониторингу

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

Лучшие практики организации сбора метрик:

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

➠ Выводить индикаторы подтверждения жизнеспособности гипотез. Гипотезы жизнеспособности – это утверждения о том, какого результата должен достичь продукт по определенным метрикам, чтобы считаться успешным. Например, «MAU > 1000» означает, что продукт должен иметь более тысячи активных пользователей в месяц. Для каждой гипотезы можно вывести индикатор, который показывает, насколько близко продукт к ее достижению, а также статус гипотезы: подтверждена, не подтверждена или в процессе проверки. Это помогает отслеживать прогресс продукта и определять, какие инициативы работают, а какие нет.

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

4.3.8.2. Подтверждение гипотез жизнеспособности

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

где n – объем выборки, Z – уровень доверия (например, 1,96 для 95 % доверительного интервала), σ – стандартное отклонение генеральной совокупности (можно оценить по предварительным данным или использовать консервативное значение 0,5), E – допустимая погрешность (например, 0,05 для 5 % точности).

Например, если мы хотим измерить долю пользователей, которые совершают покупку на нашем сайте, и хотим, чтобы ошибка выборки была не больше 3 %, то можно рассчитать объем выборки следующим образом:

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

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

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

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

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

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

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

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

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

Корректировка финансовой модели инициативы и портфеля инициатив

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

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

4.3.9. Пример поэтапного развития инициативы от идеи до мониторинга внедрения

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

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

Список действий и инструментов для развития инициативы:

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

2. Начать фазу открытия, которая состоит из трех этапов: концепция, гипотеза и мониторинг.

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

4. Если работаем над уже существующим решением, построить CJM, выделить приоритетные инсайты и включить их в перечень работ по инициативе. Затем перейти к разработке гипотезы (шаг 12).

5. Если работаем над новой потребностью и/или для нового сегмента, провести проблемное интервью для уточнения потребности и сегмента.

6. Провести решенческое интервью для определения возможного решения.

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

8. Провести оценку востребованности решения, например при помощи исследования по модели Кано.

9. Оценить ресурсы на разработку гипотезы.

10. Подготовить презентацию концепции для стейкхолдеров.

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

12. На этапе гипотезы сформулировать гипотезы жизнеспособности инициативы.

13. Определить метрики для гипотез, например, при помощи SM ART-критериев.

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

15. Оценить ресурсы на разработку инициативы.

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

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

18. Подготовить презентацию гипотезы для стейкхолдеров.

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

20. Перевести инициативу в фазу поставки, где будет происходить разработка, тестирование и внедрение инициативы.

21. После разработки вернуть инициативу в фазу открытия на этап мониторинга.

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

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

Глава 5

Основы цифрового маркетинга

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

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

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

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

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

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

5.1. Основные направления цифрового маркетинга

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

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

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

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

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

Маркетинг в социальных сетях (SMM) – это процесс использования социальных платформ, таких как Facebook, Instagram, Twitter[58], TikTok и других, для продвижения продукта или услуги, взаимодействия с целевой аудиторией, укрепления имиджа и репутации бренда, а также для мониторинга и анализа отзывов и мнений пользователей. Цель SMM – привлечь и активизировать сообщество вокруг бренда, а также повысить лояльность и удовлетворенность клиентов. Примером SMM может быть создание и ведение официальных страниц или групп в социальных сетях, публикация интересного и полезного контента, проведение конкурсов, опросов, вебинаров и других акций, а также взаимодействие с подписчиками, комментаторами и лидерами мнений. Команды роста используют SMM для увеличения социального трафика на сайт, повышения продаж и дохода, а также для получения обратной связи и рекомендаций от пользователей.

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

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

5.2. Команды роста

Команда роста (growth team) – это специальная команда, которая занимается поиском и реализацией наиболее эффективных и экономичных способов достижения роста продукта или бизнеса. Команда роста использует гибкий подход, основанный на экспериментах, аналитике и обратной связи, а также объединяет специалистов с разными компетенциями, такими как маркетинг, продукт, дизайн, инженерия и аналитика. Команда роста работает короткими итерациями как Scrum-команда, в режиме dual track (циклы открытий и поставки), и отвечает за достижение конкретных целей и метрик роста. Крупнейшие мировые компании Airbnb, Uber, Spotify, Facebook[59], Twitter[60], Google используют команды роста для развития своего бизнеса.

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

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

5.2.1. Основные типы команд роста

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

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

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

➠ Организация по метрикам – команда роста разделена на подкоманды, каждая из которых отвечает за определенную метрику роста, например, аквизицию, активацию, удержание, монетизацию или рефералы (рис. 5.1). Позволяет сфокусироваться на конкретных целях и показателях, а также избежать дублирования или конфликта задач. Этот вариант использует Facebook[61].

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

Рис. 5.1. Независимые команды роста, организованные по метрикам

Рис. 5.2. Независимые команды роста, организованные по функциям

Такой вариант применяется в Uber.

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

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

Ситуацию в этом случае может исправить управление инициативами на уровне портфеля. Команда роста закладывает в P&L своих инициатив теневой доход (Подробнее о shadow P&L см. в п. 4.3.3.7.) от продаж внутри продукта. Команда продукта учитывает в своих инициативах теневой доход от дополнительного притока новых пользователей от команды роста. Такой подход может посадить две команды в одну лодку и заставить грести в одном направлении.

Функциональная команда роста – это команда, которая подчиняется функциональным руководителям (например, продукту, инженерии и т. д.), определяющим, какие инициативы роста будут реализованы (рис. 5.3). Эта команда обеспечивает большую прозрачность и баланс между инициативами роста и не роста, а также сотрудничает с другими командами продукта, маркетинга, продаж и т. д. Примеры компаний, которые используют функциональную команду роста: Pinterst, Twitter[62], LinkedIn, Dropbox, BitTorrent.

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

Рис. 5.3. Функциональная команда роста

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

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

5.2.2. Производственный цикл команд роста

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

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

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

Доказательство прибыльности кампании. На этом этапе команда роста запускает рекламную кампанию с выбранными параметрами и измеряет ее результаты, используя метрики, такие как количество кликов, конверсии, регистрации, покупки, доход, ROI и т. д. Для этого команда использует различные инструменты аналитики – Google Analytics, Amplitude, Mixpanel и другие. Цель этого этапа – проверить гипотезы о том, что кампания финансово эффективна (САС меньше LTV) и достигает поставленных целей роста.

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

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

Отчет о кампании. Команда роста подводит итоги рекламной кампании, оценивая ее результаты, эффективность, проблемы и уроки. Для этого она собирает и анализирует данные о всех этапах производственного цикла, используя инструменты, такие как Google Data Studio, Tableau, Power BI и другие. Цель этого этапа – подготовить отчет о кампании, который будет содержать ключевые метрики, выводы, рекомендации и планы на будущее. Как говорилось ранее, одна из самых важных метрик, которую нужно определить на этапе отчета, – это реальный LTV клиентов, привлеченных кампанией. Реальный LTV отражает фактическую прибыль, полученную от клиентов, в отличие от прогнозного LTV, который основан на предположениях и моделях. Определение реального LTV после кампании позволяет команде роста оценить, насколько эффективно она использовала бюджет, какие каналы и параметры кампании были наиболее выгодными, какие гипотезы были подтверждены или опровергнуты, а также какие улучшения или изменения необходимо внести в будущих кампаниях. Кроме того, определение реального LTV после кампании позволяет команде роста прогнозировать LTV на этапе конфигурации следующих кампаний, используя реальные данные и обратную связь от клиентов, а не только теоретические модели и предположения.

Для планирования и управления работой по производственному циклу команд роста удобно использовать систему Kanban, которая предполагает визуализацию потока задач на доске с колонками, соответствующими этапам производственного цикла (рис. 5.4). Каждая задача представляет собой рекламную кампанию, которая перемещается по колонкам в зависимости от ее статуса. Такой подход позволяет команде роста видеть общую картину, контролировать прогресс, приоритизировать, устранять проблемы и улучшать процессы.

Рис. 5.4. Пример Kanban команды роста

5.2.2.2. Связь производственного цикла команд роста с циклом организации

Производственный цикл команды роста – это период времени, за который команда роста выполняет одну или несколько инициатив по росту. Инициатива по росту – это конкретная задача или проект, направленный на достижение определенной цели по росту. Инициативы по росту могут быть разной размерности, то есть требовать разного объема ресурсов, времени и усилий для их выполнения. Например, тестирование гипотезы контекстной рекламы – это маленькая инициатива, которую можно выполнить за одну неделю, а подготовка и запуск медийной кампании – это большая инициатива, которая может занять несколько спринтов.

Связь производственного цикла команды роста и цикла открытий на уровне трайба или организации заключается в том, что они оба являются формами экспериментальной культуры, которая направлена на постоянное обучение и улучшение. Однако они имеют разные цели, уровни и скоупы. Производственный цикл команды роста фокусируется на оптимизации существующих продуктов или услуг, увеличении их доходности и эффективности, а также на решении конкретных проблем или задач по росту. Цикл открытий на уровне трайба или организации фокусируется на создании новых продуктов или услуг, удовлетворении новых потребностей или решении новых проблем, а также на поиске новых рынков или сегментов. Производственный цикл команды роста работает на операционном уровне, реализуя тактику, а цикл открытий на уровне трайба или организации работает на уровне тактики, реализуя стратегию.

Чтобы производственный цикл команды роста был согласован с циклом открытий на уровне трайба или организации, необходимо учитывать следующие аспекты:

➠ Размерность инициатив по росту. Как правило, удобными сущностями для управления на уровне портфеля являются эпики, то есть инициативы, которые занимают от одного до трех месяцев. Для того, чтобы размерность инициатив команды роста совпадала с размерностью других команд, нужно объединять мелкие и дробить крупные инициативы. Например, мелкие инициативы по размещению в контексте можно объединить в одну большую инициативу «Контекстная реклама» с общим прогнозом бюджета и показателей. А инициативы больше одного квартала разделить, например, вертикально декомпозировать рекламную кампанию на несколько флайтов[63].

➠ Приоритизация инициатив по росту. Чтобы выбрать наиболее перспективные инициативы по росту, нужно учитывать не только их потенциальный вклад в достижение целей по росту, но и их связь с развитием функциональности продуктов. Для этого можно использовать различные методы приоритизации, такие как RICE, MoSCoW и т. д.

➠ Синхронизация производственного цикла команды роста с циклом открытий на уровне трайба или организации. Чтобы обеспечить эффективное взаимодействие и согласованность действий между командой роста и другими командами, нужно синхронизировать их производственные циклы, то есть определить общий график планирования, исполнения, оценки и корректировки инициатив.

Таким образом, производственный цикл команды роста и цикл открытий на уровне трайба или организации имеют свои особенности, цели и уровни, но также имеют связь и взаимозависимость, которые требуют учета размерности, приоритизации и синхронизации инициатив по росту.

5.2.2.3. Пример эффективного отчета команды

роста

Для демонстрации своей эффективность и ценности для бизнеса команда роста должна регулярно отчитываться о результатах своих экспериментов и кампаний. Отчет команды роста – это документ, который содержит информацию о проведенных, запланированных и текущих инициативах по росту, а также о достигнутых показателях и извлеченных уроках.

Существует много способов и форматов для составления отчета команды роста, но мы рассмотрим некоторые зарекомендовавшие себя принципы, которые помогут сделать отчет более понятным, полезным и убедительным (табл. 5.1).

Табл. 5.1. Пример отчета команды роста

* Соцсеть признана экстремистской и запрещена на территории РФ.

1. Приводите список рекламных кампаний, отсортированных по дате. Для каждой кампании укажите ее название, цель, гипотезу, канал, срок и статус. Это поможет дать общий обзор выполненной работы и показать динамику и направление деятельности команды роста.

2. Нужно постоянно учиться и извлекать уроки, поэтому для каждой кампании важно видеть прогнозные и фактические данные по основным показателям: САС (стоимость привлечения клиента), LTV (жизненная ценность клиента), количество пользователей в разных этапах воронки (визитер, триалер – англ, trial, пробный период, – подписчик), бюджет, качество кампании (охват, CTR и т. д.). Это поможет оценить эффективность и рентабельность кампании, а также выявить сильные и слабые стороны, возможности и риски.

3. Для извлечения уроков важно видеть, какие кампании сработали в плюс, а какие в минус (заработали больше, чем потратили), и то, что САС < LTV. Для этого можно ввести индикацию «светофор» (или emoji), которая будет показывать степень успешности кампании по цвету или смайлику.

Например:

означает, что кампания была успешной, то есть принесла положительный ROI и САС < LTV.

означает, что кампания была средней, то есть принесла нулевой или небольшой ROI и САС ~ LTV.

означает, что кампания была неудачной, то есть принесла отрицательный ROI и САС > LTV.

означает, что кампания еще не запущена или не завершена, поэтому ее результаты пока неизвестны.

Из личного опыта могу добавить, что, несмотря на очевидность тезиса о том, что для каждой кампании САС должен быть больше LTV, на практике достаточно сложно определить LTV быстро. На подсчет может уйти несколько месяцев, что может принести неприятные сюрпризы. Для бизнесов, чувствительных к соотношению CAC/LTV, важно научиться как можно быстрее прогнозировать отток. Для этого нужно как можно раньше начать собирать максимум данных о пользователях и обучать модели машинного обучения для предсказания LTV.

5.2.3. Хакинг роста

Хакинг роста – это не просто набор техник или инструментов, которые можно использовать для увеличения доходов или клиентской базы. Это скорее культура или философия, которая предполагает постоянный поиск новых возможностей для роста, экспериментирование, измерение результатов и быстрая адаптация к изменяющимся условиям рынка. Хакер роста – это тот, кто действует как хакер, то есть находит нестандартные и креативные решения для достижения своих целей.

Культура хакинга роста основывается на нескольких ключевых принципах, которые помогают хакерам роста находить и реализовывать лучшие стратегии для своих продуктов или бизнесов. Вот некоторые из них:

➠ Ориентация на данные. Хакеры роста не полагаются на интуицию или мнение, а используют данные для проверки своих гипотез, измерения эффективности своих действий и определения наиболее перспективных каналов или сегментов. Для этого они применяют различные методы аналитики, тестирования и оптимизации.

➠ Гибкость и скорость. Хакеры роста не боятся экспериментировать и тестировать разные идеи, даже если они кажутся смелыми или рискованными. Они также способны быстро менять свои планы или тактики, если те не приносят ожидаемых результатов или если появляются новые возможности. Они не тратят время и ресурсы на то, что не работает, а фокусируются на том, что приносит наибольшую отдачу.

➠ Креативность и инновация. Хакеры роста не следуют за толпой и не копируют чужие решения, а ищут уникальные способы привлечения и удержания клиентов, создания ценности и дифференциации своих продуктов или бизнесов. Они не боятся пробовать новые технологии, платформы или форматы, а также сочетать разные элементы в неожиданные комбинации.

Хакинг роста – это не новая концепция, и многие успешные компании использовали его для достижения своих целей. Ознакомимся с некоторыми известными примерами хакинга роста:

➠ Dropbox. Компания применила вирусный механизм, который позволял пользователям получать дополнительное место в облаке за приглашение своих друзей. Это привело к резкому увеличению количества регистраций и активных пользователей.

➠ Airbnb. Компания использовала платформу Craiglist для распространения своих объявлений о сдаче жилья. Это позволило ей получить доступ к большой аудитории потенциальных клиентов, которые искали альтернативу гостиницам.

➠ Hotmail. Компания добавила в свои письма подпись «P.S. I love you. Get your free e-mail at Hotmail». Это стимулировало любопытство и интерес к сервису, а также создавало эффект сарафанного радио.

5.2.3.1. Советы и лучшие практики по хакингу роста

Хакинг роста – это не универсальная формула, которая подходит всем и всегда. Он требует творческого подхода, адаптации к конкретным условиям и постоянного обучения. Однако есть некоторые советы и лучшие практики, которые могут помочь вам применять хакинг роста более эффективно:

1. Определите свои цели и метрики. Прежде чем начать экспериментировать, важно знать, чего вы хотите достичь и как будете измерять свой прогресс. Определите конкретные измеримые, достижимые, реалистичные и ограниченные по времени цели, а также ключевые показатели, которые отражают их. Например, количество регистраций, конверсия, удержание, доход на пользователя и т. д.

2. Исследуйте своих клиентов и конкурентов. Чтобы найти лучшие способы привлечения и удержания клиентов, вам нужно понять, кто они, что они хотят, что их мотивирует, какие проблемы они решают, какие каналы используют и т. д. Для этого вы можете проводить опросы, интервью, анализ данных, наблюдение за поведением и прочее. Также вам нужно знать, кто ваши конкуренты, что они предлагают, какие у них сильные и слабые стороны, стратегии и тактики и т. п. Для этого вы можете использовать различные инструменты для анализа конкурентов, такие как SimilarWeb, SEMrush, Ahrefs и т. д.

3. Генерируйте и тестируйте гипотезы. Чтобы найти самые эффективные решения для роста, вам нужно генерировать разные идеи и проверять их на практике. Для этого вы можете использовать различные методы, такие как мозговой штурм, SWOT-анализ, матрица приоритизации, Lean Canvas и т. д. Затем вы можете тестировать свои гипотезы с помощью различных методов, таких как А/В-тестирование, сплит-тестирование, мультивариантное тестирование и т. д. Главное, чтобы вы тестировали одну переменную за раз, выбирали достаточную выборку, определяли критерии успеха и измеряли результаты.

4. Масштабируйте и оптимизируйте. Когда вы находите то, что работает, вам нужно масштабировать свои действия, чтобы получить максимальный эффект. Для этого вы можете использовать различные инструменты автоматизации.

Глава 6

Основы управления цифровой компанией

Цифровая компания – это компания, которая предоставляет свои продукты или услуги через цифровые каналы, такие как интернет, мобильные устройства, социальные сети и другие платформы. Цифровая компания отличается от традиционной тем, что в ее центре находятся информационные технологии и данные, а также продуктовый подход к разработке и управлению своими решениями. Цифровая компания стремится к постоянной новации, адаптации и оптимизации своих продуктов или услуг, чтобы удовлетворять потребности и ожидания своих клиентов в меняющемся мире.

Цифровая компания имеет ряд особенностей, которые отличают ее от других типов компаний. Вот некоторые из них:

1. Цифровая компания ориентирована на клиента. Она постоянно изучает и анализирует поведение, предпочтения, проблемы и потребности своих клиентов, а также получает от них обратную связь. Она использует эти данные для создания и улучшения своих продуктов или услуг, которые решают реальные задачи и приносят ценность клиентам. Она стремится предоставлять клиентам удобный, быстрый и безопасный доступ к своим продуктам или услугам через разные цифровые каналы и точки контакта.

2. Цифровая компания гибка и адаптивна. Она способна быстро реагировать на изменения внешней среды, конкуренции, технологий и требований клиентов. Она не боится экспериментировать, тестировать и внедрять новые идеи, продукты или услуги. Она готова к постоянному обучению и развитию, а также к сотрудничеству с другими компаниями, партнерами и заинтересованными сторонами.

3. Цифровая компания инновационна и креативна. Она использует современные технологии, такие как искусственный интеллект, блокчейн, анализ данных и интернет вещей, для создания новых продуктов или услуг, которые отличаются от существующих на рынке. Она поощряет креативность и инициативу своих сотрудников, давая им свободу и ответственность за свои проекты. Она поддерживает культуру инноваций, в которой ошибки и неудачи считаются возможностью для обучения и улучшения.

4. Цифровая компания эффективна и производительна. Она оптимизирует и автоматизирует свои бизнес-процессы, используя цифровые инструменты и платформы. Она роботизирует и внедряет искусственный интеллект в те процессы, которые могут быть выполнены без участия человека. Она стремится к максимальному повторному использованию своих ресурсов, продуктов и услуг, чтобы снизить затраты и увеличить доходы.

5. Цифровая компания не только про технологии и продукты, но и про людей, которые их создают, продвигают и используют. Люди – это основной ресурс и ценность цифровой компании, а также ее основной расход. Люди, работающие в цифровой компании, обладают высокой квалификацией, креативностью и инициативой, а также большим спросом на рынке труда. Поэтому ими практически невозможно управлять императивно, то есть приказывать, контролировать и наказывать. Нужно создавать эффективную среду и культуру в которой люди будут мотивированы, вовлечены и счастливы работать в цифровой компании. Для этого нужно учитывать такие факторы, как:

• Ненасильственная среда. Люди в цифровой компании должны чувствовать себя свободно и безопасно, а не под давлением и угрозой. Они должны иметь возможность выражать свое мнение, предлагать идеи, критиковать и спорить, а также получать конструктивную обратную связь. У них должно быть право на ошибку и неудачу, а не наказание и увольнение. Они должны сохранять баланс между работой и личной жизнью, а не перерабатывать и выгорать.

• Содержательный труд. Люди в цифровой компании должны выполнять интересные и развивающие задачи, которые соответствуют их компетенциям, интересам и целям. Им необходимо видеть смысл и ценность своей работы, а также влияние ее на клиентов и бизнес. Они должны иметь возможность учиться и расти как профессионалы и личности, а также делиться своими знаниями и опытом с другими. Им следует избегать рутинных и бессмысленных задач, а также бюрократии и других непроизводительных ритуалов.

• Работа с персоналом. Люди в цифровой компании должны получать поддержку и заботу со стороны своих руководителей и коллег, а также отдела по работе с персоналом. Должны быть четкие и прозрачные критерии для найма, оценки, продвижения и увольнения. Они также должны иметь доступ к различным ресурсам и программам, которые помогают им улучшать свои навыки, карьеру и благополучие (образование, карьерное консультирование, менторство, коучинг, и т. д.).

• Бирюзовые принципы организации. Люди в цифровой компании должны работать в самоуправляемых и самоорганизующихся командах, которые имеют четкую миссию, цели и ответственность. Они должны иметь возможность принимать решения на основе согласования, а не подчинения, а также учитывать интересы всех заинтересованных сторон, а не только акционеров. Они также должны стремиться к реализации своего потенциала, а не к выполнению формальных требований, и к поиску смысла и целостности, а не к получению прибыли и власти.

В предыдущих главах мы достаточно подробно рассматривали такие особенности деятельности цифровой компании, как клиентоцентричность (см. п. 2.2.2 и 4.2.1.2), а также гибкость и адаптивность (см. 3.1). В этой главе мы обсудим такие аспекты, как эффективная культура компании, управление инновациями и технологическая основа.

6.1. Эффективная культура

Культура компании – это совокупность ценностей, убеждений, норм поведения и взаимоотношений, которые формируют ее идентичность, атмосферу и стиль работы. Культура компании влияет на многие аспекты бизнеса, такие как производительность, качество, инновации, лояльность, репутация и конкурентоспособность. Поэтому важно создавать и поддерживать эффективную культуру компании, которая будет соответствовать ее целям, стратегии и специфике.

6.1.1. Бирюзовые принципы

Не все культуры одинаково эффективны и подходят для современных цифровых компаний. В книге «Открывая организации будущего» Фредерик Лалу проследил эволюцию организационных культур и классифицировал их на разные типы по цветам, отражающим их основные характеристики и проблемы.

Изначально иерархия в организациях поддерживалась физической силой (красный тип). По таким принципам формировались первобытные боевые отряды, а сейчас формируются криминальные группы. Очевидно, что у физической силы очень ограниченные возможности, чтобы извлечь креативный потенциал из интеллекта сотрудников.

Следующий уровень – янтарный. Это организации, основанные на порядке, стабильности и нормах. Они характерны для армии, церкви, государства и школ. Им характерна вертикальная структура, формальные правила и роли. В организациях этого уровня руководитель всегда более компетентен, чем подчиненные, и отдает четкие строгие приказы. Эта система начинает ломаться, когда нужно нанимать более компетентных людей, чем руководитель: ими уже нельзя управлять четкими приказами, и на смену эволюционно приходит следующий организационный уровень зрелости.

Оранжевый тип – это организации, основанные на успехе, конкуренции и росте. Они характерны для капиталистических компаний, корпораций и бизнес-школ. Им характерна вертикальная структура, целеполагание и контроль. Управление в таких организациях осуществляется при помощи метрических показателей эффективности.

Более компетентные эксперты берут на себя обязательства за достижение значений определенных метрик. Ограничения оранжевой модели начинают возникать, когда появляются взаимные зависимости между подразделениями, и действовать нужно не в интересах собственного подразделения, а в интересах всей компании. «Мы» начинает работать более эффективно, чем «я».

Зеленый тип подразумевает предельную надперсональность целей – общее важнее личного. Это организации, основанные на равенстве, демократии и общности. Этот типа используют неправительственные организации, кооперативы и социальные предприниматели. Им характерны горизонтальная структура, участие и солидарность. Проблемы такого рода организаций – в плохой масштабируемости, коллективной безответственности и высокой чувствительности к деструктивным проявлениям участников. Требуется баланс централизованности и децентрализованности.

Бирюзовый тип – это организации, основанные на целостности, смысле и гармонии. Им характерны горизонтальная структура, долгосрочное видение и высокий уровень самоорганизации. Они организуются по фрактальному принципу, где на каждом уровне поддерживается максимальная автономность и самоуправление, но при этом поддерживается максимально плоская структура и прозрачность в масштабе всей организации.

Примеры эффективных практик, вытекающих из бирюзовых принципов:

➠ Лидерство снизу. Идеи по повышению эффективности не спускаются сверху, а генерируются на местах на уровне блока, трайба, команды. Это позволяет учитывать реальные потребности и проблемы клиентов и сотрудников, а также использовать творческий потенциал и инициативу каждого члена организации. Кроме того, это позволяет быстрее и лучше реагировать на изменения в среде и рынке, а также повышать вовлеченность и мотивацию сотрудников.

➠ Максимальная прозрачность. Все данные и информация в организации доступны всем сотрудникам, а также клиентам и партнерам. Это позволяет прогнозировать эффект от инициатив на уровне всей компании, а также контролировать и оценивать их результаты и показатели. Кроме того, это позволяет снижать риски и ошибки, а также повышать доверие и сотрудничество внутри и вне организации.

➠ Автономность. Сотрудники имеют свободу и ответственность за свою работу, а также принятие решений и действий. Это позволяет избегать бутылочных горлышек в процессе принятия решений, а также ускорять и упрощать их. Кроме того, это позволяет учитывать специфику и контекст каждой ситуации, а также использовать компетенцию и опыт каждого сотрудника.

Бирюзовые принципы могут принести много пользы цифровым компаниям, но они не должны внедряться бездумно. Нужно учитывать специфику бизнеса, рынка и культуры, а также готовность сотрудников к таким изменениям. В противном случае бирюзовые принципы могут привести к хаосу, конфликтам и потере конкурентных преимуществ. Рассмотрим некоторые аспекты, на которые нужно обратить внимание при переходе к бирюзовой модели:

➠ Лидерство снизу должно быть подкреплено ответственностью за результат. Сотрудники, которые предлагают идеи по повышению эффективности, должны также отвечать за их реализацию и оценку. Это позволит избежать ситуации, когда идеи остаются на бумаге или не соответствуют реальным потребностям и возможностям компании. Также нужно создать механизмы для сбора и анализа обратной связи от клиентов, партнеров и других сотрудников, чтобы корректировать и улучшать инициативы.

➠ Абсолютная прозрачность не должна идти вразрез с интересами компании. Есть данные и информация, которые не должны быть легко доступны всем, так как они могут быть использованы конкурентами или нарушить законодательство. Например, Рей Далио, популяризатор принципа абсолютной прозрачности, в своей книге «Принципы. Жизнь и работа» указывал, что инсайдерская информация и коммерческая тайна не должны быть раскрыты. В некоторых компаниях сферы IT данные о зарплате могут быть использованы конкурентами и, следовательно, должны быть скрыты или защищены, например, механизмами обезличивания. Поэтому нужно находить баланс между открытостью и конфиденциальностью, а также учитывать контекст, цели и интересы всех сторон.

➠ Автономность должна быть компенсирована четким пониманием границ принятия решений и механизмами митигации рисков. Сотрудники, которые имеют свободу и ответственность за свою работу, принятие решений и действий, должны также знать, какие решения и действия могут повлиять на другие части компании, ее репутацию, финансы и безопасность. Это позволит избежать ситуации, когда решения и действия одних сотрудников могут нанести вред другим или всей компании. Также нужно создать механизмы для предотвращения и управления рисками, такие как система ставок, рассмотренная ранее, или автоматический анализ финансового эффекта инициативы.

Не всегда есть возможность и необходимость создавать полностью бирюзовую организацию, особенно разрушая до основания то, что уже есть. Но максимальное внедрение принципов в процессы и культуру позволит добиться ощутимого прироста эффективности и масштабируемости для цифровой компании.

6.1.2. Ценности Scrum

Для выстраивания культуры на уровне команд очень походят ценности, описанные в руководстве по фреймворку Scrum. Они коррелируют с бирюзовыми принципами и при этом представляют собой готовое решение, которое легко инсталлируется и может поддерживаться в максимально однородном состоянии на большом количестве команд.

➠ Обязательность. Scrum-команда обязуется достигать своих целей и поддерживать друг друга. Это соответствует бирюзовому принципу целостности, когда сотрудники действуют в соответствии со своими ценностями и обещаниями, а также с эволюционной целью компании.

➠ Фокус. Scrum-команда фокусируется на работе спринта, чтобы осуществить наилучший возможный прогресс к своим целям. Это соответствует бирюзовому принципу смысла, когда сотрудники знают, что и зачем они делают, а также как это влияет на бизнес и клиентов.

➠ Открытость. Scrum-команда и ее заинтересованные стороны открыты в работе и вызовах. Это соответствует бирюзовому принципу открытости, когда сотрудники делятся своими мыслями, идеями, проблемами и решениями, а также принимают обратную связь и критику.

➠ Уважение. Члены Scrum-команды уважают друг друга как способных, независимых людей, и уважаются такими же людьми, с которыми они работают. Это соответствует бирюзовому принципу уважения, когда сотрудники ценят разнообразие, индивидуальность и уникальность каждого человека и группы, а также признают и ценят вклад, достижения и потенциал каждого сотрудника, а также поддерживают и помогают друг другу.

➠ Смелость. Члены Scrum-команды имеют смелость делать правильные вещи, работать над сложными проблемами. Это соответствует бирюзовому принципу смелости, когда сотрудники не боятся экспериментировать, тестировать и внедрять новые идеи, продукты или услуги, а также не боятся признавать и исправлять свои ошибки и неудачи и выражать свое мнение, предлагать идеи, критиковать и спорить.

Эти ценности дают направление Scrum-команде в отношении их работы, действий и поведения. Принимаемые решения, осуществляемые шаги и способ использования Scrum должны усиливать эти ценности, а не уменьшать или подрывать их. Члены Scrum-команды изучают и исследуют ценности, работая с событиями и артефактами Scrum. Когда эти ценности воплощаются Scrum-командой и людьми, с которыми они работают, эмпирические столпы Scrum – прозрачность, инспекция и адаптация – оживают, создавая доверие.

6.1.3. Непрерывное самосовершенствование

Непрерывное самосовершенствование – это процесс постоянного анализа, обучения и улучшения своих знаний, навыков и компетенций. Это одна из ключевых концепций бережливого подхода, который направлен на повышение эффективности и устранение отходов в производстве и управлении. Непрерывное самосовершенствование не только помогает достигать бизнес-целей, но и повышает личную ценность и удовлетворенность сотрудников.

Для разработчиков важно, что, работая в интересах компании, они постоянно развиваются и тем самым поднимают свою ценность. Рынок IT постоянно меняется и требует от специалистов актуальных знаний и навыков, а также способности адаптироваться к новым технологиям, методологиям и требованиям. Разработчики, которые не занимаются самосовершенствованием, рискуют устареть и потерять конкурентоспособность.

Важно, чтобы ценность постоянного развития была вшита в ДНК компании. Это означает, что компания создает условия и стимулы для самосовершенствования своих сотрудников, а также поддерживает их инициативы и достижения в этой области. Компания, которая заботится о развитии своих сотрудников, получает не только высококвалифицированный и мотивированный персонал, но и лояльных и вовлеченных партнеров, которые готовы вносить свой вклад в общий успех.

Примеры того, как это может быть реализовано

В компании внедряются горизонтальные образования – гильдии и чаптеры. Гильдии – это сообщества специалистов, которые интересуются одной темой или областью, например, архитектура, безопасность, тестирование и т. д. Чаптеры – это группы специалистов, которые работают по одной роли, например, дизайнеры, фронтенд-разработчики, бизнес-аналитики и т. д. (Подробнее про чартеры и гильдии см. в п. 3.3.8.1.)

➠ Члены гильдий и чаптеров регулярно встречаются, чтобы обмениваться знаниями, опытом, идеями и лучшими практиками. Их лидеры посвящают часть своего рабочего времени на развитие членов образований, а также координируют их деятельность с другими гильдиями и чаптерами.

➠ Для каждого чаптера строится карьерная траектория, прозрачно показывающая, как можно вырасти из джуниора до сениора и стать лидером чаптера или гильдии. Карьерная траектория определяет требования и ожидания от каждого уровня, а также критерии и процедуры оценки и повышения. Сотрудники знают, что им нужно делать, чтобы развиваться и продвигаться по карьерной лестнице, а также получают обратную связь и поддержку от своих лидеров и коллег.

➠ Организуются образовательные мероприятия с привлечением внешних экспертов, внутренняя платформа онлайн-курсов и круговое обучение. Сотрудники имеют доступ к различным формам и источникам обучения, которые помогают им повышать свои знания и навыки, а также узнавать о новых тенденциях и инновациях в своей области. Для подтверждения своей ступени сотрудники должны регулярно обучать других, делясь опытом и экспертизой.

➠ Софинансирование обучения. Компания поддерживает и поощряет желание сотрудников учиться и развиваться, оплачивая часть или полную стоимость обучения, связанного с их профессиональной деятельностью. Это может быть курс, тренинг, сертификация, конференция, воркшоп и т. д. Сотрудники могут выбирать, что им интересно и полезно, а также получать рекомендации от своих лидеров и коллег.

➠ Поощряются Т-образные навыки. Т-образные навыки – это комбинация глубоких знаний и навыков в одной области (вертикальная часть Т) и широких знаний и навыков в смежных или разных областях (горизонтальная часть Т). (Подробнее см. в п. 3.2.1.3.) Компания поощряет развитие Т-навыков, предоставляя больше возможностей и ресурсов для обучения в кроссспециальностях, а также софинансируя обучение в большем объеме при достижении ступени в кросс-специальности.

6.2. Управление инновациями

В современном динамичном и неопределенном мире управление инновациями становится все более важным и сложным. Компании сталкиваются с постоянным давлением со стороны клиентов, конкурентов, технологий и регуляторов, которые требуют от них не только адаптации к изменениям, но и создания изменений. Для этого компаниям необходимо развивать свою инновационную культуру, способности и системы, а также использовать различные подходы и инструменты для управления инновациями.

У управления инновациями очень много общего с инвестициями – есть очень высокая связь между риском и доходом.

Чем более понятными и очевидными инициативами мы планируем заниматься, тем больше шансов, что этим начнет заниматься кто-то из конкурентов.

Gartner предложил свою модель классификации инициатив Run – Change – Disrupt, которую впоследствии внедрили многие компании для управления интонационной деятельностью.

Подход Run – Change – Disrupt – это концепция, которая предлагает компаниям разделять свои инновационные инициативы на три типа: Run, Change и Disrupt. Эти типы отличаются по степени новизны, риска, сложности и влияния на бизнес, а также по способу управления и реализации.

➠ Run (поддержание) – это инициативы, направленные на поддержание и оптимизацию текущего бизнеса, удовлетворение существующих потребностей клиентов и улучшение операционной эффективности. По квадранту типов стратегических целей (см. п. 4.2.1.1) это «старая потребность – старый сегмент». Примерами таких инициатив могут быть устранение ошибок, увеличение скорости, снижение затрат, повышение качества и т. д. Они имеют низкий уровень новизны, риска и сложности, но высокий уровень влияния на бизнес. Для управления этими инициативами используется стандартный процесс управления проектами, основанный на планировании, контроле и исполнении.

➠ Change (изменение) – это инициативы, направленные на изменение и адаптацию текущего бизнеса, удовлетворение новых или изменяющихся потребностей клиентов и создание конкурентных преимуществ. По квадранту типов стратегических целей это либо «старая потребность – новый сегмент», либо «новая потребность – старый сегмент». Примерами таких инициатив могут быть добавление новых функций, расширение рынков, улучшение пользовательского опыта, внедрение новых технологий и т. д. Эти инициативы имеют средний уровень новизны, риска и сложности, а также средний уровень влияния на бизнес. Для управления ими используется гибкий процесс управления проектами, основанный на экспериментировании, обучении и адаптации.

➠ Disrupt (прорыв) – это инициативы, направленные на создание и трансформацию будущего бизнеса, удовлетворение неудовлетворенных или скрытых потребностей клиентов и создание новых рыночных ниш. По квадранту стратегических целей – «новая потребность – новый сегмент». Примерами таких инициатив могут быть разработка новых продуктов или услуг, создание новых бизнес-моделей, внедрение радикальных инноваций и т. д. Эти инициативы имеют высокий уровень новизны, риска и сложности, но низкий уровень влияния на бизнес в краткосрочной перспективе. Для управления ими используется инновационный процесс управления проектами, основанный на исследовании, творчестве и валидации.

Подход Run – Change – Disrupt помогает компаниям балансировать свой портфель инновационных инициатив, учитывая их различную природу, цели и результаты. Компаниям важно не только вкладываться в проверенные, подтвержденные бизнес-направления, но и пробовать новое, искать новые возможности и решать новые проблемы. Таким образом, компании могут не только сохранять и улучшать свой текущий бизнес, но и создавать и развивать свой будущий бизнес.

В зависимости от аппетита к риску компания может распределять ресурсы между категориями инициатив год от года. Например, в определенный год, увидев, что самый прибыльный продукт, «дойная корова», начинает снижать свою динамику роста, компания может задуматься о том, что нужно смотреть на новые потребности и сегменты, и сбалансировать свой портфель по модели Run – Change – Disrupt как 50/30/20.

Получив определенные всходы от посевов, компания может снизить аппетит к инновациям и ребалансировать портфель как 70/20/10.

Чтобы лучше классифицировать инициативы и определять их представленность в портфеле, можно выработать внутренний критерии того, что мы считаем Run, что Change, а что Disrupt. Пример критериев приведен в табл. 6.1.

В компании могут применяться собственные названия и критерии инициатив по типу инновационности, например «синицы», «журавли», «фениксы», предложенные А. Ефимовым для Сбера.

Много лет занимаясь внутренними инновациями, из личного опыта могу сказать, что в нашей культуре очень неразвито признание права на ошибку. Мне повезло, и мой портфель инноваций показал хорошую всхожесть: многие из запущенных мной продуктов оправдали вложения, были масштабированы и внедрены. Это дало мне необходимый кредит доверия, который получилось потом увеличить, что не всегда получается у коллег по цеху. Хорошая идея, на мой взгляд – на старте в новой компании сбалансировать первичный портфель так, чтобы помимо высокорисковых идей в нем были «низкорастущие фрукты» – быстрые победы, обеспечивающие кредит доверия.

Табл. 6.1. Пример внутренних критериев классификации инновационности инициатив

Инновационная деятельность требует культуры, в которой есть право на ошибку. К этому очень трудно прийти, но для некоторых, особенно для крупных технологических компаний, другого выхода нет – догоняющая стратегия может очень дорого обойтись. Нет стабильно работающих проверенных инструментов для генерации прорывных инициатив. Рассмотрим несколько инструментов, которые могут увеличить скорость и качество поиска:

➠ Демократизация роскоши. Смотрим, какие услуги сейчас доступны только богатым и как технологии могут в этом помочь. Ранее доступ к личным водителям был привилегией избранных, однако благодаря платформам типа Uber теперь любой человек может заказать такси и пользоваться услугами личных водителей. Пример возможных инноваций – аренда частного самолета через мобильное приложение, персональный стилист на основе искусственного интеллекта, виртуальная реальность для путешествий и т. д.

➠ Прогноз профессиональных тенденций. Анализируйте тенденции рынка труда и прогнозируйте, какие навыки будут востребованы в будущем, а какие уйдут. В прошлом профессии, связанные с разработкой веб-сайтов, стали востребованными после взрывного роста интернета. Образовательные программы, такие как курсы веб-разработки, успешно предсказали и соответствовали этим потребностям. Пример возможных современных направлений – разработка образовательных программ, фокусирующихся на навыках, которые будут востребованы в новых областях, таких как разработка искусственного интеллекта или управление данными.

➠ Идеальное проектирование. Представляем себе, как бы выглядел идеальный пользовательский опыт, и пытаемся приблизиться к этому. Например, при желании создать новый сервис для обучения иностранным языкам мы можем спросить себя: как бы я хотел учить язык, если бы не было никаких ограничений? Может быть, вы бы хотели иметь возможность общаться с носителями языка в реальном времени, путешествовать по странам, где говорят на этом языке, смотреть фильмы и читать книги в оригинале, играть в игры и решать головоломки на этом языке и т. д. Затем мы можем искать способы, как реализовать эти желания с помощью технологий, например создать платформу для видео-чата с носителями языка, разработать приложение для виртуальных путешествий, создать адаптивный сервис для подбора фильмов и книг по уровню языка, разработать игровой симулятор для обучения языку и т. д.

➠ Квадрант автоматизации труда. Классифицируйте типы труда по квадрантам «ручной – когнитивный» и «рутинный – не рутинный» для определения областей, где технологии могут принести наибольшую пользу (рис. 6.1). В прошлом в автомобильной промышленности роботизированные линии сборки успешно автоматизировали рутинные задачи, ускоряя процессы и повышая эффективность. Сейчас гуманоидные роботы начинают заменять человека в сфере нешаблонных ручных операций.

Рис. 6.1. Квадрант автоматизации труда

➠ Матрица пересечений потребностей и технологий. Строим детальную карту потребностей и пересекаем ее с картой актуальных технологий. В пересечении получаются потенциальные решения. Например, при желании создать новый продукт для здоровья можно выделить разные потребности, такие как профилактика, диагностика, лечение, реабилитация и т. д., и разные технологии, такие как биометрия, нанотехнологии, генная терапия, нейронные сети и т. д. Затем мы можем сочетать разные потребности и технологии и получать новые идеи, например биометрический браслет, который предупреждает о риске сердечного приступа, наночастицы, которые уничтожают раковые клетки, генная терапия, которая восстанавливает зрение, нейронная сеть, которая помогает восстановиться после инсульта и т. д.

6.3. Стратегическое, тактическое и операционное целеполагание

Целеполагание – это процесс определения и формулирования целей, которых хочет достичь организация или ее подразделения. Цели – это конкретные, измеримые, достижимые, релевантные и ограниченные по времени результаты, которые должны быть достигнуты в рамках определенной стратегии.

Целеполагание важно для успешного управления организацией, так как оно позволяет:

➠ Определить направление и приоритеты развития организации.

➠ Согласовать и мотивировать сотрудников и команды на достижение общих результатов.

➠ Измерять и оценивать прогресс и эффективность работы организации.

➠ Корректировать и адаптировать стратегию и действия в соответствии с изменяющимися условиями и обратной связью.

В зависимости от уровня управления и длительности планового периода целеполагание может быть разделено на три типа: стратегическое, тактическое и операционное.

Стратегическое целеполагание – это процесс определения и формулирования долгосрочных целей организации, которые соответствуют ее миссии, видению и ценностям. Стратегические цели подчинены разработке курса организации на длительный период (для цифровых компаний 1–5 лет) и определяют, куда и зачем организация движется. В п. 4.2.1.1 мы рассмотрели, какие типы стратегических целей бывают. В этой главе мы касаемся процесса формирования целей.

Тактическое целеполагание – это процесс определения и формулирования среднесрочных целей организации или ее подразделений, которые соответствуют стратегическим целям и устанавливаются на период от 1 квартала до 1 года. Тактические цели являются детализацией стратегических целей и определяют, как и когда организация достигнет своих стратегических результатов. Эффективность достижения тактических целей оценивается в скорости реализации бизнес-инициатив и их результативности.

Операционное целеполагание – это процесс определения и формулирования целей, связанных с эффективностью операций по реализации бизнес-инициатив. Операционные цели могут быть связаны с продуктивностью, скоростью и качеством разработки, стабильностью ПО и уровнем сервиса поддержки.

Независимо от типа и уровня целеполагания, важно, чтобы цели были SMART. SMART – это аббревиатура, которая означает:

➠ Specific (конкретные). Цели должны быть четко сформулированы и понятны для всех заинтересованных сторон. Они должны отвечать на вопросы «что?», «кто?», «где?», «когда?» и «зачем?».

➠ Measurable (измеримые). Цели должны иметь количественные или качественные показатели, которые позволяют измерять и оценивать степень их достижения. Они должны отвечать на вопрос «как?».

➠ Achievable (достижимые). Цели должны быть реалистичными и соответствовать возможностям и ресурсам организации или ее подраздела.

➠ Relevant (релевантные). Цели должны быть связаны с миссией, видением и стратегией организации, а также учитывать внешнюю и внутреннюю среду, в которой она работает. Они должны отвечать на вопрос: «почему?».

➠ Time-bound (ограниченные по времени). Цели должны иметь четкие сроки и этапы их реализации, которые позволяют контролировать и корректировать ход выполнения. Они должны отвечать на вопрос «когда?».

SMART-цели помогают повысить эффективность и результативность целеполагания, так как цели получаются более конкретными, измеримыми, достижимыми, релевантными и ограниченными по времени. SMART-цели также помогают согласовать и мотивировать всех участников процесса целеполагания, так как обеспечивают четкое понимание и общение целей, а также обратную связь и признание за их достижение.

В следующих разделах мы детально рассмотрим уровни целеполагания.

6.3.1. Стратегическое целеполагание

Стратегическое планирование компании может состоять из многих аспектов:

➠ Формулирование миссии, видения и ценностей организации.

➠ Определение стратегических направлений и приоритетов развития организации.

➠ Разработка стратегических целей и показателей их достижения.

➠ Выбор стратегических альтернатив и сценариев реализации целей.

➠ Разработка стратегического плана действий, ресурсов и ответственных.

➠ Мониторинг и контроль выполнения стратегического плана и корректировка стратегии при необходимости.

В рамках этой книги мы подробно разберем только ту часть, которая непосредственно связана с управлением цифровыми продуктами, – стратегическое целеполагание.

Стратегические цели могут формироваться в нескольких направлениях:

➠ Сверху вниз – руководство компании полностью определяет, в какой сегмент рынка компания планирует выдвигаться, какую потребность планируется удовлетворить, какие метрики будут использоваться для измерения результата и какое значение метрик будет говорить о том, что цель достигнута. Как мы уже не раз обсуждали, минусы такого директивного подхода в том, что это снимает ответственность за результат с исполнителей.

➠ Снизу вверх – цели формируются в подразделениях компании и агрегируются в виде стратегических. Минусы такого подхода в том, что он не учитывает синергию подразделений и силу компании как единого целого.

➠ Двунаправленный подход – направление целей «потребность – сегмент» и метрики определяются руководством компании, а значения метрик агрегируются из прогнозов подразделений. Такой подход позволяет действовать компании как единому целому и при этом подразделениям брать на себя ответственность за результат. Следует учитывать, что при этом требуется больше времени на формирование стратегии.

Одна из лучших практик стратегического планирования для того, чтобы компания работала как единое целое, – определить ключевую метрику, на которую могут ориентироваться все подразделения компании. Такая метрика называется North Star metric (метрика Полярной звезды). Они позволяет подразделениям, подобно мореплавателям древности, сверяться с курсом и быстро принимать решение в каком направлении двигаться. Второй большой плюс метрики полярной звезды – взаимодействие с акционерами компании, когда один простой параметр показывает прогресс компании и ее ценность для клиентов.

Несколько примеров метрик Полярной звезды:

➠ Netflix: количество часов просмотра контента. С одной стороны, эта метрика показывает востребованность сервиса, с другой – на всех уровнях позволяет принимать эффективные решения, начиная от контактной политики и заканчивая техническими инициативами по увеличению качества канала стриминга.

➠ Airbnb: количество забронированных ночей. Метрика мотивирует не только формировать лучшие рекомендации, но и делать так, чтобы клиенты останавливались как можно больше.

➠ Spotify: количество прослушанных песен. Метрика положительно влияет на разные аспекты бизнеса: персонализацию, формирование плейлистов и офлайн-режим.

Еще один важный подход при стратегическом целеполагании – анализ данных предыдущих стратегических циклов. Важно определить, какие инициативы находятся в состоянии стремительного взлета и требует большего фокуса и инвестиций, какие инвестиции нужно просто поддерживать, а какие, возможно, следует приостановить.

Известный подход по классификации фаз доходности инициатив – квадрант роста-доли от BCG (табл. 6.2).

Табл. 6.2. Квадрант роста – доли

Модель отражает четыре фазы жизненного цикла продукта, но подходит для любых инициатив типа «компонент» или «функция»:

1. Вопросительные знаки. Есть понимание, что рынок растет, и компания стремится получить долю в этом рынке. Проводится множество экспериментов для обеспечения максимального роста. Достаточно большой фокус делается на изучение потребностей аудитории, быстрые эксперименты с функциональностью и гипотезами роста.

2. Звезды. Продукты этой категории попали на волну стремительного роста. На этой фазе активируют процессы масштабирования – внедрение гибких фреймворков масштабирования (см. п. 3.3.5).

3. «Дойные коровы». Продукт приносит высокую прибыль, но появляются проворные конкуренты, чьи решения удовлетворяют потребность сегмента значительно более качественно. На этом этапе практически отсутствует экспериментирование, преобладают инициативы по оптимизации и снижению издержек. Получаемый денежный поток реинвестируется в эксперименты (вопросительные знаки), чтобы захватить рынок (звезды).

4. Собаки. Фаза, на которой доля продукта активно начинает снижаться на схлопывающемся рынке. На этом этапе важно вовремя ликвидировать продукт.

Рассмотрим пример того, как формируются стратегические цели в процессе стратегического цикла компании с учетом всего ранее:

1. Компания анализирует данные прошлого стратегического цикла, определяя:

• этапы жизненного цикла продуктов портфеля. Исходя из этого принимаются решения по ликвидации и формулируются цели по существующим продуктам (рост/качество/ оптимизация);

• аппетит к инновациям. На основе потенциала инициатив прошлого периода формируется баланс портфеля (Run – Change – Growth).

2. Актуализируется список метрик прошлого стратегического цикла, возможно, добавляются новые.

3. Анализируется существующая ситуация и выявляются возможные направления роста (новая потребность – новый сегмент).

4. Определяется, если это возможно, метрика Полярной звезды.

5. Формулируется перечень стратегических целей без целевых показателей, например:

• увеличение доли пользователей небанковских сервисов среди МСБ-клиентов;

• снижение убытков от количества ложных вызовов;

• увеличение MAU.

6. Анализ целей и выработка решений владельцами продуктов.

7. Разработка дорожной карты решений.

8. Оценка потенциальных значений метрик.

9. Определение значений для метрик стратегических целей:

• увеличение доли пользователей небанковских сервисов среди МСБ-клиентов > 30 %;

• снижение убытков от количества ложных вызовов > 20 %;

• увеличение MAU > 1 млн.

6.3.2. Тактическое целеполагание

Тактическое целеполагание – это процесс определения и формулирования среднесрочных целей организации или ее подразделений, которые соответствуют стратегическим целям и устанавливаются на период в три месяца, что позволяет быстрее адаптироваться к изменяющимся условиям и получать четкую обратную связь о результатах.

Планирование удобно проводить раз в квартал, чтобы синхронизировать цели и действия всех участников процесса, а также для анализа и корректировки предыдущих планов.

Планирование квартала – стандартная практика во многих фреймворках, например, в SAFe, где называется PI Planning.

Планирование квартала, как правило, проводится несколькими командами, объединенными общим поездом поставки или трайбом.

Для планирования квартала можно использовать подход OKR (Objectives and Key Results). OKR – это методика постановки, синхронизации и мониторинга целей и ключевых результатов на уровне организации, команды и на индивидуальном уровне. Она позволяет повысить мотивацию сотрудников, ускорить работу и сохранять фокус на приоритетных целях.

OKR состоит из двух основных компонентов:

➠ Цель (objective) – это значимая, конкретная, четко определенная и вдохновляющая цель, которой хочет достичь организация, команда или сотрудник.

➠ Ключевые результаты (key results) – это измеримые критерии успеха, которые используются для отслеживания достижения цели. Ключевые результаты должны быть количественными или качественными показателями, которые можно измерить по шкале от 0 до 100 % или с помощью любого числового значения (например, количество, сумма, процент и т. д.), которое может быть использовано для определения степени достижения цели.

Считается хорошим результатом, если цели планирования выполнены на 70 %; если на 100 % – значит, возможно, они были недостаточно амбициозны; если менее 60 % – чересчур амбициозны.

Для ускорения квартального планирования могут использоваться условные единицы по аналогии со сторипоинтами при планировании спринта.

Как правило, OKR направлены на изменение статусов инициатив, которые являются проектами или задачами, влияющими на достижение целей. Статусы инициатив могут быть следующими:

➠ Переход на стадию мониторинга – инициатива была выполнена, и теперь нужно отслеживать ее результаты и влияние на ключевые результаты и цели.

➠ Подтверждение гипотез жизнеспособности – инициатива была проверена на реальных пользователях или клиентах и доказала свою ценность и эффективность.

➠ Отмена или приостановка – инициатива была остановлена или отложена из-за низкой приоритетности, недостатка ресурсов, изменения условий или других причин.

Пример OKR на квартал для стратегической цели, заключающейся в запуске продаж небанковских сервисов для клиентов МСБ, может выглядеть так:

Цель: запустить продажи небанковских сервисов для клиентов МСБ и получить не менее 10 % рыночной доли за квартал.

Ключевые результаты:

➠ Разработать и протестировать небанковские сервисы, такие как бухгалтерия, аудит и консалтинг, и получить не менее 90 % положительных отзывов от тестовых клиентов.

➠ Создать и распространить маркетинговые материалы, которые демонстрируют преимущества и ценность небанковских сервисов для клиентов МСБ, и привлечь не менее 5 тыс. потенциальных клиентов на сайт или в офис за квартал.

➠ Обучить и мотивировать продавцов, чтобы они могли эффективно продавать небанковские сервисы, и достичь не менее 20 % конверсии из потенциальных клиентов в покупателей за квартал.

➠ Заключить не менее тысячи договоров на оказание небанковских сервисов и получить не менее 1 млн долларов выручки за квартал.

6.3.3. Операционное целеполагание

Операционное целеполагание – это процесс определения и достижения целей, связанных с операционной эффективностью. Операционная эффективность – это способность организации выполнять свои задачи с минимальными затратами ресурсов и максимальным качеством результата. Операционная эффективность особенно важна для компаний, занимающихся гибкой разработкой цифровых продуктов, так как они должны быстро адаптироваться к изменяющимся потребностям рынка и клиентов.

Для измерения и улучшения операционной эффективности при гибкой разработке цифровых продуктов можно использовать различные метрики, такие как:

➠ Lead time – время от поступления заказа до его выполнения. Эта метрика показывает, насколько быстро компания может доставить свой продукт или услугу клиенту. Чем меньше lead time, тем выше уровень удовлетворенности клиента и тем больше возможностей для повторных продаж и рекомендаций.

➠ Cycle time – время от начала работы над задачей до ее завершения. Эта метрика показывает, насколько быстро команда разработчиков может реализовать требования клиента в рамках спринта. Чем меньше cycle time, тем выше уровень адаптивности и гибкости команды, а также тем больше возможностей для получения обратной связи и улучшения продукта.

➠ Troughput – количество задач, выполненных за определенный период. Эта метрика показывает, насколько продуктивна команда разработчиков в целом. Чем больше throughput, тем больше ценности команда создает для клиента и бизнеса, а также тем меньше затрат на разработку.

➠ Defect rate – процент ошибок или дефектов в продукте. Эта метрика показывает, насколько качественно команда разработчиков выполняет свою работу и какие усилия требуются для исправления ошибок. Чем меньше defect rate, тем выше уровень надежности и безопасности продукта, а также тем меньше рисков для клиента и бизнеса.

За метрики эффективности процессов отвечают процессные менеджеры, в Scrum это Scrum-мастера.

За эффективность производства отвечают лидеры чаптеров и гильдий, которыми может руководить СТО. Эти метрики в основном определяются DoD на уровне компании и на уровне команды. Пример наиболее распространенных:

➠ Среднее время между сбоями (Mean Time Between Failures, MTBF): оценивает среднее время, проходящее между появлением сбоев.

➠ Время восстановления после сбоя (Mean Time to Recovery, MTTR): измеряет среднее время, требуемое для восстановления работы системы после сбоя.

➠ Коэффициент отказов (failure rate): оценивает частоту сбоев в работе программы.

➠ Доля времени работы без сбоев (uptime): измеряет процент времени, в течение которого система работает без сбоев.

Метрики могут отслеживаться в реальном времени на дашбордах и быть частью формулы мотивации разработчиков наравне с выполнением OKR.

6.4. Централизованные системы

Как обеспечить эффективное взаимодействие между разными командами и трайбами, которые работают над разными продуктами? Как сохранить автономность и гибкость на уровне команд, не теряя при этом единства и согласованности на уровне экосистемы? Как избежать дублирования усилий, ресурсов и знаний, а также конфликтов интересов и противоречий между разными продуктами?

Ответ на эти вопросы заключается в поиске оптимального баланса между распределением и централизацией. Распределение означает, что каждая команда имеет свою ответственность, свободу и полномочия по разработке, тестированию и развертыванию своего продукта. Централизация означает, что существуют общие правила, стандарты, процессы и инструменты, которые обеспечивают совместимость, интеграцию и синергию между разными продуктами. Найти этот баланс не всегда легко, но он необходим для достижения стратегических целей и конкурентных преимуществ.

Что же должно быть централизовано, а что – распределено в экосистеме продуктов? Нет однозначного ответа на этот вопрос: все зависит от специфики каждой компании, ее рынка, клиентов, культуры и видения. Однако можно выделить некоторые общие аспекты, которые, как правило, требуют централизации, и объяснить, почему они важны.

Дизайн-система. Для обеспечения единого стиля и удобства пользовательского интерфейса целесообразно иметь единую библиотеку для дизайнеров, мобильных и десктопных разработчиков, которую можно использовать заново. Один из примеров дизайн-системы – это SDUI (Server-Driven UI), которая позволяет генерировать пользовательский интерфейс на основе данных, полученных от сервера, без необходимости обновлять приложение на стороне клиента.

Единый трекинг задач (тасктрекинг) и база знаний. Централизованный тасктрекинг и база знаний обеспечивают эффективный обмен информацией между командами. Это особенно полезно при необходимости выполнения доработок или интеграций в систему другой команды, где единая платформа упрощает взаимодействие и сокращает время внедрения изменений.

Единая система CI/CD. Единая система Continuous Integration ⁄ Continuous Deployment (CI/CD) позволяет командам объединяться в единый поезд поставки или вносить изменения в систему другой команды. Это способствует более гибкому и быстрому развертыванию новых функций и обновлений.

Единая система управления портфелем инициатив. Централизованная система управления портфелем инициатив обеспечивает комплексный анализ финансового эффекта внедрения на уровне всей компании. Учет теневого P&L помогает принимать обоснованные стратегические решения и оптимизировать распределение ресурсов.

Единое хранилище данных о пользователях. Создание единого хранилища данных о пользователях предоставляет возможность легкого переключения между продуктами в экосистеме. Единая запись облегчает бесшовное взаимодействие, а также обучение искусственного интеллекта, что улучшает качество персонализированных рекомендаций.

Единый коммуникационный центр. Централизованный коммуникационный центр помогает ограничивать количество рекламных коммуникаций от лица бренда, обеспечивая более качественное взаимодействие с пользователями.

Идентификация и аутентификация через SSO. Использование Single Sign-On (SSO) облегчает процессы идентификации и аутентификации пользователей, позволяя им без труда входить в различные продукты экосистемы с единственными учетными данными.

BI – единая витрина данных. Централизованная В 1-система предоставляет единую витрину данных, позволяя держать дашборды в общем доступе и агрегировать информацию на уровне всей компании для принятия обоснованных стратегических решений.

Единая система управления доступом. Централизованная система управления доступом сотрудников облегчает процессы предоставления и отзыва доступов, повышая безопасность и снижая риск несанкционированного доступа.

Заключение

Подведем итоги нашего путешествия. Мы прошли большой путь, вспоминая лучшие мировые практики и примеры из жизни, помогающие эффективно управлять разработкой цифровых продуктов. От основ управления и инноваций до детального анализа стратегий развития продуктов и формирования корпоративной культуры – мы охватили самые ценные практики и реальные истории успеха.

Я надеюсь, что представленные в книге идеи и примеры вдохновят вас на создание новаторских продуктов и построение эффективных компаний. Искренне верю, что эти знания помогут вам не только достигать поставленных целей, но и преодолевать возникающие на вашем пути препятствия, выстраивая устойчивые и инновационные бизнес-структуры.

Каждое великое достижение начинается с первого шага, смелости мечтать и веры в себя. Путь к успеху не всегда легок, но он вполне осуществим для тех, кто не боится вызовов и готов учиться на собственных ошибках.

Пусть эта книга станет вашим надежным путеводителем и источником вдохновения на пути к созданию чего-то поистине значимого. Желаю вам неиссякаемого энтузиазма, творческих идей и, конечно, удачи во всех ваших начинаниях. Вперед, к новым свершениям!

Источники

1. Э. Рис. Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели (The Lean Startup): https://www. chitai-gorod.ru/product/biznes-s-nulya-metod-lean-startup-dlya-bystrogo-testirovaniya-idey-i-vybora-biznes-modeli-2332738

2. Дж. Вомак, Д. Джонс. Бережливое производство: как избавиться от потерь и добиться процветания вашей компании: https://www. chitai-gorod.ru/product/berezhlivoe-proizvodstvo-kak-izbavitsya-ot-poter-i-dobitsya-procvetaniya-vashey-kompanii-1899907

3. Р. Стейси. Стратегический менеджмент и организационная динамика (Strategic Management and Organizational Dynamics): https:// www.amazon.com/Strategic-Management-Organisational-Dynamics-7th/dp/129207874X

4. Дж. Сазерленд. Scrum. Революционный метод управления проектами (Scrum: The Art of Doing Twice the Work in Half the Time): https://www.chitai-gorod.ru/product/scrum-revolyucionnyy-metod-upravleniya-proektami-2488948

5. Руководство no Scrum: https://scrumguides.org/

6. А. Остервальд. Построение бизнес-моделей: Настольная книга стратега и новатора (Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers): https://www.chitai-gorod.ru/product/postroenie-biznes-modeley-nastolnaya-kniga-stratega-i-novatora-2298582

7. Дж. Паттон. Пользовательские истории. Искусство гибкой разработки ПО (User Story Mapping): https://www.chitai-gorod.ru/prod-uct/polzovatelskie-istorii-iskusstvo-gibkoy-razrabotki-po-2585856

8. M. Кон. Пользовательские истории: https://www.chitai-gorod.ru/ product/polzovatelskie-istorii-gibkaya-razrabotka-programmnogo-obespecheniya-per-s-angl-2321584

9. Я. Шуваев. UX/UI дизайн для создания идеального продукта (UX/UI Design for Perfect Product): https://www.chitai-gorod.ru/ product/ux-ui-dizayn-dlya-sozdaniya-idealnogo-produkta-polnyy-i-ischerpyvayushchiy-gid-2926467

10. P. Энтони. Треугольник Энтони: https://ru.wikipedia.org/wiki/Tpe-угольник_Энтони

11. Р Фитцпатрик. Спроси маму (The Mom Test): https://www. chitai – gorod.ru/product/sprosi-mamu-kak-obshchatsya-s-klientami-i-podtverdit-pravotu-svoey-biznes-idei-esli-vse-krugom-vrut-2590365-?productShelf&shelfIndex=0&productIndex=l

12. А. Купер. Психбольница в руках пациентов (The Inmates Are Running the Asylum): https://www.chitai-gorod.ru/product/psihbolnica-v-rukah-pacientov-alan-kuper-ob-interfeysah-2637570

13. А. Клемент. Когда кофе и капуста конкуренты (When Coffee and Kale Compete): https://www.amazon.com/When-Coffee-Kale-Compete-products/dp/1534873066

14. А. Клемент. Силы прогресса (The Forces of Progress): https://jtbd. info/the-forces-of-progress-4408bf995153

15. Интерком: работы, которые должны быть выполнены (Intercom on Jobs-to-be-Done): https://www.intercom.com/resources/books/ intercom-j obs-to-be-done

16. Работы, которые должны быть выполнены в Git Lab (Jobs to be Done at GitLab): https://handbook.gitlab.com/handbook/product/ux/jobs-to-be-done/

17. С. Беннинг, Т. Мофкади. Финансовое моделирование, пятое издание (Financial Modeling, fifth edition): https://www.amazon.com/ Financial-Modeling-fifth-Simon-Benninga/dp/0262046423

18. Дж Мур. Преодоление пропасти (Crossing the Chasm): https:// www.amazon.com/Crossing-Chasm-3rd-Disruptive-Mainstream/ dp/0062292986

19. Л. Хоманн. Инновационные игры (Innovation Games): https:// www.amazon.com/Innovation-Games-Creating-Breakthrough-Collaborative/dp/0321437292

20. Ф. Лалу. Открывая организации будущего (Reinventing Organizations): https://www.chitai-gorod.ru/product/otkryvaya-organizacii-budushchego-2495269

21. Э. Мейер, P. Хастингс. Никаких правил. Уникальная культура Netflix (No Rules Rules: Netflix and the Culture of Reinvention): https:// www.chitai-gorod.ru/product/nikakih-pravil-unikalnaya-kultura-netf-lix-290718

22. P. Далио. Принципы. Жизнь и работа: https://www.chitai-gorod.ru/ product/principy-zhizn-i-rabota-2676533

23. Втягивание вместо выталкивания: https://www.industryweek.com/ cloud-computing/article/22023873/push-vs-pull-manufacturing-is-a-kanban-pull-system-right-for-your-company2:

24. https://tulip.co/blog/what-is-a-push-system-vs-a-pull-system/3:

25. https://en.wikipedia.org/wiki/Push%E2%80%93pull_strategy4:

26. https://blog.item24.com/en/lean-production/production-manage-ment-a-comparison-of-the-push-and-pull-principles/

Приложение

Для вашего удобства примеры расчетов финансовых моделей, пример расчета стоимости задержки и пример отчета команды роста доступны в электронном виде по ссылке https://shuvaev.com/productbook или по QR-коду, расположенному ниже.

Примечания

1

Часто можно услышать сокращение слова «функциональность» до «функционал». В профессиональной среде много споров по поводу правомерности такого сокращения, но слово активно используется в официальных документах профильных министерств. В книге во избежание разногласий будем всегда использовать «функциональность».

2

Scrum (англ.) – популярный фреймворк разработки.

3

Scream (англ. – крик) – пародийный фреймворк, включающий худшие практики Scrum.

4

Инкремент (англ, increment – увеличение) – увеличение параметра, полезная добавка. Инкрементальный – значит увеличивающийся постепенно.

5

Стейкхолдер (англ, stakeholder – держатель акций) – в первичном понимании инвестор, вкладывающий средства в разработку. В больших компаниях – это лицо, отвечающее за эффективность инвестиций. В дальнейшем круг стейкхолдеров был расширен, и к ним стали причислять более широкий круг заинтересованных лиц, в частности пользователей-спонсоров, например представителей крупных корпоративных клиентов.

6

Бутылочное горлышко (англ, bottle neck) – узкое место на производстве, когда из-за ограничений одного элемента производственной цепи ограничивается производительность всей цепи.

7

Окружения развертывания – компьютерная система, в которой выполняется ПО. В процессе разработки ПО может переходить в разные окружения – локальное (local, компьютер разработчика), тестовое (test, для тестирования на ошибки и нагрузку), производственное (production, открытое для пользователей).

8

Непрерывная интеграция ⁄ доставка (англ, continuous integration ⁄ delivery) – регулярный автоматический процесс сборки продукта из актуальной версии и развертывание в окружениях развертывания.

9

Производственная ячейка – локально сгруппированное оборудование для выполнения определенного производственного этапа.

10

фронтенд (англ, frontend – передний край) – часть информационной системы для взаимодействия с пользователем, которая содержит пользовательский интерфейс и его логику, а также часть для взаимодействия с бэкендом (англ, backend – задний край), на котором, как правило, содержатся данные и логика их обработки.

11

QA (Quality Assurance, обеспечение качества) – процесс, направленный на формирование у продукта качественных характеристик определенного стандарта в процессе создания, эксплуатации, транспортировки и обслуживания.

12

Вайрфрейм (англ, wireframe – проволочный каркас) – эскизное обозначение элементов интерфейса на экране, напоминающее чертеж.

13

Хард-тек (англ, hard tech – сложные технологии) – классификация организаций, создающих продукты, которые непросто скопировать за счет сложности используемых технологий, ноу-хау, открытий, секретов. Более наукоемкие варианты хард-тек-компаний, ориентированных на радикальную трансформацию индустрий, принято называть «глубокие технологии» (deep tech).

14

Пользовательский опыт (UX или UE) – это то, как пользователь взаимодействует с продуктом, системой или услугой.

15

Идеация – процесс генерации идей. Может быть коллективным и организованным по различным творческим методикам для достижения максимального эффекта.

16

Материальный поток – находящиеся в движении вещественные объекты, к которым относятся сырье, вспомогательные материалы, полуфабрикаты, готовая продукция и отходы.

17

Спринт (англ, sprint – забег) – итерация в разработке, когда команда, ограниченная небольшим промежутком времени (до 1 мес.), сфокусирована на решении определенных задач.

18

Бенчмаркинг (англ, benchmarking) – сопоставительный анализ на основе эталонных показателей как процесс определения, понимания и адаптации имеющихся примеров эффективного функционирования предприятия с целью улучшения работы.

19

Граничный объект (англ, boundary object) – промежуточный артефакт, эффективный для передачи между группами для качественного взаимодействия. Компактный, понятный сторонами, но обладающий достаточной свободой интерпретации для более эффективной обработки получателем.

20

Многие эксперты считают, что более подходящий перевод для Agile – это «ловкость, проворность». В противопоставление неповоротливости и косности предыдущих подходов.

21

Карго-культ – попытка добиться эффекта процесса за счет внешнего копирования без понимания сути. Последователи меланезийского культа самолетопоклонников внешне точно копировали атрибуты аэропортов из соломы и веток, чтобы привлекать самолеты с грузами.

22

* [21] Фреймворк (англ, framework) – набор правил и ограничений для достижения целей команды. Не является методологией, но позволяет выработать методологию в процессе.

23

Jira – один из самых известных инструментов управления задачами команды разработки.

24

Kanban-доска – инструмент, использующийся в бережливом подходе для визуализации этапности прохождения артефактов. Подробнее в п. 3.1.3.6.

25

Daily standup meeting (сокр. DSM) – ежедневная короткая встреча для синхронизации статусов и планов, подробнее в п. 3.2.3.

26

Пользовательская история (англ, user story) – способ описать элемент функциональности от лица пользователя. Шаблон описания: «Я как [тип пользователя] могу [новая возможность], чтобы [ожидаемый результат]».

27

Релиз-кандидат – версия приложения, развернутая в тестовой среде и максимально готовая к релизу в конце спринта.

28

Фреймворк разработки – набор кодовых библиотек, инструментов и договоренностей, увеличивающий эффективность написания кода.

29

Большие языковые модели (англ. Large Language Models, LLM) – генеративные модели машинного обучения, создающие текст по текстовому запросу. Получили массовую популярность с появлением chatGPT.

30

Скринкаст (англ, screencast) – трансляция экрана.

31

Горизонтально интегрированная компания – это компания, элементы структуры которой связаны со стадиями производства, например департамент дизайна, департамент разработки и пр., в отличие от вертикально интегрированных компаний, элементы структуры которой связаны с источниками прибыли и, по сути, представляют собой обособленные бизнесы внутри одной компании.

32

Кросс-функциональная команда – объединение людей с разными компетенциями для достижения общей цели.

33

WIP limit (сокр. Work In Progress limit, с англ. – ограничение работ в процессе) – практика ограничения элементов, которые одновременно в работе.

34

ToDo (образовано от англ, to do – работы к выполнению) используется разработчиками во многих случаях, в том числе в статусах задач.

35

Сходимость финансовой модели – когда для моделируемого объекта (бизнеса, продукта и т. п.) наступает момент прибыльности (доходы превосходят расходы).

36

UX (англ, user experience) – пользовательский опыт.

37

Репрезентативные данные – данные о выборке объектов, достаточные, чтобы с необходимой точностью сделать предположение о всей генеральной совокупности объектов.

38

Облачные сервисы очень часто предоставляют гранты стартапам, чтобы они могли проверить свою гипотезу.

39

«Волшебник страны Оз» – метод исследования, когда исследователь имитирует функциональность. Название связано с моментом в одноименной книге, когда герой говорил от имени кукол, изображающих волшебника.

40

Юнит-экономика – экономика одной поставки, способ оценки эффективности бизнеса путем оценки прибыльности (суммы доходов и расходов) одной поставки. (Подробнее об этом см. и. 4.3.2.)

41

Домен – область знаний.

42

Фактор автобуса (англ, bus factor) – количество разработчиков, при потере которых (в оригинале «попадании под автобус») поставка не может быть выполнена.

43

Технологический стек – набор технологий, используемых ПО и для разработки и поддержки ПО. Сюда входят базы данных, фронтенд-фреймворки, инструменты разработки, мониторинга, анализа данных, внешние API и пр.

44

* [43] Закон Меткалфа гласит, что полезность сети пропорциональна половине квадрата (п^2/2) численности пользователей этой сети.

45

SH – сокращение от англ, stakeholder – стейкхолдер.

46

Пользователи-спонсоры (англ, sponsor users) – пользователи, вовлеченные в создание продукта, например, представители бизнес-заказчика для В2В-продукта.

47

Скоуп (англ, scope) – набор фич и частей продукта, закрепленных за отдельной командой.

48

Контракт – термин в контрактном программировании, обозначающий точное верифицируемое описание интерфейсов между компонентами системы.

49

Мок (англ, mock-object) – объект, имитирующий реальный объект, часто методы API. Используется в процессе разработки для отладки ПО.

50

Проприетарный Agile-фреймворк – фреймворки масштабирования гибких подходов, разработанные для конкретной компании, как например: Сбер, МТС, Яндекс и пр.

51

В некоторых компаниях (например МТС) присутствуют оба термина. Чаптер называется Центром Практик, плюс есть связное методологическое формирование – Центр Компетенции.

52

SAFe and Scaled Agile Framework являются зарегистрированными торговыми марками Scaled Agile, Inc.

53

Финансовое моделирование – это процесс построения абстрактного представления (финансовой модели) реальной или предполагаемой финансовой ситуации.

54

Конверсия (англ, conversation rate) – мера преобразования чего-либо. В цифровой аналитике – отношение количества событий, зафиксированных на текущем шаге к количеству на предыдущем.

55

Нанять решение (Hire solution) – термин, используемый в подходе «Работы к выполнению» (Jobs to be done). В нем решения или продукты представляются как конкуренты на рынке труда, которые соревнуются за право быть нанятыми для выполнения работы для пользователя.

56

МСБ-клиенты – представители малого или среднего бизнеса.

57

Бакеты (англ, bucket – ведро) в А/В-тестировании – это группы пользователей, которые получают разные варианты продукта для сравнения их эффекта. Обычно бакеты формируются случайным образом, чтобы обеспечить равномерное распределение пользователей по группам. Бакеты также называются сегментами, ветвями или вариантами.

58

Соцсети признаны экстремистскими и запрещены на территории РФ.

59

Соцсеть признана экстремистской и запрещена на территории РФ.

60

Соцсеть признана экстремистской и запрещена на территории РФ.

61

Соцсеть признана экстремистской и запрещена на территории РФ.

62

Соцсеть признана экстремистской и запрещена на территории РФ.

63

Флайт (англ, flight) – это период рекламной кампании с заданным сроком, обычно 3–6 недель.

Content

Ярослав Шуваев
Менеджмент цифрового продукта. От идеи до идеала

Предисловие автора

Для кого эта книга

Термины и определения

Введение

Глава 1 Различия между продуктовым и проектным подходами

1.1. Переход на собственную внутреннюю разработку

1.2. Циклы доработки по стремительно сокращаются

1.3. Непрерывное инвестирование и непрерывный возврат инвестиций

Глава 2 Бережливое производство и бережливая разработка

2.1. Минимизация отходов

2.1.1. Потери из-за перепроизводства

2.1.2. Потери времени из-за ожидания

2.1.3. Потери при ненужной транспортировке

2.1.4. Потери из-за лишних этапов обработки

2.1.5. Потери из-за лишних запасов

2.1.6. Потери из-за ненужных перемещений

2.1.7. Потери из-за выпуска дефектной продукции

2.2. Принципы ориентации на максимальную ценность для потребителя

2.2.1. Определение ценности продукта

2.2.2. Определение потока ценности

2.2.3. Обеспечение свободного течения потока ценности

2.2.4. Втягивание вместо выталкивания

2.2.5. Стремление к совершенству

2.3. Бережливый цикл разработки

2.3.1. Этапы цикла бережливого стартапа

2.4. Циклы открытия и поставки

Глава 3 Цикл поставки

3.1. Agile

3.1.1. Agile-манифест

3.1.1.1. Люди и взаимодействие важнее процессов и инструментов

3.1.1.2. Работающее ПО важнее подробной документации

3.1.1.3. Реагирование на изменения важнее следования плану

3.1.2. Пример гибкого подхода

3.1.3. Область применения гибких подходов

3.1.3.1. Водопадный подход

3.1.3.2. Scrum

3.1.3.3. Контринтуитивность

3.1.3.4. Связь с культурой компании

3.1.3.5. Связь между Scrum и водопадом

3.1.3.6. Kanban

3.1.3.7. Связь между Scrum и Kanban

3.1.3.8. Бережливый стартап

3.2. Scrum

3.2.1. Роли в Scrum

3.2.1.1. Scrum-команда

3.2.1.2. Лучшие практики организации Scrum-команд

3.2.1.2. Команда разработки

3.2.2. Лучшие практики

3.2.2.1. Т-образные специалисты

3.2.2.2. Минимальная команда

3.2.2.3. Долгое время вместе

3.2.2.4. Владелец продукта

3.2.2.5. Scrum-мастер

3.2.3. События Scrum

3.2.3.1. Краткое описание событий Scrum

3.2.3.2. Лучшие практики организации расписания событий Scrum

3.2.3.3. Планирование спринта

3.2.3.4. Лучшие практики планирования

3.2.3.5. Ежедневный Scrum

3.2.3.6. Обзор спринта

3.2.3.7. Лучшие практики обзора спринта

3.2.3.8. Ретроспектива спринта

3.2.3.9. Лучшие практики ретроспективы

3.2.3.10. Прояснение бэклога

3.2.3.11. Декомпозиция элементов продуктового бэклога

3.2.3.12. Картирование пользовательских историй

3.2.3.13. Связь карты пользовательской истории и бэклога продукта

3.2.3.14. Шаблоны декомпозиции

3.2.3.15. Оценка элементов продуктового бэклога

3.2.3.16. Отмена спринта

3.2.4. Артефакты Scrum

3.2.4.1. Бэклог продукта

3.2.4.2. Бэклог спринта

3.2.4.3. Инкремент продукта

3.3. Управление качеством программного обеспечения

3.3.1. Запланированное улучшение качества системы

3.3.2. Незапланированное улучшение качества системы

3.3.3. Запланированное ухудшение качества системы

3.3.4. Незапланированное ухудшение качества системы (дефекты)

3.3.5. Масштабирование гибких подходов

3.3.5.1. Масштабирование в процессе роста

3.3.5.2. Масштабирование в уже существующей компании

3.3.6. Понятие и цели масштабирования гибких подходов

3.3.7. Основные принципы и практики масштабирования гибких подходов

3.3.8. Основные фреймворки и модели масштабирования гибких подходов

3.3.8.1. Модель Spotify

3.3.8.2. Scaled Agile Framework

3.3.8.3. Scrum@Scale

Глава 4 Цикл открытия

4.1. Основные принципы управления портфелем инициатив

4.1.1. Организация конвейера открытий

4.1.1.1. Практики ускорения прохождения конвейера открытий

4.1.2. Портфель инициатив

4.2. Концепция цифровой инициативы

4.2.1. Формулирование концепции инициативы

4.2.1.1. Анализ стратегических целей компании

4.2.1.2. Исследование клиентов и их потребностей

4.2.1.3. Анализ внешней среды

4.2.1.4. Описание концепции инициативы

4.2.1.5. Оценка ресурсов

4.2.1.6. Составление презентации концепции инициативы

4.2.2. Приоритизация концепций инициатив

4.2.2.1. RICE

4.2.2.2. MoSCoW

4.2.2.3. Точечное голосование

4.2.2.4. Процесс приоритизации

4.3. Гипотеза инициативы

4.3.1. Метрики продукта

4.3.1.1. Метрики качества опыта

4.3.1.2. Метрики управленческого учета

4.3.1.3. Инвестиционные метрики

4.3.2. Юнит-экономика

4.3.3. Финансовое моделирование

4.3.3.1. Пример финансовой модели для цифрового продукта

4.3.3.2. Выбор метрик для гипотез жизнеспособности

4.3.3.3. Выбор значений для метрик гипотез жизнеспособности

4.3.3.4. Отраслевой бенчмаркинг

4.3.3.5. Модель дохода от роста конверсии

4.3.3.6. Модель дохода от роста удержания

4.3.3.7. Комплексные финансовые модели

4.3.3.8. Финансовая модель портфеля инициатив

4.3.4. Выявление присущих рисков инициативы

4.3.4.1. Как оценивается объем рисков

4.3.4.2. Выставление порога риска для проекта

4.3.5. Оценка трудозатрат на разработку

4.3.5.1. Ретроспективная оценка трудозатрат

4.3.5.2. Оценка по «ведрам»

4.3.5.3. Оценка по сходству

4.3.6. Составление презентации гипотезы инициативы

4.3.7. Приоритизация гипотез инициатив

4.3.7.1. Стоимость задержки

4.3.7.2. Приоритизация по WSJF

4.3.7.3. Игра «Купи фичу»

4.3.8. Мониторинг внедрения

4.3.8.1. Подготовка к мониторингу

4.3.8.2. Подтверждение гипотез жизнеспособности

4.3.9. Пример поэтапного развития инициативы от идеи до мониторинга внедрения

Глава 5 Основы цифрового маркетинга

5.1. Основные направления цифрового маркетинга

5.2. Команды роста

5.2.1. Основные типы команд роста

5.2.2. Производственный цикл команд роста

5.2.2.2. Связь производственного цикла команд роста с циклом организации

5.2.2.3. Пример эффективного отчета команды роста

5.2.3. Хакинг роста

5.2.3.1. Советы и лучшие практики по хакингу роста

Глава 6 Основы управления цифровой компанией

6.1. Эффективная культура

6.1.1. Бирюзовые принципы

6.1.2. Ценности Scrum

6.1.3. Непрерывное самосовершенствование

6.2. Управление инновациями

6.3. Стратегическое, тактическое и операционное целеполагание

6.3.1. Стратегическое целеполагание

6.3.2. Тактическое целеполагание

6.3.3. Операционное целеполагание

6.4. Централизованные системы

Заключение

Источники

Приложение

Примечания