Как повысить свою эффективность с помощью диаграмм

Всем привет! Меня зовут Сергей, и сейчас я работаю в роли Lead Business Analyst на одном из проектов в компании Yalantis. В данной статье я поделюсь своим опытом использования диаграмм, и тем, как они помогают сделать мою работу эффективнее. Материал будет полезен для начинающих аналитиков, а также для всех, кто хочет освежить свои знания.

А конкретно я расскажу о:

  • ERD
  • Activity diagram
  • State machine

В чем ценность диаграмм

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

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

Аналитический паралич

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

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

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

Entity relationship diagram

ERD (entity relationship diagram) — тип структурных диаграмм, который используется для проектирования баз данных. Простыми словами — они помогут вам разложить вашу систему на составляющие и понять, как эти составляющие связаны между собой.

В каких случаях стоит их применять:

  • у вас большой и сложный проект, в котором вам необходимо увидеть картину целиком;
  • у вас сжатые сроки и нет месяцев на погружение в проект;
  • у вас есть «слепые пятна» в текущем проекте;
  • хотите повысить эффективность онбординга новых членов команды.

Есть три типа (уровня абстракции) ERD:

  1. Концептуальная. Самая простая, и чаще всего аналитики работают с ней. Показывает связи между сущностями.
  2. Логическая. Содержит более подробную информацию в сравнении с концептуальной моделью. На этом уровне определяются более подробные операционные и транзакционные сущности.
  3. Физическая. Это визуальное представление вашей базы данных: ее обычно создают архитекторы или разработчики.

Как строить

Для того, чтобы правильно подойти к построению ERD диаграммы, сперва необходимо определить все возможные сущности:

После этого нам нужно связать эти сущности между собой, чтобы определить зависимости:

Завершающим этапом будет определение типа этих зависимостей.

Основные типы связей:

  • Воронья лапка (слева)
  • (Min, max)-notation Жана-Раймона Абриаля (справа)

Результатом у нас получится эта диаграмма:

На ней мы видим:

  • Один студент может иметь свой уникальный ID, как и сам ID может иметь только одного уникального студента.
  • В случае, если студент выпустился, то его ID нельзя назначить другому студенту, и наоборот.
  • Одна комната может вмещать в себя как множество студентов, так и ни одного.
  • Основное отличие типа связи «1 и только 1» от просто «1» — это то, что в случае «просто 1» студент может поменять одну комнату на другую, но по прежнему он не может находиться в двух комнатах одновременно.
  • Аналогично с кроватями и телевизором, мы спокойно их можем перенести в другую комнату.

Activity diagram

Переходим к UML-диаграммам, а начнем с Activity diagram.

Согласно скучному описанию, взятому из Википедии, активити диаграмма — это графическое представление процесса с шагами, активностями, итерациями и параллелизмом.

Если по-простому — это карта, которая показывает, как участники процесса попадают из пункта А в пункт Б.

Для очень упрощенного понимания активити диаграммы я выберу в качестве примера карту путешествия Фродо и Бильбо по Средиземью.

У нас есть участники процесса, начало и конец, а также шаги, которые необходимо выполнить, чтобы попасть из пункта А в пункт Б.

Типичные ошибки

Одна диаграмма для всех процессов. Довольно часто происходит ситуация, когда в одной диаграмме пытаются отобразить все возможные процессы. Тогда диаграмму становится довольно сложно читать, а еще сложнее поддерживать, что приводит к неизбежному — диаграмма теряет свою актуальность.

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

Когда стоит ее применять:

  • вы хотите описать некую последовательность действий;
  • во время grooming sessions вы хотите описать для команды бизнес-процесс, чтобы у них было понимание, что в целом происходит, а после — перейти к деталям;
  • вы хотите быть уверенными в том, что вы с заказчиком на одной волне: видите и понимаете процесс одинаково;
  • вам необходимо проанализировать выбранный процесс в деталях, чтобы выявить все тонкие места и, в итоге, правильно их обработать.

Как строить

Обычно при построении процессных диаграмм я стараюсь придерживаться плана из трех шагов:

  1. Planning
  2. Sketching
  3. Specification

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

Следующий этап — это создание наброска. Тут вам нужно наметить точку А и точку Б и стрелки с названием шагов (я обычно это делаю от руки в блокнотах).

Старайтесь ее упростить на этом этапе, используя негласное правило «от 5 до 15 шагов».

Завершающий этап — наводим красоту согласно аннотации.

Далее приведены основные элементы activity diagram:

Часто задаваемые вопросы

Что вот это и когда его рисовать?

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

Пример: если пользователь подает заявку в течение пяти дней после регистрации, тогда он может перейти на следующий шаг. Если пользователь подает заявку через пять дней, тогда он получает отказ и не может перейти дальше.

Что за синхронизация (толстые горизонтальные линии)?

Они показывают, что следующие действия выполняются параллельно.

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

Здесь придется немного отойти от аннотации, но лучше всего использовать ромб.

State machine

Следующая диаграмма тоже из семейства UML — State machine.

State machine — поведенческая диаграмма, которая позволяет отобразить последовательность событий, из-за которых один объект может принимать разные состояния.

Для простоты понимания далее пример состояний моей женщины.

Что мы видим на этой диаграмме?

Есть объект — «Моя девушка». Этот объект может принимать пять состояний и меняет он их в зависимости от того, какие действия (триггеры) я выполняю.

Если перевести это в Use case, то получится следующее:

  1. Я делаю какую-то пакость.
  2. Девушка перестает со мной общаться (Silent mode).
  3. Я пытаюсь узнать, что случилось.
  4. Девушка отвечает на все вопросы «Все ок» («Everything ok» mode).
  5. Я перестаю выполнять какие-либо действия, чтобы узнать причину прекращения диалога со мной.
  6. Девушка начинает злиться (Berserker mode).
  7. Я предлагаю любимую еду.
  8. Девушка обращает на меня внимание (Mr. Pukhlya mode).
  9. Девушка съедает предложенную еду.
  10. Девушка опять меня любит («Love is back» mode).

Пример с девушкой, конечно, шутливый, но так вам стало нагляднее, как работает State Machine.

Так как люди в большинстве своем визуалы, то картинки ими воспринимаются намного проще, и в случае большего количества состояний (статусов) текст будет восприниматься еще сложнее.

Когда стоит применять:

  • у вас есть один объект, который может принимать различные состояния;
  • вы хотите описать сложную логику того, как один объект изменяет свои состояния, не используя при этом кучу текста;
  • вам необходимо удостовериться, что все участники процесса разработки on the same page.

Как строить

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

На следующем и завершающем этапе необходимо назначить триггеры, по которым наш объект будет переходить из одного состояния в другое.

Хочу показать еще один альтернативный способ отображения и анализа состояний объекта. В деталях об этом способе можно почитать у Вигерса («Разработка требований к программному обеспечению»).

Читать нужно слева вверх

  • Из статуса «В подготовке» в статус «Отложен» заказ переходит, если пользователь сохраняет неполный заказ.
  • Из статуса «Отложен» в статус «В подготовке» заказ переходит, если пользователь открывает неполный заказ.

Заключение

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

Всем понятных и эффективных диаграмм!

👍НравитсяПонравилось20
В избранноеВ избранном9
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Спасибо за статью! Подскажите, с помощью каких инструментов вы рисовали диаграммы, или может вы можете посоветовать перечень удобных ресурсов для их создания?

Все рисовал в draw.io, мне еще нравится miro.com
есть еще lucid.co из популярных

Спасибо, наконец-то разобрался с Диаграммой состояний :)

Круто! Рад, что статья помогла)

Сергей, прежде всего БОЛЬШОЕ спасибо за популяризацию моделирования в работе BA/SA — это очень важное дело!
Но как к коллеге, позволю себе несколько замечаний. Я считаю что на тех кто несет знания лежит большая ответственность за качество материала и точность.
Поэтому надеюсь мои замечания будут восприняты исключительно в объективном ключе в нашем общем деле:
1) UML State machine — примеры в статье не соответствуют UML нотации (почему состояния в виде прямоугольников), также нет начала/окончания. Понятно что это как бы мелочи, но зачем отступать от стандарта (www.uml-diagrams.org/...​te-machine-diagrams.html
2) Также позволю себе покритиковать Вигерса с примером с таблицей состояний и триггеров: тоже нет понимания/индикации начала/окончания состояний; не очень интуитивно откуда и куда идет переход (с строк в колонки, или наоброт); таблица не очень удобна в случае когда между двумя состояними возможен переход разными триггерамм со своими теребованиями. Все таки UML State machine — более легко и быстро воспринимается.
4) Полезно давать реальные приемы с проектов, чем абстракции — вот например мои с одного проекта (в том числе с иерархической State machine): drive.google.com/...​F5opkPQY/view?usp=sharing и drive.google.com/...​eHtl7HB0/view?usp=sharing
5) В примере с Activity diagram — некрасивое оформление Object: вертикальный текст, да еще в разные стороны. Надеюсь это просто небрежность, а не указание на какой то смысл/требования.
6) Неточности по ERD. «ERD (entity relationship diagram) — тип структурных диаграмм, который используется для проектирования баз данных.» — ну как да, но их назначение все таки — описать/моделировать отношения между сущностями/объектами для понимания предметной области и данных ею используемых. Вопрос хранения данных в БД, это уже потом;
Есть разные нотации ERD — желательно знать еще такие нотации: chen’s erd notation, crow’s foot erd notation — они тоже часто используются; три типа (уровня абстракции) ERD — Концептуальная, Логическая, Физическая — мне кажеться как то не очень понятно в чем все таки различие (для тех кто этого не знает).
7) Ну и самое главное, на мой взгляд, не раскрыто: " В данной статье я поделюсь своим опытом использования диаграмм, и тем, как они помогают сделать мою работу эффективнее." — как это помогает быть эффективным, как именно и почему, кому будет польза? Статья 99.9% описывает несколько видов диаграмм, а что Sequence Diagrams — не увеличивают эффективности?

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

Sequence Diagrams — мне они очень нравятся, но опять же таки к ней будет много вопросов.
И как показываем практика, основанная на моем опыте (что указал в статье), новички чаще применяет все же эти 3 вида диаграмм (ERD, State machine, Activity).

Годный материал, Сергей! И примеры интересные подобраны

А кто эти люди, кто еще не знает этих диаграмм? Надеюсь они не работают программистами или аналитиками. Вроде и QA обычно это изучают.

Есть пять уровней «знания» диаграмм:
Первый — ты можешь создавать диаграммы
Второй — ты можешь внятно читать, ту диаграмму, что ты создал, даже по истечении некоторого времени
Третий — другие могут читать те диаграммы, что ты создал
Четвертый — ты можешь обсуждать свои диаграммы с теми, кто их может читать
Пятый — ты можешь читать диаграммы других

Большинство людей думают, что они на пятом уровне, особенно те, кто это изучали. Но это ошибка.

Шестой — ты знаешь, что не сможешь из них получить мысль автора, потому просто пропускаешь при чтении. Потому начинай с третьего уровня сразу. И только те диаграммы, которые понятны с ходу, ты не пропустишь. Да, так изобрели инфографику.

Это уже уровни просветления пошли, диаграммы на них вообще не нужны.

Ну вот видишь, за 3 строчки коммента просветлился. Неси мне какаву

Ну я не знаю этих диаграмм. Узнавал их раза три (точно уже не вспомню, может чаще), когда было надо, и это сливалось из памяти буквально сразу же. Потому что этот способ моделирования для памяти противен и конфликтует с тем, что там уже есть.

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

Пример с девушкой: почему понадобилась свинья? То есть почему понадобилось нарушить формальные правила языка диаграммы, чтобы объяснить очень простое явление? Правильный ответ настолько прост, что теоретики умирают от обезвоживания, истекая слюной в попытке доказать его неверность. НЕ ДОЛЖНО БЫТЬ языка диаграмм, если это только не узкоспециализированное применение, где этих диаграмм много, одинаковых, и имеет смысл тратить время-деньги на обучение их понимать. Пример такого исключения — построение автоматики промышленных микроконтроллеров. Они прямо таки программируются языком диаграммы, её нужно рисовать в редакторе.

А вот правило: диаграмма должна быть понятна даже тем, кто не знает канонов её рисования. Потому и свинья. Потому что в памяти читателя уже есть свинья. А вот связи типа «воронья лапка» там нет, и запомнить, что ДВЕ чёрточки означают ОДНО единственное значение — увы, нереально, это разрыв шаблонов. Как и то, что знак женщины ♀ означает «один или ноль», а совсем не коннектор с предварительными ласками :)

СВОЮ эффективность вы при помощи диаграмм не повысите. Но можете повысить ПОНИМАНИЕ того, что вы хотите сказать. Используйте шаблоны, уже существующие в памяти, их более чем достаточно. А бюрократию — никогда, это организационный рак.

Мне много раз при помощи диаграмм удавалось обьяснить заказчикам то что не получалось словами (там где навороченная логика а нужно обсудить) поэтому они да, для повышения эффективности коммуникации

Но не при помощи этих монструозных диаграмм, где 1 строчку текста нужно объяснять диаграммой на страницу и ещё текста на 2 страницы чтобы объяснить как читать диаграмму, и ещё страницу объяснения самой диаграммы, потому что то что там нарисовано тупо непонятно.

Возможно получилось бы и с помощью метафор/абстрактных кружков.

Я из курса по UML в универе запомнил, что мы сделали 4 «разных» диаграммы на пз и итогом было написать программу.
Я написал и даже обосновал. Но там минимум еще 3 или 4 варианта при исчерпывающем условии из разных диаграмм (состояний, классов и так далее) можно было наковырять, причем они бы не противоречили

Такие люди есть и их становиться все больше, и я имею в виду именно программистов и аналитиков. Увы это реальность.

Наливает ли себе аналитик, если он наливает только тем, кто сам себе не наливает?

Чтобы понять рекурсию, нужно сначала понять рекурсию.

Да что сложного-то в рекурсии?

Подписаться на комментарии