GTM Maturity Model: как оценить зрелость цифрового продукта и управлять его развитием

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

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

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

GTM Maturity Model — это системный подход к оценке зрелости продукта, который объединил лучшие практики по 15 направлениям разработки, маркетинга и управления командой.

Эти направления вы видите на картинке. Каждое из них формирует «луч» звезды, определяющей зрелость продукта по шкале от 0 до 5.

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

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

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

Как это работает?

Разберём на примере. Один из ключевых векторов развития продукта — нефункциональные требования (НФТ). Это динамическая характеристика, которая показывает, соответствует ли продукт рыночным ожиданиям, но не по функциям, а по таким параметрам, как безопасность, удобство интерфейсов, производительность, надёжность, доступность с разных устройств, совместимость с различными типовыми системами и тому подобное.

Как оценить эту характеристику? Есть не менее 11 метрик, по которым её можно измерить. Это:
• соответствие стандартам безопасности,
• время отклика системы,
• скорость прохождения пользовательских сценариев,
• процент успешных нагрузочных тестов,
• наличие SLA для uptime,
• количество критических инцидентов,
• скорость восстановления после сбоя,
• доля автоматизированных тестов НФТ,
• соответствие требованиям accessibility,
• уровень технического долга, связанного с НФТ,
• наличие НФТ в контрактах и др.

В каждой метрике мы прописали условия и бенчмарки, которые определяют, по данному параметру всё ок или не ок. Например, соответствие стандартам безопасности — это бинарная метрика. Если у продукта есть сертификаты (ISO 27001, SOC2), то оценка положительная, если нет — то отрицательная.

Отклик системы должен составлять ≤500 мс для 95% запросов. Процент успешных нагрузочных тестов должен быть выше 95%, а время восстановления системы после сбоя — меньше 15 минут.

Собрав все данные по НФТ и прогнав через эту оценку, вы получаете понимание, на каком уровне зрелости находится продукт по критерию нефункциональных требований. И, так как в GTM Maturity Model шкала от 0 до 5, то и уровней 5.

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

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

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

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

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

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

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

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

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

На примере тех же НФТ, за целеполагание и управление отвечают архитектор решений, руководитель DevOps, CISO (Chief Information Security Officer), продакт-менеджер, руководитель QA. Они определяют стандарты, ставят KPI, управляют компромиссами между НФТ и бизнес-целями.

А за исполнение отвечают DevOps-инженеры, security-специалисты, backend-разработчики, тестировщики производительности, SRE-инженеры, технические писатели, сетевые администраторы, Data-инженеры, юристы, специалисты по compliance. Эти люди реализуют, тестируют и поддерживают НФТ на всех этапах жизненного цикла продукта.

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

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

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

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

3. понятно кто должен поставить цели, а кто — их достичь,

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

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

Друзья, подробнее про каждое направление GTM Maturity Model расскажем на основе вашей обратной связи. Про какой из векторов вам интересно узнать в первую очередь? Дайте знать в комментариях в нашем TG-канале ➡