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

1. Заранее не сформировали повестку и не ознакомили с ней заинтересованных лиц. Во-первых, нужен план. По шагам. Конкретный план с примерами. С перебором разных сценариев. План надо отдать тестировщику — чтобы он его прогнал, дополнил, раскритиковал. Во-вторых, в приглашении на демо этот план должен быть в виде буллетов, какой функционал вы хотите показать. Что-то типа релиз-нотесов. Скорее всего их не прочитают, но шансы на успех вырастут.
2. Взяли слишком много не тех людей. Не надо звать всё, что шевелится и имеет отношение к проекту. Людям будет не интересно, они могут начать цепляться к словам, задавать ненужные вопросы (ну потому что они не в теме прошлой демо, например). Только нужные люди, заинтересованные — залог успешного мероприятия.
3. Забыли взять (или получить отказ) ключевых заказчиков. Что толку от демонстрации, когда её не увидит тот, для кого всё это. Что толку от того, что вы не услышите его замечания, не убедитесь, что всё хорошо. Мы иногда переносим демо и не переживаем за это. Есть умники, которые считают, что важно показать финальное демо для ключевого заказчика — хрень полная. Важно показать промежуточный результат. Тогда на финальном демо вы не услышите что-то типа — а это чо за хрень?
4. Забыли взять разработчиков, которые делали отчетный функционал. Если что-то пойдёт не так, если ведущий забудет что-то, если возникнут технические вопросы, если потребуются уточнения по деталям реализации — кто на это всё ответит? Тащить всю команду скорее не надо, но по представителю от рода войск будет очень уместно. Плюс послушают реакцию, покраснеют за ошибки и т.д. Очень полезно.
5. Фаталы на демонстрации. Кому охота смотреть на трейсы и синие окна. Это категорически недопустимо. Функционал, который заявлен, как рабочий — должен работать. Вы отвлекли порядочное количество людей от работы. А им предлагается посмотреть на то, как вы краснеете и занимаетесь выяснением, а можно ли что-то показать без функции добавления записи. Мои делают так: прогоняют план демонстрации на сборке, которую кладут на выделенный сервер, и до демонстрации его не трогают вообще. Всё для того, чтобы не нарушить изначальный сценарий. Всё-равно проскакивает, но не так больно.
6. Ведущий не подготовился. Мычащий ведущий это отстой. Мало того, что вы толком ничего не покажете по продукту, взамен вы покажете своё полное неуважение к аудитории ( а это ваши заказчики, на секундочку). Всё должно быть чётко — примеры, данные, копипасты, готовые примеры, положительные, отрицательные сценарии. Мои делают в обычном нотпаде. По шагам — ссылки, данные, результаты. Всё готово заранее. Контрол+Ц -> Альт+таб->КОнтрол+В. И так всё демо. Вы покажете, что вы подготовились, что вы потратили время, тем самым вы выкажете уважение к зрителям и плюс в карму.
7. Обилие технических подробностей и сленг в показе. Уверяю, никому не интересно слушать про то, что помимо нодджээса в вашей системе появился ещё какой-то кролик, у которого забирает данные какой-то червяк и кладёт в мемкэш, который отмасштабирован горизонтально для достижения надёжности. Вы нагоните тоску, заставите людей себя чувствовать идиотами. Кесарю — Кесарево, Слесарю — Слесарево. Надо понимать, для кого вы показываете. Если для админов — то да, для них потоки данных — важнейшая информация, а вот девочки из маркетинга похихикают над кроликом и пропустят самое главное.
8. Нереальные примеры при демонстрации. Так ли интересно смотреть на поведение системы при данных и сценариях, которые в жизни вообще никогда не случатся? По опыту для проведения демонстрации отлично подходят тестовые данные от ваших тестов. Причём очень круто показывать, как положительные, так и отрицательные ветки.
9. Нет того парня, кто записывает за всеми замечания. Это катастрофа. По сути тогда всё ваше мероприятие — профанация. Лучше всего конечно таскать диктофон и втихую записывать. А потом сделать стенограмму и разбираться. Но это долго. Проще записывать в реальном времени. но тогда должен быть кто-то, кто обязательно всё пишет чем подробнее, тем лучше.
10. Нет письма с замечаниями на всех участников, чтобы убедиться, что вы всё понято правильно. А вдруг что-то было отмечено в спешке? — Легко. В процессе диалога мыль могла метнуться влево или вправо, как результат — замечания будут устранены некорректно. Двойная работа.

Итого, чтобы увеличить шансы успешной демонстрации:

1. Сделать план
2. Прогнать план у тестировщика на командных склянках, на которых потом будет демонстраия.
3. Перед демо ничего не исправлять и не делать коммитов.
4. Начать готовится к демонстрации заранее, например, за 3-4 часа до ее начала. Проверить, что в переговорной всё работает, есть интернет, свет, газ, телефон.
5. Согласовать перечень функционала на демонстрацию с менеджером.
6. Убедиться, что письмо с повесткой демонстрации ушло к нужным людям
7. Проверить, что все заинтересованные лица и ключевые заказчики приглашены
8. Выбрать ведущего, подготовить примерный рассказ, подготовить тестовые примеры и тестовые данные
9. Выбрать парня, который будет записывать замечания и пожелания
10. Составить и отправить письмо с результатами демонстрации, чтобы все ещё раз убедились, что ничего не забыли.

[sgmb id=»1″]