Демонстрация результатов разработки заказчику должна показывать, какую рабочую задачу система уже решает и что ещё мешает завершению. Если ведущий переключает красивые экраны, незаметно исправляет данные и отвечает за пользователя, готовность легко переоценить.
Полезный показ заканчивается коротким журналом решений: что подтверждено, какое ограничение обнаружено и что делать дальше. Ниже — порядок демонстрации, условный пример заказа и чек-лист для повторяющихся встреч. Такой показ подтверждает прогресс этапа, но не заменяет полную техническую проверку, пользовательскую приёмку и решение о запуске.
Выберите законченный рабочий вопрос
Вместо темы «покажем раздел заказов» сформулируйте результат: оператор создаёт заказ, диспетчер назначает исполнителя, исполнитель видит своё задание. Тогда понятно, где сценарий начинается и чем заканчивается. Наличие трёх экранов не является достаточным результатом.
Укажите связь с согласованным требованием и версией системы. Если команда показывает прототип, назовите его прототипом. Если обмен имитируется, обозначьте это до начала, чтобы участники не приписали демонстрации проверку действующего подключения.
Ограничьте встречу несколькими вопросами, по которым действительно нужно решение. Длинный показ всех изменений уменьшает внимание и затрудняет фиксацию результата. Лучше пройти один законченный маршрут с исключением, чем бегло показать десять незавершённых функций.
Подготовьте исходные данные и ожидание
Используйте проверяемый набор с понятными идентификаторами. Заказчик должен знать, какие значения ожидаются, а не вычислять их по ходу демонстрации. Для расчётов подготовьте независимый контрольный результат.
В условном примере клиент К-18 заказывает 12 комплектов по 2 500 рублей. Ожидаемая сумма — 30 000 рублей. Диспетчер назначает исполнителя И-04, после чего задание должно появиться у него один раз, с правильным количеством и датой.
Рядом подготовьте ошибочную запись без клиента и повтор той же операции после имитации потерянного ответа. Это три разных проверки. Успешное создание обычного заказа не подтверждает ни валидацию, ни защиту от повторного результата.
Показывайте действия под рабочими ролями
Администратор часто имеет больше прав, чем сотрудник. Если всю демонстрацию проводят под его учётной записью, нельзя сделать вывод, что оператор сможет выполнить маршрут и не получит лишний доступ. Назовите роль перед каждым этапом.
Пусть оператор создаст заказ, затем ведущий переключится на диспетчера и исполнителя в согласованной тестовой среде. Проверьте, что данные действительно сохранены, а переход между ролями не требует ручного изменения записи разработчиком.
Отдельно покажите, чего роль делать не должна. Например, исполнитель не меняет согласованную цену. Скрытая кнопка сама по себе не доказывает защиту, поэтому полноценную техническую проверку прав выполняют отдельно. На демонстрации важно не спутать показ интерфейса с доказательством всех ограничений.
Сделайте ручные вмешательства видимыми
Иногда для продолжения показа приходится перезапустить компонент, дополнить справочник или исправить тестовую запись. Само вмешательство не делает встречу бесполезной. Проблема начинается, когда его не учитывают и объявляют весь маршрут готовым.
Зафиксируйте, что сделал специалист, почему это понадобилось и является ли действие частью будущей эксплуатации. Штатная настройка администратора отличается от исправления данных напрямую, а загрузка утверждённого справочника — от подстановки удобного ответа.
Если внешняя система пока недоступна, можно показать обработку искусственного ответа, но вывод ограничивается этой частью. В журнале пишут «обработан тестовый ответ указанного формата», а не «интеграция работает». Зависимость получает владельца и отдельную проверку.
Спросите о результате, а не об общем впечатлении
После маршрута попросите представителя процесса назвать состояние заказа, следующего ответственного и доступное действие. Это позволяет обнаружить смысловые расхождения: система показывает «готов», а пользователь понимает под этим отгрузку, хотя разработчик имел в виду назначение.
Замечания о цвете и расположении тоже могут быть полезны, но не должны вытеснять проверку данных и ответственности. Сначала выясните, позволяет ли поведение закончить работу. Затем обсуждайте удобство и визуальные предпочтения по их влиянию на действие.
Не требуйте мгновенного решения по вопросу, которого не было в повестке. Если выяснилось новое бизнес-правило, назначьте владельца и срок. Устное согласие уставшего участника в конце встречи не заменяет осознанного подтверждения изменения.
Условный итог одной демонстрации
Команда показала три проверки. Обычный заказ сохранён с суммой 30 000 рублей и передан исполнителю. Запись без клиента отклонена с понятным сообщением. При повторе после потерянного ответа появилось второе задание.
Писать «готово на 67%» не стоит. Две пройденные проверки из трёх описывают только этот набор, а ошибка повтора может блокировать рабочее использование всего маршрута. Зафиксируйте её последствие и условие повторного показа.
Итог встречи: обычный сценарий подтверждён на тестовых данных; защита от повторного задания не подтверждена; расширение маршрута отложено до исправления; следующая проверка включает повтор и сохранность первоначального заказа. Такой протокол даёт команде конкретное действие вместо общей оценки впечатления.
Чек-лист перед каждым показом
- Названы версия, среда и рабочий результат.
- Известны роли участников и полномочия принимающего решение.
- Исходные данные подготовлены и доступны для сверки.
- Контрольные суммы рассчитаны независимо.
- Имитируемые зависимости отмечены до начала.
- Показано сохранение после повторного открытия.
- Пройдено хотя бы одно существенное исключение.
- Ручные вмешательства записаны.
- Неподтверждённые части получили отдельный статус.
- Следующая проверка имеет владельца и ожидаемый результат.
Не превращайте чек-лист в одинаковый ритуал для любых изменений. Для отчёта важнее сверка формулы и периода, для интеграции — повторы и ошибки доставки, для доступа — границы ролей. Общая структура сохраняется, содержание выбирают по риску показанного результата.
Ведите журнал решений короткими записями
Карточка содержит сценарий, ожидаемый и фактический результат, ограничение, решение и ответственного. Добавьте ссылку на запись проверки или идентификатор объекта. Видеозапись может дополнять протокол, но не должна быть единственным способом найти принятое решение.
Разделите дефект, уточнение и новую потребность. Их порядок разбора описан в статье об изменениях требований. Для определения ожидаемого результата используйте критерии приёмки внутренней системы.
На следующей встрече начните с ранее открытого важного вопроса. Исправление считается подтверждённым после повторной проверки, а не после сообщения «задача закрыта». При смене условий обновите и ожидаемый результат, сохранив основание изменения.
Следующий шаг
Выберите ближайший сквозной сценарий и подготовьте обычную запись, один повтор и одно запрещённое действие. С ExtentLab можно обсудить формат демонстраций для вашей разработки: что показывать под каждой ролью, какие зависимости отмечать и какие решения фиксировать после встречи.