Дмитрий Ланецкий – ТЗ без тумана: ИИ-аудит требований, чтобы команда делала правильно (страница 2)
Уровень 4. Единый глоссарий: термины закреплены, документ перестает «разговаривать разными словами».
Уровень 5. Проверяемость: большинство требований имеют измеримые критерии и понятные границы.
Уровень 6. Обработка исключений: описаны ошибки, альтернативные ветки, крайние случаи.
Уровень 7. Согласованность: требования не противоречат друг другу и не конфликтуют с нефункциональными условиями.
Уровень 8. Трассируемость: видно, какая цель породила требование и как оно будет приниматься.
Уровень 9. Автоматизированный аудит: ИИ регулярно проверяет текст на туман, пробелы, противоречия и структуру.
Уровень 10. Непрерывное качество: требования живут вместе с продуктом, обновляются дисциплинированно, а «готовность к разработке» подтверждается системой проверки, а не верой.
Эра «бесшовных» спецификаций наступает не потому, что тексты стали длиннее или инструменты умнее. Она наступает потому, что скорость разработки и цена ошибки больше не позволяют надеяться на внимательность человека как на единственный барьер. В новых условиях выигрывает не тот, кто «лучше пишет», а тот, кто строит процесс, где смысл проверяется так же строго, как код.
Глава 2. Машина вопросов: как ИИ превращает ТЗ в список точных уточнений
В плохих требованиях много слов и мало вопросов. В хороших – наоборот: текст устроен так, чтобы вопросы уже были закрыты. Между этими двумя состояниями лежит работа, которую почти никто не любит: уточнять. Не «дописывать еще абзац», а вытаскивать из головы стейкхолдера конкретику, которая превращает намерение в спецификацию.
ИИ полезен здесь не как писатель, а как генератор вопросов. Как машина, которая видит неопределенность – и мгновенно переводит ее в список уточнений. Это меняет психологию процесса. Если раньше уточняющие вопросы воспринимались как «придирки» или «торможение», то теперь они становятся стандартной частью потока: «мы прогнали через аудит – вот вопросы, на которые нужно ответить, чтобы задача была Ready for Dev».
Почему вопросы важнее текста
Текст требований – это попытка зафиксировать решение. Вопросы – способ проверить, что решение вообще существует. Большинство провалов в разработке начинаются не с того, что команда сделала неправильно. Они начинаются с того, что команда сделала «как-то», потому что точного ответа не было.
Вопрос – это тест на границу. Если на него нельзя ответить однозначно, значит, граница не определена. А если границы нет, вы не сможете ни разработать, ни протестировать, ни принять результат.
Уточняющие вопросы выполняют три функции одновременно:
выявляют пропуски;
обнаруживают скрытые конфликты;
создают критерии приемки.
Хороший вопрос – это не «а можно подробнее?». Хороший вопрос – это «какое значение должно быть в поле X при условии Y?» или «кто имеет право на действие Z и в каких случаях?». Он не просит объяснить, он требует выбрать вариант.
Три типа «тумана», которые ИИ превращает в вопросы
Любая неопределенность в требованиях сводится к одной из трех категорий.
1) Неясные сущности.
В тексте упоминается объект, но не определено, что это такое и какие у него свойства. «Заявка», «профиль», «документ», «черновик», «заказ» – слова, которые звучат очевидно, пока не выясняется, что в разных отделах они означают разное.
ИИ задает вопросы вроде:
Какие обязательные поля у сущности?
Когда сущность считается созданной: после сохранения черновика или после отправки?
У сущности есть статусы? Какие переходы разрешены?
2) Неясные правила.
Есть действие, но не определены условия и исключения. «Система должна отправлять уведомления», «пользователь может редактировать», «данные обновляются автоматически». Вопрос не в том, что делать, а в том, когда не делать.
ИИ формулирует:
При каких условиях действие запрещено?
Что происходит при ошибке внешнего сервиса?
Есть ли лимиты: частота, объем, количество попыток?
3) Неясные критерии качества.
Функция описана как «удобная» или «быстрая», но без метрики. Это туман, который всегда превращается в конфликт при приемке: «мы думали, будет иначе».
ИИ спрашивает:
Как измеряем «быстро»: p95, p99, среднее?
Какая целевая аудитория и какие устройства считаем типовыми?
Какой сценарий берем за базовый при оценке?
Эти вопросы кажутся «техническими», но на самом деле они бизнесовые: они определяют, что будет считаться успехом.
Как устроен хороший набор вопросов
Плохие вопросы случайны: «вот тут непонятно». Хорошие – системны: они покрывают ключевые измерения требования. Практически любой функциональный пункт можно прогнать через одну и ту же рамку.
Роли: кто делает действие, кто видит результат, кто запрещен?
Данные: какие поля, валидации, форматы, источники?
Сценарии: основной поток, альтернативы, ошибки, крайние случаи?
Состояния: статусы, переходы, обратимость, журналирование?
Интеграции: какие внешние системы, таймауты, ретраи, деградация?
НФТ: скорость, надежность, безопасность, доступность, локализация?
Приемка: как тестируем, что считаем корректным, какие примеры?
ИИ можно обучить этой рамке не в смысле дообучения модели, а в смысле правильного промпта и стандарта. Тогда «машина вопросов» перестает быть хаотичной и начинает выдавать одинаково полезные наборы для разных задач.
«Вопросы как код»: превращаем уточнения в структуру
Есть старый прием инженеров: если нельзя написать тест, значит, вы не знаете, что строите. С требованиями так же: если нельзя сформулировать вопрос в формате «если X, то Y», значит, правило не определено.
Когда команда начинает относиться к вопросам как к формальному артефакту, появляется новая дисциплина:
каждый вопрос привязан к конкретному фрагменту требования;
каждый вопрос имеет тип (роль/данные/правило/НФТ/приемка);
у каждого вопроса есть статус (открыт/отвечен/спорный/перенесен);
ответы встраиваются обратно в документ, а не остаются в переписке.
Так появляется «протокол уточнений» – слой, который связывает живую коммуникацию и статичный текст. ИИ может поддерживать этот слой почти автоматически.
Почему люди сопротивляются уточнениям – и как ИИ снижает трение
Большинство конфликтов вокруг требований – это не конфликт логики. Это конфликт статусов и эмоций. Когда аналитик задает много вопросов, стейкхолдер может слышать: «ты плохо объяснил», «я не доверяю», «ты усложняешь».
ИИ снимает часть персонального напряжения. Вопросы исходят не от человека, который «сомневается», а от процедуры качества: «аудит показал неопределенности». Это не отменяет ответственности, но меняет тон разговора. Вопросы становятся не оценкой автора, а шагом процесса.
Важный нюанс: ИИ не должен «переспрашивать ради переспрашивания». Если он генерирует сотни однотипных вопросов, команда перестает их читать. Поэтому нужна фильтрация и приоритизация.
Приоритизация вопросов: что уточнять в первую очередь
Не все вопросы одинаково важны. Некоторые критичны для архитектуры и сроков, другие можно уточнить позже. Практически полезна простая шкала:
Критично (блокер): без ответа невозможно начать разработку.