Бизнес аналитик это айтишник или нет

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

Одного моего знакомого на собеседовании на позицию «Системный аналитик» спрашивали, знаком ли он с VBA и как хорошо пишет макросы. Технические задания он писал лучше

Аналитики редко играют одну роль на проекте, и рано или поздно каждый из них задает себе вопрос «Кто я?».

Немного истории

Еще несколько лет назад на HR рынке мы наблюдали бум позиций менеджеров. «Сотрудник банка и страховой компании», «консультант магазина электроники», «риелтор», «ответственный за формирование требований к программному продукту» – все именовали себя менеджерами. На втором курсе университета нам так определили роль менеджера ИТ проекта: «член команды, который организует взаимодействие между заказчиком и командой разработки; своеобразный переводчик с языка бизнеса на язык программистов». Нас учили писать техническую документацию, моделировать предметную область, предлагать решения по оптимизации бизнес-процессов, проектировать базы данных, программировать. Мы также получили еще много навыков, необходимых эффективному менеджеру проекта, но через несколько лет рынок встретил нас неожиданной новостью: для менеджера проекта гораздо важнее иметь соответствующий опыт работы, чем обширный набор академических знаний. Компании, подыскивая руководителей команд разработки, почему-то не устраивали сражений за будущих выпускников.

Пришлось проститься с надеждой на мгновенный карьерный взлет. Кто-то пошел в тестирование, кто-то – в программирование, а кто-то решил попробовать себя на позиции «Аналитик», которая на тот момент ассоциировалась только с биржей, акциями и Уолл Стрит, но при этом полностью соответствовала навыкам, полученным в университете.

Сейчас по запросу «Аналитик» сайт hh.ru выдает более четырех с половиной тысяч вакансий по всей России: требуются аналитики, системные аналитики, финансовые аналитики, бизнес-аналитики, аналитики бизнес-процессов, тест-аналитики, аналитики-маркетологи, аналитики продаж, кредитные аналитики (плюс всевозможные вариации названий должностей на английском языке). И если с финансами, продажами и маркетингом ситуация более или менее понятна (и обсуждается на других профильных ресурсах), то в сфере ИТ четкое разграничение ролей и должностных обязанностей аналитиков зачастую отсутствует.

Каких аналитиков анализируем?

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

Наибольшее количество вопросов и дискуссий в профессиональном сообществе вызывает противостояние «Бизнес-аналитик vs. Системный аналитик». Тест-аналитик ассоциируется исключительно с тестированием, но зачастую участвует и в процессе разработки (начиная с этапа формулирования бизнес- и функциональных требований), а при отсутствии бизнес- и системных аналитиков – выполняет их обязанности. В своей работе мы используем одинаковые инструменты и подходы, можем работать с одинаковыми вводными данными. Как правило, отличается только результат.

Немного статистики. Распределение вакансий для рассматриваемых ролей (системный аналитик, бизнес-аналитик, тест-аналитик) (hh.ru, по состоянию на 24.08.2017; поиск только по наименованию вакансии; география – РФ; профобласть – IT, телеком):

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

• Системный аналитик: разработка ТЗ и спецификаций; сбор и формализация требований; разработка проектных решений; проектирование интерфейсов; разработка (!) тест-кейсов; описание бизнес-процессов; функциональное тестирование; внедрение и т.д. (список не ограничивается). Рынку нужен «и швец, и жнец, и на дуде игрец».

• Бизнес-аналитик: оптимизация бизнес-процессов; управление бизнес-требованиями; написание ТЗ; проектирование интерфейса; координация разработки. Чаще всего встречаются обязанности по исследованию и оптимизации бизнес-процессов.

• Тест-аналитик: анализ продуктовых и функциональных требований к системе; участие в анализе и формировании функциональных требований к системе вместе с бизнес-заказчиками; анализ ошибок и жалоб от бизнес-заказчиков; написание ТЗ на доработку системы; моделирование бизнес-процессов; тестирование (интересно, чем в этих компаниях занимаются системные и бизнес-аналитики, если они есть?).

На позиции аналитика в отделе разработки требований мне приходилось выявлять потребности бизнеса, проводить тестирование удобства использования и анализировать API.

Со стороны может показаться, что работа аналитиков (бизнес-, тест-, системных) ограничивается узким кругом обязанностей, описанных в должностной инструкции, – разработка технических заданий, обследование бизнес-процессов, разработка плана тестирования. На деле приходится решать большое количество специфических задач, про которые не рассказывают на курсах. Так, сегодня для изучения поведения пользователей оказывается необходима Яндекс.Метрика (#тыжаналитик), завтра приходится вспоминать нотации моделирования бизнес-процессов (для демонстрации заказчику вариантов экономии ресурсов системой); а послезавтра тебе понадобятся знания XML (надо посмотреть, почему данные поступают не в полном объеме). И нельзя признаться, что ты не умеешь этого делать: учись, потому что без этих знаний и шагов ты не выполнишь задачу.

К формальным описаниям

Разные компании определяют названия должностей и обязанности на свой вкус, поэтому будет правильнее вести разговор о ролях. К сожалению, здесь мы также возвращаемся к проблеме отсутствия четких формулировок и зон ответственности. Обратимся к профессиональным стандартам (де-юре и де-факто).

1. Системный аналитик

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

В этом же документе мы найдем упоминание следующих функций:

• анализ проблемной ситуации заинтересованных лиц;
• разработка бизнес-требований к системе;
• постановка целей создания системы;
• разработка концепции системы.

Таким образом, гипотеза о том, что «системный аналитик отвечает за конечные требования к системе, а бизнес-аналитик решает проблемы бизнеса», стандартом не подтверждается.

2. Бизнес-аналитик
Попробуем подойти с другой стороны и откроем BABOK – общепризнанный стандарт по бизнес-анализу, согласно которому деятельность бизнес-аналитиков включает в себя:

• осмысление проблем и задач компании;
• анализ потребностей и решений;
• разработку стратегий;
• внедрение изменений.

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

При этом, при разработке именно программных продуктов функции бизнес- и системного аналитика во многом совпадают. BABOK не предлагает волшебную пилюлю в споре «Бизнес-аналитик vs. Системный аналитик» – наоборот, он дает пространство для маневров («Бизнес-аналитика могут также называть [барабанная дробь] системным аналитиком»). С BABOK солидарен и Карл Вигерс, автор книги «Профессиональная разработка требований к программному обеспечению», ставящий знак равенства между терминами «бизнес-аналитик», «системный аналитик», «инженер по требованиям» и «менеджер по требованиям».

В данный момент ведется работа по созданию и внедрению профессионального стандарта для позиции «Бизнес-аналитик». Его разработчики четко делят предмет работы и рабочий продукт:

По их мнению, сфера влияния системного аналитика – только информационные технологии, функции же бизнес-аналитика этим не ограничиваются. Каким образом решится конфликт ролей при разработке программного продукта (а системный аналитик будет руководствоваться стандартом и проводить «анализ проблемной ситуации заинтересованных лиц») до сих пор непонятно. Будем надеяться, что данный вопрос получит подробное разъяснение в ожидаемом документе.

3. Тест-аналитик

Целью тест-аналитика, в конечном итоге, является организация максимально эффективного (при существующих ограничениях) тестирования программного продукта. На пути к данной цели тест-аналитик:

• исследует продукт;
• анализирует сценарии использования;
• выявляет и анализирует объект и предмет тестирования;
• выбирает методы тестирования;
• анализирует тестовое покрытие;
• приоритезирует задачи тестирования.

Роль «Тест-аналитик» встречается исключительно в плоскости разработки и тестирования программного обеспечения, хотя используемые методы применимы во многих отраслях.

Про роль тест-аналитика на проекте подробно и очень понятно написал Антон Алексеев в своей статье «Тест-аналитики – кто это?». Здесь же будет озвучена мысль, которая может вызвать ожесточенные дебаты: если системный/бизнес-аналитик качественно выполнил свою работу (тот факт, что он есть на проекте, оставлю по умолчанию), то функции тест-аналитика сократятся в 2 раза. Неизменными останутся следующие объемы работ:

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

При этом уже не будет необходимости останавливаться на следующих вопросах:

• составление логической карты продукта; системные/бизнес-аналитики тоже составляют mind maps системы довольно глубокой детализации и всегда поделятся (хочется в это верить) ими со специалистами по тестированию;
• разбиение программного продукта на составные части; декомпозиция системы на компоненты должна выполняться (и выполняется) системными/бизнес-аналитиками, все материалы также включаются в техническую документацию.

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

Резюме

В большинстве компаний роли бизнес- и системного аналитика объединены; обязанности тест-аналитика возложены частично на системного/бизнес-аналитика, а частично – на тест-менеджера и инженеров по тестированию. Эти роли могут быть объединены с ролью технолога, проектировщика, технического писателя и менеджера проекта – всех, кто умеет «переводить с языка бизнеса на язык программистов». Тем не менее можно искусственно разделить границы ролей. Как и в любой профессии, пришедшей к нам с Запада, здесь допустимы различные трактовки и точки зрения (более того, на каждый аргумент в защиту той или иной позиции найдутся пять аргументов в противовес).

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

Бизнес-аналитик решает проблемы бизнеса и полностью погружен в предметную область; автоматизация и внедрение информационных систем может быть одним (но не единственным) из решений – в таком случае бизнес-аналитик или ограничивается бизнес-требованиями, или играет роль системного аналитика. Таким образом, бизнес-аналитик «ближе к бизнесу».

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

Тест-аналитик – технический специалист; определяет оптимальный набор тестов и их приоритеты для того, чтобы вся важная функциональность была протестирована в текущих ограничениях (времени/бюджета); при отсутствии системного аналитика играет его роль, также может подключаться к работе на этапе формирования бизнес-требований.

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

Источник: quality-lab.ru

Бизнес аналитик это айтишник или нет

Заблуждения обывателей

Системный аналитик — профессия, появившаяся относительно недавно на Российском рынке вакансий в IT-сфере. Понимание, кто же такой системный аналитик, возникает у кандидатов на эту должность или из требований, описанных в вакансии, или же из собственных домыслов. Давайте рассмотрим часто встречающиеся заблуждения кандидатов. Данная вакансия не для всех, кто ранее был кем-то «системным». Наша компания часто получает отклики на данную вакансию, например, от системных администраторов.

Аналитик — это тот, кто анализирует

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

Аналитик не должен уметь программировать

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

Аналитик ни за что не отвечает

На самом деле, это далеко не так, и кандидаты, желающие занять место системного аналитика в IT-компании, думают, что им не придется отвечать за работу. Ошибки аналитика в проекте являются самыми дорогими и даже могут быть фатальными для проекта.

Так чем, всё-таки, занимается аналитик?

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

На начальном этапе проектирования ПО аналитик обязан выявить у заказчика цели разработки ПО, то есть, какие основные задачи должна решать Система при ее внедрении в бизнес-процесс предприятия. Данная стадия проекта является начальной и называется процессом выявления требований. Все выявленные требования и бизнес-процессы должны быть формализованы определенным способом.

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

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

По окончании разработки любого IT-проекта наступает этап внедрения разработанного проекта в бизнес-процесс заказчика. Данный этап лежит также на плечах аналитика, он должен подготовить необходимую для пользователей документацию, провести демонстрацию работы проекта, а также обучить сотрудников заказчика. Для того, чтобы данный этап был выполнен на должном уровне, аналитик должен знать работу всего проекта от «А» до «Я», а также ориентироваться в возможных ошибках, которые будут устранены в последующих релизах. Перед этапом внедрения аналитик должен принять участие в тестировании проекта для того, чтобы убедиться в том, что все функциональные требования, указанные в ТЗ, выполняются корректно.

Секреты успешной работы

Хотелось бы затронуть тему о личностных качествах аналитика в IT-сфере. Личностные качества аналитика дают 60 % его результата. Работа аналитика связана с непосредственным общением с заказчиком, поэтому у аналитика должна быть хорошо поставленная речь, чтобы заказчик видел в собеседнике грамотного специалиста и приятного человека.

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

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

Аналитик должен обладать способностью держать большой объем информации по всему проекту, а иногда и не по одному, у себя в голове и уметь быстро просчитывать влияние тех или иных изменений, требуемых заказчику или команде разработчиков на систему в целом, чтобы своевременно согласовывать эти изменения и их последствия со всеми заинтересованными лицами. Для построения бизнес-моделей процессов заказчика аналитику необходимо обладать высокой обучаемостью. Данное качество необходимо для быстрого изучения предметной области, в которой работает заказчик. Аналитик должен стать «специалистом» в каждой из предметных областей, которые меняются с работой над каждым новым проектом. На этапе формирования требований аналитиком составляется техническое задание (ТЗ) на разработку проекта, которое необходимо согласовать с заказчиком и которое будут изучать разработчики.

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

Чаще всего модель того или иного процесса может быть представлена в виде набора объектов, а действия над ними — в виде методов. Также объекты моделей могут обладать свойствами. Объекты в моделях могут использовать все принципы ООП. При построении моделей системы, как правило, определяется и модель данных проекта.

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

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

Инструменты аналитика

Главными инструментами системного аналитика является ручка, бумага и карандаш. Хорошему аналитику этого вполне достаточно для того, чтобы сформулировать требования и составить бизнес-модель. На практике аналитики применяют различные средства моделирования, поддерживающие нотации IDEFx, UML, BPMN.

Такие средства позволяют сократить время на построение моделей и диаграмм, а также получить результат в графическом виде и в виде текстовых отчетов. Подобные инструменты оказывают помощь и в контроле над требованиями к проекту, и в поддержании их в актуальном состоянии. Примером средств моделирования являются такие приложения как: Enterprise Architect (EA), Rational Rose, RUP и др. Также аналитику приходят на помощь и офисные пакеты, такие как MS Office, iWork, Open Office.

Куда идти дальше?

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

Источник: intalent.pro

П̶л̶о̶х̶о̶й Хороший ИТ-аналитик: FAQ по пути от Junior до Lead

Павел Пестряков, руководитель проектной экспертизы по регуляторной отчетности департамента аналитических систем, R-Style Softlab

На сегодняшний день аналитик является весьма востребованной специальностью в ИТ-сфере. Профессионалы на этом рынке ценятся «на вес золота». Однако, выбрав для себя данное направление и решив построить карьеру на ниве аналитики, молодые люди – выпускники вузов не всегда понимают, чем именно им предстоит заниматься. Из нашей статьи вы узнаете, кто такие аналитики, какими качествами они должны обладать, какие их навыки и умения особенно ценны для ИТ-компаний и для бизнес-заказчиков. А полезные советы автора помогут новичкам максимально уверенно и со знанием дела пройти свой путь от Junior до Lead.

Поделиться:

Место аналитика в ИТ

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

Что касается аналитика, то он в этой схеме находится ровно посередине. Он как мостик между разработкой и заказчиком, который пропускает через себя и трансформирует запросы и «хотелки» бизнеса на язык разработки.

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

Так, например, источником данных для анализа в области энергетики являются «интернет вещей» (IoT), а также датчики, постоянно снимающие информацию. Так как таких датчиков бывает много (по несколько штук на единицу электрической сети), то и информации собирается огромное количество. В таких случаях применяются технологии управления большими данными (Big Data), а для анализа данных (включающих большое количество параметров сети) чаще всего используется либо информационные доски (дашборды), либо инструменты статистического анализа (чаще всего на базе языка программирования Python).

Крупные компании, сфера деятельности которых лежит в плоскости производства, ритейла или логистики, используют комплексные решения по управлению предприятием. Это системы класса ERP (Enterprise Resource Planning), которые наряду с обеспечением учета охватывают также расчет потребностей различных подразделений компании в ресурсах (человеческих, материальных или производственных) и управление.

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

И подобных примеров можно привести великое множество.

Аналитики много не бывает

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

Чтобы понять, кто же такой хороший аналитик, давайте посмотрим, какие задачи он решает на всем протяжении ИТ-проекта:

• Коммуницирует с заказчиком.
• Знакомится с документацией (нормативно-правовой — внешней и внутренней), с особенностями бизнеса, изучает смежные с разрабатываемой функциональностью системы, электронные таблицы и т.д.
• Выявляет потребности заказчика. Для этого прибегает к переговорам, использует опросники или другие инструменты обработки информации.
• На основе потребностей заказчика описывает требования к программному обеспечению.
• Исходя из этих требований, совместно с проектной командой решает, какие из них возможно покрыть, а какие нет.
• Фиксирует и согласует с заказчиком требования в формате Технического задания (ТЗ), Функциональных требований (FSD) или Бизнес-требований (BRD).
• Иногда кроме документации еще готовит маппинги (если задача носит интеграционный характер), пишет скрипты для выгрузки данных для примера или какие-то дополнительные поясняющие документы.
• Также неотъемлемой частью работы является описание — не столько текстовое, сколько графическое. То есть рисует бизнес-процессы, схемы интеграционного взаимодействия, архитектуру ИТ, модель данных (если речь идет о проектировании решений на базе СУБД или хранилища данных).
• Консультирует разработчиков.
• Уточняет и прорабатывает с заказчиком дополнительные требования при их наличии.
• Тестирует готовый продукт с разработчиками или с бизнес-заказчиком.
• Консультирует по продукту, если, например, он уже внедрен и находится на поддержке или сопровождении у заказчика.

Пришла, наконец, пора поговорить о специализации аналитиков. Обычно выделяют два вида аналитиков — это бизнес-аналитики и системные аналитики. В последнее время с внедрением «больших данных», решений по статистической обработке данных, Data Mining и прочими инструментами стали выделять еще и аналитиков данных (Data Analyst). Рассмотрим, как отличаются их задачи.

В идеале имеется в виду, что бизнес-аналитик более погружен в специфику заказчика, описывает минимальные требования к функционалу внедряемого решения и фиксирует основные (но и самые важные) бизнес-требования к программному обеспечению, а в период сдачи функционала не погружается в код, а работает на уровне пользователя (например, проводит сверки в Excel, проверяет работу интерфейсной части программ и т.д).

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

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

В реальной жизни аналитики не бывают исключительно системными или «бизнесовыми». Чаще всего у каждого из них есть свой набор накопленных и освоенных знаний и инструментов, исходя из его собственного опыта и полученного образования. Поэтому при формировании команды проекта его руководителю важно четко понимать, подходит ли конкретный аналитик под решение определенных проектных задач. И в этом понимании характеристика «хороший/плохой аналитик» может служить для качественной оценки его квалификации. Для каждого проекта набор навыков, инструментов и экспертизы аналитика в разных разделах знаний может быть уникален и обусловлен спецификой разрабатываемого продукта или функциональности.

Ступени роста для аналитика

Как и в прочих разделах ИТ, для аналитиков тоже существует четкая градация:

• Intern (стажер)
• Junior (младший аналитик)
• Middle (рядовой аналитик)
• Senior (старший аналитик)
• Lead (ведущий аналитик)
• Team Leader (руководитель группы аналитиков)

Intern и Junior

Путь аналитика начинается в хорошем случае уже со студенческой скамьи. Классическое образование по аналитике можно получить на специальности «Бизнес-информатика» или на специализированных программах в соответствии со сферой экономики (например, «Банковское дело» для финансовой сферы). Не меньше ценится программа по Прикладной информатике.

Само понятие «бизнес-информатики» пришло к нам из Германии и начало свой путь в образовании в конце 1990-х годов. Первая кафедра открылась в Высшей Школе Экономики. Сегодня аналогичные программы обучения предлагают также Финансовый Университет при Правительстве РФ (бывш. Финансовая академия), МГТУ им. Баумана и ряд других вузов.

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

Требования к младшему аналитику или стажеру обычно не слишком высоки. Они должны:

• Знать (поверхностно) один из языков программирования (SQL или Python).
• Понимать, как строятся информационные системы (ИС), каковы этапы их жизненного цикла и т.д.
• Иметь опыт работы с одной из нотаций (графического языка): UМL, BPMN, ARIS, Archimate.
• Уметь работы в одной из программ для проектирования ИС: Power Designer, Rational, Visio или др.

Middle, Senior

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

• Развитые компетенции для начинающих аналитиков, описанные выше;
• Коммуникативные навыки (в том числе умение вести корпоративную переписку).
• Написание проектной документации (различные виды требований, маппинги и т.д.).
• Более погруженная и самостоятельная работа (по сравнению с младшим аналитиком). Это касается не только согласования требований, но и работы на пресейлах, участия в аналитике «внутренностей систем». На данном уровне развития у аналитика уже есть понимание, как работает система, из каких частей состоит. Причем понимание бизнес-аналитика идет с позиции бизнеса, требований законодательства или принципов учета (например, бухгалтерского). А системный аналитик понимает, как это работает изнутри и может на уровне программного обеспечения и базы данных проработать требования или обозначить кейс или ошибку в ПО.
• Умение работать в команде с разработчиками и с другими аналитиками.
• Владение программами совместной работы (GIT, SVN, облачные сервисы).
• Уверенное знание отраслевой специфики.
• Опыт работы с несколькими системами одного и того же класса.

Lead, Team Lead

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

• Отличное знание предметной области на уровне заказчика.
• Навыки планирования.
• Понимание методологий разработки программного обеспечения (SCRUM, WA-TERFALL, RUP или др.).
• Знания и навыки проектного управления (работа с MS PROJECT или с пулом задач/kanban-доской или другими инструментами на основе Google-таблиц).
• Понимание архитектуры программного обеспечения.
• Принятие сложных решений для разработки ПО совместно с бизнесом и ИТ-отделом заказчика.
• Систематизация и обработка большого количества информации;
• Участие в собеседовании кандидатов на должность аналитиков или разработчиков;
  Управление комплексом мер по управлению знаниями (совместно с руководством проекта и владельцами продуктов):

• проведение внутреннего и внешнего обучения для обмена опытом команды аналитиков компании;
• подготовка обучающих материалов для новичков;
• подготовка и курирование написания проектной документации;
• развитие корпоративных стандартов по аналитике (по написанию документов (ТЗ, маппнгов, схем и пр.), по обследованию и другим процессам аналитики);
• хранение результатов аналитики для возможности повторного использования.

Основные личностные качества аналитика

Говоря об аналитиках, нельзя не упомянуть и про их личностные качества — так называемые soft skills:

• Системное мышление.
• Грамотная речь.
• Внимание к деталям.
• Навыки общения.
• Скептицизм в хорошем понимании этого слова (проверка гипотез, а не вера на слово).
• Терпение и методичность.
• Деловой подход.
• Стремление учиться.

Вместо заключения

Мне вспоминается вывеска в любимом вузе, которую я увидел и запомнил на всю жизнь: «Приходите к нам учиться. Будет сложно, но интересно». И это как раз про аналитику. Если у Вас есть желание закопаться поглубже во что-то сложно устроенное и интересное, обложиться кучей книжек, заниматься чем-то невероятно классным и умным, получать хорошую зарплату, а вместе с ней и интеллектуальное удовлетворение от проделанной работы, то советую остановить ваш профессиональный взор на карьере в аналитике.

А чтобы лучше понять, чем вам придётся заниматься, советую прочесть несколько интересных книг, которые, по моему глубокому убеждению, должны быть в библиотеке любого человека, решившего посвятить себя аналитике:

1. Н. М. Абдикеева «Корпоративные информационные системы» (издание с диском или электронная версия библиотеки znanium);
2. Е. П. Зараменских «Архитектура предприятия»;
3. О. А. Морозова «Интеграция информационных систем»;
4. Н. М. Лобанова, Н. Ф. Алтухова «Эффективность информационных систем»
5. К. Ларман «Применение UML и шаблонов проектирования»;
6. Б.Я. Советов, В. Д. Чернявский «Базы данных: учебник для бакалавриата»;
7. ITIL или любой учебник по ITSM (IT Service Management);
8. «Руководство к своду знаний по управлению проектами (руководство PMBOK)» (издание 5 или 6) за авторством PMI с приложением «AGILE практическое руководство»;
9. Международный Стандарт по Управлению Проектами ISO 21500:2012;
10. А. Просницкий. Самоучитель «Управление проектами в Microsoft Project 2010»;
11. Майк Кон «SCRUM. Гибкая разработка ПО».

Источник: www.softlab.ru