Комментарии 22
Вроде написано разбираем системного аналитика и опять все в кучу... Вода по другим ролям, BPMN-схемы, которые должен составлять БА, Активити, примера которой нет (как и упоминания про UML) и в скиллах "проектирование БД", которого тут на самом деле тоже нет (вы просто описали класс счета, причем в контексте ответа API, бд проектируется не так).
"В большинстве компаний задачи бизнес-анализа и системного анализа выполняют разные специалисты, но в моей компании это делает один человек." - вы за границей где-то работали, раз для вас в большинстве компаний это разные люди? Для российского ИТ очень характерно непонимание разделения БА и СА, поэтому это в 90% случаев совмещаемые роли.
Однажды, я встречу хорошую статью про SA.
I want to believe.
Только меня смутило 12 мест работы за 10 лет? Это нормально?
Выглядит немного не раскрыто. Сам я работаю так же системным аналитиком и хотел бы подсветить пару моментов:
1. Например проектирование БД включает в себя не только проектирование схемы, а так же продумывание необходимых индексов, прикидывания какие данные будут лежать и сколько, иногда вплоть до продумывания оптимального SQL запроса для каких-либо операций.
2. Проектирование API почему-то сразу рассматривается REST, а не рассматриваются разные варианты в рамках задачи. Почему REST для чата с ботом, а как подгружать новые сообщения от бота? Еще кажется плохое решение передавать userId в квери параметре, который никак маскироваться не будет)
3. Ну и еще куча есть стадий, например какие инструменты использовать, нужен ли КЭШ и где, в каком виде хранить, как инвалидировать, какие узкие места, как от них защищаться, например если пользователь начнет кликать 100500 раз, какие ошибки запрос должен возвращать.
Индексы, оптимизация SQL запросов - все это ложится на СА в силу каких обстоятельств?
Предположу, что команда небольшая и в ней нет отдельного архитектора или DBA?
"Еще кажется плохое решение передавать userId в квери параметре, который никак маскироваться не будет)" - соглашусь, тоже показалось странным...
Как вариант:
GET /users/{id}
Если очень хочется ходить в accounts, то GET /accounts/{id-account}
Просто странно, что в сущности account идентификатор записи user_id
Я работаю в финтехе, и тут dbaна каждую команду конечно нет, но есть отделы dba на бизнес линию. Привлекать их к простым задачам смысла нет. Тут речь о простых индексах, которые перестраиваются при вставке данных в бд. Dba же привлекают когда индексы огромные, нужно настроить процессы пересоздания и вакуумирования индексов.
Насчёт оптимизации, это скорее к тому, чтобы понимать, что предлагаемое аналитиком решение может работать и работать быстро.
Вот-вот, надо ещё думать - а нужно ли синхронно взаимодействие, может тут надо асинхронное через Кафку
В системном анализе ключевой навык - умение логически мыслить и лаконично излагать свои мысли.
А еще быстро разбираться в непонятных вещах, находя и усваивая большие объемы информации за короткое время.
Можно научиться рисовать схемки в разных нотациях, научиться классы какие-то составлять, можно даже спеки на oa3.1, gRPS и graphQL делать... И при этом быть так себе аналитиком, потому что вот не дается человеку быстро думать и понимать, когда и как все эти навыки применять правильно. Вот в этом кстати кроется сложность обучения новых кадров. Я всегда говорю ребятам, что я могу им что-то объяснить, но я не могу за них это понять.
Не должен системный аналитик проектировать ни бд, ни эндпоинты. Если в вашей компании это называется анализом - грош цена такому анализу.
Смысл системного анализа корректно составить функциональные требования и выяснить узкие места. Например необходимые интеграции, правила обработки данных. Разработчики уж как-нибудь сами разберутся как им гонять данные и куда их складывать.
Фактически в российском ИТ эта должность повсеместно не нужна. Нет в банках в рядовых командах таких процессов что требуют глубокого анализа. Зачастую это просто должность, которая плодит тонны документации устаревающей быстрее чем она пишется и при этом не помогает пониманию работы системы.
Есть какие то аргументы почему системный аналитик не должен этого делать?
У меня вот есть почему должен
Уменьшение тайм ту маркет, разработчик делает задачу меньше т.к. она уже запроектирована, задачи декомпозированы, их можно брать параллельно
У аналитика чаще всего больше бизнес контекста, понимая бизнес домен, проще понимать как хранить данные, что ещё рядом с ними может лечь в будущем
Реализация документируется, да! любой человек может придти и глянуть, а чё эндпоинт делает, что у него под коробкой, где в базе данные искать, выгружается ли это потом в olap. Если задачи проходят через аналитика, то документация устаревать не будет
Нет такой кореляции. Проектирование эндпоинтов дело 2х минут, если это все равно будет отображаться в условном swagger - тащить дубликат в confluence не имеет смысла.
Я не понимаю, вы про бизнес аналитика или про системного? Очень странно что в кросс-функциональных бизнес командах контекст есть только у одного лица. В гибких методологиях весь упор ставиться что бизнес-ценность доносится командой, а не конкретной ролью.
olap не выгружается в рамках бизнес-процесса, это единожды стандартизированный процесс, кроме того это не мешает отразить такое в требованиях. Мы, все же работаем с OLTP данными, не надо смешивать их в одном контексте. Разработчик может в базе распологать данные так, как его душе требуется и зачастую это связанно с особенностями хранения + реализации.
Моя точка зрения в том, что аналитик - переходное звено в PO или SA. Ни тот, ни другой не заправляет реализацией. Ценность разработчика не в знании очередного фреймворка, а в том, что на своей стороне он корректно реализует бизнес-требования и они будут отвечать требованиям надежность, масштабированию и сопровождению. Если для поддержания масштабирования нам надо складывать данные иначе, чем нафантазировал аналитик - так тому и быть.
Дело двух минут когда сразу понятно, что надо. Swagger не даёт всех описаний, ограничений по rps и т.д. в конфле ты можешь зафиксировать любую информацию, которую вас постоянно спрашивают при желании интегрироваться. И да бывает не только rest. Kafka, jrpc, graphQl и т.д.
Нет ни у одного человека весь контекст, но весь контекст разработчику передавать, проще его на все встречи таскать, тогда он будет сидеть на созвонах, которые он так не любит
В рамках бизнес процесса могут появляться новые данные. Новые данные - новая отгрузка, нужно понимать что должно отливаться, чтобы не занимать лишнее место в хранилищах, поэтому процесс меняется.
Я считаю, что системный аналитик не должен проектировать реализацию, потому что его сила не в этом.
Возьмем гипотетическую задачу. Мы хотим автоматически оплачивать налоги по вкладам конце года. И в этой задаче есть большая аналитическая часть: надо понять как считать налоги, куда отправлять, какие коды и поля надо заполнять чтобы налоговая приняла такой платеж.
В вашей ситуации, аналитик должен потратить львиную долю времени на проектирование базы, эндпоинтов и контрактов и, если я правильно понял, еще потратить время на все то, что я описал выше. И это еще должно как то повысить TTM, но абсолютно непонятно как это должно быть сделано.
В моем же случае, аналитик занимается той частью, которую разработчик физически выполнить не может. Ну не может он ходить и собирать информацию о том, какие там поля в формуляре надо заполнять. Но разработчик может почти бесплатно спроектировать БД и API, ведь ему это ничего не стоит. Он все равно будет это делать.
Как раз аналитик смотрит, что нужно сделать, чтобы отправить данные о налогах и описывает это в формате контрактов, схемы бд, диаграмм и прочего. Если этого не будет делать аналитик, то кто?
Ттм сокращается за счёт того, что аналитик начинает работу над проектом первым. Когда разработчики делают одни задачи, аналитик работает уже над другой, формируя беклог. Разработчики в свою очередь не тратят львиную долю времени, чтобы превратить бт в схемы и контракты
Правильно ли я понимаю, что в таком случае разработчик просто пишет код и ничего более? Получается ему не требуется погружаться в контекст, а нужно просто реализовать написанное в документации?
У меня, в двух компаниях была такая штука как груминг, это встреча где аналитик погружает всю команду в контекст, показывает задачи, по каждой задаче описание и документацию. Разработчики получаю минимально контекст, могут задать вопросы, и если им не нравится то, как что-то спроектировано они могут на это указать
Как удобно говорить от своего имени за всю ИТ индустрию в стране!
Работа с требованиями важная, но далеко не единственная деятельность аналитика.
Советую хотя бы ознакомиться с Профстандартом на специальность "Системный аналитик", где значительная доля обязанностей аналитика связана с проектированием системы.
Тогда разработчик это просто перекладыватель фантазий аналитика в код? Не проще ли написать транслятор с аналитического в какой-нибудь верхнеуровневый язык, кроме того этих языков у аналитиков весьма много. Заодно можете соотнести с профстандартом который непонятно как вообще был приплетен к разговору.
Ну-ну, разработчик разберется. Слышал я такое уже где-то. Спойлер - нет, не разберется. Образованность нынешних разработчиков, в среднем по палате, под очень большим вопросом во всем, что касается архитектуры, проектирования и алгоритмизации. Они и код-то написать нормально не могут, а думать головой вообще за гранью их компетенции.
То, что конкретно вам, якобы, аналитик не нужен, это ни что иное, как всего лишь ошибка выжившего. Ничего больше.
Чем занимается системный аналитик: разбираем на примере