Зачем бизнесу нужно DWH и как обосновать необходимость проекта? Можно ли оценить окупаемость хранилища?

⏳ 9 мин | 🟡🟡⚪️

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

Как настроить уведомления из систем документооборота (СЭД) с помощью API

⏳ 10 мин | 🟡⚪️⚪️

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

6 способов сэкономить место на дашборде, используя интерактивные функции в Tableau

⏳ 4 мин | 🟡⚪️⚪️

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

Безумные и забавные факты о SQLite

⏳ 5 мин | 🟡🟡⚪️

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

KPI по качеству управления ИТ-проектами для руководителя и команды

⏳ 9 мин | 🟡🟡⚪️

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

Двенадцать заповедей от тех, кто уже выжил в IT (и не потерял чувство юмора)

⏳ 9 мин | 🟡⚪️⚪️

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

Зачем аналитику знать Kafka?

🎯Главная цель: зачем системному аналитику знать Kafka?

Kafka — это не просто технология для разработчиков. Аналитик, понимающий её принципы, может проектировать более эффективные системы, улучшать процессы сбора данных и точнее ставить задачи команде.

❓ Зачем аналитику разбираться в Kafka?

1. Проектирование потоков данных
- Аналитик часто участвует в проектировании интеграций между системами.
- Kafka помогает организовать гибкую передачу событий (например, заказы → аналитика → CRM → склад).
- Без Kafka такие потоки часто делают через прямые вызовы API или базы данных, что сложнее масштабировать.

2. Работа с реальными данными (event-driven аналитика)
- Современные системы генерируют потоки событий (клики, платежи, логины).
- Kafka позволяет собирать их в реальном времени и передавать в аналитические хранилища (ClickHouse, BigQuery и др.).
- Без Kafka данные могут теряться или приходить с задержкой.

3. Упрощение ETL-процессов
- Раньше данные выгружали пакетами (раз в час/день), теперь можно стримить их непрерывно.
- Например:
- Данные из мобильного приложения → Kafka → обработка → витрины данных.
- Логи веб-сервера → Kafka → анализ аномалий.

4. Общение с разработчиками на одном языке
- Если аналитик говорит: *«Нам нужно подписаться на топик user_actions и агрегировать данные»* — это понятнее, чем *«Сделайте выгрузку из БД каждые 5 минут»*.
- Понимание Kafka помогает уменьшить разрыв между аналитикой и разработкой.

5. Оптимизация нагрузки на БД
- Если система пишет данные напрямую в PostgreSQL / MySQL, при высокой нагрузке могут быть тормоза.
- Kafka буферизирует данные и отдаёт их потребителям в удобном темпе.

⛔️ Когда Kafka НЕ нужна?

- Если данные обновляются редко (раз в день).
- Если система маленькая и нет проблем с производительностью.
- Если команда не готова поддерживать Kafka (это всё же дополнительная инфраструктура).

📌 Вместо вывода

Аналитику Kafka нужна, чтобы:

✅ Лучше проектировать интеграции.
✅ Работать с данными в реальном времени.
✅ Упрощать ETL и снижать нагрузку на БД.
✅ Говорить с разработчиками на одном языке.

📖 Полезные материалы для аналитика:

1. Официальная документация Kafka – база для понимания.
2. Введение в Apache Kafka для системных аналитиков и проектировщиков интеграций - основы в одном месте
3. Kafka для самых маленьких разработчиков, аналитиков и тестировщиков. - немного теории для самых маленьких

Если в вашем проекте есть много событий, микросервисы или большая нагрузка — Kafka стоит изучить 🚀

Источник: @ba_and_sa

Как сделать хорошее API

⏳ 17 мин | 🟡🟡⚪️

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

НФТ к документации: Своя игра

⏳ 4 мин | 🟡🟡⚪️

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

Как я решил выяснить, какие технологии сегодня популярны, а получился GitHub Trend Analyzer

⏳ 8 мин | 🟡⚪️⚪️

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

Станция «Confluence». Перевезти всё, что нажито непосильным трудом

⏳10 мин | 🟡⚪️⚪️

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

Просто покажи: сила визуализации в аналитике

⏳ 9 мин | 🟡⚪️⚪️

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

Стандарты и шаблоны для ТЗ на разработку ПО

⏳ 7 мин | 🟡⚪️⚪️

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

Что же такое цифровой двойник завода? Возможные варианты будущего

⏳ 3 мин | 🟡⚪️⚪️

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

Пример решения одной задачи с помощью модельно-ориентированного подхода

⏳ 22 мин | 🟡🟡⚪️

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

Аналитика требований: SMART, INVEST, MoSCoW — пытаемся систематизировать хаос

⏳ 4 мин | 🟡⚪️⚪️

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

SMART, INVEST, MoSCoW – простыми словами для новичков (с моих уст) 😏

Эти три методики помогают правильно ставить цели, разбивать задачи и расставлять приоритеты в разработке продуктов (и не только).

1️⃣ SMART – как ставить понятные цели

Используется, когда нужно сформулировать конкретную, измеримую и достижимую цель.

Расшифровка:

- S (Specific) – Конкретная:
Не "улучшить продукт", а "увеличить скорость загрузки страницы на 20%"

- M (Measurable) – Измеримая:
Должны быть цифры: "привлечь 1000 новых пользователей"

- A (Achievable) – Достижимая:
Не "сделать самый популярный сервис в мире", а "выйти в топ-3 в своём регионе"

- R (Relevant) – Релевантная:
Цель должна быть важна для бизнеса, а не просто "хотелка"

- T (Time-bound) – Ограниченная по времени:
"до конца квартала"

Пример SMART-цели:

❌ Плохо: "Сделать удобный интерфейс".
✅ Хорошо: "Увеличить конверсию оформления заказа с 5% до 8% к 1 декабря за счёт упрощения формы оплаты".

Когда использовать?
✔ Постановка KPI, планирование проектов, личные цели.
_______________

2️⃣ INVEST – как писать хорошие пользовательские истории (User Stories)

Нужен, чтобы задачи в бэклоге были независимыми, ценными и тестируемыми.

Расшифровка:

- I (Independent) – Независимая (можно реализовать без других задач)

- N (Negotiable) – Обсуждаемая (не жёсткое ТЗ, а договорённость с заказчиком)

- V (Valuable) – Ценная (должна приносить пользу пользователю или бизнесу)

- E (Estimable) – Оцениваемая (можно понять, сколько времени займёт)

- S (Small) – Небольшая (чтобы сделать за 1-2 спринта)

- T (Testable) – Тестируемая (есть чёткие критерии выполнения).

Пример INVEST-истории:

❌ Плохо: "Сделать личный кабинет".
✅ Хорошо: "Как пользователь, я хочу видеть историю заказов в личном кабинете, чтобы отслеживать статус доставки".

Когда использовать?
✔ Agile-разработка, Scrum, написание бэклога.
______________

3️⃣ MoSCoW – как расставить приоритеты

Помогает решить, без чего нельзя обойтись, а что можно отложить.

Категории:

- M (Must have) – Обязательно (без этого продукт не работает)

- S (Should have) – Важно, но не критично (можно без этого запуститься)

- C (Could have) – Было бы хорошо (если останется время)

- W (Won’t have) – Не будем делать (по крайней мере сейчас)

Пример MoSCoW-приоритизации для интернет-магазина:
- Must have: Корзина, оплата, каталог товаров.
- Should have: Поиск по сайту.
- Could have: Рекомендации товаров.
- Won’t have: Виртуальная примерочная.

Когда использовать?
✔ Планирование спринтов, MVP, управление требованиями.

_________________

Вывод:
- Хочешь чёткую цель? → SMART.
- Нужно разбить задачу на части? → INVEST.
- Не знаешь, что делать в первую очередь? → MoSCoW.

Источник: @analysis_it

Теперь ты сможешь объяснить их даже бабушке! 😉

Оценка задач в сторипоинтах по их декомпозиции: метод, который наконец-то работает

⏳ 6 мин | 🟡⚪️⚪️

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

GigaCode: как ИИ-ассистент упрощает жизнь системным аналитикам

⏳ 16 мин | 🟡🟡⚪️

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