За несколько лет работы в разработке мы получили сотни заявок на разработку сайта и разработку мобильного приложения. Примерно треть из них сопровождалась хоть каким-то техническим заданием. Из этой трети - только единицы были составлены так, что с ними можно было сразу идти в работу без дополнительных уточнений.
Это не претензия к клиентам. Большинство людей никогда не заказывали сайт или приложение раньше, и не обязаны знать, как правильно формулировать требования к разработчикам. Но это объясняет, почему так много проектов выходит за рамки бюджета, затягивается по срокам и заканчивается недовольством с обеих сторон.
Эта статья - практическое руководство для тех, кто хочет заказать разработку и хочет сделать это правильно. Мы разберём структуру ТЗ для сайта и мобильного приложения, покажем разницу между плохими и хорошими формулировками, и дадим шаблон, который можно взять за основу уже сейчас.
Зачем нужно ТЗ: реальные истории из практики
Прежде чем переходить к структуре, давайте разберём зачем вообще нужно ТЗ. Не в теории - а на конкретных историях.
История первая: "Сделайте как у конкурента"
Клиент - владелец небольшого туристического агентства в Бишкеке. Обратился с запросом: "Хотим сайт. Вот ссылка на конкурента - сделайте примерно так, только лучше и с нашим брендингом."
Мы начали работу. Сделали дизайн, согласовали, запустили первую версию. Клиент посмотрел и сказал: "Хм, не то. У конкурента есть калькулятор тура на главной - мы тоже хотим." Добавили калькулятор. "А ещё хотим, чтобы можно было онлайн бронировать, как на Booking." Это уже совсем другой функционал, он не входил в смету.
В итоге: три волны правок, полтора месяца дополнительной работы, бюджет вырос на 40% от изначального. Клиент был недоволен, что "всё стоит дороже чем договаривались". Мы были недовольны, что постоянно переделывали согласованные вещи. Проект запустили, но отношения остались напряжёнными.
Почему это произошло? Потому что "сделайте как у конкурента" - это не техническое задание. Это направление взгляда, но не карта маршрута. Каждый участник проекта додумал детали по-своему.
История вторая: разработчик сделал как понял
Другой случай. Владелец кафе заказал мобильное приложение для доставки. Проект вёлся удалённо, обсуждения шли в мессенджере. ТЗ не было - только голосовые сообщения и скриншоты.
Разработчик сделал приложение - функциональное, рабочее. Но клиент, увидев результат, оказался в растерянности: приложение работало правильно с технической точки зрения, но логика оформления заказа была выстроена иначе, чем он себе представлял. Клиент хотел, чтобы сначала выбирался адрес доставки, а потом показывалось меню с учётом зоны. Разработчик сделал наоборот: сначала выбор блюд, потом адрес.
Это не баг. Это две разные концепции пользовательского пути. Обе рабочие. Но клиент хотел одну, разработчик реализовал другую. Переделка потребовала пересмотра базовой архитектуры.
Конфликт разрешили, но и деньги, и время были потеряны. А ведь одна страница ТЗ с описанием пользовательских сценариев решила бы проблему до её возникновения.
История третья: проект в срок без переделок
И ещё одна история - позитивная. Клиент из строительной отрасли обратился с заявкой, к которой было приложено ТЗ на 12 страниц. В документе были: описание компании и её целевой аудитории, список страниц с описанием контента на каждой, технические требования (интеграция с 1С, два языка - русский и кыргызский), дизайн-референсы с пометками "нравится навигация" и "нравится цветовая схема", требования к скорости загрузки, и - что редкость - раздел с критериями приёмки.
Проект был сдан в срок. Итоговые правки заняли два дня вместо обычных двух-четырёх недель. Клиент получил именно то, что хотел. Разработчики работали без лишних уточнений.
Вывод из трёх историй один: ТЗ - это страховка для обеих сторон. Для клиента оно гарантирует, что разработчик сделает то, что нужно. Для разработчика - защиту от бесконечных "а мы думали по-другому". Без ТЗ каждый заполняет пробелы собственными предположениями. Чем больше пробелов - тем больше расхождений.
Что такое ТЗ и что это не ТЗ
Перед тем как перейти к структуре, важно договориться о понятиях.
Техническое задание - это документ, в котором зафиксированы конкретные требования к проекту: что должен делать сайт или приложение, для кого, в каких технических рамках, в какие сроки и за какой бюджет. Это не художественный текст и не маркетинговый бриф. Это рабочий документ, на основании которого разработчики составляют смету, планируют работу и принимают технические решения.
Что входит в ТЗ:
- конкретный перечень страниц и функций
- описание пользователей и их задач
- технические ограничения и требования
- требования к дизайну с обоснованием
- информация о контенте (кто готовит и когда)
- критерии приёмки готовой работы
Что не является ТЗ:
"Сделайте красиво" - это пожелание, не требование. У разработчика и клиента совершенно разные представления о красоте.
"Как Apple, только дешевле" - референс без объяснения что именно нравится и что из этого применимо к вашему проекту. Apple тратит на дизайн сотни миллионов долларов. Сказать "хочу как Apple" без уточнений означает дать команде полную свободу при нулевой ответственности.
"Вот три ссылки на сайты, которые мне нравятся" без объяснения что именно нравится и почему - тоже не ТЗ. Возможно, вам нравится анимация на первом сайте, навигация на втором и цветовая палитра на третьем. Без этих пояснений разработчик выберет сам - и почти гарантированно выберет не то.
Разница между брифом и ТЗ
Бриф - это первичный опросник, который студия присылает клиенту перед началом работы. Он помогает понять общее направление: тип проекта, бизнес-контекст, примерный бюджет, сроки. Бриф занимает одну-две страницы.
ТЗ - более детальный документ. Он пишется после брифа, часто совместно клиентом и студией, и служит основой для договора. Хорошее ТЗ для среднего сайта занимает 5-15 страниц, для сложного приложения - 20-40 страниц и больше.
Если вы пишете свой первый ТЗ - не пытайтесь сразу написать идеальный документ. Напишите то, что знаете. Хорошая студия поможет дополнить и уточнить остальное.
Структура ТЗ для сайта
Рассмотрим каждый раздел подробно - с примерами того, как писать правильно и как писать неправильно.
Общее описание проекта
Этот раздел отвечает на вопрос "что за проект и зачем он нужен".
Плохо: "Нужен сайт компании."
Что делать разработчику с этой информацией? Совершенно непонятно - какой компании, какого размера, с каким функционалом, для каких целей.
Хорошо: "Корпоративный сайт строительной компании OSOO 'Стройкомплекс'. Компания занимается возведением жилых домов и коммерческих объектов в Бишкеке и регионах Кыргызстана. Цель сайта - формирование доверия у корпоративных клиентов (заказчики крупных объектов, государственные структуры), демонстрация портфолио реализованных объектов, получение входящих заявок на строительство. Текущий сайт отсутствует, клиенты находят компанию через рекомендации и тендерные площадки."
Разница очевидна. Второй вариант сразу даёт разработчику понимание аудитории, тона, функциональных приоритетов.
Целевая аудитория
Без понимания аудитории невозможно принять правильные решения по дизайну, навигации и контенту.
Плохо: "Все, кто хочет купить наши товары."
Хорошо: "Основная аудитория - руководители малого и среднего бизнеса в Бишкеке, 30-50 лет, принимают решения о закупках. Дополнительная аудитория - снабженцы и тендерные специалисты, которые ищут поставщиков для конкретных проектов. Обе группы заходят с рабочих ноутбуков в рабочее время. Мобильный трафик ожидается не более 30%."
Это помогает разработчику расставить приоритеты: если основная аудитория работает с ноутбуков, можно уделить больше внимания десктопной версии, не жертвуя мобильной.
Функциональные требования
Это самый важный раздел ТЗ. Опишите каждую страницу сайта: что на ней находится, какие действия может совершить пользователь, какая информация обновляется и как часто.
Плохо: "Главная страница, страница услуг, контакты, блог."
Хорошо:
"Главная страница:
- Шапка с логотипом, навигацией (Услуги, Проекты, О компании, Контакты, блог), кнопка 'Получить консультацию'
- Hero-блок: заголовок, подзаголовок, кнопка CTA, фоновое фото/видео объекта компании
- Блок с ключевыми показателями (лет на рынке, сданных объектов, м2 построено) - цифры обновляются вручную через CMS
- Блок 'Услуги' - 4-6 карточек со ссылками на страницы услуг
- Блок 'Последние проекты' - 3 карточки из раздела 'Проекты', автоматически обновляется
- Блок 'Отзывы' - 3-4 отзыва, управляются через CMS
- Блок 'Партнёры' - логотипы, управляются через CMS
- Форма обратной связи (поля: имя, телефон, сообщение, согласие на обработку данных), отправка на email
- Футер с контактами, адресом, ссылками на соцсети"
Такое описание оставляет минимум пространства для интерпретаций.
Дизайн-требования
Дизайн - область с наибольшим количеством субъективных споров. Задача этого раздела - дать разработчику конкретные ориентиры.
Плохо: "Современный, минималистичный, профессиональный."
Каждый из этих эпитетов можно интерпретировать по-разному. "Современный" для одного человека - белый фон с большой типографикой, для другого - тёмная тема с градиентами.
Хорошо: "Стиль: строгий корпоративный, без ярких акцентов. Основной цвет - тёмно-синий (#1A2B4A), акцентный - оранжевый (#E87722), фон - белый/светло-серый.
Референсы:
- [ссылка 1]: нравится структура главной страницы и блок с цифрами-достижениями
- [ссылка 2]: нравится карточки проектов и то, как они раскрываются при нажатии
- [ссылка 3]: нравится типографика заголовков, НЕ нравится общий тёмный фон - у нас должно быть светлее
Логотип: есть, предоставим в векторе. Шрифты: предпочтений нет, на усмотрение дизайнера в рамках корпоративного стиля. Иконки: линейные, не filled."
Технические требования
Здесь фиксируются ограничения и требования, которые влияют на стоимость и архитектуру.
Плохо: "Сделайте хорошо, чтобы быстро грузилось."
Хорошо: "CMS: WordPress (клиент умеет работать с WordPress). Языки сайта: русский и кыргызский, переключатель в шапке. Интеграции:
- Yandex.Metrika и Google Analytics (обязательно)
- Форма обратной связи → Bitrix24 (у нас есть аккаунт)
- Онлайн-чат: интеграция с WhatsApp Business (бесплатное решение) Хостинг: предоставляем свой (VPS у Aknet). Требования к скорости: PageSpeed >= 70 на мобайле. SSL: обязательно. Robots.txt и sitemap.xml: сгенерировать при запуске."
Контент
Это раздел, о котором чаще всего забывают - и из-за этого проекты затягиваются.
Плохо: раздел отсутствует.
Хорошо: "Тексты: клиент готовит самостоятельно. Срок предоставления - не позднее чем за 2 недели до финального тестирования. Фото: клиент предоставляет фотографии объектов и команды. Количество - минимум 30 фото высокого разрешения. Видео: не планируется на первом этапе. Если тексты или фото не будут предоставлены в срок, дата запуска сдвигается на соответствующее количество рабочих дней."
SEO
Плохо: "Хотим быть первыми в Google."
Хорошо: "SEO-оптимизация: базовая. Семантическое ядро: студия собирает ядро по согласованному списку ключевых услуг (10-15 запросов на первом этапе). Мета-теги: студия заполняет title и description для всех страниц на основе ядра. Микроразметка: Schema.org для организации (название, адрес, телефон, сфера деятельности). Оптимизация изображений: webp-формат, alt-теги. Продвижение в поиске не входит в данный проект - это отдельная услуга."
Сроки и этапы
Реалистичный план - лучше амбициозного нереалистичного.
Плохо: "Хотим через две недели."
Хорошо: "Желаемая дата запуска: 1 июня 2026. Этапы:
- Сбор и согласование требований - 1 неделя
- Прототип (wireframes) - 1 неделя
- Дизайн главной + типовой страницы - 1,5 недели, согласование - 3 дня
- Дизайн всех страниц - 2 недели
- Вёрстка и интеграция с CMS - 2 недели
- Наполнение контентом - параллельно с этапом 5
- Тестирование - 1 неделя
- Запуск - 2 дня"
Бюджет
Плохо: "Бюджет обсудим."
Когда студия видит эту фразу, она вынуждена закладывать максимальный бюджет, потому что не знает верхней границы. Это не выгодно ни клиенту, ни студии.
Хорошо: "Бюджет на разработку: 150 000 - 200 000 сом. Отдельно обсуждается SEO-продвижение после запуска."
Структура ТЗ для мобильного приложения
Для мобильного приложения базовая структура та же, но добавляются специфичные разделы.
Платформы
Укажите конкретно: iOS, Android или обе платформы. Если обе - нативная разработка или кроссплатформенная (React Native, Flutter)?
Также важно: минимальная поддерживаемая версия OS. Поддержка Android 7 добавляет сложность и стоимость по сравнению с поддержкой Android 11+.
Пример: "Платформы: Android и iOS. Минимальная версия: Android 10, iOS 15. Технология: Flutter (кроссплатформенная), так как нет специфичных нативных функций."
Роли пользователей
В большинстве приложений есть несколько типов пользователей с разными правами и функциями. Это нужно зафиксировать явно.
Пример: "Роли пользователей:
- Покупатель: просмотр каталога, добавление в корзину, оформление заказа, отслеживание доставки, история заказов, отзывы.
- Курьер: получение заказов на доставку, обновление статуса доставки, история выполненных заказов.
- Администратор (веб-панель, не мобильное приложение): управление заказами, каталогом, пользователями, курьерами."
User flows
Пользовательские сценарии - описание пути пользователя через ключевые функции. Это один из самых важных разделов для мобильного приложения.
Пример: "Сценарий 'Оформление заказа':
- Пользователь открывает приложение - видит главный экран с категориями и рекомендациями
- Переходит в категорию или ищет конкретный товар через поиск
- Открывает карточку товара, выбирает количество, нажимает 'В корзину'
- Переходит в корзину, видит список товаров и итоговую сумму
- Нажимает 'Оформить заказ', система проверяет наличие авторизации
- Если не авторизован - предлагается войти через телефон или создать аккаунт
- Выбирает адрес доставки (из сохранённых или вводит новый)
- Выбирает способ оплаты: наличные курьеру / Mbank / Elsom
- Подтверждает заказ - получает экран подтверждения с номером заказа и ожидаемым временем
- Получает push-уведомление о принятии заказа в обработку"
API и интеграции
Пример: "Интеграции:
- Карты: 2GIS (актуально для Бишкека и КГ), определение местоположения, прокладка маршрута для курьеров
- Оплата: Mbank API, Elsom API, наличные (без интеграции)
- Авторизация: по номеру телефона + SMS-код (OTP). Провайдер SMS: [обсудить]
- Push-уведомления: Firebase Cloud Messaging
- Аналитика: Firebase Analytics"
Офлайн режим
Пример: "Офлайн режим: частичный. Пользователь может просматривать ранее загруженный каталог и сохранённые адреса без интернета. Оформление заказа - только при наличии соединения. Если соединение потеряно в процессе оформления - показывается понятное сообщение об ошибке."
Хранение данных
Пример: "Данные пользователя (профиль, адреса, история заказов) - хранятся на сервере, локально кэшируются для быстрой загрузки. Корзина - хранится локально и синхронизируется с сервером при авторизации. Токен авторизации - хранится в защищённом хранилище устройства."
Push-уведомления
Пример: "Push-уведомления:
- 'Ваш заказ #123 принят в обработку' - после подтверждения заказа
- 'Курьер выехал к вам' - при изменении статуса заказа
- 'Ваш заказ доставлен' - при закрытии заказа
- Промо-уведомления: администратор может отправить уведомление всем пользователям или сегменту через панель управления (не более 1 в день)"
Аналитика
Пример: "Отслеживать: количество открытий приложения, источник установки, прохождение воронки заказа (на каком шаге пользователи уходят), самые просматриваемые категории, конверсия корзины. Инструмент: Firebase Analytics. Дополнительно: Crashlytics для отслеживания ошибок."
Типичные ошибки в ТЗ
За годы работы мы видели одни и те же ошибки снова и снова. Вот восемь самых распространённых - с объяснением последствий.
Ошибка 1: "Сделайте как у конкурента"
Референсы - это нормально и полезно. "Сделайте как у конкурента" - это не ТЗ. Разные компании имеют разные функциональные потребности, разные аудитории, разные технические стеки. Сайт конкурента - это результат их собственных требований, бюджета и компромиссов.
Правильно: "Вот сайт конкурента. Нам нравится то, как у них реализован каталог услуг (структура, карточки). Хотим похожее решение, но с адаптацией под наш брендинг и с добавлением раздела кейсов."
Ошибка 2: Нет описания целевой аудитории
Без понимания аудитории разработчик не знает: насколько важна мобильная версия, нужен ли упрощённый интерфейс, какой язык интерфейса приоритетен. Все эти решения принимаются интуитивно, и часто неправильно.
Последствие: после запуска выясняется, что основная аудитория - люди 50+ с телефонами на Android, а вы сделали интерфейс с мелкими элементами в расчёте на молодых пользователей iPhone.
Ошибка 3: Список функций без приоритетов
"Нам нужны: онлайн-заказ, личный кабинет, система лояльности, интеграция с 1С, мобильное приложение, блог, форум для клиентов, многоязычность..."
Всё это "важное", всё нужно "к запуску". Когда всё приоритет первого уровня - приоритетов нет. В результате либо бюджет взрывается, либо студия выбирает что реализовывать сама - и выбирает не то, что нужно вам.
Правильно: разделите функции на три группы - "обязательно к запуску", "желательно к запуску", "в следующих версиях". Это даёт студии понимание что критично, и позволяет управлять бюджетом.
Ошибка 4: Нет технических ограничений
Клиент говорит: "Хотим интеграцию с нашей системой учёта". Не уточняет - с какой именно системой. Разработчик узнаёт в процессе, что это 1С версии 2007 года на нестандартной конфигурации, API отсутствует, интеграция возможна только через выгрузку XML-файлов раз в час.
Это отдельный проект стоимостью ещё +30% от сметы. Клиент уверен, что "интеграция входила в договор". Разработчик уверен, что "об этом не говорили". Оба правы - просто никто не уточнил до начала работы.
Ошибка 5: "Бюджет обсудим"
Когда студия не знает бюджет, она делает одно из двух: либо описывает минимальное решение (которое не удовлетворит клиента), либо закладывает максимальный бюджет. Оба варианта плохие.
Укажите диапазон. "Мы готовы потратить от 100 000 до 150 000 сом" - это нормально и помогает студии предложить оптимальное решение в этих рамках.
Ошибка 6: Нет контент-плана
Студия закончила разработку. Стоит пустой сайт - каркас без текстов и фото. Клиент говорит: "Нам нужно ещё два месяца, чтобы подготовить контент." Сайт висит недоделанным, сроки сдачи сдвигаются, оплата задерживается.
Или другой вариант: студия берётся за написание текстов, потому что без них нельзя сдать проект, но никто не закладывал это в смету.
Зафиксируйте в ТЗ: кто готовит тексты, кто делает фото, в какие сроки. Если клиент - то когда именно и что будет если сроки сорвутся.
Ошибка 7: Скопированный шаблон из интернета
В интернете есть десятки шаблонов ТЗ. Это хорошая отправная точка, но многие клиенты берут шаблон, заполняют название компании и считают задачу выполненной. В результате в ТЗ оказываются разделы, не имеющие отношения к проекту (например, требования к серверному оборудованию для простого лендинга), и отсутствуют разделы, критичные именно для вашего проекта.
Шаблон - это скелет. Его нужно адаптировать под конкретный проект, убирать лишнее и добавлять специфичное.
Ошибка 8: Нет раздела приёмки
Как вы поймёте, что работа выполнена? По каким критериям будет приниматься готовый продукт?
Без этого раздела любая сдача проекта - переговоры. Клиент всегда найдёт что-то, что "не так". Студия будет защищаться тем, что "всё сделано по ТЗ". Обе стороны будут правы.
Раздел приёмки должен содержать чёткие, проверяемые критерии: PageSpeed >= 70, все формы отправляют данные, сайт открывается на перечисленных устройствах и браузерах, все страницы из списка реализованы, интеграции работают в тестовом режиме.
Шаблон ТЗ для сайта
Ниже - шаблон, который можно взять за основу. Удалите лишние разделы, добавьте специфичные для вашего проекта.
# Техническое задание: [Название проекта]
## 1. Общая информация
- Компания:
- Тип сайта: (корпоративный / интернет-магазин / лендинг / портал / другое)
- Цель сайта:
- Целевая аудитория: (кто, возраст, устройства, задачи)
- Конкуренты (ссылки):
- Референсы (ссылки + что именно нравится и почему):
## 2. Функциональные требования
### Страницы сайта
- Главная: [что должно быть, какие блоки, какие действия]
- О компании:
- Услуги / Каталог:
- Страница услуги / товара:
- Блог (если нужен):
- Контакты:
- [другие страницы]
### Функции
- Форма обратной связи: да / нет (поля: ___)
- Онлайн-чат: да / нет (какой сервис: ___)
- Поиск по сайту: да / нет
- Корзина / заказ: да / нет
- Личный кабинет: да / нет (что внутри: ___)
- Административная панель (CMS): да / нет (кто будет использовать и для чего)
- Многоязычность: да / нет (языки: ___)
- Карта: да / нет (какая: Google Maps / 2GIS / Yandex)
## 3. Технические требования
- CMS: WordPress / Bitrix / Next.js / без CMS / другое
- Языки сайта: русский / кыргызский / английский
- Интеграции: [1С, Bitrix24, Mbank, Elsom, другое - указать что именно]
- Адаптивность: мобайл + планшет + десктоп (обязательно)
- Браузеры: Chrome, Safari, Firefox (последние 2 версии)
- Хостинг: наш / ваш (если наш - укажите параметры)
- Домен: есть / нужно зарегистрировать
- SSL: да (обязательно)
## 4. Дизайн
- Стиль: минимализм / корпоративный / яркий / другое
- Основные цвета: (hex-коды если есть)
- Логотип: есть (предоставим в векторе) / нет (нужно разработать)
- Фирменный стиль: есть (предоставим гайдлайн) / нет
- Шрифты: [если есть предпочтения или корпоративные шрифты]
- Референсы по дизайну (ссылки + что нравится / не нравится):
## 5. Контент
- Тексты готовит: клиент / студия / совместно
- Срок предоставления текстов клиентом:
- Фото: есть (предоставим) / нужно создать / используем стоковые
- Видео: есть / не нужно / нужно создать
- Количество страниц с уникальным контентом:
## 6. SEO
- Нужна базовая SEO-оптимизация: да / нет
- Семантическое ядро: клиент предоставит / студия собирает
- Мета-теги (title, description): студия заполняет на основе ядра
- Микроразметка Schema.org: да / нет
- Google Search Console и Yandex.Webmaster: настройка при запуске
## 7. Аналитика
- Google Analytics 4: да / нет
- Yandex.Metrika: да / нет
- Другое:
## 8. Сроки и бюджет
- Желаемый срок запуска:
- Бюджет (диапазон):
- Этапы: прототип → дизайн → верстка → бэкенд → наполнение → тест → запуск
- Критичные даты (если есть):
## 9. Критерии приёмки
- Сайт открывается корректно на iOS (Safari) и Android (Chrome)
- PageSpeed Insights >= 70 на мобайле
- Все формы отправляют данные и приходят на указанный email
- Все страницы из раздела 2 реализованы и наполнены контентом
- Все интеграции работают в тестовом режиме
- SSL установлен, сайт открывается по https
- [дополнительные критерии]
Что делать если нет времени составлять ТЗ
Составить полноценное ТЗ - это работа на несколько часов, иногда дней. Не у всех есть на это время, и не у всех есть опыт формулирования технических требований. Это нормально.
Хорошие студии предлагают услугу Discovery или Брифинг-сессии. Это встреча длительностью 1-2 часа, в ходе которой менеджер или аналитик студии задаёт вам структурированные вопросы, записывает ответы и на их основе составляет ТЗ.
Вы рассказываете о своём бизнесе, показываете конкурентов, объясняете что хотите получить - и на выходе получаете документ, который можно использовать для оценки стоимости и планирования работ.
Такая услуга обычно стоит $200-500 (15 000 - 40 000 сом). Это кажется дополнительной статьёй расходов, но на практике Discovery-сессия почти всегда окупается: она позволяет точнее оценить стоимость проекта, избежать дорогостоящих переделок и запустить разработку без лишних итераций.
В Aunimeda мы проводим бесплатную 30-минутную первичную консультацию, на которой помогаем понять что нужно вашему проекту, из каких этапов он будет состоять и в какой бюджет укладывается. После этого, если проект требует детального планирования, предлагаем Discovery-сессию. Если проект небольшой (лендинг, простой корпоративный сайт) - часто хватает брифа и нескольких уточняющих вопросов.
Главное правило: не начинайте разработку без какого-либо зафиксированного документа. Даже если это не полноценное ТЗ, а заполненный бриф на одну страницу - это уже намного лучше чем ничего.
Часто задаваемые вопросы о ТЗ
Нужно ли ТЗ для простого лендинга?
Для лендинга полноценное ТЗ на 15 страниц избыточно. Но минимальный бриф нужен в любом случае: цель лендинга, целевая аудитория, что должен сделать посетитель (оставить заявку, позвонить, скачать), основные блоки страницы, референсы. Это займёт 30-40 минут и предотвратит большинство проблем.
Что если требования изменятся в процессе?
Требования меняются - это нормально. Бизнес развивается, появляются новые идеи. ТЗ не запрещает вносить изменения. Оно фиксирует отправную точку и позволяет оценить стоимость изменений относительно этой точки. Стандартная практика: изменения в рамках 10-15% от исходного объёма работ студия вносит без дополнительной оплаты, более значительные изменения оцениваются отдельно.
Кто должен писать ТЗ - я или студия?
В идеале - совместно. Клиент лучше знает свой бизнес, аудиторию и цели. Студия лучше знает как технически реализовать требования, какие решения существуют, как структурировать документ. Хорошая студия не просто получает ТЗ, а помогает его улучшить: задаёт уточняющие вопросы, предлагает альтернативные подходы, предупреждает о рисках.
Можно ли ТЗ составить по телефону?
Обсудить - можно. Составить - нет. Телефонный разговор не оставляет зафиксированного документа. Через две недели вы и разработчик будете по-разному помнить что именно обсуждали. Итог разговора нужно зафиксировать письменно - хотя бы в виде резюме в мессенджере. Пусть это будет не идеальное ТЗ, но документ, с которым обе стороны согласились.
Нужно ли ТЗ если я доверяю студии?
Доверие - это хорошо. Но даже самые честные и профессиональные разработчики не умеют читать мысли. ТЗ - это не про недоверие, а про общий язык. Два человека, говорящих на одном языке, могут понять одну фразу по-разному. ТЗ снимает двусмысленности.
Как понять что ТЗ достаточно детальное?
Простой тест: дайте ТЗ человеку, который ничего не знает о вашем проекте. Если он сможет ответить на вопросы "что будет на главной странице", "для кого этот сайт", "что произойдёт когда пользователь нажмёт кнопку заказа" - ТЗ достаточно подробное.
Что делать если студия говорит что ТЗ не нужно?
Это тревожный сигнал. Студия, которая готова работать без какой-либо фиксации требований, либо очень опытна и уверена в своём процессе (такое бывает), либо перекладывает на вас риски ("мы сделаем - вам понравится"). Запросите хотя бы краткое резюме договорённостей в письменном виде.
Техническое задание - не бюрократия и не формальность. Это инвестиция времени, которая возвращается в виде сэкономленного бюджета, соблюдённых сроков и отсутствия конфликтов. Хорошее ТЗ занимает от нескольких часов до нескольких дней. Переделки из-за плохого ТЗ занимают недели.
Если вы сейчас стоите перед задачей заказать разработку сайта или разработку мобильного приложения - начните с брифа. Используйте шаблон из этой статьи как основу. Заполните то, что знаете. Остальное поможет дополнить хорошая студия на первой встрече.
Не знаете с чего начать? Команда Aunimeda проводит бесплатные 30-минутные консультации, после которых вы получите понимание что нужно вашему проекту и примерный бюджет. Напишите в WhatsApp или оставьте заявку на сайте.