Как повысить свою эффективность с помощью диаграмм
Всем привет! Меня зовут Сергей, и сейчас я работаю в роли Lead Business Analyst на одном из проектов в компании Yalantis. В данной статье я поделюсь своим опытом использования диаграмм, и тем, как они помогают сделать мою работу эффективнее. Материал будет полезен для начинающих аналитиков, а также для всех, кто хочет освежить свои знания.
А конкретно я расскажу о:
- ERD
- Activity diagram
- State machine
В чем ценность диаграмм
Предлагаю начать с базы и вспомнить/прояснить, зачем вообще нужны диаграммы, и для решения каких задач они могут нам понадобиться.
Everyday routine аналитика — работа с неопределенностями и поиск самых эффективных решений для бизнеса. В дальнейшем одним из челленджей становится правильное донесение информации до вовлеченных стейкхолдеров. Именно в этом нам помогают диаграммы, так как они позволяют собрать всю информацию в кучу и максимально наглядно визуализировать ее для комфортного восприятия.
Аналитический паралич
Перед тем как мы перейдем к рассмотрению вышеупомянутых диаграмм, важно очертить одну из проблем, с которой часто сталкиваются бизнес-аналитики — некий «аналитический паралич».
Это когда в ходе анализа вы начинаете буквально «обмазываться» инструментами (диаграммами), когда в них вообще нет необходимости. Из-за слишком большого выбора вы зависаете на этапе принятия решения и не знаете, что нужно использовать.
Поэтому в рамках этой статьи я также поделюсь своими триггерами, которые я создал для себя, чтобы понимать, когда уместно использовать тот или иной инструмент.
Entity relationship diagram
ERD (entity relationship diagram) — тип структурных диаграмм, который используется для проектирования баз данных. Простыми словами — они помогут вам разложить вашу систему на составляющие и понять, как эти составляющие связаны между собой.
В каких случаях стоит их применять:
- у вас большой и сложный проект, в котором вам необходимо увидеть картину целиком;
- у вас сжатые сроки и нет месяцев на погружение в проект;
- у вас есть «слепые пятна» в текущем проекте;
- хотите повысить эффективность онбординга новых членов команды.
Есть три типа (уровня абстракции) ERD:
- Концептуальная. Самая простая, и чаще всего аналитики работают с ней. Показывает связи между сущностями.
- Логическая. Содержит более подробную информацию в сравнении с концептуальной моделью. На этом уровне определяются более подробные операционные и транзакционные сущности.
- Физическая. Это визуальное представление вашей базы данных: ее обычно создают архитекторы или разработчики.
Как строить
Для того, чтобы правильно подойти к построению ERD диаграммы, сперва необходимо определить все возможные сущности:
После этого нам нужно связать эти сущности между собой, чтобы определить зависимости:
Завершающим этапом будет определение типа этих зависимостей.
Основные типы связей:
- Воронья лапка (слева)
- (Min, max)-notation Жана-Раймона Абриаля (справа)
Результатом у нас получится эта диаграмма:
На ней мы видим:
- Один студент может иметь свой уникальный ID, как и сам ID может иметь только одного уникального студента.
- В случае, если студент выпустился, то его ID нельзя назначить другому студенту, и наоборот.
- Одна комната может вмещать в себя как множество студентов, так и ни одного.
- Основное отличие типа связи «1 и только 1» от просто «1» — это то, что в случае «просто 1» студент может поменять одну комнату на другую, но по прежнему он не может находиться в двух комнатах одновременно.
- Аналогично с кроватями и телевизором, мы спокойно их можем перенести в другую комнату.
Activity diagram
Переходим к UML-диаграммам, а начнем с Activity diagram.
Согласно скучному описанию, взятому из Википедии, активити диаграмма — это графическое представление процесса с шагами, активностями, итерациями и параллелизмом.
Если по-простому — это карта, которая показывает, как участники процесса попадают из пункта А в пункт Б.
Для очень упрощенного понимания активити диаграммы я выберу в качестве примера карту путешествия Фродо и Бильбо по Средиземью.
У нас есть участники процесса, начало и конец, а также шаги, которые необходимо выполнить, чтобы попасть из пункта А в пункт Б.
Типичные ошибки
Одна диаграмма для всех процессов. Довольно часто происходит ситуация, когда в одной диаграмме пытаются отобразить все возможные процессы. Тогда диаграмму становится довольно сложно читать, а еще сложнее поддерживать, что приводит к неизбежному — диаграмма теряет свою актуальность.
Микс поведенческой и структурной диаграммы. Вторая распространенная ошибка — решение аналитика отображать как действия, так и статусы выполнения этих действий в пределах одной диаграммы. В таком случае диаграмма превращается в структурную (которой она, по сути, не является), она далека от действительности и читать ее просто невозможно.
Когда стоит ее применять:
- вы хотите описать некую последовательность действий;
- во время grooming sessions вы хотите описать для команды бизнес-процесс, чтобы у них было понимание, что в целом происходит, а после — перейти к деталям;
- вы хотите быть уверенными в том, что вы с заказчиком на одной волне: видите и понимаете процесс одинаково;
- вам необходимо проанализировать выбранный процесс в деталях, чтобы выявить все тонкие места и, в итоге, правильно их обработать.
Как строить
Обычно при построении процессных диаграмм я стараюсь придерживаться плана из трех шагов:
- Planning
- Sketching
- Specification
Первый шаг — это планирование. Тут вам нужно определить основных участников процесса, понять, где процесс начинается, очертить, что является целью этого процесса, и где он заканчивается.
Следующий этап — это создание наброска. Тут вам нужно наметить точку А и точку Б и стрелки с названием шагов (я обычно это делаю от руки в блокнотах).
Старайтесь ее упростить на этом этапе, используя негласное правило «от 5 до 15 шагов».
Завершающий этап — наводим красоту согласно аннотации.
Далее приведены основные элементы activity diagram:
Часто задаваемые вопросы
Что вот это и когда его рисовать?
Чаще всего это используют, когда нужно отобразить, что в результате выполнения альтернативного действия процесс для пользователя заканчивается.
Пример: если пользователь подает заявку в течение пяти дней после регистрации, тогда он может перейти на следующий шаг. Если пользователь подает заявку через пять дней, тогда он получает отказ и не может перейти дальше.
Что за синхронизация (толстые горизонтальные линии)?
Они показывают, что следующие действия выполняются параллельно.
Как мне отобразить, что пользователю нужно выбрать одну из нескольких опций, так как дальше процесс идет по-разному?
Здесь придется немного отойти от аннотации, но лучше всего использовать ромб.
State machine
Следующая диаграмма тоже из семейства UML — State machine.
State machine — поведенческая диаграмма, которая позволяет отобразить последовательность событий, из-за которых один объект может принимать разные состояния.
Для простоты понимания далее пример состояний моей женщины.
Что мы видим на этой диаграмме?
Есть объект — «Моя девушка». Этот объект может принимать пять состояний и меняет он их в зависимости от того, какие действия (триггеры) я выполняю.
Если перевести это в Use case, то получится следующее:
- Я делаю какую-то пакость.
- Девушка перестает со мной общаться (Silent mode).
- Я пытаюсь узнать, что случилось.
- Девушка отвечает на все вопросы «Все ок» («Everything ok» mode).
- Я перестаю выполнять какие-либо действия, чтобы узнать причину прекращения диалога со мной.
- Девушка начинает злиться (Berserker mode).
- Я предлагаю любимую еду.
- Девушка обращает на меня внимание (Mr. Pukhlya mode).
- Девушка съедает предложенную еду.
- Девушка опять меня любит («Love is back» mode).
Пример с девушкой, конечно, шутливый, но так вам стало нагляднее, как работает State Machine.
Так как люди в большинстве своем визуалы, то картинки ими воспринимаются намного проще, и в случае большего количества состояний (статусов) текст будет восприниматься еще сложнее.
Когда стоит применять:
- у вас есть один объект, который может принимать различные состояния;
- вы хотите описать сложную логику того, как один объект изменяет свои состояния, не используя при этом кучу текста;
- вам необходимо удостовериться, что все участники процесса разработки on the same page.
Как строить
Чтобы построить такую диаграмму правильно, сначала определим все известные нам состояния объекта.
На следующем и завершающем этапе необходимо назначить триггеры, по которым наш объект будет переходить из одного состояния в другое.
Хочу показать еще один альтернативный способ отображения и анализа состояний объекта. В деталях об этом способе можно почитать у Вигерса («Разработка требований к программному обеспечению»).
Читать нужно слева вверх
- Из статуса «В подготовке» в статус «Отложен» заказ переходит, если пользователь сохраняет неполный заказ.
- Из статуса «Отложен» в статус «В подготовке» заказ переходит, если пользователь открывает неполный заказ.
Заключение
Аналитик всегда должен пополнять свой набор инструментов и совершенствовать свое владение ими, чтобы независимо от контекста, в котором он находится, и задачи, которую ему нужно решить, он смог найти самый эффективный solution.
Всем понятных и эффективных диаграмм!
22 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів