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