Зачем нужно техническое задание
Техническое задание - это договор о том, что именно будет сделано, между заказчиком и командой разработки. Без него каждый понимает задачу по-своему: заказчик ждёт одно, разработчики делают другое, и на приёмке начинаются споры о том, что имелось в виду. Хорошее ТЗ фиксирует функциональность, ограничения и критерии готовности, поэтому напрямую влияет на смету и сроки: чем точнее описаны требования, тем меньше переделок и тем ближе оценка к реальности.
Вопрос «как написать техническое задание» стоит решить до того, как обсуждать цену и дедлайны, а не после. В противном случае вы получите размытую смету, которая вырастет на 30-50% по ходу работы, потому что обе стороны открыли для себя новые требования, которые никто не обсуждал на старте. Хорошее ТЗ спасает деньги, время и репутацию обеих сторон. Это не просто документ - это инструмент управления проектом.
Техническое задание - это не бумажка на галочку. Это экономический инструмент: он либо экономит вам 20-30% бюджета, потому что смета честнее, либо стоит вам 50% переделок, потому что требования были размыты. Выбирайте первое, всегда.
Структура технического задания: из чего оно состоит
Структура технического задания почти всегда одинаковая, меняется только глубина деталей в каждом разделе. Вы можете писать развёрнуто или кратко, но порядок разделов универсален: сначала контекст и бизнес-цель, потом пользователи и сценарии, потом техничка и данные, потом интеграции и интерфейс, в конце критерии приёмки. Этот порядок помогает команде разработки понять не только ЧТО нужно сделать, но и ПОЧЕМУ, что критично для принятия правильных решений.
На практике не обязательно писать все разделы одинаково подробно. Важно, что под каждый пункт можно было проверить результат: сделано или нет. Например, для простого лендинга раздел про интеграции может быть одной строкой, а про интерфейс - ссылкой на Figma. Для системы управления данными, наоборот, раздел про данные займёт половину документа. Принцип простой: пишите ровно столько, сколько нужно, чтобы команда поняла задачу и не было разночтений.
| Раздел ТЗ | Что описать | Минимальный пример |
|---|---|---|
| Цель и контекст | Какую проблему решаем, для кого, почему именно сейчас | Компания продаёт услуги B2B, клиенты разбросаны по регионам, сейчас заявки приходят на почту и часто теряются в спаме. Нужна система учёта с уведомлениями менеджерам в реальном времени, чтобы не упустить сделки. |
| Пользователи и роли | Кто работает с системой, какие права и обязанности каждого | Менеджер по продажам (читает и редактирует заявки, отправляет письма), руководитель (смотрит статистику и отчёты), администратор (управляет учётными записями и доступами). |
| Функциональные требования | Что система делает без слова как | Менеджер может создать заявку, назначить ответственного, отправить клиенту письмо из интерфейса, отложить задачу на позже, перевести заявку в статус выигрыш или потеря. |
| Нефункциональные требования | Нагрузка, скорость, безопасность, платформы | До 1000 пользователей, работа на мобильном браузере без приложения, HTTPS, двухфакторная аутентификация, время ответа API < 200ms. |
| Интеграции | Связь с внешними сервисами | Отправка писем через Sendgrid или SMTP компании, выгрузка статистики в Яндекс.Метрику один раз в сутки, синхронизация с 1С. |
| Данные и хранение | Что храним, как долго, требования регуляции | Истории общения храним 3 года, после удаления восстановление невозможно, compliance с 152-ФЗ (персональные данные). |
| Интерфейс и дизайн | Макеты, стиль, тон общения | Минималистичный дизайн, мобильный-first, цвета по брендбуку компании, письма в дружелюбном стиле, время отклика интерфейса < 1 сек. |
| Этапы и приёмка | Как разбиваем работу, критерии готовности каждого этапа | MVP: заявки и менеджер (1,5 месяца). Интеграции: почта, SMS (1 месяц). Интеграция CRM: май следующего года. Критерий приёмки: все функции MVP работают без ошибок. |
Эта таблица - минимум. Для сложного проекта каждый раздел может развиться в отдельный документ из 5-10 страниц. Но даже краткое заполнение этой базовой структуры снимает большую часть вопросов до старта разработки.
Уровни детализации ТЗ: выбирайте по масштабу проекта
Не всегда нужно писать ТЗ на 50 страниц. Иногда достаточно 5 страниц, которые охватывают главное. Выбор уровня детализации зависит от размера проекта, типа контракта и опыта команды. Чем больше денег и времени вы вкладываете, тем подробнее должно быть ТЗ. Вот практический ориентир:
| Уровень | Объём | Когда подходит | Примеры требований |
|---|---|---|---|
| Минимальный (Lean) | 2-5 стр | Лендинг, простой CRUD, прототип, agile с weekly refinement | Функции перечислены пунктами, нет подробных сценариев, дизайн - ссылка на макет, MVP четко выделен. |
| Стандартный (Standard) | 10-20 стр | Веб-приложение, мобильное приложение, стартап-MVP, фиксированная цена до 500k | Функции описаны сценариями, граничные случаи указаны, есть таблица данных, нефункциональные требования перечислены, безопасность описана. |
| Детальный (Comprehensive) | 30-50+ стр | Сложная система, банк/страховка, критичная безопасность, регуляция, бюджет > 500k | Каждый сценарий разобран по шагам с экранами, таблицы данных с типами и ограничениями, security requirements подробны, все интеграции задокументированы. |
| Discovery-first (Рекомендуемый для новичков) | Итеративно | У вас есть идея, но нет опыта писать ТЗ, нужна честная оценка | Начинаете с 3-5 страниц, команда проводит аналитику 2-4 недели, уточняет требования, выпускает финальное ТЗ. |
Уровень детализации должен соответствовать риску и бюджету. Чем больше денег вы вкладываете и чем дольше работа, тем подробнее должно быть ТЗ. Для маленькой задачи 5 тысяч рублей можно обойтись Lean, но для системы, которую потом будут использовать годы - нужен Comprehensive.
Плохая и хорошая формулировка требования: примеры
Главная ошибка в ТЗ - размытые формулировки, которые нельзя проверить. На приёмке возникает спор: заказчик говорит, что требование не выполнено, команда говорит, что выполнено, и никто не прав, потому что требование можно интерпретировать как угодно. Это называется субъективное требование и оно стоит денег. Вот как отличить плохую формулировку от хорошей:
- Плохо: приложение должно быстро работать. Хорошо: экран каталога открывается не дольше 2 секунд при 3G с 500 товарами.
- Плохо: удобная авторизация. Хорошо: вход по номеру телефона с СМС-кодом, повторная отправка кода через 60 секунд, блокировка после 5 неверных попыток.
- Плохо: система должна быть безопасной. Хорошо: пароли хешируются (bcrypt, 12 раундов), HTTPS на всех эндпоинтах, двухфакторная аутентификация для администраторов, логирование всех действий.
- Плохо: красивый дизайн. Хорошо: минималистичный дизайн в стиле Material Design, цвета из палитры: основной #006AFF, ошибки #FF3B30, отступы кратны 8px.
- Плохо: уведомлять пользователя об ошибках. Хорошо: если запрос упал, показать красный алерт с текстом ошибки и кнопкой повторить, алерт закрывается через 5 секунд автоматически или вручную.
Разница в том, что вторые формулировки измеримы и проверяемы: по ним однозначно понятно, выполнено требование или нет, и не остаётся места для спора на приёмке. Измеримость - главное правило хорошего ТЗ. Если требование нельзя измерить никаким способом - переформулируйте его или уберите.
Готовый шаблон ТЗ: 9 разделов, которые работают в 99% проектов
Вот готовый каркас, который можно взять за основу и заполнить под свою задачу. Используйте его как чек-лист: если вы ответили на все 9 пунктов, значит, ТЗ готово к передаче команде. Среднее время заполнения - от 4 часов для простого проекта до 2-3 дней для сложного.
- Цель проекта - какую проблему решаем, для кого, в какие сроки. Вписать в 3-5 предложений бизнес-контекст: кто сейчас пользуется, почему они страдают, почему это нужно решить именно сейчас.
- Пользователи и роли - кто будет работать с системой, какие действия они выполняют. Описать каждую роль в 1-2 предложениях, уточнить права (кто может удалять, кто только смотреть, кто может изменять).
- Пользовательские сценарии - пошагово, от входа до целевого действия, для каждой роли. Например: менеджер открывает приложение, вводит пароль, видит список новых заявок, нажимает на заявку, вводит комментарий, нажимает отправить, клиент видит уведомление в реальном времени.
- Функциональные требования - список функций системы, каждая на отдельную строку, без деталей реализации. Функция должна быть проверяемой: не экспорт данных, а экспорт заявок в CSV с колонками: ФИ, телефон, статус, дата создания, исходящие письма.
- Нефункциональные требования - нагрузка (сколько пользователей/заявок в сутки), скорость (время загрузки страниц), безопасность (шифрование, 2FA), платформы (мобильный браузер, iOS, Android), язык интерфейса, требования доступности.
- Интеграции - платежи (какая система, какие методы), уведомления (СМС, почта, push, Telegram), карты, аналитика, внешние API. Описать, когда срабатывает интеграция и что должно произойти в системе.
- Данные - что храним (заявки, пользователи, логи), сроки хранения, требования 152-ФЗ (персональные данные), GDPR (если EU пользователи), политика резервных копий, шифрование в покое и в движении.
- Интерфейс - макеты (ссылка на Figma или Penpot), тон общения (формально/дружелюбно), брендинг (цвета, логотип, шрифты), мобильная адаптация, требования доступности (контраст не хуже 4.5:1, размер шрифта > 14px).
- Этапы и приёмка - как разбиваем работу (MVP, второй релиз), сроки каждого этапа, критерии приёмки каждого (все функции работают, тесты написаны, документация готова, нет critical bugs).
Даже краткое заполнение этого шаблона (по 1-2 абзаца на раздел) снимает большую часть будущих вопросов. Команда может начать разработку, опираясь на ваши ответы, и вы будете знать ровно, что именно будет сделано и когда.
Частые ошибки в ТЗ и как их избежать
Даже опытные заказчики делают ошибки при составлении ТЗ. Обычно они не насмерть, но вызывают переделки и споры, которые съедают 10-20% бюджета. За 10 лет практики работы с разными клиентами видно, что одни и те же ошибки повторяются: недоопределённость требований, смешивание функционала с технологией, забывчивость про граничные случаи. К счастью, все эти ошибки предотвращаемы. Вот самые частые ошибки и как их избежать:
- Писать как надо сделать вместо что должно получиться. Например, используйте React вместо интерфейс должен отвечать за 1 секунду. Выбор технологий - дело команды, ваше дело - результат и ограничения. Исключение: если у вас есть строгое требование (например, интеграция с legacy системой), оно должно быть явно обозначено.
- Смешивать обязательное и желательное. Пометьте явно, что нужно к запуску (MVP), а что может подождать до версии 2.0 (nice-to-have). Иначе команда закладывает всё сразу, смета растёт, сроки сдвигаются, и вы получаете самолёт вместо автомобиля.
- Забыть про нефункциональные требования. Если вы не указали, сколько пользователей, какая нагрузка, требования к безопасности - команда заложит минимум. Потом переделка при росте пользователей выйдет в 2-3 раза дороже, чем правильно сделать с начала.
- Не описать граничные случаи. Что происходит, если пользователь потерял интернет посередине операции? Если оплата не прошла, но деньги списались? Если список пуст? Именно необработанные сценарии чаще всего всплывают на приёмке и требуют срочных переделок.
- Размытые критерии приёмки. Не пишите когда всё готово. Напишите конкретно: все 12 функций работают без ошибок, написано >= 70% автотестов, код выложен на dev-сервер, техническая документация готова, нет critical и major bugs.
- Не приложить макеты или дизайн-систему. Если есть макеты в Figma - приложите ссылку с комментарием о том, какие экраны в MVP. Если дизайна нет - явно опишите в требованиях: цвета RGB, шрифты, расстояния, брендинг, контрастность.
- Забыть про регуляцию. Если вы работаете с данными в России - уточните 152-ФЗ требования. Если есть платежи - уточните стандарты (PCI DSS). Если есть клиенты из EU - GDPR. Это не просто требования, это ограничения архитектуры, которые влияют на стоимость и сроки.
Самая частая причина переделок и конфликтов - это не неправильная разработка, а неполное описание требований. Поэтому перед передачей ТЗ команде переспросите себя: могу ли я доказать, что каждое требование выполнено? Если ответ нет - переформулируйте это требование или уберите его из ТЗ.
Чек-лист: готово ли ваше ТЗ к старту разработки
Перед тем как отправить ТЗ команде, проверьте эту батарею вопросов. Если не на все вы ответили утвердительно - ТЗ ещё нужно дошлифовать. Каждый пропущенный пункт - это риск переделки на 10-50k рублей.
- Ясна ли цель проекта в одном предложении и почему это нужно сделать именно сейчас?
- Каждое требование измеримо и проверяемо (или это субъективная оценка вроде красиво)?
- Обозначены ли MVP и nice-to-have требования явно?
- Описаны ли граничные случаи (пустой список, ошибка оплаты, потеря сети, блокировка пользователя)?
- Указана ли ожидаемая нагрузка (пользователи в месяц, заявки в день, РПС)?
- Описаны ли требования к безопасности и регуляции (152-ФЗ, GDPR, PCI DSS)?
- Приложены ли макеты (Figma, Penpot) или точно описан дизайн (цвета, шрифты, отступы)?
- Указаны ли сроки и этапы работ с критериями приёмки каждого?
- Привязаны ли требования к ролям и сценариям (кто и как будет это использовать)?
- Есть ли полный список всех интеграций (платежи, уведомления, API, экспорт)?
- Ясны ли критерии приёмки каждого этапа (количество тестов, документация, отсутствие багов)?
- Понял ли я, что может быть использовано готовым (SaaS, библиотека), а что надо писать с нуля?
Если на 70% вопросов чек-листа вы ответили да - можно смело передавать команде. Остальное уточните вместе с ней на аналитике. Если меньше 50% да - ТЗ нужно доработать, иначе риск переделок вырастет с 15% до 50%.
Что приложить к ТЗ помимо текста
ТЗ - это не только слова. К нему стоит приложить дополнительные материалы, которые помогут команде разработки быстрее разобраться, меньше уточнять и избежать ошибок. Хорошо приложенные материалы - это основа эффективного взаимодействия между заказчиком и разработчиком:
- Макеты интерфейса (Figma, Penpot, даже фотографии с планшета/телефона) - по ним логика видна лучше, чем в словах. Обозначьте, какие экраны в MVP, а какие в версии 2.
- Диаграммы потока данных (какие данные откуда берутся, куда отправляются, где обрабатываются) - особенно важно для систем с интеграциями и сложной логикой.
- Таблица разрешений по ролям (кто может читать/писать/удалять в каждом разделе) - спасает от ошибок в доступах.
- Примеры API ответов или формата данных, которые должны храниться - если интегрируетесь с внешним сервисом, приложите реальные примеры JSON.
- Требования к логированию и аналитике: какие события должны логироваться, в каком виде, с каким уровнем детализации.
- Скрины конкурентов или похожих решений (если у вас есть) - сильно помогают команде понять ваше видение и избежать ошибок других.
- Ссылку на регуляцию или compliance документы (если релевантны: 152-ФЗ, GDPR, PCI DSS) - команда поймёт constraints и сможет планировать архитектуру.
Что делать, если ТЗ нет, но разработка нужна уже вчера
Если у вас есть идея, но нет ни ТЗ, ни чёткого понимания объёма - это нормально. Писать сразу детальный документ не нужно. Вместо этого задача решается предпроектной аналитикой, которую иногда называют Discovery или Vision Phase.
Discovery - это процесс, когда аналитик вместе с вами превращает идею в прототип, бэклог требований и обоснованную оценку. Аналитик расспрашивает вас про пользователей, их болевые точки, текущие процессы. Рисует диаграммы, может предложить варианты архитектуры, которые вы не рассматривали, предупредит о технических сложностях. На выходе рождается ТЗ - но уже проверенное на реалистичность, а не написанное вслепую. Аналитик также обычно делает конкурентный анализ, чтобы понять лучшие практики. Это стоит своих денег и экономит в 2-3 раза больше на переделках.
Discovery обычно занимает 2-4 недели и стоит 10-20% от бюджета разработки (примерно 50-150k рублей для типового проекта). Это инвестиция, которая окупается сразу: правильное ТЗ снимет половину переделок. Если вы только выбираете подрядчика, обратите внимание, готов ли он начать именно с аналитики, а не сразу назвать цену за разработку приложения без документа. Подрядчик, который готов работать через Discovery, обычно качественнее и опытнее.
Если вы в первый раз заказываете разработку и боитесь ошибиться - всегда просите начать с Discovery. Это защитит вас лучше, чем любое ТЗ, которое вы напишете сами. Стоимость Discovery часто входит в общий бюджет, если вы потом заказываете разработку той же команде.
Практические примеры ТЗ для разных типов проектов
ТЗ может выглядеть по-разному в зависимости от типа проекта. Для лендинга это может быть просто список страниц и функций на 2-3 листа. Для мобильного приложения нужны пользовательские сценарии и дизайн-макеты. Для сложной B2B системы требуется детальное описание всех интеграций, ролей, прав доступа и граничных случаев. Главное, что должно быть везде - это измеримость и ясность. Даже минимальное ТЗ на 1-2 странице уже создаёт общее понимание между заказчиком и разработчиком.
- Лендинг (1-3 дня работы): список разделов, требования к SEO, подключение аналитики, контактная форма, чек-лист всех текстов и картинок.
- Мобильное приложение (2-6 месяцев): описание пользователей и их потребностей, 5-10 пользовательских сценариев, дизайн-макеты всех экранов, API требования, безопасность, интеграции (платежи, push-уведомления).
- Admin-панель (3-8 недель): роли и разрешения, таблица данных, CRUD операции для каждой сущности, фильтры и поиск, экспорт, логирование.
- E-commerce маркетплейс (4-12 месяцев): модели пользователей (покупатель, продавец, администратор), каталог с фильтрацией, корзина и чекаут, платёжная система, система рейтинга, чат между участниками.
- Интеграция с 1С или другой legacy системой (2-4 недели): описание источников данных, формат синхронизации, частота обновления, обработка конфликтов, откат при ошибке.
Как ТЗ влияет на стоимость и сроки разработки
Качество ТЗ напрямую связано с честностью оценки и сметы. Вот как работает механика: по размытому ТЗ команда закладывает риск и неизвестность в смету. Вместо 100 часов она пишет 150, потому что может всплыть что-то неожиданное. Цена получается на 30-50% выше, чем нужно реально. По детальному ТЗ команда считает предметно. Она знает ровно, что нужно сделать, может разбить на таски и оценить каждый. Цена получается точнее, часто ниже. Это особенно важно, если вы работаете с фиксированной ценой: подрядчик, которому хватило детального ТЗ, может дать честную смету, а не защищать себя буфером.
На сроках то же самое: размытое ТЗ = неопределённость = буфер в план = сроки растягиваются. Точное ТЗ = план без буфера = реальные сроки, которым можно доверять. Кроме того, детальное ТЗ позволяет работать по фиксированной цене (Fixed Price). Без детального ТЗ честнее модель Time & Material, потому что никто не может гарантировать объём работ. А время и материалы - это риск для заказчика, потому что работа может тянуться месяцами. В среднем правильное ТЗ сокращает время разработки на 15-25% за счёт того, что не нужны постоянные уточнения.
Резюме: техническое задание - это не бюрократия и не лишняя работа. Это основа договора между вами и подрядчиком, инструмент управления проектом и защита для обеих сторон. Даже простое ТЗ на 2-3 страницы уже радикально улучшает результаты разработки. Потратьте время на ТЗ в начале - сэкономьте деньги и нервы в конце.