Оставьте заявку
Мы свяжемся с вами, чтобы обсудить детали
Интернет-маркетинг

7 обязательных пунктов технического задания на разработку сайта

Сегодня мы хотели бы поговорить о техническом задании (техзадание, ТЗ). И это непростая тема для разговора. С одной стороны, все понимают, что ТЗ, конечно же, нужно, но с другой — этим словосочетанием порой называют и произвольный документ из пары страничек, где как придётся перечислены «хотелки» заказчика, и тяжеленный толмуд, написанный по ГОСТу (этот вариант ещё хуже, по моему скромному мнению).

Так что начнем с самого начала — с определения:

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

И порядок должен быть именно таким. В процессе чтения вы поймёте почему я заостряю на этом внимание.

Работы по подготовке техзадания мы называем проектированием, а сам документ — это всего лишь результат проектирования, а не самоцель.

Из каких же пунктов состоит качественное ТЗ:

1.Бизнес-задачи проекта

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

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

Почему это так важно. Дело в том, что на основе измеряемых бизнес-задач можно выработать KPI (ключевые показатели эффективности) сайта, и по ним определять — хорошо сайт работает или нет, надо ли награждать достойных или стоит наказывать нерадивых. На основании же неизмеряемых бизнес-задач ничего сделать нельзя. Можно только гадать — работает сайт на бизнес или нет.

2.Описание целевых аудиторий сайта

Кто будет пользоваться проектируемым сайтом? Что у этих людей общего? Что отличает одну группу от другой? И забудьте про «мужчины и женщины в возрасте от 25 до 45 лет». Это не помогает, правда. Опишите как можно более подробно тех людей, для которых разрабатывается сайт. Да-да, сайт разрабатывается не для заказчика, как бы это странно не звучало.

3.Описание ключевых ролей — персонажей

После описания целевых аудиторий сайта мы должны объединить характерные отличительные особенности каждой целевой аудитории в своего персонажа — предполагаемого пользователя, для которого, собственно, и создаётся сайт.

Персонаж обладает своей историей, в которой описываются контекст использования сайта (в какой ситуации он попал на сайт, откуда он пришёл, что уже знает о компании)и мотивация пользователя — чего он хочет получить от использования сайта?

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

Каждый отдельный персонаж — это отдельный сценарий использования сайта, а возможно, что и свой интерфейс взаимодействия с сайтом (экран, страница, раздел). Поэтому не плодите без необходимости лишних персонажей, это только путает разработчиков.

Для чего нужны персонажи. Человеку проще представить себе пусть вымышленного, но конкретного пользователя, чем какого-то абстрактного «пользователя сайта». Персонажи помогают всем участникам проекта лучше понять — для кого и для чего создаётся сайт.

4.Юзер-стори (user story)

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

Сценарии детально описывают каждый шаг персонажа на пути к достижению своей цели. Весь этот путь называется — user experience (опыт взаимодействия). Это то, что останется с пользователем после общения с вашим сайтом: будет ли он доволен, получит ли то, что хотел и даже больше, или же — нет, и тогда вы потеряете потенциального клиента. Поэтому это так важно.

5.Функционал сайта

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

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

6.Требования к интерфейсу и внешнему виду

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

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

Лучший дизайн — это когда пользователь не видит никакого «дизайна» и просто получает удовольствие от процесса общения с сайтом.

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

7.Технические ограничения

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

Одними из самых важных и часто встречающихся ограничений являются интеграции с внешними сервисами. Это может быть учетное ПО на стороне заказчика или некий внешний веб-сервис (например, сервер почтовых рассылок или система эквайринга). Как правило, именно при интеграции возникает большинство непредвиденных проблем. Поэтому важно на самых ранних этапах обсуждать такие технические детали — с чем придётся интегрироваться, если API, есть ли к нему документация.

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

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

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

 

12247939 1241412972551008 1579896837395524806 o
Автор: Константин Найчуков

Бывший директор по развитию Мэйк, ныне друг и внешний консультант по контекстной рекламе. Пообщаться с Константином можно в Facebook.

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