Документирование архитектуры

⏳ 6 мин | 🟤⚪️⚪️

Перейти | BA|SA

Как я парсил схемы Visio

⏳ 19 мин | 🟤🟤⚪️

Перейти | BA|SA

MES без розовых очков. Разбираем внедрение системы на практике, подводные камни и факторы успеха

⏳ 7 мин | 🟤⚪️⚪️

Перейти | BA|SA

Write. Review. Commit. Repeat. Как документируют в Postgres Professional

⏳ 3 мин | 🟤⚪️⚪️

Перейти | BA|SA

Салют! Сегодня на повестке дня - «Что такое UML? Это не язык, это — алфавит»

Часть 1:

Часто представляют, что UML — это единый язык для описания всего. Это не совсем так.
UML (Unified Modeling Language) — это, в первую очередь, набор нотаций. Как алфавит. Вы же не пишете все подряд, используя все буквы сразу? Вы составляете из букв слова, а из слов — предложения, подходящие для конкретной ситуации.

Так и с UML. Это инструментарий с правилами, из которого вы выбираете нужную «диаграмму» для решения конкретной задачи.

❓Для чего его используют? Главное — донести мысль.

Основная цель UML — визуализировать, специфицировать, проектировать и документировать артефакты разрабатываемой системы.
Проще говоря, чтобы:

1. Понять самому. Разложить сложную систему на части и увидеть взаимосвязи.
2. Объяснить другим. Донести архитектурные идеи до команды разработчиков, стейкхолдеров, тестировщиков.
3. Зафиксировать договоренности. Создать документацию, которая станет источником истины.

🧑‍💻 Как часто используют? Реальность против идеала.

Здесь есть разрыв между «как в книгах» и «как в жизни».

- В классических водопадных (Waterfall) проектах UML использовали часто и много, создавая полный комплект документации на этапе проектирования.

- В современных гибких методологиях (Agile, Scrum) подход изменился. Полные, детализированные диаграммы, которые долго рисовать и поддерживать, — это анти-паттерн. Они устаревают быстрее, чем код.

📈 Сегодня UML используют выборочно и прагматично:

- «На салфетке» (on a napkin). Быстро набросать схему взаимодействия на доске или в миро/ FigJam во время обсуждения. Это 80% пользы от UML.
- Для ключевых, сложных моментов. Описать архитектуру системы (Component Diagram), сложное бизнес-правило (State Machine Diagram) или запутанный процесс (Activity Diagram).
- В документации на высокоуровневом уровне. Чтобы новые члены команды или стейкхолдеры могли быстро войти в курс дела.

‼️Вывод: UML жив и актуален, но не как объемный документ, а как инструмент для коммуникации и проработки сложных мест.
_______________

🤝 В связке с какими нотациями используют?

1. BPMN (Business Process Model and Notation) — лучший друг и дополнение.

Это самая распространенная связка. BPMN идеально подходит для моделирования бизнес-процессов: кто, что, кому передает, какие решения принимает. Это взгляд бизнеса.

UML подхватывает эстафету на уровне системных требований и архитектуры.

· Пример: Сначала вы описываете процесс «Оформление заказа» в BPMN (с участием Клиента, Менеджера, Курьера). Затем вы берете часть этого процесса, которую должна автоматизировать система, и детализируете ее на UML Sequence Diagram (какие сообщения передаются между фронтендом, бэкендом и базой данных) или UML Activity Diagram (логика внутри системы).

2. User Stories / Use Cases.

Текстовая пользовательская история («Как [Пользователь], я хочу [сделать что-то], чтобы [получить пользу]») часто слишком абстрактна.

Ее прекрасно дополняет:
· UML Use Case Diagram: чтобы показать границы системы и всех акторов.
· UML Activity Diagram: чтобы детализировать сценарий успешного выполнения и альтернативные сценарии.

3. C4 Model (Context, Containers, Components, Code).

C4 — это современный и очень популярный подход для описания архитектуры программного обеспечения. Многие диаграммы C4-модели (особенно на уровнях Component и Code) можно прекрасно рисовать с использованием нотаций UML (Component Diagram, Class Diagram). C4 дает структуру, а UML — конкретный синтаксис.

Выбор всегда за вами, с чем компоновать UML, и вообще компоновать ли.

Продолжение следует 👇

Источник: @ba_and_sa

Часть 2: «Что такое UML? Это не язык, это - алфавит»

❓Используют ли UML для моделирования бизнес-процессов?

Краткий ответ: можно, но BPMN почти всегда лучше.

UML для этого предлагает две основные диаграммы:

- UML Activity Diagram: Хорошо подходит для описания потока работ (workflow) внутри системы или алгоритма. Она отлично показывает параллельные процессы, ветвления, слияния.

- UML Use Case Diagram: Показывает, что делает система с точки зрения пользователя, но не как и в какой последовательности.

Почему же BPMN чаще предпочтительнее для бизнес-процессов?

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

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

- Ясное разделение ответственности: Дорожки в BPMN наглядно показывают, кто за что отвечает — человек, отдел или система.

‼️Вывод: Используйте UML Activity Diagram, если вы описываете чисто системную логику или алгоритм.

Используйте BPMN, если вы описываете бизнес-процесс с участием людей, отделов и внешних систем.
_________________

Итог от меня:

Не заставляйте себя использовать все диаграммы UML. Это не спринт на 100 метров, а марафонский набор инструментов.

1. Начните с цели: «Что я хочу объяснить? Архитектуру? Взаимодействие? Состояние объекта?»
2. Выберите инструмент под задачу: Sequence — для взаимодействия, State Machine — для жизненного цикла, Component — для архитектуры.
3. Рисуйте максимально просто. Избегайте излишней детализации, если она не несет ключевой смысл.
4. Комбинируйте с BPMN и User Stories. Это синергия, которая покроет 99% ваших задач по анализу.

Удачи в моделировании!

Источник: @ba_and_sa

Идеи потерявшие смысл: Scrum и ООП

⏳ 8 мин | 🟤🟤⚪️

Перейти | BA|SA

Карта бизнес-способностей. Просвечиваем корпоративные боли и лечим их архитектурно: эволюция бизнес-аналитика

⏳ 10 мин | 🟤🟤⚪️

Перейти | BA|SA

Салют! Продолжим тему UML-моделирования, и рассмотрим 12 диаграмм UML, которые делятся на два основных типа: структурные и поведенческие.

Структурные диаграммы описывают структуру системы (например, диаграмма классов, компонентов, развертывания), а поведенческие — её поведение и взаимодействия (например, диаграмма деятельности, последовательности, состояний). 

1️⃣ Структурные диаграммы:

- Диаграмма классов: Отображает классы, их атрибуты, методы и связи между ними. 

- Диаграмма компонентов: Показывает, как компоненты системы (например, сервисы, приложения) организованы и зависят друг от друга. 

- Диаграмма развертывания: Описывает физическое развертывание системы на аппаратных узлах. 

- Диаграмма объектов: Представляет собой моментальный снимок системы с конкретными объектами и связями между ними. 

- Диаграмма пакетов: Группирует элементы модели в пакеты и показывает зависимости между этими пакетами. 

- Диаграмма композитной структуры: Показывает внутреннюю структуру класса и взаимодействие его элементов. 

- Диаграмма профилей: Позволяет определять пользовательские стереотипы, теги и ограничения для моделирования. 


2️⃣ Поведенческие диаграммы:

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

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

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

- Диаграммы взаимодействия:

- Диаграмма последовательности: Иллюстрирует, как объекты взаимодействуют друг с другом во времени, показывая последовательность вызовов. 

- Диаграмма коммуникации: Похожа на диаграмму последовательности, но фокусируется на сообщениях, которыми обмениваются объекты, отображая их на общей линии, а не в отдельной временной шкале. 

- Диаграмма обзора взаимодействия: Позволяет представить взаимодействие нескольких диаграмм последовательности или коммуникации в виде единой диаграммы. 

- Временная диаграмма: Показывает, как состояние объекта изменяется с течением времени, накладывая временные ограничения

Источник: @ba_and_sa

Построение и развитие ИТ-архитектуры организации

12 ЭТАПОВ ПОСТРОЕНИЯ И РАЗВИТИЯ ИТ-АРХИТЕКТУРЫ ОРГАНИЗАЦИИ:

1. Разработка ИТ‑стратегии
2. Разработка иерархического реестра (каталога) всех ИТ‑систем и ИТ‑платформ организации
3. Заполнение детальных параметров (карточек, спецификаций) всех ИТ‑систем и модулей
4. Разработка архитектурных моделей ИТ-систем
5. Разработка графических моделей по интеграции (связям) ИТ-систем
6. Разработка иерархического реестра (каталога) всех баз данных (структур данных) и их параметров
7. Разработка технической архитектуры и дополнительных моделей (в зависимости от задач)
8. Установление связей объектов и моделей ИТ‑архитектуры с объектами и моделями бизнес-архитектуры
9. Проработка операционных рисков (ИТ-рисков) и системы информационной безопасности
10. Разработка нормативных документов и форм документов
11. Проведение аудита (оценки) ИТ-архитектуры по чек-листу и аналитических работ
12. Сбор новых требований и задач к автоматизации и цифровизации от подразделений

⏳ 10 мин | 🟤⚪️⚪️

Перейти | BA|SA

Рисуем бизнес-процессы в нотации Archimate

⏳ 5 мин | 🟤⚪️⚪️

Перейти | BA|SA

Один Swagger вместо сотни страниц Confluence: как в Рунити навели порядок в API-документации

⏳ 9 мин | 🟤⚪️⚪️

Перейти | BA|SA

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

⏳ 7 мин | 🟤⚪️⚪️

Перейти | BA|SA

Паттерны интеграции API

⏳ 13 мин | 🟤⚪️⚪️

Перейти | BA|SA

Не только трансформеры: за пределами стандартных архитектур LLM

⏳ 31 мин | 🟤🟤🟤

Перейти | BA|SA

Салют! Сегодня затрону тему «Выгорание на рабочем месте». Все чаще получаю сообщения в личку на эту тему 🥲

Да, за 12+ лет в аналитике я сама прошла через несколько циклов выгорания в начале своего пути. Это не стыдно признать. В нашей профессии это почти профессиональное заболевание: постоянный цейтнот, работа с большими объемами информации, необходимость быть «мостом» между разными, часто конфликтующими сторонами, и ощущение, что твой труд — это бесконечный список правок и доработок.

Поделюсь не теорией, а именно своим выстраданным опытом.

Разделю его на две части:
- Часть 1: профилактика (как не доводить)
- Часть 2: «скорая помощь» (если уже выгорел).

1️⃣ Часть 1. План профилактики: Как не довести себя до состояния "я не могу"

Это не разовые действия, а система привычек. Как гигиена для ума.

1️⃣ Жесткие границы между работой и личной жизнью.
Это основа основ. Аналитик — это не пожарная служба 24/7 (если только это не прописано в вашем договоре и не оплачивается соответственно).

Что я делаю:

· Что я делала раньше (в офисе): Мой рабочий компьютер выключается в 18:30-19:00 (в зависимости от вашего договора). После этого я не проверяю рабочие чаты и почту. Точка. На телефон рабочие мессенджеры не установлены (только телега). Если нужна срочная связь — пусть звонят (такие случаи можно пересчитать по пальцам за год).
· Что делаю сейчас, уже с опытом (на удаленке): работаю в день не более 8-9 часов, либо же днем, либо вечером, в зависимости от своих личных планов (прелести удаленки☺️) Иногда работаю значительно меньше 🙈

· Физическое разделение: Если работаешь из дома, выдели угол, который ты покидаешь в конце дня. В моем случае кабинет в доме и отдельный рабочий ноут.

2️⃣ Управление энергией, а не временем.
Мы не роботы, и не лошади. Наша продуктивность волнообразна.

Что я делаю:

· Я отследила свои «биологические часы». Пик аналитической деятельности у меня с 10 до 13 и с 16 до 18. Бывает, что открывается втрое дыхание по вечерам)) В это время я занимаюсь самой сложной работой: проектирование, глубокий анализ, моделирование и тд. А в «провалы» (после обеда) — провожу митинги, отвечаю на почту, делаю рутинные правки в документах. В любом случае стараюсь митинги назначать на первую половину дня, но конечно это не всегда так
· Правильное разделение рабочего времени: главное чтобы не было так, что в один день много встреч или вообще только встречи, всегда распределяю свое рабоче время и на встречи и на остальную работу 50/50 или 30/70.
· Техника «Помидора»: 25 минут
фокуса, 5 минут отдыха. В эти 5 минут я встаю из-за стола, смотрю в окно, пью воду. Не листаю соцсети! Полный отдых от техники.

3️⃣ Регулярный «апгрейд» навыков, но без фанатизма.
Выгорание часто приходит от ощущения рутины и стагнации.

Что я делаю:

· Я выделяю 2-4 часа в неделю на то, чтобы изучить что-то новое, не связанное с текущим проектом. Новый инструмент для визуализации (Miro, FigJam), чтение статьи про Event Storming, просмотр вебинара по новой методологии. Это дает ощущение развития и отрывает от текучки

· Я выделяю 1-2 часа ежедневно для своего канала (написание постов, поиск и прочтение статей и др.)

4️⃣ Честность с собой и руководством.

Что я делаю:

· Я научилась говорить «нет» или «это потребует больше времени, чем вы думаете». Я не боюсь сообщать о перегрузе. Фраза «У меня сейчас полная загрузка по проекту X. Если это приоритетнее, давайте обсудим, что мы можем сдвинуть» — работает безотказно.

· Ведение «защищенного» списка задач: У меня всегда есть видимый для руководства бэклог. Когда приходит новая срочная задача, мы вместе решаем, что из него выходит. Это снимает ответственность за расстановку приоритетов только с тебя

5️⃣ Физическая активность и хобби «не за компьютером».
Наша работа — сидячая и умственная. Телу и мозгу нужна компенсация.

Что я делаю:

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

Источник: @ba_and_sa

Продолжение следует👇

Часть 2. «Скорая помощь» 🚑: Если ты уже выгорел и не можешь работать

Было у меня такое состояние: открываешь Jira, а глаза не фокусируются. Читаешь ТЗ в пятый раз и не понимаешь смысла. Появляется физическое отвращение к мысли о работе. по утрам не хочешь даже вставать, чтобы идти на работу 🥲.

Вот мой план по выходу из этого состояния:

Шаг 0️⃣: Признать проблему.
Не винить себя. Не говорить «я ленивая/ленивый». Выгорание — это не лень, это истощение ресурсов. Ты не сломался, ты устал. Это лечится.

Шаг 1️⃣: Взять паузу. Идеально — отпуск. Если нет — больничный.
Не «отгул», а именно полноценный отдых минимум на 1-2 недели. Цель — НЕ ДЕЛАТЬ НИЧЕГО связанного с работой. Никаких курсов, никакого «подучить английский для карьеры». Лежать, смотреть сериалы, гулять, спать. Дать мозгу отдохнуть. Съездить на море/горы/СПА-отель и тд. Провести все эти дни с семьей или друзьями. Полный релакс от работы!!!!

Шаг 2️⃣: Провести «аудит» причин.
На паузе, когда немного отпустит (на день 6-8), я беру блокнот и анализирую (куда же без нашего аналитического мышления!). Что именно вызывает наибольшее истощение?

- Люди? (Постоянные конфликты, токсичный менеджер, неадекватные стейкхолдеры)

- Процессы? (Адский воркфлоу, бесконечные согласования, бюрократия)

- Задачи? (Они стали слишком рутинными/скучными/непонятными)

- Отсутствие смысла? (Не понимаю, зачем я делаю этот проект, не вижу ценности)

- Перегруз? (Объем работы физически нереализуем)

Это помогает не валить все в кучу и понять, с чем именно бороться.

Шаг 3️⃣: Начать с малого. Возвращение «в строй».
После паузы возвращаться постепенно.

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

- Фокус на простых, завершаемых задачах: Выбрать 1-2 небольшие задачи, которые можно сделать и закрыть. Это дает быстрое ощущение результата и победы.

- Снизить планку: Первое время не стремиться к идеальным артефактам. Сделать «достаточно хорошо» и двигаться дальше. Перфекционизм — союзник выгорания.

Шаг 4️⃣: Внедрить изменения на основе «аудита».
Если понял причину — действуй.

- Если люди — начинай фиксировать общение (письма вместо звонков), учиться мягко противостоять, или, что честно, обновлять резюме.

- Если процессы — предложи улучшения. Возможно, автоматизировать что-то, изменить шаблоны документов. Поделись болью с тимлидом.

- Если задачи — поговори с руководителем о смене проекта или о добавлении более интересных задач в твой пул.

- Если перегруз — возвращаемся к пункту про «честность и границы».

Шаг 5️⃣ (самый сложный): Обратиться за помощью.
Это не слабость. Можно обратиться к психологу, если он тебе помогает (скажу честно, это не моя тема). Также можно говорить с понимающим руководителем, ментором. Иногда просто проговаривание проблемы с коллегой, который тебя понимает, снимает 50% напряжения.

‼️ Если не помогает ничего, меняй проект/работу или вообще сферу!! Работать и истощать себя нельзя, не получается, пробуй себя в чем-то другом!!! Не бойся перемен!!!

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

____________________

Резюме от «опытного» коллеги:

Выгорание — это сигнал системы о том, что выбранный режим работы несовместим с жизнью. Это не ваша личная неудача.

· Чтобы не доводить: Выстраивай границы, управляй энергией, а не временем, и имей жизнь вне работы.
· Если выгорел: СТОП -> ОТДОХНИ -> ПРОАНАЛИЗИРУЙ -> ВОЗВРАЩАЙСЯ ПОСТЕПЕННО -> ВНЕДРИ ИЗМЕНЕНИЯ.

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

Удачи всем!!!

Источник: @ba_and_sa