Пользовательские истории. Искусство гибкой разработки ПО (Паттон) - страница 133
Я думаю, в кино эти эскизы используются для того, чтобы более тщательно обдумать будущий фильм. Как инвестор я хотел бы, чтобы можно было заранее подсчитать, сколько площадок и павильонов нужно для съемки и как они должны выглядеть. Необходимо также знать, какие потребуются декорации, реквизит и спецэффекты. Словом, мне нужны были бы сценарий, раскадровка и множество других деталей, на которых базируются построение плана и оценка затрат. Имея эти данные, можно запланировать бюджет и временной график съемок фильма.
Вот какие сведения вы должны получить, прежде чем приступите к реализации своего решения.
Дэвид Хассман, DevJam
Многие люди излишне усложняют процесс исследования, а он может быть очень простым и при этом вполне эффективным. Оставьте в стороне воображаемую жесткость требований и выделите время на исследование идей с помощью примеров и маршрутов пользователей, как говорится в приведенном далее руководстве.
Следуйте простому плану.
1. Предложите идею для исследования.
2. Выберите людей, которым, по вашему мнению, будет выгодна реализация этой идеи.
3. Сделайте подборку примеров того, как эти люди используют данную идею.
4. С помощью этих примеров составьте карту и маршруты, которые, по вашему мнению, понадобятся.
Помните, что, как автор, вы несете ответственность за создание адекватного пользовательского взаимодействия, а не просто новых функциональностей.
Идеи не обязаны быть гениальными. Да, вы хотите создать великолепный продукт, но зачастую самые блестящие идеи не срабатывают как надо, в то время как полезность других, не вызывающих такого восхищения поначалу, раскрывается, когда их рассматривают в контексте применения для выполнения определенной задачи.
Выбор «пассажиров» не отбор космонавтов. Не стоит чересчур усложнять отбор целевой аудитории. Если вы не уверены, с чего начать, просто составьте список пользователей, которым, по вашим предположениям, будут полезны ваши идеи. Дополните их образы, чтобы они долго оставались живыми и реальными в сознании членов команды разработки. Поработав с ними некоторое время, выберите какой-то конкретный тип пользователя и не слишком волнуйтесь о правильности решения. Будьте готовы извлекать уроки из исследований и не беспокойтесь о том, верен ваш выбор или нет, – скорее всего, нет.
Составьте обширный перечень примеров. Именно здесь многие люди теряют контроль над собой и лезут в дебри. Начните с самого простого, очевидного примера, чем конкретней он будет, тем лучше. Затем переходите к примерам посложнее и не бойтесь поднимать планку высоко. Создавая набор ограничений, вы не даете никаких гарантий. Но чем сложнее пример, тем конкретнее он должен быть. Если вы не уверены в необходимом уровне конкретики, трансформируйте рабочий пример в тест – это на шаг приблизит вас к автоматизированной валидации.