Astra inclinant, non necessitant
Худшее, что вы можете сделать — тупо отправить ссылку на реализованное приложение заказчику. Скорее всего, его не примут, получите массу непонимания. Нужна сессия демо функциональности заказчику. О нём и поговорим.
Основные проблемы «интуитивного» демо
Во многих компаниях руководитель проекта обязан демонстрировать продукт заказчику. Обычно он думает, что в этом нет никакой проблемы, ведь приложение разрабатывалось под его руководством, он там всё знает. Просто откроет и будет показывать, что и как работает.
Такой подход быстрый, но у него есть минусы:
- Недостаток контекста: Пользователи чаще всего хотят видеть связные процессы, а не отдельные фичи.
- Отсутствие структуры: Система не есть сумма элементов. Приложение не есть набор функций, нужна структура повествования.
- Проблемы с вовлечением: Если вы будете показывать функции как технарь, аудитория быстро потеряет интерес.
Что такое пользовательский сценарий
Рассмотрим на примере формы на бронирование отпуска с именем сотрудника, видом отпуска, датами начала и завершения. Форма подсчитывает количество дней отпуска, относительно производственного календаря и подсказывает, достаточно ли дней у пользователя есть в распоряжении.
Показываем пользователю весь сценарий. Как он авторизуется в системе, открывает форму отпуска, заполняет поля, выбирает из выпадающего календаря даты, видит на форме инфу о количестве выбранных и доступных дней отпуска, жмёт на кнопку бронирования, система пишет о приёме заявки. Заказчики видят цельный процесс.
Кроме того, если в системе несколько ролей, вы можете показать, как будет выглядеть этот сценарий, относительно других ролей.
Почему сценарий важнее отдельных фич
Помним, что бизнес заказывает программное обеспечение не в качестве самоцели, а чтобы решить какие-то свои бизнес-потребности. И вот на этом мы должны сделать акцент на демо, показав, как разработанные фичи вписываются в его текущие процессы и облегчают решение задач. Для этого нужна демонстрация связных процессов.
Работа с ролями
Ролевая модель стоит во главе проектирования любой системы. Например, в предыдущем примере могут быть три роли — сотрудник, подающий заявку на отпуск, эйчар, руководитель сотрудника.
| Роль | Функции |
|---|---|
| HR-менеджер | Подтвердить, отклонить или удалить заявку |
| Начальник отдела | Подтвердить или отклонить заявку |
| Сотрудник | Видеть статус заявки заявок |
Во время демо нужно зайти под каждой из ролей и показать процесс с точки зрения каждого типа пользователей. Само собой разумеется, что у вас должны быть заранее подготовлены аккаунты и лежать под рукой данные для авторизации.
Непосредственно демо
В первую очередь надо решить вопрос с вопросами (лол). Нужно проговорить, в какие моменты демо заказчик может задавать вопросы, чтобы демо не стало скомканным, если этих вопросов будет слишком много. Можно предложить спрашивать после каждого блока или вообще, в конце всего демо, если оно небольшое.
Как правило, вам нужно расшарить экран и включить запись. Имейте в виду, что если вы маковод, нужно заранее решить вопрос с правами показывать экран для приложения, через которое вы созваниваетесь. Так как дача прав требует перезапуска приложения, это нужно сделать заранее, не тупить во время демо.
Понятно, что вы от и до знаете всю функциональность, но я вас прошу, не торопитесь и не мельчите. Заказчики же видят его впервые, им надо осознать, что происходит.
Обязательно в конце демо скажите, что закончили.
Сбор обратной связи по итогам демо
У заказчика вечно просыпается «аппетит» во время демо. И он начинает накидывать фичи. Как это обрабатывать?
- Не соглашайтесь брать фичи сразу, игнорируя аналитику. В каждой фиче надо разобраться, понять, действительно ли она нужна, кому нужна, какую проблему решает. Записывайте.
- Фокусироваться на проблеме. Возможно, проблема, которую хочет решить заказчик, решается другим способом, более изящно.
- Всё записывать.
- Не забывать о приоритизации прилетевших фич. Но это лучше сделать хотя бы после минимального анализа.
Подготовка тестового контура и проведения внутреннего демо
Джобс, когда показывал первый айфон, очень чётко представлял, что устройство не работает как надо. Можно нажимать только некоторые последовательности операций, которые более-менее отлажены. Вы во время своего демо должны понимать, что могут вылезти ошибки. Поэтому лучше для демо подготовить отдельный тестовый контур, в котором система будет работать более-менее корректно.
Если у вас начнут вылезать ошибки, заказчик к этому гарантированно очень плохо отнесётся, решит, что софт не готов. Такого лучше избежать.
Что нужно проверить в тестовом контуре?
- Гриды не должны быть пустыми. В системе должны быть заведены пользователи, созданы тестовые заявки с заголовками и данными, похожими на реальные.
- Неоднократно проверить сценарии.
- Прорепетировать. Провести внутреннее демо аккаунтами или деливери или кто там у вас.
Хорошо, если внутреннее демо проходит в формате обсуждения, где например аккаунт сможет задавать вопросы, а вы сможете ответить на них.
Итого
Ваше демо должно быть отлаженным и структурированным. Представлять собой связные сценарии использования ПО. Не грузите лишними техническими деталями, показывать реальную пользу системы. Подготовить тестовую среду, учитывать роли, тем самым показывая, что система готова к тестовой эксплуатации.
