Дмитрий Ланецкий – ТЗ без тумана: ИИ-аудит требований, чтобы команда делала правильно (страница 1)
Дмитрий Ланецкий
ТЗ без тумана: ИИ-аудит требований, чтобы команда делала правильно
Глава 1. Эра «бесшовных» спецификаций: почему человек больше не лучший аудитор
Есть профессии, где цена одной неверной фразы измеряется не временем, а цепочкой последствий. Требования к продукту – как раз такая область. Одно слово «быстро», одно «примерно», одна пропущенная оговорка про роли или исключения – и дальше все движется по инерции: дизайнер рисует одно, разработчик понимает другое, тестировщик проверяет третье, а пользователь получает четвертое. Ошибка в коде заметна сразу: она падает, ломает, кричит. Ошибка в тексте требований умеет быть тихой – и потому особенно дорогой.
Цена ошибки в тексте: почему исправление требования на этапе кода стоит в разы дороже
Когда команда обнаруживает проблему уже в реализации, она редко ограничивается «поправим одну строчку». Изменение требования затрагивает архитектурные решения, сценарии, данные, интерфейсы, интеграции, тесты, документацию и обучающие материалы. Чем позже вы ловите дефект смысла, тем больше следов он успевает оставить. Поэтому в индустрии так устойчиво живет идея: исправление ошибки на стадии разработки и тем более после релиза может стоить на порядок дороже, иногда – в десятки раз, чем на стадии формулирования и согласования.
Важно не число, а механизм. На раннем этапе вы платите временем мысли: переформулировать, уточнить, договориться. На позднем – временем системы: переписать, откатить, мигрировать, защититься от побочных эффектов. И еще вы платите доверением: команда устает от постоянных «ой, мы имели в виду другое», а бизнес теряет темп.
ИИ как «холодный рецензент»: отсутствие замыленного глаза и предвзятости
Человек, который писал требования, почти неизбежно «достраивает» текст в голове. Он помнит обсуждения, контекст, нюансы, которые остались за пределами документа. Поэтому он читает свою же формулировку не как читатель, а как автор – и пропускает дырки, потому что мозг услужливо подставляет недостающее.
ИИ-аудитор в этом смысле полезен именно своей холодностью. Он не был на встрече, не слышал интонаций, не понимает «ну вы же знаете, как у нас принято». Он видит только текст – и это главный критерий качества требований: если смысл нельзя восстановить из документа, значит, документ не выполняет функцию.
При этом «холодность» – не про бездушие, а про дисциплину. ИИ не устает перечитывать одно и то же. Не раздражается на десятый одинаковый абзац. Не делает скидку на статус автора. Не «понимает, что вы имели в виду» – и именно поэтому помогает заставить документ говорить прямо.
Проблема информационной плотности: когда объем документа превышает возможности внимания
Современные продукты сложны, и требования часто превращаются в массив текста, где важное и второстепенное смешано. Чем выше плотность информации, тем труднее удерживать картину целиком. В итоге возникает типичная ловушка: каждую отдельную строчку можно защитить, но целое перестает быть читаемым и проверяемым.
Человек в такой ситуации начинает пользоваться сокращениями мышления: пролистывает знакомые места, цепляется за ключевые слова, игнорирует редкие ветки. Это не слабость, а свойство внимания. И именно здесь ИИ дает преимущество: он способен последовательно пройти документ целиком, удерживая одинаковое качество проверки от первой страницы до последней, не «проседая» на рутине.
Автоматизация против рутины: освобождение системного аналитика для проектирования смыслов
Парадокс профессии аналитика в том, что самые дорогие компетенции часто тонут в обслуживании процесса. Вместо того чтобы проектировать логику, искать оптимальные сценарии, строить удобную модель предметной области, специалист неделями вычитывает формулировки, ловит повторы, сверяет термины, проверяет, не забыл ли кто-то слово «не».
ИИ не снимает ответственность, но снимает часть рутинной нагрузки: первичную вычитку, подсветку «мягких» мест, список вопросов к стейкхолдерам, поиск несоответствий по глоссарию, базовую проверку структуры. В идеале это меняет экономику труда: аналитик меньше «пишет текст», больше проектирует смысл и управляет качеством коммуникации.
ИИ-детектор неопределенности: как нейросеть считывает «туман» в формулировках
Неопределенность редко выглядит как явная ошибка. Обычно она маскируется под «все понятно». В тексте требований туман появляется в трех типичных формах:
слова-оценки: «быстро», «удобно», «красиво», «достаточно надежно»;
размытые границы: «при необходимости», «в некоторых случаях», «по умолчанию» без описания условий;
скрытые сравнения: «улучшить», «упростить», «оптимизировать» без точки отсчета.
ИИ хорошо замечает такие места, потому что он «не знает», как именно в вашей компании принято понимать «быстро». И он заставляет задать правильный вопрос: чем измеряем? где граница? кто решает, что условие наступило? какой сценарий считается эталоном?
Это не придирки. Это превращение желания в проверяемое требование. Там, где раньше было «удобно», появляется «не более трех кликов». Там, где было «быстро», появляется «время ответа в типовом сценарии». И документ перестает быть литературой, становится инженерной инструкцией.
Переход от «написания» к «валидации»: новая роль автора требований
Раньше умение писать требования воспринималось как навык создания текста. Сегодня все больше – как навык настройки проверки. Хороший документ рождается не из вдохновения, а из цикла: сформулировал → проверил → уточнил → проверил снова. ИИ ускоряет этот цикл до темпа, в котором становится нормой проверять каждую существенную формулировку сразу, а не «на финальной вычитке перед разработкой».
Роль автора меняется: он становится куратором смысла. Он задает структуру, объясняет намерение, выбирает точность, определяет ограничения. А затем организует валидацию: прогон через чек-листы, сверку по глоссарию, тест на противоречия, поиск пропусков. В этом подходе качество появляется не потому, что автор «очень постарался», а потому что система не позволяет плохому тексту пройти дальше.
Скорость обратной связи: аудит за минуты вместо многочасовых встреч
В классическом процессе многие проблемы всплывают на встречах: «подождите, а что значит…», «а кто это делает…», «а что будет, если…». Эти обсуждения важны, но у них есть недостаток: они дороги по времени и зависят от состава участников. Если на созвоне не оказалось нужного человека, вопрос уходит в «потом», а потом превращается в баг или конфликт.
ИИ способен дать первую волну вопросов быстро. Не вместо людей, а до людей. Он помогает подготовить повестку: что именно неясно, где конфликт, какие термины гуляют, какие сценарии не покрыты. В результате встреча становится короче и предметнее. Команда тратит время не на чтение текста вслух, а на решения.
Прозрачность качества: введение объективных метрик для оценки текста ТЗ
Одна из причин, почему требования часто «вечно недовольны всеми», заключается в отсутствии измеримости. «Хорошее ТЗ» звучит как вкус. У каждого свой. И когда метрик нет, спор превращается в борьбу авторитетов.
ИИ-аудит открывает дорогу к метрикам текста. Не к идеальным и абсолютным, а к полезным и сравнимым. Например:
доля неопределенных формулировок на страницу;
количество терминов, не совпадающих с глоссарием;
число требований без критериев приемки;
количество упоминаний ролей без описания прав;
процент сценариев без обработки ошибок и исключений.
Эти метрики не заменяют здравый смысл, но дают инструмент управления. Вы видите динамику: документ улучшается или деградирует. Команда может договориться о порогах «готово к разработке» и перестать спорить на уровне ощущений.
Культура Ready for Dev: как ИИ гарантирует, что задача понятна разработчику
«Готово к разработке» – это не статус в трекере и не фраза «вроде все обсудили». Это состояние текста, при котором разработчик может принять решения без угадывания. Хорошая спецификация отвечает на вопросы, которые возникают у инженера автоматически: какие входы, какие выходы, какие роли, какие ограничения, какие исключения, какие интеграции, какие критерии приемки.
ИИ здесь полезен как имитатор «внешнего читателя». Он может сыграть роль разработчика, который не был в контексте, и задать вопросы, которые обычно всплывают слишком поздно. Если ИИ при чтении требования постоянно вынужден спрашивать «что именно?», «когда?», «для кого?», «что если?», значит, документ еще не готов.
На практике культура Ready for Dev выглядит как привычка: ни один существенный пункт не уходит в разработку без минимального пакета ясности. ИИ помогает сделать эту привычку дешевой, регулярной и не зависящей от настроения команды.
Артефакт: карта «10 уровней зрелости требований: взгляд ИИ»
Чтобы видеть прогресс, полезно иметь простую шкалу зрелости. Ниже – карта из десяти уровней, по которой можно оценивать, где находится ваш процесс работы с требованиями и куда расти дальше.
Уровень 1. Текст как переписка: требования существуют в чатах и устных договоренностях.
Уровень 2. Документ есть, но без структуры: длинные абзацы, мало разделов, много «понятно по контексту».
Уровень 3. Появляется шаблон: роли, сценарии, ограничения, критерии приемки хотя бы местами.