Анализ отличий в работе системного и бизнес-аналитика через призму процессного подхода
Всем привет!
Меня зовут Станислав, я работаю старшим системным аналитиком в отделе развития голосового антифрода.
Сейчас в мои задачи входит анализ и управление требованиями к веб-приложению для настройки проверок параметров вызовов. Помимо описания взаимодействия между front- и back- слоями, я взаимодействую со смежной командой для проработки интеграции между нашим приложением и модулем принятия решений по результатам проверки параметров вызовов.
Глядя на свою текущую работу и сравнивая её со своим опытом работы в бизнес-анализе, я замечаю много схожих подходов к исследованию и выявлению требований. Хочу поделиться с вами своими размышлениями на эту тему и буду рад обратной связи :)
Работа аналитика
«А ты кем работаешь? Аналитиком? А кто это?»
Пожалуй, примерно так звучат первые вопросы, когда после нового знакомства люди начинают узнавать тебя получше.
В чем вообще заключается работа аналитика? Зачем он нужен?
Как мне кажется, предназначение аналитика в поиске ответов на следующие вопросы:
Что нужно сделать?
Зачем это делать?
Как это сделать?
Попробуем по очереди ответить на эти вопросы с точки зрения бизнес- и системного аналитика.
Что нужно сделать?
Бизнес-аналитик | Системный аналитик |
Создать или оптимизировать процесс работы заказчика | Наладить взаимодействие между компонентами одной или нескольких информационных систем |
На первый взгляд задачи кажутся отличными друг от друга и расположены на разных уровнях представления.
Однако как аналитики будут подходить к её решению? Скорее всего, оба сформируют видение текущего состояния в виде модели AS IS (как есть) и определят, что вообще сейчас происходит в вверенной им области. Оба аналитика определят предварительные варианты решения и сформулируют одну или несколько моделей TO BE (как должно быть).
И оба создадут артефакт, который наглядно покажет, почему предлагаемое решение будет работать и как оно удовлетворит требования поставленной задачи. Это может быть диаграмма нового процесса или алгоритма взаимодействия (BPMN, UML (sequence или activity)) или документ с верхнеуровневыми требованиями к созданию нового или изменению текущего решения.
Зачем это делать?
Бизнес-аналитик | Системный аналитик |
Снизить расходы ресурсов, повысить качество результатов, ускорить выполнение задач | Расширить функциональность ИС, обогатить используемые данные |
Продолжим сравнение в работе специалистов анализа. Отвечая на заданный вопрос «Зачем?», аналитики должны учитывать, что, помимо решения задачи «в лоб», они не должны забывать о тех преимуществах, которые должно привнести разрабатываемое решение. В этих преимуществах должны будут найти отклик будущие нефункциональные требования.
Если бизнес-аналитик может работать с метриками процесса (количество привлекаемых сотрудников, скорость выполнения операций, количество ошибок), то системному аналитику будут ближе понятия производительности и отказоустойчивости системы (какое количество запросов может обработать система за единицу времени, каков максимальный объём обрабатываемого файла, согласованность передаваемых и ожидаемых параметров запросов).
Таким образом оба специалиста должны разрабатывать своё решение не только опираясь на выявленные ранее требования, но и учитывая ограничения, обусловленные бизнес-правилами или техническими возможностями, применяемых в компании.
Как это сделать?
Бизнес-аналитик | Системный аналитик |
Определить операции в процессе, которые необходимы для достижения требуемого эффекта | Определить точки интеграции, алгоритмы взаимодействия между ИС и их компонентами |
А вот на этом шаге у аналитиков есть возможность проявить весь свой творческий потенциал :) Вооружившись требованиями и балансируя их ограничениями, аналитик может приступать к детальной проработке решения. В ходе этого процесса аналитик может пройти через следующие этапы:
Коммуникации с заинтересованными лицами
Заказчики, эксперты, пользователи, архитекторы, разработчики, тестировщики являются одним из основных источников сведений, которые аналитики используют в своей работе. И что бизнес-аналитик, что его системный коллега по анализу должны применять соответствующие инструменты, для работы с этим источником — интервью, опросы, мозговые штурмы.
Анализ текущих документов/регламентов/протоколов взаимодействия
Может стать неплохим источником сведений, из которых аналитики могут почерпнуть информацию. Однако, к сожалению, не на всех проектах уделяют должное внимание поддержанию актуальности подобных артефактов…
Формализация требований
Данный этап определяется устоявшимися в компании/проекте подходами и шаблонами к оформлению. Где-то достаточно описать полностью описать User Story в трекере задач, где-то написать статью в местной базе знаний, а кому-то не обойтись без оформления документации по ГОСТ (19 или 34 группы) и пройтись по всем кругам согласования.
Управление требованиями (изменения)
Самое любимое, да) Кому не приходилось менять требования по ходу работы над задачей, тот очень большой везунчик. К счастью или нет, но большинству специалистов приходится сталкиваться с внесением изменений в требования к разрабатываемому решению. Из-за этого аналитикам приходится заново сверять ожидаемые результаты с теми изменениями, которые пришли в ходе анализа. И системному, и бизнес-аналитику нужно хорошо владеть навыками управления требованиями: вести версионность артефактов, поддерживать трассировку требований на всех уровнях декомпозиции, отслеживать, какие изменения только ждут своей очереди, какие ушли разработчикам в реализацию, а с какими пришли тестировщики за консультацией.
Вместо заключения
В этой небольшой статье мне хотелось показать, что в работе таких, на первый взгляд, разных специалистов как системный и бизнес-аналитик есть много общего. Мои предположения подтверждает и опыт собеседований, которые я проводил — откликаясь на одну и ту же вакансию системного аналитика, люди имели за своими плечами разнообразный опыт, который в равной степени коррелировал как с задачами бизнес-анализа, так и с задачами системного аналитика.
С другой стороны, командам/проектам могут требоваться как более технически подготовленные специалисты, которые могут и требования собрать, и код по ним написать, так и более погруженные в конкретный бизнес-домен, чтобы переводить потребности заказчика на более понятный коллегам технический или даже общепринятый язык.
В любом случае, аналитик — это в первую очередь профессионал, который знает, что, зачем и как реализовано в рассматриваемом решении. Специализация определяет лишь уровень декомпозиции, на котором он сможет дать вам более развёрнутый ответ на поставленные вопросы.
И помните, аналитик — это не просто профессия или роль, это состояние души и организация мыслей. С таким подходом и жизнь становится понятнее, и работать интереснее.
