Проекты срываются не потому, что кто-то плохо программирует. Они срываются потому, что в середине работы выясняется: заказчик имел в виду одно, подрядчик услышал другое, и оба уверены, что договаривались именно об этом. Техническое задание — это не бюрократия, а зафиксированный список решений, которые иначе будут приниматься на ходу и каждый раз в чью-то пользу.
Чем ТЗ отличается от договора
Договор отвечает на вопросы «кто кому и сколько»: сроки, оплата, ответственность, права на результат. Что должно быть в договоре, мы разбирали отдельно. ТЗ отвечает на другой вопрос — что именно будет сделано, и настолько подробно, чтобы по нему можно было проверить результат.
Практическое следствие: ТЗ почти всегда является приложением к договору, и ссылается договор именно на него. Если в договоре написано «разработка сайта», а приложения нет, предмет договора не определён — и спорить о том, входила ли интеграция с учётом в стоимость, бессмысленно с обеих сторон.
Хорошее ТЗ — это документ, по которому разные исполнители сделают примерно одинаковый результат. Если по тексту можно сделать и так, и втрое дешевле, это не ТЗ, а описание пожеланий.
Чем ТЗ не является
- Не описанием дизайна. Дизайн фиксируется макетами, и они становятся приложением наравне с текстом
- Не руководством по разработке: выбор фреймворка, структуры базы и способа сборки — ответственность исполнителя, а не заказчика
- Не пересказом сайта конкурента. Ссылка «сделать как у них» не говорит ничего о том, что именно понравилось: структура, подача, скорость или подбор товара
- Не набором общих требований вроде «современный, удобный, быстрый». Эти слова невозможно проверить, поэтому они не требования
- Не документом на сто страниц ради объёма: ТЗ на небольшой сайт укладывается в десять, и это нормально
Границы: что входит и что не входит
Раздел, который экономит больше всего нервов, и при этом его чаще всего нет. Перечислить, что входит, недостаточно — нужен явный список того, что не входит, потому что именно оттуда берутся конфликты.
- Наполнение каталога: кто переносит товары, в каком количестве и из какого источника. Перенос трёх тысяч позиций руками — это отдельная работа и отдельные деньги
- Тексты страниц: пишет заказчик, пишет подрядчик, или берутся с текущего сайта как есть
- Фотографии и их обработка: съёмка, покупка стоков, удаление фона
- Регистрация домена, оплата хостинга, лицензии платформы и модулей — на кого оформляются и кто платит
- Настройка почты для домена, подключение телефонии, установка чата
- Реклама, SEO, ведение после запуска — отдельные услуги, которые в разработку не входят, если не написано обратное
- Мобильное приложение, личный кабинет, многоязычность — то, о чём упомянули голосом на первой встрече и не упомянули в документе
Формулировка «не входит» не означает отказ. Она означает, что это делается отдельно и считается отдельно, — и лучше узнать об этом на этапе сметы, чем за неделю до запуска. Как складывается стоимость по этапам, видно в разборе цены интернет-магазина.
Типы страниц вместо количества страниц
Считать страницы бессмысленно: тысяча карточек товара делается один раз как шаблон, а пять уникальных страниц с разной вёрсткой — это пять раз работы. Поэтому в ТЗ перечисляются типы, а не единицы.
- Для каждого типа: какие блоки на странице, откуда берутся данные, что происходит при пустых данных
- Отдельно — состояния: загрузка, пустой результат поиска, товар снят с продажи, ошибка оплаты
- Отдельно — страницы, которые не видно в меню, но без которых не обойтись: 404, результаты поиска, страница благодарности, политика обработки данных
- Какие типы страниц будут в макетах, а какие собираются из уже отрисованных блоков без отдельного дизайна
- Какие страницы заказчик сможет создавать сам в конструкторе блоков, а какие верстаются разработчиком
Последний пункт определяет, сколько заказчик сможет делать самостоятельно после сдачи. Это решение про деньги в долгую: универсальный редактор блоков дороже на старте и дешевле в эксплуатации.
Сущности и поля — самая полезная часть
Таблица из трёх колонок, которая стоит половины документа: сущность, поле, тип и обязательность. Товар, категория, бренд, заявка, статья, отзыв, сотрудник — у каждого свой набор полей.
- Тип поля: строка, число, дата, список значений, ссылка на другую сущность, файл. От этого зависит и интерфейс, и структура базы
- Обязательность и значение по умолчанию: что делать, если у товара нет цены или картинки
- Откуда поле заполняется: руками в админке, приходит из учётной системы или вычисляется
- Что происходит при удалении связанной сущности: удалить категорию с товарами внутри — запретить или перенести
- Ограничения: длина текста, допустимые форматы файлов, максимальный размер загрузки
Обязательность и источник заполнения — не формальность. Поле, которое приходит из учёта, нельзя давать редактировать в админке: правка затрётся при следующем обмене, и это станет багом, о котором будут спорить.
Роли и права
Даже на простом сайте ролей минимум две: администратор и контент-менеджер. На магазине добавляется менеджер заказов, иногда — оптовый покупатель с особыми ценами. Для каждой роли описывается, что она видит и что может менять.
- Кто может менять цены и видеть персональные данные покупателей — это вопрос не удобства, а ответственности
- Кто может удалять, а кто только скрывать: удаление карточки убивает страницу, которая уже в поиске
- Нужен ли журнал действий: кто и когда изменил цену. Для магазина с несколькими менеджерами — почти всегда да
- Что происходит при увольнении сотрудника: доступ отключается или передаётся
- Двухфакторная аутентификация в админке: обязательна, рекомендуется или не нужна
Интеграции: четыре вопроса на каждую
Самая частая причина, по которой смета вырастает в середине проекта. Строка «интеграция с 1С» не описывает ничего: это может быть односторонняя выгрузка остатков раз в сутки, а может быть двусторонний обмен с заказами, контрагентами и дилерскими ценами — разница в разы.
- Направление: что едет на сайт, что едет обратно
- Состав данных по каждому направлению: товары, цены, остатки, заказы, статусы, покупатели
- Частота и способ запуска: по расписанию, по событию, по нажатию кнопки
- Источник правды по каждому полю: кто побеждает при расхождении — сайт или учёт
Четвёртый вопрос — главный, и ответ на него даёт не программист. Дальше добавляются технические подробности: протокол, формат, наличие тестового контура, кто предоставляет доступы и в какой срок. Отсутствие тестовой базы учёта — классическая причина, по которой интеграция стоит в плане, а сделать её нельзя. Как это выглядит внутри, видно на примере обмена с 1С и синхронизации с МойСклад.
Требования, которые нельзя проверить, — не требования
Нефункциональная часть обычно состоит из общих слов, а должна состоять из проверяемых условий. Формулировка «сайт должен быть быстрым» не проверяется. «Оценка производительности в выбранном инструменте не ниже установленного порога на указанных страницах при измерении в мобильном режиме» — проверяется.
- Браузеры и их версии: что считается поддерживаемым, а что отображается без гарантий
- Разрешения экрана для проверки адаптивности, включая самое узкое
- Порог скорости и инструмент, которым он измеряется, с указанием страниц для замера
- Ожидаемая нагрузка: сколько одновременных посетителей, есть ли пики от рассылок или рекламы
- Требования к доступности, если сайт будет использоваться людьми с ограничениями или если это требование отрасли
- Резервные копии: частота, глубина хранения, где лежат. Копия на том же сервере копией не считается
SEO-требования, которые дешевле заложить сразу
Переделывать это после запуска дорого, а на этапе проектирования почти ничего не стоит. Поэтому короткий список лучше включить в ТЗ даже тогда, когда продвижением будет заниматься кто-то другой.
- Человекопонятные адреса с возможностью задать их вручную для каждой страницы
- Поля заголовка, описания и первого заголовка страницы, редактируемые отдельно от названия
- Шаблоны метатегов с подстановкой для типовых страниц каталога
- Карта сайта, формируемая автоматически, и управляемый файл robots
- Механизм постраничных редиректов для переноса адресов со старого сайта
- Канонические адреса и управление индексацией страниц фильтров
- Микроразметка для товаров, хлебных крошек и организации
- Счётчики аналитики и цели на отправку форм — до запуска, а не после
Пятый пункт особенно важен при замене существующего сайта: без карты редиректов проект теряет накопленные позиции, и восстановление занимает месяцы. Если сайт уже есть, этот раздел пишется вместе с подрядчиком по продвижению, а не вместо него.
Критерии приёмки
Раздел, превращающий ТЗ из описания в инструмент. Он отвечает на вопрос, при каких условиях работа считается выполненной, — и формулируется так, чтобы ответ был «да» или «нет», без обсуждения.
- Перечень сценариев, которые должны работать: оформить заказ, оплатить, получить письмо, найти товар фильтром, отправить заявку
- Срок на проверку результата заказчиком и форма, в которой передаются замечания
- Что считается недоработкой по ТЗ, а что — новым пожеланием. Это граница между гарантией и платной доработкой
- Сколько кругов правок входит в этап и что происходит дальше
- Порядок приёмки по этапам: макеты, вёрстка, функциональность, наполнение — чтобы не принимать всё в последний день
Третий пункт — источник большинства конфликтов на финише. Если он описан, разговор занимает минуту: смотрим в документ. Если не описан, спор упирается в то, кто убедительнее говорит.
Окружения, доступы и передача
- Где собирается проект до запуска и закрыт ли этот адрес от индексации
- Кто владелец домена, хостинга и аккаунтов аналитики: регистрируются они на заказчика сразу, а не переоформляются потом
- Где лежит исходный код и получает ли заказчик к нему доступ
- Что передаётся при сдаче: доступы, макеты в исходном формате, инструкция по администрированию
- Что происходит после запуска: гарантийный срок, что в него входит и что в него не входит
Второй пункт стоит проверить до подписания: домен и хостинг, оформленные на подрядчика, — самая распространённая форма зависимости, и обнаруживается она в момент, когда с подрядчиком хочется расстаться. Остальные признаки, на которые стоит смотреть до начала работ, мы собрали в отдельном материале.
Как это выглядит в работе
ТЗ не пишется заказчиком в одиночку и не пишется подрядчиком в одиночку. Рабочая схема: заказчик описывает бизнес-задачу и ограничения, подрядчик превращает это в структуру, типы страниц, сущности и интеграции, а затем обе стороны проходят документ по разделам и спорят на этом этапе, а не в процессе разработки.
- Документ версионируется: у каждой правки видно дату и автора
- Изменения после согласования оформляются отдельно, с оценкой влияния на срок и стоимость
- Нерешённые вопросы остаются в документе явным списком, а не исчезают — иначе они всплывут в худший момент
- Макеты, карта сайта и таблица полей живут приложениями и обновляются вместе с текстом
Отдельно про сроки: написание ТЗ занимает время и часто оплачивается как самостоятельный этап. Это выглядит как лишний расход, пока не сравнить его с расходом на переделку половины проекта в середине. Второй вариант дороже всегда.
Мы начинаем проекты с такого документа и считаем смету по нему, а не по впечатлению от брифа: так видно и объём, и то, о чём стороны думали по-разному. Это касается и разработки сайтов в целом, и интернет-магазинов, где большая часть документа уходит на каталог и интеграции. Если проект начинается с визуальной части, структура и типы страниц фиксируются вместе с дизайном — макеты и ТЗ должны описывать одно и то же.
