Как составить грамотное ТЗ на разработку сайта

Если есть хоть малейшая вероятность того, что вас поймут неправильно, то вас обязательно поймут неправильно. Эта истина или закон подлости (называйте как угодно) срабатывает почти всегда, при чем в любой сфере деятельности. К созданию сайтов это тоже можно отнести. Приведем один пример, заказчик хотел социальную сеть, как Фейсбук, а в итоге получил форум для любителей спорта. Что-то явно пошло не так. И при этом виноват разработчик, ведь это он не угадал хотелку заказчика. Чтобы не было никаких проблем, нужно правильно и грамотно составлять техническое задание (ТЗ). Вот как раз об этом мы сейчас и поговорим.

Что такое техническое задание

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

Зачем составлять ТЗ на сайт

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

Зачем же нужно это задание? Все просто. Оно упрощает жизнь заказчику, потому что: 

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

Говоря об исполнителе, то:

• дает ему четкое понимание главных задач;
• некая страховка от выполнения несогласованных задач.

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

Как правильно составить ТЗ?

Просто написать на листке бумаги три пункта — этого мало. Помните, что чем подробнее написано техническое задание, тем лучше. И так, с чего же должно состоять грамотное и правильное ТЗ?

Техническое задание составляет разработчик

Хорошее ТЗ может составить только исполнитель (разработчик или проект-менеджер). Очевидно, что именно он больше всех понимает суть создания сайта. Владельцу бизнеса просто нужен готовый проект и ему наверное не так важно, что будет написано в техзадании. Ему нужен результат. Итог таков: составляет ТЗ разработчик, а заказчик просто одобряет. Но при этом, заказчик непосредственно участвует в процессе для: 

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

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

Писать нужно без двусмысленностей

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

Избегайте размытых формулировок: 

• сайт должен быть удобным — удобным для кого?
• на ресурсе должен быть качественный контент — качественный это какой?
• проект должен нравиться заказчику — а если он встал не с той ноги? 

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

• ресурс должен быстро загружаться — каждая страница сайта должна иметь минимум 80 баллов в Google PageSpeed Insights;
• на главной странице должны быть списки статей — вывод последних 4-х статей.

Укажите информацию о компании

Важно, чтобы каждый член команды понимал, чем занимается компания клиента и кто ее ЦА. Чтобы не путаться в проектах, сразу прописывайте все в ТЗ. 

Также пропишите и цель проекта, чтобы в итоге не получить блог вместо новостного проекта. 

Разъясните сложные термины

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

Например, не каждый знает, что такое СМS — движок на котором делается сайт, система управления им. 

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

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

Распишите требования к работе сайта

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

Создайте структуру сайта

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

• разработчик;
• сеошник;
• маркетолог и др.

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

Можно наглядно нарисовать блок-схему. Таким образом всем будет все понятно и доступно. Структура — это фундамент. Помните про это. 

Объясните содержание страниц

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

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

Распишите варианты использования сайта

Заказчики очень любят выделяться. Они могут поставить сложную задачу для разработчика по созданию ресурса с нестандартным интерфейсом. В таком случае показать одну структуру страниц недостаточно. Все должны понимать (клиент и все исполнители) как посетитель будет пользоваться готовым сайтом. Для такой задачи подходит простой сценарий: 

“действие пользователя… — … ответ сайта…— …— …результат”

Рассмотрим на примере. Посетитель интернет-магазина решил оформить заказ. Он нажимает на кнопку “Заказать”— сайт открывает простую форму заказа —  пользователь вводит необходимые данные (номер телефона, Ф.И.О. и пр.) и нажимает “Ок” —  сайт принимает заявку и выводит сообщение “Заказ оформлен” — на электронный адрес менеджера приходит письмо с контактными данными заказчика. 

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

Определитесь с контентом

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

То, что тексты должны быть уникальны — это да. Но важно прописать все четко, в деталях. Обязательно отметить и сервисы на которых тексты будут проверяться. Опять же, фраз “качественный текст”, “полезный для ЦА” тоже нужно избегать, так как конкретики здесь ноль.

Говоря о статьях, то существуют отдельные правила по составлению ТЗ для авторов статей. 

Опишите дизайн

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

Вместо вывода: структура техзадания

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

Каждое техническое задание должно иметь следующую структуру:

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

Вопросы и ответы

Какие ключевые разделы должны входить в ТЗ для разработки сайта?

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

Каким образом оценить успешность выполненного проекта на основе ТЗ? 

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

Что такое принцип “SMART” и как он применяется к ТЗ?

Принцип “SMART” означает, что цели и задачи в ТЗ должны быть конкретными (Specific), измеримыми (Measurable), достижимыми (Achievable), релевантными (Relevant) и ограниченными по времени (Time-bound).