Читать книгу Прототипирование. Практическое руководство - Тодд Варфел - Страница 13

Джонатан Бейкер-Бейтс – один из тех, кто на опыте убедился в выгодах прототипирования. Он трудится в британской консультационной компании, где используются традиционные методы. Группа разработчиков регулярно получает 200-страничные технические задания, по которым надо определить стоимость и создать продукт. Для этого их и принимают на работу. Компания, где трудится Джонатан, недавно начала использовать прототипирование. Теперь вместо 200-страничного документа они предоставляют высокоточный прототип и 16-страничное описание к нему.

После этих изменений в компании заметили ряд существенных улучшений:

• На разработку прототипа и 16-страничного дополнительного документа требуется меньше времени и сил, чем на написание 200-страничного техзадания.

• Точность оценки стоимости проекта и его продолжительности повысилась на 50%.

• Количество уточняющих запросов от команды разработчиков сократилось на 80%.

• Количество переделок и исправлений ошибок после выпуска продукта уменьшилось до 25% от уровня предыдущих проектов.

• Вся команда согласилась, что прототипирование проще, чем традиционная модель.

Практический пример: прототипирование при жестких бюджете и сроках

Джонатан Бейкер-Бейтс

У нас имелось меньше четырех месяцев на создание «неформального» сайта для одного из ведущих разработчиков компьютерных игр, сильная концепция визуального дизайна, ряд требований к контенту и функциональности и команда, разбирающаяся в CMS. Но бюджет был стесненным, а рамки проекта – неопределенными. К тому же мы в первый раз сотрудничали с этим клиентом, и он был не из тех, кто готов изучать длинные документы (которые нередко доходили до 200 страниц в похожих проектах). Требовалось заинтересовать участников и с самого начала четко определить, что мы собираемся сделать.

Мы решили, что с первого же дня будем разрабатывать функциональный HTML-прототип всего сайта на платформе Axure. Мы надеялись показать почти все необходимые требования с таким уровнем детализации, чтобы они были ясны всем и каждому, будь то СЕО[6] или интегратор CMS.

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

Мы сразу обратили внимание на то, что при создании прототипа отпала необходимость в длинных «вводных» описаниях и обсуждениях. Те, кто его видел, понимали, что мы старались сделать, за несколько минут, а не часов или дней. Поэтому мы могли перейти к обсуждению деталей. Это дало нам ряд выгод. Во-первых, точность оценок продолжительности работы оказалась очень высокой. Во-вторых, мы потратили на обсуждение проекта (в том числе возможных проблем) в целом примерно на 80% меньше времени, чем обычно. Наконец, интеграция и тестирование прошли гладко, а количество отклонений от спецификаций было примерно на 25% меньше, чем обычно. Бюджетные и временны́е ограничения никуда не делись, но прототип позволял быстро показать, как сгладить требования, чтобы получить согласие клиента.

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

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