Как провести демо, после которого бизнес-заказчик останется доволен
Привет, Хабр! Меня зовут Маргарита, я аналитик в департаменте e-commerce КОРУС Консалтинг. Я провела множество демонстраций разработанной функциональности на разных проектах, а также присутствовала на них как слушатель и специально наблюдала за реакциями участников со стороны. В этой статье я поделюсь опытом о том, как эффективно провести демо для бизнес-заказчиков на примере нового раздела «Обращения» на b2b-портале. Многие приемы применимы и к другим форматам — обучению пользователей, пресейлам и т.д.
В конце статьи я сформулировала 9 советов, которые помогут повысить эффективность демо для бизнес-заказчика.
Этап 1. Подготовка к проведению демонстрации
Демо проводится в конце этапа разработки (спринта, MVP, блока задач) как этап сдачи функциональности заказчику. Я рассматриваю его не как простую формальность, а как публичное выступление с определенными целями:
Продемонстрировать выполненную командой работу так, чтобы задачи быстрее перешли на следующий этап (были приняты бизнесом к тестированию, получили согласование релиза на прод и т.д.)
Рассказать об изменениях в продукте так, чтобы бизнес точно понимал их.
Получить обратную связь и вместе сформулировать идеи по развитию, которые пополнят бэклог.
Поддержать и развить партнерство с заказчиком.
Достижение этих целей требует выделения достаточного времени на подготовку, которая состоит из следующих шагов.
Определяю аудиторию
Перед любым выступлением краткий анализ аудитории помогает определить, на каких моментах нужно сделать акцент, а какие затрагивать нет смысла. Так можно эффективнее распределить время, уменьшить число вопросов, а главное — удерживать внимание слушателей. Так, например, на демо для руководителей бизнес-подразделений я сделаю упор на пользе для компании и конечного пользователя, а не на деталях технической реализации.
Я узнаю, кто будет приглашен, и формулирую:
Какова роль каждого из слушателей? Какие у них цели?
Насколько они погружены в продукт (проект)?
Какие термины привыкли использовать?
Иногда на этом этапе происходит обратное — содержание выполненных задач приводит к пересмотру состава участников со стороны бизнеса.
На последнее демо моей команды по новому разделу «Обращения» на b2b-портале были приглашены текущие и новые участники проекта из разных подразделений. Все они — представители бизнес-направлений, которые погружены во множество задач и потоков информации помимо развития нашего сайта. ИТ-терминология для них специфична и не всегда понятна. Иногда они используют разные термины для одних и тех же объектов. И моя задача — сделать демо понятным для каждого слушателя.
Готовлю общую информацию о системе
Если на демо будут слушатели, которые увидят систему впервые, я уделяю несколько минут общей информации о навигации и ключевых функциях, даже если они не связаны с демонстрирующими задачами напрямую. Такая вводная поможет слушателям сосредоточиться на основной части демо и меньше отвлекаться на изучение меню или других элементов.
Так, для демо по обращениям на b2b-портале я выделила следующие вопросы:
Какие имеются навигационные элементы? Где найти основные разделы?
Какие имеются роли пользователей? В чем их ключевые отличия?
Как получить доступ и авторизоваться в системе?
Определяю список сценариев, которые важны для бизнеса
Я рассматриваю демо как имитацию работы будущего пользователя в системе. Как правило, бизнес-заказчика интересуют основные сценарии, по которым будет работать пользователь. В моем примере это создание обращения и просмотр информации о нем в каждом из статусов.
Если времени достаточно, я дополняю их альтернативными сценариями. Например, сохранение данных в Local storage, чтобы продолжить заполнение, если вкладка браузера была закрыта до отправки формы. Еще это может быть обработка ожидаемых ошибок, вызываемых пользовательскими действиями.
А вот от негативных сценариев, связанных с обработкой технических ошибок, я в большинстве случаев отказываюсь. Они вызывают много вопросов, ведь бизнес ожидает, что система будет работать без сбоев. Хотя все зависит от задачи, и иногда эти сценарии могут быть не менее важны.
Также на демо для бизнеса я опускаю технические аспекты реализации, если они не отражаются на работе пользователей. В моем примере это особенности реализации интеграции с S3 для хранения прикрепленных к обращениям файлов — передача файлов во временный бакет, инициация запроса на их перенос в постоянный и т.д.
Хочу отметить, что такие вопросы могут включаться в план демо, если на нем будут присутствовать ИТ-специалисты со стороны заказчика (актуально для подрядчиков).
Учитываю интеграции со смежными системами
Если в задаче участвует интеграция со смежной внутренней системой, я стараюсь организовать демо сквозного бизнес-процесса от его начала и до завершения. В зависимости от состава участников и их погруженности в продукты, действия в смежной системе может выполнять команда разработки или сам заказчик. Важно договориться о зонах ответственности заранее, чтобы все были готовы.
Этот подход может не подойти для сложных бизнес-процессов, затрагивающих множество сервисов. Но он выглядит более понятным для бизнеса и может быть реализован, если в процессе задействовано 2–3 системы.
В моем примере мы подготовили демо вместе с командой CRM. Мы показали весь бизнес-процесс обработки обращения: его создание клиентом на b2b-портале, действия менеджеров в CRM и отображение каждого из них для клиента.
Прописываю шаги и важные акценты
Детализация может казаться излишней, но она упрощает формирование структурного рассказа, в котором не будут упущены важные для слушателей акценты. Можно заранее сформулировать ценность для бизнеса или пользователя, которую несут функции, проверки и подсказки, встречающиеся в сценариях. Сделать это помогает проведенный ранее анализ аудитории.
Обсудите расстановку акцентов с аналитиком, который собирал требования к задаче. Он поможет учесть то, что было особенно важным для заказчика. В моем примере при обсуждении обращений заказчик несколько раз говорил о своей боли: из-за отсутствия раздела на b2b-портале клиенты отправляют обращения на почту, но забывают указать данные заказа. Без них рассмотреть обращение невозможно, поэтому менеджеры должны позвонить клиенту и уточнить их. На демо я уделила особое внимание этому блоку полей на форме и особенностям его заполнения.
Приведу начало сценария создания обращения на b2b-портале:
Перейти к форме создания обращения, проговорить значение по умолчанию в поле «Тема» и соответствующие ему блоки полей.
Изменить значение в поле «Тема», проговорить изменение следующих полей.
Проговорить логику формирования списка заказов (только отгруженные за последние 3 месяца) и работы поиска (по полям A, B, C) в поле «Номер заказа», заполнить поле.
Далее в этом сценарии описаны все шаги заполнения формы, отправка обращения, изменения на стороне CRM в ходе его обработки и отображение этих изменений на b2b-портале.
Уделяю внимание администрированию системы
Для упрощения дальнейшей коммуникации я проговариваю, какие изменения можно проводить без участия разработчиков: указывать настройки, редактировать справочники, загружать новости и т.д. Если у участников демо есть нужные права, я показываю им, как это сделать. В противном случае я проговариваю, к кому они могут обратиться.
Готовлю данные, которые не будут сбивать слушателей
По моим наблюдениям, на демо важно показывать данные, приближенные к реальным. Заказчик часто воспринимает данные (содержимое базы данных и других хранилищ) и логику их обработки (работающий код) как единую систему. А абстрактные данные (тест 1, 1234567890, abcde), неактуальные данные (закрытые склады, снятые с производства товары), некорректные тестовые данные (сумма заказа 200 руб. при первоначальной стоимости 100 000 руб. и скидкой 50%) перетягивают внимание на себя. Они заставляют слушателей представлять корректные данные на нужных местах и отвлекают от демо, побуждают задавать вопросы об этих несоответствиях.
Также важно согласовать данные с командой, чтобы в них не вносились изменения.
Для демо раздела «Обращения» я выбрала компанию с подходящими заказами и удалила обращения темами вида «Тест 1». Также я заранее подготовила содержание обращения, чтобы быстро скопировать его, когда потребуется.
Предварительно прохожу по сценариям
При подготовке я прохожу по составленным сценариям на той среде разработки, на которой буду проводить демо. Так можно заметить проблемы, если некоторые части кода не были доставлены или были удалены при решении конфликтов.
Я как аналитик использую этот шаг не только для подготовки к демо, но и как возможность стать пользователем собственной системы и оценить ее удобство. Это влияет на мои решения при выполнении следующих задач. А иногда так возникают идеи для наполнения бэклога, которые не были очевидны при проектировании.
Этап 2. Проведение демонстрации
Вначале я называю задачи, которые буду демонстрировать, и их ценность для бизнеса и пользователя, а затем перехожу к подготовленному плану.
Прохожу по сценариям
Я провожу демо по памяти, но имею под рукой написанные сценарии. Хорошая подготовка позволяет чувствовать себя уверенно, что сразу слышно в речи и влияет на восприятие информации, которую я передаю.
Я стараюсь озвучивать выполняемые шаги по структуре: действие пользователя — отклик системы. Например:
Для перехода к форме я нажимаю «Создать обращение». Отобразилась сокращенная форма, по умолчанию поле «Тема» заполнено значением Х.
Если я выбираю вариант Y в поле «Тема», форма изменяется. В конце появляются дополнительные поля А, B и C, а также подсказка D.
В поле «Номер заказа» доступен список заказов моей компании, отгруженные в течение последних 3 месяцев. Это ограничение ускоряет загрузку страницы. Если я хочу отправить обращение по более раннему заказу, необходимо… и т.д.
За счет того, что я проговариваю не только свои действия, но и отклик системы, а также ценность функции, длительность комментариев к каждому шагу увеличивается. У слушателей появляется больше времени для изучения интерфейса и подготовки комментариев, а у экрана — для загрузки при разной скорости интернета. При этом в речи не возникает пауз, она воспринимается естественно.
Использую термины, понятные для аудитории
По моим наблюдениям, важно следить за использованием терминов и давать их определения, когда без них не обойтись. Я всегда стараюсь заменять ИТ-термины, англицизмы и просторечия на их аналоги:
Деплой → процесс доставки кода
Шарить экран → демонстрировать экран
Задизайблено → поле недоступно для редактирования, кнопка неактивна
Поп-ап → всплывающее окно или сообщение
Плашка → отметка или информационное сообщение и т.д.
Хотя термины могут казаться понятными из контекста и сопровождаются демо, при их использовании я часто вижу нахмуренные брови и другие проявления напряжения на лицах бизнес-заказчиков :)
Поэтому я стараюсь их избегать, чтобы облегчить восприятие информации. Это проявление уважения к клиенту, который часто перегружен большим количеством информации по другим процессам.
На демо по обращениям участники разных бизнес-подразделений иногда использовали разные термины для одних и тех же объектов, поэтому я старалась проговаривать оба термина.
Обрабатываю обратную связь и ищу в ней ценные идеи
Во время демо возникают вопросы, замечания и даже споры. Это нормальный процесс, который может стать источником идей для развития продукта. Он указывает на то, что участники вовлечены в демонстрацию и для них важен результат. Поэтому на встрече должен присутствовать аналитик, который занимался задачей. Он прокомментирует, по какой причине и в каком контексте было принято решение в пользу конкретной реализации.
Иногда заказчик может задавать вопросы не по теме встречи или по уже показанной функциональности. Тогда я кратко отвечаю на них, но продолжаю модерировать встречу и удерживать участников в рамках подготовленного плана. Это повышает вероятность успеть показать все задачи за отведенное время и запустить дальнейшие процессы — тестирование заказчиком, выпуск релиза и т.д. Вместо ответов в моменте я предлагаю запланировать отдельную встречу и обсудить вопросы на ней, если это необходимо. Эта встреча может иметь более узкий состав участников.
Проговариваю дальнейшие шаги
Договориться о дальнейших шагах, сроках и ответственных за их выполнение — важный этап любой встречи. Это могут быть вопросы о тестировании со стороны бизнеса, сроках поставки релиза, устранения замечаний и обсуждения открытых вопросов. После встречи у всех участников должно быть единое понимание следующих действий.
Этап 3. После демонстрации
Конечно, после проведения демо мы с командой обрабатываем обратную связь и устраняем замечания. Но есть еще два важных шага, которые я выделяю.
Отправляю протокол встречи
После демо, как и после любой встречи с заказчиком, я отправляю всем участникам протокол. Я включаю в него краткое описание задач (просто копирую подготовленные Release Notes), а также все замечания, идеи, вопросы и договоренности.
Рефлексирую и оцениваю полученный опыт
Важно выделить время, чтобы проанализировать полученный опыт и сделать выводы на будущее.
Какую обратную связь озвучил заказчик?
Что ему было не понятно в ходе демо?
На что он реагировал негативно, а на что позитивно?
Ответы на эти вопросы и применение их в дальнейшем позволяют развиваться профессионально и улучшать отношения с клиентом, ведь он будет видеть изменения и внимательное отношение. Хотя обычно мы говорим, что наша компания работает с компаний-заказчиком, на самом деле работают друг с другом конкретные люди, отношения между которыми влияют на общий результат. Даже небольшие, но регулярные улучшения со временем приводят к большим переменам.
9 советов, как сделать демо для бизнес-заказчика эффективнее
Перед демо проанализируйте состав участников и адаптируйте рассказ под их позицию и опыт.
Если на демо приглашены слушатели, которые увидят систему впервые, начните встречу с вводной информации о ней, и только потом переходите к частным сценариям.
Сосредоточьтесь на основных сценариях использования системы. Опустите ошибки и технические аспекты реализации, если они не влияют на работу пользователей.
Если есть возможность, лучше показывайте сквозной бизнес-процесс от и до во всех задействованных системах.
На демо показывайте данные, приближенные к реальным. Тестовые данные будут сбивать слушателей с толку.
Сократите использование специфической ИТ-терминологии и англицизмов. Речь должна быть понятной и привычной для слушателей.
Обратная связь, даже если она негативная — это источник идей и показатель заинтересованности в результате. Не игнорируйте предложения заказчиков. После завершения демо выясните, почему у них возникли конкретные предложения и оцените их вместе.
Все участники должны одинаково понимать дальнейшие шаги, их сроки и ответственных. Зафиксируйте их и направьте участникам по почте.
После демо уделите несколько минут рефлексии и проанализируйте полученный опыт. Маленькие шаги постепенно приведут к большим результатам.
А какие интересные демо для бизнеса проводили вы? Буду очень рада узнать о вашем опыте в комментариях.
