Изменения

Границу ответственности провели '''примерно''' по границе между сбором требований и проектированием системы, оставив требования за заказчиком, а проектирование - за подрядчиком в ИТ-разработке. Таким образом, бизнес-аналитики отошли к Заказчику и при этом '''ушли из ИТ к технологам''' бизнеса, которые разрабатывая технологию работы компании и ее бизнес-процессы, заодно определяют необходимый уровень поддержки автоматизацией, формулируя требования. А системные аналитики остались в ИТ, и стали называться просто аналитиками.

Только вот '''примерно''' в предыдущем абзаце написано не просто так. На реальную ситуацию накладывается множество других аспектов. С одной стороны, во многих компаниях нет квалифицированных бизнес-технологов как отдельной специализации, а разделение обязанностей и процессы определяют руководители по месту. Понятно, что в этом случае выполнять роль бизнес-аналитиков они не могут, и эта задача переходит к ИТ-подрядчику в автоматизации. С другой стороны, руководитель у заказчика часто имеет собственный ИТ_опыт проектирования систем, и тогда он '''вместо требований формулирует технические решения''', залезая на поляну системного аналитика. Что не есть хорошая ситуация, поскольку его опыт часто находится достаточно далеко в прошлом, а ИТ развивается быстро. А еще он часто игнорирует требования других стейкхолдеров и пользователей. То есть, залезая на поляну системного аналитика, он, тем не менее, не выполняет функции бизнес-аналитика.

А несколько позже произошло другое изменение в разделении труда, уже в самой ИТ-разработке. Пришел Scrum, подняв на флаг кроссфункциональную команду разработчиков. Фишка в том, что коммуникация через артефакты, предполагаемая классическим разделением труда - весьма неэффективная штука для ИТ-разработки. И чем меньше коммуникаций на пути от пользователей, тем более вероятно, что продукт будет удовлетворять их потребности. А квалифицированный разработчик вполне может выполнить функции системного аналитика по проектированию системы, если обучится языку заказчика. Все это вызвало многочисленные дискуссии о необходимости специализации аналитика некоторое время назад. А еще вызвало проблемы с архитектурой сложных систем, разрабатываемых кусочным образом - этот фокус оказался упущен.

Сейчас Agile и Scrum ослабили требования кроссфункциональности, вернув специализации. В целом это естественно: маятник всегда качается далеко, а потом возвращается, это называется диалектикой развития. И область деятельности бизнес-аналитика как отдельная - тоже продолжает существовать.

Но это - специализации, преимущественное положение. А аналитик на проекте может быть один. Что не означает, что он выполняет функции и того и другого - он заполняет '''просвет между заказчиком и разработчиками''' где бы этот просвет не находился и какого бы размера не был. При том, что при разной организации ИТ-разработки этот просвет может иметь очень разную конфигурацию.

= Кто нужен на проекте=

В принципе, описанные задачи по организации работы - находятся в поле деятельности HR. Однако, требуют специфических знаний об организации ИТ-разработки. Которые не обязательно осваивать самому. Но и полагаться на публичные советы тоже не слишком следует, потому что решения могут '''критичным образом''' сказаться на успехе проекта. Эту задачу тоже пытались решить традиционными методами - через сертификации, однако темп развития ИТ таков, что это по факту институализироваться не успевает, все стандарты, тот же BABOK - находятся в прошлом. Поэтому стоит действовать другим методом - через доверенных экспертов или сообщества.