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

Традиционно в процессе проектирования составляется техническое задание и передается дизайнеру или разработчику. Те изучают требования и создают нечто, основываясь на своем восприятии спецификаций.

Теоретически техническое задание призвано снижать напрасные затраты времени. Главная цель – чтобы все занимались одной и той же задачей. Если все находятся на одном и том же этапе, напрасные затраты времени должны сократиться. Звучит потрясающе.

Правда, только в теории. На практике все иначе. Процесс проектирования и разработки на основе технического задания имеет ряд недостатков, которые и приводят к потерям времени:

1. Задание написано не для «тех» людей. Дизайнеры и разработчики редко участвуют в создании технического задания. Его пишет бизнес-аналитик или другой специалист, не имеющий достаточных технических знаний. Поэтому нередко приходится несколько раз переделывать задание.

2. Слишком много времени и усилий. Количество времени, потраченного на создание, рецензирование и пересмотр технических заданий, весьма значительно. При разработке сложных систем этот процесс иногда занимает 3–9 месяцев, а иногда и больше. За это время многое может измениться.

3. Неокончательная финальная версия. Теоретически техническое задание – окончательный документ. На практике же требования постоянно меняются, даже после того как их составление «завершено».

4. Неправильное понимание. Количество неправильно понятых мест в техническом задании объемом 60–200 страниц нередко значительно. Непонимание ведет к затратам времени на переделку и отсрочке выпуска продукта.

5. Несущественные детали. Техническое задание нередко заполнено описанием малозначимых или незначимых функциональных возможностей. На их создание и тестирование требуется время. Результат – потеря времени на их описание в техзадании, их внедрение и тестирование (часто такие возможности вообще впоследствии не используются).

6. Слишком позднее обнаружение ошибок. В техническом задании сложно обнаружить ошибки, пока система не начнет работать. Чем позже ошибка обнаружена, тем дороже ее исправление.

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

1. Решения принимаются правильными людьми. Дизайнеры и разработчики могут использовать свои опыт и знания и принимать грамотные решения.

2. Выживание наиболее приспособленных. Генерируется и испытывается множество идей, «выживают» сильнейшие из них.

3. Адаптивность. Прототипы могут быть доработаны с учетом новых возможностей и требований.

4. Снижение вероятности неправильного понимания. Прототип – визуальное, а иногда и физическое представление системы. Его сложнее понять неправильно, чем бумажный документ объемом 60–200 страниц. Снижение вероятности неправильного понимания сокращает количество переделок. Результат – меньшие затраты и более ранний выход на рынок.

5. Точность. При использовании прототипирования создаются продукты, более точно соответствующие желаемым характеристикам. Результат – меньшие потери при проектировании, разработке и переделках.

6. Раннее обнаружение несоответствий. Прототипирование помогает обнаружить несоответствия на ранних стадиях проектирования и разработки. Чем раньше будут выявлены проблемы, тем дешевле обойдется их исправление.

7. Снижение рисков. Прототипирование помогает снизить риски, уменьшая вероятность неправильного понимания и выявляя проблемы на ранних этапах.

Прототипирование не может решить всех проблем разработки по техническому заданию, но способно снизить уровень неэффективности и непроизводительных затрат.