Главная » Хабрахабр » [Перевод] Почему вам стоит перестать использовать продуктовые роадмапы и попробовать GIST

[Перевод] Почему вам стоит перестать использовать продуктовые роадмапы и попробовать GIST

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

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

Раньше я делал так:

Стратегия — Роадмап — План проекта — Реализация (Agile).

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

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

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

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

Итак, в чём же заключается альтернатива?

GIST

Я внедрял GIST в нескольких компаниях и результаты очень схожи — на выходе мы имеем простые легковесные планы, готовые к изменениям и быстрому обновлению, меньше нагрузки на менеджеров, больше автономии команды разработки и возросшую скорость их работы, упрощённое взаимодействие внутри компании и в результате гораздо лучшие продукты и управленческие решения. Это система планирования, которую я начал использовать, работая в Google и в дальнейшем в течение нескольких лет адаптировал под принципы Lean Startup и Agile.

Каждый из этих блоков имеет свой горизонт планирования и подразумевает свою частоту изменений; для каждого блока может использоваться разный инструментарий для управления, но все они формируют планирование для компании в целом и определяют действия команд. Эта система названа мной GIST по названию основных блоков: Goals (цели), ideas (идеи), step-projects (шаг-проекты), tasks (задачи).

Цели — год 1, год 2.
Идеи.
Шаг-проекты — квартал 1, квартал 2, квартал 3, квартал 4.
Задачи.

Цели

“Если вы скажете человеку куда идти, но не скажете, как туда попасть, то будете поражены результатами”

Паттон Джордж С.

Любой генерал современной армии скажет, что такой подход должен остаться в прошлом — нужно задать солдатам цель и предоставить возможность достичь её самостоятельно (принцип Mission Command). Большинство стратегических планов грешит тем, что определяет решения, а не цели (используем технологию X, партнеримся с компанией Y, запускаемся в стране Z). Такой подход подразумевает больше полномочий, он более осмысленен и снижает нагрузку на менеджмент — решения могут меняться в зависимости от ситуации в поле, а цели остаются неизменны.

В любой момент времени цели отвечают на вопрос “Почему мы занимаемся этим проектом”. Цели в рамках GIST воплощают эти принципы — они описывают стратегию компании в терминах желаемого результата: куда мы хотим прийти, когда, как поймём, что пришли.

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

Примеры целей в форме записи OKR:

4% и менее. Ц: Выйти на безубыточность к концу 2018 г.
КР: Минимум 5 новых энтерпрайз-клиентов.
КР: Уменьшить отток до 2.

Ц: Предоставить возможность пользоваться продуктом на мобильных платформах.
КР: MAU на мобильных > 20 000.
КР: >25% ключевых действий производится на мобильных.

Ц: Приятный пользовательский опыт без багов.
КР: Починить топ-10 багов, зарепорченных пользователями.
КР: Уменьшить длительность ответа техподдержки на 40%.

Идеи

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

Линус Паулинг

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

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

Вместо этого мы:

  1. Собираем все идеи в Банк Идей — в основном это отдельная БД или таблица в Excel. Приветствуются любые идеи, и в Банке могут быть сотни идей.
  2. Приоритезируем, отталкиваясь от доказательств — мне нравится ICE-приоритезация от Шона Эллиса, но можно использовать любой метод (оценивать трудозатраты и отдачу — недостаточно!).
  3. Планируем в тестирование настолько много идей, насколько это возможно — они реализуются в рамках шаг-проектов.

Шаг-проекты

“Думайте о великом, но начинайте с малого”

Один из 8 столпов инноваций от Google

Это распространённая и очень дорогостоящая ошибка — можно потратить кварталы, иногда даже годы на ещё неподтверждённую идею. Очень соблазнительно выбрать одну многообещающую идею, превратить её в проект на 9-18 месяцев и заняться реализацией. прожигание денег, ведь большинство идей вообще не стоит инвестиций. Это.

Вместо этого мы разбиваем крупные проекты на маленькие пошаговые проекты, шаг-проекты, каждый не дольше 10 недель, и реализуем их по одному за раз.

Пример шаг-проекта: мокап — прототип — MVP — dogfood — бета — запуск (релиз).

В правильной последовательности каждый шаг-проект включает в себя улучшенную, дополненную версию идеи, которая на каждом новом этапе доступна всё большему количеству пользователей. В соответствии с принципом Lean Startup Build-Measure-Learn, каждый шаг-проект — это фактически самостоятельный эксперимент по тестированию идеи.

1 → мокап v. Реальный пример проекта, декомпозированного на шаг-проекты:
Первоначальный план: Старт проекта → мокап v. 1, предварительное исследование → мокап v. 2 → рабочий прототип → черновая версия → dogfooding в компании → альфа → бета → X.
Фактические действия: Старт проекта → мокап v. 2, первое пользовательское исследование → рабочий прототип, второе пользовательское исследование → черновая версия, dogfooding в основной команде → dogfooding в компании → изучение результата dogfooding → альфа → интервью с альфа-пользователями → бета → опрос бета-пользователей → статистика использования → Y.

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

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

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

Задачи

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

Цикл планирования

Планирование с GIST с многоуровневое и итеративное:

  1. Цели обычно имеют горизонт планирования в один год или несколько лет — здесь как раз поощряется умение мыслить далеко наперёд. Они определяются в начале года и переоцениваются и корректируются каждый квартал — мы не хотим преследовать устаревшие цели.
  2. Идеи собираются и приоритизируются постоянно. Мы никогда не останавливаем процесс поиска новых идей.
  3. Шаг-проекты определяются в начале каждого квартала. Команда выбирает, какие цели и идеи она хочет реализовать в этом квартале и соответственно определяет шаг-проекты по ним. Список квартальных шаг-проектов переоценивается и переприоритезируется каждые 1-2 недели, с учётом планирования работ по задачам.

Задачи планируются в 1-2-недельные итерации предпочтительным для команды методом (например, на планировании спринта, если у вас скрам), и корректируются ежедневно.

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

Вам до сих пор нужны роадмапы?

Роадмапы обычно используются для следующих целей: Я думаю, нет.

  1. Планирование работы — надеюсь, теперь я вас убедил, что роадмапы не обязательны для этого.
  2. Внутренняя коммуникация — мой опыт показывает, что коллеги и члены правления охотно понимают и принимают язык GIST — переход не такой трудный и все ценят реалистичность и правдоподобность задач. Разумеется, вся система планирования должна быть доступна любому сотруднику компании и члену правления.
  3. Внешняя коммуникация — с клиентами и партнёрами ожидания от “формального роадмапа” могут быть очень высоки. Как обычно, это наша работа — сместить фокус обсуждения с конкретных фичей в пользу потребностей.
  4. При использовании GIST вы можете отвечать в стиле “У нас есть цель заняться взаимодействием внутри продукта в третьем квартале. Я не могу точно сказать, как это будет работать. У нас есть несколько идей и мы будем работать гибко. Скорее всего, у нас будет MVP во втором квартале. Хотите ли вы быть в числе бета-тестировщиков и дать фидбек?”
  5. Если повезёт, и взятые в работу идеи “выстрелят”, то это сработает лучше, чем любой график роадмапа.

Заключение

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

Основные принципы:

  • Нет разделения идей, планирования задач и их реализации — всё это происходит регулярно и зачастую одновременно.
  • Нужно формулировать цели вместо решений или расплывчатых формулировок стратегии.
  • Используются банки идей вместо продуктового бэклога.
  • Нужно двигаться короткими шаг-проектами внутри квартала, вместо длинных многоквартальных / многолетних проектов.
  • Не нужно делать ставки на несколько крупных идей, которые займут целую вечность — мы тестируем много идей быстро и доводим до релиза только те, которые работают.
  • Применяются итерации — ревизии каждой части плана проводятся часто и систематически, оставаясь Agile на всех уровнях.

Нам в объединённую компанию “Колёса | Крыша | Маркет” такие тоже нужны, поэтому у нас открыты вакансии менеджеров продуктов и менеджеров проектов. Весь мир развивается и для создания крутых продуктов нужны крутые продакт-менеджеры.

Кроме того, в июне мы запускаем “Колёса Академию”, где проведём обучение менеджеров, разработчиков, тестировщиков и UX-дизайнеров.


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Newman и Continuous Integration на примере Atlassian Bamboo. Изобретение велосипеда

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

«Невозможная» ретро игра

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