Данная иллюстрация была создана с помощью нейросети DALL-E 3. В настоящее время широко обсуждаются прогнозы о возможности замены системных аналитиков искусственным интеллектом. Так, ИТ-архитектор и тренер школы системного анализа Юрий Куприянов еще год назад отмечал риск сокращения специалистов начального уровня ввиду их потенциальной замещения нейросетями. Схожие выводы озвучивал Виталий Волнянский в своих публикациях о развитии технологий ИИ. Тем не менее, с момента выхода ChatGPT до настоящего времени массовых увольнений сотрудников в сфере системного анализа зафиксировано не было. Более того, среди известных мне системных интеграторов и компаний-разработчиков сложного программного обеспечения для промышленности, крупного ритейла и систем безопасности (включая решения на базе компьютерного зрения) также отсутствуют случаи масштабного сокращения специалистов данного профиля.

Более того, только на Хабр Карьера в настоящий момент 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 раза. Рутинные задачи, которые раньше делегировались техническим писателям, теперь не требуют стороннего участия.

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

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

Автор: @smirnov_dm
Источник: https://habr.com/