Приходилось ли работать с прототипами
Что проверяют
Понимаете ли вы, зачем прототип нужен аналитику: это не картинка для красоты, а дешёвый способ проверить понимание задачи до того, как её начнут делать. Смотрят, умеете ли выбирать уровень детализации и доводить выводы до требований.
Как отвечать
Сначала уточните, о каких прототипах речь: набросок экранов, кликабельный макет, прототип отчёта или витрины данных, проверка интеграции на стенде. Затем разложите свой опыт по шагам:
- зачем понадобился прототип: спор о сценарии, разное понимание у заказчика и команды, риск дорогой переделки;
- какой уровень детализации выбрали. Чем раньше этап, тем грубее должен быть макет: серые прямоугольники обсуждают по делу, готовый дизайн обсуждают по цвету кнопок;
- как проверяли: давали человеку задачу и смотрели, справится ли он, а не спрашивали «нравится ли вам»;
- что изменилось по итогам и куда это записали.
Последний пункт важнее остальных. Прототип отвечает на вопрос и дальше устаревает, а договорённости живут в требованиях: сценарии, правила, состояния, обработка ошибок. Скажите прямо, где у вас проходила граница между макетом и постановкой задачи.
Где спотыкаются
Делают прототип слишком подробным слишком рано. Обсуждение сваливается на шрифты и отступы, логика и данные остаются неразобранными, а переделывать вылизанный макет команде уже жалко.
Второе: собрали обратную связь и не перенесли её в требования. Через месяц разработчик берёт устаревший макет как источник истины и аккуратно повторяет то, от чего отказались на демонстрации.
Третье: показывают прототип только заказчику и своей команде. Так проверяется мнение тех, кто и так согласен, а наводящий вопрос вида «удобно же» делает результат совсем предсказуемым.