Представьте: проект в разгаре, а перед запуском его в прод вдруг получается, что нет функционала, потому что на этапе проектирования системы требование недовыявили… Итог — аврал, доработки и сдвигающиеся сроки. Знакомо? Каждый такой «сюрприз» — потерянные время, деньги и нервы. Недаром говорят: доработать требования в начале проекта куда легче, чем переписывать потом тысячи строк кода. Как предотвратить эти ситуации? Один из проверенных способов — формализация требований с помощью Use Case.

Как именно Use Case помогает избежать ошибок в требованиях и сэкономить на доработках, рассказали ниже.

1️⃣ Помогает выявлять скрытые сценарии и исключения на раннем этапе. Прописывая различные варианты использования системы, аналитик заранее замечает нетривиальные пути. Use Case вынуждает продумать альтернативные потоки и исключения, которые иначе проявились бы только ближе к релизу. В результате скрытые требования и зависимости обнаруживаются заранее, а решение выходит более полным и устойчивым. Никаких внезапных «ой, а что если пользователь сделает X?» на финальных стадиях — эти вопросы вы закрываете еще на этапе анализа.

2️⃣ Упрощает коммуникацию с командой разработки. Это общий язык, который понятен аналитику, тестировщику и разработчику. Сценарии использования служат эффективным средством коммуникации: они снимают разночтения, помогают совместно уточнить требования и границы проекта. В итоге и ожидания клиента, и план реализации синхронизированы.

3️⃣ Диаграмма Use Case формирует общую картину того, как можно пользоваться системой: от входа в систему до достижения цели. Это не разрозненные пожелания, а связное повествование о работе системы. Такой подход дает целостное видение функциональности: какой функционал доступен конкретной роли; какие смежные системы задействованы в каждом отдельном варианте; для каких функций необходимо участие пользователя, а какие выполняет сама система при срабатывании триггера. Такой подход позволяет отследить по функциям различия в ролевой политике, а также «логику» распределения доступов и функционала. При этом процесс контроля полноты выделенных Use Case также становится проще, позволяя избежать ситуаций, когда «упустили какую-то часть процесса».

Применение Use Case снижает вероятность некорректного понимания требований. Если при описании требования в виде конкретных Use Case соблюдены все правила формирования качественных требований, то они перестают быть расплывчатыми тезисами. Каждый Use Case — это четкое однозначное описание поведения пользователя и системы в каждом отдельно взятом варианте. Такая конкретика повышает точность понимания системы и уменьшает риск разных трактовок со стороны участников проекта. В итоге - у всех единое видение, что именно должно быть реализовано, и заказчик получает то, что ожидал увидеть.

Четкое выделение шагов в Use Case позволяет однозначно определить и оценить результат, который должен быть на каждом шаге достигнут. Это дает возможность тестировщикам качественно подготовиться к тестированию функционала заранее, еще на этапе проектирования, что положительно влияет на соблюдение сроков и качества процесса разработки.

Use Case — это не лишняя бюрократия. Эта диаграмма может стать отличным помощником всей команде разработки. Научиться, как правильно описывать требования с помощью Use Case, Вы можете на нашем воркшопе «Use Case: основы».

Подробнее

#воркшоп@systems_education #системный_анализ@systems_education #требования@systems_education #Use_Case@systems_education

27 июня (пт) в 18:00 мск проведём вебинар в формате круглого стола на тему «Аналитик 1С: Границы ролей и технологий»

На круглом столе мы сравним профессиональные роли бизнес-, системного аналитика и аналитика 1С, разберём технологические особенности платформы 1С и обсудим, как выбор типовой, кастомной или самописной конфигурации меняет компетенции, методики и ответственность аналитиков.

▫️Кому будет полезен вебинар?
— Аналитикам 1С всех специализаций
— Системным аналитикам и solution-архитекторам, которые периодически сталкиваются с проектами на 1С
— Бизнес-аналитикам и product-/project-менеджерам, отвечающим за формулирование требований и выбор технологической стратегии
— Разработчикам 1С и full-stack-инженерам, которые нередко совмещают кодинг с аналитической работой
— IT-директорам, руководителям цифровых проектов, владельцам процессов, стремящимся сократить «дистанцию» между бизнес-потребностью и реализацией
— HR- и L&D-специалистам

▫️Участники круглого стола
— Михаил Максимов, Продакт, Бизнес-аналитик. Кандидат экономических наук. Автор и ведущий YouTube-канала для системных и бизнес-аналитиков. TOGAF certified.
— Татьяна Рыловникова, Старший аналитик 1С в OZON Банк. В 1С с 2016 года, работала с очень широким спектром конфигураций (от бухгалтерии предприятия до ERP, по дороге захватив общепит, тоир, университет и не только).
— Илья Отькало, Ген. директор «CORS Academy». Автор Курса Аналитика 1С. Автор книги «Автоматизация бизнес-процессов».
— Денис Богданов, Руководитель группы развития анализа в BIA Technologies. Более 15 лет в IT на разных позициях (разработчик, руководитель проектов, product owner, full-stack аналитик) в B2B и B2G.

👥 У всех слушателей будет возможность задать вопросы в режиме реального времени

Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

Регистрация обязательна
❗️Если у вас не открывается страница регистрации в браузере Telegram, перейдите в любой другой браузер — это должно решить проблему.


▫️Рекомендации SE
— Для аналитиков 1С, которые хотят перейти в другой стек — Курс «Интеграция систем. Разработка требований и основы проектирования»
— Для системных аналитиков, кто хочет перейти в 1С — Курс Аналитика 1С

#вебинар@systems_education

Event Storming + C4: как эффективно использовать их вместе?

▫️Event Storming — однозначный must-have для аналитиков

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

Однако после яркой и продуктивной сессии возникает логичный вопрос: что делать со всей этой информацией дальше? На стене — красочное полотно из стикеров, в головах участников — масса инсайтов. Известно, что по итогам Event Storming бизнес-процесс виден на схеме, но еще более важно знание, которое возникло в умах участников. Вот тут и таится проблема: как сохранить и передать это знание тем, кто не был на сессии, и не утратить важные детали?

▫️Нотация C4 в таких случаях становится мостом от домена к архитектуре

Нотация C4 — легковесный стандарт для описания программной архитектуры. Контекстная диаграмма (C4 Level 1) отлично подходит для структурирования знаний сразу после сессии Event Storming'a. Она берет то общее видение, что родилось на стикерах, и оформляет в понятную картину системы и ее окружения. По сути, мы переводим язык событий и акторов в язык компонентов и связей.

Сначала на сессии вы выявляете ключевые доменные события, участников процесса, ограничения и границы контекстов. А затем фиксируете эти находки в архитектурных диаграммах.

▫️Комбинация Event Storming + C4 — это полезный тандем, который позволяет не только быстро разобраться в бизнес-домене, но и закрепить понимание в виде четкого плана системы. Event Storming дает энергию и глубину инсайтов, C4 — структуру и наглядность.

В нашей школе у вас есть возможность на практике познакомиться с двумя этими техниками на практике.
Подробнее о воркшопе по C4
Подробнее о воркшопе по Event Storming

#воркшоп@systems_education

Опубликовали запись вебинара на тему «Методика проектирования бизнес-алгоритмов с помощью ИИ»

На вебинаре Алина Богачёва, исполнительный и финансовый директор SE, в режиме живого сторителлинга рассказала о своей методике проектирования бизнес-алгоритмов на примере самой ужасной службы доставки.

Тайм-код вебинара:
00:00 Введение
01:28 План выступления
01:55 В чем проблема?
06:10 Пример самой ужасной службы доставки
18:30 Когнитивная стратегия проектирования бизнес-алгоритмов
24:21 Создаём промт для ИИ на основе когнитивной стратегии
34:10 Выводы
37:00 Вопросы слушателей

Посмотреть запись можно как на нашем YouTube канале, так и в группе в ВК

Курс, который может быть вам интересен — Бизнес-анализ + ИИ. Разработка требований к ИТ-решению с использованием нейросетей

📌 Всех, кто не хочет пропустить ни одного анонса наших вебинаров, приглашаем в нашу группу @se_webinars, где мы по топикам публикуем новости, полезные материалы, записи и слайды презентаций вебинаров.

#вебинары@systems_education

В предыдущем посте мы рассказали, что такое дерево текущей реальности и как его построить. А сегодня мы покажем, как превратить методику в запрос для ИИ

Шаг 1. Подготовьте корзину фактов: все нежелательные явления, цитаты из интервью, показатели.

Шаг 2. В запросе пропишите правила:
— использовать только факты, без выдумок;
— отмечать тип узла (причина, проблема, последствие);
— каждую стрелку проверять по первым трём категориям правомерных оговорок;
— слабые места помечать флагом.

Шаг 3. Попросите ИИ перечислить все связи, которые не прошли проверку, и сформулировать вопросы заказчику.

Шаг 4. Добавьте задание назвать корневые причины и предложить три гипотезы устранения, указав, какие данные нужно подтвердить для проверки эффекта.

📌 Так ИИ действует в режиме опоры на факты: не придумывает новых данных, сразу подсвечивает логические пробелы и помогает получить управляемое дерево текущей реальности.

На курсе «Бизнес-анализ + ИИ. Разработка требований к ИТ-решению с использованием нейросетей» мы обучаем промт-инжинирингу на реальном бизнес-кейсе логистики. Подробнее тут.

#бизнес_анализ@systems_education #ИИ@systems_education

Опубликовали статью Анны Вичуговой на тему «Пакетный и потоковый ETL для PostgreSQL с AirFlow и с коннекторами Kafka»

В этой статье на практических примерах рассматривается, как и с помощью каких инструментов можно реализовать потоковый и пакетный ETL-процессы. В статье даются рекомендации по проектированию ETL-конвейеров.

Подробно рассматривается:
— что такое ETL и для чего он нужен?
— на что обратить внимание при проектировании ETL?
— пример проектирования пакетного ETL с Apache Airflow
— пример проектирования потокового ETL с Kafka

Статья может быть интересна системным и бизнес-аналитикам, которые хотят получить общее представление о проектировании ETL.

Почитать можно тут

#статьи@systems_education

Воркшоп «Проектирование интеграции с REST API»

🔹Когда?
30-31 Августа

🔹Воркшоп будет полезен тем, кто хочет:
— познакомиться с REST API
— научиться проектировать интеграцию «с нуля»
— описывать REST-интерфейсы в виде, пригодном для разработки

🔹Что получишь от воркшопа?
Пошаговую методику и шаблон описания интеграции
— Участники проанализируют процесс взаимодействия систем, потоки данных и опишут REST-like API
— Поймут, как аналитик решает интеграционные задачи
— Подготовят постановку задачи на интеграцию на основе шаблона

Регистрация

#воркшоп@systems_education #интеграция@systems_education #RESTAPI@systems_education