В начале было – техническое задание или дизайн?

22.01.2016

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

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

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

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

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

Структурируем техзадание

Само по себе ТЗ – это не продукт. Это образ будущего продукта, но образ максимально достоверный и однозначный. А потому здесь будет много страниц и масса подпунктов.

  1. Терминология, общие положения.
  2. Интерфейсы страниц.
  3. Компоненты страниц (блоки интерфейса).
  4. Требования к CMS сайта.
  5. Права, роли.
  6. Блок-схемы, функциональные описания для разработчиков.
  7. Возможные пользовательские сценарии, то есть функциональные описания для пользователей.
  8. Структура данных: перечень сущностей, атрибутов, предметов.

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

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

В результате возникает несоответствие – дизайн корректируется под требования клиента, и утверждается дизайн-макет, не имеющий ничего общего с ранее составленным и подписанным (и взятым за основу!) ТЗ. А ведь разработчик ориентировался именно на техзадание и уже спланировал свою рабочую нагрузку.

Метод решения спорных ситуаций

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

Второй метод – это увеличение сметы, включение в нее дополнительных затрат. Вроде бы и все логично, вот только заказчик вряд ли такую логику поймет.

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

Выход из ситуации – есть!

Если ТЗ так или иначе придется переписывать под дизайн, то почему бы и не сделать вначале дизайн? А дизайнер будет работать по прототипам! Ведь документация гораздо менее «мобильна» по сравнению с дизайном – легче изменить картинку, нежели формулировать юридически и технически грамотным языком очередные пункты «руководства к действию». Кроме того, визуализация избавляет от неточностей восприятия.

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

Преимущества очевидны

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

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

С прототипами удобнее работать и проектировщикам, и клиенту. Ведь дизайнер получает для работы картинки, понятные его восприятию, а клиент имеет возможность однозначно оценить предварительный «макет», а не углубляться в чтение многотомника из тысяч букв. Таким образом исключается риск разных ожиданий от продукта у клиента и компании-разработчика.

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

Последнее в нашем блоге