Гибкое прототипирование для гибкой разработки

Хорошие требования описывают использование продукта. Но как сделать хорошие требования? Как учесть все, что требуется пользователю при работе? Как не сделать продукт, выполняющий задачи наполовину? И как добиться единого понимания между заказчиком, дизайнером и разработчиками? Ведь мы же знаем, что большинство продуктовых решений так или иначе будут приняты уже в ходе разработки… Для написания кода есть отличная практика – TDD. Мы пишем тесты, а потом пишем код. И пишем его до ровно до тех пор, пока тесты не начинают отрабатывать корректно. Можно ли что-либо подобное проделать с требованиями?

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