Как мы адаптируем Agile в Ozon?

⏳ 16 мин | 🟡🟡⚪️

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

AI, макеты и дедлайн: как за 8 часов исследовать продуктовый сценарий, нагенерить идей и взяться за макеты

⏳ 4 мин | 🟡🟡⚪️

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

Введение в OpenAPI: ёмко и полезно о важном

⏳7 мин | 🟡⚪️⚪️

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

Притирка команды: как выжить в новом проекте и не сбежать в лес

⏳ 6 мин | 🟤⚪️⚪️

Перейти | BA|SA

Как провести ретроспективу, которая реально работает

⏳ 4 мин | 🟡🟡⚪️

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

EDA of dataset Python

⏳ 6 мин | 🟡🟡⚪️

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

Всем привет! Топ-материалов, которые вышли у нас в 2024 году📌

«Повторение - мать учения»

📝Требования:
- Гайд по написанию пользовательских историй и критериев приёмки
- Бизнес-аналитик — мастер переговоров или как не сойти с ума, работая с требованиями
- Краткий гайд по общению с заказчиком

- Гайд для системного аналитика: как управлять требованиями на разных этапах проекта.
- Как написать требования к IT-продукту и их протестировать, чтобы результат соответствовал ожиданиям
- Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения
- Работа над ошибками: как правильно работать с требованиями

📌Моделирование | Нотации:
- Разбор программы Business Studio
- BPMN — белый световой меч аналитика
- Система условных обозначений BPMN

- UML обзор основных типов диаграмм
- Диаграммы последовательности — единственная хорошая вещь, которую UML привнес в разработку ПО
- Диаграмма последовательности
- Диаграмма последовательности (sequence-диаграмма)

📚Методологии разработки ПО:
- Waterfall, Agile, Scrumban — плюсы и минусы, или Что не так с эталонными подходами к разработке
- 9 лучших канбан-досок для работы и личных дел в 2024

⚙️Интеграция | Архитектура ПО:
- Что такое API на простом
- 25 вопросов и ответов по терминам REST API на собеседовании по вакансии системного аналитика
- Как мы описываем требования к REST API для бэкенда в Confluence
- Как проектировать веб-API: 7 самых важных вопросов
- Kafka vs RabbitMQ: что нужно знать аналитику про брокеры сообщений
- Kafka. Лучшие практики применения. Настройки Producer & Consumer
- Технологии интеграции информационных систем. Часть 2. GraphQL, gRPC, WebSocket, webhook, брокеры сообщений
- Что такое брокеры сообщений

- Сложно о простом. Модель OSI и TCP/IP

- Что такое архитектура
- Слоистая архитектура приложений: как обеспечить поддерживаемость доменного слоя
- Функциональная архитектура в проектах внедрения на платформе 1С
- Клиент-серверная архитектура. SA для самых маленьких

🛠️SQL и базы данных:
- Ключи в базе данных: практический обзор для начинающих системных аналитиков
- Памятка/шпаргалка по SQL
- Шпаргалка по оконным функциям в SQL
- Шпаргалка по SQL
- Обширная шпаргалка по SQL

✅Разное:
- О бизнес-аналитиках в ИТ
- Компетенции ИТ-аналитика или как попасть в сферу ИТ
- Критерии качества аналитиков
- Куда и как развиваться системному аналитику, если «потолок» уже близко
- Системный аналитик краткий гайд
- ИИ-инструменты для аналитиков: теория, кейсы, советы
- Введение в системный анализ

- Как избежать выгорание на рабочем месте
- Версионность документации
- Задачи и тестовые задания
- Анализ по сайту найма на позиции БА и СА

✅Литература:
- Азбука системного мышления
- Проектирование веб-API

Источник: @analysis_it

Салют! Сегодня будем обсуждать и делиться советами, как собирать требования

Сбор требований — это фундамент любого проекта. Ошибки на этом этапе приводят к переделкам, срыву сроков и недовольству заказчика. Расскажу по шагам, как делать это правильно, избегая типичных ловушек, исходя из своего опыта☝️

🚀 1. Подготовка: что сделать до встречи с заказчиком

✅ Поймите контекст проекта:
— Какие бизнес-цели преследует заказчик? (Пример: увеличить продажи на 30% через новый сайт).
— Кто ключевые стейкхолдеры? (руководитель, пользователи, IT-отдел).
— Изучите существующие документы: ТЗ, отчеты
— Проанализируйте и изучите конкурентов

✅ Составьте план интервью:

Лучше быть готовым, чем краснеть. Я заранее на лист бумаги выписывала цель проекта, главне вопросы, в зависимости от заказчиков (если их несколько)
— Определите, какие вопросы задать. Например:
«Какие проблемы решает этот проект?»
«Как вы видите успех через полгода после запуска?»

✅ Выберите инструменты:
Чаще всего я пользовалась листом бумаги
— Анкеты
— Шаблоны для документирования (Confluence, Excel)
— Доски (Miro для мозговых штурмов)…

——————

▶️ 2. Начало общения: как установить контакт

✅ Первые 10 минут — самые важные:
— Объясните свою роль: «Я помогу формализовать ваши идеи так, чтобы команда их правильно реализовала»
— Уточните формат работы: «Сейчас я задам несколько вопросов, а потом мы обсудим детали»

✅ Слушайте активно:
— Кивайте, повторяйте ключевые тезисы: «Правильно ли я понял, что основная проблема — долгая обработка заказов?».
— Задавайте открытые вопросы:
«Расскажите, как сейчас происходит процесс X»
— Переспросите, если что-то было непонятно

——————

🛠️ 3. Техники сбора требований

✅ User Stories (Пользовательские истории):
Формат: *«Как [роль], я хочу [действие], чтобы [цель]»*.
Пример: *«Как менеджер, я хочу фильтровать заказы по дате, чтобы быстро находить просроченные»*.

✅ Мозговой штурм:
Используйте Miro или доску. Фиксируйте все идеи, даже странные. Позже вместе с заказчиком отсортируйте их по приоритету

✅ Прототипы:
Набросайте схему интерфейса или бизнес-процесса. Часто заказчик не понимает текста, но сразу видит ошибки в визуальной схеме

——————

📌 4. Что обязательно уточнить

✅ Функциональные требования: Что система должна делать (например, «формировать отчет в PDF»)

✅ Нефункциональные требования:
— Производительность («загрузка страницы — не дольше 2 сек»)
— Безопасность («двухфакторная аутентификация»)

✅ Ограничения: Бюджет, сроки, законодательство («данные должны храниться в РФ»)

——————

⛔️ 5. Чего делать НЕЛЬЗЯ

❌ Додумывать за заказчика.
*Неверно:* «Вам, наверное, нужна интеграция с 1С?»
*Правильно:* «Какие системы должны быть подключены?»

❌ Игнорировать конфликты требований.
Если отдел продаж хочет «гибкую настройку цен», а бухгалтерия — «фиксированные правила», вынесите это на обсуждение. Сами не принимайте решений.

❌ Откладывать документирование.
Фиксируйте требования сразу в структурированном виде.
Можно использовать пример:
- Требование | Возможность отмены заказа
- Тип | Функциональное
- Приоритет | High
- Источник | Интервью с менеджером

——————

📝 6. Проверка и согласование

✅ Валидация требований:
Покажите заказчику документ и задайте вопросы:
*«Всё ли учтено? Нет ли противоречий?»*

✅ Используйте примеры:
«Представьте: пользователь пытается оформить заказ ночью. Как система должна реагировать?»

——————

Советы напоследок

- Говорите на языке заказчика. Избегайте технических терминов.

- Управляйте ожиданиями: Если требование невозможно, сразу скажите: «Это потребует 3 месяца работы. Есть ли бюджет?».

- Итеративность: Требования меняются. Регулярно возвращайтесь к ним и актуализируйте.

——————

Инструменты в помощь:
- Jira + Confluence — для документирования.
- Draw.io / Lucidchart — для диаграмм процессов.
- Balsamiq — для прототипов.

Главное — не бойтесь задавать «глупые» вопросы. Лучше уточнить сто раз, чем переделывать проект. Удачи! 🚀

Источник: @ba_and_sa

Разработка и производство современных ASIC/SoC глазами тополога

⏳ 10 мин | 🟡⚪️⚪️

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

Нотация BPMN. Практическое моделирование

«Авторы подготовили для вас более 100 иллюстраций, с описанием наиболее распространенных вопросов, связанных с практическим использованием нотации BPMN и моделированием бизнес-процессов»

⏳ 16 мин | 🟡🟡⚪️

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

Собеседование по System Design: рассказ очевидца

⏳ 10 мин | 🟡⚪️⚪️

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

Всем привет! Недавно проводила опрос про сбор требований с заказчиков, а точнее с какими трудностями сталкивается аналитик чаще всего.
Сегодня немного углублюсь в тему и рассмотрим каждую трудность по-отдельности:

1️⃣ Частые изменения требований

Это вечная боль аналитиков, по-крайней мере у меня 🤯 данная ситуация очень часто встречалась на проектах, что заказчику приходит в голову новая идея и мне нужно что-то решать, поэтому у нас все изменения были вынесены в отдельный док, с приоритетами и рисками, и мы их старались внедрять на след этапе, но не всегда кончено это получалось(

- Описание проблемы:
Заказчики могут менять требования на протяжении проекта, что приводит к переделке работы, срыву сроков и увеличению бюджета

- Решение:
- Внедрите процесс управления изменениями. Каждое новое требование должно быть задокументировано и оценено с точки зрения влияния на сроки, бюджет и ресурсы.
- Используйте инструменты для отслеживания изменений (например, Jira, Trello).
- Регулярно напоминайте заказчику о последствиях изменений и предлагайте альтернативы.
- Закрепите базовые требования на этапе подписания договора или технического задания.

2️⃣ Заказчик не может четко сформулировать требования

Бывали и такие заказчики, которые сами не знали, что хотят, точнее не могли четко описать свои требования. И мы приходили к сути через долгие переговоры, могли кого-то подключить во время совещания, взять паузу, но по итогу приходили к консенсусу

- Описание проблемы:
Заказчик может не понимать, чего именно он хочет, или не уметь выразить свои мысли в конкретных требованиях

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

3️⃣ Недостаток времени на уточнение и сбор требований

Парой заказчики хотят многое за быстрые сроки, из-за чего уменьшается время на сбор и проработку требований, из-за чего мне приходилось перерабатывать 🤯

- Описание проблемы:
Часто проекты начинаются с жестких сроков, и времени на детальный сбор требований просто нет

- Решение:
- Сфокусируйтесь на минимально жизнеспособном продукте (MVP). Определите ключевые функции, которые должны быть реализованы в первую очередь.
- Используйте итеративный подход: собирайте требования по мере работы над проектом.
- Заранее согласуйте с заказчиком, что часть требований будет уточняться в процессе.
- Документируйте все допущения и риски, связанные с недостатком информации.

4️⃣ Заказчик не вовлечен в процесс

У меня бывали такие случаи раннее

описывала кейсы

- Описание проблемы:
Заказчик может быть пассивным, не участвовать в обсуждениях, не предоставлять обратную связь или пропускать встречи.

- Решение:
- Назначьте ответственного за взаимодействие с вашей стороны и со стороны заказчика.
- Регулярно напоминайте о важности их участия для успеха проекта.
- Используйте короткие и четкие отчеты, чтобы заказчик мог быстро ознакомиться с прогрессом.
- Проводите регулярные синхронизации (например, раз в неделю) и запрашивайте обратную связь.

5️⃣ Аналитик не может найти общий язык с заказчиком или его игнорируют

У меня тоже были такие ситуации, но мы всегда находили пути решения. Я проводила доп совещания, где рассказывала кто я такая, и какую ценность приношу компании

- Описание проблемы:
Иногда заказчик может не воспринимать аналитика всерьез, игнорировать его рекомендации или не идти на контакт.

- Решение:
- Установите доверительные отношения. Покажите свою экспертизу, но будьте открыты к их мнению.
- Используйте данные и факты для аргументации своих предложений.
- Если заказчик игнорирует вас, привлеките вышестоящих лиц (например, спонсора проекта).
- Постарайтесь понять мотивацию заказчика и адаптировать стиль общения под его потребности.

Источник: @analysis_it

Краткий гайд по написанию бизнес-процессов

1️⃣ С чего начать?

1. Определите цель описания бизнес-процесса:
- Для обучения/инструкций: процесс должен быть простым и понятным для новичков.
- Для регламентов: процесс должен быть детализированным и формализованным.
- Для аудита: процесс должен отражать реальное положение дел, включая слабые места.
- Для автоматизации: процесс должен быть четким, с указанием точек интеграции и данных.

2. Соберите информацию:
- Поговорите с участниками процесса (сотрудниками, руководителями).
- Изучите документацию, если она есть. Или поищите инфу в инете.
- Наблюдайте за процессом в действии.

3. Определите границы процесса:
- Где процесс начинается?
- Где заканчивается?
- Какие входные и выходные данные?
- Кто ответственный или кто участник?

4. Выберите нотацию для описания:
- BPMN (Business Process Model and Notation) — для сложных процессов.
- Flowchart (блок-схемы) — для простых процессов.
- Текстовое описание — для инструкций или регламентов.

2️⃣ Как правильно описывать бизнес-процессы?

1. Разбейте процесс на этапы:
- Каждый этап должен быть логически завершенным.
- Укажите, кто отвечает за каждый этап (роль или должность).

2. Используйте четкие формулировки:
- Избегайте двусмысленности.
- Указывайте конкретные действия, например, "Сотрудник проверяет заявку на соответствие требованиям".

3. Добавьте условия и ветвления:
- Если процесс может идти по разным сценариям, укажите условия (например, "Если заявка одобрена, перейти к этапу 3; если нет, вернуть на доработку").

4. Укажите входы и выходы:
- Что поступает на вход этапа (документы, данные, ресурсы).
- Что является результатом этапа.

5. Визуализируйте процесс:
- Используйте диаграммы, схемы, таблицы для наглядности.
- Для сложных процессов используйте специализированные инструменты (например, Bizagi, Lucidchart, Visio).

3️⃣ Советы для новичков

- Начинайте с простого:
Не пытайтесь описать весь процесс сразу. Разбейте его на части.

- Не усложняйте:
Избегайте излишней детализации, если это не требуется для цели.

- Проверяйте на практике: Убедитесь, что описание соответствует реальности.

- Используйте шаблоны:
Найдите примеры похожих процессов и адаптируйте их под свои нужды.

- Собирайте обратную связь:
Покажите описание участникам процесса и внесите правки.

4️⃣ Инструменты для описания бизнес-процессов

- BPMN-диаграммы: Bizagi, Lucidchart, Visio.
- Блок-схемы: Draw.io, Miro.
- Текстовые редакторы: Word, Google Docs (для регламентов).
- Специализированные программы: ARIS, ELMA, Business Studio.

5️⃣ Пример структуры описания бизнес-процесса (можно использовать как шаблон)

1. Название процесса:
Например, "Обработка заказа клиента"

2. Цель процесса:
Например, "Обеспечить своевременную обработку и доставку заказа"

3. Участники процесса:
Менеджер, склад, курьер

4. Этапы процесса:
- Этап 1: Получение заказа.
- Этап 2: Проверка наличия товара.
- Этап 3: Сборка заказа.
- Этап 4: Доставка клиенту

5. Входы/выходы:
Заявка клиента → Подтверждение заказа → Доставленный товар

6. Условия и исключения:
Если товара нет на складе, уведомить клиента.

Чуть позже скину «Шпаргалку по подходам в зависимости от целей Бизнес-процесса»

Источник: @ba_and_sa