Почему без бизнес-аналитики и матрицы RACI нельзя даже гречку сварить

Интересный кейс команды интеграторов ROCKET. Клиент – реальная российская компания, у которой проектное управление «почему-то не взлетало». Разобрались, почему, и очень жизненно описали взаимоотношения бизнеса и аутсорс-аналитиков.

Перейти

​​​​Алоха! сегодня предлагаю поговорить о таком методе сбора требований как "Event storming"

Если не вдаваться в подробности, то можно сказать, что одним из важных и сложных моментов, предшествующим разработке архитектуры приложения, это сбор требований и моделирование бизнес-процессов. И это не зависит сложный ли намечается продукт или легкий, требования все равно нужны, так как надо понимать "Что" требуется сделать, "Какие" объекты будут в будущей системе и "Какие" сценарии должны происходить. И сложность требований будет зависеть от самого продукта, так как в сложном бизнес-процессе будет присутствовать большое количество объектов и вариантов сценариев с ними. И именно для сбора требований к сложным продуктам помогает подход Event storming, так как знания о продукте или бизнес-процессах можно получить из устаревшей документации или их можно получить только у собственника бизнеса или product manager/project manager, грубо говоря данные требования не будут описаны в едином источнике знаний, а будут разбросаны по всем процессам и участникам вовлеченным в продукт.

Теперь поговорим именно о методе сбора требований "Event storming" - как же он поможет нам собрать требования:

Event storming - подход к решению проблем в процессе разработки, введённый итальянским программистом Альберто Брандолини, успешно используемый им в контексте DDD.

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

Главный результат — это быстрое исследование предметной области и фиксация знаний среди заинтересованных лиц

Структура Event storming:

🟨Пользователь Actor / Клиент - человек, выполняющий команду через представление
🟦Команда - это команда, выполняемая пользователем через представление агрегата, которая приводит к созданию события домена
🟨Агрегат - совокупность объектов домена, которые можно рассматривать как единое целое
🟥Внешняя система - сторонний поставщик услуг, например платежный шлюз или транспортная компания
🟧Событие домена - это событие, происходящее в бизнес-процессе
🟪Бизнес-процесс / Правило - обрабатывает команду в соответствии с бизнес-правилами и логикой
🟩Представление - это представление, с которым пользователи взаимодействуют для выполнения задачи в системе
Наглядное представление структуры приведено в прикрепленной картинке👇


Более подробно познакомиться с темой можно с помощью полезных материалов:

📌Event Storming на практических кейсах:
- Статья
- Презентация

📌Книга "Event Storming​" (если есть ссылки на прочтение книги, делитесь в комментах) - данную книгу можно назвать комиксом. Если вам интересна тема со стикерами, досками и kanban, то event storming скорее всего тоже вам «зайдет»‎. Книга Event Storming - рассказывает о технике специфицирования в терминах DDD, CQRS и Event Sourcing в форме увлекательной игры со стикерами, фломастерами и доской (доска может быть физической или виртуальной, но с физической гораздо веселее). С точки зрения наглядности, метод не успевает за Activity и BPMN-диаграммами. Но он гораздо более легковесный и прост в освоении и понимании.

#сбортребований

Автор: @ba_and_sa

​​ Цикл открытых вебинаров по BPMN2

📌Часть 1: BPM, BPMN, BPMS что это за термины и что они значат
📌Часть 2: основы BPMN
📌Часть 3: делаем хорошие схемы
📌Часть 4: остальные символы BPMN и межпроцессное взаимодействие
📌Часть 5: межпроцессное взаимодействие
📌Часть 6: ТЗ на процессное приложение
📌Часть 7: практика создания диаграмм аналитического уровня

Шпаргалка UML Diagram

В шпаргалке UML Notation вы узнаете:

- Вещи в UML
- Тип отношений в UML
- Диаграмма вариантов использования UML
- UML State Machine Diagram
- Диаграмма деятельности UML
- Диаграмма последовательности
- Диаграмма сотрудничества
- Временная диаграмма
- Диаграмма компонентов UML
- Диаграмма развертывания

Перейти

Техзадание на разработку сайта: запрещенные слова и выражения

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

Главная цель технического задания – убедиться, что клиент и исполнитель правильно поняли друг друга.

Перейти

​​50 лучших вопросов из интервью для бизнес-аналитиков

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

Перейти

DATApedia - канал про Data Science, и все что связано с данными, в котором вы найдете:

— Переведенные статьи;
— Полезные видео;
— Интересные опросы;
— Профессиональный юмор;

Присоединяйтесь, давайте расти как профессионалы вместе 😉

Подписаться: @data_science_wiki

​​Нефункциональные требования к системе

При разработке или при внедрении существующей Информационной системы специалисты обязательно столкнутся в своей работе с необходимостью определения требований.

Можно разделить требования на поведенческие (требования к поведению системы или требования, которые несут функциональный характер) и не поведенческие (которые несут нефункциональный характер).
К поведенческим требованиям можно отнести: функциональные требования, пользовательские требования и бизнес-требования.
А вот Нефункциональные требования (NFRs), являются часто просто всеобъемлющим термином, который охватывает все требования пользователя, не являющиеся в явном виде функциональными. NFRs иногда называют скорее не поведенческими, чем нефункциональными. К ним можно отнести: Бизнес-правила, системные требования, требования к документированию, требования к дизайну, требования к надежности и безопасности, и т.д.

✅Функциональные требования - описывают, что конкретно нужно реализовать в той или иной системе или продукте, какие действия должны производить пользователи в отношении данной разработки

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

К нефункциональным требованиям (NFRs) можно отнести:
— Технические ограничения (Restrictions) - ОС и их версии, сетевые особенности, браузеры и их версии, устройства и другие аппаратные требования
— Локализация (Localizability) - требования к возможности и простоте локализации приложения, перечень языков, на которые предполагается локализация приложения
— Производительность (Performance) - требования к количеству одновременно работающих пользователей, обслуживаемых транзакций, времени реакции, продолжительности вычислений, скорости и пропускной способности каналов связи
— Масштабируемость (Scalability) - оценивает самые высокие рабочие нагрузки, при которых система все еще будет справляться
— Надежность (Reliability) - поведение приложения при наступлении нештатных ситуаций, например, автоматический перезапуск, восстановление работы, дублирование важных данных, резервирование логики
— Доступность (Availability) - требования ко времени непрерывной работы приложения, например, 24x7, минимальное время простоя и т.п.)
— Безопасность (Security) - Как система и ее данные защищены от атак или несанкционированного доступа
— Удобство использования (Usability) - удобно ли людям пользоваться продуктом. Можно оценивать по 5 параметрам: Обучаемость, Эффективность, Запоминаемость, Ошибки, Удовлетворенность)

NFRs - должны быть измеримы и их можно проверить и протестировать

#сбортребований

Автор: @ba_and_sa

Более подробно познакомиться с темой помогут статьи:
📌Что такое нефункциональные требования, примеры, что в них должно быть
📌Нефункциональные требования к системе: понятие и примеры
📌О нефункциональных требованиях. Примеры, типы и подходы к их формированию

Основы SQL / Уроки по SQL для начинающих

📌 Урок 1 - Что такое SQL? Установка локального сервера
📌 Урок 2 - Создание БД, таблиц и работа с ними
📌 Урок 3 - Добавление и обновление записей в БД
📌 Урок 4 - Удаление данных из БД
📌 Урок 5 - Выборка данных из БД. Where, Order, Limit
📌 Урок 6 - Создание индексов и работы с ними
📌 Урок 7 - Объединение данных
📌 Урок 8 - Псевдонимы, функции и Group By

Перейти к плейлисту

Сам себе PKI: Теория на примере Let’s Encrypt

📌Часть 1 - в статье познакомимся с теорией и разберем пример, как происходит установка HTTPS соединения между браузером и веб-сайтом при использовании сертификатов Let's Encrypt

📌Часть 2 - в этой статье перейдем к практике и самостоятельно реализуем ту же самую схему