Плохое ТЗ — причина 80% конфликтов между заказчиком и разработчиком. «Я имел в виду другое», «Это не входило в стоимость», «Мы же договаривались» — всё это от того, что на старте не зафиксировали ожидания.
Хорошее ТЗ экономит деньги, нервы и время. Покажу как его написать, даже если вы далеки от технологий.
Зачем вообще нужно ТЗ
Техническое задание решает три задачи:
-
Фиксирует границы проекта. Что входит в работу, а что нет. Без этого разработчик делает одно, а заказчик ждёт другое.
-
Даёт основу для оценки стоимости. Чем точнее описан проект — тем точнее оценка. «Сделайте мне сайт» может стоить от 30 000 до 3 000 000 рублей. «Сделайте лендинг на 5 экранов с формой заявки и интеграцией с amoCRM» — это уже конкретная задача с понятной ценой.
-
Защищает обе стороны. Если разработчик сделал всё по ТЗ — заказчик не может предъявить претензии за отсутствие функций, которых в ТЗ не было. И наоборот.
Я видел проекты, которые разваливались из-за отсутствия ТЗ. И проекты, которые шли как по рельсам — потому что на старте потратили пару дней на документ.
Структура хорошего ТЗ
1. Описание проекта
Кратко: что это за продукт, для кого и зачем. Две-три строки.
Пример: «Веб-приложение для учёта бронирований в кальянной. Целевая аудитория — администраторы и менеджеры заведения. Цель — заменить бумажный журнал и уменьшить количество ошибок при бронировании.»
2. Функциональные требования
Самая важная часть. Список того, что система должна делать. Каждая функция — отдельным пунктом.
Пример:
- Администратор может создать бронь: дата, время, стол, имя гостя, телефон, количество человек
- Система показывает занятость столов на выбранную дату в виде сетки
- При создании брони гостю отправляется SMS-подтверждение
- За 2 часа до брони гостю отправляется напоминание
- Администратор может отменить бронь с указанием причины
Чем подробнее — тем лучше. Не стесняйтесь описывать очевидные вещи.
3. Нефункциональные требования
Это про то, как система должна работать:
- Скорость загрузки страницы — не более 2 секунд
- Поддержка мобильных устройств
- Одновременная работа до 10 пользователей
- Хранение данных за последние 2 года
4. Дизайн и интерфейс
Варианты от простого к сложному:
- Референсы. «Хочу как у вот этого сайта, но с нашими цветами». Это лучше, чем ничего.
- Вайрфреймы. Схематичные макеты экранов. Можно нарисовать на бумаге или в Figma.
- Готовый дизайн. Макеты в Figma от дизайнера. Идеальный вариант, но стоит дополнительных денег.
5. Интеграции
С какими сервисами должна работать система:
- CRM (какая именно)
- Платёжная система
- SMS-шлюз
- Бухгалтерия (1С, Моё дело)
- Мессенджеры (Telegram-бот, WhatsApp)
6. Сроки и этапы
Разбейте проект на этапы с промежуточными результатами:
- Этап 1 (2 недели): основной функционал бронирования
- Этап 2 (1 неделя): SMS-уведомления и напоминания
- Этап 3 (1 неделя): отчёты и аналитика
Промежуточные результаты позволяют контролировать процесс и вносить корректировки на ранних этапах.
7. Бюджет
Укажите бюджет или хотя бы вилку. Это помогает разработчику предложить решение, которое вписывается в ваши возможности. Бюджет 100 000 рублей и бюджет 1 000 000 рублей — это два разных проекта.
Частые ошибки
«Сделайте красиво». Красиво — это субъективно. Дайте конкретные референсы, укажите цвета, шрифты, стиль. Или наймите дизайнера.
Слишком много функций на старте. Не пытайтесь впихнуть в первую версию всё, что когда-либо может понадобиться. Начните с минимума, который решает основную задачу. Остальное — во второй версии.
Отсутствие приоритетов. Отметьте каждую функцию как «обязательно», «желательно» или «было бы здорово». Если бюджет или сроки поджимают — разработчик будет знать, что можно отложить.
Размытые формулировки. «Удобный личный кабинет» — это не требование. «Личный кабинет с возможностью просмотра истории заказов, изменения контактных данных и управления подпиской» — это требование.
Забыть про мобильные устройства. Половина трафика идёт с телефонов. Если не указать, что нужна адаптивная вёрстка — разработчик может сделать только десктопную версию.
Не указать, кто предоставляет контент. Тексты, фотографии, иконки — кто их готовит? Если заказчик — укажите сроки. Если разработчик — это дополнительная стоимость.
Шаблон ТЗ
Вот минимальный шаблон, который можно использовать для любого проекта:
1. ОБЩЕЕ ОПИСАНИЕ
- Название проекта
- Цель проекта
- Целевая аудитория
2. ФУНКЦИОНАЛ
2.1 Обязательные функции
- [список]
2.2 Желательные функции
- [список]
3. ДИЗАЙН
- Референсы: [ссылки]
- Фирменные цвета: [hex-коды]
- Логотип: [прилагается / нужно разработать]
4. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ
- Адаптивность: [да/нет]
- Браузеры: [список]
- Скорость загрузки: [требования]
5. ИНТЕГРАЦИИ
- [список сервисов]
6. КОНТЕНТ
- Кто предоставляет: [заказчик / разработчик]
- Сроки предоставления: [даты]
7. СРОКИ И ЭТАПЫ
- Этап 1: [описание, срок]
- Этап 2: [описание, срок]
8. БЮДЖЕТ
- Общий бюджет / вилка: [сумма]
Совет от практика
Не бойтесь написать «я не знаю, как это лучше сделать — предложите варианты». Хороший разработчик оценит честность и предложит решение. Плохой — согласится на всё и потом не сделает.
И ещё: ТЗ — это живой документ. Он может и должен дополняться в процессе. Главное — фиксировать изменения письменно и согласовывать стоимость доработок до их начала.
Итог
Хорошее ТЗ — это инвестиция. Два-три дня на его подготовку сэкономят недели разработки и тысячи рублей на переделки. Используйте шаблон выше, описывайте функции конкретно, расставляйте приоритеты — и проект пойдёт значительно легче.