Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Как создаются шедевры: будни технического писателя
Один из важнейших принципов работы команды «Оптимакрос» — прозрачность. Нам важно, чтобы каждый процесс был понятным и хорошо документированным, чтобы даже новичок быстро разобрался. За созданием...
❤7
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Субъективный рейтинг: 10 самых часто встречающихся ошибок аналитика при написании требований
Знаете, как часто бывает: читаешь чей-нибудь умный труд (например, прекрасную книгу Карла Вигерса «Разработка требований к программному обеспечению» ), всё вроде понятно — требования должны быть...
👍3
Please open Telegram to view this post
VIEW IN TELEGRAM
Практические курсы по бизнес-анализу – обучение системных и бизнес-аналитиков, курсы BABOK
Разбираемся с RabbitMQ на практическом примере в cloudmq
Что такое RabbitMQ, как он работает и что нужно аналитику знать об этом ПО для интеграции ИС и проектирования взаимодействия микросервисов
❤1
Please open Telegram to view this post
VIEW IN TELEGRAM
Практические курсы по бизнес-анализу – обучение системных и бизнес-аналитиков, курсы BABOK
Задаем НФТ в точных цифрах: пример расчета нагрузки в rps
Как рассчитать нагрузку в rps и задать нефункциональные требования к производительности в точных цифрах: пример для интернет-магазина
Конвейеры данных (Data Pipelines) — это автоматизированные процессы сбора, обработки, преобразования и перемещения данных из различных источников в целевые хранилища (например, базы данных, DWH, озёра данных).
❓ У вас может появится вопрос «Зачем знать аналитику?»
1. Понимание данных — чтобы разбираться, откуда берутся данные, как они очищаются и преобразуются.
2. Качество данных — чтобы выявлять и исправлять ошибки на этапе ETL/ELT.
3. Оптимизация запросов — чтобы писать эффективные SQL-запросы, зная, как данные подготовлены.
4. Автоматизация отчётов — чтобы настраивать регулярные выгрузки и дашборды.
5. Взаимодействие с инженерами — чтобы грамотно ставить задачи по доработке пайплайнов.
🤔 Нужно ли углубляться в тему или поверхностно знать основы?
- Да, если аналитик работает с Big Data или участвует в построении аналитической инфраструктуры.
- Нет, если роль ограничена готовыми данными в BI-инструментах, но базовое понимание всё равно полезно.
📎 Так же прикрепляю статьи на данную тему:
- Что такое конвейер данных? И почему вы должны это знать
- Конвейер данных и конвейер ETL: в чем разница?
- Как построить конвейер данных: пошаговое руководство
Источник: @ba_and_sa
1. Понимание данных — чтобы разбираться, откуда берутся данные, как они очищаются и преобразуются.
2. Качество данных — чтобы выявлять и исправлять ошибки на этапе ETL/ELT.
3. Оптимизация запросов — чтобы писать эффективные SQL-запросы, зная, как данные подготовлены.
4. Автоматизация отчётов — чтобы настраивать регулярные выгрузки и дашборды.
5. Взаимодействие с инженерами — чтобы грамотно ставить задачи по доработке пайплайнов.
- Да, если аналитик работает с Big Data или участвует в построении аналитической инфраструктуры.
- Нет, если роль ограничена готовыми данными в BI-инструментах, но базовое понимание всё равно полезно.
- Что такое конвейер данных? И почему вы должны это знать
- Конвейер данных и конвейер ETL: в чем разница?
- Как построить конвейер данных: пошаговое руководство
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Архитектура проекта автоматического обучения ML-моделей
Хабр, привет! На связи Кравцов Кирилл и Суздалев Руслан из команды моделирования поведенческих сценариев Центра развития искусственного интеллекта СПАО «Ингосстрах»(далее — ЦРИИ). В статье...
This media is not supported in your browser
VIEW IN TELEGRAM
До дедлайна остались считанные минуты, а аналитик не выходит на связь
PM в это время:
PM в это время:
😁34❤15😢3💯2
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Архитектурные паттерны для высокой масштабируемости. Часть 3
Итак, в прошлых частях 1 и 2 я писал что обеспечение консистентности данных сильно мешает масштабированию. Что же делать на практике? Здесь не будем касаться случаев ультра параллелизма и...
❤2
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Пример проектирования, ориентированного на домен: От хаоса к чистой архитектуре
A Domain-driven Design Example: From Chaos to Clean Architecture Пример проектирования, ориентированного на домен: От хаоса к чистой архитектуре Всестороннее исследование принципов Domain-driven...
🔥4❤3
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Качество требований в IT-проектах
Качество требований в IT-проектах — тема, которая редко обходится без болезненных вопросов и неочевидных ответов. Эта статья — не о критериях идеальных требований (их мы касаться не будем), а о том,...
👍6❤3
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Тяжёлая артиллерия в оценке сроков задач
Закон Хофштадтера Всегда потребуется больше времени, чем вы ожидаете, даже если вы знаете закон Хофштадтера. Вступление Сразу хочу отметить, что метод не универсальный и подходит не для всех задач,...
Forwarded from Analyst IT
Please open Telegram to view this post
VIEW IN TELEGRAM
ArtofBA
Как аналитику развить устойчивость и не стать мизантропом ≡ Блог ArtofBA
🔥9👍5😁3❤2
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Рекомендации по сбору и приоритизации требований для бизнес-аналитика
— Голдстейн. — Да, мистер Старк. — Дай мощный бит, под который я буду бить лучшего друга , писать эту статью. ©Железный человек Привет, Хабр! Меня зовут Дмитрий Сушков, последние 5...
❤5🥱5
Салют! Ребят у кого нибудь есть вопросы для разбора? Или может кто столкнулся с проблемой на проекте?
Просто ко мне, в последнее время, стали в личку писать, в основном новички, с вопросами/проблемами, с которыми они столкнулись, и мы находили пути решения. И тут меня посетила идея спросить напрямую, у кого есть что обсудить)))
Поэтому, если у вас есть вопросы/проблемы, вы можете их оставить в комментариях, и я потом буду делать посты с их разборами) если такой формат у нас примется, буду делать такие разборы еженедельно☺️ если нет, значит у всех все хорошо и всем все понятно в этой жизни)))
Го!!!
P.s. если кто-то хочет анонимно, пишите мне в личку, я опубликую вопрос от канала)))
Просто ко мне, в последнее время, стали в личку писать, в основном новички, с вопросами/проблемами, с которыми они столкнулись, и мы находили пути решения. И тут меня посетила идея спросить напрямую, у кого есть что обсудить)))
Поэтому, если у вас есть вопросы/проблемы, вы можете их оставить в комментариях, и я потом буду делать посты с их разборами) если такой формат у нас примется, буду делать такие разборы еженедельно☺️ если нет, значит у всех все хорошо и всем все понятно в этой жизни)))
Го!!!
P.s. если кто-то хочет анонимно, пишите мне в личку, я опубликую вопрос от канала)))
🔥6👍5🤩3❤2
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
ACID, BASE, CAP: Фундамент архитектуры распределенных систем
Современная разработка ПО – это почти всегда про распределенные системы. Микросервисы, облака, глобальный охват – все это стало нормой. Но за красивыми диаграммами и модными словами скрывается...
👍8❤4🙏3
Please open Telegram to view this post
VIEW IN TELEGRAM
РБК Компании
Почему сотрудники плохо работают: новый взгляд на бизнес-процессы | РБК Компании
ИП Чернышова Елена Борисовна: Как увеличить выручку компании на 50% всего за 8 месяцев и всегда ли нужно менять команду при низкой продуктивности персонала
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
BPMN умер, все сделает ИИ
Мы все видели, как такие инструменты, как ChatGPT, справляются с множеством бизнес-задач, автоматизируя практически всё. И это правда — генеративный ИИ действительно способен выполнять широкий спектр...
👍10🤔7❤3🔥2😁1🤯1👌1
Салют! Праздники закончились пора возвращаться в строй! И решила разобрать часть вопросов, которые поступили мне в личку и в комменты под моим постом ☺️
Начнем с вечно волнующей темой аналитиков: «Как работать со стейкхолдерами, которые "уходят в тень"?
Ситуация от подписчика (написала в личку):
Есть процесс, который нужно автоматизировать и улучшить (добавить прогнозирование, фичи для управленческих решений). Есть несколько ключевых стейкхолдеров:
- А — главные по процессу (по регламенту), но избегают вовлечения, не объясняют логику решений.
- Б, В — помогают, согласовывают.
- Г — ключевой внешний пользователь.
Проблема: А игнорирует обсуждения, не аргументирует свои решения, а без них сложно проектировать систему.
Предистория:
❓ Что делать? (Или чтобы я посоветовала)
1. Разобраться в мотивах "ухода в тень"
Почему А не хочет участвовать? Возможные причины:
- Не видят ценности ("и так работает, зачем менять?").
- Боятся изменений (автоматизация = потеря контроля, прозрачность решений).
- Нет времени/ресурсов (воспринимают как дополнительную нагрузку).
- Политика ("если раскроем логику, нас загрузят еще больше").
Как проверить?
- Задать косвенные вопросы:
- "Какие боли у вас в этом процессе?"
- "Если бы можно было изменить одну вещь — что бы выбрали?"
- Поговорить с Б и В — возможно, они знают подводные камни.
2. Снижать сопротивление через выгоды
Люди не против изменений — они против невыгодных им изменений.
Как "продать" проект отделу А?
- Связать с их KPI (если автоматизация сократит их рутину или снизит риски). Нужно это показать!
- Дать почувствовать контроль (например, через промежуточные согласования).
- Создать "пилот" (не всю систему, а прототип для части процесса и заинтересовать стейкхолдера).
3. Работать через других
Если А блокирует процесс, но Б и В лояльны:
- Формализовать требования через них (возможно, у них есть доступ к данным/логике).
- Подключить Г (внешний пользователь) — если он начнет давить, А может стать сговорчивее.
4. Документировать и эскалировать
Если А саботирует проект, а без них нельзя:
- Фиксируйте попытки контакта (письма, митинги, отказы дать информацию).
- Готовьте альтернативные сценарии (например: "Если А не предоставит данные, прогнозирование будет на основе Х").
- Эскалируйте на уровень выше — но не просто "они не работают", а "из-за этого будут риски Х, предлагаю решение Y".
✅ Вывод
Главное — не принимать "уход в тень" как данность. Пробуйте:
- Искать мотивы (почему А избегает контакта?).
- Менять фокус (через других стейкхолдеров или выгоды для А).
- Фиксировать и эскалировать (если всё уперлось в саботаж).
✍️ А у вас были похожие ситуации? Как выходили из них?
Начнем с вечно волнующей темой аналитиков: «Как работать со стейкхолдерами, которые "уходят в тень"?
Ситуация от подписчика (написала в личку):
Есть процесс, который нужно автоматизировать и улучшить (добавить прогнозирование, фичи для управленческих решений). Есть несколько ключевых стейкхолдеров:
- А — главные по процессу (по регламенту), но избегают вовлечения, не объясняют логику решений.
- Б, В — помогают, согласовывают.
- Г — ключевой внешний пользователь.
Проблема: А игнорирует обсуждения, не аргументирует свои решения, а без них сложно проектировать систему.
Предистория:
Подписчица пришла на проект без опыта, за спиной была только магистратура по прикладной информатики, т.е. понимание было нашей сферы деятельности, какие то знания были, задача была понятна. Но! Был момент на проекте, когда подписчица осталась одна в роли аналитика, и обращаться было не к кому с вопросами, только напрямую к неразговорчивым стейкхолдерам, а аналитик был до этого без опыта😠 из-за чего в голове было много вопросов, недопонимания, страх, что не справится и тд.
1. Разобраться в мотивах "ухода в тень"
Почему А не хочет участвовать? Возможные причины:
- Не видят ценности ("и так работает, зачем менять?").
- Боятся изменений (автоматизация = потеря контроля, прозрачность решений).
- Нет времени/ресурсов (воспринимают как дополнительную нагрузку).
- Политика ("если раскроем логику, нас загрузят еще больше").
Как проверить?
- Задать косвенные вопросы:
- "Какие боли у вас в этом процессе?"
- "Если бы можно было изменить одну вещь — что бы выбрали?"
- Поговорить с Б и В — возможно, они знают подводные камни.
2. Снижать сопротивление через выгоды
Люди не против изменений — они против невыгодных им изменений.
Как "продать" проект отделу А?
- Связать с их KPI (если автоматизация сократит их рутину или снизит риски). Нужно это показать!
- Дать почувствовать контроль (например, через промежуточные согласования).
- Создать "пилот" (не всю систему, а прототип для части процесса и заинтересовать стейкхолдера).
3. Работать через других
Если А блокирует процесс, но Б и В лояльны:
- Формализовать требования через них (возможно, у них есть доступ к данным/логике).
- Подключить Г (внешний пользователь) — если он начнет давить, А может стать сговорчивее.
4. Документировать и эскалировать
Если А саботирует проект, а без них нельзя:
- Фиксируйте попытки контакта (письма, митинги, отказы дать информацию).
- Готовьте альтернативные сценарии (например: "Если А не предоставит данные, прогнозирование будет на основе Х").
- Эскалируйте на уровень выше — но не просто "они не работают", а "из-за этого будут риски Х, предлагаю решение Y".
Главное — не принимать "уход в тень" как данность. Пробуйте:
- Искать мотивы (почему А избегает контакта?).
- Менять фокус (через других стейкхолдеров или выгоды для А).
- Фиксировать и эскалировать (если всё уперлось в саботаж).
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤4👌2