Комментарии 19
Что их не убивает - делает их сильнее. Ну или не делает...
Хорошая статья, в части разницы между специальностями, так точно.
Но есть один момент. Все зависит от качества сотрудника. В реальности навыки сбора требований довольно таки часто приобретают технические спецы: архитекторы, тим лиды, те же системные аналитики.
Потому что довольно таки часто тех. спецы могут заменить бизнес аналитика, но банально этого не делают, так как заняты другими задачами. А вот наоборот практически нереально, так как нужна техническая экспертиза без вариантов
Не думаю, что не нужно тягаться амбициями и знаниями, в каждой сфере они свои. Результат такой замены БА системным аналитиком - это обычно либо честно записанные слова бизнеса, который напридумывал себе функций, либо имеем договоренности, подогнанные под реализацию... Для небольших типовых задач это прокатывает, а бывает, что лучше нанять БА
Да никто не тягается. Все мы работает со всеми и все такое.
Но нужно же трезво смотреть на вещи.
Есть к примеру "визионеры". Люди, которые давно переросли просто уровень SME, они "видят" тенденции отрасли в целом ... таких единицы, за них держатся, так как они делают "продажи", да и бизнес вообще на высоком уровне.
Есть уровень ниже. Условно видеть отрасль через 5 лет они не могут, но работать на уровне разработки бизнес стратегии, консалтинг - есть и такие. Но обычно их пара-тройка на большую организацию, на реально большую. Или они разбежались по крупному консалтингу и "лидят" проекты (типа "лицо" команды, а за ними "мальки на вырост").
Следующий уровень. Просто сеньоры. Тоже редкая птица. Тут стратегия уровня enterprise конечно нет, но участие в разработке решения именно в части идей - да. Как правильно это сильный SME, но узкий, в отличии от предыдущего, который умеет "играть" на уровне большой конторы/отрасли.
---------------------------------------- все, тут водораздел ----------------------------------
Все что ниже, в лучшем случае съем требований, контроль скоупа и написание документов. Часто в документах все равно куча косяков, противоречий и неточностей, но всем по фиг, так как реально положить. Главное код написать. Иногда может быть предложение как сделать, на основании предыдущего опыта.
Цена такого спеца - уровне мидла не самой дорогой технологии, и то- часть переплата за стаж и возраст.
Чем ниже, тем печальнее, так как нет базовых технических знаний
Ниже водораздела уровне компетенций, как я писал выше - потянет большинство лидов/архитекторов, но у них своих задач по горло.
Осталось подружить этих двух сотрудников, потому что они могут тянуть систему в разные стороны.
Наоборот, они как полярные мнения для баланса между требованиями и реализацией. Ну и да, им нужно совместно договариваться и искать золотую середину треугольника (контент-сроки-бюджет). Чтобы не получилось в духе: "Дайте нам такой отчёт и точка, ничего не хотим слышать, сами разбирайтесь, выжспециалисты. " или наоборот "Не нужен вам этот отчёт, вот есть два (или три), в которых вся эта инфа есть уже"
Однажды люди узнают, что все функции бизнес аналитика должен делать продакт-менеджер. А ещё, что в некоторых вполне себе больших IT компаниях нет роли системного аналитика - она поделена между продактом и сеньорными разработчиками. И перестают плодить избыточные роли в командах.
Продакт-менеджер - роль в продуктовой компании, бизнес-аналитик - роль в процессе заказной разработки. Они очень плотно пересекаются, в каких-то случаях (например, если компания делает коробочный софт для бизнеса, но в то же время готова его кастомизировать под клиента) - вообще сливаются в одну. Тут нет антагонизма как такового.
Системный анализ вешать на разработчика можно, если речь идёт о долгом развитии одной и той же системы. Если проекты, над которыми работают команды, разные (совсем разные) - лучше выделить отдельного человека.
А вообще роль и позиция - разные сущности. Роль определяется задачами. Несколько ролей вполне могут быть реализованы в рамках одной должности, но важно, чтобы навыки для них не были слишком взаимоисключающими.
У меня тоже был перед глазами пример, когда работу по первичному анализу требований совмещали продакт и тимлид (если планировали большие изменения, то включалась вся команда, включая инженеров по качеству), вполне успешно. О том, что это оказывается отдельная особая должность узнала не так давно, удивилась. Мне и до сих пор непонятно, как человек который не знает продукт ни с технической стороны, ни со стороны пользователя может этим заниматься.
Продакт не должен делать работу бизнес-аналитика, хотя может в некоторых ситуациях. Иначе не было бы двух отдельных специальностей и профстандартов для них.
Касаемо отсутствия системных аналитиков в некоторых компаниях. Это решение конкретной компании, у которой наверняка есть на то веские причины. Во многих других фирмах ситуация иная - и системный аналитик может быть обязательной ролью в команде.
Опять проблемы с терминологией. То, что в статье называют бизнес-аналитиком - как раз функции системного аналитика в большинстве компаний. То, что назвали "системным аналитиком" - функции техлида или разработчика внедрения. Про функции бизнес-аналитика в статье вообще ни слова не сказано.
Хочу напомнить, что аналитик - не занимается проектированием и разработкой, это задачи для другой роли.
В статье смешали задачи решения проблем заказчика, сбора требований, проектирования и реализации. Это разные активности, которые могут очень разными способами распределяться по команде, но "как" - это всегда задачи разработчика, а не аналитика.
Так что должны делать БА и СА?
аналитик - не занимается проектированием и разработкой, это задачи для другой роли
каждый раз радуюсь, когда такое читаю или слышу, но
функции системного аналитика в большинстве компаний
к сожалению, уже далеко не в большинстве.
Это не всегда так. Системные аналитик определяет как система должна работать, по какой логике, а разработчик подсказывает можно это настроить в виде кода или нет и далее уже на языке программиста говорит что делать разработчику или делает сам.
Системные аналитик является связующим звеном между бизнесом и ит-службой
"Как система должна работать" - это и есть проектирование. И это может делать только человек, погруженный в реализацию системы (разработчик, архитектор, техлид и т.п.).
Это не имеет никакого отношения к анализу.
Связующее звено между бизнесом и разработкой (на IT-службой, это вообще из другой оперы) называются продакт-менеджерами.
Зависит наверное от размеров компании)
Все модели ложны, некоторые полезны. Продакты, архитекторы, аналитики (системные и бизнес) это всего лишь названия ролей или должностей. Как верно заметили, люди с этими ролями могут иметь или не уметь нужные скиллы
В контексте есть ряд других параметров (зрелость ит в отрасли, ит в компании, адекватность заказчиков, текущий ит ландшафт, бюджет, сроки, наличие коробочного решения, цели и масса всего ) что влияет на то, как нужно строить историю от запроса к ит системе. И бьюсь об заклад во многих случаях наличие 2 классов аналитиков будет избыточно, если не вредно.
Итого: в попытке обобщения нв мой взгляд полностью утрачено здравое зерно. Лучше расскажите о своих факапах или победах
IIBA откройте или BABOK. Вроде как отраслевой стандарт. Там расписаны грейды аналитиков и их специализации. Много нового узнаете. Условно говоря как вы договоритесь, тем человек и будет.
Хочется одновременно и согласиться с автором по некоторым пунктам, а по некоторым наоборот поспорить, в любом случае, спасибо за статью. Маленьким командам теперь есть на что опираться, когда они обращаются к боссу с претензией по нагрузке: "иди расширяй команду, без системных/бизнес аналитиков (зависит от того какие уже есть хD) работать нельзя, даже на хабре так написано, жмот!")
Чем бизнес-аналитик отличается от системного и почему для проектов цифровой трансформации вам нужно два специалиста