Как составить ТЗ для корпоративного IT-проекта: шаблон и чек-лист

Вы — IT-директор или руководитель цифрового проекта в компании с оборотом от 1 млрд рублей. Перед вами задача: запустить новый корпоративный продукт — внутренний сервис, клиентский портал или AI-модуль для автоматизации. Вы знаете, что 68% корпоративных IT-проектов выходят за бюджет, а 43% не укладываются в сроки. Одна из главных причин — плохое техническое задание на разработку ПО.

Хорошее ТЗ — это не бюрократический документ «для галочки». Это контракт между бизнесом и разработкой, который определяет, что именно вы получите, в какие сроки и за какие деньги. В этом руководстве — структура корпоративного ТЗ, шаблон, чек-лист и типичные ошибки, которые стоят компаниям миллионы рублей. Всё на основе реального опыта ITESCO — резидента Сколково, который помогает крупным компаниям в Москве запускать IT-продукты за 22 рабочих дня.

Содержание

• Что такое хорошее техническое задание и зачем оно нужно
• Структура корпоративного ТЗ: 12 обязательных разделов
• Функциональные и нефункциональные требования: в чём разница
• Как описать бизнес-логику в техническом задании
• Требования безопасности в ТЗ: ФЗ-152 и корпоративные стандарты
• Требования к интеграциям: ERP, CRM, 1С и корпоративные шины
• 7 ошибок при составлении ТЗ, которые стоят миллионы
• Шаблон ТЗ и чек-лист для корпоративного IT-проекта
• FAQ о техническом задании на разработку

Что такое хорошее техническое задание и зачем оно нужно

Техническое задание на разработку ПО — это документ, который фиксирует, что именно нужно создать, как система должна работать и каким критериям соответствовать. Для корпоративного сектора ТЗ — не формальность, а инструмент управления рисками. Без него каждый участник проекта интерпретирует задачу по-своему, а итог предсказуем: сроки срываются, бюджет растёт, а результат не соответствует ожиданиям.

ТЗ vs другие документы: SRS, BRD, FRD

В корпоративной практике используется несколько типов документов для фиксации требований. Важно понимать разницу:

ДокументНазначениеАудиторияСтандарт

BRD (Business Requirements Document)Зачем нужен проект, бизнес-цели, ROIТоп-менеджмент, стейкхолдерыBABOK FRD (Functional Requirements Document)Что должна делать системаАналитики, PMIEEE 830 SRS (Software Requirements Specification)Полная спецификация: функциональные + нефункциональные требованияРазработчики, QAIEEE 830, ГОСТ 34 **ТЗ (техническое задание)**Комплексный документ: бизнес-контекст + требования + критерии приёмкиВсе участники проектаГОСТ 34.602-89, ГОСТ 19.201-78

В российской практике техническое задание на разработку ПО обычно объединяет элементы BRD, FRD и SRS в один документ. Это удобно для внутреннего согласования: один файл проходит через юристов, безопасников, IT-отдел и бизнес-заказчика.

Когда ТЗ обязательно по закону

Для государственных заказчиков и компаний с госучастием техническое задание по ГОСТ 34.602-89 — обязательное условие конкурсной документации. Для коммерческих проектов формат свободный, но стандартизированная структура защищает обе стороны: заказчика — от «размытых» результатов, подрядчика — от бесконечных переделок.

По нашему опыту работы с банками, ретейлом и телеком-компаниями в Москве, корпоративное ТЗ должно отвечать на три вопроса: «что делаем?», «как проверяем?» и «что будет, если не сделаем?». Если документ не отвечает хотя бы на один из них — это не ТЗ, а wishlist.

Хорошее ТЗ vs плохое ТЗ

КритерийПлохое ТЗХорошее ТЗ

Требования«Система должна быть удобной»«Время отклика страницы до 200 мс при 1000 одновременных пользователях» ПриёмкаНе описанаЧёткие acceptance criteria для каждой функции Безопасность«Обеспечить безопасность данных»«Шифрование AES-256, соответствие ФЗ-152, ролевая модель доступа» Интеграции«Интеграция с 1С»«REST API, обмен данными: счета, оплаты, остатки; частота: real-time; формат: JSON; версия 1С: 8.3.24» Объём2-3 страницы20-60 страниц (зависит от проекта) РискиНе упомянутыОписаны для каждого модуля с планом митигации

Структура корпоративного ТЗ: 12 обязательных разделов

За 10 лет работы с enterprise-клиентами мы в ITESCO выработали структуру ТЗ, которая закрывает потребности всех участников проекта — от CIO до QA-инженера. Каждый раздел решает конкретную задачу и имеет чёткие критерии полноты. Грамотно составленное техническое задание на разработку ПО — фундамент успешного проекта.

1. Общие сведения

Название проекта, заказчик, исполнитель, дата, версия документа. Кажется банальным, но для корпораций критически важна версионность: когда документ проходит 5-7 кругов согласования, нужно точно знать, какую версию утвердил CISO, а какую — бизнес-заказчик.

2. Цели и задачи проекта

Бизнес-цели с привязкой к KPI. Не «автоматизировать процесс», а «сократить время обработки заявки с 48 до 4 часов, снизить нагрузку на операторов на 60%». Цели должны быть SMART: конкретные, измеримые, достижимые, релевантные, ограниченные по времени.

3. Описание текущего состояния (AS-IS)

Как процесс работает сейчас: какие системы используются, где узкие места, какие данные обрабатываются. Для крупных компаний это описание может занимать 5-10 страниц — и каждая из них экономит недели споров на этапе разработки.

4. Описание целевого состояния (TO-BE)

Как должна работать система после внедрения. Здесь важна визуализация: BPMN-диаграммы, блок-схемы, wireframes. Текстовое описание субъективно, диаграмма — нет.

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

Что система должна делать. Каждое требование — отдельный пункт с уникальным идентификатором (FR-001, FR-002…), приоритетом (Must / Should / Could) и критериями приёмки. Подробнее — в разделе ниже.

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

Как система должна работать: производительность, безопасность, доступность, масштабируемость. Для enterprise-проектов этот раздел обычно важнее функциональных требований — система, которая «всё делает, но тормозит при 100 пользователях», для корпорации бесполезна.

7. Требования к безопасности

Отдельный раздел, а не подпункт NFR. Для корпоративных проектов — это ФЗ-152, корпоративная политика ИБ, требования CISO, модель угроз. Подробнее — в разделе о безопасной разработке ПО.

8. Требования к интеграциям

С какими системами нужна интеграция, какие данные передаются, в каком формате, с какой частотой. Для enterprise-проектов интеграции с ERP, CRM и 1С — как правило, самая сложная и затратная часть проекта. Раздел ниже разбирает это подробно.

9. Требования к пользовательскому интерфейсу

Макеты, гайдлайны, требования к доступности (WCAG 2.1), адаптивность. Для B2B-систем — корпоративный брендбук, требования к дашбордам и отчётам.

10. Требования к инфраструктуре

Где разворачивается система: on-premise, частное облако, публичное облако. Требования к серверам, ОС, СУБД, контейнеризации. Для корпораций, работающих с персональными данными, размещение часто ограничено территорией РФ.

11. План тестирования и приёмки

Acceptance criteria для каждого модуля. Виды тестирования: функциональное, нагрузочное, security, UAT (User Acceptance Testing). Кто принимает, по каким критериям, в какие сроки.

12. Глоссарий и приложения

Термины, сокращения, ссылки на корпоративные стандарты и регламенты. В enterprise-проекте участвует 10-20 специалистов из разных отделов — единый глоссарий исключает разночтения.

Эта структура совместима с ГОСТ 34.602-89 и IEEE 830, что позволяет использовать одно и то же ТЗ и для внутреннего согласования, и для тендерной документации.

Функциональные и нефункциональные требования: в чём разница

Разделение требований на функциональные (FR) и нефункциональные (NFR) — основа грамотного технического задания. В корпоративных проектах это разделение определяет, как будет строиться тестирование, оценка бюджета и приоритизация. В ITESCO мы используем методологию, совместимую с IEEE 830 и адаптированную под российскую корпоративную практику.

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

Описывают что должна делать система. Каждое требование формулируется через user stories или use cases.

Формат user story:

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

Пример для корпоративного портала:

• FR-001: Как руководитель отдела, я хочу видеть дашборд с KPI своих сотрудников за текущий квартал, чтобы принимать решения о распределении ресурсов.
• FR-002: Как HR-специалист, я хочу выгружать отчёт по посещаемости в формате Excel, чтобы передать его в бухгалтерию для расчёта зарплаты.
• FR-003: Как администратор, я хочу управлять ролями и правами доступа через интерфейс, чтобы не привлекать разработчиков при изменении оргструктуры.

Acceptance Criteria (критерии приёмки)

Каждая user story должна сопровождаться критериями приёмки — конкретными условиями, при выполнении которых функция считается реализованной.

Пример acceptance criteria для FR-001:

• Дашборд отображает данные за текущий квартал по умолчанию
• Доступен выбор произвольного периода (от-до)
• Данные обновляются в реальном времени (задержка не более 5 минут)
• При отсутствии данных отображается сообщение «Данные за выбранный период отсутствуют»
• Дашборд доступен только руководителям с ролью manager и выше

Нефункциональные требования (NFR)

Описывают как система должна работать. Для корпоративных проектов NFR часто определяют 40-60% бюджета — потому что «сделать, чтобы работало» и «сделать, чтобы работало при 10 000 одновременных пользователях с 99.9% аптаймом» — это два совершенно разных проекта.

Категория NFRЧто описываетПример для enterprise

ПроизводительностьВремя отклика, пропускная способностьP95 время ответа API < 200 мс при 5000 RPS ДоступностьSLA, допустимый простой99.9% uptime (не более 8.76 часов простоя/год) МасштабируемостьРост нагрузки и данныхГоризонтальное масштабирование до 50 000 пользователей без архитектурных изменений БезопасностьЗащита данных, аутентификацияФЗ-152, OWASP Top 10, 2FA для административных ролей СовместимостьБраузеры, ОС, устройстваChrome 120+, Firefox 120+, Safari 17+, мобильные (iOS 16+, Android 13+) ПоддерживаемостьЛогирование, мониторинг, деплойЦентрализованное логирование, blue-green deployment, rollback за 5 минут

Приоритизация: MoSCoW

Не все требования одинаково важны. Метод MoSCoW помогает расставить приоритеты:

• Must have — без этого система не работает (80% бюджета)
• Should have — важно, но можно отложить на следующую итерацию
• Could have — «приятно иметь», реализуется при наличии ресурсов
• Won’t have (this time) — осознанно исключено из текущей версии

Для корпоративного MVP приоритизация критична: вы берёте только Must have, запускаете продукт за 22 дня и валидируете гипотезу. Should и Could — в следующих итерациях.

Как описать бизнес-логику в техническом задании

Бизнес-логика — это правила, по которым система принимает решения и обрабатывает данные. Это самый сложный раздел ТЗ: его нужно одинаково понимать и бизнес-заказчику, и разработчику. Ошибки в описании бизнес-логики — причина №1 переделок в корпоративных IT-проектах.

Use Cases vs User Stories

Для корпоративных проектов мы в ITESCO рекомендуем комбинировать оба подхода:

ПараметрUser StoriesUse Cases

ФорматОдно предложение: «Как [роль]…»Структурированный документ: акторы, предусловия, шаги, альтернативные сценарии КогдаДля простых функций, CRUD-операцийДля сложной бизнес-логики с ветвлениями ПлюсБыстро, понятно бизнесуПолное покрытие, включая edge cases МинусНе покрывает альтернативные сценарииОбъёмно, требует времени

Пример Use Case для корпоративной системы

UC-005: Согласование заявки на закупку

• Актор: Руководитель отдела
• Предусловие: Заявка создана сотрудником, статус «На согласовании»
• Основной сценарий:

Руководитель открывает список заявок на согласование

• Система отображает заявки с суммой, статусом и сроком
• Руководитель выбирает заявку и проверяет детали
• Руководитель нажимает «Согласовать» и добавляет комментарий
• Система меняет статус на «Согласовано» и уведомляет инициатора
• Если сумма > 500 000 ₽ — заявка автоматически направляется на второй уровень согласования (финансовый директор)
• Альтернативный сценарий: Руководитель нажимает «Отклонить» — заявка возвращается инициатору с комментарием, статус «Отклонено»
• Исключение: Если руководитель не реагирует 3 рабочих дня — система отправляет эскалацию на уровень выше

Decision Tables для сложных правил

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

Сумма заявкиКатегорияОтделСогласование

< 100 000 ₽КанцелярияЛюбойАвтоматическое < 100 000 ₽IT-оборудованиеЛюбойРуководитель отдела 100 000-500 000 ₽ЛюбаяЛюбойРуководитель отдела + Финансовый директор

500 000 ₽ЛюбаяЛюбойРуководитель отдела + Финансовый директор + Генеральный директор

Такая таблица исключает двусмысленность и легко конвертируется в код. Разработчик смотрит на неё и точно знает, что реализовывать.

BPMN-диаграммы

Для сложных бизнес-процессов (особенно с участием нескольких отделов) текст и таблицы недостаточны. BPMN 2.0 — стандарт описания бизнес-процессов, который понимают и бизнес-аналитики, и разработчики. Инструменты: Camunda Modeler (бесплатный), draw.io, Bizagi Modeler.

В ITESCO мы используем BPMN на этапе discovery-фазы: вместе с заказчиком рисуем процесс, находим неочевидные ветвления и edge cases. Это позволяет выявить 80% проблем ещё до написания первой строчки кода. Подробнее о том, как избежать провалов в IT-проектах, — в отдельном разделе.

Требования безопасности в ТЗ: ФЗ-152 и корпоративные стандарты

Для корпоративного проекта раздел безопасности — не приложение к ТЗ, а его ядро. Если вы разрабатываете систему, которая обрабатывает персональные данные сотрудников, клиентов или партнёров — требования ФЗ-152 должны быть учтены на уровне архитектуры, а не «прикручены» после разработки.

Что обязательно включить в раздел безопасности

1. Классификация данных

• Какие категории персональных данных обрабатываются (ФИО, паспорт, медицинские, биометрические)
• Уровень защищённости информационной системы (УЗ-1, УЗ-2, УЗ-3, УЗ-4 по постановлению №1119)
• Объём обрабатываемых данных (до 100 000, более 100 000 субъектов)

2. Модель угроз

• Актуальные угрозы (несанкционированный доступ, утечка, модификация, DDoS)
• Вероятность и последствия каждой угрозы
• Меры защиты для каждой угрозы

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

ТребованиеСпецификацияОбоснование

Шифрование данных в покоеAES-256ФЗ-152, приказ ФСТЭК №21 Шифрование данных при передачеTLS 1.3Защита от перехвата АутентификацияSSO через корпоративный AD + 2FA для админовКорпоративная политика ИБ АвторизацияRBAC (Role-Based Access Control)Принцип минимальных привилегий ЛогированиеВсе действия пользователей, хранение 12 месяцевАудит, расследование инцидентов Защита от OWASP Top 10SQL injection, XSS, CSRF, SSRF и другиеСтандарт отрасли Резервное копированиеЕжедневное, RPO 1 час, RTO 4 часаНепрерывность бизнеса

4. Организационные требования

• NDA с подрядчиком и всеми участниками разработки
• Политика обработки персональных данных (для публикации на сайте)
• Согласие на обработку персональных данных (формы)
• Процедура реагирования на инциденты (72 часа — уведомление Роскомнадзора)

Подробная инструкция по обеспечению безопасности при разработке — в разделе о безопасной разработке ПО. Там разбираем SSDLC (Secure Software Development Lifecycle) и подготовку к корпоративному аудиту.

Типичная ошибка: безопасность «после разработки»

Если требования безопасности описаны в ТЗ — подрядчик закладывает их в архитектуру с первого дня. Если нет — вы получаете работающую систему, которая не пройдёт аудит CISO. Доработка безопасности post factum стоит в 3-5 раз дороже, чем проектирование «с нуля».

В ITESCO соответствие ФЗ-152 включено в каждый пакет разработки — это не опция, а стандарт. Мы работаем с компаниями, где аудит безопасности — обязательный этап приёмки, и знаем, какие вопросы задаёт CISO.

Требования к интеграциям: ERP, CRM, 1С и корпоративные шины

Интеграции — самая недооценённая часть технического задания на разработку ПО. По нашей статистике, именно интеграции съедают 30-40% бюджета enterprise-проекта, а ошибки в их описании — главная причина срыва сроков.

Что описать для каждой интеграции

Для каждой внешней системы в ТЗ необходимо зафиксировать:

ПараметрПример: интеграция с 1С:ERP

Система1С:ERP 2.5, серверная версия ПротоколREST API через HTTP Service 1С / OData НаправлениеДвустороннее: наша система <-> 1С **Данные (наша → 1С)**Заявки на закупку, акты, счета на оплату **Данные (1С → наша)**Справочники контрагентов, остатки на складах, статусы оплат ФорматJSON (REST API) или XML (ComV2) ЧастотаСправочники — раз в час; остатки — real-time; документы — по событию ОбъёмДо 10 000 позиций/сутки Обработка ошибокRetry 3 раза с экспоненциальной задержкой, dead letter queue, уведомление в Telegram МониторингPrometheus-метрики: latency, error rate, queue depth

Типичные корпоративные интеграции

• 1С (ERP/УТ/Бухгалтерия) — обмен документами, справочниками, остатками. Критично: версия 1С, способ подключения (HTTP Service, OData, ComV2), формат данных
• CRM (Bitrix24, amoCRM, Salesforce) — синхронизация лидов, контактов, сделок. Webhook vs polling, дедупликация записей
• SSO/LDAP/AD — единый вход через корпоративный Active Directory. Протокол: SAML 2.0 или OpenID Connect. Маппинг ролей AD → роли в системе
• Корпоративные шины (ESB) — IBM MQ, RabbitMQ, Apache Kafka. Формат сообщений, SLA на доставку, гарантии доставки (at-least-once, exactly-once)
• Электронная подпись (КЭП) — интеграция с КриптоПро, подписание документов. Сертификация ФСБ
• Платёжные шлюзы — ЮKassa, CloudPayments, Сбер Эквайринг. PCI DSS, токенизация карт

Чек-лист описания интеграции

• Название и версия внешней системы
• Протокол (REST, SOAP, gRPC, файловый обмен)
• Направление данных (одно-/двустороннее)
• Перечень передаваемых сущностей + формат (JSON/XML/CSV)
• Частота обмена (real-time / по расписанию / по событию)
• Объём данных (записей в сутки / пиковая нагрузка)
• Аутентификация (API key, OAuth 2.0, сертификат)
• Обработка ошибок (retry, dead letter queue, алерты)
• SLA (время отклика, допустимый простой)
• Ответственный за внешнюю систему (ФИО, должность, контакт)

Если в ТЗ написано просто «интеграция с 1С» без этих деталей — готовьтесь к 2-3 месяцам переговоров на этапе разработки и бюджету x2 от первоначального.

7 ошибок при составлении ТЗ, которые стоят миллионы

За 10 лет работы с enterprise-клиентами мы собрали антипаттерны, которые встречаются в 80% технических заданий. Каждая ошибка — это потенциальный перерасход бюджета на 20-50%.

Ошибка 1. «Размытые» требования

Формулировки типа «система должна быть быстрой», «удобный интерфейс», «высокая надёжность». Это не требования, а пожелания. Без конкретных цифр (200 мс, 99.9% uptime, 3 клика до целевого действия) подрядчик интерпретирует их по своему усмотрению — и результат вас не устроит.

Ошибка 2. Отсутствие acceptance criteria

Каждое требование должно быть проверяемым. Если вы не можете описать тест, который проверяет выполнение требования, — значит требование сформулировано плохо. Acceptance criteria — это контракт: «если условие X выполнено — функция принята».

Ошибка 3. Забытые нефункциональные требования

70% ТЗ, которые мы видим, содержат только функциональные требования. NFR «подразумеваются» — и это ловушка. Подрядчик сделает систему, которая работает на 10 пользователях. А когда вы подключите 5000 — она ляжет. Потому что нагрузка «не была в ТЗ».

Ошибка 4. Интеграции «по остаточному принципу»

Одна строчка «интеграция с 1С, CRM и AD» в конце ТЗ. На практике каждая интеграция — это отдельный мини-проект с собственными сроками, рисками и зависимостями. Недооценка интеграций — причина №1 срыва сроков в enterprise.

Ошибка 5. ТЗ пишет только IT-отдел

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

Ошибка 6. Отсутствие раздела безопасности

Для стартапа это допустимо. Для компании с оборотом от 1 млрд — нет. Если ТЗ не содержит требований по ФЗ-152, модели угроз и корпоративной политике ИБ, вы гарантированно получите продукт, который не пройдёт внутренний аудит. А доработка безопасности post factum — это рефакторинг на 30-50% кодовой базы.

Ошибка 7. «Монолитное» ТЗ без версионности

ТЗ на 100 страниц, написанное за 3 месяца, к моменту начала разработки уже устарело. Требования меняются, бизнес-контекст сдвигается. Решение: итеративный подход. Минимальное ТЗ для MVP → разработка → обратная связь → расширение ТЗ для следующей итерации.

Именно поэтому в ITESCO discovery-фаза и составление ТЗ — первые 3 дня из 22 рабочих дней пакета. Мы помогаем клиентам сформулировать требования компактно, точно и проверяемо, чтобы избежать типичных ошибок IT-проектов. Подробнее о ценообразовании — в разделе о стоимости IT-проекта.

Шаблон ТЗ и чек-лист для корпоративного IT-проекта

Ниже — практический шаблон и чек-лист, которые мы используем в ITESCO при работе с enterprise-клиентами в Москве. Шаблон совместим с ГОСТ 34.602-89 и IEEE 830.

Шаблон структуры ТЗ

РазделСодержаниеОбъём

1. Общие сведенияНазвание, заказчик, исполнитель, даты, версия, согласования1-2 стр. 2. ГлоссарийТермины, сокращения, определения1-2 стр. 3. Бизнес-контекстЦели (SMART), задачи, KPI, ROI, ожидаемые результаты2-3 стр. 4. Описание AS-ISТекущие процессы, системы, проблемы, узкие места3-5 стр. 5. Описание TO-BEЦелевые процессы, BPMN-диаграммы, wireframes5-10 стр. 6. Функциональные требованияUser stories / Use cases, acceptance criteria, приоритизация MoSCoW10-20 стр. 7. Нефункциональные требованияПроизводительность, доступность, масштабируемость, совместимость3-5 стр. 8. Требования безопасностиФЗ-152, модель угроз, шифрование, аутентификация, логирование3-5 стр. 9. ИнтеграцииКаждая система: протокол, данные, частота, SLA, обработка ошибок5-10 стр. 10. UI/UXМакеты, гайдлайны, доступность, адаптивность3-5 стр. 11. ИнфраструктураРазмещение, серверы, ОС, СУБД, CI/CD, мониторинг2-3 стр. 12. Тестирование и приёмкаВиды тестов, acceptance criteria, процедура UAT, сроки2-3 стр. 13. Сроки и этапыRoadmap, milestones, зависимости, буферы1-2 стр. 14. ПриложенияBPMN-диаграммы, макеты, спецификации API, матрица ролейпо объёму

Итого: 40-70 страниц для среднего корпоративного проекта. Для MVP-фазы — 15-25 страниц (фокус на Must have).

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

Используйте этот чек-лист перед передачей ТЗ подрядчику или в тендерную комиссию:

Бизнес-контекст:

• Цели проекта сформулированы по SMART
• KPI определены с числовыми значениями
• ROI рассчитан на горизонте 1-3 года
• Описание AS-IS включает текущие проблемы и метрики
• Описание TO-BE содержит BPMN или блок-схемы

Требования:

• Каждое FR имеет уникальный ID (FR-001, FR-002…)
• Каждое FR содержит acceptance criteria
• Приоритизация по MoSCoW выполнена
• NFR описаны с конкретными цифрами (latency, uptime, RPS)
• Требования безопасности соответствуют ФЗ-152 и корпоративной политике

Интеграции:

• Для каждой внешней системы указаны: протокол, данные, частота, SLA
• Описана обработка ошибок для каждой интеграции
• Указан ответственный за каждую внешнюю систему
• Учтены версии внешних систем (1С, CRM, ERP)

Инфраструктура и деплой:

• Среда размещения определена (cloud / on-premise / гибрид)
• Требования к серверам и ОС зафиксированы
• CI/CD и процедура деплоя описаны
• Резервное копирование и disaster recovery определены

Тестирование:

• Виды тестирования определены (функциональное, нагрузочное, security, UAT)
• Критерии приёмки для каждого модуля описаны
• Процедура UAT согласована с бизнес-заказчиком
• Сроки тестирования включены в roadmap

Как ITESCO помогает с техническим заданием

Составление детального ТЗ — часть стандартного пакета ITESCO. За первые 3 дня из 22-дневного цикла мы проводим discovery-фазу: интервью с бизнес-заказчиком, анализ текущих систем, формирование требований, приоритизация и BPMN-моделирование. Вы получаете готовое техническое задание на разработку ПО, согласованное с вашей командой — CIO, CISO, бизнес-аналитиками.

Если вы уже начали формировать требования самостоятельно — мы поможем доработать существующее ТЗ: проверим полноту, добавим недостающие разделы, формализуем acceptance criteria. Опыт работы с банками, ретейлом, телеком и промышленностью в Москве позволяет нам видеть типичные пробелы и закрывать их до начала разработки. Подробнее о выборе IT-подрядчика для корпоративного проекта.

FAQ о техническом задании на разработку

Сколько стоит составление ТЗ для корпоративного IT-проекта?

В ITESCO составление детального ТЗ входит в стандартный пакет разработки (до 900 000 рублей за весь проект). Discovery-фаза и формирование требований — первые 3 дня из 22 рабочих дней. Вы не платите отдельно за ТЗ. Если вам нужно только техническое задание без разработки (например, для внутреннего тендера), стоимость обсуждается индивидуально и зависит от масштаба проекта — как правило, от 150 000 до 400 000 рублей. Для сравнения: на рынке в Москве стоимость составления корпоративного ТЗ у консалтинговых компаний начинается от 300 000 рублей и может достигать 1-2 млн для сложных проектов.

Какой стандарт использовать для ТЗ: ГОСТ 34 или IEEE 830?

Зависит от контекста. ГОСТ 34.602-89 обязателен для госзаказчиков и компаний с госучастием — его требуют в тендерной документации. IEEE 830 (SRS) — международный стандарт, более гибкий и удобный для коммерческих проектов. На практике мы в ITESCO комбинируем оба подхода: берём структуру из ГОСТ 34 (для формальной приёмки) и наполняем её по методологии IEEE 830 (user stories, acceptance criteria, MoSCoW-приоритизация). Такой документ проходит и внутреннее согласование в корпорации, и тендерную комиссию.

Сколько времени нужно на составление хорошего ТЗ?

Для корпоративного проекта средней сложности — 2-4 недели при участии бизнес-аналитика и представителей заказчика. В ITESCO мы укладываемся в 3 рабочих дня, потому что используем стандартизированный фреймворк: шаблон структуры, библиотеку типовых NFR для enterprise, готовые чек-листы для ФЗ-152 и интеграций. Ключевой фактор — доступность стейкхолдеров: если CIO, CISO и бизнес-заказчик оперативно отвечают на вопросы, ТЗ формируется за 3-5 дней. Если согласования затягиваются — может уйти и 2 месяца.

Нужно ли писать ТЗ для MVP или это лишняя бюрократия?

ТЗ для MVP — не бюрократия, а инструмент экономии. Разница в объёме: для полномасштабного проекта ТЗ занимает 40-70 страниц, для MVP — 15-25 страниц с фокусом на Must have функции. Без ТЗ вы рискуете получить «не тот продукт» и потерять 22 рабочих дня и весь бюджет. Для корпоративного сектора ТЗ также служит формальным основанием для внутреннего согласования — без документа бюджетный комитет не утвердит расходы. В ITESCO ТЗ для MVP включает: бизнес-цели, 10-15 ключевых user stories с acceptance criteria, NFR (производительность, безопасность), интеграции и план тестирования.

Как описать требования к AI-компонентам в ТЗ?

AI-компоненты требуют специфических разделов в ТЗ: описание модели (задача, метрики качества — accuracy, precision, recall, F1), требования к данным (объём обучающей выборки, формат, источники, разметка), инфраструктура для обучения и инференса (GPU, RAM, latency), процедура мониторинга модели в продакшене (data drift, model drift). Для LLM-интеграций нужно описать: выбор провайдера (OpenAI, Anthropic, YandexGPT), fallback-стратегию при недоступности API, максимальную стоимость запросов в месяц, политику хранения промптов и ответов. В ITESCO все проекты за последние два года включают AI-элементы, и мы используем собственный шаблон для AI-требований.

Что делать, если требования меняются после утверждения ТЗ?

Изменение требований — нормальная часть корпоративного проекта. Ключевое — процедура управления изменениями (change management), которая описывается в ТЗ: кто инициирует изменение, кто согласовывает, как оценивается влияние на сроки и бюджет, как обновляется документация. Для MVP-проектов в ITESCO мы используем итеративный подход: ТЗ покрывает Must have для первой итерации (22 дня), а Should и Could формализуются для следующих итераций на основе реальных данных от пользователей. Это позволяет адаптировать продукт к рынку без многомесячного пересогласования документации.

Можно ли заказать аудит существующего ТЗ перед началом разработки в Москве?

Да, ITESCO проводит аудит технических заданий для корпоративных клиентов в Москве. Мы проверяем: полноту структуры (12 обязательных разделов), качество требований (конкретность, проверяемость, непротиворечивость), соответствие ФЗ-152, полноту описания интеграций, наличие acceptance criteria и NFR. По результатам вы получаете отчёт с конкретными рекомендациями и оценкой рисков. Типичные проблемы, которые мы находим: отсутствие NFR (70% ТЗ), неполное описание интеграций (85%), расплывчатые acceptance criteria (60%), игнорирование требований безопасности (50%). Аудит занимает 3-5 рабочих дней и помогает избежать проблем на этапе разработки.

Составление корпоративного ТЗ — процесс, требующий опыта и методологии. Если вы планируете запуск IT-проекта и хотите начать с правильного фундамента, запишитесь на бесплатный Zoom-колл с командой ITESCO. Мы разберём вашу задачу, оценим техническую сложность и поможем сформулировать требования так, чтобы проект уложился в сроки и бюджет.