Для начала смоделируем ситуацию:

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

После согласования основных деталей по бюджету, дизайну

и обсуждения технических требований,

команда приступает к разработке проекта:

трудится над программной частью

и доводит до совершенства дизайн,

придумывает множество убойных фишек

и, конечно, проводит тестирование на каждом этапе.

И вот наступает день Х – презентация готового продукта.

Но долгожданный релиз выглядит совершенно иначе, чем вы ожидали!

Возникает резонный вопрос:

как это могло произойти,

если все шло строго по утвержденной схеме и требованиям?

Это довольно распространенная ситуация в большинстве компаний по разработке ПО.

Одним из успешных решений ее может стать

демонстрация проекта,

которая нашла отличное применение на практике и в нашей компании.

Что такое демонстрация

Демонстрация проекта, или demo

– это неотъемлемая часть любой работы над проектом,

проводится по завершении спринта

и нацелена на представление итогов работы клиенту.

Как правило, demo позволяет определить,

в правильном ли направлении движется проект,

сформировать единое видение конечного продукта,

следить за прогрессом

и корректировать сложности еще в процессе разработки,

а не на этапе сдачи проекта.

Конечная цель demo

– получение не просто проекта,

соответствующего заявленным техническим требованиям,

а действительно нужного именно вам и вашему бизнесу продукта.

Какая бы методология ведения проектов ни была выбрана (PMI, Scrum, Canban и т. д.),

demo рекомендуется проводить на каждом из этапов работы над проектом:

На этапе планирования, путем создания макетов и прототипов;

На этапе разработки, демонстрируя промежуточные результаты,

например, по завершении спринта или контрольной точки;

По завершении всей работы, например, на последнем тестировании.

Я как менеджер проектов

стараюсь показывать результат работ своим клиентам настолько часто,

насколько это возможно.

Представим, что есть в наличии

тестовый вариант мобильного приложения,

планы работ на следующий спринт,

результаты работ по завершении текущего спринта,

клиенту отправлены уведомления

о возможности начала тестирования новой версии продукта.

Все это не дает гарантии,

что все заинтересованные лица самостоятельно проверят результат.

По теме: Как мы работали с финской таможней – опыт Pochta.fi

Рассмотрим два кейса,

которые встречались в практике

Кейс 1.

Я информирую клиента о результатах спринтов,

команда ведет все задачи в Trello или Jira,

где весь процесс разработки можно отследить.

Проходит десять спринтов,

и по результатам очередных переговоров мы начинаем понимать,

что клиент не знает своего продукта

и не ориентируется в нем.

Кейс 2.

Команда выполнила работы по спринту,

протестировала новую версию продукта,

внесла дополнительные изменения,

я проинформировала клиента о том, чтобы он посмотрел результат.

Пришел фидбэк, в котором сказано, что можно запускать проект.

Все запустили, загрузили,

и приходит еще одно письмо – что логика работы не такая, как ожидалась.

И знаете, какой вывод я вынесла из этого?

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

должна быть показана клиенту,

тогда подобных ситуаций не возникнет.

Команда разработала новый функционал вашего будущего бизнес-инструмента,

менеджер проектов показал, описал и проговорил его вместе с вами.

Таким образом, команда исполнителей лучше поймет,

насколько результат удовлетворяет ваши ожидания,

будем ли мы двигаться в заданном направлении

или пора что-то изменить, пока еще не поздно…

Вернемся на секунду к разработке мобильного приложения:

если бы на этапах работы над проектом были проведены demo,

тогда вы бы получили замечательный продукт,

и в день Х вас бы не ожидало разочарование.

Аналогично и с кейсами:

здесь проблема кроется в самом проведении демонстрации.

Важен не только факт проведения demo,

но и способы презентации.

Конечно,

личные встречи клиента с менеджером проектов

– это идеальное решение,

но чаще всего клиент и команда исполнителей далеки друг от друга.

Поэтому есть иные способы проведения demo,

которые я использую в своих проектах:

Подведем итоги

Я настоятельно рекомендую как можно чаще проводить demo.

Идеальным вариантом является

проведение демонстрации проекта после каждого спринта,

чтобы вы могли увидеть, пощупать

и протестировать полученный на данном этапе продукт,

оценить его функционал,

дать напутствия команде разработчиков

и обсудить возможные разногласия,

вопросы

и новые идеи.

Проведение demo нацелено на создание

первоклассного бизнес-решения,

которым вы будете довольны на все 100%,

и даже больше.

-------------------

https://rb.ru/opinion/project-demo/