Несколько картинок, полезных для понимания и объяснения ключевых идей в управлении продуктами
Говорят, одна картинка стоит тысячи слов, но я, если честно, думаю, что это даже преуменьшение: визуализация помогает обеспечить общее понимание идеи, упростить коммуникацию и устранить большую часть нюансов, присущих письменной и устной речи.
Мне хотелось бы показать вам шесть схем, которые я часто использую при обсуждении идей, касающихся управления продуктами. Они хорошо принимаются аудиторией и отлично передают суть. Вот эти схемы:
- «Менеджер по продукту как узкое место».
- «Воронка доставки продукта».
- «Классическое противостояние Waterfall — Agile».
- «Размер инициативы, риск и вовлечение руководства».
- «Бункеры знаний».
- «Важность сегментации».
Можете использовать их в своей работе каким угодно способом.
Переведено в Alconost
«Менеджер по продукту как узкое место»
Одна из самых распространенных ошибок, которые я замечаю у менеджеров по продуктам, — это стремление участвовать во всех обсуждениях. Да, за этим стоит правильное намерение: вам нужно разбираться во всём, чтобы иметь возможность ответить на любой вопрос по продукту.
К сожалению, в таком подходе есть много минусов. Во-первых, это непрактично: вы очень быстро окажетесь перегружены информацией, что отрицательно скажется не только на эффективности команды, но и на вашем самочувствии. Поверьте — я испытал это на себе. Во-вторых, вы таким образом разрушаете автономию команды.
Хороший менеджер по продукту знает, когда нужно вмешаться, а когда лучше отойти в сторону — поговорят и разберутся сами. Цель создания автономной команды — устранить как можно больше зависимостей.
Рассмотрим пример на картинке ниже. Представьте себе ситуацию слева, когда веб-разработчик спрашивает о том, какой алгоритм отслеживания реализовать, а менеджер по продукту обращается к аналитикам, которые говорят, что нужно придерживаться реализации iOS. Затем менеджер идет к iOS-разработчику, получает нужную информацию, а затем возвращается к веб-разработчику и всё ему объясняет. Такой подход не только добавляет менеджеру по продукту лишнюю работу, но и задерживает решение вопроса.
Сравните это с примером справа: веб-разработчик обращается напрямую сначала к аналитику (тот объясняет, что требуется), а затем к специалисту по iOS (который дает нужную информацию). Обратите внимание, насколько меньше в этом случае взаимодействий (красные стрелки).
Если расширить наш пример и добавить еще несколько стрелок (зеленые и синие), это будет намного ближе к реальному числу одновременно решаемых в команде вопросов. Количество взаимодействий быстро увеличивается, и все они завязаны на менеджере.
Как применять схему. Если вы постоянно перегружены, подумайте о том, оптимально ли налажено взаимодействие в команде: правда ли вам необходимо быть на каждом собрании? Продолжается ли нормальная работа, пока вы в отпуске, или всё останавливается? Если верно последнее, то вам нужно сознательно приложить усилия, которые позволят упростить взаимодействие в ваше отсутствие.
«Воронка доставки продукта»
Это одна из моих любимых схем: она позволяет объяснить понятие воронки продуктивности команд относительно величины проектов, над которыми ведется работа. Часто мне приходится сталкиваться с разочарованием и деловых партнеров, и разработчиков по поводу времени выхода продукта на рынок: им кажется, что работа идет слишком медленно.
Обычно эта проблема вызвана тем, что работа ведется только над большими задачами (воронка слева). В результате команда может одновременно заниматься только чем-то одним. Такой подход может быть правильным, если мы уверены, что определенная функция обязательно будет востребована — а это бывает редко. Если что-то выходит с конвейера (в нашем случае — из воронки) и оказывается ненужным, то вы в итоге затрачиваете больше усилий, чтобы это понять, чем требовалось.
Причина, по которой в гибком подходе к разработке стремятся делить работу на меньшие фрагменты, заключается в том, что это позволяет быстрее получать ощутимый, ценный для бизнеса результат, причем с меньшим риском. Воронка справа дает гораздо больший простор для маневра: меньшие по объему задачи (синие точки) могут быстрее проходить через воронку — а значит, они быстрее будут проверены в деле. Если результат оказался успешным, можно вложить больше усилий (розовый кружок). Если результат неудовлетворительный — переключаемся на что-нибудь другое, но ограничиваем выделяемые ресурсы. Каждая проверка на практике позволяет увеличивать вкладываемые ресурсы. В итоге у нас множество маленьких проектов, несколько средних и совсем мало — больших. Таким образом снижается риск и повышается окупаемость вложений.
Как применять схему. Вспомните, над чем пришлось работать в последние месяцы (в том числе над тем, что было отброшено). Были ли все задачи большими по масштабу и сложности, или это было сочетание различных текущих задач (и по одной теме, и по разным)? Назначьте каждой задаче размер (например, по шкале S, M, L) и представьте, как будет выглядеть воронка.
«Классическое противостояние Waterfall — Agile»
В Интернете множество примеров на эту тему, но мне хотелось бы обратить внимание на затрачиваемые усилия. Многие продуктовые компании не говорят напрямую о том, что время команды — тоже инвестиция. Если бы у менеджеров по продуктам были в распоряжении отчеты по прибылям и убыткам их детища, они бы увидели, что заработная плата — часто самая большая статья расходов. Поэтому нужно искать все возможности повысить прибыль (возврат инвестиций).
Когда команда сдает работу большими фрагментами, мы надеемся получить немедленный эффект. Но даже если допустить, что мы сразу выпускаем идеальное решение без технических проблем (скажу по секрету: такое очень маловероятно), то получается, что наша команда (если смотреть по шкале времени) делала крупные инвестиции, которые ничего не давали (график слева).
Выпуская продукт чаще, меньшими частями, вы сдаете работу постепенно — и это начинает сразу же окупаться, потому что вы можете быстрее учиться на ошибках и понимать, что нужно, а что — нет. На втором графике ценность продукта для бизнеса почти всегда выше стоимости затраченных усилий — именно к этому нужно стремиться.
Как применять схему. Я часто использую эти графики, когда нужно объяснить, почему добавить что-нибудь еще к возможностям продукта на текущей итерации — не всегда в наших интересах. Кроме того, с их помощью удобно напоминать себе и команде о коммерческой стороне вопроса.
«Размер инициативы, риск и вовлечение руководства»
Эта диаграмма отражает два аспекта. Слева — сама пирамида инициатив. Ее ширина показывает, над каким числом инициатив можно работать одновременно: широкое основание — много, узкое — мало. При этом задачи с более высоким риском находятся вверху (их немного), а с небольшим риском — внизу (таких больше).
Справа — индикатор участия руководства. Чем он шире, тем большее вовлечение руководства в работу требуется или ожидается — то есть, с бо́льшим числом начальников более высокого ранга нужно советоваться. Чем индикатор у́же, тем меньше нужно обращаться к «вышестоящим».
У вас наверняка есть множество мелких задач — вроде проверки написанных текстов или нарисованных картинок: риск у них очень низкий, результаты можно постоянно оптимизировать. Здесь руководству участвовать будет не очень интересно — да и смысла в этом нет. А вот у задач в верхней части пирамиды риск будет выше (например, это может быть запуск совершенно нового продукта) — тут-то и понадобится участие и поддержка руководства.
Как применять схему. По моему опыту, эта схема — отличный инструмент как для руководителей, так и для самих команд: она объясняет, почему руководство необходимо привлекать в одних случаях, и почему этого не стоит делать в других.
Тема участия руководителей в работе довольно сложная. Подробнее я рассмотрел ее в статье Почему «Модель Spotify» не решает всех проблем.
«Бункеры знаний»
Эта диаграмма — результат ежеквартальной проверки положения дел в команде, где работал мой коллега. Это — прекрасный способ визуализировать влияние изолированности отделов и команд в отношении обмена знаниями. Невозможно быть осведомленным на 100% во всех областях, затрагиваемых выпускаемым продуктом, но если осознавать недостаток знаний, это поможет сосредоточиться на коммуникации между отделами.
Отдельный сотрудник обычно хорошо ориентируется в том, над чем работает. Но чем дальше от вас находятся другие, тем меньше они осведомлены в «вашей» теме.
Как применять схему. Напоминайте себе и остальным, что работа в организации обязательно будет замедляться из-за того, что никто не может знать всё, и, что ещё важнее, — если возникает конфликт, то одной из наиболее вероятных причин будет недостаток информации, а не злой умысел (см. статью Недопонимание, а не злой умысел).
«Важность сегментации»
Одна из распространенных ошибок, которые мне встречаются, когда в компании рассматривают инициативы и эксперименты, — это оптимизация по средним значениям, а не по сегментам. Мой любимый пример искаженного к среднему восприятия: «В среднем у человека меньше двух ног».
Если гипотезы и области охвата становятся слишком обширными, они естественным образом ограничивают потенциальное влияние теста. По сути, вы пытаетесь удовлетворить множество людей одновременно — и это вряд ли сработает. На приведенной ниже схеме наиболее распространенным является третий случай (справа), в котором существенных изменений нет.
Ниже приведены три гипотетических эксперимента. В первом мы получили подъем, во втором — падение, в третьем изменений не было. Однако часто, если углубиться в результаты, можно найти новые потенциальные возможности или какие-то ограничения. В первом случае, хотя эксперимент в целом и был успешным, в сегменте B можно увидеть снижение показателей — здесь нужно было бы разобраться, в чем причина ухудшения, и, возможно, исключить его при выпуске продукта.
Взглянем теперь на третий случай. В целом существенных изменений не было, однако положительные результаты есть в сегментах B и C — и они компенсируются падением в сегментах A и D. Таким образом, и здесь мы получили направление, которое можно в дальнейшем изучить.
Как применять схему. Старайтесь формулировать более конкретные гипотезы и изучайте результаты на предмет дополнительных возможностей и ограничений. По теме гипотез и экспериментов я настоятельно рекомендую почитать что-нибудь из Рика Хайама — загляните в его Экспериментальный центр. Создавайте архетипы с помощью исследований пользователей и демографических данных (Никки Андерсон) — это поможет лучше понять, на какой сегмент потребителей вы нацелены.
Заключение
Вот и всё. Надеюсь, приведенные схемы и диаграммы помогут визуализировать некоторые концепции и объяснить их остальным!
О переводчике
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
→ Подробнее
