Полное руководство по составлению технического задания для IT-проекта

Введение

Техническое задание (ТЗ) — это фундамент любого успешного IT-проекта. Это документ, который описывает, что именно нужно создать, как это должно работать и какие результаты ожидаются. Качественное ТЗ экономит деньги, время и нервы, а плохое или отсутствующее ТЗ приводит к бесконечным правкам, конфликтам с исполнителями и провалу проекта.

Согласно исследованиям, около 70% IT-проектов превышают бюджет или сроки именно из-за неправильно составленного или отсутствующего технического задания. Для предпринимателя это означает прямые финансовые потери и упущенные возможности на рынке.

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

Основные функции ТЗ

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

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

Минимизация правок. Чем точнее описано, что нужно сделать, тем меньше итераций доработок потребуется. Каждая правка стоит денег и времени.

Основа для тестирования. ТЗ определяет критерии приемки работы. Без них невозможно объективно оценить, выполнена ли работа качественно.

Коммуникация между специалистами. Если над проектом работает команда, ТЗ обеспечивает единое понимание задач всеми участниками.

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

1. Общая информация о проекте

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

Что включить:

Название проекта и краткое описание в 2-3 предложениях. Например: "Мобильное приложение для заказа доставки продуктов из локальных фермерских хозяйств. Приложение соединяет покупателей напрямую с фермерами, минуя посредников".

Информация о компании-заказчике. Укажите сферу деятельности, масштаб бизнеса, особенности работы. Это поможет разработчикам понять контекст и предложить оптимальные решения.

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

2. Бизнес-цели и задачи

Это критически важный раздел, который многие упускают. Разработчики должны понимать не просто что делать, но и зачем.

Опишите бизнес-цели:

Какую проблему решает продукт? Например: "Наши клиенты тратят слишком много времени на оформление заказов по телефону, что приводит к потере 30% потенциальных покупателей".

Какие показатели бизнеса должны улучшиться? Конкретные метрики: увеличение конверсии на 25%, сокращение времени обработки заказа с 10 до 2 минут, снижение нагрузки на колл-центр на 50%.

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

Какие есть бизнес-ограничения? Например, бюджет не более 500 тысяч рублей, запуск обязательно до начала сезона, интеграция с существующей учетной системой обязательна.

3. Описание целевой аудитории и пользователей

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

Создайте пользовательские персоны:

Для каждого типа пользователей опишите портрет. Например:

"Мария, 35 лет, менеджер среднего звена. Пользуется смартфоном iPhone 12. Ценит простоту и скорость. Делает заказы в обеденный перерыв или вечером. Не очень технически подкована, нуждается в интуитивном интерфейсе. Главная мотивация — экономия времени и качественные продукты".

"Владимир, 52 года, фермер. Использует Android-смартфон. Не очень уверенно пользуется приложениями. Нужен простой интерфейс с крупными кнопками. Основная задача — получать заказы и подтверждать наличие товара. Работает на улице, часто в условиях плохой связи".

Для каждой персоны опишите основные сценарии использования продукта, болевые точки, ожидания от продукта.

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

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

Принципы описания функционала:

Используйте формулировку "Система должна...". Например: "Система должна позволять пользователю зарегистрироваться через email или номер телефона".

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

Указывайте приоритеты функций. Используйте категории: критичные (must have), важные (should have), желательные (nice to have). Это поможет при необходимости сокращения бюджета или сроков.

Пример детального описания функции:

Функция: Регистрация пользователя

Приоритет: Критичный

Описание: Система должна позволять новым пользователям создавать учетную запись.

Сценарий:

1. Пользователь нажимает кнопку "Зарегистрироваться" на главном экране
2. Система отображает форму регистрации с полями: имя, email, телефон, пароль, повтор пароля
3. Пользователь заполняет поля и нажимает "Создать аккount"
4. Система проверяет корректность данных (формат email, длина пароля не менее 8 символов, пароли совпадают)
5. Если данные некорректны, система показывает сообщение об ошибке под соответствующим полем
6. Если данные корректны, система отправляет код подтверждения на указанный email/телефон
7. Пользователь вводит код подтверждения
8. Система создает учетную запись и автоматически авторизует пользователя
9. Система перенаправляет пользователя на главный экран приложения

Альтернативные сценарии:

• Если email уже зарегистрирован, система показывает сообщение "Этот email уже используется" и предлагает восстановить пароль
• Если код подтверждения не приходит, пользователь может запросить повторную отправку через 60 секунд
• Пользователь может зарегистрироваться через социальные сети (Google, Apple ID)

Бизнес-правила:

• Один email может быть привязан только к одному аккаунту
• Минимальная длина пароля — 8 символов
• Код подтверждения действителен 15 минут
• После 3 неудачных попыток ввода кода, запросить новый код можно только через 5 минут

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

Эти требования определяют качественные характеристики системы.

Производительность:

Максимальное время загрузки страницы — 3 секунды. Система должна поддерживать одновременную работу 1000 пользователей без деградации производительности. Время отклика API — не более 500 миллисекунд.

Надежность:

Доступность системы — 99.5% времени (допустимый простой не более 3.6 часа в месяц). Система должна автоматически создавать резервные копии данных каждые 24 часа. При сбое система должна восстанавливаться автоматически в течение 15 минут.

Безопасность:

Все пароли должны храниться в зашифрованном виде. Передача данных должна осуществляться по защищенному протоколу HTTPS. Система должна блокировать учетную запись после 5 неудачных попыток входа. Персональные данные пользователей должны храниться в соответствии с законом о защите персональных данных (152-ФЗ). Платежные данные не должны храниться в системе, обработка платежей через PCI DSS сертифицированный сервис.

Масштабируемость:

Система должна позволять увеличение числа пользователей до 10 000 без изменения архитектуры. Возможность горизонтального масштабирования серверной части.

Совместимость:

Веб-версия должна корректно работать в браузерах Chrome (последние 2 версии), Safari (последние 2 версии), Firefox (последние 2 версии). Мобильная версия должна поддерживать iOS 14+ и Android 9+. Адаптивный дизайн для экранов от 320px до 2560px по ширине.

Юзабилити:

Новый пользователь должен иметь возможность зарегистрироваться и сделать первый заказ без обучения за 5 минут. Все основные функции должны быть доступны не более чем за 3 клика. Интерфейс должен соответствовать принципам accessibility (WCAG 2.1 уровень AA).

6. Дизайн и пользовательский интерфейс

Общие требования к дизайну:

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

Требования к макетам:

Укажите, нужны ли прототипы перед разработкой (рекомендуется). Определите, на каких устройствах нужны отдельные макеты (desktop, tablet, mobile). Укажите состояния, которые нужно отрисовать (пустые экраны, экраны с данными, состояния загрузки, ошибки).

Важные элементы:

Логотип и его размещение. Навигация и структура меню. Формы ввода данных и их валидация. Кнопки и их состояния (обычное, hover, нажатие, неактивное). Уведомления и сообщения об ошибках. Модальные окна и всплывающие элементы.

7. Интеграции с внешними системами

Если ваш продукт должен взаимодействовать с другими системами, детально опишите это.

Для каждой интеграции укажите:

С какой системой интеграция (название, версия, производитель). Цель интеграции (какие данные передаются, с какой частотой). Доступные методы интеграции (API, файловый обмен, веб-хуки). Формат данных (JSON, XML, CSV). Есть ли документация по API, доступы для тестирования. Требования к синхронизации (реального времени, раз в час, раз в сутки). Как обрабатывать ошибки интеграции.

Типичные интеграции:

Платежные системы (Сбербанк, ЮKassa, Stripe). CRM-системы (Битрикс24, amoCRM, Salesforce). Системы аналитики (Google Analytics, Яндекс.Метрика). Email-сервисы (SendGrid, Mailchimp). SMS-шлюзы (SMSC, Twilio). Системы учета (1С, SAP). Социальные сети (авторизация, шаринг). Картографические сервисы (Google Maps, Яндекс.Карты).

8. Техническая архитектура

Даже если вы не технический специалист, некоторые технические решения нужно зафиксировать.

Укажите, если известно:

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

Если у вас есть существующая инфраструктура:

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

9. Этапы разработки и критерии приемки

Разбейте проект на логические этапы (вехи, milestone).

Типичные этапы:

Этап 1: Проектирование (2 недели)

• Создание прототипов основных экранов
• Согласование прототипов с заказчиком
• Создание дизайн-макетов
• Согласование дизайна Критерии приемки: утвержденные прототипы и дизайн-макеты всех экранов

Этап 2: Разработка MVP (6 недель)

• Реализация критичного функционала
• Базовая административная панель
• Интеграция с платежной системой Критерии приемки: работающая версия с критичными функциями, успешное тестирование основных сценариев

Этап 3: Доработка и тестирование (3 недели)

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

Этап 4: Запуск и поддержка (2 недели)

• Развертывание на продуктивном сервере
• Обучение администраторов
• Мониторинг первых пользователей Критерии приемки: система работает стабильно, обучение проведено

Для каждого этапа определите:

Сроки начала и завершения. Список конкретных результатов (deliverables). Критерии приемки (как вы поймете, что этап завершен успешно). Ответственных лиц. Процедуру приемки (кто и как тестирует, сколько времени на приемку, как оформляются замечания).

10. Роли и ответственность

Четко определите, кто за что отвечает в проекте.

Со стороны заказчика:

Владелец продукта (принимает ключевые решения, приоритизирует функционал). Технический контакт (отвечает на технические вопросы, предоставляет доступы). Контент-менеджер (предоставляет тексты, изображения, данные). Тестировщик (проверяет работу на каждом этапе).

Со стороны исполнителя:

Проект-менеджер (координирует работу команды, коммуникация с заказчиком). Аналитик (уточняет требования, документирует функционал). Дизайнер (создает макеты и прототипы). Разработчики (создают программный код). Тестировщик (проверяет качество работы). DevOps-инженер (настраивает серверы, развертывание).

11. Коммуникация и отчетность

Определите регламент взаимодействия.

Регулярные встречи:

Еженедельные созвоны по статусу проекта (день, время, участники, формат). Демонстрации готовой работы (раз в 2 недели, показ функционирующих частей). Планирование спринтов (если используется Agile-подход).

Инструменты коммуникации:

Основной канал (email, мессенджер, корпоративный портал). Система управления задачами (Jira, Trello, Asana). Хранилище документов (Google Drive, Confluence). Для срочных вопросов (телефон, Telegram).

Отчетность:

Еженедельные отчеты о прогрессе (что сделано, что планируется, проблемы). Трекинг времени (если оплата почасовая). Уведомления об изменениях сроков или бюджета.

12. Бюджет и условия оплаты

Зафиксируйте финансовые договоренности.

Укажите:

Общий бюджет проекта или бюджет на каждый этап. Валюта и условия оплаты. График платежей (например: 30% аванс, 40% после приемки MVP, 30% после финального запуска). Что входит в стоимость (разработка, дизайн, тестирование, развертывание). Что не входит в стоимость (дополнительный функционал, изменения после согласования, контент, обучение пользователей). Процедура изменения бюджета (при добавлении нового функционала, изменении требований). Штрафные санкции за нарушение сроков (если предусмотрены).

13. Авторские права и конфиденциальность

Юридические аспекты проекта.

Права на результаты работы:

Кому принадлежат исключительные права на программное обеспечение. Кому принадлежат права на дизайн. Может ли исполнитель использовать проект в портфолио. Может ли исполнитель использовать наработки в других проектах.

Конфиденциальность:

NDA (соглашение о неразглашении) — требуется ли, когда подписывается. Какая информация является конфиденциальной. Обязательства по защите данных пользователей. Ответственность за утечку информации.

14. Гарантии и поддержка

Что происходит после запуска проекта.

Гарантийный период:

Длительность гарантии (типично 1-3 месяца). Что входит в гарантию (исправление ошибок, которые были на момент сдачи проекта). Что не входит в гарантию (новый функционал, изменения требований, ошибки из-за действий заказчика). Время реакции на критичные ошибки.

Пост-гарантийная поддержка:

Условия дальнейшей поддержки (почасовая оплата, абонентская плата, пакеты часов). Что включает поддержка (исправление ошибок, консультации, мелкие доработки). Время реакции на обращения. Условия развития продукта (новый функционал, масштабирование).

15. Документация

Какая документация должна быть передана по завершении проекта.

Техническая документация:

Описание архитектуры системы. Документация API (если есть). Схема базы данных. Инструкция по развертыванию. Инструкция по настройке серверов. Документация кода (комментарии, описание модулей).

Пользовательская документация:

Руководство администратора. Руководство пользователя. FAQ (часто задаваемые вопросы). Видеоинструкции (если предусмотрены).

16. Риски и ограничения

Опишите известные риски и ограничения проекта.

Технические риски:

Сложность интеграции с внешними системами. Ограничения сторонних сервисов. Риски производительности при высоких нагрузках.

Организационные риски:

Зависимость от предоставления данных/контента от заказчика. Зависимость от согласований третьих сторон. Риски изменения требований в процессе разработки.

Смягчение рисков:

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

Чего НЕ должно быть в техническом задании

Распространенные ошибки

Расплывчатые формулировки:

Неправильно: "Система должна работать быстро" Правильно: "Время загрузки страницы не должно превышать 3 секунд"

Неправильно: "Дизайн должен быть современным и красивым" Правильно: "Дизайн в стиле минимализм, цветовая схема: белый фон, акцентный цвет #3498db, шрифт Inter, референсы: Airbnb, Stripe"

Технический жаргон без объяснений:

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

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

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

Описание решений вместо задач:

Неправильно: "Сделайте регистрацию через OAuth 2.0 с использованием JWT токенов" Правильно: "Пользователь должен иметь возможность зарегистрироваться через социальные сети (Google, Facebook). Предложите оптимальное техническое решение"

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

Избыточная детализация мелочей:

Не нужно описывать цвет каждой кнопки и размер каждого шрифта в ТЗ. Для этого есть дизайн-макеты. В ТЗ указывайте функциональные требования и общие принципы дизайна.

Функции "на будущее":

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

Отсутствие приоритетов:

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

Нереалистичные ожидания:

Не требуйте создать "приложение как Uber" за 100 тысяч рублей и месяц работы. Uber разрабатывали сотни специалистов несколько лет. Будьте реалистичны в ожиданиях по соотношению функционала, бюджета и сроков.

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

Подготовка

Шаг 1: Исследование и анализ

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

Шаг 2: Определение scope (объема работ)

Составьте список всех желаемых функций. Проранжируйте их по важности. Определите MVP — минимальный набор функций для запуска. Оцените примерный бюджет и сроки.

Шаг 3: Выбор исполнителя

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

Составление ТЗ

Шаг 4: Написание черновика

Используйте структуру, описанную выше. Пишите простым языком. Добавляйте визуальные материалы (схемы, скриншоты, примеры). Не пытайтесь написать идеальное ТЗ сразу.

Шаг 5: Обсуждение с исполнителем

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

Шаг 6: Доработка и согласование

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

После подписания ТЗ

Управление изменениями:

Любые изменения в ТЗ после начала работы должны оформляться официально. Создайте процедуру запроса изменений (Change Request). Каждое изменение должно быть оценено по влиянию на сроки и бюджет. Критичные изменения требуют пересогласования всего плана проекта.

Регулярный пересмотр:

В долгих проектах (более 3-6 месяцев) проводите периодический пересмотр ТЗ. Рынок меняется, могут появиться новые требования законодательства, конкуренты могут выпустить новые функции.

Инструменты для работы с ТЗ (продолжение)

Документирование

Confluence / Notion — wiki-системы для структурированного хранения документации. Позволяют создавать связанные страницы, встраивать медиа, организовывать иерархию документов. Удобны для больших проектов с множеством разделов.

Miro / Figma — для создания визуальных схем, user flow, диаграмм процессов. Помогают наглядно показать логику работы системы и пользовательские сценарии.

Прототипирование

Figma / Sketch / Adobe XD — для создания интерактивных прототипов интерфейса. Позволяют показать, как будет работать продукт, до начала разработки.

Balsamiq / Axure — для быстрых низкодетализированных прототипов (wireframes). Полезны на этапе согласования структуры и логики.

InVision / Marvel — для создания кликабельных прототипов из статичных макетов.

Управление проектом

Jira / YouTrack — системы управления задачами для разработки. Позволяют декомпозировать ТЗ на задачи, отслеживать прогресс, фиксировать ошибки.

Trello / Asana — более простые инструменты для управления задачами. Подходят для небольших проектов.

GitHub / GitLab — для технических проектов, где важен контроль версий кода и документации.

Коммуникация

Slack / Microsoft Teams — для оперативного общения команды. Позволяют создавать каналы по темам, интегрируются с другими инструментами.

Zoom / Google Meet — для видеовстреч и демонстраций.

Loom — для записи видеообъяснений и демонстрации экрана. Полезно для асинхронной коммуникации.

Особенности ТЗ для разных типов проектов

Мобильное приложение

Дополнительные разделы:

• Платформы: iOS, Android или кроссплатформенное решение (React Native, Flutter)
• Версии ОС: минимальные поддерживаемые версии iOS и Android
• Разрешения: какие разрешения требуются (камера, геолокация, уведомления, контакты)
• Оффлайн-режим: что должно работать без интернета, как синхронизировать данные
• Push-уведомления: типы уведомлений, когда отправляются, как настраиваются пользователем
• Публикация: требования к App Store и Google Play, сертификаты, процесс модерации
• Обновления: стратегия обновления приложения, обязательные и необязательные обновления

Веб-приложение

Дополнительные разделы:

• SEO требования: мета-теги, sitemap, скорость загрузки, мобильная оптимизация
• Аналитика: какие события отслеживать, какие метрики важны
• Многоязычность: какие языки поддерживать, где хранятся переводы, RTL-языки
• Админ-панель: функционал для управления контентом, пользователями, настройками
• Email-уведомления: какие письма отправляются, шаблоны, триггеры

E-commerce проект

Дополнительные разделы:

• Каталог товаров: структура категорий, атрибуты товаров, фильтры, сортировка
• Корзина и оформление заказа: процесс чекаута, способы доставки, расчет стоимости
• Платежи: способы оплаты, валюты, обработка возвратов
• Личный кабинет: история заказов, избранное, списки желаний
• Промокоды и акции: типы скидок, условия применения, ограничения
• Управление запасами: учет остатков, резервирование товаров, уведомления о наличии
• Интеграция с ERP/CRM: синхронизация заказов, клиентов, товаров
• Отзывы и рейтинги: модерация, ответы продавца, фото от покупателей

CRM-система

Дополнительные разделы:

• Сущности системы: клиенты, сделки, задачи, документы и связи между ними
• Воронка продаж: этапы, правила перемещения, автоматизация
• Роли и права доступа: кто что может видеть и редактировать
• Отчеты и аналитика: какие отчеты нужны, фильтры, экспорт данных
• Автоматизация: триггеры, автоматические задачи, уведомления
• Интеграция с телефонией: запись звонков, история коммуникаций
• Email-маркетинг: рассылки, сегментация, шаблоны

Чек-лист готовности ТЗ

Перед передачей ТЗ исполнителю проверьте:

Полнота

• Описаны все основные функции продукта
• Указаны все интеграции с внешними системами
• Определены роли пользователей и их права
• Описаны все бизнес-процессы и сценарии использования
• Указаны нефункциональные требования (производительность, безопасность)
• Приложены визуальные материалы (схемы, примеры, референсы)

Ясность

• Используются конкретные формулировки, а не общие фразы
• Нет двусмысленных или противоречивых требований
• Технические термины объяснены или есть глоссарий
• Каждое требование можно проверить (есть критерий выполнения)

Приоритеты

• Функции разделены на критичные, важные и желательные
• Определен MVP — минимальный набор для запуска
• Есть план действий при нехватке бюджета или времени

Организация

• Определены этапы разработки и сроки
• Для каждого этапа указаны критерии приемки
• Назначены ответственные лица с обеих сторон
• Определен регламент коммуникации
• Согласован бюджет и условия оплаты

Юридические аспекты

• Определены права на результаты работы
• Подписан NDA, если требуется
• Указаны условия гарантии и поддержки
• Описана процедура изменения ТЗ

Типичные проблемы и их решения

Проблема: "ТЗ слишком большое, никто не будет это читать"

Решение:

• Создайте executive summary — краткое описание на 1-2 страницы
• Используйте структуру с понятными заголовками
• Добавьте оглавление с гиперссылками
• Визуализируйте сложные моменты схемами и диаграммами
• Разбейте документ на модули, которые можно читать независимо

Проблема: "Мы не знаем всех деталей заранее, проект будет меняться"

Решение:

• Используйте гибкую методологию (Agile, Scrum)
• Создайте ТЗ для MVP, остальное — в backlog
• Установите процедуру изменений с оценкой влияния
• Планируйте итеративно — спринтами по 2-4 недели
• Включите в договор резерв времени и бюджета на изменения (10-20%)

Проблема: "Разработчик говорит, что это невозможно реализовать"

Решение:

• Спросите причины: технические ограничения, стоимость, сроки?
• Попросите предложить альтернативное решение
• Если вопрос в стоимости, пересмотрите приоритеты
• Получите второе мнение от другого специалиста
• Возможно, требование сформулировано неправильно — уточните цель, а не способ

Проблема: "ТЗ постоянно меняется, проект никогда не закончится"

Решение:

• Заморозьте изменения на период разработки текущего этапа
• Все новые идеи складывайте в backlog для следующих версий
• Каждое изменение оценивайте по влиянию на сроки и бюджет
• Устанавливайте дедлайны для согласования изменений
• Используйте правило "scope freeze" за N недель до дедлайна

Проблема: "Заказчик и разработчик по-разному понимают требования"

Решение:

• Используйте прототипы и макеты для визуализации
• Проводите регулярные демонстрации готовой работы
• Внедрите практику "acceptance criteria" — четкие критерии для каждой функции
• Записывайте важные обсуждения и решения
• Используйте примеры и сценарии использования

Стоимость разработки и ТЗ

Как ТЗ влияет на стоимость

С детальным ТЗ:

• Точная оценка стоимости (±10-15%)
• Меньше изменений в процессе разработки
• Меньше итераций доработок
• Прозрачность использования бюджета
• Итог: стоимость может быть выше на этапе оценки, но итоговые затраты ниже

Без ТЗ или с расплывчатым ТЗ:

• Приблизительная оценка (±50-100%)
• Множество изменений и правок
• Конфликты по оплате дополнительных работ
• Риск превышения бюджета в 2-3 раза
• Итог: кажется дешевле на старте, но реальные затраты значительно выше

Кто должен составлять ТЗ

Варианты:

1. Заказчик самостоятельно — если есть опыт и техническая экспертиза

• Плюсы: глубокое понимание бизнеса, контроль процесса
• Минусы: риск упустить технические аспекты, больше времени

1. Бизнес-аналитик на стороне заказчика — для крупных компаний

• Плюсы: профессиональное качество, защита интересов заказчика
• Минусы: дополнительные затраты на аналитика

1. Совместно с исполнителем — самый распространенный вариант

• Плюсы: баланс бизнес-экспертизы и технических знаний
• Минусы: нужно четко разделить ответственность, оплачивается отдельно

1. Исполнитель полностью — если заказчик не знает, что хочет

• Плюсы: быстро, профессионально
• Минусы: высокий риск несоответствия ожиданиям, конфликт интересов

Рекомендация: Оптимальный вариант — совместная работа, где заказчик описывает бизнес-требования, а исполнитель дополняет техническими деталями.

Альтернативы классическому ТЗ

User Stories (Пользовательские истории)

Формат Agile-методологии. Вместо детального ТЗ — набор историй:

"Как [роль] я хочу [действие], чтобы [цель]"

Пример:

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

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

Job Stories

Альтернатива User Stories с фокусом на контекст:

"Когда [ситуация], я хочу [мотивация], чтобы [ожидаемый результат]"

Пример:

• Когда я еду на работу в метро, я хочу быстро просмотреть новости, чтобы быть в курсе событий за 5 минут

Lean Canvas + Roadmap

Для стартапов — одностраничный бизнес-план + дорожная карта развития продукта вместо детального ТЗ. Разработка идет итерациями с постоянной валидацией гипотез.

Когда можно обойтись без ТЗ

• Очень маленькие проекты (лендинг на 1-2 страницы)
• Типовые решения (например, сайт-визитка по шаблону)
• Проекты с фиксированным функционалом (например, интеграция готового плагина)

Но даже в этих случаях минимальное описание требований необходимо.

Заключение

Техническое задание — это не бюрократия и не формальность. Это инструмент, который:

• Экономит деньги — предотвращает дорогостоящие переделки
• Экономит время — сокращает количество правок и недопониманий
• Снижает риски — фиксирует договоренности и защищает интересы
• Повышает качество — задает четкие критерии результата

Главный принцип: лучше потратить больше времени на планирование, чем столкнуться с проблемами в разработке.

Три уровня зрелости ТЗ

Базовый уровень (минимально необходимый):

• Описание функционала
• Основные пользовательские сценарии
• Критерии приемки
• Бюджет и сроки

Продвинутый уровень (для серьезных проектов):

• Детальные требования
• Прототипы и макеты
• Интеграции и нефункциональные требования
• Этапы и процедуры

Профессиональный уровень (для крупных систем):

• Полная документация всех аспектов
• Техническая архитектура
• Риски и стратегии смягчения
• Регламенты и стандарты

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

Последний совет

Помните: ТЗ — это живой документ. Он должен развиваться вместе с проектом. Не бойтесь вносить изменения, но делайте это осознанно, с оценкой последствий.

Чек-лист (Master Checklist) для проверки ТЗ IT-проекта.

Блок 1. Бизнес-контекст и Общие положения

Эти пункты защищают вас от создания продукта, который работает, но никому не нужен.

• [ ] Глоссарий: Определены ли все специфические термины? (Что такое «лид», «сделка», «агрегатор» именно в вашей системе?).
• [ ] Целевая аудитория (Persona): Четко ли описано, кто пользуется системой? (Возраст, техническая грамотность, устройства).
• [ ] Монетизация: Описано ли технически, в какой момент вы берете деньги? (Подписка, разовая покупка, комиссия с транзакции, Freemium).
• [ ] География и Время: На какие часовые пояса рассчитан проект? (Нужно ли хранить время в UTC и конвертировать для пользователя?).
• [ ] Языки (Локализация): Нужна ли мультиязычность? Как хранятся переводы? (В коде или в админке).
• [ ] Список платформ: Web (Desktop/Mobile), iOS (версии), Android (версии).
• [ ] Браузерная поддержка: Поддерживаем ли старые браузеры (Safari 10, старые Chrome)? Нужно ли поддерживать Internet Explorer (обычно нет, но лучше зафиксировать).

Блок 2. Пользователи и Права доступа (RBAC)

Здесь чаще всего забывают про внутреннюю кухню проекта.

• [ ] Матрица ролей: Полный список (Гость, Юзер, Премиум-юзер, Менеджер, Админ, Супер-Админ).
• [ ] Регистрация:
• [ ] По email/телефону/соцсетям (каким?).
• [ ] Требуется ли подтверждение (ссылка на почту, SMS-код)?
• [ ] Есть ли капча (защита от ботов)?
• [ ] Авторизация:
• [ ] Как долго живет сессия? (Выбрасывает через 15 минут или "запомнить меня" навечно?).
• [ ] Что происходит при входе с нового устройства?
• [ ] Восстановление доступа: Сценарий "Забыл пароль". Сценарий "Потерял доступ к телефону".
• [ ] Удаление аккаунта: Может ли пользователь сам удалиться? (Требование App Store). Данные стираются или просто скрываются (Soft delete)?

Блок 3. Интерфейс (UX/UI) и Состояния

Дизайн — это не только когда все хорошо, но и когда все сломалось.

• [ ] Happy Path: Описан идеальный сценарий работы.
• [ ] Состояния загрузки (Loaders): Что видит юзер, пока грузятся данные? (Спиннер, скелетон, прогресс-бар).
• [ ] Пустые состояния (Empty States): Как выглядит корзина, если она пуста? Как выглядит поиск, если ничего не найдено?
• [ ] Ошибки валидации: Как подсвечиваются поля при ошибке? Текст ошибок прописан?
• [ ] 404 и 500: Есть ли дизайн страниц "Страница не найдена" и "Ошибка сервера"?
• [ ] Уведомления (Toasts/Popups): Как система сообщает об успехе ("Сохранено") или ошибке?
• [ ] Анимации: Описаны ли переходы между экранами и микро-анимации кнопок?

Блок 4. Работа с данными и Функционал (Детализация)

Самый объемный блок. Проверяем логику.

• [ ] Поиск:
• [ ] По каким полям ищем?
• [ ] Нужен ли "живой поиск" (подсказки при вводе)?
• [ ] Учитываем ли опечатки (Fuzzy search)?
• [ ] История поиска сохраняется?
• [ ] Фильтрация и Сортировка:
• [ ] Какие параметры фильтров? (Диапазоны цен, чекбоксы).
• [ ] Сбрасываются ли фильтры при обновлении страницы?
• [ ] Формы ввода:
• [ ] Ограничения по символам (макс. длина имени, формат телефона).
• [ ] Можно ли вводить эмодзи?
• [ ] Автозаполнение адресов (интеграция с картами/Дадата)?
• [ ] Работа с файлами:
• [ ] Какие форматы разрешены (JPG, PNG, PDF)?
• [ ] Максимальный вес файла (чтобы не положили сервер).
• [ ] Можно ли загружать несколько файлов сразу?
• [ ] Нужна ли обрезка фото (кроп) перед загрузкой (напр. для аватарок)?

Блок 5. Админ-панель (Back-office)

Без этого блока вы не сможете управлять бизнесом.

• [ ] Дашборд: Видит ли админ сводную статистику (новые юзеры за день, выручка)?
• [ ] Управление контентом (CMS):
• [ ] Редактирование текстов на лендинге.
• [ ] Загрузка баннеров.
• [ ] Модерация отзывов/комментариев.
• [ ] Управление пользователями:
• [ ] Просмотр профиля юзера.
• [ ] Ручная блокировка (Бан) с причиной.
• [ ] Просмотр истории действий юзера (Логи).
• [ ] Экспорт данных: Есть ли кнопка "Скачать в Excel/CSV" (заказы, юзеры)?

Блок 6. Интеграции и API

Как ваша система общается с внешним миром.

• [ ] Платежный шлюз:
• [ ] Сценарий успешной оплаты.
• [ ] Сценарий отказа (недостаточно средств).
• [ ] Рекуррентные платежи (автосписания).
• [ ] Возвраты (автоматические или ручные через админку?).
• [ ] Email/SMS сервисы: Кто отправляет письма (SendGrid, Unisender)? Шаблоны писем сверстаны?
• [ ] Карты/Гео: Google Maps, Yandex, OpenStreet? (Учтена ли платность API?).
• [ ] Обработка сбоев: Что делает система, если внешний сервис (например, банк) не отвечает? (Повторяет запрос или выдает ошибку?).

Блок 7. Технические и Нефункциональные требования

Фундамент дома.

• [ ] Нагрузка:
• [ ] Ожидаемое кол-во пользователей (DAU/MAU).
• [ ] Пиковые нагрузки (например, в "Черную пятницу").
• [ ] Скорость: Требования к Time to Interactive (время до возможности нажать кнопку).
• [ ] SEO-подготовка (для Web):
• [ ] Server Side Rendering (SSR) — обязательно для индексации поисковиками (особенно если React/Vue).
• [ ] Возможность менять Meta-теги (Title, Description) из админки.
• [ ] Генерация Sitemap.xml и Robots.txt.
• [ ] Безопасность:
• [ ] Хранение паролей (только хэши!).
• [ ] Защита от SQL-инъекций и XSS.
• [ ] SSL-сертификаты (HTTPS).
• [ ] Резервное копирование (Backups): Как часто? Куда? Как быстро можно восстановиться?

Блок 8. Мобильное приложение (если есть)

Специфика сторов.

• [ ] Оффлайн-режим: Что работает без интернета? (Показываем кэш или заглушку?).
• [ ] Пуш-уведомления: Глубокие ссылки (Deep Links) — при клике на пуш открывается конкретный товар или главная?
• [ ] Обновления: Нужен ли механизм принудительного обновления (Force Update), если вышла критическая версия?
• [ ] Требования сторов: "Войти с Apple" (обязательно для iOS), удаление аккаунта, политика конфиденциальности.

Блок 9. Юридические вопросы и Приемка

Защита прав на код.

• [ ] Передача прав: Написано ли, что исключительные права на код, дизайн и БД переходят заказчику?
• [ ] Репозиторий: Код должен быть выложен в ваш Git-репозиторий.
• [ ] Техническая документация: Обязан ли исполнитель описать архитектуру и API (Swagger)?
• [ ] Сроки гарантии: Исправление багов бесплатно в течение X месяцев после релиза.
• [ ] Deployment: Кто настраивает боевой сервер и выкладывает приложение в сторы?