Сегодня тяжело найти человека, который бы не слышал прогнозов о том, что нейросети уже готовы заменить системных аналитиков, в особенности на этапе формирования требований к новым системам. Например, тренер в школы системного анализа, ИТ-архитектор в “Systems.Education“ Юрий Куприянов ещё год назад писал на Хабре о том, что системные аналитики с junior level рискуют потерять работу, т.к их способен заменить ИИ. Аналогичные выводы сделал наш руководитель практики технологических решений Виталий Волнянский в своих комментариях и публикациях о нейросетях в СМИ.

Между тем, из ЕАЕ-Консалт после релиза Chat GPT до настоящего времени не был уволен ни один сотрудник, занимающийся системным анализом. Более того, среди знакомых мне системных интеграторов, компаний, разрабатывающих сложный софт для промышленности, крупного ритейла и систем безопасности (например, на основе компьютерного зрения), также не было массовых увольнений специалистов моего профиля. Более того, только на Хабр Карьера в настоящий момент 479 вакансий системных аналитиков, профессия остаётся крайне востребованной и за пределами России, например считается  дефицитной в США. В посте предлагаю данные небольшого сравнительного исследования, не претендую на научную репрезентативность, но полагаю, что результаты, отчасти, раскрывают причины того, о чем я написал выше. 

Небольшой эксперимент

Я попробовал сравнить эффективность и корректность формирования требований и создания ТЗ. С одной стороны, оценивалась работа генеративного искусственного интеллекта (Chat GPT-4 Turbo) под управлением оператора без опыта в системном анализе (работает тестировщиком), с другой, работа системного аналитика, прошедшего 6 месячные курсы бизнес-анализа (курс содержал основы системного анализа) и проработавшего один год. Чтобы исключить искажение результатов в эксперименте участвовали мои коллеги.   

Условия проведения эксперимента

Тестировал на реальных проектах, которые я взял в качестве халтуры. Я подобрал 3 проекта разной сложности, чтобы сравнить результаты на разных уровнях. Сбором первичных бизнес-требований занимался я сам. В него входило глубинное интервью, с фиксацией ключевых моментов взаимодействия пользователей и систем и результатов, подготовка диаграммы Исикавы, подготовка списка бизнес-требований к системам, а также таблицы, сделанные по методу 5 почему, составленные по требованиям с неочевидной логикой. Таким образом каждый участник получил одинаковый набор первичных данных:

• Общие описания проектов;

• Списки бизнес-требований, сформулированные мной на основе глубинного интервью;

• Диаграммы Исикавы, структурирующие основные бизнес-требования;

• Таблицы “5 почему” для уточнения сути логически не очевидных требований.

Также для 2-х из трёх проектов потребовалось предварительно исключить  противоречивые требования, которые в основном касались адаптивности и автономности систем. Для одного была предоставлена API-документация, так как проект предусматривал широкое использование стороннего API.

Таким образом специалистам, готовящим ТЗ, были предоставлены одинаковые наборы данных, с помощью которых нужно было создать артефакты, совокупно представляющие собой ТЗ для трёх принципиально отличающихся проектов:

1. Интернет-магазин для торговли музыкальными инструментами и аксессуарами — типовой проект, где в списке требований уже были работающие референсы.

2. Сайт и система криптоэквайринга, работающая с API сторонней биржи и использующая её субаккаунты с возможностью нескольких типов вывода средств из системы (ончейн, карта, счет юрлица, наличные).

3. Доработка ПО для программно-аппаратных комплексов фотовидеофиксации нарушений ПДД. В частности, разработка OEM-решения для различных типов комплексов, дообучением нейросети для фиксации новых типов нарушений и новых типов государственных регистрационных знаков, с подготовкой патча для уже работающей системы и разработкой нового интерфейса в виде веб-приложения.

Задачи были выбраны не случайно, так как:

• первая представляет собой максимально шаблонное решение, изобилующее абсолютно стандартными требованиями;

• вторая — нетиповой проект, связанный с редко использующимся API (как выяснилось, ещё и чудовищно документированным китайскими коллегами);

• третья — предельно специфична и в ней важен учет особенностей, о которых крайне мало данных в открытых источниках, а до 2021 года было ещё меньше.

Требования к содержанию и оформление документов по каждому из проектов отличалось:

• Для интернет-магазина заказчик не предъявил требований к оформлению и содержанию, сказав, что достаточно “любого внятного ТЗ, описывающего основные функции, сущности, нефункциональные требования, стек, состав страниц сайта и логику взаимодействия с пользователем”. В итоге, его устроил следующий состав документа: общие сведения, глоссарий, features list (функциональные требования), нефункциональные требования, стек технологий, описание страниц и элементов интерфейса, описание ролей и User Story для каждой роли, логика взаимодействия пользователя с системой для нескольких функций.

• Для системы криптоэквайринга заказчик потребовал присутствия в ТЗ таких артефактов как: features list, scope, подробную SRS (software requirements specification), Process flow (в виде текста и блок-схем) для некоторых функций,  сценарные use cases, описание страниц для создания прототипа, роли пользователей и User Story для каждого типа, текстовое и схематическое описание архитектуры будущей системы, а также попросил оформить паспорт проекта с кратким общим описанием системы. 

• В ТЗ на доработку ПО для детекции нарушений ПДД должны были присутствовать те же артефакты, что и для системы криптоэквайринга, а кроме того, требовалось создать отдельную часть, оформленную в соответствии с ГОСТ 34.602-2020, где, помимо привычных разделов, необходимо было описать:

  • состав и содержание работ по созданию автоматизированной системы;

  • порядок разработки автоматизированной системы;

  • порядок контроля и приемки автоматизированной системы;

  • требования к составу и содержанию работ по подготовке объекта автоматизации к вводу автоматизированной системы в действие;

  • требования к документированию.

Для оценки эффективности и корректности формализации требований при создании ТЗ я использовал следующие критерии:

1. Время подготовки набора артефактов анализа для создания ТЗ

2. Время подготовки финального текста ТЗ, оформленного в соответствии с требованиями.

3. Количество выявленных ошибок при проверке готового ТЗ

4. Время на внесение изменений по выявленным ошибкам 

Также, время на подготовку визуальной части ТЗ: блок схем процессов, архитектуры, сценарных последовательностей, не учитывалось. Мы не использовали сторонние плагины, типа Show Me и т.п., так как скорость их работы, на мой взгляд, сопоставима со скоростью подготовки схем и диаграмм в Miro вручную.

Результаты 

Проект 1 Интернет магазин

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

Ошибки аналитика связаны с игнорированием (по невнимательности) некоторых особенностей бизнес требований: отсутствие некоторых полей для фильтров и карточек товара.

Итог: абсолютное превосходство ИИ. Полнота описаний, требований не просто сопоставима, но выше, чем при работе живого аналитика, текст артефактов и итогового ТЗ лишен избыточности, при этом хорошо понятен как разработчикам так и заказчику. Количество ошибок и дополнений незначительное, время подготовки значительно меньше. Юрий Куприянов и Виталий Волнянский были абсолютно правы: junior-аналитик становится абсолютно ненужным.

Проект 2 Сервис криптоэквайринга 

Примечание: Ошибки ИИ связаны с незнанием API и предложением гипотетически полезных, но не возможных при практической реализации решений: оффчейн транзакции, особенности реферальной системы. Также есть ошибки за счет неверного контекста, которые привели к генерации требований, не соответствующих бизнес-целям системы: завышенная пиковая нагрузка на процессинг, а также недостаточность требований к некоторым специфическим вещам, таким как безопасность рабочих нод в kubernetes, игнорирование известных уязвимостей.  

Ошибки аналитика связаны с ограниченным техническим бэкграундом и невнимательностью: недостаточность метрик в аналитике, непонимание работы оркестраторов, слабое представление о том, где имеет смысл применять микросервисную архитектуру.

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

Проект 2 ПО для детекции нарушений ПДД

Примечание: Ошибки ИИ связаны с незнанием особенностей систем, неправильным или неполным отражением бизнес-требований в контексте, а также не способностью корректно создавать документы в рамках ГОСТ (попытки лучше, чем у ChatGPT 3.5, но пока далеки от результатов человека). Наибольшее количество ошибок и дальнейших правок касалось параметров настройки машинного зрения и конфигурации, “не знания” ИИ особенностей различных камер и аппаратно-программных комплексов для фиксации нарушений ПДД и недостаточное отражение этих параметров в контексте, игнорирование некоторых запросов в контексте, высокая вариативность в подходов к созданию подобных систем. 

Ошибки аналитика связаны с ограниченным техническим бэкграундом, неполным представлением об архитектуре вырабатываемой системы и, каюсь, моими собственными недоработками в описании (которые, к слову, Chat GPT понял вполне себе верно, в отличии от живого аналитика).

Итог: значительная разница во времени в пользу аналитика, в силу меньшего количества ошибок, знания ГОСТа, хорошего представления о системе (писал ТЗ на предыдущий патч), небольшого количества ошибок.

В сухом остатке по эксперименту

Очевидно, что ИИ может заменить аналитика и дать ему фору, когда речь идёт о плюс-минут типовых проектах. Chat GPT предлагает почти безошибочные решения для поставленных бизнес-задач, подбирает лучшие практики и варианты. Как только задачи становятся менее типовыми, а решения требуют творческого подхода к формированию и формализации требований, эффективность ИИ снижается. Для получения результата требуется всё большее количество запросов, часть из которых могут истолковываться не верно. 

С ростом сложности и уникальности системы процесс подготовки артефактов анализа стремится к тому, чтобы превратиться в бесконечный. При этом крайне важен бэкграунд того, кто формирует запрос. Анализируя данные по эксперименту, я понял, что если бы на месте оператора без специальных знаний (я пригласил на эту роль тестировщика) был опытный аналитик, он ставил бы вопросы системе менее абстрактно и значительно ускорил бы подготовку документа. Вывод: ИИ, пока, в полной мере не заменяет аналитика, но является потрясающим инструментом, способным многократно ускорить его работу и увеличить её качество.

Личный опыт 

Для описания моего личного опыта использования Chat GPT хорошо подойдут статданные. До начала использования ИИ я готовил, в среднем, до 15 документов в месяц. После появления ChatGPT 3.5 turbo их количество выросло до 25, а четвертой версией превышает 40. Коллеги делятся похожими результатами. Скорость подготовки регламента для процесса уменьшилась в 4 раза, ТЗ — 2-3 раза. Рутинные задачи, которые раньше делегировались техническим писателям, теперь не требуют стороннего участия.

Краткий вывод

Пока речь не идёт о замене специалистов моего профиля, по крайней мере в вопросе специфических задач, когда требуется формировать требования к нетривиальным продуктам, системам связанным с особенностями сложных процессов, управлением промышленным оборудованием и при разработке приложений, функции которых привязаны к соблюдению законодательных норм в конкретной юрисдикции. Проблемы происходят как на уровне формализации требований в определённом виде (ГОСТы), так и на этапе генерации “осмысленных” результатов. При этом нейросети невероятно ускоряют работу живых аналитиков и улучшают качество нашей работы.