Ответ на пост «Чем занимается системный аналитик»
Не умаляю опыта ТС, но у нас опыт системного аналитика отличается. Не смогла пройти мимо.
Чем занимается системный аналитик кхд.
Пришла задача.
Примеры задач из опыта:
1)Псевдопростые. Например, добавить новый признак, по которому сможем отделять, ну пусть ипотеку от остальных кредитов. Или - из-за добавления нового тарифа изменить алгоритм расчёта таким-то образом.
Псевдопростые - т.к. на первый взгляд кажется всё очевидным (и иногда это действительно так. А иногда - открывается бездна)
2)Обобщённые. Всё упало, ничего не работает - спасай!!!
3)Рефакторинг. Перенос ранее реализованной логики на другую систему с другой архитектурой и зачастую - источниками данных. Но чтоб всё для конечных пользователей продолжало работать как раньше.
Обсуждение с заказчиком
В целом согласна с ТС в части простых задач.
Отдельный ад - это рефакторинг. Бизнес-пользователи обычно максимально саботируют процесс так как их и так всё устраивает, а то что старую систему через два месяца отключат - их не волнует.
Сильно помогает наличие отдельного бизнес-аналитика - на него вот эту всю рутину взаимодействия с бизнесом можно переложить. Понятно, что периодичечки всё равно нужно лично участвовать во встречах для обсуждения вопросов конкретной реализации. Но это уже другое.
Документация
ТС почему-то скромно умолчал о том, что основная часть времени уходит на работу с документацией. Составление документации по проводимым доработкам. Изучение документации с целью понять "что это должно было быть и как это должно было работать".
Сюда же согласования.
Их много. Подготовлена документация по функциональным требованиям? Согласовываем. Приёмо-сдаточнве испытания. И т.д.
Сюда же изучение чужого кода в попытках понять что это такое, как с этим работать и не упадёт ли что-то после нашей доработки (эх, регресс-анализ...)
Проработка архитектуры
Понятно, что речь не глобально об архитектуре всей системы - но той маленькой части, с которой работаешь. Любую задачу можно решить несколькими способами. Выбор оптимального - задача аналитика.
Регламенты
Речь про регламентв взаимодействия с другими объектами. Например, известно что на основе вашей витрины в полночь строится отчётность, что уходит бизнес-пользователям. И если вы поставите старт расчёта такой витрины на час ночи... будет упс.
Сюда же про историзацию данных, глубину хранения, запланированное время актуальности данных (обычно Т-1 или Т-2, то есть полные данные сегодня видим - только за вчера или за позавчера соответственно). И если некорректно настроить регламент забора данных - потеряем ещё день актуальности.
Составление прототипа
Далее аналитик садится и пишет код. Да, обычно это что-то относительно корявое, но - работающее и выдающее в ответ какие-то похожие на правду данные. В зависимости от задачи - на этом этапе может начаться активная сверка с эталоном (в случае рефакторинга). Впрочем, если бизнес готов предоставить вариант того, что он хочет видеть в итоге (что бывает при автоматизации каких-то полуручных в прошлом расчётов), то тоже можно сверить. Или можно сделать скриптом выгрузку и пообщаться с бизнесом - насколько это похоже на то, что они хотят видеть.
На этом этапе любые изменения/доработки - дешёвая вещь, так как реализация пока только в виде скрипта. И лучше на этом этапе понять, что мы движемся куда-то не туда, чем потом переделывать всё.
Передача в разработку.
Если всё хорошо, то подробное описание + прототип передаётся разработчику. Тот это всё красиво оформляет патчом, причёсывает код, оптимизирует, передаёт в установку на прод.
Про 60% времени... На прошлом месте работы 70-80% времени была документация и согласования. На текущем месте работы, где есть отдельный бизнес-аналитик - непосредственно анализ (то есть продумывание архитектуры, поиск почему данные не сходятся с последующим исправлением, работа с кодом - разбор чужого, написание прототипов).
По сути по линейке разработчик - системный аналитик - бизнес-аналитик - проджект менеджер сдвинулась ближе к разработчику, мне так комфортнее.
