Прогрессивные технологии, продукты и услуги, которые делают нашу жизнь лучше, появляются благодаря людям и их решениям. Желание помочь в этом нелегком деле вдохновило нашу компанию на создание системы для исследований Oprosso в 2015 году, а впоследствии, в 2021-м, и Oprosso CEM – платформы для управления клиентским опытом.

Oprosso CEM – результат стараний десятков сотрудников, партнеров и клиентов компании. Однако, главной движущей силой выступает продуктовая команда: она отвечает за продукт, решает, что должно быть и как работать, чтобы бизнес был успешен, а продукт – востребован. Что – это ответы на вопросы «кому мы продаем?», «что мы продаем?», «какую задачу или проблему решаем?», «в чем ценность нашего решения?». Как – детальная проработка продукта, чтобы он делал то, что должен.

В преддверии запуска Oprosso CEM мы поговорили с директором по продукту Вячеславом Степановым о том, как организована его команда,  какие существуют основные этапы и подводные камни разработки.

Расскажи, пожалуйста, о своем пути в продуктовую разработку в Oprosso?

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

Поделись, какие специалисты входят в продуктовую команду Oprosso?

Помимо продуктового менеджера в команде работают UX-дизайнер и аналитик. Я стараюсь нанимать универсальных специалистов, которые умели бы исследовать, проектировать, готовить описание требований для разработчиков, отвечать на их вопросы, учитывать комментарии, а также глубоко знать предметную область. У многих сотрудников моей команды уже есть предыдущий смежный опыт: это либо исследователи, которые ушли в проектирование интерфейсов, либо проектировщики, которые пришли в исследования. Подобный опыт позволяет им успешно проходить цикл разработки продукта от начала до конца – от выявления запроса и потребности до релиза. Так что у нас люди, отобранные штучно, и большая часть команды, это люди с образованием в сфере UX.

Не вредит ли специалисту такая «универсальность»? Считается, что человек, который умеет «все и сразу», обычно не успешен нигде.

Если говорить про удаленные друг от друга области, например, контент-маркетолог/бухгалтер, то в этом случае функциональное объединение в одном специалисте выглядит странно. Но когда области смежные как, например, у full-stack разработчиков, это, наоборот, преимущество, которое делает их более ценными специалистами на рынке. То же самое с UX-дизайнерами и исследователями-аналитиками.

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

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

Как может в дальнейшем развиваться такой специалист?

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

Как ты строишь работу команды над продуктом?

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

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

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

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

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

Следующий этап – тестирование интерактивного прототипа. Чтобы организовать этап максимально эффективно, прежде чем приступить к проектированию прототипа, необходимо подготовить гипотезы относительно функционала, спроектированного на предыдущем этапе, и сценарий тестирования, т.е. задания и вопросы. Это позволит нам сконструировать необходимые для исследования сценарии работы, при этом не делая лишнее. Прототипы на этом шаге могут быть достаточно объемными, многостраничными, высоко интерактивными, наша цель – создать иллюзию, что это рабочий продукт и максимально смоделировать пользовательский опыт. Это довольно объемная задача, в том числе технически. Дальше мы традиционно используем так называемое RITE-тестирование, интерактивное тестирование прототипов. Суть метода заключается в том, что мы делаем первую версию интерактивного прототипа и просим одного-двух пользователей пройти по этому прототипу. В ходе прохождения становятся видны основные проблемы, новые сценарии. Тут же вносим изменения в прототип и зовем на тест следующего респондента. Цикл повторяется: каждый следующий респондент работает с несколько иной версией прототипа, чем предыдущий. И так до тех пор, пока не дойдем до ситуации, в которой респондент достаточно чисто прошел по всем сценариям, которые мы закладывали в тестирование, и выполнил все задачи. 

Когда мы все спроектировали, протестировали и уже в достаточной степени уверены в том решении, которое подготовили, наступает этап подготовки описания функциональных требований для разработчиков. Тут могут быть следующие подводные камни: мы описываем функциональные состояния системы, исходя из пользовательского сценария, а разработчики и команда тестирования смотрят на это под другим углом. Они думают: как это будет работать, если мы попытаемся это сломать? А если мы введем данные бесконечной длины? А если в этом поле будет отрицательное значение? Таких «а если» очень много. Мы стараемся их учитывать и описывать, но что-то можем упустить. Поэтому перед тем, как отдать задачу в разработку, продуктовая команда представляет её разработчикам и тестировщикам, отвечает на вопросы, иногда что-то уточняет и корректирует по собранной обратной связи.

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

Как плотно строится взаимодействие с командой разработки?

В принципе, консультация с командой разработки пронизывает большую часть этапов создания продукта или фичи. Первую консультацию мы делаем после сбора бизнес-требований. На ней мы определяемся с тем, что должен делать функционал, коротко описываем, что в нем будет и спрашиваем разработку, есть ли какие-то узкие места, где мы могли бы упростить им работу. Вторая консультация – после подготовки макетов. Мы показываем их и просим дать обратную связь. И самое детальное обсуждение происходит в момент передачи функциональных требований. Разработка изучает документ, задает вопросы и/или дает предложения, как можно упростить, сократить работу. Так или иначе, но в ходе постоянной коммуникации с отделом разработки в нас самих уже развивается «внутренний голос разработчика», который задает эти вопросы.

Было ли такое, что на одном из этапов вы понимали, что идете не в ту сторону, и нужно все переделать?

Постоянно, и это нормальная жизнь продуктовой команды, особенно на ранних этапах. Приведу пример из периода, когда мы только делали функционал Oprosso СЕМ. В одном из релизов мы планируем выпустить панель мониторинга – единый дашборд, на котором сводятся результаты разных исследований. Исходя из этого, появились опасения, что если все проводимые в рамках компании исследования не будут шаблонизированы, то, когда исследователи попытаются свести данные по одной точке контакта, они обнаружат, что у всех подразделений разные шкалы подсчета результатов: одни создали вопрос с единичным выбором, другие со множественным. У одних 5 вариантов ответа, у других 6. А это, естественно, нивелирует пользу единой панели мониторинга показателей. Мы понимали, что в такой ситуации клиенты так или иначе пришли бы к нам и попросили свести все данные в одну шкалу.

Чтобы избежать такой ситуации, мы сразу хотели зашить функционал шаблонов, который позволял бы унифицировать все шкалы, формулировки, варианты ответов, ключевые настройки вопросов и запрещал вносить в них изменения. Мы спроектировали такое решение, пошли к пользователям, и… они не поняли наше решение. Как только мы это ни называли: методика исследования, шаблон вопросов, шаблон методик. Однако, клиенты ожидали привычного, прямого порядка – я создаю вопросы, вот моя анкета, все работает. А у нас выходило, что ты создаешь шаблон методики, потом саму методику, в которую переносим вопросы из шаблонов. Мы пробовали много вариантов, переделывали интерфейс так и эдак, вставили экран-обучалку, которая объясняла, что это такое и зачем нужно. В итоге от обязательного использования шаблонов отказались.   

Откуда берутся идеи для разработки продукта?

По-разному, например, в каких-то компаниях основатель может сказать: «А давайте сделаем вот так». В каких-то, и по моему мнению это наилучший вариант, идеи исходят из запросов рынка: клиенты говорят прямо, что им нужно или приходит несколько клиентов со схожими запросами. И тут важная деталь: в этих запросах нужно увидеть контур будущего продукта. Наша компания в принципе так и развивается – делает продукт на основании запросов клиентов, собирает обратную связь: что самое важное, чего явно не хватает для решения задач. Я всегда на встречах задаю вопрос: «Решает ли продукт, который мы показали, ваши задачи? Есть что-то, чего не хватает? Чего?» И слушаю, что говорят. Это ложится в основу бэклога.

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

Что для тебя значит заниматься разработкой продукта?

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