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