Комментарии 11
Мне кажется, по моему скромному опыту, что бизнес нужен там где:"а давайте придумаем что-то новенькое". А системщик: "ребят а давайте посмотрим, куда это можно впихнуть" Но в целом Имхо разница размывается.
Спасибо за краткое изложение, но у меня повились вопросы.
Логичнее располагать вопросы аналтика иерархично. Первым напрашивается "Зачем?"
"Зачем это делать?" для СА - расширить функциональность?
Если у нас есть БА, то не могу представить для СА такой формулировки.
Результат БА - артефакты в виде описанных конкретных целей бизнеса и способа их достижения бизнесом - бизнес-процесс. БА говорит, что делать с бизнес-функциональностью (создать/изменить/убить, не "расширить/уменьшить").
Тогда зачем это делать СА? Чтобы заработать денег - какой вопрос, такой и ответ, потому что вопрос должен указывать на объект, а не на субъект; например, Что должен достичь СА? достичь (описанных БА) конкретных целей системы.
Благодарю за отзыв и вопросы:)
1. На счёт иерархии вопросов - я отталкивался от того, что аналитикам ставят задачи в стиле "Мы хотим..." или "Нам нужно...". То есть аналитик работает с более менее сформулированной потребностью "Что нужно сделать?" и потом уже включает весь свой профессионализм и выясняет "Зачем?":)
2. Вы верно подметили, что объектом для БА является процесс и его элементы, которые позволят достичь поставленные бизнесом цели.
Под "расширением" я подразумевал, что в зону ответственности СА входит добавление/изменение возможностей в работе ИС.
На уровне БА нет данных, например, о применяемых протоколах связи или используемых файловых хранилищах. БА может поставить требования вида "Направить договор в соседний отдел через e-mail".
Когда СА будет анализировать это требование, он наверняка запросит пример договора и получит pdf-файл на 100Мб и спросит "А зачем нам отправлять такой большой файл именно по электронной почте? Может быть положить его в облачное хранилище?"
И отсюда может быть несколько путей развития ИС:
1. Увеличить максимальный размер обрабатываемых файлов на почтовом сервере;
2. Создать новое облачное хранилище с разграничениями прав доступа и скачивания файлов;
3. Разработать сервис с web-интерфейсом для отображения содержимого договора и возможностью его подписать или отправить на доработку.
Поэтому мне кажется, что системному аналитику тоже полезно задавать вопросы о целях той или иной доработки. Это поможет поддерживать связь между уровнями абстракции требований и предложить более качественное решение задачи:)
Задача БА - выявить цель бизнеса, когда к нему прикатывает "Мы хотим". И только потом работать с требованиями по реальным целям.
Поэтому приведённый пример с БА - это плохой БА.
БА - это не передачтик между бизнесом и командой разработки. Прежде чем выкатывать требования, БА должен прогнать их по критериям. И тогда автоматом не будет этого примера.
Ок, допустим, БА промахнулся с договором через e-mail.
Но дальше, если возможные решения напрямую затрагивают бизнес-процессы, то это уже вне работы СА.
То, что описано в примере, обсуждается на этапе принятия решений по бизнес-процессам (см. выше, это я уже повторяюсь). И в данном случае СА это должен вернуть взад БА, чтоб тот почесал затылок и провернул ещё одну итерацию с бизнесом и командой
Да, этому бизнес-аналитику ещё есть чему поучиться ?
Тем положительнее, как мне кажется, оказался эффект от заинтересованности системного аналитика в целях поставленной задачи. И у обоих специалистов появились точки для своего дальнейшего развития.
Думаю, здесь сработали бы иные механизмы для разрешения подобной ситуации и у ребят получилось спроектировать более грамотное и согласованное решение ?
Хорошая статья. Задачи системного и бизнес-аналитиков тесно пересекаются и часто в вакансиях компаний в требования к системному аналитику включают требования бизнес-аналитика и наоборот.
Приведите пример пересечения задач СА и БА
Не думаю, что у этих ролей есть пересечения именно на уровне задач:)
В статье я размышлял именно о подходах в решении задач - какие шаги и умозаключения объединяют эти специальности.
Могу предположить, что ситуации с пересечением возникают в ситуациях, когда в команде или на проекте нет выделенных ролей БА и СА. Поэтому на всех уровнях анализа приходится работать одному человеку.
Или в команде нет выделенного дизайнера UI - тогда и БА и СА могут взять на себя роль по прототипированию макетов пользовательского интерфейса на основании требований.
Помните "Люди в черном 2"?
Бизнес-аналитику все равно, кто сидит под столом и сортирует письма.
А системному нет! :)
Выражение "Нет человека - нет проблемы" в 21 века приобретает совсем другой смысл.
Поэтому первый вопрос "Чья проблема?
Очевидно, что 2 вопрос:" В чем суть проблемы? "
3 вопрос:" Почему проблема возникла? "
И вот только теперь" Зачем решать проблему? Что сделать? И как это сделать?"
Анализ отличий в работе системного и бизнес-аналитика через призму процессного подхода