Техническое задание (ТЗ) — это документ, который определяет судьбу проекта. Хорошее ТЗ экономит недели разработки и тысячи рублей. Плохое — превращается в ХЗ (неизвестно, что задумано). За 22 года в бизнес-анализе я написала сотни ТЗ. Вот мой практический подход: полный шаблон, который реально работает.
Почему ТЗ — это ваша власть
ТЗ — это не просто бумага. Это ваш инструмент:
✅ Спасает проект от провала (разработчики понимают, что делать)
✅ Экономит деньги (нет переделок и правок)
✅ Защищает вас как аналитика (всё прописано чёрно-белое)
✅ Позволяет считать часы и деньги (на основе объёма работ)
✅ Увеличивает вашу цену (клиенты видят профессионализм)
Люди, которые быстро пишут хорошие ТЗ, зарабатывают в 2–3 раза больше. Точка.
Шаблон ТЗ
Я буду использовать адаптированный шаблон IEEE 830 + мой личный опыт. Это НЕ госстандарт, это то, что реально работает в коммерческих проектах.
ЧАСТЬ 1: ОРГАНИЗАЦИОННАЯ ЧАСТЬ (10 минут)
1.1 Титульный лист
════════════════════════════════════════════════════════════
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Проект: [Название проекта]
Версия ТЗ: 1.0
Дата создания: [Дата]
Автор: [Ваше имя]
Заказчик: [Компания/Имя клиента]
Исполнитель: [Ваша компания или вы]
════════════════════════════════════════════════════════════
1.2 История изменений
1.3 Глоссарий (сокращения и термины)
1.4 Оглавление
(Автоматически генерируется в Word/Google Docs)
ЧАСТЬ 2: ОБЩАЯ ИНФОРМАЦИЯ О СИСТЕМЕ (15 минут)
2.1 Введение
Назначение документа
Этот документ определяет функциональные и нефункциональные требования к системе [Название системы]. Документ предназначен для [разработчиков, тестировщиков, заказчика, менеджера проекта].
Область действия
Этот документ описывает разработку системы [название] с целью [основная цель]. Система будет использоваться для [основные процессы].
Целевая аудитория документа
- Разработчики (Python, Java, 1С и т.д.)
- Тестировщики и QA
- Заказчик (бизнес)
- Project Manager
2.2 Назначение и цели создания системы
Проблема (контекст)
Опишите, почему нужна эта система. Приведите цифры, боль клиента:
❌ Неправильно: "Нужно автоматизировать учёт"
✅ Правильно: "Сейчас учёт в Excel: теряют 30% товара, отчёты составляют 3 дня, ошибки в закупках стоят компании 500K в год. Нужна система, чтобы это решить."
Основные цели
- Сократить время на учёт с 3 часов в день до 30 минут
- Снизить ошибки в учёте на 95%
- Давать прогнозы по спросу автоматически
- Увеличить ROI на 250K в год
Краткое описание решения
Онлайн-система с мобильным приложением и веб-интерфейсом для управления складским учётом в реальном времени.
2.3 Характеристика объектов автоматизации
Бизнес-процессы, которые будут реализованы в системе:
- Приход товара на склад
- Выписка товара со склада
- Инвентаризация
- Формирование отчётов по остаткам
- Прогнозирование спроса
Текущее состояние
Используется Excel, Google Sheets, частично вводная вручную. Интеграции с 1С нет.
Желаемое состояние
- Полная автоматизация
- Интеграция с 1С
- Мобильный доступ для кладовщиков
- Автоматические прогнозы
ЧАСТЬ 3: ДЕТАЛЬНЫЕ ТРЕБОВАНИЯ (30 минут)
3.1 Целевые пользователи и их роли
3.2 Справочники (основные данные системы)
Справочник "Товары"
- Код товара (уникальный)
- Название
- Единица измерения
- Цена закупки
- Цена продажи
- Поставщик
- Статус (активно/неактивно)
Справочник "Поставщики"
- ID поставщика
- Название
- Контакт
- Email
- Телефон
Справочник "Склады"
- ID склада
- Название
- Адрес
- Ответственный (менеджер)
Справочник "Единицы измерения"
- шт (штука)
- кг (килограмм)
- л (литр)
- м² (квадратный метр)
3.3 Функциональные требования (описание процессов)
Сценарий 1: Добавление товара на склад (ПРИХОД)
Тип процесса: Ручной
Участники: Кладовщик, Система
Роль: Кладовщик
Позитивный путь (Happy Path):
- Кладовщик открывает Главное меню → "Приход товара"
- Система открывает форму "Новый приход"
- Кладовщик заполняет:
Дата прихода (по умолчанию сегодня)
Склад (выпадающий список)
Поставщик (выбор из справочника) - Кладовщик добавляет товары в таблицу:
- Товар (поиск + выбор)
- Количество
- Цена за единицу - Система автоматически считает сумму (Кол-во × Цена)
- Кладовщик нажимает "Сохранить"
- Система проверяет (бизнес-проверки — см. ниже)
- Если всё ок → сохраняет, показывает "Приход создан"
- Остатки товара автоматически увеличиваются
Негативный путь (Error Path):
Сценарий 1a: Товар не найден в справочнике
- Кладовщик вводит название товара
- Система не находит совпадение
- Показывает "Товар не найден. Добавить новый?"
- Кладовщик нажимает "Добавить"
- Открывается форма добавления товара (см. отдельный сценарий)
Сценарий 1b: Ошибка в данных
- Кладовщик забыл выбрать склад
- Система показывает красный текст под полем: "Обязательное поле"
- Кладовщик не может сохранить до заполнения
Сценарий 1c: Дублирование прихода
- Кладовщик добавляет товар, который уже был добавлен в текущий приход
- Система предупреждает: "Товар [название] уже добавлен. Изменить количество?"
Таблица проверок (валидация данных):
Сценарий 2: Выписка товара со склада (РАСХОД)
Тип процесса: Ручной
Участники: Кладовщик, Система
Роль: Кладовщик
Позитивный путь:
- Кладовщик открывает Главное меню → "Выписка товара"
- Система открывает форму "Новая выписка"
- Кладовщик выбирает:
- Склад (обязательно)
- Тип выписки: продажа / внутреннее перемещение / брак - Добавляет товары:
- Товар (из справочника)
- Количество для отпуска - Нажимает "Сохранить"
- Система проверяет: хватает ли товара на складе
- Если хватает → сохраняет, остаток уменьшается
- Если не хватает → показывает ошибку
Негативный путь:
Сценарий 2a: Недостаточно товара
- Кладовщик пытается выписать 100 шт, а на складе 50
- Система показывает: "Ошибка! На складе только 50 шт. Имеющееся количество: 50"
- Предлагает варианты: "Отпустить всё (50 шт)?" или "Отмена"
Таблица проверок:
Сценарий 3: Просмотр остатков (АНАЛИТИКА)
Тип процесса: Полностью автоматический
Участники: Кладовщик, Менеджер по закупкам, Директор, Система
Роль: Любая
Процесс:
- Пользователь открывает "Остатки товара" или "Дашборд"
- Система считывает данные из таблицы "Остатки"
- Отображает таблицу в режиме реального времени:
- Товар
- Текущий остаток
- Минимальный уровень (когда нужно заказывать)
- Статус (норма / низкий / критический) - Товары с остатком ниже минимума выделяются красным
Технические требования:
- Обновление данных: каждые 5 секунд
- Кэширование: данные кэшируются, чтобы не перегружать БД
3.4 Экранные формы (UI требования)
Форма 1: "Приход товара"
3.5 Справочники и интеграции
Справочник "Товары"
Источник данных: 1С (ежедневная выгрузка в 02:00)
Частота обновления: 1 раз в день (ночью)
Справочник "Склады"
Источник: статический (вводится вручную в системе)
Справочник "Единицы измерения"
Источник: статический (заранее заложены в системе)
3.6 Сценарии использования (User Stories или Use Cases)
Use Case 1: Кладовщик добавляет приход товара
- Актор: Кладовщик
- Предусловие: Кладовщик залогинен, имеет роль "Кладовщик"
- Основной поток: [см. Сценарий 1]
- Исключения: [см. негативные пути]
- Постусловие: Приход сохранен, остатки увеличены
3.7 Нефункциональные требования
Требования к производительности
- Сохранение прихода: < 2 секунд
- Загрузка справочника товаров: < 3 секунд (даже если 100K товаров)
- Обновление дашборда: каждые 5 сек (real-time, но с кэшем)
Требования к доступности
- Система должна быть доступна 24/7
- Время апдейта: в 02:00–03:00 (когда никто не работает)
Требования к безопасности
- Все пароли хранятся в хэшированном виде (bcrypt)
- API требует токен аутентификации
- Логирование всех операций (кто, когда, что изменил)
- Только кладовщики видят свои операции, директор видит всё
Требования к браузерам
- Chrome 90+, Firefox 88+, Safari 14+, Edge 90+
- Мобильная версия: iOS Safari 14+, Chrome Android 90+
Требования к базе данных
- PostgreSQL 12+
- Автоматическое резервное копирование каждые 6 часов
Требования к архитектуре
- Технологический стек: Node.js + React + PostgreSQL (если не задано — уточнить)
- Мобильное приложение: React Native или Flutter
ЧАСТЬ 4: ТРЕБОВАНИЯ К ИНТЕГРАЦИИ (10 минут)
4.1 Интеграции с внешними системами
Интеграция с 1С (выгрузка справочника товаров)
Интеграция с Email (отправка уведомлений)
Таблица уведомлений:
ЧАСТЬ 5: КРИТЕРИИ ПРИЁМКИ И ТЕСТИРОВАНИЯ (5 минут)
Чеклист приёмки (Acceptance Criteria):
ЧАСТЬ 6: ОГРАНИЧЕНИЯ И ДОПУЩЕНИЯ (5 минут)
Ограничения:
- Система поддерживает только русский язык (для будущих версий: многоязычность)
- Максимум 1000 товаров в одном приходе
- История данных хранится только 2 года
- В одном момент времени может быть не более 50 одновременных пользователей (расширяется платно)
Допущения:
- 1С будет доступна в нашей сети 24/7
- Интернет соединение стабильное (> 1 Mbps)
- Пользователи будут обучены работе с системой (минимум 2 часа)
ЧАСТЬ 7: РИСКИ И ЗАВИСИМОСТИ (5 минут)
Как использовать этот шаблон за 1 час
Минут 0–5: Введение + Общая информация
Напишите назначение, цели, целевых пользователей.
Минут 5–35: Функциональные требования
Опишите 2–3 основных сценария (приход, расход, отчёт). Каждый сценарий = happy path + error path.
Минут 35–45: Нефункциональные требования + интеграции
Перечислите требования к скорости, безопасности, интеграциям.
Минут 45–60: Критерии приёмки + глоссарий
Финальный чеклист и условия завершения.
Главные ошибки, которых избегать
❌ Ошибка 1: Писать без сценариев
✅ Правильно: Каждый функционал = пошаговый сценарий + проверки
❌ Ошибка 2: Забыть про error path
✅ Правильно: Описать оба пути: "когда всё работает" и "когда ошибка"
❌ Ошибка 3: Писать технические детали вместо требований
✅ Правильно: "Система должна хранить данные 2 года" вместо "используй Oracle DB"
❌ Ошибка 4: Не согласовать с клиентом
✅ Правильно: Показать черновик, получить feedback, переписать
Почему это экономит деньги
До хорошего ТЗ:
- Разработка: 4 недели
- Переделки: 2 недели
- Тестирование: 2 недели
- Итого: 8 недель
После хорошего ТЗ (мой шаблон):
- Разработка: 2 недели
- Переделки: 0 недель (всё ясно)
- Тестирование: 1 неделя
- Итого: 3 недели
Экономия: 5 недель = 40% от времени проекта
Если проект стоит 500K рублей, вы сэкономили клиенту 200K. Это стоит того, чтобы потратить час на хорошее ТЗ.
Вывод
Хорошее ТЗ — это не просто формальность. Это инструмент власти:
- Вы контролируете проект
- Клиент получает то, что хотел
- Разработчик работает эффективнее
- Все зарабатывают больше
Используйте мой полный шаблон. Адаптируйте под свой проект. Пишите ТЗ за час. И зарабатывайте как профессионал.
В следующей статье расскажу, как вести переговоры с разработчиком, чтобы он понял именно то, что нужно, и не спрашивал одно и то же по 10 раз.
Подписывайся на канал https://t.me/+Ps9pPJNvL1xjNTI6