Комментарии 38
Ну я на прошлой работе был СА, но по факту фулстеком СА+БА, и у нас не было техписов, потому доку вели по большей части сами, но тестеры был. Помощь саппортам - это по сути 3-я линия поддержки, в целом норм
На нынешнем месте я СА и тут в команде платформы и инфраструктуры, так что бизнес-анализом особо заниматься не приходиться, так что я бы сказал, что я прям трушный СА))
Коллеги из команд, относящихся к бизнесу - по сути фулстеки и они совмещают роли СА с БА, но с уклоном в СА всё-таки
По-моему, когда всё в одном - это скорее из-за специфики бизнеса, ну или нежелания работодателя расширять штат
На самом первом месте работы я занималась выездами в поля к заказчику, настройкой коробочного продукта и ответами на вопросы пользователей. Должность эта у нас тогда называлась "консультант". Все из-за этого очень возмущались и требовали переименования в бизнес-аналитиков. Вот теперь я думаю, а может и правда все правильно называлось...)
Ну это сомнительно как-то?♂️
Моё первое место в IT было в 2020-2021 годах (IT - не первая моя карьера) - проджект-менеджер в Веб-студии, там я реально много чего делал, включая системный анализ, но такие места хороши для того, чтоб набрать скилов и понять какое направление IT - тебе интересно, чтоб двигаться в его сторону ?
Вместо найма разных специалистов, можно нанять одного человека со средним уровнем знаний, который закроет собой сразу множество задач.
Еще такой кейс - у них раньше был человек, которые все это делал за одну зарплату, пока наконец не понял, что можно делать меньше, а получать больше. Договориться с руководством о повышении зп не удалось и он ушел.
А теперь руководство пока еще не поняло, что такие спецы не часто встречаются и ищет ему замену. Через полгода-год возьмет троих, иначе не получается закрыть все задачи.
Меня настораживает, что сами аналитики, которые говорят на большую аудиторию, поддерживают тезис "Аналитик - это и швец, и жнец, и на дуде игрец". Я уверена, что это действительно скилловые ребята, но у меня есть гипотеза, что они "выжившие" среди большого количества тех, кто не смог или не захотел в этом участвовать
"[любая роль]: в каждой бочке затычка" (с)
В моем представлении, возможно очень субъективном и ошибочном, системный аналитик - это естественное развитие из роли архитектора. То есть это в первую очередь опытный программист, который со временем все меньше пишет код и больше думает о проекте в целом, о процессах, видит всякую фигню и нестыковки, и анализирует то, как все это интегрируется с оффлайновым миром. Эдакий "смотрящий за проектом". Поэтому требования о понимании технической стороны, как разработка происходит - это естественным образом полученный прошлый опыт. Сбор информации о происходящих процессах и синхронизация участников - это текущие обязанности. Умение видеть отклонения в строгих системах - это обязательное личное качество. Собственно и для роли архитектора оно лишним не будет. А третья линия поддержки - это экстренные ситуации, когда люди не знают, как что-то работает за пределами их кабинета, но у нас есть смотрящий, который сверху видит все и может направить в нужную сторону. С такой стороны требования не выглядят прямо страшными. То же самое можно сказать про более близкую мне специальность WebGL-разработчиков-математиков. Там требования порой - закачаешься, но если подумать про суть, откуда эта роль берется - вроде как все выглядит логично. Попадая на эту роль естественным путем ты просто не можешь не иметь навыков, которые там ожидаются. Просто и там, и тут, предполагается, что нужет человек с предыдущим опытом в чем-то. В этих областях не может быть зеленых стажеров.
Я сейчас поняла, что на своей практике вижу движение только в одну сторону: из бизнес-аналитиков в системные, из системных в архитекторы.
Действительно могут быть кейсы, когда нужен специалист с комбинацией сильных компетенций в разных областях. За обретением таких компетенций полагаю стоит серьезный релевантный бекграунд работы и обучения. И эксперт, который в итоге получится, будет очень специализированным, очень дорогим и в какой-то степени уникальным.
Что-то мне тоже не попадались системные аналитики родом из архитекторов. Из тестировщиков были, из техписов тоже были достойные, иногда из разработчиков встречаются. А чаще всего встречаются такие, что родились уже аналитиками и из программирования знают только слово "асинхронный", но не могут отличить хэш от base64.
Минутку, наоборот, это архитектор может в прошлом быть системным аналитиком. (И в большом количестве случаев так и бывает).
Чтобы архитектор пошел в СА - это даунгрейд, да и по предлагаемым зп это хорошо видно.
А вы описали скорее архитектора, как по мне. СА это "вот задача, нужно описать контракт" или "вот бизнес-процесс, нужно построить sequence-диаграмму". Ну, в компаниях где принято разделять труд, а не вешать все на одного)
Так вот почему у нас все жалуются, что продукты технически становятся хуже - в архитекторы вырастают не инженеры-программисты, а люди, рисующие диаграммы! Я тут, конечно, иронизирую, но в этом действительно что-то не так. Роли смешиваются, не говоря уже про порядок получения навыков, и получается что-то странное. С одной стороны становится сложно провести грань, кто в среде аналитиков от мира бизнеса, а кто от мира технологий, а с другой стороны как-то так выходит, что на одну из верхних позиций в технической карьере, которая по идее должна быть выше синьеров-помидоров, можно попасть в обход собственно технической части. Кажется, что тут настолько термины перемешались, что дальше уже некуда перемешивать. Не удивительно, что в вакансиях такое взаимное непонимание происходит.
Чисто теоретически, это как раз следствие той проблемы, о которой говорит ТС. Бизнес-аналитики - это те самый, которые "от мира бизнеса". Человек, знающий бизнес-процессы в текущей фирме, с хорошим опытом и насмотренностью таких же процессов в других фирмах. Тот, кто знает Best practice и может описать новый процесс и выявить недостатки существующих. А вот на основании анализа БА уже архитектор должен принять решение об используемых технологиях и отдать задачи по написанию спецификаций другим профильным специалистам. Уж точно не БА и не СА должен расписывать структуру json'а.
Проблема возникает тогда, когда бизнес в стремлении оптимизировать расходы (ну как же, БА напсал и сидит сложа руки, а задач нет) отправляет аналитиков в помощь тестировщикам/тех.писателям/поддержке. К этому быстро привыкают и потом пытаются закрыть должность новым человеком, которому в требования уже пишут "Тестирование/приёмка/написание интерфейсов" Порочный круг!
Тут просто намешано. Стоит различать несколько вертикалей.
Со стороны ИТ:
Из системного аналитика можно вырасти в функционального архитектора.
Из разработчика в технического архитектора.
Со стороны бизнеса:
Консультант - Бизнес-аналитик
И тогда всё логично вырисовывается.
Я понял. Меня смутило то, что я считал, что чтобы быть хорошим системным аналитиком нужно для начала быть как минимум средненьким техническим архитектором и понимать, как твоя система собственно работает. У меня первые две вертикали слились в одну большую. Но видимо под системным аналитиком принято считать немного другое.
Работала СА в одной компании. Ко мне могли зайти с запросом: А можешь в jenkins настроить автоматическую проверку орфографии всей документации проекта или сделать бэкап базы...? Я всегда говорила "Конечно! Я же специалист! Я всё могу! " и уходила разбираться, хотя этот опыт мне вообще никуда.
Я долгое время бралась за все, что скажут. Во-первых, было ощущение "ну надо делать раз больше некому", а во-вторых, синдром отличника. Вообще благодаря этому узнала про SQL, протоколы, базы данных, логи и др. Эти знания сейчас помогают лучше понимать процесс разработки, но специалистом по базам данных я себя по-прежнему не считаю
В целом всё верно. Так оно и есть. Ощущаю всё это на себе каждый день.
Я работаю аналитиком больше 8 лет и рассматриваю свою роль как некий гибрид, цель которой упростить жизнь команде разработки и максимально ускорить доставку функционала до прода. А следовательно я на себя беру большо функций. Как мне кажется, это совершенно нормально. Плюс я не верю, что в продуктовой команде аналитик может быть только бизнес или только системным, в любом случае это совмещение ролей. Так как я не могу нормально писать функциональные требования, не понимаю бизнес и тд...
Я тоже считаю, что главная моя задача как аналитика помогать команде быстрее разбираться с задачами. Поэтому я много общаюсь с ними голосом, подсвечиваю риски, визуализирую во время встреч наши договоренности, использую нотации с легким уровнем вхождения, стараюсь не перегружать сценарии логикой и другое, что могу облегчить как аналитик. Чего я не делаю: не захожу в зону ответственности другого специалиста, понимая что там он справится сильно лучше меня. А если такого специалиста нет, то капаю на голову продакту, что нам нужен такой специалист)
Ну иногда можно залезть "на чужую" территорию. По крайней мере, я так делаю, если хочу что-то новое и не обычное сделать. И это ускорит команду.
На одном из проектов у нас долго не было дизайнера. Кому-то нужно было закрывать эти задачи и я взяла их на себя. Рисовала в пейнте макеты. Это было интересно и странно. Я четко понимала, что мне сильно не хватает знаний по UX и мои макеты, мягко говоря, слабые. Например, одним из моих гениальных решений было использовать в качестве иконки обратной связи - эмодзи. А потом у нас появился нормальный дизайнер. Поэтому я тоже хожу "на чужую" территорию, просто чувствую себя импостером в этот момент)
Да все из-за кадровых проблем. Всегда все из-за них. А кадровые проблемы бывают двух типов: кадров мало и кадры фигня. Причем одно другому не мешает.
1) Кадров мало. Часто некому в принципе хоть как-то формализовать все приобретенные компетенции по продукту и каждая новая фича бьет этим по лбу. На моей опыте все эти шесть "ролей" часто ложатся на плечи разраба, то есть меня. Дальше - или с коллегами повезло и они обучаемые, или "ну ее нафиг работу твою", потому что проблемы будут расти до состояния "невывозимо".
2) Кадры фигня. То есть никто не хочет в кросс-функциональность эту вашу: на выходе дизайнера картинка без описания сценариев, на вход у разраба принимается только детализированная задача и никакого аналитического выхода он не дает, на выходе у ПО (на которого навесили функции и СА и БА и ПМ и фонарь на лоб повесили, чтобы он еще на трех проектах по ночам светил) невразумительная двухстрочная лабуда вместо постановки задачи по случайному адресу. Если с наймом в этом варианте проблем нет - такая команда будет пожирать самого ответственного из нанятых ей в "усиление", любого СА и БА или даже разраба который не только задачки в жире умеет двигать, а еще и головой подумать когда надо.
Я вот всячески всегда и всем советую не парить себе голову формализмами, а искать людей с которыми работать приятно. Что по ту что по эту сторону переговорного стола на собесе. Но это и у меня не всегда получается что по ту что по эту ¯\_(ツ)_/¯
Очень часто действует правило: в любой непонятной ситуации зови системного аналитика. Не уверен, хорош ли дизайн -- зовём СА, не уверен, что бизнес-аналитик понимает бизнес -- зовём СА, архитектор сильно занят, а делать и согласовать архитектуру обязательно для релиза -- зовём СА. Главное -- всегда произносить слова: "Это технический вопрос", даже если это и не так)))
Практически на всех проектах совмещала роль бизнес-аналитика и системного аналитика. На самом деле, встречала только одну организацию , где эти роли были организационно разделены вплоть до разных должностных инструкций и отделов.
Перечень требований в приведенной вакансии вообще не вызвал бы удивления.
Что касается всех остальных вспомогательных ролей, дело мне кажется, не только в навыке системного анализа, который везде применим, но и в том, что аналитик - сосредоточение всех коммуникаций в команде и еще ходячая база знаний проекта с быстрым доступом.
Если представить, что на все эти роли будут разные люди, то будут большие временные (и не только) затраты на коммуникацию, смысловые потери. Иногда проще увеличить команду аналитиков и разделить области функционально, чем делить по виду деятельности.
То, что на каждом новом проекте требуются новые навыки, даже нравится.Это ведь не только у аналитиков так, хотя аналитиков возможно чаще кидают между совсем разными проектами. Мобильная разработка, Internet of things, DataWarehouse? Разберемся. Навыки не обнуляются, а накапливаются, имхо.
Тут главное не схватить "фактор автобуса", если аналитик берет на себя большую часть задач. Полагаю везде нужна золотая середина.
Работаю системным аналитиком, и полностью согласна. Периодически читаю телеграм-каналы и просматриваю вакансии, после чего ловлю жесткий синдром самозванца
Поддерживаю мнение. Когда искала работу системным аналитиком, записывала к себе все ожидания после каждого собеседования и создавала конспект по теме. В итоге на каждом новом собеседовании появлялась какая-то новая область, в которой я просто не разбираюсь. Так же вроде меня сейчас взяли на системный анализ перехода на микросервис, а в итоге я пишу требования к доработке crm написанной на php. То есть вообще другая область разбора информации. Это, конечно, интересно и расширяет область знания, но все таки хочется чего-то более определенного
Большой спектр требований и обязанностей в вакансиях аналитика присутствовал почти всегда, т.е. по моим наблюдениям - например, умение общаться с закачиком и описывать структуру БД, или составлять макеты интерфейса пользователя и участвовать в приёмке-передаче системы - такие пункты можно было увидеть ещё в начале 2010-х.
Но это не тренд!
В российском айти основная тенденция последних лет сводится к тому, что акцент в работе системного-аналитика смещается от выявления требований к проектированию решений. Собственно, новая версия профстандарта это и отражает. Некоторые из его авторов про это рассказывали на различных площадках.
А поскольку вы, судя по тексту в начале статьи, смотрите на работу аналитика прежде всего с точки зрения модели компетенции BABoK, то и "новые" реалии рынка труда сбивают вас с толку. И, кстати, системный анализ как научный метод или даже дисциплина не является основой знаний исключительно аналитика - по-хорошему этим должен владеть любой ИТ-инженер.
Системный аналитик: каждой бочке затычка