Почему ТЗ важнее начальной сметы: цена размытых требований
В классической разработке действует жесткое инженерное правило: ошибка, допущенная на этапе ТЗ и не замеченная до релиза, стоит в 10 раз дороже. Когда заказчик приходит со словами «сделайте современный сайт для оптовых продаж, пример — вот эти три ссылки», каждый участник процесса представляет совершенно разный продукт.
Разработчик видит стандартный шаблон с готовой корзиной, дизайнер фантазирует о сложных 3D-анимациях, а бизнес ожидает синхронизацию цен с 1С каждые 15 минут и автоматический расчет габаритов груза для СДЭК. Итогом становится взаимное разочарование, срыв дедлайна на 3 месяца и перерасход бюджета.
Хорошее ТЗ описывает не то, как нажимаются кнопки, а какие бизнес-задачи решает каждый сценарий пользователя и какие измеримые критерии приемки у каждого экрана.
6 обязательных разделов технического задания, которые защитят проект
Многие неповоротливые студии до сих пор требуют от заказчиков 50 страниц сухих гостовских формулировок, заставляя их выполнять работу аналитика. Мы считаем иначе: техническое задание должно быть компактным и рабочим. Обычно мы сами формируем эти шесть ключевых блоков после брифинга, чтобы полностью защитить вас от сюрпризов:
Бизнес-цели и Customer Journey Map (CJM)
Кто является целевым клиентом, с какого устройства он заходит (мобильный или десктоп), какую ключевую боль решает и какое главное целевое действие должен совершить на сайте (оставить контакт, рассчитать смету, скачать презентацию).
Карта сайта (Sitemap) и структура страниц
Полный список всех экранов и подстраниц. Древовидная структура навигации исключает ситуацию, когда перед сдачей внезапно выясняется, что «забыли страницу возврата и политики конфиденциальности».
Функциональные требования и формы захвата
Детальное описание полей каждой формы, валидация номеров телефонов, сценарии успешной отправки, всплывающие окна и условия показа интерактивных квизов.
Внешние интеграции (CRM, эквайринг, Telegram)
Куда уходят заявки: в AmoCRM / Bitrix24, Telegram-чат руководителей или на почту. Какая платежная система подключается (ЮKassa, СБП, CloudPayments), нужны ли фискальные чеки.
Технические требования к скорости и адаптивности
Четкие метрики приемки: оценка Google PageSpeed от 85+ на мобильных, чистая работа на iOS Safari и современных браузерах, корректная поддержка экранов от 375px до 4K.
Критерии приемки и передача исходников
Фиксация условий передачи: 100% передача прав на Figma-макеты, исходный код в GitHub/GitLab, настройка хостинга на аккаунте заказчика и гарантийный срок поддержки (в fellows — от 30 дней).
Формулировки-ловушки: как распознать плохое ТЗ от подрядчика
Иногда недобросовестные студии и фрилансеры предлагают подписать ТЗ, состоящее из размытых фраз. Это создает иллюзию договоренности, но на деле всегда приводит к конфликтам на этапе сдачи. Если вы читаете предложенное вам ТЗ, обращайте внимание на эти «слова-паразиты». Вот как они должны быть переписаны в здоровом документе:
«Сделать стильный, продающий дизайн»
«Разработать дизайн в минималистичной эстетике по брендбуку. Акцентный шрифт — вариативный sans-serif, контрастность текста не ниже WCAG AA, 60fps микроанимации кнопок».
«Быстрая загрузка страниц»
«Время первого содержательного отображения (FCP) до 1.4 секунды при 4G-соединении, Core Web Vitals LCP до 2.2 с, общий вес стартового бандла до 350 Кб».
«Удобная админка»
«Возможность редактировать заголовки, цены и баннеры без привлечения программистов через структурированный UI-интерфейс».
«Все стандартные интеграции»
«Отправка имени, телефона и UTM-меток в AmoCRM по REST API с созданием новой сделки в воронке "Первичный лид"».
Как мы в fellows составляем спецификацию вместе с заказчиком
Вам не обязательно быть техническим директором и тратить недели на написание ТЗ в одиночку. В бюро <strong>fellows</strong> процесс устроен максимально практично:
Классический бюрократический подход
- Заказчику высылают опросник на 60 абстрактных вопросов
- Три недели уходит на согласование юридических формулировок
- Любое уточнение в процессе считается платной доработкой
- ТЗ пишется в Word и отрывается от реального дизайна
Спринтовый подход fellows
- 60-минутное интервью с ведущим дизайнером и инженером
- Разработка кликабельного прототипа вместо сухого текста
- Прозрачная смета с калькуляцией часов по каждому этапу
- Фиксация цены и сроков спринтов в день утверждения прототипа
Часто задаваемые вопросы
Нет, достаточно сформулировать общую задачу и ориентиры. Мы сами проведем брифинг, декомпозируем задачи и подготовим спецификацию в рамках нулевого спринта.