Как составить техническое задание на сайт

Зачем вам ТЗ, даже короткое

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

Без него происходит знакомая история. Работа начинается, потом выясняется, что нужен ещё калькулятор и личный кабинет, сроки уезжают, и обе стороны считают себя правыми. Поэтому даже страница текста, написанная заранее, экономит больше, чем кажется.

Что обязательно включить

Минимальный набор блоков, который закрывает большую часть вопросов разработчика.

• 1Задача бизнеса: что должно измениться после запуска и по какому признаку вы поймёте, что сайт работает.
• 2Кто пользователь: кто приходит, с каким вопросом, что ему мешает принять решение.
• 3Структура: список страниц или экранов, а для каждого перечень блоков своими словами.
• 4Функции: формы, калькуляторы, фильтры, поиск, авторизация, оплата. Для каждой опишите, что на входе и что на выходе.
• 5Интеграции: куда уходят заявки, обмен с 1С или CRM, платёжные системы, службы доставки.
• 6Контент: какие тексты, фотографии и документы есть, чего нет и кто это готовит.
• 7Технические условия: домен, хостинг, доступы, что переносится со старого сайта.
• 8Что в работу не входит: это избавляет от спора о реальных ожиданиях.

Какой уровень детализации нужен

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

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

Частые ошибки

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

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

Если писать ТЗ не хочется

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

Такое описание и становится рабочим ТЗ. Оно удобнее формального документа, потому что написано по вашей задаче, а не по шаблону, и к нему можно возвращаться при приёмке этапов. Разбор задачи и первая консультация бесплатны: форма на сайте, Telegram @inter1ark или почта vitoscarasel@gmail.com.