Как происходит защита проекта пилотной версии продукта в продуктовом подходе? С помощью соответствующего артефакта, "Карточки проекта". При переходе со стадии Design на стадию Development фреймворка для управления инициативами, чтобы получить бюджет для следующей стадии, Product owner готовит "Карточку проекта" - в нем описаны все составляющие проекта по реализации инициативы.
"Карточка проекта" похожа на «Карточку инициативы» - эту карточку вы также защищаете, но на стадии Ideation, когда ваша задача - пройти валидацию идеи и получить бюджет, чтобы перейти со своей идеей на стадию Discovery и ее исследовать, прорабатывать.
Основные составляющие для «Карточки проекта», но уже провалидированные, берутся из «Карточки инициативы».
Рассмотрим пример того, как может выглядеть «Карточка проекта».
Первый слайд (лист) – это своеобразный паспорт проекта, здесь коротко отображаются основные составляющие инициативы.
- Название проекта – это короткое и ясное название вашей инициативы, того решения, которое вы реализуете.
- В блоке «Целевые сегменты» нужно указать ту аудиторию, на которую ваше решение должно повлиять и за счет которого вы получите бизнес-эффект. В блоке «Проблематика» вы указываете провалидированные гипотезы о проблемах целевых сегментов.
- Также вы указываете провалидированные гипотезы о решениях этих проблем в соответствующих блоках («Ключевые гипотезы»).
В блоке «Проект MVP» возможны разные варианты наполнения.
- Если вы уже запустили MVP и собираетесь реализовать полноценное решение, то вы описываете, как все было.
- Если же вы еще пока защищаете бюджет на реализацию MVP, то вы указываете что вы собираетесь реализовывать в рамках MVP.
В обоих случаях вы указываете пилотную зону, какой у вас пилотный сегмент, размер пилотной аудитории.
Вы указываете user stories, какие пункты бэклога должен включать MVP, метрики, которые служат критериями его успешности MVP – саму метрику, ее текущий показатель и целевой показатель, достижение которого укажет на то, что MVP работает, решение удачное.
Можно взять три-четыре ключевых метрики, которые вы прорабатывали на предыдущих этапах работы над инициативой.
- Если вы уже запускали MVP, нужно показать, на какие метрики вы смотрели, когда это делали.
- Если вы только готовитесь запустить MVP, то вы говорите про те метрики, по которым будете принимать решение: сработало MVP или не нет?
В roadmap MVP вы указываете ключевые этапы запуска MVP - реализация MVP до такой-то даты, запуск, «раскатка», сам эксперимент, подведение результатов (неделю-две).
- В блоке «Экономика» вы указываете источники прибыли (берете их из подготовленной вами финансовой модели) в двух вариантах (целевой и амбициозный, превосходящий ожидания), затраты по различным составляющим, отдельно – затраты на команду. Здесь вы указываете не конкретные фамилии, а сколько человек, какой компетенции вам нужно, с каким вовлечением.
- Также на общем, базовом слайде «Карточки проекта» нужно указать имена и фамилии владельца продукта и спонсора (того, кто отвечает за бюджет).
В блоке справа внизу вы указываете ключевые риски.
Это те риски, которые, например, могут, сдвинуть сроки реализации MVP, помешать достичь цели, юридические ограничения, нехватка ресурсов и т.д.
Описывая риски, в графе «как решаем» вы должны указать, как будете их нивелировать, решать, указываете предложения по решению.
- Если вы знаете как митигировать (уменьшить вероятность наступления рискового события и минимизировать последствия его возможного наступления) риски, то вы указываете решения.
- Если нет – то вы указываете, чья помощь вам потребуется. Например, вы можете указать, что вам потребуется вовлечение руководителя IT, если у вас есть риск нехватки IT-ресурсов.
Верхнеуровневая дорожная карта по инициативе делится на три части.
- Первый разрез – «Максимальная детализация».
Это описание MVP - либо ближайший шаг, либо уже пройденный шаг.
- Второй разрез – средний уровень детализации
Это уже дорожная карта реализации целевого, полноценного решения.
- Третий разрез - "Целевое видение проекта, гипотезы"
Здесь уровень достоверности невысокий.
Указываются гипотезы о том, что будет происходить с продуктом в будущем.
- В «Команде проекта» вы описываете внутренние и внешние ресурсы.
На первом, основном слайде «Карточки проекта» в команде проекта вы указываете не конкретные фамилии, а сколько человек, какой компетенции вам нужно, с каким вовлечением.
Здесь же, на слайде «Команда проекта» вы все расписываете подробно: роль, компетенция, ФИО (если нет и TBD, если нет, вы узнаете ФИО после утверждения этого проекта, когда пройдет процедура выделения, сбора команды из контрактных людей со стороны IT, со стороны бизнеса, со стороны еще кого-то).
В графе «Внутренние ресурсы» есть разделение:
- команда проекта - те, кто работает над продуктом и реализует его
- команда поддержки – те, кто будет сопровождать продукт в дальнейшем, когда вы его запустите
Вовлеченность может быть на все время, full time, либо частично.
Графа «Задачи» заполняется опционально.
Если вы понимаете, за какие задачи, зоны человек будет отвечать, можно здесь их перечислить.
В графе «Компетенции», например, можно прописать следующее.
- Роль - «Владелец продукта».
Компетенция - проведение исследований, работа с данным и т.д.
- Роль - Backend разработчик.
Компетенция - разработка API на Java, написание тестов и т.д.
Важно, что вы должны разделить команду на внешние и внутренние ресурсы.
Т.е. здесь желательно указывать, какие позиции вы будете закрывать inhouse, т.е. нанимать людей в штат, а какие позиции вы можете закрыть вендорами, т.е. привлечением аутсорса.
По внутренним ресурсам считается FTE.
По внешним можно тоже посчитать, но обычно, если вы знаете ставки, то можно указывать конкретные деньги - бюджет, который нужен на привлечение внешних ресурсов.
- Помимо «Команды проекта» еще важно указать стейкхолдеров - ключевых, заинтересованных в вашем проекте лиц.
Проект решения
- На слайде «Проект решения» вы описываете те тезисы, которые вам нужно утвердить.
Т.е. вы говорите о том, что проект «такой-то» вам нужно коллегиальным решением управляющего комитета перевести на этап Development (или Внедрение, или масштабирование, в зависимости от того, в какой момент жизненного цикла продукта вы выходите на этот управляющий комитет).
Вы говорите о том, какой бюджет вам необходим на ту стадию, на которую вы переходите, и что вам нам нужно выделить команду указанного состава.
- В блоке «Приложения» вы можете вставить все рабочие материалы, которые вы прорабатывали в ходе предыдущий стадий.
Например, это могут быть:
- CJM пользователя
- обязательно финансовая модель продукта
- обязательно дорожная карта инициативы
Так как речь идет о конкретных деньгах, выделении конкретного бюджета, то в «Карточке проекта» вы описываете уже проработанное решение, оно должно быть более детальным.
В финансовой модели должны быть точно просчитаны и указаны данные по доходам, целевым показателям метрик, расходам.
Хотите внедрить продуктовый подход, обучить Владельцев продуктов или топ-менеджмент? Обращайтесь, будем рады помочь!
Мы всегда на связи: Telegram, сайт, info@neuromap.tech.
Читайте наши паблики, оставляйте заявки на обучение, бесплатную консультацию.
Удачи в бизнесе!
