Вернуться назад

Бизнес против системы: учимся различать аналитиков в теории и на практике

Всем привет! И сегодня мы поговорим про то, о чем принято спорить до пены у рта или задумчиво молчать с непониманием происходящего. А именно, о разнице между такими существами айтишного бестиария, как системный аналитик (англ. SA или рус. СА) и бизнес-аналитик (англ. BA или рус. БА).

Вступление: кто и про что

Для начала небольшой дисклеймер. В IT я тружусь с 2015 года в найме и на 2-3 года дольше, если считать попытки в стартапы и бизнес, и за это время увидел массу интерпретаций ролей специалистов в разработке. Последние несколько лет я трудился в роли системного аналитика в двух компаниях, а ранее вдоволь понаблюдал за работой бизнес-аналитиков в еще одной, частично подменяя их по ситуации. В текущий момент я перешел к роли Product Owner на своем проекте в Innovative People, однако совсем недавно был ведущим в системной аналитике, так что память свежа.

Эта статья не является истиной в последней инстанции, да и ничто не может быть абсолютной истиной, так как в IT достаточно гибко работает подстройка функций члена команды под конкретные задачи компании и видение команды (и это хорошо!). Так что воспринимайте сей рассказ как обзорную информацию для тех, кто “хочет войти в IT”, либо “хочет войти в аналитику”, либо прямо сейчас столкнулся с задачей сборки команды и пытается разобраться, кого нанимать и для каких целей.

А теперь поехали.

Аналитики: красивое и понятное формальное деление

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

Как правило, в разработке всегда присутствует разрыв между тем, что хочет сделать заказчик (бизнес) и тем, как это делает исполнитель (команда разработки). По сути, это банальная проблема перевода “с языка на язык”, так как заказчик рассматривает проблему со своей точки зрения, но не может реализовать своими руками цифровое решение для нее. С другой стороны, разработчики могут решить потенциально любую проблему за деньги заказчика, но с трудом понимают общие фразы, экономические описания и прочие “сделайте, чтоб было круто”.

Именно тут и приходит на помощь аналитик.

Обращаясь к главному источнику знаний обо всем на свете (“Википедии”), можно получить такое обобщенное описание ролей:

“Бизнес-аналитик — специалист, использующий методы бизнес-анализа для исследования потребностей деятельности организаций с целью определения проблем бизнеса и предложения их решения.

Международный Институт Бизнес-Анализа (IIBA, International Institute of Business Analysis) определяет бизнес-аналитика «как посредника между заинтересованными лицами для сбора, анализа, коммуницирования и проверки требований по изменению бизнес-процессов, регламентов и информационных систем. Бизнес-аналитик понимает проблемы и возможности бизнеса в контексте требований и рекомендует решения, позволяющие организации достичь своих целей».”

И далее:

“Системный аналитик — в широком смысле — специалист по решению сложных организационно-технических проблем, имеющих междисциплинарную природу, использующий принципы общей теории систем и методы системного анализа.

В узком смысле в сфере информационных технологий данный термин используется для обозначения профессиональной роли и профессии, ответственной за анализ потребностей пользователей на предмет возможности их удовлетворения посредством функций соответствующей информационной системы. Также его называют «постановщик задач». Основным продуктом такого системного аналитика являются организационно-технические решения, оформляемые как техническое задание на систему или программное обеспечение.”

Можно порыться в интернетах и найти несколько иные определения и версии, но в общей сути они сводятся к одному и тому же, поэтому не будем тратить время и сойдемся на следующем кратком выводе:

В общепринятой (более-менее принятой) парадигме, бизнес-аналитик выступает в роли переводчика, приближенного к бизнесу. Системный аналитик — переводчик со стороны техники.

Как это выглядит должно выглядеть на практике

Допустим, к нам приходит заказчик и хочет сделать некоторый социальный сервис “Рукакнига”, но с нюансами и с бюджетом несколько отличающимся от бюджетов корпорации “Бета”. После того, как продажники заверили его в том, что это возможно, и контракт получил свои подписи, включается коммуникация Заказчик—Разработка.

В дело вступает БА, который:

• Детально разбирается в “хотелках”, уточняет их формулировку,
• подробно и максимально полно описывает их в формате User Story,
• изображает некоторое число макетов разной степени тяжести,
• иногда — рисует флоу жизни пользователя в будущем продукте в одной из доступных нотаций,
• по мере разработки: проводит демо MVP, билдов и фич для заказчика.

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

В идеальном мире именно на этом этапе включается Системный аналитик (почему я говорю про идеальный мир — поясню чуть позднее). Именно системщик:

• Подбирает под бизнес-запросы техническую реализацию. Учитывает ландшафт системы, если новинки — часть более крупного продукта или системы продуктов, подбирает способы интеграции с дополнительными сервисами, если они нужны.
• Проектирует REST-сервисы и базу данных, рисует замысловатые UML-диаграммы и дизайн-схемы для бэкенда, вскрывает возможные слабые места, подсвечивает дополнительные риски корнер-кейсов, закладывает логику и задел под масштабируемость, и так далее. В целом это напоминает работу мини-архитектора.
• Также именно СА будет сопровождать разработку, поясняя документацию там, где она почему-то оказалась не до конца прозрачной или чрезмерно сложной, а также разбираясь с появляющимися проблемами наподобие “по документации описано вот так, но мы писали код и вдруг поняли, что так не выйдет” или “безопасники сообщили, что наша фича полный провал, нужно перелопатить все интеграции”.
• Также от СА, как правило, ожидается создание исчерпывающего набора артефактов: документация разных типов, схемы, инструкции, таблицы, диаграммы. При этом артефакты должны соответствовать определенным стандартам и нотациям для обеспечения унификации и понятности.

Подытоживая написанное выше, можно сделать вывод, что ключевое отличие бизнес и системного аналитика кроется в области знания, куда они погружаются. Что, в общем-то, очевидно из названия специальностей: БА максимально разбирается в бизнесе заказчика, СА максимально разбирается в подкапотном пространстве продукта. При этом аналитики находятся в живой коммуникации и вдвоем полностью закрывают вопрос “трудности перевода” с бизнесового на айтишный и обратно.

Как это выглядит в реальности

Кажется, что все логично и мы легко и по-гусарски разобрались в вопросе. Но нет.

Я не случайно чуть ранее сделал ремарку про “идеальный мир”, потому что в действительности граница между этими двумя специальностями размыта максимально.

• Кто из аналитиков проводит демо готовой фичи, если в команде нет Product Owner?
• На каком моменте бизнес-аналитик останавливает детализацию фичи по технической части?
• Нужно ли рисовать макеты системному аналитику для понятной увязки кнопок фронта с бэком?
• А приемочное тестирование кто проведет?

Возможно, ответ кажется вам очевидным, но ставлю десятку, что он работает только в пределах вашего проекта/команды. Стоит сделать шаг в другой мир и там законы существования окажутся иными.

Я, например, долгое время работал в компании с бизнес-аналитиками, чья работа заключалась в формировании коммерческого предложения (казалось бы, почему не продажники?), кропотливой записи созвонов с заказчиком и поверхностного описания хотелок в JIRA, но на этом их полномочия иссякали — всю “технику” разработчики ваяли на свое усмотрение, попутно обкладываясь по мере сил UML и BPMN (либо, что чаще, практикуя “интуитивное программирование”). Однако в других компаниях порой БА называют человека, который заходит на территорию СА и сопровождает весь цикл разработки с некоторыми ограничениями по технике (например, не заведует архитектурой, не проектирует базы данных).

С другой стороны, бывают команды, где системные аналитики проводят демо заказчикам или даже рисуют макеты, на которые натягивается дизайн без привлечения отдельного специалиста-дизайнера. Где-то, например, СА может не касаться архитектуры, которая полностью отдана Архитектору. А уж тактика привлечения СА в качестве эксперта на встречи с бизнесом и вовсе может быть самой разнообразной: от полного запрета на общение (дабы не пугать своим видом чутких и впечатлительных стейкхолдеров) до активного привлечения на каждую встречу в качестве убойной артиллерии.

Более того, некоторые компании и вовсе не заморачиваются, а просто называют специалиста “Аналитик”, зачастую подразумевая нечто, что я для себя называю Full Stack Analyst по аналогии с Full Stack Developer. То есть мастер на все руки, который: и в запросах заказчика разберется, и переговоры проведет, и схему архитектуры бэка размером с простыню запилит.

Хочу отметить, что последний пример про Full Stack Analyst не взят с потолка, именно так я провел года полтора своей карьеры. Макеты, демо, чек-листы приемочных тестов и тп. Впрочем, макеты рисовать было не обязательно и в список задач моих это формально не входило, но оставлять продукт совсем без потуг в UX/UI было стремновато. Конечно, на выходе мы все равно получили пульт управления звездолетом, но я хотя бы попытался.

Тут мог бы быть четкий вывод, но он будет размытым

Как видите, классификация БА/СА по итогу оказывается весьма расплывчата и зависима от паттернов работы в конкретной компании или команде. Именно это и становится причиной постоянной путаницы и бесконечных холиваров на форумах о том, что же “должен и не должен делать аналитик”.

Что касается лично моего мнения, споры эти порой чрезмерны и бессмысленны, потому что любой специалист, в конечном итоге, “должен делать” то, что ожидается от него в конкретном проекте или команде, а не обмазываться формализмом в ущерб продукту. В пределах разумного, конечно же.

А разумным в данном случае будет считать, что:

• БА — это история про бизнес и общение с заказчиком (ЧТО мы будем делать),
• СА — это история про технику и общение с командой (КАК мы это сделаем).
• Продукт/проект может требовать смещения ролей и оно вполне допустимо, если не является банальным злоупотреблением или прикрыванием дыр менеджмента.
• Драматичную историю полного любовного слияния обеих профессий в одном человеке стоило бы честно называть в стиле Full Stack Analyst. Но и любить (и платить) за такое, разумеется, нужно соответствующе.

На этом все. Спасибо, что дочитали. Надеюсь, эта краткая экскурсия будет в той или иной степени полезна. Всем интересных проектов, крутых фич и качественных продуктов!

Читать материал в блоге Innovative People на Хабре