Что можно анализировать месяц?

**** Когда мы начали регулярно измерять Lead Time, меня удивил один показатель. Самым длинным этапом разработки очень часто оказывался… анализ требований.

Не разработка. Не тестирование. Не согласования. А именно анализ.

Иногда он занимал несколько недель, а иногда и больше месяца.

И у меня возник простой вопрос: Что можно анализировать месяц?

Чтобы найти ответ, я пошла не в отчеты, а на встречи бизнеса с командой. И увидела очень знакомую картину. Бизнес приносит идею: иногда это несколько страниц текста, а иногда буквально несколько тезисов “на салфетке”. Дальше начинается бесконечный цикл вопросов. Аналитик уточняет => потом разработчики => потом архитектор =>потом тестировщики. И в какой-то момент я поймала себя на мысли: Мы уже не анализируем требования. Мы пишем их вместо бизнеса. Именно тогда я решила провести эксперимент. Вместо того чтобы самой в десятый раз перечитывать документ, я попросила AI сделать совсем другую работу. Не написать требования. А найти в них слабые места. Честно говоря, с первого раза получилось посредственно.

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

Например: — каких данных не хватает; — где нарушена логика; — какие сценарии забыли описать; — какие вопросы обязательно нужно задать бизнесу до начала разработки.

После нескольких итераций результат приятно удивил. За несколько минут AI выдавал тот список вопросов, который опытный аналитик обычно формирует после долгого чтения документа. И вот здесь произошло самое интересное: мы поняли, что ценность AI вовсе не в том, что он анализирует требования вместо аналитика - он помогает аналитикам быстрее думать.

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

После этого мы начали использовать такой подход не только в аналитике, но и вместе с Product Owner’ами. А затем появилась новая идея. Если AI умеет находить пробелы в требованиях… Почему бы не помочь бизнесу написать хорошие требования сразу? Так родилась идея мультиагентной системы. Сейчас мы создаем BRD-агента, который помогает проверить требования еще до того, как они попадут в разработку. Он не заменяет аналитика. И не заменяет Product Owner’а. Он помогает увидеть то, что легко упустить в начале проекта. Прототип уже радует результатами, и сейчас мы готовимся к его внедрению.

Что я вынесла из этой истории: Для меня это совсем не история про AI. Это история про инженерное мышление. Мы не искали, куда можно «прикрутить» новую технологию - мы нашли узкое место в процессе, поняли его причину и только потом подобрали инструмент. Мне кажется, именно в этом сегодня и заключается работа технологического руководителя. Не внедрять AI ради AI. А строить инженерные системы, в которых технологии помогают людям принимать лучшие решения.

P.S. Любопытно, что самый заметный эффект оказался вовсе не в экономии времени аналитиков. Главным изменением стало качество диалога между бизнесом и ИТ. Когда на первую встречу приходишь уже с хорошо структурированными вопросами, обсуждение превращается из бесконечного уточнения деталей в совместный поиск лучшего решения. И именно это, на мой взгляд, гораздо ценнее любой автоматизации.

Что можно анализировать месяц? | Сетка — социальная сеть от hh.ru