Работа с конечным пользователем в модели прототипа

Одной из самых сложных задач при разработке программного обеспечения является приведение продукта в соответствие с видением владельца продукта. Процесс этот непростой, поскольку иногда возникает недопонимание, а иногда цели меняются. В любом случае, когда видение и результат не совпадают, наступает момент, когда никто не доволен.

В традиционных моделях, таких как водопадная методология, владелец продукта и конечный пользователь играют весьма пассивную роль. После завершения анализа требований разработчики приступают к работе, и до момента готовности проекта к развертыванию взаимодействие практически не происходит.

Другие методологии, в том числе итерационные модели, считают это проблемой и находят ценность в вовлечении обеих ролей на протяжении всего проекта. Идея заключается в том, что разработка программного обеспечения - это не линейный процесс, и постоянная обратная связь помогает улучшить работу и создать лучшее решение в долгосрочной перспективе.

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

Хотя существует множество подходов к созданию прототипов, все они имеют схожую схему:

Прототипы создаются с использованием ярлыков и кода-заместителя. Идея заключается не в том, чтобы создать полнофункциональное программное обеспечение без ошибок (это будет потом). Прототип - это демонстрационный образец, как эскиз чертежа или макет здания. 

Если уж на то пошло, то прототип - это как игровая площадка в песочнице. Это место для экспериментов, где каждый участник проекта может возиться и вносить изменения по своему усмотрению, не опасаясь сломать что-то или взять на себя обязательства, которые впоследствии могут оказаться проблематичными. 

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

Пожалуй, самая большая проблема с прототипами заключается в том, что на их создание требуется время. Это время можно потратить с пользой, но не каждый проект может похвастаться длительным циклом разработки. В тех случаях, когда оперативность выполнения проекта является важным фактором, более надежными оказываются agile-методы.

Пользователи играют ключевую роль в модели прототипа. Они являются авторитетом, теми, чьи рекомендации помогут разработчикам сформировать конечный продукт. Роль пользователя относительно проста: садишься с прототипом, играешь с ним, задаешь вопросы, даешь обратную связь, ждешь, пока будет готов другой прототип, и все повторяется. 

Однако пользователи, превышающие свои полномочия или не понимающие сути модели прототипа, могут помешать процессу. Вот несколько рекомендаций, которые следует иметь в виду.

Разработчики, не создавайте прототип в вакууме. Вы всегда должны представлять прототип с документацией, в которой четко указаны цели создания прототипа, существующие системы, тип обратной связи, которую вы ожидаете получить, и возможные ошибки, которые могут быть обнаружены пользователями. Это поможет пользователю управлять своими ожиданиями.

Пользователи, читая документы, помните, что прототип - это не конечный продукт. То, что вам не нравится или кажется непривлекательным, на самом деле может оказаться условными обозначениями, которые будут изменены в будущих итерациях. 

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

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

Не существует единого подхода к созданию прототипов, и понимание разницы между бросовым и инкрементным прототипом поможет вам стать лучшим тестировщиком.
Выброшенные прототипы являются доказательством концепции - они создаются быстро и отбрасываются в два раза быстрее. Они используются для демонстрации конкретной функции или предварительного подхода к проекту.
Для бросовых прототипов обратная связь должна быть сосредоточена на конкретных функциях, которые тестируются. Не стоит думать о том, как можно улучшить прототип, выходя за рамки его возможностей, поскольку велика вероятность того, что он будет отброшен после обработки обратной связи. 
Эволюционные прототипы - это непрерывный процесс: один и тот же прототип дорабатывается и расширяется с каждым циклом обратной связи. Поскольку вся работа ведется с одним и тем же прототипом, это экономит время и силы. На сегодняшний день это самый распространенный вид прототипирования.
Пользователи обращают внимание не только на сам прототип, но и на то, как он развивается с каждой итерацией. Попробуйте найти, где в проекте были применены ваши предыдущие отзывы, и проверьте, соответствует ли это тому, что вы хотели. 
При использовании инкрементальных прототипов конечный продукт разделяется на различные подсистемы. Прототип создается для каждой части проекта, и после тестирования и доработки всех прототипов они объединяются в конечный продукт.
Как и в случае с бросовыми прототипами, ваша роль здесь сфокусирована на предоставлении обратной связи по основной функциональности, которую вы тестируете. И снова, если вы не знаете, почему что-то отсутствует, проверьте документацию или спросите разработчика, возможно, то, что вы ожидали, на самом деле является частью другой подсистемы.

Прототипы - это способ общения между разработчиками и пользователями, ведь, как говорится, одно изображение стоит больше тысячи слов. В данном случае именно прототип является связующим звеном между вашим видением и реальной разработкой. 
Модель прототипа - это один из многих подходов к разработке программного обеспечения, который понимает, что пользователи являются неотъемлемой частью процесса, и их присутствие в курсе событий гарантирует более быстрый цикл разработки и лучший результат в конечном итоге.