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

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

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

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