Курица или яйцо: что раньше, прототипы или ТЗ?

Бывают ситуации, когда проект нужно подготовить в очень сжатые сроки, и совсем нет времени на изучение способов решения задачи и выбора из них самого оптимального. Команда просто бросается с головой в реализацию, полагаясь на опыт и интуицию. Обычно получается хорошо. Но остается ощущение, что можно сделать лучше, была бы только возможность остановиться и обдумать задачу.
Например, в нашей команде разработки интернет-решений не у всех и далеко не всегда было понимание, с чего начинать проектирование: с прототипов интерфейсов или технического задания. В обоих случаях есть сторонники и противники, есть плюсы и минусы. Не хватает только единого мнения.

Договоримся, что прототипы и ТЗ мы используем для того, чтобы:

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

Прототипы могут быть любого типа. ТЗ можно заменить на схемы с пояснениями. Здесь содержание важнее формы. Конечно, при условии, что формат документа устраивает и заказчика, и команду.

Сначала правильнее проработать прототипы

Как это будет. Рисуем. Обсуждаем. Перерисовываем и обсуждаем. Обсуждаем и дорисовываем. Согласовываем.
Результат, который мы видим. Много детальных прототипов. Все понимают, как будет выглядеть система. Всем нравится.
Результат на самом деле. Цели и задачи проекта нигде не зафиксированы, поэтому нет уверенности в том, что прототипы им соответствуют. Никто не помнит, какие ограничения и функции обсуждались при формировании прототипов. В любом случае их нет в формате, который можно передать заказчику или команде. И если автор прототипов внезапно решит улететь на Марс, то на расшифровку его работы уйдет много времени. И, скорее всего, после проработки описания окажется, что кто-то из команды иначе представлял себе действия, совершаемые по клику. Даже если прототип интерактивный, он не отражает внутреннюю логику.
Необходимые действия. РазработатьТЗ. Важно не просто описать то, что есть на прототипах, а полностью проработать функционал. Откорректировать прототипы. Причём это могут быть как незначительные правки, так и кардинальные изменения или отрисовка прототипа.

Или всё-таки сначала ТЗ?

Как это будет. Анализируем. Продумываем. Описываем. Обсуждаем. Анализируем. Дописываем и обсуждаем. Анализируем. Обсуждаем и переписываем. Согласовываем.
Результат, который мы видим. У нас есть ТЗ. Десятки или сотни страниц с детальным описанием.
Результат на самом деле. Автор документа знает, как всё должно быть. Знает, какие есть ограничения. Никто не представляет себе, как это описание будет выглядеть визуально. Вряд ли кто-то кроме автора прочитал и разобрался в документе, потому что сплошной текст без картинок уныл и трудно воспринимается.
Необходимые действия. Спроектировать прототипы. Упростить и дополнить ТЗ после прорисовки прототипов (хорошие прототипы выявят узкие места и логические ошибки в описании).

Что не так?

Неизбежные ошибки
В случае первоочередности прототипов мы упускаем детали, которые удается продумать только на этапе описания. Если на первом плане ТЗ, то мы не видим способы оптимизации интерфейса, которые так легко выявить на прототипе. Ошибки возникают потому, что мы слишком явно разделяем части одного целого.

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

Разница восприятия
Очень трудно прийти к единому видению проекта, ориентируясь только на текст или только на прототипы. Люди представляют себе разные образы, когда читают один тот же текст, и подразумевают разный функционал, глядя на одни и те же картинки.

Размывание процесса
При разделении проектирования прототипов и ТЗ на отдельные этапы, мы согласовываем один документ, затем второй, а затем вносим правки в первый, хотя он был уже согласован. У заказчика складывается впечатление, что договоренность не важна, а правки ТЗ и прототипов доступны на любом этапе проекта. Под слоганом “давайте изменим вот эту кнопку” происходит бесконечная итерация изменений.

Рост трудозатрат и снижение мотивации
Если наращивание описания и прототипов происходит постепенно, то правки вносить легче и быстрее, ведь править нужно меньший объём. Простая математика: 5 прототипов сделаны на основе главной страницы, значит, в случае правок главной страницы мы правим сразу 6 прототипов. В итоговом ТЗ нужно править 100 страниц, а в первоначальной концепции только 10 (все цифры, конечно, условные, но основную идею они отображают). Создание всеобъемлющих описаний, отрисовка сразу всех прототипов и их последующие правки – зря потраченное время. Но что гораздо хуже – возникает ощущение бесполезной работы, которую нужно переделывать от начала до конца снова и снова (пусть даже незначительно).

И прототипы, и ТЗ

Вспомним, для каких задач нам нужны прототипы и ТЗ:

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

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

Как это будет.
1. Проработка концепции и прототипов основных страниц. Анализируем. В ТЗ описываем концепцию проекта, указываем основные модули/блоки/функции, продумываем роли и указываем ограничения. Рисуем прототипы самых сложных и самых важных страниц. Обсуждаем. Как правило, по концепции у команды возникает много вопросов, а у заказчика – много пожеланий. Анализируем. Корректируем. Согласовываем.

Обсуждение с заказчиком – необязательно личная встреча (хотя это самый лучший способ). Чтобы получить быстрый ответ или сэкономить время, используйте Skype, режим редактирования в Word, электронная почта и прочие способы связи.

2. Детализация описания и прорисовка прототипов всех уникальных страниц. Анализируем. Расширяем описание в ТЗ. Технические аспекты описываем на высоком уровне. Рисуем прототипы всех уникальных страниц, то есть для похожих страниц, например, “Создание опроса” и “Редактирование опроса”, на данном этапе можно отрисовать только одну из них. Обсуждаем. Анализируем. Корректируем. Согласовываем.
3. Полное описание и прорисовка прототипов всех страниц. Анализируем. Фиксируем в ТЗ все нюансы по функционалу и технической стороне реализации. Рисуем все состояния элементов и страниц. Обсуждаем. Анализируем. Корректируем. Согласовываем.

Прототипы и ТЗ могут делать разные люди, если они при этом являются эффективной командой.

Результат, который мы видим. Все понимают, как будет выглядеть система. Все понимают, каким функционалом будет обладать система.
Результат на самом деле. Документы, с которыми удобно работать всем членам команды и заказчику. Всё отрисовано, всё описано.
Необходимые действия. Двигаться дальше по проекту.

Марина Демина, проектировщик ADV/web-engineering