Различные аналитики (БА, СА и др.). Кто они?




Главная   Форумы   Аналитик как профессия, призвание или lifestyle   Различные аналитики (БА, СА и др.). Кто они?

В теме 18 ответов, и 13 участников, последнее обновление сделано пользователем Аватар (Romario) Romario 5 г назад.

Показано 15 ответов - от 1 до 15 (всего 18)
  • Автор
    Сообщения
  • 13.03.2010 в 22:23 # 4613
    А давайте попробуем своими силами и нашим накопленным опытом разобраться (если и не раз и навсегда, то хотя бы начнем это делать), какие же существуют различные аналитики и чем они отличаются. Чем они отличаются каждый сам сможет разобраться, если для каждого будут даны четкие определения.
    Давайте так.. кто каких аналитиков знает, тот таким и дает описания.
    Я пока подкину четырех. Без описания (:

    · Бизнес аналитики (Business Analyst, BA)
    · Системный аналитик (Systems Analyst, SA)
    · Business Systems Analyst (BSA, извиняйте не знаю, как это будет на русском)
    · Аналитик требований (Requirements Analyst, RA)

    Поделиться:

    Цитировать

    14.03.2010 в 17:20 # 4614
    Привет,

    Ниже опишу, как я лично себе представляю эти роли.

    BA — в чистом смысле слова "бизнес-аналитик". Не обязан иметь технического экспириенса (только в общем представлять процесс разработки ПО), зато должен обязательно говорить на языке заказчика, знать его культуру, особенности, уметь общаться и быть лицом компании, в которой он работает. В идеале должен быть знаком в определенной степени с бизнес-областью проекта. Его задачи и цели — помочь заказчику понять, чего тот хочет, то бишь, предложить идеи автоматизации бизнеса, основываясь на бизнес-целях и текущих проблемах. Вследствие специфики часто ездит по командировкам. Максимум, что на него можно возложить — это извлечение user requirements и передача команде.
    Я лично не участвовал в проектах с четко выделенными BA и мне кажется, что эта роль является излишней в традиционном Offshore процессе разработки (при наличии постоянного меняющихся проектов различных бизнес областей и заказчиков, которые знают хотя бы на приблизительном уровне, чего они хотят).

    SA — не сильно знаком с этим термином, но предположу, что это почти "системный архитектор", то бишь человек, который на основе функциональных требований (либо требований пользователя — но тогда в его компетенции уже будет формулировка и специфицирование функциональных требований) должен предложить функциональное видение системы (а вполне возможно и физическую архитектуру и концепцию системы). Я не знаю точно, кто такой SA, поэтому, наверное, скажу, что их я в глаза не видел :) .

    BSA — судя по названию — нечто общее между BA и SA. На данном этапе позволю себе приравнять его к RA и сказать, что это, собственно, большинство из нас. И задача этих людей… ну тут долго писать и все, думаю, знают, чем они занимаются на работе :) .. Короче, прослойка между командой разработки и заказчиком. Как-то так..

    Буду рад услышать другие трактовки этих терминов.

    Поделиться:

    Цитировать

    21.03.2010 в 12:28 # 4615
    Аватар (Mr.Dr.Jr.)
    Mr.Dr.Jr.
    Подписчик
    Привет!

    От себя я бы сказал следующее:

    — Системный аналитик это более широкое определение аналитика как такового без специализации в какой-либо области. Конечно можно было бы предположить что это должно быть слово "аналитик", однако все что мы пытаемся проанализировать так или иначе представляет из себя систему с причинно следственными связями, а следовательно любой кто пытается проанализировать и разобрать систему может считаться "системным аналитиком". Этот тот же пример с "системным архитектором", считаю оба понятия весьма абстрактными. При конкретизации архитектора может выйти "Adobe Flex Architector" или же "Java Architector".

    - Я еще знаю одну конкретную специализацию для аналитика — это Финансовый аналитик (Financial Analyst, FA). Познаний в этой профессии у меня не много, все что прочитал это то что их может быть несколько под видов. Одни занимаются анализом деятельности компании по отношению к рынку, другие же наоборот анализируют внутреннее фин. состояние компании.

    Поделиться:

    Цитировать

    01.07.2010 в 10:46 # 4616
    Аватар (Aliaksei Rudzko)
    Aliaksei Rudzko
    Подписчик
    Обещал написать в эту тему. Вот, собственно.
    Я работаю SA 3 года. До этого выступал в ролях BA, Configuration Specialist, Application Engineer, Architect Assistant, IT Support Specialist, Pre-sales Consultant, наконец — 12 лет "отпахал" как Software Development Engineer. Вроде (как мне кажется) знаю процесс разработки программного продукта "от и до". К слову, процессы эти бывают весьма и весьма различными и отличающимися от классических. Здесь я рассмотрю один из процессов разработки, в котором явно прослеживаются различия между BA и SA.

    Итак, основной "неклассической" чертой является то, что проект отталкивается не столько от требований, сколько от собственно анализа бизнеса и моделирования процессов.
    1. Клиент звонит в отдел pre-sales и проявляет заинтересованность в покупке нашего продукта и интеграции его в уже имеющуюся у них корпоративную систему и, соответственно, бизнес-процесс.
    2. Pre-sales Specialist (он же BA со знанием специфического домена) выезжает на место и проводит предварительное интервью с клиентом, где выясняет возможности для предоставления сервисов.
    3. BA и SA вместе пишут предложение. BA берет на себя часть, касающуюся функций системы, а SA — технологий и продуктов, используемых для её разработки. PM добавляет коммерческую часть. Legal dept. проверяет предложение с юридической точки зрения.
    4. PM заключает договор с клиентом и на его основании пишет Statement of Work — документ, расписывающий состав и содержание необходимых работ. Также, составляет проектный план.
    5. Архитектор, общаясь с high and medium level менеджерами заказчика, пишет System Architecture Document. В нём (в абсолютном отрыве от используемых технологий !) описываются бизнес-сущности, их взаимоотношения, основные workflows, ввод и вывод, бизнес правила. Строится высокоуровневая модель данных и всего бизнес-процесса, в котором задействована система.
    6. Бизнес-аналитик, общаясь с medium and low level менеджерами заказчика и основываясь на архитектурном документе, пишет Functional Specification. Здесь определяются и описываются (как правило, как Use Cases) функции, которые выполняет система.
    7. Архитектор, SA и представители IT заказчика определяют технологии и программные продукты, необходимые для функционирования системы. SA пишет Technical Requirements Document.
    8. SA пишет Detailed Specification. В ней — скрины, детальное описание каждого поля, комбика и иконки. Там же — детальное описание каждого алгоритма, отражающего специфические бизнес-правила. Здесь уже учитываются технологические особенности.
    9. Configuration Specialist производит конфигурацию готовых продуктов, баз данных, систем поддержки версий и т.д. Разработчики начинают кодировать.
    10….

    Указанные выше шаги не обязательно исполняются один за другим. Часто они происходят "внахлёст". Также часто необходимо бывает вернуться назад, чтобы переосмыслить систему — принять новые решения или вовсе прекратить работу.

    Выводы сделайте сами. :)

    Поделиться:

    Цитировать

    09.07.2010 в 22:41 # 4617
    Аватар (Николай Киреев)
    Николай Киреев
    Участник
    Приведу другие определения, отличия и предназначение названных выше специалистов. И так:

    1. Бизнес аналитики (Business Analyst, BA) — специалисты, которые занимаются изучением и моделированием исключительно предметной области (для этого используют специфические стереотипы языка UML) включая:
    а) выявление и моделирование сущностей предметной области, определяют их атрибуты, иерархии, при необходимости связи между сущностями. Создается диаграмма сущностей предметной области (по типу это Class diagram);
    б) выявление и моделирование функционеров предметной области (бизнес-актеры) и их функциональных обязанностей (бизнес-use case´s). Создаются специальные Business Use Case Diagram;
    в) изучение и моделирование бизнес-процессов (при необходимости состояний). Создаются Activity/Statechart Diagram;
    г) создают Глоссарий предметной области.

    2. Аналитик требований (Requirements Analyst, RA). Отвечает за выявление, документирование и моделирование функциональных требований и за обеспечение их однозначной трассировки с пожеланиями заказчика. Его деятельность включает:
    а) выявляет и фиксирует пожелания заказчика, связанные с функциональностью системы;
    б) каждому выявленному пожеланию ставит в соответствие одну или несколько функций системы, благодаря которым оно реализуется;
    в) создает спецификацию функциональных требований;
    г) функции (несколько, или одну) отождествляет с Use Caseами;
    д) документирует пожелания, функции и Use Case в трассировочной матрице;
    е) создает Use Case-модели, в которых находят отражение каждая функция бизнес-логики;
    ж) приводит краткое высокоуровневое описание Use Case, связанных с бизнес-логикой, моделирует Use Case с помощью Activity Diagram

    3. Системный аналитик (Systems Analyst, SA). Создает модели системного анализа (с помощью специальных стереотипов), т.е. первичную архитектуру (архитектуру анализа):
    а) проводит подробное описание потоков событий Use Case, создавая для этого экранные формы;
    б) из описанных потоков событий выявляет взаимодействующие объекты программной системы (лингвистический анализ потоков событий);
    в) создает динамические модели взаимодействия объектов программной системы, построение Sequence Diagram;
    г) моделирует структуру связей между объектами программной системы (Collaboration Diagram);
    д) создает диаграмму классов анализа (Class Diagram).

    Business Systems Analyst (BSA, извиняйте не знаю, как это будет на русском) — это, возможно, когда не требуется большого изучения предметной области и двух специалистов можно объединить в одном.
    Если у кого возникнут вопросы по этому посту, то буду рад на них ответить!

    Поделиться:

    Цитировать

    10.07.2010 в 09:23 # 4618
    Аватар (Николай Киреев)
    Николай Киреев
    Участник
    Каждый из указанных мною выше аналитиков отвечает за определенную область анализа программной системы и создает определенные артефакты, которые отличаются от других набором специфических стереотипов, входящих в стандарт UML. Весь процесс разработки программного продукта при этом полностью согласуется с технологией Unified Process (если хотите, то с Rational Unified Process), т.е. является итерационным инкрементальным, хорошо поддерживается средствами Rational Software (Requisite Pro, Rational Rose, Rational Soda). Каждый из аналитиков точно знает круг своих обязанностей. На каждого такого специалиста имеется свой вид сертификации. С заказчиками контактируют все эти специалисты, но каждый в рамках своих обязанностей: БА едет (если это требуется) к заказчику и изучает предметную область и обсуждает с заказчиком vision; специалист по RE согласует с заказчиком спецификацию требований и высокоуровневые описания Use Cases; СА согласует с заказчиком подробные сценарии вместе с первичными экранными формами.

    При такой организации работ все очень четко и главное, есть у кого и за что спрашивать!

    Поделиться:

    Цитировать

    19.07.2010 в 12:42 # 4619
    Аватар (ed_master)
    ed_master
    Подписчик
    nousy123 — практически идеальная картина :) Ещё бы такое в реальности увидеть :)
    Поделиться:

    Цитировать

    19.07.2010 в 22:02 # 4620
    Аватар (Николай Киреев)
    Николай Киреев
    Участник
    практически идеальная картина Ещё бы такое в реальности увидеть

    Нет, это не идеальная, а такая как она должна быть. При этом, это не догма, а руководство к действиям и, в зависимости от проекта и степени знания предметной области можно оптимизировать. Хотите так организовать на своей фирме, приглашайте, проведу тренинг на основе очень маленького реального проекта и все как и, что делать подробно на практике объясню на хороших примерах.

    Поделиться:

    Цитировать

    20.07.2010 в 11:06 # 4621
    Аватар (ed_master)
    ed_master
    Подписчик

    [quote]практически идеальная картина Ещё бы такое в реальности увидеть

    Нет, это не идеальная, а такая как она должна быть. При этом, это не догма, а руководство к действиям и, в зависимости от проекта и степени знания предметной области можно оптимизировать. Хотите так организовать на своей фирме, приглашайте, проведу тренинг на основе очень маленького реального проекта и все как и, что делать подробно на практике объясню на хороших примерах.[/quote]
    Спасибо. Я уже неоднократно проводил "тренинги" на основе реальных и больших и маленьких проектов для руководства, но у них есть своя, "перпендикулярная" точка зрения на происходящее в целом и на аналитику в частности. К сожалению.

    Поделиться:

    Цитировать

    23.08.2010 в 15:57 # 4622
    Аватар (Джафар)
    Джафар
    Подписчик
    Из собственных наблюдений, в наших реалиях есть два самых распространенных вида аналитиков:
    - Человек, который собирает данные в кучу и предоставляет на их основе руководству красивый отчет. Распространен в крупных торговых, реже в производственных, компаниях. Существует потому, что квалифицированный бухгалтер, на которого эта задача бы вешалась за неимением аналитика, стоит дорого.
    - Человек, который общается с заказчиком и превращает его "хотелки" в требования к продукту, он же переводит пожелания "белого масы" на язык понятный кудрявым девелоперам.
    :)
    Поделиться:

    Цитировать

    21.11.2010 в 09:17 # 4623
    Аватар (surok)
    surok
    Подписчик
    Добавлю свои пять копеек в копилку (на основе своего опыта):
    1. Business Analyst — отвечает за коммуникации с заказчиком, на выход выдаёт High Level Requirements и документ с Use Cases
    2. System Analyst — на вход получает документы от BA и на выход выдаёт Low Level Requirements и дизайн спецификации
    3. QA Analyst — отвечает за контроль внутренних процессов и качество выдаваемого решения
    4. Product Analyst — занимается сбором и анализом требований с проектов и за последующее расширение продуктового решения
    Поделиться:

    Цитировать

    18.12.2010 в 17:11 # 4624

    Добавлю свои пять копеек в копилку (на основе своего опыта):
    1. Business Analyst — отвечает за коммуникации с заказчиком, на выход выдаёт High Level Requirements и документ с Use Cases
    2. System Analyst — на вход получает документы от BA и на выход выдаёт Low Level Requirements и дизайн спецификации
    3. QA Analyst — отвечает за контроль внутренних процессов и качество выдаваемого решения
    4. Product Analyst — занимается сбором и анализом требований с проектов и за последующее расширение продуктового решения

    Позволю себе несколько вопросов, чтобы лучше разобраться в вашем опыте..
    1) А где работает Business Analyst?
    2) С кем он(а) общается, кроме заказчика и системного аналитика?
    3) Системный аналитик не общается с заказчиком вообще?
    4) QA аналитик отвечает за контроль внутренних процессов чего: проектной команды, отдела, в котором работает, отдела QA, всей компании?
    5) Если QA аналитик отвечает за качество выдаваемого решения, то за что отвечает QA Engineer / QA Lead / QA Manager? Понимаете, к чему я клоню?
    6) Не совсем понятны функции и обязанности продуктового аналитика. С каких именно проектов он собирает и анализирует требования? В чем принципиальное отличие от бизнес и системного аналитиков?

    Поделиться:

    Цитировать

    20.12.2010 в 16:18 # 4625
    Добавлю еще один взгляд на специфику всех этих аналитиков. Недавно участвовал в тренинге по работе с требованиями, и так предлагалась следующая интерпретация:

    - Системный аналитик: мегагуру всего и вся ("трехзвездочный генерал"). Человек, который умеет работать с требованиями, начиная с этапа анализа бизнеса (типа, я проанализирую, что у вас в компании не так, и предложу свое решение, которые поможет вам сократить издержки/увеличить прибыль и т.д.) и заканчивая чуть ли не построением архитектуры приложения и структуры классов/БД. Такие люди — на вес золота и встречаются крайне редко.
    - Бизнес-аналитик ("однозвездочный генерал") — собственно, работа с бизнес-частью. Результаты его работы нельзя пускать в разработку.
    - Аналитик требований ("однозвездочный генерал") — трансформирует результаты работы бизнес-аналитика в функциональную спецификацию.
    Т.о. БА + RA — это примерно СА. Только СА все равно гораздо предпочтительнее, чем связка БА — RА.
    В наших условиях аутсорсинга БA/CА нужны довольно редко, так как клиент обычно представляет, что конкретно ему нужно внедрить и какие бизнес-цели это преследует. Поэтому и наиболее распространены у нас аналитики требований.

    От себя: я не совсем согласен с определением системного аналитика. Но соглашусь с тем, что человек, умеющий все описанное выше, это некий сверхаддский мегагуру :) .

    Поделиться:

    Цитировать

    23.12.2010 в 15:14 # 4626
    Аватар (Йожин)
    Йожин
    Подписчик
    Я работаю системным аналитиком. И действительно могу сказать, что занимаюсь всем начиная от анализа бизнес-процессов и заканчивая разработкой архитектуры приложения и моделей данных с ним связанных. Теперь буду знать что я на вес золота :)
    Поделиться:

    Цитировать

    23.12.2010 в 15:55 # 4627

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

    Интересно (:
    А вы не могли бы рассказать немного о себе в теме "Давайте знакомиться"?

    Поделиться:

    Цитировать

Показано 15 ответов - от 1 до 15 (всего 18)

Вы должны авторизироваться для ответа в этой теме.