Войти в систему
Войти с помощью соц. сетей:
Если предназначение качественного тестирования заключается в быстром обучении и составлении новой аналитической картины, то количественные методики — это инструменты для сбора подтверждений ценности ваших идей.
Иногда необходимо собрать достаточно данных для получения статистически достоверных результатов — особенно для потребительских сервисов с большим ежедневным трафиком, — а иногда планка устанавливается ниже. Мы просто собираем фактические данные об использовании продукта, которые считаем полезными подтверждениями его ценности, способными, помимо всего прочего, помочь нам принять обоснованное решение насчет наших дальнейших действий. Это и есть основное предназначение прототипа на реальных данных, который мы обсуждали раньше. Напомним, что такой прототип входит в число создаваемых на этапе исследования продукта для того, чтобы предложить ограниченной группе пользователей определенные сценарии его применения и в итоге собрать некоторые фактические данные об этом.
Существует несколько основных способов сбора таких сведений. Выбор методики зависит от объема вашего трафика, времени и отношения к риску.
У стартапов трафик обычно невелик, да и времени маловато, зато они смело идут на риск — ведь им еще нечего терять. В устоявшейся компании трафика более чем достаточно, и она располагает временем. Причиной для беспокойства обычно бывает то, что у менеджмента может лопнуть терпение. И, как правило, такие компании не склонны рисковать.
Золотым стандартом этого типа тестирования считается A/B-тест. Мы очень любим эти тесты, потому что пользователь не знает, какую версию продукта он видит, и мы получаем данные, весьма надежные с точки зрения точности прогнозирования, к чему мы, собственно, и стремимся.
Имейте в виду: речь идет о немного ином типе A/B-тестов, чем A/B-тесты с целью оптимизации. Во втором случае мы экспериментируем с разными призывами к действию, цветовыми решениями кнопок и тому подобными вещами. Концептуально эти типы тестирования одинаковы, но на практике между ними есть важные различия. В частности, A/B-тесты с целью оптимизации обычно предполагают поверхностные изменения с низким уровнем риска; часто это тесты в рамках сплит-теста (50:50).
В ходе A/B-тестирования на этапе исследования мы демонстрируем продукт 99 процентам пользователей, а прототип на реальных данных — только одному проценту, а то и меньше. И гораздо внимательнее отслеживаем результаты.
Если ваша компания не готова идти на риск или вам не хватает трафика, чтобы продемонстрировать версию продукта одному или даже 10 процентам пользователей и быстро получить значимые результаты, примените такой эффективный метод сбора доказательств, как тест только по приглашению. В этом случае вы определяете группу пользователей или клиентов, с которыми связываетесь и приглашаете испытать новую версию продукта. Вы говорите им, что это экспериментальная версия и, решив запустить ее на своем оборудовании, они дают согласие на участие в тестировании. Получаемые от этой группы данные не так информативны и полезны для прогнозирования, как полученные в результате реального «слепого» А/Б-тестирования. Очевидно, что чаще всего использовать «сырой» продукт соглашаются так называемые ранние последователи — люди, склонные ко всему новому и непривычному. Тем не менее мы получаем группу реальных людей, которые выполняют свою работу с использованием нашего прототипа на реальных данных, и данные, собранные таким образом, действительно очень важны и интересны.
Я даже не могу сосчитать, как часто мы полагаем, будто у нас есть то, что пользователи непременно полюбят, а после того как делаем это доступным для узкой группы людей, обнаруживаем, что их это ничуть не интересует. К сожалению, после проведения количественного теста данного типа мы точно узнаем только одно: что люди упорно этим не пользуются; и ни малейших подсказок и намеков на то, чем объясняется такая ситуация. Поэтому после такого теста проводится тот или иной качественный тест, позволяющий еще раз протестировать идею и максимально быстро узнать, почему пользователи увлечены ею не так сильно, как мы надеялись.
В одном из вариантов теста только по приглашению к тестированию привлекают участников программы по выявлению новых потребителей, которую мы обсуждали выше, в разделе, посвященном методикам для выработки идей. Эти компании уже принимают участие в тестировании ваших новых версий, и у вас налажены с ними тесные взаимоотношения, благодаря чему можно без труда продолжить с ними сотрудничество.
Обычно я применяю такой подход как основную методику для сбора фактических данных об использовании продуктов для корпоративных клиентов. Участники нашей программы по выявлению новых потребителей часто получают обновления прототипа на реальных данных, и мы сравниваем их данные об использовании с данными более широкого пула клиентов.
Роль аналитики
Одно из самых значительных изменений в нашем сегодняшнем подходе к созданию нового продукта связано с использованием аналитических данных. В наши дни от каждого хорошего продакта ожидают умения работать с такими данными и использовать аналитику для быстрого обучения, приобретения нужных знаний и повышения профессионального уровня.
Я объясняю это изменение несколькими факторами. Во-первых, тем, что благодаря глобальному доступу — и появлению сетевых устройств — рынок наших продуктов в последние годы резко расширился, а объем данных многократно увеличился и несравненно быстрее обеспечивает нас интересными и статистически значимыми результатами.
Во-вторых, тем, что инструменты для получения доступа к этим данным и приобретения благодаря им ценных знаний за последние годы значительно усовершенствовались. Но главную причину я вижу в осознании той роли, которую обычно играют эти данные, помогая вам быстро учиться и адаптироваться к изменениям.
В сильных продуктовых командах мы видим пять основных областей применения аналитических данных. Предлагаю детально рассмотреть каждую из них.
Понимание поведения пользователей и потребителей
Большинство людей, думая об аналитике, имеют в виду именно данные о пользователях продуктов, притом что это только один тип аналитики. Эти данные изучаются для того, чтобы понять, каким образом пользователи и клиенты используют наши продукты (помните: на одного потребителя приходится много пользователей, по крайней мере в контексте «бизнес для бизнеса»). Мы делаем это для выявления функций, которые ими не используются; для подтверждения того, что функции применяются так, как мы того ожидали; или просто для того, чтобы лучше понять, насколько велика пропасть между тем, что люди говорят и что делают.
Успешные продуктовые команды собирают и используют такие аналитические данные с этой целью уже не менее тридцати лет. За доброе десятилетие до появления интернета персональные компьютеры и серверы с помощью превентивного контроля состояния устройств собирали поведенческую аналитику, которая затем изучалась продуктовыми командами для доработки и усовершенствования продукта. По-моему, это одно из очень немногих требований к продукту, которое не стоит даже обсуждать. Я убежден: если вы собираетесь добавить новую фичу, вам необходимо включить как минимум базовый механизм сбора аналитики по ее использованию. А иначе как вы узнаете, работает ли она так, как вам требуется?
Оценка прогресса продукта
Уже много лет я пылкий сторонник использования данных для управления продуктовыми командами. Вместо того чтобы выдавать команде устаревшие дорожные карты» с составленными кем-то списками догадок относительно того, какие фичи могут (или не могут) сработать, я предпочитаю предложить ей набор бизнес-целей с измеримыми конечными результатами, после чего команда сама принимает решение, какими способами лучше всего этих целей достигать. Это один из аспектов всеобъемлющей тенденции, наблюдающейся сегодня в сфере разработки новых продуктов — сосредоточиваться на результате, а не на процессе.
Подтверждение перспективности идей относительно продукта
Сегодня мы — особенно в компаниях по выпуску потребительских товаров, — проводя A/B-тесты, а затем сравнивая полученные результаты, имеем отличную возможность вычленить вклад новых фич, новых версий рабочих процессов и новых проектных решений. Это позволяет получать наглядные подтверждения того, какие из наших идей работают, а какие нет. Нам не нужно делать это со всеми своими предложениями, но для исследования продуктов, сопряженных с серьезным риском или высокими затратами на развертывание, или тех, что требуют изменений поведения пользователей, этот инструмент может быть чрезвычайно действенным и полезным. Даже если сбор статистически значимых результатов существенно затруднен из-за объема трафика или занимает очень много времени, мы имеем возможность собирать фактическую аналитику с помощью прототипов на реальных данных и принимать в итоге более информированные решения.
Сбор информации для принятия решений о продукте
По моему многолетнему опыту, самым скверным в решениях о продуктах в прошлом было то, что они обычно опирались на чьи-то мнения. И как правило, чем более высокую должность занимал в организации этот человек, тем больше с ним считались.
Сегодня, когда мы руководствуемся правилом «данные важнее мнений», у нас есть возможность провести тест и использовать собранные данные для принятия более обоснованных решений. Конечно, аналитика — это еще не все, и мы не должны становиться ее рабами, но в лучших продуктовых командах я вижу бесчисленные примеры удачных решений, в основу которых легли именно результаты тестов. И я постоянно слышу от людей, как часто аналитические данные становятся для них сюрпризом и как сильно меняют их точку зрения.
Вдохновение от работы над продуктом
Я давно укрепился в намерении использовать аналитические данные во всех перечисленных случаях, но, должен признать, мой фаворит — этот последний пункт. Совокупные данные, собранные из всех доступных источников, могут стать для нас настоящей «золотой жилой». Тут часто все сводится к умению задавать правильные вопросы, но впоследствии, изучая эти данные, мы можем выявить некоторые очень большие возможности в плане создания новых продуктов. Лучшие проекты, которые разрабатываются прямо сейчас, были вдохновлены именно аналитикой. Конечно, мы часто получаем отличные идеи, наблюдая за потребителями и применяя новые технологии, но анализ и изучение данных нередко становятся озарением и мощным толчком, дающим старт поистине революционным идеям. Во многом так происходит потому, что аналитика частенько застает нас врасплох, становится сюрпризом. У нас имеется ряд предположений о том, как используется наш продукт, причем о большинстве вариантов мы даже не подозреваем, и, увидев данные, очень удивляемся тому, насколько сильно действительность не соответствует нашим ожиданиям. И такие сюрпризы нередко становятся толчком к реальному прогрессу.
Менеджер по высокотехнологичным продуктам обязан разбираться в разных видах данных для тех продуктов, с которыми он работает. Многие коллеги, надо признать, подходят к этой задаче слишком узко. Вот базовый набор аналитики для работы с большинством высокотехнологичных продуктов.
Надеюсь, теперь вы видите, какую огромную роль играет аналитика в успехе продуктовых команд. Однако, как бы ни были важны и полезны эти данные, важно помнить, что они проливают свет на происходящее, но не объясняют причин. Для интерпретации количественных результатов нам необходимы качественные методики.
(Обратите внимание: аналитические данные часто используются для отслеживания ключевых показателей эффективности [key performance indicators, KPI]).
Работа вслепую
Как ни удивительно, я и сегодня сталкиваюсь с продуктовыми командами, которые либо не используют свой продукт для сбора аналитических данных, либо так мало занимаются этим, что все равно не знают, использовался ли их продукт, и если да, то как.
Мои команды — и каждая команда, которую я могу вспомнить из тех, с какими когда-либо работал, — делают это так давно, что нам даже трудно представить, как можно работать без этой ценной информации. Я даже не могу вспомнить, каково это — не иметь ни малейшего представления о том, как использовался тот или иной продукт, какие фичи помогают пользователю решить его проблемы и те ли это фичи, которые, на наш взгляд, необходимо предложить, чтобы продукт охотно покупали.
Проще всего это делать с помощью «облачных» продуктов и сервисов, и большинство из нас используют веб-аналитику, но иногда мы выбираем для этого собственные инструменты.
Как я уже говорил, хорошие продуктовые команды занимаются сбором аналитики о своих продуктах не один год. И не только с помощью «облачных» сайтов, но и с использованием установленных мобильных приложений или приложений для ПК — локального софта, оборудования и устройств, которые периодически проводят проверку и отправляют командам данные о фактическом использовании их продуктов. Нужно сказать, очень немногие компании сегодня настолько консервативны, чтобы запрашивать разрешение перед отправкой этих данных; в основном все проходит, так сказать, без лишних слов.
Безусловно, надо анонимизировать данные и агрегировать их так, чтобы в них не было никаких сведений, по которым можно установить личность их автора. И все же время от времени в новостях рассказывают о компаниях, которые нажили большие проблемы из-за того, что в своем стремлении выйти на рынок рассылали «сырые» данные. Создается впечатление, что, по мнению журналистов, мы отслеживаем их ради корыстных, гнусных целей, но все компании, с которыми я знаком, просто стараются выпускать лучшие продукты — более ценные, удобные и полезные для людей. А сбор аналитических данных уже давно стал в этом одним из важнейших инструментов.
В общем все происходит так: сначала мы задаем себе вопрос, что нам нужно знать об использовании наших продуктов, затем дополняем продукт возможностями для сбора этой информации (выбор методик зависит от используемого инструмента и от того, какие данные нам нужны). И в конце генерируем онлайн-отчеты в различных формах для анализа собранных данных и их интерпретации.
Мы стремимся располагать инструментами для оценки всего нового, что добавляется в продукт, чтобы незамедлительно узнавать, работает ли он так, как мы ожидаем, и не возникло ли не предусмотренных нами последствий. Честно говоря, без этого инструментария я не стал бы выводить на рынок ни одну новую фичу. Откуда нам знать, как она в действительности работает?
Большинство успешных менеджеров продукта первым делом утром проверяют аналитику, чтобы узнать, что произошло за предыдущую ночь. Они постоянно проводят тестирование в той или иной форме, и им, разумеется, очень интересно, что эти тесты показывают.
Конечно, существуют экстремальные среды, где все происходящее защищено надежнейшими брандмауэрами, но даже в этом случае продакты могут генерировать периодические отчеты об их использовании; эти отчеты анализируются и после получения разрешения направляются продуктовым командам (при необходимости в виде электронных или печатных документов).
Я большой энтузиаст радикального упрощения продуктов путем удаления из них всех функций и опций, которые не способны нести даже свой вес. Но если не знаешь, что и как используется, это становится весьма мучительным, ведь неизвестно, что происходит на самом деле. В этом случае у нас нет данных, которые подтверждали бы наши теории или решения, и наш менеджмент (с полным на то правом) артачится, не желая их принимать.
На мой взгляд, вам стоит начать с признания того, что наличие аналитических данных о продукте обязательно, и стартовать отсюда в обратном направлении, чтобы найти лучший способ их получения.
Войти с помощью соц. сетей: