Как составить ТЗ: что такое техническое задание, основные требования и ошибки

Техническое задание (ТЗ) для разработчиков — это документ, в котором подробно изложены требования к программному продукту, сайту, приложению или другой системе. Оно описывает запрос заказчика и служит основным ориентиром для команды проекта: разработчиков, тестировщиков и дизайнеров.

Зачем нужно техническое задание

Техническое задание помогает:

• Четко определить объем работы и требования к проекту.
• Обеспечить контроль качества на всех этапах работы.
• Ускорить процесс разработки и снизить количество ошибок.

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

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

1. Общее описание проекта/ функционала
   • Назначение и цели разработки.
   • Краткое описание системы или продукта.

*Краткий комментарий: Важно передать общую цель, ваше видение  вашей команде проекта — в особенности менеджеру. Понял менеджер = понял дизайнер и разработчик.

2. Функциональные требования
   • Описание всех функций и возможностей.
   • Пользовательское взаимодействие с ним заказчика и его сотрудников.

*Краткий комментарий: Всё что вы хотели бы получить и как должно работать нужно донести до исполнителей.

3. Технические требования
   • Cms, фреймворки и языки программирования.
   • Требования к серверной части, базе данных и API.
   • Все вводные данные по используемым технологиям и вспомогательным сервисам.

*Краткий комментарий: Здесь не нужно иметь профобразование и техническую специальность. Выскажите пожелания, пропишите примеры — опытная команда проекта вас скорректирует и посоветуют как лучше.

4. Интерфейс и дизайн
   • Прототипы, макеты или ссылки на дизайн-систему.
   • Описание логики пользовательского интерфейса.

*Краткий комментарий: Если нет готовых макетов — их придется рисовать — пришли те ссылки на сайты, которые вам нравятся. Не хотите заниматься макетами? Спросите нас — есть вариант решения (у нас есть страница Сайты с готовым дизайном? хотела заманить туда)

5. Безопасность и производительность.
   • Ожидаемая нагрузка на сервер, минимальная скорость работы.
   • Защита данных, шифрование, доступы и требования.

*Краткий комментарий: Звучит очень сложно и серьезно — только на первый взгляд. У разработчиков есть опыт и понимание общих стандартов для сайтов для 100 человек и для 10 000 посетителей

6. Тестирование и контроль качества
   • Способы проверки функциональности.
   • Критерии успешного тестирования.

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

7. Сроки и этапы разработки
   • Возможные риски и способы их минимизации.
   • Дедлайны и порядок выполнения работ.

*Краткий комментарий: Сроки могут сдвигаться по разным причинам — лучше сразу это заложить в план.

8. Документация и поддержка
   • Требования к документации по коду.
   • План технической поддержки* после запуска.

*Краткий комментарий: Желательно прописать все ключевые моменты и дополнять на каждом этапе жизненного цикла проекта.

Пункты, которые описаны выше могут меняться или исключаться, главное — структура.

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

Например, техзадание для дизайнера на создание логотипа 

Цель: Создать логотип для интернет-магазина одежды.

Основные требования:

1. Стиль: минимализм, современные тенденции.
2. Цвета: предпочтительно черный, белый, бежевый.
3. Шрифты: лаконичные, без засечек.
4. Форматы файлов: PNG, SVG, AI.
5. Применение: сайт, соцсети, печатная продукция.
6. Референсы (примеры): ссылки на стиль или лого, которые могут быть использованы.
   

Для разработчика необходимо расписывать требования довольно подробно — такие они ребята)
Для них очень высокая цена ошибки, поэтому, лучше однозначно прописать даже логичные детали

Требования к техзаданию

ТЗ для техподдержки: требования к разработке страницы записи на приём к косметологу на OpenCart

1. Общие требования

• Разработка ведётся на OpenCart 3.x.
• Код должен соответствовать стандартам MVC-архитектуры OpenCart.
• Использование OCMod/VqMod для внесения изменений без модификации ядра.
• Поддержка кэширования (если используется OC-Cache).
• Кросс-браузерная совместимость (Chrome, Firefox, Safari, Edge).
• Должна быть адаптивность (Bootstrap 4/5).

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

2.1. Возможности пользователя

✅ На сайте создается новая страница «Запись на приём» (/appointment).
✅ Форма содержит поля:

• Имя (обязательное)
• Телефон (обязательное)
• Email (опционально)
• Дата и время приёма (обязательное, с выбором свободного времени)
• Выбор услуги (выпадающий список)
• Комментарий (опционально)
  ✅ После отправки формы пользователь получает уведомление «Ваша запись принята! Мы свяжемся с вами для подтверждения.»
  ✅ Запись сохраняется в базе данных и отображается в админке OpenCart.
  ✅ Автоматическое email/SMS-уведомление пользователю.

2.2. Возможности администратора

✅ В админке OpenCart (Admin > Записи > Приёмы) добавляется новый раздел, где администратор может:

• Просматривать заявки (ФИО, Телефон, Email, Дата, Время, Услуга, Статус).
• Фильтровать заявки по дате и статусу.
• Менять статус заявки («Ожидает подтверждения», «Подтверждено», «Отменено»).
  ✅ При изменении статуса пользователь получает уведомление по email/SMS.

3. Технические требования

3.1. База данных

✅ Создать таблицу oc_appointments с полями:

• id (INT, PRIMARY KEY, AUTO_INCREMENT) – ID записи
• customer_name (VARCHAR, 255) – имя клиента
• customer_phone (VARCHAR, 20) – телефон
• customer_email (VARCHAR, 255) – email
• appointment_date (DATE) – дата приема
• appointment_time (TIME) – время приема
• service_id (INT) – ID услуги
• comment (TEXT) – комментарий
• status (VARCHAR, 20) – статус записи

3.2. Backend (PHP, OpenCart MVC)

✅ Разработка контроллера appointment.php (catalog/controller/appointment.php).
✅ Разработка модели appointment_model.php (catalog/model/appointment_model.php).
✅ Подключение роутинга (route=appointment/index).

3.3. Frontend (HTML + JS + AJAX)

✅ Форма записи с валидацией (email, телефон).
✅ Использование AJAX для отправки формы без перезагрузки страницы.
✅ Календарь выбора даты и времени (flatpickr.js).
✅ Поле «Выбор услуги» подтягивает данные из каталога (oc_product).
✅ Форма адаптивна (Bootstrap 5).

4. Интеграции

✅ Email-уведомления через mail->send().
✅ SMS-уведомления через API Twilio (twilio.com/docs).
✅ Google reCAPTCHA v2 для защиты от ботов.

5. Производительность и безопасность

✅ SQL-запросы только через $this->db->query() (с защитой от инъекций).
✅ Ограничение частоты записей – не более 1 заявки в 10 минут с одного IP.
✅ Валидация данных (filter_var(), preg_match()).

6. Этапы разработки и сроки

📌 ИТОГО: 13 дней на разработку и тестирование.

Распространенные ошибки при подготовке техзадания

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

1. Размытые, не конкретные требования

🔴 Ошибка: «Приложение должно работать быстро» или «Интерфейс должен быть удобным».
✅ Правильно: «Время отклика сервера не должно превышать 200 мс при 1000 одновременных запросах» или «Все элементы интерфейса должны соответствовать макетам в Figma (ссылка на готовый макет)».

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

2. Отсутствие четкого описания функционала

🔴 Ошибка: «Пользователь должен иметь возможность управлять своими данными».
✅ Правильно:

• «Пользователь может изменять имя, email и пароль в личном кабинете».
• «Данные обновляются после нажатия кнопки Сохранить».

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

3. Несоответствие поставленных задач предоставленным ресурсам

🔴 Ошибка: Использование тяжелых анимаций или сложных алгоритмов без учета производительности.
✅ Правильно: «Сайт должен работать на мобильных устройствах от iPhone 8 и выше, анимации должны быть не дольше 0.3 секунды. Если правило не соблюдается — меняем анимацию на изображения (ссылка на файл)».

📌 Почему это важно: Не все технические решения возможны в рамках ограниченного бюджета или технологий, лучше иметь альтернативный вариант.

4. Противоречивые требования

🔴 Ошибка: В одном разделе написано «Форма регистрации должна быть простой», а в другом «Регистрация возможна только после подтверждения email и ввода паспорта».
✅ Правильно: Убедитесь, что все требования логично связаны между собой.

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

5. Отсутствие UX/UI-требований

🔴 Ошибка: «Сделайте красивый дизайн» без референсов и макетов.
✅ Правильно:

• «Дизайн должен соответствовать цветовой палитре бренда (HEX-коды цветов)».
• «Адаптивность под экраны 320px – 1440px, макеты в Figma».

📌 Почему это важно: Без четких требований дизайн не будет соответствовать ожиданиям.

6. Нет четкого описания API и интеграций

🔴 Ошибка: «Нужно подключить платежную систему».
✅ Правильно: «Оплата через Stripe. API-документация: stripe.com/docs«.

📌 Почему это важно: Если разработчик будет искать документацию самостоятельно — она может быть не той, на которую вы ориентировались. Но абсолютно точно — ему нужно заранее понимать, с какими сервисами предполагается взаимодействие.

7. Игнорирование вопросов безопасности

🔴 Ошибка: «Система должна хранить данные пользователей».
✅ Правильно:

• «Пароли хранятся в зашифрованном виде (bcrypt)».
• «Доступ к API только через JWT-токены».

📌 Почему это важно: В наше время *безопасность нельзя игнорировать.
Мы планируем провести вебинар на тему безопасности 20 февраля 2025г.
Будем вам рады!

8. Отсутствие четких сроков и этапов разработки

🔴 Ошибка: «Проект должен быть готов через 2 месяца».
✅ Правильно:

1. Разработка архитектуры – 2 недели.
2. Backend – 1 месяц.
3. Frontend – 1 месяц.
4. Тестирование – 2 недели.

📌 Почему это важно: Без четкого плана нет понимания по завершению каждого этапа, отсутствуют точки контроля.

9. Нет требований к тестированию

🔴 Ошибка: «Приложение должно работать без багов».
✅ Правильно:

• «Функциональное тестирование перед каждым релизом».
• «Тестирование кросс-браузерности (Chrome, Safari, Edge)».

📌 Почему это важно: Без тестирования приложение может работать нестабильно.

10. Нет плана *поддержки после запуска

🔴 Ошибка: «После сдачи проекта разработчики больше не нужны».
✅ Правильно:

• «Гарантийный период – 3 месяца после релиза».
• «Обновления – раз в квартал».

📌 Почему это важно: После запуска всегда находятся баги и доработки — невозможно всё предусмотреть и проверить заранее.

*Техническая поддержка и развитие важный этап жизненного цикла проекта после его релиза.

Составление технического задания: пошаговый план действий

Как же составить ТЗ, чтобы команда проекта четко видела, что  вы хотите от них, как заказчик, смогла декомпозировать задачи, обозначила сроки их выполнения, оценила задачи и выполнила все эти договоренности?

1. Определите цель проекта/ создаваемой доработки

Чтобы написать ТЗ, ответьте на главные на вопросы:

• Какую проблему решает проект?
• Кто будет пользоваться продуктом/ доработкой?
• Какие задачи он должен выполнять?

✍ Пример:
Проект: Интернет-магазин электроники.
Цель: Создать удобную платформу для продажи товаров с возможностью оформления заказов онлайн.
Целевая аудитория: Люди, которые покупают технику через интернет (формулировка общая для упрощения, определение ЦА и характеристика каждого её сегмента должна проводиться более подробно) 

2. Опишите основные функции

Здесь пропишите, какие задачи должен выполнять продукт/ проект/ доработка

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

1. Регистрация и авторизация
   • Возможность входа через email и соцсети.
   • Восстановление пароля через email.
2. Каталог товаров
   • Фильтры по цене, бренду, категории.
   • Сортировка по рейтингу и популярности.
3. Корзина и оформление заказа
   • Добавление и удаление товаров.
   • Выбор способов оплаты (перечисляем, которые хотим видеть на сайте)
   • Выбор способов доставки (перечислим, которые планируем использовать)
4. Личный кабинет
   • Просмотр истории заказов.
   • Управление персональными данными.
   • Двусторонняя интеграция с 1С

✍ Пример описания в одном из пунктов:
«Пользователь должен иметь возможность добавить товар в корзину. Если товара нет в наличии, кнопка «Купить» должна быть неактивной.»

3. Опишите технические требования

Определите, какие технологии вы хотели бы использовать

• Frontend: React + TypeScript
• Backend: Node.js + NestJS
• База данных: PostgreSQL
• API: REST/GraphQL
• Хостинг: AWS, Docker

4. Укажите требования к дизайну

• Дизайн должен быть адаптивным для мобильных устройств
• Ссылка на макеты в Figma

✍ Пример:
«Дизайн интерфейса должен соответствовать макетам в Figma (ссылка).
Все элементы должны быть адаптированы под экраны от 320px до 1440px.»

5. Безопасность и производительность

• Как у вас будут защищены персональные данные пользователей?
• Какие есть ограничения по нагрузке на сервер?
• Будет ли использована защита от DDoS-атак?

✍ Пример:
«Все пароли должны храниться в зашифрованном виде (bcrypt, SHA-256). Доступ к API – только через авторизованные запросы с JWT-токенами.»

6. Этапы разработки и сроки

Разбейте работу на этапы:

1. Разработка архитектуры – 2 недели
2. Программирование Backend – 1 месяц
3. Разработка Frontend – 1 месяц
4. Тестирование – 2 недели
5. Запуск MVP – Дата: 01.06.2024

✍ Пример записи:
«На каждом этапе работы разработчики должны передавать промежуточные результаты по проекту/ продукту.»

7. Тестирование и отладка

• Здесь нужно расписать, какие тесты могут быть проведены, например:
  • Функциональные (работоспособность всех кнопок).
  • Нагрузочные (выдерживает ли сайт 1000 пользователей одновременно).
• На каком этапе тестирует команда проекта, на каком — команда заказчика

✍ Пример::
«Приложение должно пройти тестирование на различных устройствах (Windows, Mac, iOS, Android). Разрешено использовать эмуляторы.
Перед релизом необходимо исправить  все критические баги»

8. Поддержка и документация

• Кто будет поддерживать проект после релиза, план для технической поддержки
• Установить порядок поддержания документации проекта

✍ Пример:
«После сдачи проекта разработчики осуществляют гарантированное обслуживание проекта в течение полугода в рамках 10ч ежемесячно.
Задачи, не вошедшие в первоначальное ТЗ являются доработками и оцениваются отдельно.»

Итак, как выглядит итоговое ТЗ?

🔹 Цель проекта – описание задач, которые решает проект, его целей, конечных пользователей
🔹 Функциональность – что и как должен делать сайт/ приложение.
🔹 Технологии – список желаемых инструментов — здесь важно, чтобы этот момент можно было скорректировать с командой проекта
🔹 Дизайн – требования к стилю, адаптивности, UI/UX.
🔹 Безопасность – защита данных и производительность.
🔹 Этапы и сроки – когда и что будет готово, как что является результатом каждого этапа.
🔹 Тестирование – как и кем проверяем работоспособность.
🔹 Поддержка – кто отвечает за продукт после релиза, в каком объеме осуществляется техническая поддержка

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

Важно найти исполнителей, с которыми было бы не страшно начать важное дело. Готовы встретиться с вами, помочь облачить ваши идеи и требования в конкретные формы и оценить эти задачи в реализацию.