Как правильно рассказать о value. Практические советы, как готовиться и проводить демо

Всем привет! Меня зовут Марина Варасова, я Project Manager и Scrum Master в компании Techstack. За девять лет работы в IT-индустрии я провела сотни демо и видела совершенно разные варианты этого процесса. В этой статье я расскажу, как, зачем и почему проводить демо, а также поделюсь несколькими правилами его успешного прохождения. Если вы Product Owner, Project Manager, Scrum Master или любой другой человек, заинтересованный в успехе продукта, то эта статья для вас.

Зачем проводить демо

Кратко оговорюсь, что демо — это наглядная презентация работы, выполненной за спринт. Зачем демонстрировать результаты спринта клиентам? Объясню на бытовом примере.

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

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

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

Что показывать на демо

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

Для успешного и эффективного проведения демо обратите внимание на наличие нескольких элементов:

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

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

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

Кому показывать демо

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

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

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

Product Owner может казаться самым очевидным заинтересованным лицом на демо, но мой совет — не нужно ждать демо, чтобы Product Owner принял ваши юзерстори. Они должны быть приняты заранее в соответствии с критериями приемки в течение спринта. Идеальная ситуация: спринт закончился, все стори приняты, а на демо вы просто показываете, чего успели достичь.

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

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

Когда проводить демо

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

Как проводить демо

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

Опишите контекст

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

Подготовьте сценарий

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

Обозначьте ценность

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

Готовьте визуальное сопровождение

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

Не прекращайте говорить

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

Формируйте содержание демо в зависимости от аудитории

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

Учитывайте предыдущий опыт

При каждом последующем демо фиксируйте опыт предыдущего. Если вы уже поняли, что у вашего слушателя обычно мало времени, постарайтесь подстроить свое демо под него. Или, наоборот, бывают клиенты, которым лучше все подробно объяснить, наглядно показать, а потом еще и в письменном виде все представить. Учитывайте такие особенности.

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

Подготавливайте все вспомогательные данные в отдельном файле

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

Проверяйте продукт перед демо

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

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

Объявляйте stop deployment перед демо

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

Репетируйте

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

Говорите размеренно

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

Делайте паузы для вопросов

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

Адекватно воспринимайте обратную связь

Конечно, положительная обратная связь всем нравится и всех мотивирует. Но бывает, что вы получаете в ответ критику. И это тоже неплохо, потому что наша цель — делать качественные технические продукты, а это всегда требует улучшений и обновлений. Даже критический отзыв продвигает нас ближе к цели. Фиксируйте обратную связь письменно или запрашивайте ее в виде change request, чтобы быть уверенным, что вы с заказчиком и конечными пользователями представляете себе одинаковую «собаку».

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

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

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

Что в итоге

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

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

👍НравитсяПонравилось12
В избранноеВ избранном3
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Спасибо, Мариш! :)
Информативная статья и отличный чек-лист для моментального внедрения!

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

А якщо компанія продуктова і замовника немає? Щось зміниться?

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

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

Инкремент, вынесенный на демо

А що таке інкремент?

Инкремент — это результат работы спринта — потенциально готовый к релизу функционал, который соответствует ДоД. Сам продукт складывается из инкрементов. Есть даже такое понятие: инкрементальная разработка.

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

тільки як пафос

а также на профессиональный сленг

удивительно читать на ДОУ что кого-то задевает слово агенда
с точки зрения чистоты языка несомненно это неправильно, с точки зрения аудитории ДОУ как раз наоборот — привычный термин, да заимствованный из английского

жира, таски, митинг (мои родственники долго привыкали когда я говорю «я на митинге» поскольку в их сознании митинг это совершенно другое) и так далее

та же история, у меня была уверенность, что несмотря на то, что аудитория ДОУ — не моя локальная команда, но что заимствованные термины всем знакомы и привычны.

Я с вами соглашусь :). спасибо за комментарий. Велью — это ценность, а агенда — повестка встречи. Мне будет очень приятно, если кроме факта использования заимствованных слов в моей статье для вас была какая-то ценность. (или велью :) )

А вам подобається, коли ваші співробітники розмовляють з вами в стилі «я вчора ресерчнул сторі, заапрувь мій естимейт і адвайзні по некст таскам»

Мне очень нравится, когда сотрудники обладают навыками коммуникации, когда они что-то ресерчат :), когда задают вопросы или когда советуются. И мне совершенно неважно, делается это на украинском языке, на русском, на суржике из проф. терминов или на английском. Главное — результат. Предпочитаю поддерживать людей и оставаться в конструктивном русле.

Сокращу до смысла: Не прекращайте говорить

— Наша работа — брать бабло у клиента из кармана и класть в наш карман.
— Это да, но если вы заодно и клиенту поможете заработать, это выгодно для каждого, правда ведь?
— Нет.

Подписаться на комментарии