Проектирование без CustDev’а. На примере развития корпоративного ПО для выездного обслуживания
Не секрет, что во время разработки программного обеспечения в b2b очень сложно найти пользователей, чтобы провести CustDev и проверить жизнеспособность гипотез и идей, которые родились во время исследования у продуктового дизайнера.
Но развивать продукт нужно, и поэтому приходится находить методы, которые все-таки позволят оценивать востребованность новых фичей корпоративными пользователями.
В b2b не покастдевить соседа
Меня зовут Армине, я продуктовый дизайнер в компании HubEx. Когда пришла в компанию после b2c, пришлось перестраиваться, потому что в разработке программного обеспечения для бизнеса уровень сложности выше (сложная мотивация + длинный цикл принятия решения о покупке), а доступ к клиенту для проведения исследований практически никакой.
Поясню на своем примере. HubEx — платформенное решение для управления выездным обслуживанием, у нас есть больше 40 преднастроенных отраслевых решений. То есть продукт подходит и клининговым компаниям, и тем, кто обслуживает постаматы, и даже сервисным подразделениям промышленных холдингов. Понятно, что одни отрасли используют одну часть функций, другие — другую. Поэтому, когда речь заходит о кастдеве, желающих потратить время на фичу, польза которой для них не всегда очевидна, найти крайне проблематично. Ну и сила привычки в корпоративном сегменте — вечная боль как для разработчиков бизнес-приложений, так и для самих компаний, которым тяжело даются изменения.
А учитывая целевую аудиторию продукта — технические и генеральные директора, главные инженеры и руководители отделов сервиса — им совсем не до развития платформы и исследований.
Тем не менее, развитие продукта — непрерывный процесс, и нам нужно опираться на потребности нашей аудитории. Рассказываю, как мы их выявляем.
Наши способы Customer Development
Собственная база пользователей. Так как у нашей целевой аудитории, как правило, нет времени, то время от времени мы исследуем пользователей платформы. Стоит сказать, что в b2b, как правило, покупают ПО одни, а пользуются — другие. В случае с HubEx покупают платформу топ-менеджеры, а большинство пользователей — диспетчеры, сервисные инженеры и другие выездные специалисты. Их мы кастдевим, но результаты таких исследований не всегда применяем.
Объясню на примере. В системе есть карта, на которой можно видеть местоположение каждого выездного сотрудника в режиме реального времени. Она нужна, чтобы контролировать кто, где и когда находился, в какое время назначенный на заявку мастер выезжал на объект и выезжал ли. Когда мы проектировали возможность создания заявок на обслуживание прямо с такой карты, а не из меню «Заявки», большинство пользователей отнеслись к идее прохладно. Однако в результате оказалось, что это одна из наиболее популярных функций.
«Если бы я спросил у людей, что им нужно, они бы попросили более быструю лошадь», — поговаривал Генри Форд. Так и в нашем случае — мало кто может сформулировать и описать свои потребности, и периодически нам приходится наносить пользу принудительно =)
В случаях исследования своих пользователей, перед проектированием очередной пользовательской функции, мы приоритезируем идеи и гипотезы по ICE Scoring. Да, методологию часто ругают за субъективность, но учитывая специфику b2b, описанную выше, и скромный объем исследований, не вижу в этом катастрофы.
Наш скоринг выглядит так:
кол-во текущих клиентов, которые ожидают фичу
кол-во «горячих» потенциальных клиентов, которые ждут фичу
кол-во лидов, интересовавшихся фичей
кол-во проваленных сделок из-за отсутствия фичи
кол-во запросов на фичу от текущих пользователей через техподдержку и команду внедрения
кол-во жалоб, связанных с отсутствием фичи
наличие фичи у западных конкурентов
наличие фичи у российских конкурентов
влияние фичи на быстродействие, отказоустойчивость
сложность внедрения фичи по 4-бальной шкале
Маркетинговые агентства и аутсорсеры. Ввиду разнообразия масштабов и разношерстности сферы выездного обслуживания, отдать исследование на откуп сторонним исполнителям с непрозрачными методами исследования мы не решились.
Платформа Яндекс.Взгляд. На постоянной основе это недешево, тоже отказались.
Социальные сети. Про них стоит сказать отдельно. Это очевидный и массовый канал, который мы пока не пробовали. До недавнего времени у компании не было социальных сетей и сформированной в них аудитории. Сейчас они появились, надеюсь, через несколько месяцев мы обязательно воспользуемся аудиторией своих каналов.
Как проектировать без кастдева
Несмотря на customer development своих пользователей, в основном мы обходимся собственными силами.
Покажу механику проектирования фичи на примере разработки «Расписания заявок». Это своего рода месячный календарь, где диспетчер распределяет заявки по исполнителям.
ЭТАП 1. Как продуктовый дизайнер я получаю от владельца продукта User Story с общим описанием того, какой результат и какую ценность должен получить тот или иной пользователь. В моем случае вводные были следующими:
Как руководитель компании, я хочу увидеть, сколько запланировано заявок на день, на неделю, на месяц, с целью понимания загруженности персонала и необходимого штата сотрудников.
Как диспетчер сервисной службы, я хочу понимать загруженность сотрудника в расписании, с целью планирования обслуживания клиентов.
Как диспетчер сервисной службы, я хочу видеть количество плановых, срочных, назначенных и не назначенных заявок, с целью равномерного распределения работ.
ЭТАП 2. Для понимания, в какую сторону двигаться и какой функционал проектировать, я пишу Job Story, которая мне помогает видеть:
В нашем случае месячный календарь в системе выглядел как еженедельный, который приходилось «листать» или кликать между вкладками, чтобы увидеть картину в целом. Отсутствовала возможность быстро корректировать разные виды и типы заявок.
В нашем случае — понимание загруженности каждого сотрудника в отдельности и компании в целом, возможность ускорить назначение и распределение заявок в целях соблюдения SLA с клиентами.
В нашем случае — равномерное распределение заявок, сокращение объема переработок персонала, оптимальная комплектация штата сотрудников.
Сразу покажу «было — стало» и вернусь к последовательности действий, которая к таком результату привела.
Так выглядел месячный календарь с расписанием заявок до изменений:
Так выглядел месячный календарь с расписанием заявок
Так он стал выглядеть после:
ЭТАП 3. Далее делаю mindmap — это помогает подытожить исследование и собрать мои мысли, идеи и гипотезы на едином борде. Использую Miro.
Так выглядела карта в моем примере (оригинал здесь):
ЭТАП 4. Mindmap презентую команде, и во время обсуждения решаем, какой функционал разработать в MVP, а что оставить на потом, чтобы сохранить бюджет, если идея не пройдет валидацию.
ЭТАП 5. Прорисовка интерфейса. Здесь не буду подробно останавливаться. Отмечу только, что если есть дизайн-система, то можно не прототипировать. Но если вы работаете над новым продуктом, то прототип сэкономит ваше драгоценное время.
ЭТАП 6. После отрисовки интерфейса начинается самое интересное. Нужно проверить:
Например, сначала я не рисовала временную шкалу. Пользователь, открывая интерфейс, не понимал текущее время. Это, по сути, когнитивная нагрузка для пользователя, и добавив обычную шкалу мы улучшили UX.
С командой мы проводим общую оценку Userflow (порядка действий, которые выполняет пользователь для решения задачи). Я делаю это на презентации статичных дизайн-макетов или на кликабельном прототипе.
ЭТАП 7. Наконец, я отдаю дизайн тестировщикам, а владелец продукта проводит параллельный груминг интерфейса с командой разработки. Получается, своего рода, коридорное исследование.
Так, команда тестирования знакомится с интерфейсом уже на этапе разработки дизайна и дает мне раннюю обратную связь, а команда разработки лучше понимает бизнес-задачи выездного обслуживания в связке с текущей архитектурой и возможными рисками для развития платформы.
Ура! Можно отдышаться =)
Надеюсь, получилось на своем примере с HubEx показать, как кастдевить в b2b, если нет возможности проводить полноценный Customer Development.
