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

Примеры: роли и права, основной сценарий, обязательные поля, критерии приемки.

Важно: без ответа возможны переделки или неверные решения.

Примеры: обработка ошибок, лимиты, интеграции, нефункциональные требования.

Желательно: улучшает продукт, но не ломает поток.

Примеры: редкие крайние случаи, нюансы текста, косметика.

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

Шаблон «пакета вопросов» для одной фичи

Чтобы вопросы были удобны, их нужно подавать в форме, которую легко обсудить и закрыть. Пример структуры:

Суть функции (пересказ в одном предложении) – чтобы сверить понимание.

Открытые определения – что такое ключевые сущности.

Правила и условия – когда работает, когда нет.

Права и роли – кто может что.

Ошибки и исключения – что если.

НФТ – скорость, надежность, безопасность.

Приемка – примеры, тестовые кейсы, критерии.

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

Встраивание в процесс: «аудит → вопросы → ответы → обновление ТЗ»

Если «машина вопросов» существует отдельно, она превращается в игрушку. Эффект появляется, когда она встроена в рутину.

Минимальный цикл:

Автор пишет черновик требования.

ИИ проводит аудит и формирует пакет вопросов.

Команда отвечает (часть – письменно, часть – на коротком созвоне).

Ответы встраиваются в ТЗ, а вопросы закрываются.

Повторный аудит проверяет, что туман исчез.

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

Ошибка, которую совершают почти все: путать вопросы с решениями

ИИ иногда может предложить варианты ответов. Это полезно, но опасно. Вопрос – это инструмент извлечения намерения. Решение – ответственность команды.

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

Поэтому вопрос должен оставаться вопросом. А опции – быть лишь способом ускорить выбор.

Итог: вопросы как ускоритель ясности

Когда требования становятся ясными, они становятся быстрыми. Не потому, что вы меньше пишете, а потому, что вы меньше переделываете. ИИ превращает уточнение из эпизода в систему: из редкого усилия – в регулярную процедуру.

В следующей главе мы разберем, как ИИ ищет противоречия в документе: когда разные части ТЗ тихо говорят разные вещи – и как ловить это до того, как конфликт превращается в баг.

Глава 3. Охота на противоречия: как ИИ находит конфликты в требованиях раньше тестировщика

Большинство проблем в требованиях – не пробелы, а конфликты. Документ может выглядеть «полным»: роли перечислены, сценарии описаны, поля названы. Но внутри него живет другая опасность – разные куски текста тихо противоречат друг другу. И пока вы читаете документ линейно, мозг сглаживает углы: «ну, это, наверное, про другое». Разработчик сглаживает так же – только кодом. А потом приходит тестировщик и обнаруживает, что система может работать либо по первому абзацу, либо по пятому, но не по обоим сразу.

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

Откуда берутся противоречия (и почему они неизбежны)

Противоречия появляются не из злого умысла. Они рождаются естественно:

документ пишут разные люди или один человек в разное время;

требования меняются, а старые фрагменты забывают обновить;

один раздел описывает «как должно быть», другой – «как было раньше»;

бизнес хочет гибкости, а безопасность – жестких правил;

интерфейс описан одним языком, API – другим.

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

Четыре вида конфликтов, которые чаще всего ломают проект

1) Конфликт ролей и прав.

В одном месте сказано: «пользователь может редактировать заявку», в другом: «после отправки заявку редактировать нельзя». Оба утверждения могут быть «верными», но при разных условиях. Если условий нет – это противоречие.

2) Конфликт статусов и переходов.

Документ описывает статусы сущности, но переходы между ними расходятся: в разделе «Сценарии» есть переход A→C, а в разделе «Бизнес-правила» утверждается, что после A возможен только B.

3) Конфликт данных и валидаций.

В одном разделе поле обязательное, в другом – «если заполнено». В одном месте формат даты ISO, в другом – локальный. В одном месте ограничение 255 символов, в другом – 500.

4) Конфликт нефункциональных требований.

«Система должна хранить историю изменений 3 года» и «данные должны быть удалены по запросу пользователя в течение 30 дней». Это не «ошибка», это необходимость согласовать приоритеты и режимы хранения.

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

Как ИИ технически «видит» противоречие, даже если оно замаскировано

В документе редко встречается прямое «разрешено» vs «запрещено» рядом. Обычно конфликт спрятан в деталях:

разные слова для одной сущности («заявка» vs «обращение»);

разные модальности («может» vs «должен»);

разные условия («после отправки» vs «после подтверждения»);

разные уровни абстракции (раздел про UI против раздела про API);

разная степень категоричности («всегда» vs «как правило»).

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

«Матрица согласованности»: простой артефакт, который спасает большие ТЗ

Чтобы превратить охоту на противоречия в процесс, полезно мыслить матрицей: сущность × аспект.

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

Вручную это адская работа, потому что вам нужно: