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

Чётко сформулированное техническое задание (ТЗ) – основа успешного сотрудничества с внешним подрядчиком. Оно позволяет избежать недопонимания, сократить количество правок и уложиться в согласованные сроки. Ниже описано, как собрать информацию, оформить документ и проверить его качество перед передачей исполнителю.

Зачем нужно ТЗ и какие принципы лежат в его основе

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

Основные принципы:

• Конкретность – вместо «сделать удобный интерфейс» указывать конкретные элементы и их поведение.
• Измеримость – каждое требование должно допускать объективную проверку (например, время загрузки страницы не более 2 сек).
• Проверяемость – должно быть ясно, как заказчик будет подтверждать выполнение.
• Приоритизация – важные функции выделяются, менее критичные отмечаются как желательные.
• Согласованность – требования не должны противоречить друг другу или ограничениям проекта.

Структура технического задания

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

1. Вводная часть

Кратко описывается проект, заказчик и контекст выполнения работ. Указываются:

• Название проекта и его цель.
• Краткая информация о заказчике (отрасль, основные продукты).
• Ожидаемый результат и основные выгоды для заказчика.

2. Цели и задачи

Формулируются конкретные измеримые цели, которые проект должен достичь. Например:

• Увеличить конверсию формы регистрации на 15 % за три месяца после запуска.
• Сократить время обработки заказа в CRM с 5 до 2 минут.

3. Функциональные требования

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

Пример:

• Система должна позволять пользователю загружать файл размером не более 10 МБ в форматах PDF, DOCX, XLSX.
• После загрузки файл сохраняется в личном кабинете и становится доступным для скачивания в течение 30 дней.

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

В этом блоке фиксируются качественные характеристики: производительность, безопасность, удобство использования, совместимость.

• Страница продукта должна загружаться за 2 сек при соединении 3G.
• Все передаваемые данные шифруются протоколом TLS 1.2 или выше.
• Интерфейс должен соответствовать WCAG 2.1 уровень AA.

5. Ограничения и предположения

Указываются факторы, которые могут повлиять на реализацию:

• Используемый стек технологий: PHP 8.2, PostgreSQL 15, Vue 3.
• Интеграция с существующим API платежного шлюза – доступна только в тестовой среде до 01.10.2025.
• Бюджет на разработку не превышает 1 200 000 руб.

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

Описывается, как заказчик будет проверять выполнение каждого требования. Указываются:

• Методы проверки (тест‑кейсы, демонстрация, аудит кода).
• Приемлемые отклонения (например, допустимая погрешность времени ответа ±0,2 сек).
• Ответственные лица за приемку с каждой стороны.

7. Сроки и этапы

План работы делится на этапы с промежуточными датами и результатами.

1. Этап 1 – анализ и утверждение ТЗ (до 10.11.2025).
2. Этап 2 – прототип основных экранов (до 25.11.2025).
3. Этап 3 – разработка backend и API (до 15.12.2025).
4. Этап 4 – интеграция и внутреннее тестирование (до 30.12.2025).
5. Этап 5 – приемочное тестирование и передача в эксплуатацию (до 15.01.2026).

8. Коммуникация и ответственные лица

Указываются каналы связи, частота встреч и ответственные за согласование:

• Еженедельные статус‑встречи в Zoom по понедельникам 10:00.
• Заказчик – проектный менеджер Игорь Смирнов.
• Подрядчик – техническийリード Анна Петрова.
• Срочные вопросы – в корпоративном чате Slack, канал #project‑alpha.

Как собрать информацию для ТЗ

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

1. Интервью с заказчиком – выявить бизнес‑цели, болевые точки и ожидаемый результат.
2. Анализ существующей системы – документировать текущие workflow, ограничения и интеграции.
3. Составление списка вопросов – охватить функционал, производительность, безопасность, поддержка.
4. Согласование приоритетов – отметить, какие функции обязательны, а какие могут быть отложены.
5. Формирование черновика ТЗ – заполнить каждый раздел собранными данными.

Проверка готового ТЗ

Перед передачей подрядчику документ следует проверить на соответствие принципам и отсутствие двусмысленностей. Используйте следующий чек‑лист:

• Все требования начинаются с глагола действия и содержат измеримый критерий.
• Нет противоречий между функциональными и нефункциональными блоками.
• Ограничения реалистичны и не исключают возможность выполнения обязательных требований.
• Критерии приемки четко описывают, как будет подтверждаться выполнение.
• Сроки этапов согласованы с календарем заказчика и подрядчика.
• Ответственные лица и каналы связи указаны без ambiguity.

Если какой‑то пункт вызывает сомнения – уточните его с заказчиком перед финальной версией.

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

Избегайте следующих pułков, которые часто приводят к доработкам и конфликтам:

• Расплывчатые формулировки. Фразы вроде «сделать систему удобной» не дают четкого ориентира.
• Отсутствие приоритетов. Все требования отмечены как обязательные, что усложняет планирование.
• Противоречия. Например, требование высокой скорости работы и одновременно запрет на использование кэша.
• Игнорирование интеграции. Не указаны форматы обмена данными с существующими системами.
• Неопределенные сроки. Указание «в ближайшее время» вместо конкретных дат.
• Отсутствие критериев приемки. Подрядчик не понимает, когда работа считается завершенной.

Когда достаточно короткого брифа, а когда нужен полный ТЗ

Объем документа зависит от сложности проекта и уровня доверия между сторонами.

Критерий	Краткий бриф (до 2 страниц)	Полный ТЗ (более 2 страниц)
Простой лендинг или одностраничный сайт	Достаточно	Избыточно
Многофункциональная веб‑приложение с интеграциями	Недостаточно	Необходимо
Срочный правка или небольшое улучшение	Достаточно	Избыточно
Проект с жесткими бюджетными и временными ограничениями	Рискованно	Рекомендуется

Если вы не уверены, начните с брифа и после согласования деталей переходите к полному ТЗ.

Следующий шаг после утверждения ТЗ

После того как документ проверен и подписан обеими сторонами, организуйте kickoff‑встречу. На ней:

• Повторно пройдите по ключевым разделам ТЗ, уточните непонятные моменты.
• Определите ответственных за каждый этап и согласуйте календарь встреч.
• Установите порядок приемки промежуточных результатов (демо, отчеты, тест‑кейсы).
• Зафиксируйте каналы escalation для срочных вопросов.

Четкое начало работ снижает риск недопонимания и задает правильный тон всему проекту.

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