Comments 13
Скажите пожалуйста, чем системный аналитик отличается от бизнес-аналитика?
Добрый день!
Ответим в разрезе финтеха:
Бизнес-аналитик исследует рыночные тренды, формирует требования к продукту и согласует их.
Системный аналитик проектирует техническую реализацию: разрабатывает схемы API для платежных шлюзов, настраивает интеграцию с процессинговыми системами или проектирует базы данных для обработки транзакций. BA отвечает за то, «что нужно бизнесу», а SA — за то, «как это реализовать технически».
Разве, последняя часть это не про архитектора?
Добрый день!
Отвечает автор статьи:
Не совсем. SA занимается технической реализацией на уровне проектирования интерфейсов, интеграций и структур данных — это ближе к аналитике, чем к архитектуре. Архитектор обычно выбирает технологии, определяет масштабируемость системы, стратегию развертывания и т. д. SA фокусируется на деталях, которые позволят реализовать требования, а архитектор — на том, как вся система будет работать в целом.
Но ведь в статье Вы общение с бизнесом отдали в руки SA, а не BA.
Одно дело, когда бизнес хочет кнопку или поле и точно знает что там будет, а вот когда бизнес хочет видеть баланс клиента или долг то нужен BA, который выяснит финансовое значение баланса или долга. Ещё интереснее, когда надо удалить что-то относящееся к счетам, то тут без юриста и бухгалтера и вовсе никак. А у вас это всё SA.
Добрый день!
Отвечает автор:
Действительно, в классическом понимании BA должен работать с бизнесом, чтобы выяснить суть требований, а SA — проектировать техническое решение. Однако в крупных компаниях (в частности, в "Совкомбанк Технологиях") процессы часто бывают гибкими: SA может получать требования как через BA, так и напрямую от бизнеса. Главное — чётко определять границы: если вопрос касается сложной бизнес-логики (расчёты, регуляторика), привлекаются BA или эксперты (юристы, бухгалтеры).
многих ошибок можно избежать, если ведется хорошая и подробная документация. Но очень подробная документация, как правило, сложна и не читабельна, да и писать её лень, поэтому на одни и те же грабли наступают вновь и вновь
Какое ТЗ - такое и ХЗ. Это рекальное искусство писать "понятные" ТЗ. И умение перевести с клиентского "я показал ваш скрипт тещё -её не прёт. Сделайта так. чтобы пёрло" многово стоит
Я думал работа аналитиков заключается в том чтобы говорить "Да, сделаем", по крайней мере так оно выглядет у нас в конторе
Спасибо за статью, вспомнил, кто такой этот ваш системный аналитик :)
Казалось бы ничего сложного в такой работе, но если учитывать все детали большой системы, то ... оказывается, что без аналитиков там невозможно
Почему-то начинающие аналитики напрочь забывают про два важных подэтапа:
Изучение нормативно-правовых актов в предметной области. Это помогает как возвращать на землю слишком витающих в облаках заказчиков, так и избегать тупых ошибок проектирования. Условно, если подрядчик хочет построить ТРЦ без лестниц и систем пожаротушения, именно аналитик должен ткнуть ему ШНК и СНИПы.
Изучение аналогичных продуктов. Успешные конкуренты помогут получить информацию о действующих BestPractice, "невзлетевшие" конкуренты - посоветуют грабли, на которые не стоит наступать
От «хочу» к ТЗ – как системный аналитик превращает хаос в чёткие требования