➠ Частично бесплатная (фримиум, 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-компанией, которая способна расти в разы, сохраняя при этом гибкость и эффективность.

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

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

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

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

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

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