Субъективный рейтинг: 10 самых часто встречающихся ошибок аналитика при написании требований

⏳ 8 мин | 🟤⚪️⚪️

Перейти | BA|SA

RabbitMQ для аналитика: практический ликбез

⏳ 13 мин | 🟤🟤⚪️

Перейти | BA|SA

НФТ к производительности: расчет нагрузки в rps на практическом примере

⏳ 7 мин | 🟤⚪️⚪️

Перейти | BA|SA

Конвейеры данных (Data Pipelines) — это автоматизированные процессы сбора, обработки, преобразования и перемещения данных из различных источников в целевые хранилища (например, базы данных, DWH, озёра данных).

❓У вас может появится вопрос «Зачем знать аналитику?»

1. Понимание данных — чтобы разбираться, откуда берутся данные, как они очищаются и преобразуются.

2. Качество данных — чтобы выявлять и исправлять ошибки на этапе ETL/ELT.

3. Оптимизация запросов — чтобы писать эффективные SQL-запросы, зная, как данные подготовлены.

4. Автоматизация отчётов — чтобы настраивать регулярные выгрузки и дашборды.

5. Взаимодействие с инженерами — чтобы грамотно ставить задачи по доработке пайплайнов.

🤔 Нужно ли углубляться в тему или поверхностно знать основы?

- Да, если аналитик работает с Big Data или участвует в построении аналитической инфраструктуры.

- Нет, если роль ограничена готовыми данными в BI-инструментах, но базовое понимание всё равно полезно.

📎 Так же прикрепляю статьи на данную тему:

- Что такое конвейер данных? И почему вы должны это знать
- Конвейер данных и конвейер ETL: в чем разница?
- Как построить конвейер данных: пошаговое руководство

Источник: @ba_and_sa

Архитектура проекта автоматического обучения ML-моделей

⏳ 11 мин | 🟤🟤⚪️

Перейти | BA|SA

Архитектурные паттерны для высокой масштабируемости. Часть 3

⏳ 9 мин | 🟤🟤⚪️

“Разберем бизнес кейсы ближе к e-commerce, banking. Рассматриваем только data-bounded приложения, т.е. 90% случаев.”

Перейти | BA|SA

Прошлые статьи:

Часть 1
Часть 2

Пример проектирования, ориентированного на домен: От хаоса к чистой архитектуре

⏳ 14 мин | 🟤🟤⚪️

Перейти | BA|SA

Качество требований в IT-проектах

⏳ 8 мин | 🟤⚪️⚪️

Перейти | BA|SA

Тяжёлая артиллерия в оценке сроков задач

⏳ 12 мин | 🟤🟤⚪️

Перейти | BA|SA

Как аналитику развить устойчивость и не стать мизантропом

⏳ 4 мин | 🟡⚪️⚪️

Читать статью | Analyst IT

Рекомендации по сбору и приоритизации требований для бизнес-аналитика

⏳ 6 мин | 🟤🟤⚪️

Перейти | BA|SA

ACID, BASE, CAP: Фундамент архитектуры распределенных систем

⏳ 7 мин | 🟤🟤⚪️

Перейти | BA|SA

Почему сотрудники плохо работают: новый взгляд на бизнес-процессы

⏳ 6 мин | 🟤⚪️⚪️

Перейти | BA|SA

AI в работе технического писателя

⏳ 4 мин | 🟤🟤⚪️

Перейти | BA|SA

BPMN умер, все сделает ИИ

⏳ 4 мин | 🟤⚪️⚪️

Перейти | BA|SA

Салют! Праздники закончились пора возвращаться в строй! И решила разобрать часть вопросов, которые поступили мне в личку и в комменты под моим постом ☺️

Начнем с вечно волнующей темой аналитиков: «Как работать со стейкхолдерами, которые "уходят в тень"?

Ситуация от подписчика (написала в личку):
Есть процесс, который нужно автоматизировать и улучшить (добавить прогнозирование, фичи для управленческих решений). Есть несколько ключевых стейкхолдеров:
- А — главные по процессу (по регламенту), но избегают вовлечения, не объясняют логику решений.
- Б, В — помогают, согласовывают.
- Г — ключевой внешний пользователь.

Проблема: А игнорирует обсуждения, не аргументирует свои решения, а без них сложно проектировать систему.

Предистория:

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

❓Что делать? (Или чтобы я посоветовала)

1. Разобраться в мотивах "ухода в тень"
Почему А не хочет участвовать? Возможные причины:
- Не видят ценности ("и так работает, зачем менять?").
- Боятся изменений (автоматизация = потеря контроля, прозрачность решений).
- Нет времени/ресурсов (воспринимают как дополнительную нагрузку).
- Политика ("если раскроем логику, нас загрузят еще больше").

Как проверить?
- Задать косвенные вопросы:
- "Какие боли у вас в этом процессе?"
- "Если бы можно было изменить одну вещь — что бы выбрали?"
- Поговорить с Б и В — возможно, они знают подводные камни.

2. Снижать сопротивление через выгоды
Люди не против изменений — они против невыгодных им изменений.

Как "продать" проект отделу А?
- Связать с их KPI (если автоматизация сократит их рутину или снизит риски). Нужно это показать!
- Дать почувствовать контроль (например, через промежуточные согласования).
- Создать "пилот" (не всю систему, а прототип для части процесса и заинтересовать стейкхолдера).

3. Работать через других
Если А блокирует процесс, но Б и В лояльны:
- Формализовать требования через них (возможно, у них есть доступ к данным/логике).
- Подключить Г (внешний пользователь) — если он начнет давить, А может стать сговорчивее.

4. Документировать и эскалировать
Если А саботирует проект, а без них нельзя:
- Фиксируйте попытки контакта (письма, митинги, отказы дать информацию).
- Готовьте альтернативные сценарии (например: "Если А не предоставит данные, прогнозирование будет на основе Х").
- Эскалируйте на уровень выше — но не просто "они не работают", а "из-за этого будут риски Х, предлагаю решение Y".

✅ Вывод

Главное — не принимать "уход в тень" как данность. Пробуйте:
- Искать мотивы (почему А избегает контакта?).
- Менять фокус (через других стейкхолдеров или выгоды для А).
- Фиксировать и эскалировать (если всё уперлось в саботаж).

✍️ А у вас были похожие ситуации? Как выходили из них?

Кто выполняет функции системного аналитика в США?

⏳ 6 мин | 🟤⚪️⚪️

Перейти | BA|SA