Search
Write a publication
Pull to refresh

Comments 13

Скажите пожалуйста, чем системный аналитик отличается от бизнес-аналитика?

Добрый день!

Ответим в разрезе финтеха:

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

Системный аналитик проектирует техническую реализацию: разрабатывает схемы API для платежных шлюзов, настраивает интеграцию с процессинговыми системами или проектирует базы данных для обработки транзакций. BA отвечает за то, «что нужно бизнесу», а SA — за то, «как это реализовать технически».

Разве, последняя часть это не про архитектора?

Добрый день!

Отвечает автор статьи:

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

Но ведь в статье Вы общение с бизнесом отдали в руки SA, а не BA.

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

Добрый день!

Отвечает автор:

Действительно, в классическом понимании BA должен работать с бизнесом, чтобы выяснить суть требований, а SA — проектировать техническое решение. Однако в крупных компаниях (в частности, в "Совкомбанк Технологиях") процессы часто бывают гибкими: SA может получать требования как через BA, так и напрямую от бизнеса. Главное — чётко определять границы: если вопрос касается сложной бизнес-логики (расчёты, регуляторика), привлекаются BA или эксперты (юристы, бухгалтеры).

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

Какое ТЗ - такое и ХЗ. Это рекальное искусство писать "понятные" ТЗ. И умение перевести с клиентского "я показал ваш скрипт тещё -её не прёт. Сделайта так. чтобы пёрло" многово стоит

Я думал работа аналитиков заключается в том чтобы говорить "Да, сделаем", по крайней мере так оно выглядет у нас в конторе

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

Добрый день! Рады, что вам понравилось!) Солидарны - без аналитиков никак!

Почему-то начинающие аналитики напрочь забывают про два важных подэтапа:

  1. Изучение нормативно-правовых актов в предметной области. Это помогает как возвращать на землю слишком витающих в облаках заказчиков, так и избегать тупых ошибок проектирования. Условно, если подрядчик хочет построить ТРЦ без лестниц и систем пожаротушения, именно аналитик должен ткнуть ему ШНК и СНИПы.

  2. Изучение аналогичных продуктов. Успешные конкуренты помогут получить информацию о действующих BestPractice, "невзлетевшие" конкуренты - посоветуют грабли, на которые не стоит наступать

Sign up to leave a comment.