Комментарии 14
Прекрасное
Супер, видно что писал человек, который реально работал, а не условный джун, начитавшийся интерента
--------------
Хотя, я как архитектор, могу описать проблему проще (наверное). В более-менее большой команде просто часто есть смежные области, которые вроде бы покрыты, а в реале - нет. Поэтому часто вы - это тот, кто просто закрывает эти gaps и все. И где они в конкретном проекте - не важно
С одной стороны сложно - с другой, со временем вас начнуть ценить именно за это. Но можно этого и не делать. Но так неинтересно :)
Два возражения:
1. Контексты в общем случае пересекают системы вложенные в другой контекст, случай когда там только апи торчит - идеален.
2.Ирония насчет того что смежники не пересекают свои компетенции довольно смешная, обычно пересекают, САшки тут не единственные мученики, причем случай когда это прям для всех так это опять-таки идеал. Максимальная ответственность падает на самого ответственного и это было и будет.
Ценные знания, спасибо что делитесь
Вижу в начале статьи, что много требований к системному аналитику пересекаются с требованиями к архитектору. То есть знание того как устроена система, какие есть связи, как сделать оптимальное решение ввиду всего этого. И также состав ваших команд не предполагает наличие архитектора либо вы его оставили за скобками.
Как вы считаете чем бы вам тогда помог архитектор и кто сейчас выполняет его роль?
Привет!
По моему скромному мнению, архитектор отвечает за проектирование системы. Так сказать, за активную фазу (создать что-то с нуля, будь то вся система или её новая часть). Здесь же и про выбор конкретного стека технологий и паттернов.
А САн уже работает с тем, что есть: имеет в голове архитектуру и может оценить как впишутся конкретные доработки и в каких местах могут быть проблемы.
Грань тут тонка и, как писали выше, ответственность на себя возьмёт самый ответственный :)
Но при наличии выделенного архитектора команде не приходится играть в чехарду и постоянно подстраиваться под реализацию (когда, например, бэк сделал модели и контроллеры API, фронт в это время накидал формы и свои модели - а только потом они согласовывают результаты).
Надо как-то эту статью на стол начальству подложить))
Спасибо за статью! Очень живая, видно, что инфа "с полей"
Прекрасная, прекрасная статья.А теперь открываем вакансии САнов финтеха...
Достаточно часто меня туда хантят, а я чот не иду )
Спасибо за статью. Очень своевременно появилась)
Если будет возможность раскройте пожалуйста:
Построение дашбордов и Оптимизацию процессов.
На каком этапе выпуска ПО появляются такие задачи? Какие артефакты являются результатом? Как использует сам Системный аналитик и команда? Кто потребители?
Рад слышать :)
Про дашборды и процессы всё довольно творчески получается, ниже распишу ориентиры (как сам видел, у всех опыт, конечно, разный).
Дашборды
* В рамках статьи подразумеваю, что речь про внутренние (продуктовые) дашборды, а не про непосредственную бизнес-фичу продукта для конечных пользователей.
Появляются тогда, когда есть данные - как правило, это логи (операций, ошибок, сессий и т.д.). Т.е. раньше какого-либо функционала, который генерирует эти данные дашбордов нет.
Возможные причины появления дашбордов (равно сбора метрик продукта):
- анализ ошибок (как количественный, так и качественный)
- поиск узких мест обработки данных
- сбор статистики для прощупывания будущего функционала
- и т.д. и т.п.
Артефактами являются либо таблицы, либо графики. Удобно работать с интерактивными представлениями, например, в Grafana. Но также могут быть более специализированные BI-инструменты.
Про то, как используются дашборды, думаю, понятно из примеров причин чуть выше :)
А использовать могут и PM, и сами аналитики, и QA (проверка результатов), и разработка (отладка логики ПО), и DevOps (нагрузка и балансировка) - в общем всё зависит от конкретной задачи, по которой строятся дашборды. Хотя в первую очередь на них смотрят PM и аналитик, чтобы дальше уже ставить задачи.
---
Оптимизация процессов
А это уже так чётко не опишешь. Суть в том, чтобы, видя узкие места, поднимать вопросы по их устранению. Такой скилл сильно зависит от междисциплинарного опыта и личной ответственности.
Пара примеров:
1. Во время работы по инцидентам (когда обкатывали новую фичу) аналитик работал с логами и осознал, что они слабо структурированы и не покрывают критические моменты обработки. После выполнения работы по анализу (если текущих логов с горем по полам хватает) он поднимает вопрос в команде о более полезных логах, предлагает их формат или описывает ключевые точки и требуемую информацию.
2. Аналитик работает над задачей, связанной с хранилищем данных, получаемых от внешней системы. Данные мы получаем в CSV и очевидно внутри нашего хранилища дублируем структуру входных файлов. При этом в дорожной карте есть задача на замену источника этих данных другой системой. И аналитик понимает, что если сейчас не абстрагировать формат данных, то потом всем придётся держать в уме довольно странные маппинги, которые остались из-за формата данных уже не поддерживаемого (почему мы на вход получаем поле title, а в БД храним его как category?).
3. Ну и пример попроще и больнее: в вики-системе нет структуры и тяжело что-то найти и актуализировать...
4. Также, встречаются ситуации, в которых нет либо чёткого жизненного цикла задачи (со статусной моделью и ответственными за конкретные этапы), либо нет шаблонов самих задач (я говорю про банальные 3-4 пункта типа Сроки, Критичность, На что влияет, Контактное лицо). И тут аналитик вполне имеет право добавить в работу команды немного... системности (:
Довольно хорошо разграничено, но на практике нигде не видел соблюдения хотя бы примерно в этих рамках.
А сейчас мне свезло так, что я устроился в организацию, которая выкупила продукт у другой компании. Документации по ней почти нет (фигак-фигак и в прод). При этом я как СА должен как-то клещами вытащить инфо из их архитектора, который готов общаться только голосом час в неделю. И доступ в их api, код и БД у меня конечно же отсуствует. Дико было увидеть такое в компании федерального уровня, но вот так. И заранее об этом конечно же не сказали.
Разделяю вашу боль, был подобный опыт.
Хотя с доступами мне везло, конечно, больше. Но и они не всегда могут помочь, тем более когда утеряны знания по тому, как и почему всё устроено.
Не могу посоветовать что-то конкретное, но часто можно обернуть ситуацию в пользу прокачки каких-либо своих скиллов. Всё дело в балансе и получаемой ценности.
Как системному аналитику не делать чужую работу