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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы подписались на нашу рассылку
Спасибо!
Мы обещаем, что не будем спамить, все только самое
нужное и полезное для вашего развития.