Любите ли вы демо так, как его любим мы? Сейчас посмотрим.

Что такое вообще демо? Это когда команда раз в спринт приходит к клиенту и говорит: «вот, клиент, смотри, что мы сделали». И ждет фидбек. Так?

Нуууу…нет 🫤

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

Но нельзя просто так взять и решить: «Теперь мы на демо синхронизируемся, а не просто показываем работу». Чтобы демо было продуктовым, а не формальным, важно держаться нескольких принципов.

✅ Демо — не встреча для согласования результатов.

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

✅ Главная цель — понять направление, а не показать результат.

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

✅ Демонстрируют те, кто делает.

Когда разработчик, дизайнер или аналитик сами показывают свою часть, разговор получается живым и предметным. А ещё степень вовлечённости и ответственности выше: когда знаешь, что предстоит рассказывать о своей работе, стараешься сделать её как можно лучше.

✅ На демо рождаются идеи, а не формальный фидбэк. И эти идеи нужно не только фиксировать, но и валидировать.

У нас 6 из 10 демо вообще могут проходить без какого-либо фидбэка. И это нормально. Но новые идеи и мысли, что бы ещё добавить, регулярно возникают. И тут важно понимать, что любая идея без структуры — просто поток сознания. Её нужно отловить, отрефлексировать и провалидировать: действительно ли она нужна продукту или это шаг в сторону feature creep.

А что на ваших демо важнее — показать сделанное или свериться с курсом? Делитесь в комментариях!

#продуктоваяразработка #процессы

Привет! Это Веня. Раз уж мы заговорили о демо, то хочу одну важную тему поднять: что на самом деле есть демо.

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

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

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

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

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

Хорошее демо проходит спокойно. На нем можно честно сказать, что сделали, что заняло больше времени и что вызывает вопросы. Клиент на таком демо – не экзаменатор, а часть команды. Он помогает скорректировать направление, расставить приоритеты и принимать стратегические решения, от которых зависит релиз.

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

Резюмируем. На демо здорового человека нам нужно:

✅ Показать, что сделали, и сколько времени это заняло.
✅ Понять, нет ли риска, что мы уходим не туда.
✅ Отметить, если какая-то часть решения получилась не так, как ожидали, чтобы вовремя скорректировать курс. Но не копаться в том, почему так получилось, кто виноват и что делать – все это проговариваем отдельно.

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

Доверим проведение демо самому разговорчивому или самому трудолюбивому❓


Что демо должно из себя представлять разобрались. Но этому всему вроде как нужен ведущий. Это менеджер? Тимлид? Разработчик, который делал фичу? Может вся команда понемногу?

Кажется, на рынке любят искать золотой стандарт, но, если честно, его нет. Порой один человек стабильно ведёт демо, и все в восторге. Видели и обратный вариант, когда весь проектный состав выходит в звонок, и это тоже работает прекрасно.

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

С одной стороны, удобно сделать проведение демо отвественностью одного конкретного человека. Например, проджекта. Но есть нюансы:

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

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

Плюсы заметны сразу:
✅ рассказывать (и слушать) проще, потому что никому не надо заходить в чужую область ответственности;
✅ качество демо растёт, потому что самый классный способ описать проделанную работу – дать слово тому, кто её делал
✅ команда получает шанс показать свой вклад и целиком, и по отдельности, а клиент видит живых людей, а не абстрактный «отдел разработки».


🔣Есть и бонус: демо – это безопасная тренировка публичных выступлений🔣


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

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

Но если смотреть на долгую дистанцию, мы тут поняли для себя, что прозрачность и качество объяснения выше там, где демо – общая работа.

А у вас как? 🥴

Демо должно быть скучным.

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

Скучное демо — лучший показатель того, что продукт развивается правильно.

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

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

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

Для подготовки скучных демо нужно всего лишь:

🔣 оставлять место критическим обсуждениям и корректировкам внутри спринта;
🔣 показывать клиенту промежуточные версии вне демо;
🔣 выносить мелкие правки в отдельный процесс;
🔣 сделать клиента вовлеченным владельцем продукта, а не время от времени приезжающим ревизором.

Формальную приёмку и демо совмещают те, кто любит боль 😈

Это как раз тот случай, когда демо превращается в экзамен. А мы уже говорили, что от такого превращения никому лучше не станет. И продукту вашему — тоже.

Мы разделяем эти вещи принципиально. И вот в чем разница.

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

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

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

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

Как один стейкхолдер может разрушить полгода работы за пять минут

Привет, на связи Андрей! Хочу немного уделить внимания тому аспекту демо, с которым никому не нравится сталкиваться 😐

Вот вы полгода делаете сервис, демо идут ровно и скучно, команда уверена в курсе. И вдруг на встрече появляется важный стейкхолдер — условный Василий Петрович — и с порога заявляет:

— Что это все вообще такое? Всё не то и всё не так.

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

Что делать в такой момент?

➕ Спокойно поговорите отдельно.

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

➕ Если вопросы серьёзные, повысьте прозрачность.

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

➕ Настройте регулярный формат взаимодействия.

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

В итоге появление Василия Петровича должно перестать быть сюрпризом. И никакого стресса 😉

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

Итак, рецепт успешного демо продукта:

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

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

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

А потом разговор съезжает не туда. Человек от бизнеса цепляется за решение из чужого проекта и начинает примерять его на себя.
Вместо «какую проблему мы хотим решить» идет обсуждение в духе «давайте внедрим вот это, оно же у них работает».

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

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

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

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

Хочется понять, насколько эта боль общая.
Сталкиваетесь с таким же «витринным мышлением» на кастдевах?
Как вы возвращаете разговор с полки готовых решений обратно к реальным задачам?

Давайте попробуем собрать коллективный разум.