Как составить хорошее техническое задание на разработку сайта

Время чтения:10 минут

Если что-то сказанное вами можно неверно интерпретировать, то вас обязательно не так поймут. Эта особенность хорошо описана в Законе Мэрфи. Поэтому, когда вы обращаетесь в web-студию, то без понятного технического задания вряд ли можно получить то, что хочется. Разработчики не экстрасенсы – они не могут угадать желания клиента, поэтому зачастую тратят свое время и деньги заказчика впустую.
Чтобы такого не происходило, надо грамотно составлять ТЗ. В этой статье мы подробно разберем, что следует указывать, а также как не стоит писать техническое задание. Эта статья пригодится как самим веб-студиям, так и бизнесменам, которые обращаются к ним.

Зачем нужно ТЗ?

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

Для клиента – это:

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

Для исполнителя техническое задание также несет выгоду:

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

Кто составляет техзадание?

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

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

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

Как нужно писать техническое задание

Пишите однозначно и точно

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

плохой-дизайн-сайта.jpg
Кому-то такой дизайн нравится

Также в ТЗ надо исключить формулировки наподобие:

  • Сайт должен понравиться заказчику. А это будет зависеть от того, что заказчик с утра съел горькую кашу?
  • Сайт должен быть удобным. Для кого?
  • Сайт должен выдерживать большие нагрузки. А большие это какие? 10 тысяч? 100 тысяч? Миллион?
  • Качественный экспертный контент. А какие критерии экспертности?

Поэтому постарайтесь заменить все неоднозначности как можно более точными формулировками. Например:

Как не надо Как надо 
Сайт должен быстро грузиться Любая страница должна получить более 90 баллов в Google PageSpeed Insights
Сайт должен выдерживать большое количество пользователей  Сайт должен выдерживать 70 тысяч посетителей одновременно
На главной странице выводятся статьи На главной странице выводится список последних 8 опубликованных статей
Стильный и приятный интерфейс подписки Поле «Оставьте e-mail» и кнопка «Подписаться» с утвержденным дизайном

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

Общая информация

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

цели-и-задачи-сайта.jpg

Глоссарий терминов

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

термины-технического-задания.jpg
Рекомендуем писать пояснения в инфостиле

Описание инструментов и требований к хостингу

Нужно сразу решить на чем будет сделан сайт, какие будут движки и библиотеки. Заодно указываются требования к хостингу, чтобы не получилось такого, что вы делали на PHP, а у клиента сервер на .NET.

требования-к-web-серверу.jpg

Требования к работе сайта

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

требования-к-сайту.jpg

Структура сайта

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

структура-сайта.jpg

Наполнение каждой страницы

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

прототип-сайта.jpg

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

структура-сайта-с-разделами.jpg

Сценарий использования сайта

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

  • Действие пользователя.
  • Ответное действие сайта.
  • Результат.
порядок-оформления-работ.jpg Пример сценария

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

Контент

Заранее решите кто будет отвечать за наполнение контентом. Сделает ли разработчик все сразу без дополнительной платы; потребует ли он за тексты деньги или заказчик сам будет писать туда заголовки и статьи.

требования-к-контенту-и-наполнению-сайта.jpg Распишите, кто за какой контент отвечает

Критерии оценки качества текстов довольно разнятся. Есть объективные, наподобие воды, количества ключевых слов или повторов. А есть необъективные – наподобие красоты или стиля. Чтобы лучше понимать, что считать хорошим текстом, рекомендуем вам почитать посты про копирайтинг в наших группах в социальных сетях.

Описание дизайна

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

требования-к-дизайну-сайта.jpg

Дополнительные соглашения

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

порядок-оформления-работ.jpg

Резюме

Для каждого конкретного сайта структура может немного различаться. Какие-то пункты добавляться, а какие-то можно убрать (например, сценарии). Но в целом в каждом ТЗ на разработку сайта необходимо указывать:

  • Блок информации о компании, ЦА, цели и задачи сайта.
  • Расшифровку терминов.
  • Технические требования к верстке и работе сайта.
  • Указание инструментов и технологий, с помощью которых будут работать, а также список требований к хостингу.
  • Описание структуры сайта.
  • Эскизы страниц или описания элементов, которые там будут.
  • Список контента, который делает разработчик.

Связаться с нами

Нажимая на кнопку "Отправить" вы соглашаетесь с политикой обработки данных!