Демонстрация разработки

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

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

Однако тут есть опасности:
▪️ проводить демо в виде презентации, без установки решения на тестовый стенд Заказчику
Глядя на презентацию невозможно вообразить все кейсы и высказать замечания по поводу удобства использования системы. Мы же хотим реальную обратную связь, поэтому нужно давать возможность ответственному человеку пробовать выполнить действия в создаваемой системе самому, “руками”.
Стоит договориться о составе принимающих сотрудников.

▪️ отсутствие времени у Заказчика
Как же часто бывает, что у Заказчика не находится времени на промежуточные демо. А вот когда время подходит к сдаче проекта, все судорожно начинают приемку. И одномоментно возникаем миллион замечаний.
Стоит договариваться о выделении рабочего времени для принимающих сотрудников.

▪️ недоделки в функционале
Реализовать тестовую функциональность на заглушка отнимает кучу времени. И с каждой ошибкой/не работающей фичей теряется лояльность и терпение.
Стоит договориться о ключевых вехах в функционале, который будет достоин тестового стенда.

Проводить демо стоит, и нужно это делать как можно раньше. Но это всего лишь один из хороших инструментов