Дмитрий Ланецкий – ТЗ без тумана: ИИ-аудит требований, чтобы команда делала правильно (страница 4)

найти все места, где упоминается «заявка»;

понять, что «обращение» – это то же самое;

сопоставить условия;

заметить, что «после модерации» и «после подтверждения» описывают один и тот же этап.

ИИ делает это быстро – и именно поэтому он превращает «невозможную проверку» в регулярную.

Противоречия vs вариативность: как не превращать аудит в паранойю

Не каждый «разный текст» – конфликт. Иногда это разные режимы:

разные роли (админ vs пользователь);

разные платформы (мобайл vs веб);

разные тарифы (бесплатный vs платный);

разные юрисдикции (EU vs остальной мир);

разные каналы (email vs push).

Проблема не в том, что режимы существуют, а в том, что документ не говорит, где какой режим. Хороший аудит не обвиняет, он уточняет: «это два разных режима? тогда нужны условия переключения». ИИ должен не просто кричать «противоречие», а формулировать вопрос: какое утверждение применяется при каких условиях?

В идеале результат аудита выглядит так:

потенциальный конфликт A ↔ B;

общая сущность и аспект;

отличающиеся условия;

вопрос: «это разные сценарии или ошибка?»

предложение: как разнести по условиям, чтобы стало непротиворечиво.

Практика «одного источника правды»: где именно должна жить каждая истина

Противоречия часто возникают потому, что одно и то же правило описано в нескольких местах. Например, права доступа прописаны и в разделе «Роли», и в сценариях, и в требованиях к API. Кажется логичным – но это три точки, которые нужно синхронизировать при изменении.

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

статусы и переходы – в таблице статусов (и сценарии на нее ссылаются);

права – в матрице ролей (и UI/API используют ссылки);

поля и форматы – в модели данных (и сценарии не повторяют форматы);

НФТ – в отдельном разделе, а функционал лишь ссылается.

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

«Конфликтная карта»: как упаковывать результаты аудита так, чтобы ими пользовались

Самая частая ошибка аудита – он выдает длинный список замечаний без структуры. Люди перестают читать. Поэтому результаты нужно упаковывать:

Топ-10 критичных конфликтов (блокируют разработку или приемку).

Список средних конфликтов (риск переделок).

Слабые несостыковки (термины, формулировки, стилистика).

Для каждого пункта:

цитата фрагмента A и B (коротко);

почему это конфликт (в одном предложении);

что надо уточнить/решить;

куда внести правку (раздел/артефакт).

ИИ может сформировать такую «конфликтную карту» автоматически, и это делает аудит пригодным для работы, а не просто «отчетом ради отчета».

Пример типичного противоречия и правильное исправление

Пусть в документе есть:

«Пользователь может отменить заказ до момента оплаты».

«После создания заказа отмена недоступна, возможен только возврат».

Это выглядит как конфликт, но может быть решено, если уточнить статусную модель:

статус «Создан» (до оплаты) – отмена доступна;

статус «Оплачен» – отмена недоступна, доступен возврат;

статус «В обработке» – отмена по правилам X;

статус «Доставлен» – возврат по правилам Y.

Правильное исправление – не переписать одну фразу, а вынести правило в таблицу статусов, а обе формулировки сделать ссылками на нее. Тогда противоречие исчезает системно.

Почему тестировщик не должен быть первым, кто находит конфликт

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

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

Итог: конфликт – это не ошибка текста, это ошибка согласования

Требования противоречат друг другу не потому, что автор «плохо писал». Они противоречат, потому что в организации существуют разные цели, разные ограничения и разные представления о правильном решении. Документ – место, где эти различия должны быть согласованы и превращены в единый набор правил.

ИИ помогает сделать это раньше, чем конфликт успеет стать кодом.

Следующая глава – про глоссарий и термины: как ИИ ловит ситуацию, когда команда говорит «одними словами», но про «разные вещи», и почему это главный источник скрытых багов.

Глава 4. Война терминов: как ИИ превращает глоссарий из формальности в систему контроля смысла

Большинство команд уверены, что говорят на одном языке. И почти каждая команда ошибается.

Проблема терминов коварна тем, что она редко выглядит как проблема. Слова привычны, обсуждения идут бодро, документы пишутся быстро. А потом внезапно выясняется, что «заявка» для бизнеса – это намерение клиента, для поддержки – это тикет, для разработки – запись в базе, а для юридического отдела – документ, который надо хранить пять лет. Все уверены, что правы, и все действительно правы – просто каждый прав в своей комнате. Требования же пытаются собрать эти комнаты в один дом. И если у дома разные планы этажей, он трескается.

ИИ особенно полезен там, где человек бессилен: в систематическом обнаружении расхождений языка. Не «подозрительных слов» вообще, а конкретных мест, где термин живет в нескольких значениях, где одно и то же понятие названо разными словами, и где слова создают ложную уверенность.

Термины – это не слова. Это контракт

В требованиях термин – это не лексика, а юридический контракт внутри команды. Он фиксирует:

что именно является сущностью;

где границы этой сущности;

какие свойства обязательны;

какие действия допустимы;