Техническое задание на сайт: образец в Word и генератор

Зачем техническое задание, если подрядчик «и так понял»

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

Что входит в ТЗ из генератора

Как сформулировать цели

Цель «красивый современный сайт» не поможет ни подрядчику, ни вам. Хорошая цель измерима и связана с бизнесом: «получать 100 заявок в месяц с сайта», «снизить число звонков с вопросом "сколько стоит" за счёт калькулятора», «продавать онлайн 20% ассортимента». Из целей вытекают приоритеты: если главное — заявки, то форма на каждом экране важнее анимаций; если продажи — важнее скорость каталога и удобство оплаты.

Функциональные и нефункциональные требования

Функциональные требования описывают, что сайт делает: принимает заявки, фильтрует каталог, принимает оплату. Нефункциональные — каким он должен быть: быстрым на мобильном, защищённым, доступным, работающим в нужных браузерах, с ежедневными резервными копиями. Именно нефункциональные требования чаще всего «подразумеваются» и не записываются, а потом оказывается, что сайт открывается 8 секунд на телефоне или хранит персональные данные на зарубежном сервере. Генератор предлагает типовой набор — снимите лишнее, но не пропускайте раздел.

Приёмка: как проверить, что сделано то, что заказано

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

Что должно перейти к вам после запуска

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

Частые ошибки в ТЗ

• Описание дизайна словами вместо референсов. «Стильно и лаконично» каждый понимает по-своему — приложите примеры.
• Нет ответственного со стороны заказчика: согласования идут через несколько человек, и решения меняются.
• Функции без сценариев: «личный кабинет» — это может быть и страница с заказами, и полноценный сервис.
• Забыли про перенос со старого сайта: без карты редиректов можно потерять позиции в поиске; об этом — статья редизайн без потери позиций.
• ТЗ написано один раз и не обновляется. Изменения по ходу проекта нужно вносить в документ и согласовывать.

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

Как формулировать требования

Плохо: «Удобный каталог». Хорошо: «Каталог с фильтрами по цене, размеру и материалу; фильтры работают без перезагрузки страницы; выбранные фильтры сохраняются в адресе, чтобы ссылкой можно было поделиться». Вторую формулировку можно оценить и проверить при приёмке.