[Анализ и проектирование систем, Управление персоналом, Карьера в IT-индустрии, Лайфхаки для гиков] Должен ли системный аналитик вторгаться на чужую территорию?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 2 месяца
Сообщений: 27286
На Хабре много статей о том, кто такой системный аналитик. С базовым определением профессии все понятно. Но я хочу поговорить о разграничении полномочий в командах с разным набором ролей. В зависимости от ситуации границы обязанностей системного аналитика размываются, требуя дополнительных знаний. Хочу поделиться своими наблюдениями о том, какие из этих знаний делают аналитика более востребованным на рынке труда.
Конкретные обязанности и рабочие процессы, в которых участвует системный аналитик, существенно зависят от внутреннего устройства компании. В качестве точки отсчета предлагаю взять мою текущую роль в команде.В Maxilect системный аналитик в первую очередь концентрируется на технических задачах. Он немного понимает программный код, может самостоятельно писать базовые SQL запросы, осознает и применяет различные принципы построения архитектуры приложений, а также их взаимодействия. Умеет работать и проектировать веб сервисы и очереди (MQ). Но бизнес анализом ему заниматься не приходится. Команда получает от бизнеса задачи, которые отвечают на вопрос: “Что нужно сделать”. А системный аналитик решает “Как команда это реализует”. Детально прорабатывая задачу, системный аналитик может обсудить промежуточный вариант с разработчиком или обсудить что-то с архитектором. Но именно он решает, какие веб-сервисы будем вызывать, как обрабатывать полученные данные и какие для этого нужны доработки. Организует обсуждение со сторонними командами, если требуется. Фактически, здесь роль системного аналитика близка к канонической. Но Maxilect - далеко не первое место моей работы. За весь свой трудовой путь я видела разные реализации этой роли. Видела компании, которые в целях экономии пытаются повесить функцию системного анализа на разработчиков. Но лично я придерживаюсь принципа, что каждый должен заниматься своим делом. Разработчику лучше сосредоточиться на коде, в то время как понимание требований обеспечит аналитик.В реальных командах функции системного аналитика размываются. Их тем больше, чем меньше проект и компания. Аналитик может и обучать, и тестировать, и проводить демо, и даже в командировки на внедрения летать (если это предполагает характер разрабатываемого продукта), вторгаясь таким образом на территорию смежных специалистов.Дисклаймер о джунах, мидлах и сениорахКонечно, масштабы воздействия на проект зависят от уровня подготовки самого аналитика. Джуну с его базовым пониманием теории сбора требований и бизнес-процессов вряд ли кто-то доверит в одиночку закрыть две-три роли. Ему бы погрузиться в принципы работы системы, да инструменты освоить от Word до UML или какого-нибудь Balsamiq.После пары лет работы, первых столкновений с микросервисами, REST, SOAP и т.п. специалист превратится в мидла, который сможет решать задачи самостоятельно. И начиная с этого момента он сможет осваивать смежные роли, продолжая углубляться в детали своей профессии. Уровня сениора с его многолетним опытом, базовыми навыками архитектора, пониманием интеграционных сервисов или умением пилить монолиты, а также опытом руководства командой, он скорее всего достигнет уже совмещая несколько направлений.Не исключено, что именно совмещение и дает этот толчок в развитии. Но разделение на уровни настолько условно, что дальше я не буду акцентировать внимание на том, как смежные роли с ним связаны.Поговорим о том, какие направления аналитику открываются чаще.Аналитик и бизнесПо моим наблюдениям чаще всего системному аналитику приходится закрывать функции бизнес-аналитика.И системный, и бизнес аналитик - это звенья цепочки между заказчиком и разработчиком. Первый - немного в сторону технической части, второй - в сторону бизнеса. Грань между ними очень тонкая, поэтому роли часто путают. А в небольших проектах эти роли обычно закрывает один человек. Если мы не говорим о масштабном проекте, то одной головы вполне достаточно, чтобы разобраться в бизнес-процессах и держать в уме архитектуру системы - знать, что где лежит и какие именно нужно внести изменения, чтобы реализовать новые требования.Я обратила внимание, что из этих двух ролей в вакансиях компании чаще пишут “системный аналитик”, предлагая совмещения в текстовом описании позиции или между строк. Мне кажется, бизнес-аналитик - это более редкий узкий специалист, которого не каждая компания может и хочет себе позволить. Так что, закрывая обе роли, ты становишься более универсальным специалистом, которому легче найти работу.Но отсутствие бизнес-аналитика на проекте не всегда гарантирует, что нужно будет совмещать. It - сфера динамично развивается и в ней появляются новые смежные профессии. Еще 3-4 года не многие слышали про роль product owner, а сейчас роль владельца продукта все более востребована. И я уже ни раз сталкивалась с командами, где именно PO определяет, какие бизнес-задачи войдут в скоуп спринта, а какие нет. В каком-то смысле, помимо выполнения своих основных функций, product owner встраивается в цепочку разработки вместо бизнес-аналитика, взаимодействуя и с заказчиком, и с системным аналитиком.Нужно ли тестировать?Системный аналитик должен хорошо разбираться в системе и ее функциях. Поскольку он ориентируется в требованиях заказчика, я все чаще вижу, что аналитиков подключают к тестированию. Я и сама на текущем проекте тестирую отдельные модули системы. Тестировщики же фокусируются на более объемных частях задачи.С запросом на тестирование силами системных аналитиков я сталкивалась еще пару лет назад. Но тогда я не встречала таких пунктов в описаниях вакансий. Сейчас на кадровых порталах уже открыто пишут, что системный аналитик, претендующий на вакансию, должен писать тест-кейсы и сам их проверять.Системный аналитик vs архитекторСистемный аналитик не является архитектором, но часто ему приходится закрывать эту роль хотя бы частично, хотя на мой взгляд это неправильно.Архитектор - важный и нужный специалист, но обычно его ищут на большие проекты, где недостатки архитектуры могут в буквальном смысле похоронить хорошее решение. Если архитектор на проекте присутствует, системному аналитику приходится тесно с ним взаимодействовать, особенно в период онбординга.Когда проект обходится без архитектора, его функции делятся между другими участниками команды, например техлидом, product owner, а иногда и самим системным аналитиком (такую схему работы “на троих” я встречала на одном из бывших проектов). Это нельзя назвать обычной или правильной практикой. Но так или иначе системному аналитику все равно придется разбираться в архитектуре, понимать, какая технология и за что отвечает. Необходимость изучить архитектуру проекта тянет за собой много требований. Надо уметь работать с интеграционными сервисами - понимать, что куда передать, чтобы совместить две системы, что такое интеграционная шина и как она работает. Надо понимать, как из одной системы в другую дойдет сообщение, и что при этом произойдет, а значит требуется знать, как работают очереди (RabbitMQ, Kafka). Необходима работа с базами данных.Системному аналитику не обязательно уметь проектировать все это, но надо следить за технологиями, понимать, зачем и в каких ситуациях они применяются.Выйдет ли из аналитика лид?Стоит следить и за трендами в управлении. Аналитиков часто ставят на роль лидов - дескать, они хорошо понимают в проекте, умеют общаться с бизнесом. На мой взгляд, это не всегда оправданный шаг. Руководство - это в большей степени менеджерская работа, которая отнимает много времени. Это в первую очередь распределение задач, полученных сверху, между мидлами и джунами в своей команде. Мне кажется, эту работу проще возложить на руководителя проекта или product owner - мне так работать привычнее. А сильный аналитик может сосредоточиться непосредственно на своей работе. Но для некоторых переход из системного аналитика в лиды - это хороший шаг в карьере, к которому лучше готовиться заранее, изучая особенности работы команд, различия в подходах к разработке (это уже про Agile, Scrum, Kanban).Вместо заключения отмечу, что роль системного аналитика для проекта крайне важна. Но для нее нельзя написать список необходимых и достаточных навыков. В этой сфере знания никогда не бывают лишними. Может пригодиться и опыт кодинга, и умение писать запросы в БД, и общие представления о сфере, в которой разрабатывается проект. Все это делает системного аналитика более востребованным на рынке труда.Автор статьи: Лейла Кадырова, Максилект.P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы вVK,FB,Instagram илиTelegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.
===========
Источник:
habr.com
===========
Похожие новости:
- [Законодательство в IT, Карьера в IT-индустрии, IT-компании, Удалённая работа] Удаленка по новым правилам: 13 вопросов и ответов
- [Python, Обработка изображений, Машинное обучение, Лайфхаки для гиков] Как удалить татуировку с помощью глубокого обучения (перевод)
- [Git, Хранение данных, Лайфхаки для гиков] Знакомьтесь, pass (перевод)
- [Карьера в IT-индустрии, Лайфхаки для гиков, Удалённая работа] Как найти удаленную работу в зарубежной компании. 10 шагов
- [C++, Реверс-инжиниринг, Игры и игровые приставки, Лайфхаки для гиков] Как в Runescape ловят пользователей ботов, и почему они не поймали меня (перевод)
- [Учебный процесс в IT, Карьера в IT-индустрии] О стажировках для тех, кто еще не :) Эпизод 2
- [Управление персоналом] Вопросы, которые вам следует задать рекрутеру, чтобы успешно пройти телефонное собеседование (перевод)
- [Анализ и проектирование систем, Управление продуктом] 4 вида аналитики, в которых нужно разбираться продуктовой команде
- [Анализ и проектирование систем, Распределённые системы] Стабильная нестабильность — оксиморон или необходимость?
- [Управление персоналом] Как я перестал превращать собес в экзамен: оцениваем хард- и софт-скиллы за одно собеседование
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_upravlenie_personalom (Управление персоналом), #_karera_v_itindustrii (Карьера в IT-индустрии), #_lajfhaki_dlja_gikov (Лайфхаки для гиков), #_sistemnyj_analitik (системный аналитик), #_biznesanalitika (бизнес-аналитика), #_biznesanalitik (бизнес-аналитик), #_blog_kompanii_maxilect (
Блог компании Maxilect
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_upravlenie_personalom (
Управление персоналом
), #_karera_v_itindustrii (
Карьера в IT-индустрии
), #_lajfhaki_dlja_gikov (
Лайфхаки для гиков
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Апр 10:25
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 2 месяца |
|
|
На Хабре много статей о том, кто такой системный аналитик. С базовым определением профессии все понятно. Но я хочу поговорить о разграничении полномочий в командах с разным набором ролей. В зависимости от ситуации границы обязанностей системного аналитика размываются, требуя дополнительных знаний. Хочу поделиться своими наблюдениями о том, какие из этих знаний делают аналитика более востребованным на рынке труда.  Конкретные обязанности и рабочие процессы, в которых участвует системный аналитик, существенно зависят от внутреннего устройства компании. В качестве точки отсчета предлагаю взять мою текущую роль в команде.В Maxilect системный аналитик в первую очередь концентрируется на технических задачах. Он немного понимает программный код, может самостоятельно писать базовые SQL запросы, осознает и применяет различные принципы построения архитектуры приложений, а также их взаимодействия. Умеет работать и проектировать веб сервисы и очереди (MQ). Но бизнес анализом ему заниматься не приходится. Команда получает от бизнеса задачи, которые отвечают на вопрос: “Что нужно сделать”. А системный аналитик решает “Как команда это реализует”. Детально прорабатывая задачу, системный аналитик может обсудить промежуточный вариант с разработчиком или обсудить что-то с архитектором. Но именно он решает, какие веб-сервисы будем вызывать, как обрабатывать полученные данные и какие для этого нужны доработки. Организует обсуждение со сторонними командами, если требуется. Фактически, здесь роль системного аналитика близка к канонической. Но Maxilect - далеко не первое место моей работы. За весь свой трудовой путь я видела разные реализации этой роли. Видела компании, которые в целях экономии пытаются повесить функцию системного анализа на разработчиков. Но лично я придерживаюсь принципа, что каждый должен заниматься своим делом. Разработчику лучше сосредоточиться на коде, в то время как понимание требований обеспечит аналитик.В реальных командах функции системного аналитика размываются. Их тем больше, чем меньше проект и компания. Аналитик может и обучать, и тестировать, и проводить демо, и даже в командировки на внедрения летать (если это предполагает характер разрабатываемого продукта), вторгаясь таким образом на территорию смежных специалистов.Дисклаймер о джунах, мидлах и сениорахКонечно, масштабы воздействия на проект зависят от уровня подготовки самого аналитика. Джуну с его базовым пониманием теории сбора требований и бизнес-процессов вряд ли кто-то доверит в одиночку закрыть две-три роли. Ему бы погрузиться в принципы работы системы, да инструменты освоить от Word до UML или какого-нибудь Balsamiq.После пары лет работы, первых столкновений с микросервисами, REST, SOAP и т.п. специалист превратится в мидла, который сможет решать задачи самостоятельно. И начиная с этого момента он сможет осваивать смежные роли, продолжая углубляться в детали своей профессии. Уровня сениора с его многолетним опытом, базовыми навыками архитектора, пониманием интеграционных сервисов или умением пилить монолиты, а также опытом руководства командой, он скорее всего достигнет уже совмещая несколько направлений.Не исключено, что именно совмещение и дает этот толчок в развитии. Но разделение на уровни настолько условно, что дальше я не буду акцентировать внимание на том, как смежные роли с ним связаны.Поговорим о том, какие направления аналитику открываются чаще.Аналитик и бизнесПо моим наблюдениям чаще всего системному аналитику приходится закрывать функции бизнес-аналитика.И системный, и бизнес аналитик - это звенья цепочки между заказчиком и разработчиком. Первый - немного в сторону технической части, второй - в сторону бизнеса. Грань между ними очень тонкая, поэтому роли часто путают. А в небольших проектах эти роли обычно закрывает один человек. Если мы не говорим о масштабном проекте, то одной головы вполне достаточно, чтобы разобраться в бизнес-процессах и держать в уме архитектуру системы - знать, что где лежит и какие именно нужно внести изменения, чтобы реализовать новые требования.Я обратила внимание, что из этих двух ролей в вакансиях компании чаще пишут “системный аналитик”, предлагая совмещения в текстовом описании позиции или между строк. Мне кажется, бизнес-аналитик - это более редкий узкий специалист, которого не каждая компания может и хочет себе позволить. Так что, закрывая обе роли, ты становишься более универсальным специалистом, которому легче найти работу.Но отсутствие бизнес-аналитика на проекте не всегда гарантирует, что нужно будет совмещать. It - сфера динамично развивается и в ней появляются новые смежные профессии. Еще 3-4 года не многие слышали про роль product owner, а сейчас роль владельца продукта все более востребована. И я уже ни раз сталкивалась с командами, где именно PO определяет, какие бизнес-задачи войдут в скоуп спринта, а какие нет. В каком-то смысле, помимо выполнения своих основных функций, product owner встраивается в цепочку разработки вместо бизнес-аналитика, взаимодействуя и с заказчиком, и с системным аналитиком.Нужно ли тестировать?Системный аналитик должен хорошо разбираться в системе и ее функциях. Поскольку он ориентируется в требованиях заказчика, я все чаще вижу, что аналитиков подключают к тестированию. Я и сама на текущем проекте тестирую отдельные модули системы. Тестировщики же фокусируются на более объемных частях задачи.С запросом на тестирование силами системных аналитиков я сталкивалась еще пару лет назад. Но тогда я не встречала таких пунктов в описаниях вакансий. Сейчас на кадровых порталах уже открыто пишут, что системный аналитик, претендующий на вакансию, должен писать тест-кейсы и сам их проверять.Системный аналитик vs архитекторСистемный аналитик не является архитектором, но часто ему приходится закрывать эту роль хотя бы частично, хотя на мой взгляд это неправильно.Архитектор - важный и нужный специалист, но обычно его ищут на большие проекты, где недостатки архитектуры могут в буквальном смысле похоронить хорошее решение. Если архитектор на проекте присутствует, системному аналитику приходится тесно с ним взаимодействовать, особенно в период онбординга.Когда проект обходится без архитектора, его функции делятся между другими участниками команды, например техлидом, product owner, а иногда и самим системным аналитиком (такую схему работы “на троих” я встречала на одном из бывших проектов). Это нельзя назвать обычной или правильной практикой. Но так или иначе системному аналитику все равно придется разбираться в архитектуре, понимать, какая технология и за что отвечает. Необходимость изучить архитектуру проекта тянет за собой много требований. Надо уметь работать с интеграционными сервисами - понимать, что куда передать, чтобы совместить две системы, что такое интеграционная шина и как она работает. Надо понимать, как из одной системы в другую дойдет сообщение, и что при этом произойдет, а значит требуется знать, как работают очереди (RabbitMQ, Kafka). Необходима работа с базами данных.Системному аналитику не обязательно уметь проектировать все это, но надо следить за технологиями, понимать, зачем и в каких ситуациях они применяются.Выйдет ли из аналитика лид?Стоит следить и за трендами в управлении. Аналитиков часто ставят на роль лидов - дескать, они хорошо понимают в проекте, умеют общаться с бизнесом. На мой взгляд, это не всегда оправданный шаг. Руководство - это в большей степени менеджерская работа, которая отнимает много времени. Это в первую очередь распределение задач, полученных сверху, между мидлами и джунами в своей команде. Мне кажется, эту работу проще возложить на руководителя проекта или product owner - мне так работать привычнее. А сильный аналитик может сосредоточиться непосредственно на своей работе. Но для некоторых переход из системного аналитика в лиды - это хороший шаг в карьере, к которому лучше готовиться заранее, изучая особенности работы команд, различия в подходах к разработке (это уже про Agile, Scrum, Kanban).Вместо заключения отмечу, что роль системного аналитика для проекта крайне важна. Но для нее нельзя написать список необходимых и достаточных навыков. В этой сфере знания никогда не бывают лишними. Может пригодиться и опыт кодинга, и умение писать запросы в БД, и общие представления о сфере, в которой разрабатывается проект. Все это делает системного аналитика более востребованным на рынке труда.Автор статьи: Лейла Кадырова, Максилект.P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы вVK,FB,Instagram илиTelegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect. =========== Источник: habr.com =========== Похожие новости:
Блог компании Maxilect ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ), #_upravlenie_personalom ( Управление персоналом ), #_karera_v_itindustrii ( Карьера в IT-индустрии ), #_lajfhaki_dlja_gikov ( Лайфхаки для гиков ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Апр 10:25
Часовой пояс: UTC + 5