Техническое задание, которое защищает заказчика, а не подрядчика

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

Поэтому главный вопрос к каждому пункту ТЗ: можно ли по нему однозначно сказать «сделано» или «не сделано»? Если нет — пункт бесполезен.

Формулировки, которые ничего не значат

Сравните.

«Сайт должен быстро загружаться» — не значит ничего. Быстро для кого, на каком соединении, какая страница?

«Главная страница отображает основное содержимое за 2,5 секунды на 4G-соединении» — проверяемо. Есть число, есть условия, есть способ измерить.

«Удобная админка» — не значит ничего.

«Контент-менеджер без участия разработчика добавляет услугу, меняет цену, загружает фотографии и публикует статью» — проверяемо. Садимся, делаем, смотрим.

«Современный адаптивный дизайн» — не значит ничего.

«Все страницы корректно отображаются при ширине экрана от 320 до 1920 пикселей, без горизонтальной прокрутки» — проверяемо.

Что должно быть в ТЗ

Перечень страниц и что на каждой

Не «раздел услуг», а список: страница списка услуг, страница отдельной услуги, что на ней есть — заголовок, описание, цена, форма, блок с похожими услугами.

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

Описание того, что человек делает, а не того, что есть на экране. «Посетитель находит услугу через поиск, открывает её, нажимает „Оставить заявку“, заполняет имя и телефон, получает подтверждение на экране; заявка приходит на почту и в CRM».

Сценарии ловят пропущенное лучше любых списков. Написав такой абзац, вы сразу спросите: а что если CRM недоступна? А что если телефон введён неверно?

Что происходит при ошибках

Самая пропускаемая часть. Форма не отправилась, файл слишком большой, оплата не прошла, сервис недоступен. Если это не описано, подрядчик решит сам — и почти наверняка не так, как вы бы хотели.

Границы

Явный список того, что не входит. Многоязычность, личный кабинет, мобильное приложение, наполнение контентом, перенос старых статей. Один абзац «в объём работ не входит…» предотвращает больше конфликтов, чем десять страниц описания того, что входит.

Интеграции — поимённо

Не «интеграция с CRM», а «Битрикс24, передача заявки методом crm.lead.add, поля: имя, телефон, почта, комментарий, источник». Без этого «интеграция» может оказаться письмом на почту.

Критерии приёмки

Отдельным разделом: список проверок, которые вы проведёте при сдаче. Подрядчик будет знать, к чему готовиться, и это в его же интересах.

Кто пишет ТЗ

Обычно подрядчик — у него есть опыт, и это отдельная оплачиваемая работа. Здесь и кроется конфликт интересов: автор документа склонен формулировать так, чтобы потом было проще сдать.

Отсюда два правила. Первое: ТЗ, написанное подрядчиком, читает кто-то на вашей стороне, кто будет этим пользоваться — маркетолог, контент-менеджер, руководитель отдела продаж. Второе: за каждую обтекаемую формулировку просите число или проверяемое условие.

Живой документ

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

Заведите правило: любое изменение оформляется письменно, хотя бы письмом с формулировкой «фиксируем: делаем так-то, срок сдвигается на столько-то». Этого достаточно, чтобы спустя полгода восстановить картину.