В последнее время наблюдаю тенденцию увеличения обязанностей системного аналитика, и, кажется, в явном виде об этом никто не говорит. Наоборот, смотря профессиональные чаты и общаясь с коллегами, я в большинстве случаев считываю превалирующую мысль, что системный аналитик — это специалист, который должен и может всё: и бизнес-цели по SMART поставить, и базу данных разработать. Мне как системному аналитику видится в такой тенденции будущая проблема моей профессии: знания и достижения, которые я приобретаю сейчас, будут обнуляться на каждом новом проекте, потому что там от меня будут ожидать что-то совсем другое. В этой статье пробую разобраться почему системный анализ как подход к решению задач превратился в должность “человек-оркестр”?
Я работаю в IT почти 15 лет. В роли аналитика участвовала примерно в 7 проектах, техническим писателем - в 2 проектах, продактом - в 1 проекте. На проектах, где я работала на позиции аналитика, мне всегда приходилось совмещать несколько ролей: бизнес-аналитика, системного аналитика, дизайнера, технического писателя, тестировщика, саппорта. На других позициях мой круг задач был в основном очерчен задачами конкретной роли. Я выделила бизнес- и системного аналитика отдельно, потому что сейчас многие в явном виде разделяют эти две позиции, в том числе и профстандарты. Но лично мой опыт показывает, что на практике та часть работ по анализу, которую я провожу на старте, независимо от названия роли, требует системного анализа: выяснения проблемной ситуации, целеполагания, моделирования задачи, поиска разных решений и оценки эффективности этих решений. Поэтому говоря сейчас “Системный аналитик”, я подразумеваю “Бизнес-аналитик (в разработке требований к ПО)” и наоборот. Мне, конечно, не так важно как меня называют, сколько важно то, какие ожидания на меня накладывают, называя меня определенным образом.
Тенденции
За последний год спрос на системных и бизнес-аналитиков в России вырос. Согласно опросу, проведенному службой Хабра, динамика изменения спроса выглядит так:
В явном виде на мысли о парадоксальном расширении требований к навыкам системного аналитика меня натолкнули требованиях в вакансиях. Например, ниже текст вакансии “Ведущий/старший системный аналитик”, который выложили в публичный канал в тг для системных аналитиков.
Попробуйте посчитать сколько ролей вы тут видите? Я насчитала 6. С моей точки зрения эти требования, конечно, знакомы для специалиста в IT, но один человек тут закопается. Только чтобы перманентно выяснять потребности, разбирать процессы и формализовывать их в требуемых нотациях, нужно немало сил и рабочего времени.
Под спойлером привела еще два примера требований к системным аналитикам, чтобы показать насколько разнятся ожидания у работодателей. Взято с известного русского сайта по поиску работы на 2023 год
Еще один заметный симптом: в профильных каналах и курсах по системному анализу идет тенденция на упор в техническое проектирование API, физических баз данных, микросервисов и архитектурных решений в целом. Я не буду здесь приводить конкретные каналы и сайты, чтобы не посчитали за рекламу, но они легко находятся по словам “системный” и “анализ”. Стандартные темы таких уроков:
Какую архитектуру выбрать для проекта?
Проектирование интеграции информационных систем
Паттерны проектирования микросервисной архитектуры
Проектирование и реализация очередей в брокерах RabbitMQ и Apache Kafka
То есть, от специалиста по системному анализу сейчас ожидаются такие умения как поиск архитектурного решения, его формализация на слоях данных и сервисов, документирование решения для разработки, несение ответственности за принятое решение.
Здесь я не пытаюсь дать оценку: хорошо это или плохо. Это то, как сложились обстоятельства на рынке системных аналитиков. Ниже я агрегирую собственный опыт и кейсы из общения в комьюнити, и привожу сложившееся видение причин таких тенденций.
Почему так происходит?
Так дешевле. Вместо найма разных специалистов, можно нанять одного человека со средним уровнем знаний, который закроет собой сразу множество задач. В целом для систем невысокого уровня сложности или стартапов, или систем на поддержке это целесообразно, но является ли такой специалист системным аналитиком?
Слабо организованы процессы на проекте. Руководитель понимает, что есть проблемы, но не понимает где и почему. Ищется специалист, чтобы он не только обнаружил, но и решил эти скрытые проблемы. Специалист с названием “системный аналитик” больше всего подходит под такой запрос.
Проекты усложняются, растет сильная взаимосвязь между пользователями и информационными системами, происходит глубокое пересечение реальной и виртуальной жизни, в которой люди решают свои потребности. Появляется необходимость в кросс-функциональном специалисте, который сможет закрывать задачи взаимосвязанных прикладных областей.
Тенденция к самоорганизующимся командам, в которых для принятия самостоятельных решений нужно понимать смежные области.
Коллега, которая смотрела мою статью до публикации, сказала: “Да, это общая тенденция. Так происходит во многих сферах, особенно в стартапах, где все делают всё”. Но на мой взгляд уникальность профессии системных аналитиков глубже, чем экономия на ресурсах в стартапах. Системный анализ - это не функциональная роль как разработка, тестирование или продажи. Системный анализ - это подход к решению задач, который по сути может применять абсолютно любой человек в любой работе. Возможно именно поэтому идет попытка натянуть способность системно решать задачи на всевозможные функциональные роли.
К чему это может привести?
И на моем опыте уже приводит:
Перманентный синдром самозванца у людей на позиции системного аналитика. Тот объем знаний, который ожидают от такого специалиста, просто не может вместить в себя средний статистический человек.
Новые люди, которые приходят в профессию, не осознают, что их нагружают нерелевантной работой и уходят, не справившись с завышенными требованиями.
Специалист, который пытается делать всё: анализ, дизайн, проектирование, саппорт, интеграции - будет напоминать утку: умеет летать, плавать и ходить, но всё делает посредственно.
Если техническое решение придумывает один человек с небольшим техническим опытом, то высока вероятность большого количества багов в краткосрочном периоде и конструирование легаси - в долгосрочном.
Проседает непосредственно та часть, из-за которой и появляется потребность в аналитике в команде. Предварительный анализ задач или никто не делает, или делают по остаточному принципу, или делают специалисты, которые не владеют навыками системного анализа.
Что делать
Работая системным аналитиком, я всегда напоминаю себе следующие тезисы, когда вижу попытку наслоить мою работу на другие контексты:
Какие основополагающие задачи я пришла решать на проект как системный аналитик?
выяснять реальные потребности реальных людей;
вместе с командой разработки и пользователем искать решение проблемы;
уменьшать неопределенность в задаче;
формализовывать решение с фокусом на закрываемой потребности;
формулировать критерии проверки успешности решения;
проверять, что человек получил ожидаемый результат;
проверять как подействовало полученное решение на реальных данных.
На мой взгляд это то, что любой аналитик в разработке требований к ПО (как бы мы его не называли бизнес- или системный) должен всегда уметь делать и может по желанию ограничить свой круг деятельности только этими задачами.
Находить проблемы за счёт применения инструментов системного анализа и решать эти проблемы - разные навыки. Я как аналитик могу предложить свое или поревьюить существующее техническое решение в силу большого опыта работы. Могу подсветить плюсы и минусы, но не буду принимать окончательное решение. Согласование технического решения делает релевантный специалист с соответствующими навыками и он же несёт за него ответственность.
Если я готова изменить свой круг обязанностей, то говорю, что я как системный аналитик беру на себя другую роль - роль архитектора (разработчика, техлида, инженера по интеграциям), плюс ответственность за разработку технических решений (а также зарплату соответствующей роли). А еще снимаю с себя риски за непроведённый анализ задачи. То есть, в явном виде подсвечиваю наложение новых обязанностей: не “системный аналитик разрабатывает API”, а “системный аналитик взял на себя роль разработчика и разрабатывает API”.
Поделитесь в комментариях своим опытом, наблюдаются ли у вас такие тенденции? Устанавливаете ли вы границы своих рабочих обязанностей? Если да, то как вы определяете границу, за которую дальше идти нецелесообразно?
Резюме
Тенденция на кросс-функциональность навыков в IT понятна и на мой взгляд будет только прогрессировать. Чтобы качественно делать сегодняшние и завтрашние задачи нам нужно получать новые знания, в том числе и из смежных областей. Но давайте обозначать за какие области мы готовы и способны отвечать в первую очередь, а какие нам вторично наслаивает контекст. Вместо того, чтобы из одного специалиста делать “человек-оркестр”, можно создать тенденцию всеобщего обучения системному подходу для решения задач. А системный аналитик - это не затычка под каждую дыру на проекте, но это специалист, который хочет и может системно посмотреть на задачу, уменьшить неопределенность и поддержать процесс создания ценности.
