Ответ на пост «Чем занимается системный аналитик»⁠⁠1

Не умаляю опыта ТС, но у нас опыт системного аналитика отличается. Не смогла пройти мимо.

Чем занимается системный аналитик кхд.

Пришла задача.

Примеры задач из опыта:

1)Псевдопростые. Например, добавить новый признак, по которому сможем отделять, ну пусть ипотеку от остальных кредитов. Или - из-за добавления нового тарифа изменить алгоритм расчёта таким-то образом.

Псевдопростые - т.к. на первый взгляд кажется всё очевидным (и иногда это действительно так. А иногда - открывается бездна)

2)Обобщённые. Всё упало, ничего не работает - спасай!!!

3)Рефакторинг. Перенос ранее реализованной логики на другую систему с другой архитектурой и зачастую - источниками данных. Но чтоб всё для конечных пользователей продолжало работать как раньше.

Обсуждение с заказчиком

В целом согласна с ТС в части простых задач.

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

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

Документация

ТС почему-то скромно умолчал о том, что основная часть времени уходит на работу с документацией. Составление документации по проводимым доработкам. Изучение документации с целью понять "что это должно было быть и как это должно было работать".

Сюда же согласования.

Их много. Подготовлена документация по функциональным требованиям? Согласовываем. Приёмо-сдаточнве испытания. И т.д.

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

Проработка архитектуры

Понятно, что речь не глобально об архитектуре всей системы - но той маленькой части, с которой работаешь. Любую задачу можно решить несколькими способами. Выбор оптимального - задача аналитика.

Регламенты

Речь про регламентв взаимодействия с другими объектами. Например, известно что на основе вашей витрины в полночь строится отчётность, что уходит бизнес-пользователям. И если вы поставите старт расчёта такой витрины на час ночи... будет упс.

Сюда же про историзацию данных, глубину хранения, запланированное время актуальности данных (обычно Т-1 или Т-2, то есть полные данные сегодня видим - только за вчера или за позавчера соответственно). И если некорректно настроить регламент забора данных - потеряем ещё день актуальности.

Составление прототипа

Далее аналитик садится и пишет код. Да, обычно это что-то относительно корявое, но - работающее и выдающее в ответ какие-то похожие на правду данные. В зависимости от задачи - на этом этапе может начаться активная сверка с эталоном (в случае рефакторинга). Впрочем, если бизнес готов предоставить вариант того, что он хочет видеть в итоге (что бывает при автоматизации каких-то полуручных в прошлом расчётов), то тоже можно сверить. Или можно сделать скриптом выгрузку и пообщаться с бизнесом - насколько это похоже на то, что они хотят видеть.

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

Передача в разработку.

Если всё хорошо, то подробное описание + прототип передаётся разработчику. Тот это всё красиво оформляет патчом, причёсывает код, оптимизирует, передаёт в установку на прод.

Про 60% времени... На прошлом месте работы 70-80% времени была документация и согласования. На текущем месте работы, где есть отдельный бизнес-аналитик - непосредственно анализ (то есть продумывание архитектуры, поиск почему данные не сходятся с последующим исправлением, работа с кодом - разбор чужого, написание прототипов).

По сути по линейке разработчик - системный аналитик - бизнес-аналитик - проджект менеджер сдвинулась ближе к разработчику, мне так комфортнее.