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