Русский
Русский
English
Статистика
Реклама

Управление продуктами

Перевод 20 психологических уловок в дизайне продуктов

31.08.2020 14:14:39 | Автор: admin

Совершенствование продуктов с применением когнитивных искажений и моделей убеждения.



Несколько лет назад коллега из моей бывшей компании (BlaBlaCar) познакомил меня с игрой Mental Notes. Разрабатывая какую-либо функцию, мы вместе с несколькими менеджерами по продукту, дизайнерами и разработчиками делали поведенческий анализ, во время которого старались понять, как и какие принципы поведенческой психологии можно применить в проекте.

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

Для справки: представленные далее темы и их описания взяты из колоды карт Mental Notes.


Социальное доказательство


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

Если в приложении нужно, чтобы пользователь выполнил необычное действие или завел новую некомфортную привычку, часто используют социальные доказательства: например, комментарии, оценки, отзывы и т. д.

Возьмем приложение для медитации Petit BamBou: оно в реальном времени показывает, сколько человек медитирует или медитировали за последние неделю, месяц, год и т. д. таким образом нам хотят показать, что медитация доступна каждому, и препятствий для занятий ею быть не должно.


Приложение для медитации Petit BamBou

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


Страницы с ценами в мобильных приложениях The Athletic и MasterClass

У более дорогого варианта часто бывает метка Самый популярный; иногда приводятся отзывы клиентов, призванные убедить купить наконец-то продукт или услугу.


Любопытство


Если человека подразнить интересной информацией, он захочет узнать больше!

Именно это делает фитнес-приложение Strava в своей функции Анализ темпа: вам дают предпросмотр того, как выглядит график, но не более того. Чтобы увидеть подробный анализ, нужно купить подписку Summit.


Анализ темпа в Strava триггер, побуждающий подписаться на премиум-версию

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


Веб-сайт Wall Street Journal

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


Узнать проще, чем вспомнить


Пережитое ранее легче узнать, чем вспомнить.

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

Например, Airbnb дает восемь различных критериев оценки места, где вы останавливались. Это позволяет получить от гостя достаточно количественной информации в случае, если он не даст словесный отзыв. Кроме того, благодаря такому подходу гостям проще вспомнить определенные моменты своего опыта. Если бы Airbnb не предлагал все эти категории, то оценки наверняка были бы менее аккуратными: гости оценивали бы только самые приятные и неприятные впечатления, а про середину забывали бы.


Система оценок Airbnb

Поэтому и страховой стартап Lemonade предлагает несколько предопределенных категорий дорогостоящих предметов.


Последний этап процесса запроса расценок в Lemonade

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


Приятные моменты


Мы вспоминаем и положительно реагируем на небольшие, неожиданные и веселые приятные моменты.

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


Скриншоты приложения Zenly

Внушительный список интерфейсных мелочей и пасхалок, которые могут вызывать приятные эмоции, можно найти на странице Little Big Details. Например, вот одна из моих любимых:


Если включить композицию из плейлистов Звездных войн на Spotify, то панель воспроизведения превратится в световой меч.


Привязка и приспосабливание


Принимая решения, мы чересчур полагаемся или привязываемся к одному аспекту или фрагменту информации.

Например, при покупке ноутбука на сайте Apple.com вам предлагают множество вариантов (200 $ мощнее процессор, 100 $ лучше видеокарта, 400 $ больше объем диска, 299,99 $ предустановленный Final Cut Pro X, 199,99 $ Logic Pro X). Если брать по отдельности, то за всё получится внушительная сумма. Но вы уже сделали мысленный скачок и платите за ноутбук 2799 $, поэтому кажется, что каждая опция не так уж и дорого, верно?



Тот же подход применим, когда вы платите 150 $ за продукты на кассе, и вам предлагают пожертвовать на благотворительность 0,50 $ не такая уж и большая сумма относительно всего чека, верно?


Умеренные трудности


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

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




Эстетика как удобство использования


Эстетичный дизайн часто воспринимается как более удобный в использовании.

Привлекательные элементы воспринимаются нами как более удобные в использовании. Приложение-календарь Sunrise, купленное Microsoft в 2015 г. за более чем 100 млн долл., на тот момент было лучшим в своей категории на платформах iOS и Android: тысячи пользователей хвалили его за понятный и удобный интерфейс.



Но действительно ли возможности Sunrise такие уникальные? В приложении было несколько удобных функций например, интеграция с событиями в Facebook. Но ничего сверхнеобычного там не было в том числе ничего, что календари от Apple или Google не могли бы скопировать за пару недель.

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


Установление ценности


Мы ценим то, что стоит дороже.

Стоимость может выражаться и в деньгах, и во временных затратах.

В отношении денег можно привести множество не самых интуитивных примеров, когда компании повышали конверсию и (или) доход, просто подняв цены. В книге Не сходите с ума на работе Джейсон Фрайд и Дэвид Хайнемайер Хенссон рассказывают, что повышение начальной цены Basecamp с 29 $ до 99 $ в месяц позволило привлечь новых клиентов: иногда чем выше стоимость, тем более полезным кажется продукт.


Страница с ценами Basecamp

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


Боязнь потери


Мы не любим терять или упускать то, что уже имеем (даже если есть возможность получить больше).

Хороший пример этого психологического трюка часто можно увидеть при отмене подписки на некоторые сервисы. Например, если вы решите отменить тарифный план Adobe Creative Cloud, вы увидите следующее:


Процесс отмены подписки на Adobe Creative Cloud

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

Боязнь потери широко используется в продуктах, которые можно попробовать без регистрации, частый случай в мобильных приложениях: например, если не зарегистрироваться в Angry Birds, вы потеряете весь ход игры.



Так же сделано и в Duolingo: если не зарегистрироваться, вы потеряете всю введенную исходную информацию, а также результаты первого пройденного вводного теста.

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


Контраст


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

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



Что нужно пассажиру на этом этапе? Спокойно указать свои данные, при необходимости добавить пару услуг и поскорее перейти на страницу оплаты.

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

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


Регулярные события


Повторяющиеся события вызывают постоянный интерес, формируют ожидание и дают чувство принадлежности.

По этой причине в Headspace внедрили групповую медитацию: каждый день в определенное время все премиум-пользователи Headspace могут объединиться и вместе медитировать. Утверждается, что такая групповая медитация поощряет формирование и соблюдение режима медитации. Но еще это отличный способ обеспечить долгосрочное удержание пользователей и дать им чувство общности.




Последовательность действий


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

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

В этой статье я рассмотрю процесс регистрации в онлайн-банке N26: выделив каждому этапу регистрации отдельный экран, разработчики создают впечатление, что открыть банковский счет проще простого!


Процесс регистрации в N26 в 2018 г.

На веб-сайте они даже дают такую рекламу: Банковский счет в N26 за 8 минут.



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


Ограниченный выбор


Мы с большей вероятностью сделаем выбор, когда вариантов меньше.

В последние годы некоторые компании смогли сформировать свое ценностное предложение на упрощении количества предлагаемых вариантов.

Например, прокат автомобилей Virtuo строит бизнес на том, что предлагает в каждом случае всего несколько автомобилей премиум-класса.


Результаты поиска в приложении Virtuo

Если вам дается ограниченный выбор, вы с большей вероятностью примете решение.

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


Репутация


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

В качестве примеров продуктов, опирающихся на понятие репутации, можно назвать Reddit и StackOverflow: за публикации и комментарии пользователи либо зарабатывают репутацию (получая положительные голоса, значки, трофеи, медали), либо теряют ее (получая отрицательные голоса).



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


Авторитет


Мы предпочитаем следовать примеру и советам признанного авторитета.

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

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

AirHelp понимает эту проблему поэтому они добавляют в процесс запроса элементы, обосновывающие его авторитетность:

  • Они упоминают регламент EC261.
  • Они дают возможность пообщаться с человеком: Джейн ваш помощник в AirHelp.



Первая страница процесса оформления заявки на компенсацию на сайте AirHelp

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


Ограниченный доступ


Мы естественным образом хотим то, что считаем эксклюзивным или принадлежащим избранному обществу.

Думаю, не нужно напоминать о шумихе, которая возникла вокруг Inbox альтернативного приложения электронной почты от Google: когда оно вышло в ограниченный доступ пару лет назад, каждый пытался заполучить приглашение.



Приложение Inbox в итоге кануло в лету: компания Google закрыла его в 2019 г. Сервис предлагал пару новых (в сравнении с Gmail) функций, но ожидаемой революции в электронной почте он не произвел. Тем не менее, продвижение этого продукта на рынке было успешным. Подобный ажиотаж сейчас наблюдаются вокруг Superhuman и Clubhouse.

Еще один пример ограничения доступа сообщество дизайнеров Dribbble.


Главная страница Dribbble

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


Самовыражение


Мы ищем возможность выразить свою личность, свои чувства и мысли.

Это очень мощный принцип, который работает во всех возрастных группах.

Приложения, ориентированные на подростков, почти всегда дают возможность настроить профиль: изменить цвета, аватар, добавить классные аксессуары и т. д. Примеры Pokmon Go, Snap (с Bitmoji) и (совсем недавно) Stadium Live.


Настройка аватара в Stadium Live

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


Настраиваемые рамки для фото в профиле Facebook

Среди SaaS-инструментов также можно найти такие примеры: Trello дает пользователям возможность менять цвет и изображение фона, Slack предлагает множество тем для настройки интерфейса.

Использование принципа самовыражения укрепляет связь между продуктом и пользователями.


Дефицит


Если что-то ограничено в доступности или рекламируется как дефицитное, мы склонны придавать этому более высокую ценность.

Безупречное мастерство в применении этого принципа демонстрирует Booking.com: при просмотре гостиниц на странице поиска нередко можно увидеть несколько визуальных подсказок, указывающих на дефицитное предложение.



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

  • Забронировано 27 раз за последние 6 часов (эта фраза также применяет принцип социального доказательства).
  • Большой спрос: на сайте осталось всего 7 номеров!

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


Юмористический эффект


Поданная с юмором информация запоминается легче и радует пользователя.

Citymapper приложение для навигации по городу, альтернатива Google Картам. Множество своих поклонников сервис заполучил отчасти благодаря юмору и причудливым формулировкам.

Например, при поиске маршрута из пункта А в пункт Б иногда можно использовать функции Телепорт, Катапульта или Реактивный ранец и тогда Борис Джонсон переместится из А в Б менее чем за 5 секунд.


Предложение катапультировать Бориса Джонсона и правда звучит забавно.

Citymapper и платную подписку строит частично на таком юмористическом подходе.


Платная подписка Citymapper Citymapper CLUB

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


Непредсказуемые вознаграждения


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

Один из элементов, благодаря которым Snapchat завоевал пользователей, это трофеи.


Трофеи в Snapchat

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

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

Подробнее о непредсказуемых вознаграждениях и геймификации в этой колоде в целом пишет Mozza: Mobile Gamification How The Best Apps Nailed It (Waze, Duolingo, Tinder, Snapchat, LinkedIn, Zenly).



Надеюсь, вам понравились эти примеры! Может, и вы знаете примеры реализации психологических принципов в дизайне продукта? Расскажите о них!

Если вас заинтересовали Mental Notes и соответствующая карточная колода, то, к сожалению, заказать ее уже нельзя. Но похожую информационную подборку можно найти здесь: плакат Persuasive Patterns Poster от UI Patterns.

Если вам понравилась эта статья и вас интересует применение психологии в дизайне продуктов, я рекомендую зайти на отличную страницу Growth.design The Psychology of Design, где составлен еще более длинный список (101 пункт!) когнитивных искажений и принципов, влияющих на удобство пользования.


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее
Подробнее..

Практика создания единого шаблона проектов на базе Azure DevOps (TFS)

16.04.2021 08:17:32 | Автор: admin

В одной из прошлых статей мы писали, как всей компанией перешли на единый трекер на базе Azure DevOps (TFS). Это позволило нам создать единый свод правил для ведения проектов. Рассказываем, как наш проектный офис разработал логику, по которой сейчас работают все наши команды.

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

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

Целью было сделать так, чтобы в итоге каждый проект можно было прочитать в трекере и однозначно понять его состояние. Причём сделать это может как человек (настраивать сквозные метрики по всем проектам, понимать, где всё хорошо, а где хуже), так и машина (сервис формирования Release Notes понимает, какие задачи с какими статусами и тегами включать в рассылку). И конечно, все вновь запускаемые проекты нужно сразу создавать в тех же правилах.

Этой цели мы сейчас и добились. Когда менеджер отправляет заявку администраторам, чтобы ему завели новый проект, ему не нужно объяснять, что там должно быть: какие настройки и типы задач, к каким системам подключить. Всё необходимое есть в проекте с самого начала, можно сразу заводить спринты, заполнять задачи, готовить план разработки.

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

Дальше про то, по какой логике работает шаблон и какие настройки в него встроены по умолчанию.

Что входит в шаблон проекта True Engineering

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

На вершине пирамиды - Epic. Это бизнес-ценность, которую должна воплощать в себя функция продукта. С точки зрения разработки значимая часть функциональности, которую можно поставить за несколько итераций.

Здесь важным критерием является конечность эпика во времени, то есть достижимость конкретной цели. Хороший пример эпика Автоматизация тестирования на проекте.

Под ними Feature, эти элементы разрабатываются за 1-3 спринта). Одна Feature один бизнес-сценарий. Например, оформление командировок.

Ещё одним уровнем ниже PBI (Product Backlog Item, единица поставки), они представляют собой отдельный кейс в рамках сценария. Подготовка заявки на командировку, согласование поступающих заявок, загрузка чеков для авансового отчёта это PBI. Они разделяются на Task-и, атомарные единицы работы, которая назначается на исполнителя и не занимает больше 8 часов.

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

2. Механика конвейера разработки. Это огромная часть работы любого PM они контролируют, в каком состоянии находится каждая разрабатываемая фича, отслеживают, чтобы в нужный момент команда могла отправить код на тест, и так далее.

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

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

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

3. Поддержка планирования ресурсов и времени. Мы внедрили во всех командах три метрики для контроля трудозатрат:

  • Первоначальная оценка времени на разработку

  • Реально зарепорченное время

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

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

Технические возможности шаблона в Azure DevOps

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

Плагин TFS Aggregator. Этот инструмент подключается к проекту и позволяет автоматические контролировать движение статусов Task-ов и по этим данным отслеживать состояние их родительских PBI. В результате мы можем написать единые правила для трекера заказчика и отправлять ему оповещения о статусах релизов, комментариев к задачам и т.д. Эта функция используется для автоматического сбора Release Notes, уведомления заказчикам о поставках фич, как мы рассказывали в материале про Release Notes.

Интеграция с OLAP-кубом. Эта функциональность отвечает за анализ трудозатрат, статусов задач, контроль Time-to-Market, прочих проектных показателей. Раньше мы использовали куб для контроля показателей внутри проектов. Когда у нас появилась единая система координат, стало возможным делать сквозную аналитику по всем командам сразу мы знаем, что во всех проектах действуют одни и те же измерения с одними и теми же смыслами.

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

Календарь. Этот модуль помогает отслеживать, кто в команде собирается в отпуск, кого в тот или иной период привлекают к работе в параллельной команде и проч.

Куда двигаемся дальше

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

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

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

Подробнее..

Масштабируем продакт-менеджмент как управлять продуктом, который разрабатывают 50 команд

24.02.2021 20:16:16 | Автор: admin
Всем привет!

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

image

Интересующимся и желающим пообщаться на эту тему добро пожаловать под кат.

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

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

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

Знакомая картина?

Так выглядит типичная, и не самая худшая система разработки ПО. Обычно, к такому виду приходят департаменты разработки компаний с успешными продуктами лет через 10-15. Успешные продукты приносят деньги, деньги вкладываются в разработку. Разработка растет как на дрожжах, ее линейно масштабируют и приходят к ситуации, когда проектные менеджеры уже не могут держать в голове все зависимости, множество команд начинают тянуть одеяло на себя, и, порой вредят продукту, нежели развивают его. В такой ситуации вполне нормально, когда одна команда стремится к собственному успеху, уже не переживая, что их коллеги испытывают какие-то проблемы и их общая фича не будет из-за этого доставлена. В порядке вещей разрабатывать тот функционал, который громче всех просят бесконечные стейкхолдеры, а не тот, который нужен пользователям. Не редкость и разработка в стол. Процесс ведь идет требования приходят, реализуются, тестируются, поставляются. За ширмой из суеты и шума легко спрятать главное разработка продукта уже далеко не такая эффективная, как раньше.

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


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

Не похоже на историю выше, верно?

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

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

  • Пользователей кастдевил продакт? Теперь ваши владельцы продукта о них не вспоминают, они носятся от одного стейкхолдера к другому, пытаясь понять за какие требования хвататься в первую очередь;
  • Была ясная и прозрачная юнит-экономика? Теперь владельцы продукта не считают даже PnL, загружая всю команду на пол спринта сторями с сомнительной пользой;
  • Были job story, customer journey map и прочие персоны? Теперь в сторе пишут Как продакт оунер я хочу чтобы это было сделано, потому что это нужно департаменту Operation and Maintanence;
  • Было понимание ответственности за результат и сроки? Теперь каждая команда сама за себя, ваши фичи доставят на релиз-другой позже.

Сложность управления разработкой для масштабных продуктов растет по экспоненте. Что же делать?

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

Списочком

Являются ли они серебряной пулей?

Я пережил несколько бизнес-трансформаций, в которых нанимались золотые коучи, внедрялись самые современные процессы управления и взаимодействия. Тысячи людей меняли свои позиции в одночасье и переходили в новую структуру, новую команду, на новые процессы, в новых проектах.

И могу сказать следующее:

  • это дорого;
  • это не быстро;
  • это очень рискованно;
  • конечный успех сильно зависит от культуры компании. Если люди понимают и верят успех вероятен.

Единственно ли верен подобный подход? Давайте посмотрим, что еще можно сделать.

image

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

Продукт. Продукт должен приносить ценность. Рассмотрите зоопарк ваших систем и компонент с точки зрения ценности. Выделите все потоки ценности (value streams) для конечных клиентов, контрагентов или третьих лиц и разделите карту систем по таким потокам. Каждый владелец продукта должен иметь в управлении полную цепочку систем, имеющих ценность. Дайте ему пару аналитиков, если объем ответственности слишком велик.

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

Пользователи. В сторону стейкхолдеров. Только пользователи могут дать верное представление о ценности продукта. Владелец продукта должен ориентироваться на результаты интервью и анализ тикетов поддержки в своих гипотезах.

Гипотезы. Никаких больше имплементаций функционала в слепую. У каждого эпика или фичи должны быть ожидания по влиянию на метрики. Реализуя фичи и проверяя их А/B тестами, владельцы продукта должны понимать успешна была гипотеза или нет.

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

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

Масштабируем продакт-менеджмент, часть 2 продукт

01.03.2021 16:18:41 | Автор: admin

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

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

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

В разных компаниях по разному организуют разработку таких систем. В одних компаниях можно увидеть команды разработки, которые ответственны за несколько компонент, в других наоборот, одну компоненту может разрабатывать несколько команд. Однако чаще всего на одну систему приходится одна команда разработки. Это классический и наиболее распространенный подход компонентных команд (component teams).

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

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

Чем это грозит?

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

Как же тогда определить, что такое продукт?

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

Ценность понятие субъективное. В процессе взаимодействия с решением у покупателя возникнет некоторое собственное ощущение того, насколько простым, приятным, удобным и полезным это взаимодействие. Именно за это покупатель и платит.

Оплата в свою очередь это самый просто маркер для выделения продукта. То, за что пользователь готов платить, и называется продуктом. В данном случае это некоторый набор из систем, людей и процессов, обеспечивающий поток ценности пользователю (operational value stream).

В таком случае владельцу продукта с методологической точки зрения более правильно было бы реализовать разработку сразу нескольких систем, участвующих в потоке ценности. Такие команды разработки называются продуктовыми или функциональными (feature teams или cross-component teams).

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

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

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

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

И еще раз о том, зачем выделять продукт.

В случае, когда продукт выделен правильно, владелец продукта имеет возможность:

  1. Влиять на все компоненты, составляющие поток ценности;

  2. Видеть реальные метрики продукта, а не косвенные, отраженные в компоненте;

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

  4. В ворохе заявок в поддержку выявлять наиболее критические, а не только те, которые относятся к его компоненте;

  5. Фокусировать усилия команды на наиболее проблемных местах, "расшивая" одно "бутылочное горлышко" за другим.

Спасибо за внимание, в следующей статье поговорим про метрики.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru