Ошибки в ТЗ на разработку ПО: статистика и цена промахов

Это прямое следствие того, что система начала строиться до фиксации границ, сценариев и критериев приёмки.

Статистика ошибок в ТЗ на разработку ПО показывает устойчивую картину. По анализу 117 проектов, 31% дефектов зарождается на стадии технического задания. Ещё 66% появляется при реализации. Между этими цифрами нет противоречия: дефект требования часто проявляется как дефект кода, интеграции или приёмки. Команда исправляет симптом. Источник остаётся в исходной постановке.

Проблема не в самом документе ТЗ. Проблема в отсутствии управляемого процесса requirements engineering: декомпозиции, валидации, трассировки и тестирования требований до передачи задачи в разработку.

Анатомия дефектов: где требования теряют точность

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

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

Типовые дефекты ТЗ для корпоративного и настольного ПО:

• Не определён владелец данных. Неясно, какой модуль создаёт запись, какой имеет право её менять, где хранится audit trail.
• Не описана модель доступа. Роли названы, но отсутствует matrix разрешений: просмотр, создание, редактирование, экспорт, удаление, согласование.
• Пропущены негативные сценарии. Есть путь «документ сохранён», но нет поведения при конфликте версий, сетевом таймауте, недоступности API, переполнении хранилища.
• Смешаны functional и non-functional requirements. В одном пункте одновременно требуют сформировать отчёт, отдать его за две секунды и поддержать 5 тыс. параллельных сессий. Такие условия требуют разных методов проверки.
• Не зафиксированы интеграционные контракты. В ТЗ есть фраза «получать данные из ERP», но нет схемы полей, SLA внешней системы, политики retry, idempotency и правил обработки дублей.
• Не определён источник истины для справочников. После запуска появляются расхождения между CRM, бухгалтерской системой, локальной базой приложения и BI-витриной.
• Не описан lifecycle объекта. Статусы перечислены, но переходы между ними не ограничены. Пользователь может отменить уже закрытую операцию или отредактировать документ после отправки в архив.

Для desktop-софта и офисных программ к этому добавляются особенности клиентской среды: локальное хранение, права на файловую систему, обновления ОС, поддержка форматов, сетевые папки, корпоративные proxy, ограничения endpoint protection. Формулировка «приложение должно открывать файл» не является требованием. Нужна матрица: какие форматы, какой предельный размер, что происходит при повреждённом файле, где создаётся временная копия, как удаляются остаточные данные.

Дефект требования — это не пункт с опечаткой. Это незафиксированное решение, которое команда примет позднее и уже за счёт бюджета разработки.

Ошибки на стадии ТЗ особенно опасны тем, что они проходят CI/CD без технических сигналов. Pipeline способен выявить падение unit-теста, нарушение контракта API, деградацию coverage. Он не определит, что бизнес ожидал другой порядок согласования или что оператор не должен видеть персональные данные в экспортном файле.

Почему стоимость исправления растёт по фазам

Классическая модель Барри Боэма описывает рост стоимости исправления дефекта по мере движения продукта в жизненном цикле. За единицу берётся исправление на стадии требований. На проектировании стоимость оценивается в 5x, при кодировании — в 10x, на тестировании — в 20x, после релиза — до 100x.

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

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

Например, в ТЗ на внутренний документооборот не указан запрет на редактирование документа после подписания. На стадии требований это одна строка в state model и одно правило доступа. После реализации затрагиваются:

• frontend-форма и доступность control-элементов;
• backend-проверки переходов статусов;
• модель ЭП или журнал событий;
• интеграция с архивом;
• экспорт в офисные форматы;
• права ролей;
• набор автотестов;
• данные, уже созданные в production.

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

По данным исследований, переделка ошибочных требований занимает от 28% до 42% всех затрат на разработку. Оценка Boehm и Pappacio ещё жёстче: исправление ошибок требований поглощает от 30% до 50% бюджета проекта. Для архитектурного комитета это означает одно: бюджет на разработку нельзя отделять от качества входного контура. Это один финансовый контур.

Тестирование требований: shift-left без формального ритуала

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

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

На одну фичу тестирование требований занимает от 25 минут до 6 часов. Исправление самого ТЗ — от 10 минут при мелкой корректировке до 9–10 часов, если нужно пересобрать логику и пройти согласования. Это дешевле, чем менять реализацию после того, как задача прошла refinement, development и QA.

Процесс целесообразно встраивать до commit в sprint, а не превращать в отдельный бюрократический шлюз.

Минимальный контур проверки для команды

1. Проверить атомарность. Одно требование описывает один наблюдаемый результат. Формулировка «добавить импорт, валидацию и уведомления» должна быть разложена на независимые элементы backlog.

2. Построить сценарии до разработки. Для каждой роли фиксируются happy path, альтернативные ветки, ошибки ввода, недоступность зависимости и правила восстановления операции.

3. Задать acceptance criteria в проверяемой форме. Не «система быстро формирует отчёт», а измеримое условие: объём входных данных, допустимое время ответа, среда измерения, поведение при превышении лимита.

4. Проверить трассировку. У business requirement должна быть связь с функциональным требованием, архитектурным решением, задачей разработки и набором тестов. Без traceability невозможно доказать полноту покрытия.

5. Выделить NFR в отдельный слой. Performance, availability, RPO, RTO, security, observability, compatibility и требования к обновлению не должны растворяться в пользовательских историях.

6. Провести техническую валидацию. Архитектор подтверждает, что требование не конфликтует с выбранным стеком, лицензированием, ограничениями ОС, network topology и vendor lock-in.

7. Подготовить тестовый дизайн до реализации. Если QA не может сформировать test cases из требования, задача не готова к разработке. Это не дефект QA. Это дефект входных данных.

Внедрение такого подхода сокращает среднюю продолжительность жизненного цикла фичи на 1,5–7 часов. В проектах, где практика закреплена в delivery-процессе, количество багов снижается в 2–5 раз, а экономия общего бюджета разработки достигает 30%.

Shift-left не переносит QA «влево». Он устраняет передачу неформализованных решений в код.

Неполные сценарии становятся дефектами при приёмке

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

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

Через два месяца после внедрения тестирования требований число дефектов, связанных с пропущенными сценариями, в одном из наблюдаемых кейсов сократилось в пять раз: с 15 до 3. Количество багов из-за отсутствия тест-кейсов снизилось втрое: с 3 до 1. Такие цифры не означают, что процесс гарантирует отсутствие дефектов. Он сокращает класс дефектов, который дешевле всего устранить до начала реализации.

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

Примерные зоны риска:

• обновление Windows или macOS меняет модель прав и ломает привычный путь записи файлов;
• новый дистрибутив Linux обновляет библиотеку, от которой зависит desktop-клиент;
• офисный пакет по-разному интерпретирует шаблон, созданный в другой версии;
• синхронизация работает при постоянном соединении, но создаёт конфликты после offline-режима;
• обновление не предусматривает rollback и оставляет базу данных в несовместимой схеме.

Все эти случаи должны быть видны в ТЗ как ограничения и сценарии эксплуатации. Нельзя компенсировать их фразой «поддерживать актуальные версии ОС». У неё нет границ тестирования, оценки и SLA.

Нефункциональные требования следует вести как измеряемый каталог. В нём фиксируют:

• поддерживаемые версии ОС, браузеров, офисных пакетов и runtime;
• лимиты на размер файла, число записей, объём базы и длительность операции;
• требования к журналированию, retention policy и экспорту audit log;
• допустимое время простоя при обновлении;
• порядок миграции данных и rollback;
• условия работы при нестабильной сети;
• минимальные требования к CPU, RAM, дисковому пространству и сетевому каналу;
• правила обработки персональных и коммерчески чувствительных данных.

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

ТЗ как контракт между продуктом, разработкой и эксплуатацией

В enterprise-разработке ТЗ нельзя рассматривать как документ аналитика. Это контракт минимум между четырьмя контурами:

В зрелом delivery-процессе требование не получает статус Ready только потому, что его согласовал заказчик. Оно проходит review по нескольким осям: бизнес-ценность, архитектурная реализуемость, тестируемость, безопасность, эксплуатационная пригодность.

Для команды, которая поддерживает несколько версий desktop-приложения, это особенно критично. В backlog должно быть отдельно видно, какие требования относятся к новой функции, какие — к compatibility layer, какие требуют миграции, а какие создают обязательства по сопровождению. Иначе feature delivery незаметно превращается в накопление несовместимостей.

Иногда проблема лежит вне контура разработки: пользователи получают новую функциональность без объяснения изменённого процесса и создают поток обращений в service desk. Канал коммуникации не заменяет спецификацию, но снижает операционный шум. Для подготовки понятных материалов о повседневных изменениях полезен формат практических жизненных советов, если он отделён от технической документации и runbook.

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

Оценка Института программной инженерии SEI указывает, что ошибки в требованиях обходятся бизнесу США более чем в 30 млрд долларов ежегодно. Для отдельной компании этот показатель не нужно механически переводить в локальную валюту или использовать как прогноз. Его функция другая: показать масштаб класса потерь.

Архитектурный комитет должен считать не стоимость одного дефекта, а стоимость потока переделок.

Для этого достаточно собрать несколько метрик в Jira, YouTrack или другой ALM-системе:

• долю задач, возвращённых из QA в статус анализа;
• количество change request после старта разработки;
• число дефектов, классифицированных как missing requirement;
• время от Ready for Development до приёмки;
• долю незапланированных работ в спринте;
• количество инцидентов, где root cause связан с отсутствующим или противоречивым требованием;
• объём часов на rework по компонентам;
• процент требований с привязанными acceptance criteria и test cases.

Эти показатели не требуют сложной BI-платформы. Достаточно договориться о классификации причин и не списывать все возвраты в общий статус «доработка». Если причина не маркируется, организация не видит, где теряет бюджет: в анализе, архитектуре, кодировании или эксплуатации.

31% дефектов, возникающих на этапе ТЗ, не означают, что нужно переносить ответственность за качество продукта на аналитика. Это означает, что входной контур должен стать коллективной инженерной процедурой. Бизнес отвечает за правила и результат. Архитектура — за ограничения и целостность. Разработка — за реализуемость. QA — за проверяемость. Эксплуатация — за жизнеспособность после релиза.

Финальный контроль перед передачей задачи в разработку должен быть предельно прикладным:

• у функции определены пользователь, владелец данных и границы ответственности;
• основной, альтернативный и аварийный сценарии описаны;
• acceptance criteria можно проверить без устных пояснений;
• NFR вынесены в измеримые параметры;
• интеграционные контракты, таймауты и обработка ошибок зафиксированы;
• есть связь между требованием, архитектурным решением и тестами;
• определены условия обновления, миграции и rollback;
• change request после старта разработки учитывается как метрика качества требований, а не как фоновая работа.

Ошибки в ТЗ на разработку ПО не устраняются согласованием документа в почте. Они снижаются через requirements testing, трассировку и дисциплину Ready. Это дешевле, чем исправлять последствия в коде, на приёмке и в production.