От первого лица: Бизнес-аналитик. Суть работы и перспективы роста

От первого лица: Бизнес-аналитик. Суть работы и перспективы роста

Cегодня о своей профессии рассказывает аналитик одной из крупнейших IT-компаний Татарстана Людмила Давыдова. Кстати, недавно центр профориентации ПрофГид разработал точный тест на профориентацию, который сам расскажет, какие профессии вам подходят, даст заключение о вашем типе личности и интеллекте.

В чем суть выполняемых аналитиком задач?

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

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

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

  • Профориентация в школе. Акция 15+15
    Специальное предложение для школ, учителей и профориентологов, работающих с школьниками.

Какими навыками и компетенциями нужно обладать? Нужно ли иметь It-образование?

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

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

Ну и, разумеется, больших успехов не добиться без усидчивости (на разработку одного макета может уйти несколько часов!)

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

Для интерфейсов мне нравится Balsamiq Mockups, за разнообразие инструментария и веселенький дизайн.

Процессы мне удобнее отрисовывать в нотации EPC (хотя BPMN тоже ничего).

Кто категорически не может это делать?

Далекие от математики и логики, не думающие, поверхностные люди. Гуманитариям тоже вряд ли придется по душе работа аналитика.

Кто выше аналитика такого рода? Есть ли куда расти?

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

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

В чем главная радость и смысл бытия на работе? Какие моменты приносят радость и какие огорчения?

Радость — когда удается найти решение сложной задачи, большая радость — когда оно нравится заказчику. Огорчает, когда придуманный тобой алгоритм не проходит системный анализ, и приходится начинать все сначала.

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

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

Много ли коммуникаций и с кем? С какими людьми приходится иметь дело?

Много. Без коммуникаций никуда, аналитик работает в команде. Общение происходит как с заказчиком (ключевые специалисты, либо члены группы внедрения), так и внутри своей команды. Наиболее тесно общаться приходится с разработчиками, и системными аналитиками. У нас это особенные люди, с особенно — техническим складом ума, не допускающие «лирики» и требующие «объяснить суть». Мне безумно интересно с ними работать. Еще есть технические писатели, руководители проектов, другие аналитики, специалисты техподдержки, руководители отделов, — поле для общения огромное.

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

Какова вилка зарплаты?

Минимальная зарплата аналитика, насколько мне известно, 20 тысяч. Самая высокая, о которой слышала, 50, но думаю, это не потолок.

Дает ли работа в достаточной мере сложных задач? Ведь только ими и растешь.

На любом проекте есть задачи сложные и рутинные. В моей работе соотношение примерно 40/60, и меня это устраивает. Каждый день — и зарядка для ума, и возможность отдохнуть за написанием инструкций.

Приведу несколько примеров задач из практики:

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

Решение: Взаимодействие X и Y реализовано через веб-сервисы. Файловый обмен ведется в режиме 24/7, с момента наступления определенного события в системе Y, до полного завершения выгрузки/до наступления дедлайна/до ручной остановки процесса. Разработан формат обмена, перекрестная (между двумя системами) матрица статусов загрузок, утверждены коды возвратов. Файлы на входе Y проверяются на корректность, а в случае ошибок отклоняются до исправления ошибок и повторной загрузки. Реализована форма мониторинга, ведутся подробные логи. По завершению загрузки каждого файла Y подтверждает или не подтверждает прием файла. Проведено нагрузочное тестирование X и Y в период работы сервиса обмена данными (результаты тестирования были неутешительными, поэтому пришлось придумать хитрый алгоритм очередности загрузок, позволяющий не грузить тяжелые файлы в периоды активной работы пользователей Y). Разработана инструкция по настройке сервиса и работе с ним. В данный момент времени обмен данными между X и Y ведется только через разработанный сервис.

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

Задача: обеспечить систему заказчика актуальной нормативной базой.

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

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

3. Ввести новый параметр для расчетных операций в системе.

Выполнение:

1) Определить точку «входа» параметра в Систему: вводится пользователем? Рассчитывается из других параметров (Каких? Каким образом? В какой момент времени?)?

2) Определить функции, в которых будет задействован новый параметр.

3) Для каждой функции: Проверить, влияет ли новый параметр на выполнение последующих операций, ввести параметр в формулы расчета.

4) Определить способ и место отображения параметра в интерфейсе. Нарисовать макеты.

5) Узнать, должен ли новый параметр фигурировать в выходных формах: в каких именно, каким образом.

6) На содержимое каких выходных форм этот параметр повлияет неявно? Если да, определить степень влияния, вынести вопрос на обсуждение.

7) Определить объем необходимых доработок.

8) Написать постановку задачи на разработку, либо ТЗ (в зависимости от объема доработки).

9) Протестировать результат.

Вопросы задала Эльмира Давыдова.

0 комментариев
Оценка: