Я системный аналитик. Задаюсь, как и многие, вопросом: “Что будет с профессией системного аналитика после масштабного внедрения ИИ в процессы разработки?”

Очевидное — ИИ будет использоваться для написания требований и технических заданий для разработчиков. LLM — языковые модели. Инструмент системного аналитика — язык, точнее мышление языком. Результат, который можно потрогать,— текст. Уже есть работающие инструменты, преднастроенные агенты, которые генерят аналитические артефакты (или много текста) вместо или вместе с системным аналитиком.

Очевидно надо использовать. Во-первых оторвемся от демпингующих джунов и мидлов, мол, обезьяна с гранатой еще не спецназ. Во-вторых, среди действующих коллег, будем наравне с теми кто не побоялся продать собственное мышление железу, но выдает артефактов со скоростью N стр. / мин (где N — произвольное число, из того же множества что и заработная плата it-шников 300K / сек).

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

Но у любой волнующей человека (системного аналитика) проблемы всегда легко найти решение — простое, достижимое и ошибочное. Выше ошибочное.

Основная задача разработчика — писать код. В позитивном сценарии использования ИИ, бизнес приобретает скорость разработки, разработчик — не отставание, не понижение.

Потенциальная опасность для бизнеса — бардак в коде, для разработчика — утрата способности писать код руками (утрату здесь трактовать одновременно как “угасание”, потому что любой неиспользуемый навык засыпает, и “лишение”, потому что руками будет писать не принято). Другими словами — разработчик делегирует ИИ то, за что ему платят деньги, ничего не приобретая взамен.

В отличие от разработчиков, у системных аналитиков есть другая возможность: продолжать ставить задачи на разработку. Не “рядовым” разработчикам, а ИИ, параллельно сократив объем генерируемой документации: с микро объяснений каждого шага до условно-чистых требований. Другими словами — системный аналитик не теряет свой ключевой навык.

Исторический пример на примере описания контрактов API. Вначале была табличка. Табличку заменил Swagger (OpenAPI). Спецификация контракта легко преобразуется в код. Аналитик не пишет код, но вплотную приближается, фактически подает на вход разработки кусок кода. Ожидается, что тоже самое можно сделать не только с описанием контракта, но и кодом самих контроллеров и дальше кодом вызываемых функций.

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

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

—

Если вы системный аналитик и хотите понять как устроена программа и взаимодействие с популярными решениями (redis, rabbitMQ, …), обращайтесь.

Обучение онлайн в мини-группах.

#системныйанализ #системныйаналитик