Как правильно написать техническое задание для программиста

Фраза «нужно немного доработать сайт» для заказчика может звучать понятно. Для программиста она почти ничего не говорит. Что именно изменить? Как должен работать результат? Что происходит при ошибке? Что считать выполненной задачей?Если эти вопросы не решить до начала разработки, ответы появляются уже в процессе: в переписке, комментариях, звонках. В итоге требования меняются на ходу, сроки растут, а заказчик и исполнитель могут по-разному понимать, какой результат был согласован.Техническое задание помогает этого избежать.

Что такое ТЗ для программиста простыми словами

ТЗ для программиста — это документ, в котором зафиксировано, что нужно разработать или изменить, как должен работать результат, какие есть ограничения и как будет проверяться выполненная работа.Хорошее техническое задание должно отвечать как минимум на пять вопросов:

• что нужно сделать;
• зачем это нужно;
• как должен работать функционал;
• что входит в задачу;
• как проверить результат.

Например, формулировка: «Добавить форму обратной связи» оставляет слишком много вопросов.Гораздо точнее: «Добавить на страницу услуги форму с полями „Имя“, „Телефон“ и „Комментарий“. Телефон сделать обязательным. После успешной отправки создать лид в Битрикс24 и показать пользователю сообщение „Спасибо! Заявка отправлена“. При ошибке введенные данные должны остаться в форме».Во втором случае программист понимает ожидаемое поведение, а заказчик может проверить результат.Поэтому задача ТЗ — не сделать документ максимально большим или технически сложным. Главное — убрать неоднозначность между тем, что заказчик хочет получить, и тем, что разработчик должен реализовать.

Когда нужно ТЗ и кто его составляет

Полноценное техзадание нужно не для каждой мелкой правки. Если требуется заменить текст, ссылку или изображение, обычно достаточно коротко описать задачу и ожидаемый результат.ТЗ становится особенно важным, когда в работе есть логика: формы, фильтры, личный кабинет, интеграции, работа с данными, изменение структуры сайта, новый раздел или автоматизация процессов.Есть простой ориентир: если одну и ту же задачу два разработчика могут понять по-разному, требования лучше зафиксировать письменно.Составление ТЗ — не обязательно обязанность одного человека. Заказчик формулирует цель и ожидаемый результат, менеджер или аналитик помогает структурировать требования, дизайнер отвечает за интерфейс, SEO-специалист — за требования, связанные с поисковой оптимизацией, а разработчик проверяет, насколько все это технически реализуемо.Для небольшой задачи ТЗ может занимать несколько абзацев. Для сложного проекта — несколько страниц. Важен не объем документа, а количество неясных мест, которые он снимает до начала разработки.

Что должно быть в ТЗ для программиста

Структура зависит от задачи, но в большинстве случаев техническое задание стоит собирать из нескольких обязательных частей.

1. Текущее состояние

Сначала опишите, что уже есть и как это работает сейчас.Для сайта полезно указать:

• страницу или раздел;
• существующий функционал;
• используемую CMS или платформу, если это важно;
• связанные системы;
• известные ограничения.

Например: Сейчас заявки с формы приходят только на email. Менеджер вручную переносит данные клиента в Битрикс24. Так разработчик сразу понимает исходную точку.

2. Цель и ожидаемый результат

Здесь нужно ответить на два вопроса: зачем выполняется задача и что должно измениться после разработки.Например: Цель: убрать ручной перенос заявок.Результат: после отправки формы на сайте в Битрикс24 автоматически создается новый лид с данными пользователя.Цель не должна быть формальной. Необязательно придумывать метрики, если их нет. Главное — понятно объяснить, какую проблему должна решить разработка.

3. Что входит и не входит в задачу

Этот раздел помогает заранее определить границы.Например:Входит:

• передача формы в Битрикс24;
• создание лида;
• передача имени, телефона и комментария;
• сообщение об успешной отправке.

Не входит:

• настройка воронки продаж;
• создание роботов в CRM;
• изменение дизайна формы;
• доработка других форм сайта.

Так снижается риск ситуации, когда заказчик и исполнитель по-разному понимают объем работ.

4. Сценарии и функциональные требования

Опишите, что делает пользователь и как на его действия должна реагировать система.Например:

1. Пользователь заполняет форму.
2. Система проверяет обязательные поля.
3. После отправки создает лид в CRM.
4. Пользователь получает сообщение об успешной отправке.

Отдельно стоит предусмотреть основные нестандартные ситуации: неверные данные, отсутствие результата, недоступность внешнего сервиса, повторное нажатие кнопки, отсутствие прав.После этого сценарий переводится в конкретные требования.Не так: «Сделать удобный поиск».А так: «Поиск начинается после ввода трех символов и выполняется по названию и артикулу товара».Хорошее требование можно проверить однозначно.

5. Интерфейс, интеграции и технические ограничения

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

• с какой системой идет обмен;
• какие данные передаются;
• в каком направлении;
• что должно происходить при ошибке.

Если важны скорость, нагрузка, безопасность, браузеры или ограничения текущей CMS, их также нужно указать в ТЗ.Для сайта отдельно стоит проверить, затрагивает ли доработка SEO: URL, редиректы, индексацию, метатеги, фильтры, пагинацию или аналитику.

6. Критерии приемки

В конце ТЗ должен быть список условий, по которым можно проверить работу.Например:

• обязательные поля нельзя отправить пустыми;
• после успешной отправки создается один лид;
• все необходимые данные передаются в CRM;
• при ошибке введенные данные не исчезают;
• форма корректно работает на мобильной версии;
• событие аналитики срабатывает только после успешной отправки.

Если результат можно пройти пункт за пунктом и отметить «выполнено / не выполнено», ТЗ составлено значительно лучше.

Как правильно формулировать требования

Чем меньше в ТЗ оценочных слов, тем проще программисту понять задачу. Формулировки вроде «удобно», «красиво», «быстро» или «как у конкурента» лучше заменять конкретным поведением системы.

Неудачная формулировка	Более точная формулировка
Сделать удобный фильтр	Добавить фильтрацию по цене, бренду и наличию с возможностью выбрать несколько параметров
Улучшить поиск	Запускать поиск после ввода от трех символов по названию и артикулу
Сделать форму лучше	Добавить обязательное поле телефона и передавать данные формы в CRM
Сделать адаптив	Реализовать отображение интерфейса для мобильной и desktop-версии по макету
Настроить интеграцию	После успешной отправки формы создавать лид в Битрикс24 и передавать согласованные поля
Сделать как на другом сайте	Описать конкретные элементы и сценарии, которые нужно повторить

Полезное правило: одно требование — одно понятное условие, которое можно проверить после разработки.Если есть референс или пример у конкурента, его можно приложить к ТЗ, но он не должен заменять описание задачи. Разработчик должен понимать, что именно из примера нужно перенести в проект, а что к работе не относится.

Пример технического задания для программиста

Ниже — короткий пример как правильно написать техническое задание для программиста для сайта.Задача: подключить форму «Получить консультацию» к Битрикс24.Текущее состояние: форма содержит поля «Имя», «Телефон» и «Комментарий». Сейчас заявки отправляются только на email.Нужно реализовать:

1. После отправки формы проверять обязательное поле «Телефон».
2. При корректных данных создавать новый лид в Битрикс24.
3. Передавать в CRM имя, телефон, комментарий и URL страницы.
4. После успешной отправки показывать сообщение «Спасибо! Заявка отправлена».
5. Не перезагружать страницу после отправки.
6. При ошибке CRM сохранять введенные пользователем данные и показывать сообщение об ошибке.
7. Не создавать повторный лид, если пользователь несколько раз нажал кнопку отправки.

Не входит в задачу:

• изменение дизайна формы;
• настройка воронки и роботов в Битрикс24;
• доработка других форм сайта.

Критерии приемки:

• без телефона форма не отправляется;
• после успешной отправки в CRM появляется один лид;
• все предусмотренные данные передаются правильно;
• при ошибке данные пользователя не исчезают;
• форма работает на мобильной и desktop-версии.

Такой пример показывает главное: ТЗ не обязательно должно быть длинным. Даже небольшую задачу можно описать так, чтобы и заказчик, и разработчик одинаково понимали результат.

Шаблон ТЗ для программиста

Для своей задачи можно использовать компактную структуру:Проект: Название сайта или системы.Задача: Что нужно разработать или изменить.Цель: Какую проблему должна решить доработка.Текущее состояние: Как функция работает сейчас.Что нужно реализовать: Конкретный список требований.Сценарии: Что делает пользователь и как отвечает система.Интеграции и данные: Какие внешние системы используются и что между ними передается.Ограничения: Что важно учитывать при разработке.Что не входит в задачу: Связанные работы, которые выполняться не должны.Критерии приемки: Список проверок, по которым принимается результат.Сроки и этапы: Если они заранее определены.Для небольшой доработки этого шаблона обычно достаточно. Для сложного проекта его можно дополнить требованиями к безопасности, производительности, API, тестированию, миграциям и документации.

Типичные ошибки при составлении ТЗ

Даже подробное техзадание может не сработать, если в нем остаются места для двойной трактовки.Чаще всего проблемы возникают из-за следующих ошибок:

• слишком общие формулировки без проверяемого результата;
• описание только идеального сценария без ошибок и исключений;
• отсутствие границ задачи;
• требования разбросаны по ТЗ, переписке и устным договоренностям;
• не указано, что считать готовой работой;
• заказчик описывает технический способ реализации, не зная ограничений проекта;
• не учтено текущее состояние сайта, CMS или связанных систем.

Например, подключение формы к CRM не означает автоматически настройку всей воронки продаж. Если это не входит в задачу, лучше указать это прямо.Перед передачей ТЗ программисту стоит проверить три вещи:

• Понятно ли, что нужно сделать?
• Понятно ли, что не входит в задачу?
• Можно ли однозначно проверить результат?

Если на все три вопроса можно ответить «да», документ уже выполняет свою основную функцию.

Чек лист перед отправкой техзадания программисту

Убедитесь, что ваше техническое задание — это дорожная карта, а не лабиринт. Перед тем как нажать «Отправить», проверьте документ по этим пунктам:

1. Контекст и Цель: Четко ли описано, зачем нужен продукт и какую бизнес-задачу он решает? (Программист должен понимать ценность работы, а не просто механически писать код).
2. Границы scope: Определено ли, что не входит в задачу? (Защита от «разрастания функционала»).
3. Логика пользователя: Описаны ли сценарии поведения пользователя (User Stories) и логика взаимодействия с интерфейсом?
4. Технический стек: Есть ли требования к языкам, фреймворкам и окружению?
5. Дизайн и Данные: Прикреплены ли макеты (Figma/Sketch) и описана ли структура базы данных или формат обмена данными (API)?
6. Критерии приемки: Поймете ли вы однозначно, что работа выполнена качественно? (Definition of Done).

Только утвердительно ответив на все пункты, вы экономите дни переписки и нервы.

Можно ли составить ТЗ с помощью ИИ

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

1. Описать исходную задачу своими словами.
2. Попросить ИИ найти неоднозначные места и задать уточняющие вопросы.
3. Ответить на них.
4. Сформировать черновую структуру ТЗ.
5. Проверить требования вместе с разработчиком.
6. Зафиксировать итоговую версию документа.

ИИ хорошо помогает не забыть сценарии, ошибки и ограничения, но он не знает реальную архитектуру проекта, особенности интеграций и внутренние правила компании.Не стоит передавать в публичные ИИ-сервисы пароли, API-ключи, персональные данные, закрытый код и другую конфиденциальную информацию без соответствующего разрешения.

Ответы на частые вопросы

Сколько страниц должно быть в техническом задании?

Фиксированного объема нет. Небольшую доработку можно описать на одной странице, а сложный проект потребует более подробного документа. Важна не длина, а однозначность требований.

Кто должен писать ТЗ — заказчик или программист?

Заказчик лучше понимает бизнес-задачу и ожидаемый результат, а разработчик — технические ограничения. Поэтому хороший вариант — подготовить требования со стороны заказчика и согласовать их с исполнителем до начала разработки.

Нужно ли ТЗ для небольшой задачи?

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

Чем ТЗ отличается от брифа?

Бриф помогает собрать исходную информацию и пожелания. Техническое задание фиксирует конкретные требования к разработке и условия приемки результата.

Можно ли просто показать программисту сайт конкурента?

Можно использовать его как референс, но этого недостаточно. Нужно указать, какие именно функции, элементы или сценарии требуется реализовать в вашем проекте.

Что делать, если требования изменились во время разработки?

Изменения нужно зафиксировать и согласовать с исполнителем. Если они увеличивают объем работы, могут измениться сроки и стоимость. Актуальные требования лучше хранить в одном месте, чтобы у команды не было нескольких версий задачи.

Коротко о главном

Хорошее ТЗ для программиста — это не максимально подробный документ и не набор профессиональных терминов.Его задача — сделать требования понятными и проверяемыми.Если разработчик понимает:

• что нужно сделать;
• зачем это делается;
• как должен работать результат;
• какие есть ограничения;
• что не входит в задачу;
• как будет проходить приемка,

значит, техническое задание выполняет свою функцию.