Как грамотно составить ТЗ на разработку сайта
Чек-лист по созданию ТЗ для разработки сайта.
Составление технического задания (ТЗ) — один из самых важных этапов подготовки к разработке сайта.
От того, насколько грамотно оно будет составлено, зависят не только дальнейшие отношения заказчика и исполнителя, но и результат их сотрудничества.
По сути ТЗ = документ с требованиями к сайту.
Перечень целей проекта, где указана суть разработки, сформированы требования к дизайну, функциям, структуре, системе управления сайтом, программному обеспечению и т.д.
Если вы составили четко и подробно — исполнителю будут понятны поставленные задачи и дальнейший план действий. Не постарались и сделали «от балды» или не сделали вовсе — результат будет соответствующий.
Польза от технического задания очевидна. Заказчик уже во время процесса составления:
- понимает, за что он будет платить деньги;
- оценивает компетентность исполнителя;
- узнает стоимость разработки.
Исполнитель:
- понимает, что хочет заказчик;
- получает некий «справочник», на который опирается во время разработки;
- страхуется от внезапных «хотелок» заказчика, когда проект почти готов;
- облегчает и ускоряет работу за счёт понятной структуры.
Можно ли получить хороший результат без ТЗ? Скорее нет.
Потому что работа без него может обернуться для заказчика дополнительными финансовыми расходами, срывом сроков или еще хуже — необходимостью переделывать готовый сайт.
Как правильно составить ТЗ
Создание технического задания включает в себя несколько обязательных этапов.
Чтобы не упустить важные моменты, сохраните нашу шпаргалку:
Целься
Путь без цели — время в воду. Все, кто работает над заданием, должны чётко понимать, для кого и с какой целью оно вообще делается.
Нужно показать разработчикам бизнес-логику проекта, рассказать каким функциям должен отвечать готовый сайт, и какие пользователи входят в его целевую аудиторию.
Поясняй
В задании должны быть описаны все функциональные требования. Обговорите и составьте структуру сайта, опишите элементы каждой страницы, нарисуйте примерные схемы. Здорово, если есть возможность найти и показать подходящие референсы.
Совет: для этого можно собрать исполнителей – маркетологов, сеошников, разработчиков. Это поможет решить, какие страницы нужны на сайте и как на них можно будет попасть.
Уточняй
Определите с разработчиком стек технологий для вашего проекта. В тексте задания должны быть указаны инструменты, движки, фреймворки и библиотеки. Также на этом этапе нужно уточнить требования к серверу и хостингу.
Определяй
Фиксируйте сроки исполнения и требования к сервису, на основании которых будет приниматься проект.
ВАЖНО: избегайте субъективных оценочных суждений. Если в задании есть места, которые можно расшифровать по-разному — с большой вероятностью их поймут неправильно.
Вместо «красивый», «модный», «лаконичный» понятнее звучит конкретное требование «Нам нужен сайт в фирменной цветовой гамме». Не бойтесь написать больше: в техническом задании это только на руку.
Как это делаем мы
Все технические задания в нашей компании уникальны. Мы отталкиваемся от потребностей клиента, анализируем имеющуюся бизнес-модель, а затем выстраиваем картинку того, что от нас хотят получить.
Так мы выделяем два вида клиентов:
Первые — компании, которые приходят за решением конкретной проблемы, например, оптимизация работы сотрудников или доработка нового функционала интернет-магазина.
Вторые — компании, которые приходят за реализацией масштабного проекта. Обычно это стартапы, где необходимо определить не только степень трудозатрат разработки, но и помочь с приоритезацией бэклога.
Если заказчик компетентный и уже знает, что такое разработка и четко может перечислить требования, то техническое задание составляет он, но при нашем участии. Это не значит, что мы стоим над душой, пока продакт-оунер сформирует документ. Тут идет речь о командной работе. Мы объясняем, что и зачем важно сделать, показываем примеры реализации, обсуждаем их с клиентом.
Но есть и заказчики, которые пока не вникали в процессы разработки. Под них мы прорабатываем первичную документацию, согласовываем ее и через несколько итераций создаем уже полный пакет документов.
Подтверждение качества наших ТЗ = кейсы. Кстати, в телеге поделились скринкастами одного из проектов, который мы разрабатывали с нуля. Заглядывайте, а если появились вопросы — пишите.
Спасибо, описано доступным языком. Хотелось бы уточнить, является ли ТЗ для вас единственным проектным документом или уточняющие спецификации в процессе проектирования все же тоже готовите? У нас, как правило, ТЗ приходит от Заказчика и очень верхнеуровневое. Если мы понимаем, что нужно более подробное ТЗ, то стараемся заключить отдельный договор на написание, т.к. с данным ТЗ заказчик может впоследствии обратиться в другую компанию и трудозатраты на "помощь" хотелось бы возместить. При этом, в любом случае, в ТЗ все детали невозможно учесть, поэтому уже на проекте стараемся писать более подробные проектные решения/спецификации.
У нас основной упор на долгосрочное сотрудничество и большие проекты, но да мы используем дополнительную спецификацию, которая применима на небольшие проекты.
Например у нас ведётся расширенный бэклог с небольшими кейсами и приоритетами. Благодаря этому документу формируется спецификация работ на месяц, которая идёт в приложение к договору.
Помимо документации перед началом работ, активно используем выгрузки ответов из таск менеджеров, на ретро срезаем некоторые часы, которые по каким то причинам были потрачены зря, чтобы клиент платил за «эффективно потраченное время».
Четкое и понятное ТЗ, это идеализированная модель взаимодействия с заказчиками. Для того, чтобы написать хорошее техническое задание нужно хотя бы поверхностное понимание в этой области.
Часто на практике техническое задание не описывает все детали проекта, если даже оно объемное. Разработчик может добиваться от заказчика более конкретной информации, задавая уточняющие вопросы. Но это тоже полностью не спасает ситуацию, потому что разработчик не сможет угадать все требования заказчика к функционалу.
Если ТЗ совсем непонятное, тогда заказчик должен быть готов к срыву сроков и дополнительной оплате.
Думаю, что всегда возникают дополнительные требования во время разработки, просто важно их количество. Поэтому подрядчик всегда должен рассчитывать бюджет и сроки учитывая все риски.