Сегодня мы хотели бы поговорить о техническом задании (техзадание, ТЗ). И это непростая тема для разговора. С одной стороны, все понимают, что ТЗ, конечно же, нужно, но с другой — этим словосочетанием порой называют и произвольный документ из пары страничек, где как придётся перечислены «хотелки» заказчика, и тяжеленный толмуд, написанный по ГОСТу (этот вариант ещё хуже, по моему скромному мнению).
Так что начнем с самого начала — с определения:
Техническое задание — это документ, детально описывающий проектируемый сайт, а именно: сценарии его применения, функциональность и внешний вид.
И порядок должен быть именно таким. В процессе чтения вы поймёте почему я заостряю на этом внимание.
Работы по подготовке техзадания мы называем проектированием, а сам документ — это всего лишь результат проектирования, а не самоцель.
Из каких же пунктов состоит качественное ТЗ:
1.Бизнес-задачи проекта
Никто не заказывает разработку сайта просто так. Как правило, с помощью сайта хотят решить какие-то бизнес-задачи. Но часто заказчику кажется, что эти задачи должны быть очевидны исполнителю, а это не так. Не жалейте времени на формализацию задач и обсуждение их с исполнителем. Это один из самых важных этапов подготовки ТЗ.
Очень важный момент: бизнес-задачи должны быть измеримыми, иначе это не задачи, а пожелания. Если вы пишите в задачи «повышение узнаваемости бренда компании», то будьте любезны так же написать — как вы будете это измерять. Иначе это пустой звук, не более того.
Почему это так важно. Дело в том, что на основе измеряемых бизнес-задач можно выработать KPI (ключевые показатели эффективности) сайта, и по ним определять — хорошо сайт работает или нет, надо ли награждать достойных или стоит наказывать нерадивых. На основании же неизмеряемых бизнес-задач ничего сделать нельзя. Можно только гадать — работает сайт на бизнес или нет.
2.Описание целевых аудиторий сайта
Кто будет пользоваться проектируемым сайтом? Что у этих людей общего? Что отличает одну группу от другой? И забудьте про «мужчины и женщины в возрасте от 25 до 45 лет». Это не помогает, правда. Опишите как можно более подробно тех людей, для которых разрабатывается сайт. Да-да, сайт разрабатывается не для заказчика, как бы это странно не звучало.
3.Описание ключевых ролей — персонажей
После описания целевых аудиторий сайта мы должны объединить характерные отличительные особенности каждой целевой аудитории в своего персонажа — предполагаемого пользователя, для которого, собственно, и создаётся сайт.
Персонаж обладает своей историей, в которой описываются контекст использования сайта (в какой ситуации он попал на сайт, откуда он пришёл, что уже знает о компании)и мотивация пользователя — чего он хочет получить от использования сайта?
Персонажи определяют необходимый функционал (что сайт должен сделать, чтобы удовлетворить потребности пользователя) и интерфейс взаимодействия с ним (как сайт должен выполнять свои функции, чтобы удовлетворить потребности пользователя).
Каждый отдельный персонаж — это отдельный сценарий использования сайта, а возможно, что и свой интерфейс взаимодействия с сайтом (экран, страница, раздел). Поэтому не плодите без необходимости лишних персонажей, это только путает разработчиков.
Для чего нужны персонажи. Человеку проще представить себе пусть вымышленного, но конкретного пользователя, чем какого-то абстрактного «пользователя сайта». Персонажи помогают всем участникам проекта лучше понять — для кого и для чего создаётся сайт.
4.Юзер-стори (user story)
Это сценарии, которые описывают все возможные ситуации использования сайта, начиная от самого важного — первой сессии, когда пользователь впервые знакомится с интерфейсом сайта, и заканчивая решением задач каждого персонажа.
Сценарии детально описывают каждый шаг персонажа на пути к достижению своей цели. Весь этот путь называется — user experience (опыт взаимодействия). Это то, что останется с пользователем после общения с вашим сайтом: будет ли он доволен, получит ли то, что хотел и даже больше, или же — нет, и тогда вы потеряете потенциального клиента. Поэтому это так важно.
5.Функционал сайта
Пользовательские сценарии определяют функционал сайта, который фиксируется в виде списка. В дальнейшем этот список будет использоваться программистами для расстановки приоритетов задачам при разработке сайта, чтобы быстрее доводить до рабочего состояния полноценные функции сайта, а не абстрактные программные блоки.
Именно так: сначала мы описываем, что делают с сайтом персонажи, а потом мы определяем исходя из этого, какой у сайта должен быть функционал. Не наоборот. Если мы видим, что ни у одного персонажа нет потребности в какой-то функции, то ее и не должно быть. Если мы начинаем за уши притягивать персонажей к функционалу, то можно смело бросать все работы по проектированию — от них все равно не будет никакого толка.
6.Требования к интерфейсу и внешнему виду
Так же пользовательские сценарии в большой степени определяют интерфейс проектируемого сайта. Для того, чтобы заказчику (да и остальным участникам проектной команды) было проще представить себе проектируемый сайт, мы используем динамические прототипы, схематично изображающие расположение всех основных элементов каждой страницы и позволяющие имитировать работу будущего сайта — можно нажимать на функциональные кнопки и перемещаться между страницами. Иногда мы используем статические прототипы, если функционал у сайта простой и всем и так понятно, как это будет работать.
Требования же к визуальному оформлению сайта фиксируются в виде мудборда — большого коллажа, на котором располагаются примеры графических решений, которым должен соответствовать разрабатываемый сайт. Чаще всего всего это примеры, взятые с других сайтов или из смежных областей (иллюстрации или промышленный дизайн, например). При этом стоит так же помнить, что визуальное оформление ни в коем случае не должно мешать пользователю решать свои задачи.
Лучший дизайн — это когда пользователь не видит никакого «дизайна» и просто получает удовольствие от процесса общения с сайтом.
Если у заказчика есть брендбук или гайдлайн, то требование им следовать так же фиксируется в этом пункте ТЗ.
7.Технические ограничения
В данном разделе фиксируются возможные технические ограничения в разработке сайта — используемые технологии, правила взаимодействия с внешними системами и сервисами и прочие влияющие на разработку сайта вопросы.
Одними из самых важных и часто встречающихся ограничений являются интеграции с внешними сервисами. Это может быть учетное ПО на стороне заказчика или некий внешний веб-сервис (например, сервер почтовых рассылок или система эквайринга). Как правило, именно при интеграции возникает большинство непредвиденных проблем. Поэтому важно на самых ранних этапах обсуждать такие технические детали — с чем придётся интегрироваться, если API, есть ли к нему документация.
Так же к техническим ограничениям можно отнести планы на развитие и масштабирование проекта. Функционал, который пока только планируется, не стоит описывать подробно, но наметить пути развития лучше уже сейчас. Чтобы в будущем избежать возможных проблем.
Мы рекомендуем подходить к подготовке техзадания со всей ответственностью, но не доходить до фанатизма и не зарываться в документацию с головой и надолго. В бизнесе все меняется очень быстро, поэтому нужно двигаться быстро, быть гибкими и готовыми к возможным изменениям.
Если вы сконцентрируетесь при подготовке ТЗ на действительно важных вещах и не будете зарываться в детали, то этот документ поможет вам запустить действительно успешный интернет-проект, который будет не только радовать глаз, но и приносить реальную пользу бизнесу.
