Дмитрий Ланецкий – ТЗ без тумана: ИИ-аудит требований, чтобы команда делала правильно (страница 5)
кто имеет право на действия;
как сущность связана с другими сущностями.
Когда термин не определен, текст превращается в художественную прозу: каждый читает свое. И даже если команда «договорилась устно», договоренность не переживает смену людей, времени и контекста. Поэтому глоссарий – не приложение «для галочки», а средство сделать смысл переносимым.
Почему «глоссарий есть» часто не значит «он работает»
Во многих документах глоссарий существует как отдельная страница, которую никто не открывает. Он не влияет на написание текста. Термины не связаны с требованиями. Определения не проверяются. В итоге:
глоссарий устаревает быстрее, чем требования;
в тексте появляются новые термины без добавления в словарь;
старые термины используются в новом смысле;
синонимы размножаются, пока никто не замечает.
Глоссарий начинает работать только тогда, когда он становится частью контроля качества. Не справочником, а системой: термин либо определен и используется единообразно, либо документ считается «не готов».
Три болезни языка, которые чаще всего ломают ТЗ
1) Синонимический шум.
Одно понятие называют разными словами: «клиент/пользователь/заказчик», «заказ/покупка/сделка», «обращение/тикет/заявка». Иногда это стилистика, но чаще – источник расхождения: у разных слов подтягиваются разные ассоциации и правила.
ИИ выявляет такие группы автоматически, потому что видит, что контекст употребления совпадает. Он не «понимает» ваш бизнес, но замечает повторяемые шаблоны: те же поля, те же статусы, те же действия – но разные названия. Это сигнал: либо вы плодите синонимы, либо у вас скрыто две сущности.
2) Омонимия смысла.
Одно слово используется в разных значениях. Самые опасные термины – самые простые: «документ», «профиль», «аккаунт», «проект», «пакет», «счет». В одном разделе «счет» – invoice, в другом – account balance. И никто не замечает, пока не появляется интеграция или отчет.
ИИ ловит это по разным связкам: если рядом с одним и тем же словом появляются разные наборы атрибутов и действий, значит, слово распадается на несколько смыслов. Это не обязательно ошибка – но это обязательно должно быть зафиксировано: либо разделяем термины («Счет на оплату» vs «Баланс счета»), либо вводим уточнение в определение.
3) Плавающие границы.
Термин вроде бы один, но его границы меняются по ходу текста. Например, «пользователь» то включает админа, то нет. «Заказ» то включает доставку, то описывается как только корзина. «Регистрация» то означает создание аккаунта, то подтверждение email.
Это самый дорогой тип ошибки, потому что он не выглядит как противоречие. Он выглядит как «естественная речь». И именно поэтому нужен аудит: чтобы заставить границы быть постоянными.
Как ИИ строит «терминологическую карту» документа
Чтобы проверять термины, недостаточно иметь список слов. Нужно иметь карту: где термин употребляется, с какими глаголами, атрибутами и условиями.
Практически полезная модель выглядит так:
Термин (существительное, сущность)
Определение (одно предложение)
Синонимы/запрещенные формы
Атрибуты (поля, свойства)
Действия (создать, изменить, отправить, удалить)
Связи (входит в, принадлежит, связан с)
Статусы (если есть)
Примечания и исключения
ИИ может извлечь это из текста даже тогда, когда вы ничего не структурировали. Он собирает повторы: где термин встречается, какие слова рядом, какие правила к нему привязаны. И затем сравнивает: одинаковая ли «обвязка» у термина во всех разделах.
Если обвязка различается – значит, либо термин плавает, либо в документе скрыто несколько сущностей под одним названием.
Глоссарий как линтер: принцип «не определено – значит нельзя»
В коде есть линтеры: они не спорят, они запрещают. Они не говорят «ну, вроде понятно». Они говорят: «ошибка, не проходит». Для требований можно создать такую же культуру.
Правило простое: если в документе появляется новый термин (ключевая сущность, роль, статус, событие), он должен:
быть добавлен в глоссарий,
иметь определение,
быть использован единообразно.
ИИ легко выступает линтером: он находит термины, которых нет в словаре. Находит определения, которые не совпадают с употреблением. Находит синонимы, которые просачиваются.
И главное – делает это каждый раз одинаково, не уставая, не стесняясь и не пропуская мелочи.
Что считать «термином» на практике
Одна из причин, почему глоссарии вырождаются, – люди пытаются определить все слова. Это превращает словарь в энциклопедию и убивает мотивацию.
Рабочее правило: термином считается то, что влияет на решения и тестирование. Обычно это:
сущности данных (Заказ, Платеж, Заявка, Документ);
роли (Пользователь, Администратор, Менеджер);
статусы (Черновик, Отправлен, Подтвержден);
события (Создано, Оплачено, Отменено);
бизнес-понятия, которые несут правила (Тариф, Лимит, Комиссия).
Служебные слова и интерфейсные подписи не нужны в глоссарии. Нужны те, что управляют поведением системы.
Как ИИ помогает писать определения, которые реально работают
Плохое определение звучит красиво и бесполезно: «Заявка – это запрос пользователя на услугу». Хорошее – ограничивает: «Заявка – это сущность, создаваемая пользователем для получения услуги X; имеет статусы A/B/C; считается созданной после события Y; уникальна в рамках Z».
ИИ может предложить такие определения не из «мудрости», а из текста: он собирает все места, где термин описан, и синтезирует короткое определение, которое включает реальные свойства и правила. Затем человек утверждает или правит. Так глоссарий перестает быть «сочинением», он становится извлеченной моделью.
Критерий качества определения прост: если по нему можно написать тест-кейс или таблицу статусов, значит, оно хорошее.
Типовой процесс: терминологический аудит как этап Ready for Dev
Чтобы термины перестали быть «последним разделом в конце», нужен процесс.
Минимальный цикл:
Автор пишет черновик ТЗ.
ИИ извлекает кандидаты в термины и строит терминологическую карту.
ИИ отмечает:
термины без определения,
синонимы одного понятия,
слова с несколькими смыслами,
плавающие границы.
Команда принимает решения: