Проблема У некоторых моих друзей, коллег, менеджеров, HR и представителей «бизнеса» в голове путаница между типами аналитиков.
Термин «аналитик» используется для профессий, совершенно отличающихся друг от друга — бизнес-аналитик (BA), системный аналитик (SA), аналитик данных, UX-аналитик, аналитик информационной безопасности, аналитик бизнес-процессов и еще 5-10, все эти типы имеют много различий.
Теперь о двух конкретных, наиболее запутанных между собой, но сильно отличающихся в отечественных ИТ-реалиях.
Кому будет полезна эта статья:
Кому | Как |
Аналитик и его коллеги | Аналитику необходимо самоидентифицироваться, чтобы правильно распределять усилия в обучении и развитии, поиске работы исходя из интересов и видения будущего.
Коллегам необходимо понимать, что является прямой обязанностью, а что — непосильной нагрузкой для аналитика. Пример: БА обязан предоставить описания xml-схемы сервиса, а СА – дотошное знание нормативной документации предметной области.
|
HR | Кандидатов легче фильтровать на первом и последующих этапах рекрутинга, а также получать более релевантные ответы, правильно описывая вакансии.
Повысьте удовлетворенность сотрудников работой «там, где им нужно быть». Пример: вакансии БА со знанием Java, проведением большого объёма презентаций и продаж для СА.
|
В голову | Целенаправленный отбор и распределение ресурсов, готовых выполнять конкретную комбинацию рабочих обязанностей, улучшение коммуникации в коллективе.
Пример: «Технарь» выбран на должность, требующую максимальной коммуникативности и гибкости, без желания развивать такие навыки.
|
Предположения
В этой статье больше говорится об ИТ-секторе.Рассмотрен «дистиллированный» смысл позиций.
В реальной жизни, особенно в командах, где развиваются Т-образные навыки (модель развития компетенций сотрудников смежных профессий), все сложнее и запутаннее, но если ваш аналитик не многогранный Янус, то переход между разными обязанностями — задача непростая.
Главная часть
Общаясь с BA и SA из компаний и проектов разного масштаба, я видел разлад в концепциях, порождающий споры.Как это обычно бывает, отсутствие общепринятой терминологии препятствует распределению задач и ответственности в проекте между теми, кто способен выполнить их с наибольшей эффективностью.
Чтобы в этих спорах обратиться к объективному источнику, я решил поискать мнения в Интернете.
Делюсь результатами своих поисков.
Бизнес-анализ и системный анализ в ИТ — это совокупность практик, методов и задач.
, которые упрощают разработку информационных систем, необходимых для решения бизнес-целей организаций.
Путаница между этими двумя понятиями существует не только в бытовой среде, а именно: https://en.wikipedia.org/wiki/Systems_analyst : Системный аналитик обычно ограничен назначенной или заданной системой и часто работает вместе с бизнес-аналитиком.
Эти роли, хотя и частично совпадают, но не одинаковы.
В качестве источников, которые могли бы установить «водораздел» между СА и БА, я старался использовать совокупность знаний БА, общепринятую профессиональную литературу, нормативные документы и статьи на различных ресурсах.
Мне не удалось найти достаточно четко сформулированного разделения.
И вот почему:
- В современных русскоязычных статьях и книгах, которые мне попадались, мне не удалось найти истину – чаще всего мнение привязано к конкретной организационной культуре, структуре или ситуации.
В одних статьях СА можно было назвать «системным администратором», в других пытались сравнивать с финансовым аналитиком и так далее (ссылки приводить не буду во избежание конфликтных ситуаций), в других БА и СА были рассматриваться вместе, в отличие от других типов аналитиков.
- В зарубежной литературе (основой изучения BA/SA многие считают книги К.
Вигерса и Д.
Битти, BABOK, А.
Коберна, «Руководство PMI по бизнес-анализу» и др.
), в которых проводится разделение BA и SA принципиально отсутствует. В некотором смысле, возможно, из-за различий в деловой культуре, они вводят в заблуждение еще больше.
Так, в книге К.
Вигерса и Д.
Битти бизнес-аналитик определяется как «роль в проектной команде, основная ответственность которой заключается в работе с представителями заинтересованных сторон для выявления, анализа, уточнения, проверки и управления требованиями проекта.
Его еще называют аналитиком требований.
системный аналитик , инженер по требованиям, менеджер по требованиям, аналитик бизнес-систем или просто аналитик».
То есть понятия неразделимы и приравниваются друг к другу.
В книгах PMI и IIBA упоминание термина «системный аналитик» вообще довольно скудно, и нет даже следа описания его отличия от «бизнес-аналитика».
- Нормативная документация Минтруда (профессиональные стандарты) приводит к разделению, достаточно близкому к реальному, хотя БА в стандарте считается далеким от ИТ.
При этом возникает понимание, почему в отечественном бизнесе так разделены понятия – призма стандартов.
Роль БА здесь заключается в том, чтобы обеспечить изменения в организации, которые принесут пользу заинтересованным сторонам, путем выявления потребностей заинтересованных сторон и обоснования решений, описывающих возможные способы реализации изменений.
Роль ЦС заключается в разработке, восстановлении и поддержании требований к программному обеспечению, информационной системе, продукту, инструменту на протяжении всего их жизненного цикла.
Подход от работа автор Алан Вонгсаван, который изучил литературу и результаты нескольких интервью и составил список базовых навыков, составляющих львиную долю рутинной деятельности BA и SA (основную часть рабочего времени):
*В зарубежных источниках более уместны термины «ориентированный на технологии» и «ориентированный на бизнес».
Где:
Выявление требований | процесс выявления требований из различных источников посредством интервью, семинаров, анализа задач, рабочих процессов и документов и других методов |
Знание бизнеса | понимание предметной области бизнеса, происходящих в ней процессов, целей бизнеса и окружающей среды |
Презентация | способность представить информацию группе людей или отдельным заинтересованным сторонам.
Может содержать рекламные элементы |
Лидерство и дипломатия | способность вести переговоры между бизнес-пользователями и техническими специалистами для разработки лучшего решения для каждого |
Связь | роль посредника, связующего звена между пользователями и бизнесом и техническими специалистами |
Изучать | поиск информации и применение методов анализа и синтеза |
Анализ данных | это умение находить и использовать важные факты, относящиеся к предмету анализа |
Решение проблем | поиск наиболее удобных (особенно нетривиальных) решений текущих ситуаций |
технические навыки | знание технологий, программирования, создания и настройки баз данных и других технических аспектов, стандартов и правил проектирования решений |
Такое взаимодействие легко вписывается в рамки, например вот как это выглядит в V-Model, водопадной модели или гибких методологиях:
Почему такое разделение?
Навыки, необходимые для бакалавров и системных администраторов, на высшем уровне одинаковы, но дьявол кроется в деталях.Для полноценной работы системному аналитику требуется гораздо больше практических технических навыков; он гораздо ближе к группе технических специалистов и должен лучше понимать их язык (без этого трудно завоевать уважение в коллективе, а значит, невозможно передать свое видение).
Бакалавр ИТ больше ориентирован на общение с бизнесом; его задача — выявить потребность (боль), найти, сформулировать и предложить решение проблемы бизнес-заказчика с помощью ИТ-систем и каким-то образом «продать» это решение.
Близость и понимание пользователя помогает БА более эффективно расставлять приоритеты задач, описывать нефункциональные требования и ограничения в конкретном случае.
Более того, у БА завышенные требования к системе, он мыслит категориями бизнес-целей и не должен быть ограничен возможностями технологий, что для БА неприемлемо.
Иногда такие завышенные требования к БА помогают найти действительно прорывные решения.
Однако есть и ограничения.
Для BA это рамки предметной области или изучаемой отрасли (например: глубокие знания банковских правил), для SA — технологии и системы (например: выдающийся опыт работы с продуктами Oracle).
Эти ограничения могут стать препятствием при перемещении между командами, проектами и компаниями, но при желании и помощи коллег их можно быстро устранить.
Практически всегда аналитик в команде в большей или меньшей степени выполняет обе роли (поэтому хотелось бы избежать споров о совмещении «а у нас еще есть бакалавр и вирусолог»).
В некоторых случаях аналитики могут не понадобиться; в других – один специалист может полностью выполнять обе роли.
Это не нарушает правил, но говорит о совмещении ролей, уровне зрелости и ценности конкретного специалиста.
В случае с опытным сотрудником это вполне нормально, а вот вакансия «младшего бакалавра» со знанием SQL, JS и API на известном сайте выглядит странно.
https://en.wikipedia.org/wiki/Systems_analyst : Некоторые преданные своему делу профессионалы обладают практическими знаниями в обеих областях (бизнес-анализ и системный анализ) и им удается успешно совмещать обе эти профессии, эффективно стирая грань между бизнес-аналитиком и системным аналитиком.
Абстрактный пример:
Иван – бакалавр компании «Исполнитель».Ева — системный аналитик в компании «Исполнитель».
Компания «Заказчик» нуждается в серьезном усовершенствовании существующей системы.
В данной ситуации задачи Ивана (БА): выявить функциональные и нефункциональные требования Заказчика и Подрядчика, устранить противоречия между заинтересованными сторонами для определения приемлемого решения, создать прототипы, взаимодействовать с заказчиком в процессе разработки.
, проведем демо-показ и примем работу.
Делайте все это вместе с Евой.
Задачи Евы (SA): оптимально спроектировать модификацию, описать ее влияние на систему, ограничения и возможные улучшения, создать спецификацию, декомпозировать и передать задачи в разработку, контролировать их своевременное выполнение в соответствии с требованиями.
Делайте все это вместе с Иваном.
Вместо вывода
От каждого можно услышать, что со временем сложность бизнес-задач и их ИТ-решений возрастает в геометрической прогрессии.Наряду с этим стек технологий развивается интенсивно и экстенсивно, вширь и вглубь.
Выбор правильного сочетания технологий может обеспечить революционные конкурентные преимущества, но может и нанести вред; часто выбор делается на несколько лет вперед, помещая разработчиков в узкие рамки.
Текущая ситуация требует от ИТ-аналитиков (1) глубоких знаний предметной области, особенностей внутренних процессов, внешней среды и тенденций, (2) не менее глубоких знаний технологий, зачастую их практического использования.
Можно быть идеалистом, искать гения и требовать от него высокого понимания разных, если не полярных, областей знания.
Можно спуститься на землю и понять, что такая двойственность обязанностей, скорее всего, приведет к провалам в обе стороны.
Сидеть на двух стульях – не лучшая практика.
Если сложность проекта требует наличия БА и СА, то сначала следует сформулировать концепцию, какой уровень знаний бизнеса и технических особенностей необходим от специалиста, и воплотить ее в опубликованную вакансию, стратегию собеседования и тестирования.
.
Всегда хочется «одного размера для всех», но мы живем в реальной жизни, где это, скорее всего, усложнит поиск и увеличит затраты на привлечение «нескольких механизаторов».
Коллегам, которые нашли себя или планируют работать в качестве BA или SA, советую провести ту же процедуру и честно понять для себя, хотите ли вы (1) искать зерно истины в постоянно меняющемся бизнесе, который часто игнорирует алгоритмы и логику или (2) исследует и проектирует сложные, запутанные, но интересные системы.
Это поможет сократить путь к выбранной вершине и уменьшить дискомфорт от пребывания не на своем месте в погоне за «красивой позицией».
Приложение
Ну что, главный редактор, теперь стало понятнее? "=" Теги: #Карьера в ИТ-индустрии #Управление проектами #Управление персоналом #Анализ и системное проектирование #системный анализ #бизнес-анализ #разработка программного обеспечения
-
Планирование Черновиков В Yahoo
19 Oct, 24 -
Пляж На Стене Дома?
19 Oct, 24 -
Документы По Делу Джонджана
19 Oct, 24 -
Mfcast #21: Специально Для Ос Google Android
19 Oct, 24