Как согласовать этапы и сроки разработки ТЗ на программу для ЭВМ

Почему важно детально прописать график разработки ТЗ

Техническое задание (ТЗ) является юридическим и техническим фундаментом для создания любого программного обеспечения. Согласно статье 1261 Гражданского кодекса РФ, программа для ЭВМ охраняется как произведение литературы, однако ее функционально-технические характеристики определяются именно в ТЗ. Отсутствие детального графика разработки этого документа часто приводит к срыву сроков всего проекта еще до написания первой строки кода.

Детализация графика создания ТЗ решает следующие задачи:

• Исключение «размывания» границ проекта (Scope Creep). Без четкого плана аналитики могут бесконечно собирать требования, пытаясь описать второстепенные функции.
• Фиксация зон ответственности. График четко разграничивает, когда заказчик должен предоставить доступы к своим системам или провести интервью, а когда подрядчик обязан предоставить готовый раздел документа.
• Финансовое планирование. Разработка ТЗ в крупных проектах составляет от 10% до 15% от общей стоимости контракта. Поэтапная оплата аналитики снижает финансовые риски сторон.
• Предотвращение простоя разработчиков. Понимание того, как согласовать этапы и сроки разработки тз на программу для ЭВМ, позволяет вовремя подготовить спецификации для программистов, исключая оплату их вынужденного простоя.

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

Ключевые этапы подготовки технического задания

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

Этап 1: Предпроектное обследование и сбор требований

На этом этапе аналитики проводят интервью с ключевыми стейкхолдерами заказчика, изучают существующую ИТ-инфраструктуру и бизнес-процессы.

• Срок: от 5 до 10 рабочих дней (в зависимости от масштаба системы).
• Результат: реестр заинтересованных лиц, протоколы интервью, схема бизнес-процессов «как есть» (As-Is).

Этап 2: Проектирование архитектуры и интеграционных сценариев

Определяется общая концепция программы для ЭВМ, структура базы данных, требования к безопасности и варианты интеграции со сторонними сервисами через API.

• Срок: от 7 до 15 рабочих дней.
• Результат: архитектурная концепция, перечень интеграционных методов, ER-диаграмма сущностей базы данных.

Этап 3: Разработка функциональных и нефункциональных требований

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

• Срок: от 10 до 20 рабочих дней.
• Результат: первый черновик ТЗ по ГОСТ 19.201-78 или ГОСТ 34.602-89.

Этап 4: Создание UX/UI-прототипов (интерактивных макетов)

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

• Срок: от 5 до 12 рабочих дней.
• Результат: кликабельный прототип в Figma или аналогичном инструменте проектирования.

Этап 5: Согласование, устранение замечаний и утверждение

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

• Срок: от 5 до 10 рабочих дней (лимитированное количество итераций).
• Результат: утвержденное сторонами ТЗ, подписанный акт.

Методы оценки реалистичности сроков для цифровых сервисов

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

Метод декомпозиции (WBS — Work Breakdown Structure)

Процесс написания ТЗ разбивается на мельчайшие задачи (например, «описать авторизацию через Госуслуги», «спроектировать личный кабинет юридического лица»). Каждая задача оценивается аналитиком в часах. Сумма часов с добавлением буфера на коммуникации (обычно 15–20%) дает итоговый срок этапа.

Метод трех точек (PERT)

Для каждой задачи рассчитываются три сценария:

1. Оптимистичный ($O$): все стейкхолдеры доступны, требования понятны сразу.

2. Наиболее вероятный ($M$): стандартный рабочий процесс с небольшими задержками.

3. Пессимистичный ($P$): долгие согласования, противоречивые требования.

Итоговая оценка ($E$) рассчитывается по формуле:

$$E = \frac{O + 4M + P}{6}$$

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

Когда перед менеджментом стоит задача понять, как согласовать этапы и сроки разработки тз на программу для цифровые сервисы современного типа (например, финтех-платформы или мобильные приложения с высокой нагрузкой), стандартных подходов бывает недостаточно. Для таких продуктов необходимо закладывать дополнительное время на изучение документации внешних API (платежные шлюзы, СБП, ЕСИА, сервисы геолокации) — на это уходит от 3 до 7 рабочих дней работы системного аналитика.

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

Таблица проверки готовности этапов ТЗ

Используйте эту таблицу для контроля качества и своевременности подготовки разделов технического задания.

Типичные риски при нарушении регламента согласования

Если стороны не зафиксировали жесткие правила согласования, проект неизбежно сталкивается со следующими проблемами:

• Риск «бесконечных правок». Заказчик может еженедельно присылать новые пожелания, меняющие концепцию. Без ограничения количества итераций (рекомендуется не более 3 раундов правок) процесс согласования ТЗ может длиться месяцами.
• Простой команды разработки. Если разработчики уже забронированы под проект, а ТЗ не готово к назначенному сроку, исполнитель несет прямые убытки или переводит специалистов на другие задачи, из-за чего старт разработки откладывается на неопределенный срок.
• Юридические споры. В случае отсутствия промежуточных актов по этапам ТЗ, заказчик имеет право потребовать возврата аванса, сославшись на то, что работа не выполнена в срок. Включение штрафных санкций (пени в размере 0.1%–0.5% от стоимости этапа за каждый день просрочки) дисциплинирует обе стороны.

Когда стоит пересмотреть сроки разработки ТЗ

Существуют объективные обстоятельства, при которых первоначальный график разработки технического задания должен быть изменен путем подписания дополнительного соглашения:

1. Существенное изменение рамок проекта (Change Request). Если в процессе предпроектного обследования выяснилось, что требуется интеграция с устаревшей ERP-системой заказчика, документация к которой утеряна, срок разработки ТЗ увеличивается на время проведения реверс-инжиниринга этой системы.

2. Задержка предоставления информации заказчиком. Исполнитель не может сформировать требования без доступов к тестовым контурам ИТ-систем заказчика или без предоставления им регламентов бизнес-процессов. В этом случае срок сдвигается соразмерно задержке со стороны клиента.

3. Изменение законодательства. Если во время проектирования принимаются новые нормативные акты, регулирующие сферу работы ПО (например, изменения в правилах маркировки товаров или обработки персональных данных), ТЗ должно быть переработано под новые стандарты.

Чек-лист перед решением

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

• Определены ответственные лица (Single Point of Contact). С обеих сторон назначены конкретные сотрудники, обладающие правом утверждать промежуточные результаты аналитики.
• Зафиксирован формат предоставления результатов. Указано, в каком виде передаются артефакты (ссылка на проект в Figma, документ в формате DOCX, проект в Jira/Confluence).
• Прописан регламент согласования. Установлен четкий срок на рассмотрение каждой версии документа заказчиком (не более 3–5 рабочих дней) и срок на устранение замечаний исполнителем (не более 3 рабочих дней).
• Ограничено количество итераций правок. В договоре зафиксировано, что после 3-го круга внесения изменений любые новые требования оформляются как платные доработки (Change Requests).
• Указаны стандарты разработки. В договоре есть ссылка на ГОСТ 19.201-78 (для программ для ЭВМ) или ГОСТ 34.602-89 (для автоматизированных систем), определяющие структуру документа.