Хороший курс по проектированию микросервисов — редкость.

Здесь даём ровно то, что нужно в реальной практике:
— Декомпозиция бизнес-домена — как разбить монолит на сервисы и обосновать решение;
— Интеграции между сервисами — REST, события, очереди и когда что выбирать;
— Паттерны и антипаттерны микросервисной архитектуры — чтобы отвечать не «по книжке», а из практики.

Плюс — живые разборы кейсов и канал с быстрыми ответами на вопросы.

Курс ведёт архитектор Кирилл Ветчинкин — разработчик с 15-летним опытом, 8+ лет внедряет MSA.
Если вы работаете с распределенными системами, хотите разложить в голове паттерны и научиться не просто «пилить микросервисы», а понимать, зачем они бизнесу — присоединяйтесь.

📌 Старт: 9 сентября
👉 https://microarch.ru/courses/microservices?utm_source=posev&utm_medium=erid:2VtzqxAo18TN&utm_campaign=5

Реклама. ИП Ветчинкин К.Е. ИНН: 773376451099 Erid: 2VtzqxAo18T

у вас такое практикуют? 😁

🎬 Основы UML: Диаграммы вариантов использования (Use Case Diagrams) 🤝

Привет, системные аналитики! 🤓

Сегодня погружаемся в мир UML и разбираемся с одним из самых полезных инструментов для моделирования требований – диаграммами вариантов использования (Use Case Diagrams).

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

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

• Актор (Actor): Представляет собой пользователя (человека, систему, устройство), который взаимодействует с системой. Обозначается в виде человечка 🧍.
• Пример: Клиент, Администратор, Банковская система.
• Вариант использования (Use Case): Описывает конкретную задачу или функцию, которую выполняет система для актора. Обозначается в виде овала ⚪️.
• Пример: "Оформить заказ", "Войти в систему", "Просмотреть отчет".
• Отношения (Relationships): Связывают акторов и варианты использования, а также сами варианты использования между собой.

Типы отношений:

• Ассоциация (Association): Указывает на взаимодействие актора с вариантом использования. Обозначается линией ➡️.
• Пример: Клиент оформляет заказ.
• Включение (Include): Указывает на то, что один вариант использования всегда включает в себя другой. Обозначается пунктирной линией с открытым треугольником dashed_arrow_point_right.
• Пример: "Оформить заказ" включает в себя "Проверить наличие товара на складе".
• Расширение (Extend): Указывает на то, что один вариант использования может быть расширен другим. Обозначается пунктирной линией с открытым треугольником.
• Пример: "Оформить заказ" может быть расширен "Применить промокод".
• Обобщение (Generalization): Указывает на наследование свойств и поведения от одного актора или варианта использования к другому. Обозначается сплошной линией с открытым треугольником.


Зачем нужны диаграммы вариантов использования?

• Помогают понять требования заказчика.
• Облегчают коммуникацию между аналитиками, разработчиками и заказчиками.
• Служат основой для создания тестов и документации.
• Визуализируют функциональность системы.

Как выявить ключевые потребности бизнеса: 5 практических методов для аналитика

В самом сердце успешного проекта лежит четкое понимание потребностей бизнеса. Но как же их выявить? Вот 5 проверенных методов, которые помогут вам в этом:

1. 🗣 Интервью с заинтересованными сторонами (Stakeholder Interviews):
• Суть: Личные беседы с ключевыми представителями бизнеса (руководители, менеджеры, пользователи).
• Как: Подготовьте структурированные вопросы, чтобы понять их цели, проблемы, ожидания и приоритеты.
• Совет: Не ограничивайтесь "дежурными" вопросами. Углубляйтесь в детали, чтобы выявить скрытые потребности.
• Пример вопроса: "Какие три самые большие проблемы вы сейчас видите в процессе X?" или "Что вы хотите улучшить в ближайшие 6 месяцев?"

2. 📜 Анализ документации (Document Analysis):
• Суть: Изучение существующих документов (отчеты, бизнес-планы, регламенты, маркетинговые материалы).
• Как: Выявляйте ключевые цели бизнеса, процессы, ограничения и зависимости.
• Совет: Не полагайтесь только на официальные документы. Ищите неофициальные записи, переписки и другие источники информации.
• Что искать: SWOT-анализы, результаты исследований рынка, feedback от клиентов.

3. 🕵️‍♀️ Наблюдение (Observation):
• Суть: Непосредственное наблюдение за работой сотрудников, процессами и системами.
• Как: Следите за тем, как люди взаимодействуют с системами, какие задачи они выполняют, какие проблемы у них возникают.
• Совет: Будьте беспристрастны и внимательны к деталям. Записывайте все свои наблюдения.
• Пример: Наблюдение за работой операторов колл-центра, чтобы понять, какие вопросы задают клиенты чаще всего.

4. 🤝 Воркшопы (Workshops):
• Суть: Организация совместных сессий с заинтересованными сторонами для обсуждения проблем, генерации идей и определения требований.
• Как: Используйте структурированные методы (мозговой штурм, SWOT-анализ, приоритизация требований).
• Совет: Приглашайте представителей разных отделов и уровней иерархии.
• Что нужно: Четкий план, модератор, визуализация (доска, флипчарт).

5. 📊 SWOT-анализ:
• Суть: Оценка сильных и слабых сторон компании, возможностей и угроз внешней среды.
• Как: Составьте матрицу SWOT, проведите анализ и определите стратегические направления развития.
• Совет: Используйте результаты SWOT-анализа для определения ключевых потребностей бизнеса.
• Пример: Слабая сторона - устаревшая IT-инфраструктура, потребность - модернизация IT-систем.

Как выглядит рабочий день системного аналитика?

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

0:00 Вступление
0:40 Кто такой системный аналитик?
2:53 Что делает системный аналитик?
4:05 Какие уровни бывают у системных аналитиков?
4:45 Рабочий день системного аналитика
8:50 Как я формирую свой рабочий день?

Смотреть это видео на youtube: youtu.be/1tkmeKRwVO0

Режим работы 996

В то время как, Европа проводит эксперименты по сокращению рабочей недели до 4 дней, в американских стартапах всё чаще переходят на режим работы 996.

Режим работы "996" — это распространённый особенно в Китае режим работы, который предполагает:
9:00 — начало рабочего дня,
21:00 (9 PM) — конец рабочего дня,
6 дней в неделю (обычно с понедельника по субботу).

Причина очевидна: таким образом американские компании пытаются конкурировать с китайскими. Больше рабочего времени = больше поставленного кода. Сотрудники соглашаются на такие условия добровольно, надеясь на опционы и быстрый карьерный рост.

На мой взгляд — это даёт короткосрочный буст в производительности, чтобы показать инвесторам свой уровень продуктивности. Однако в долгосрочной перспективе такая практика принесёт только выгорание и потерю сотрудников.

А вы что думаете?

Пруфы

Логическая задача на собеседовании «Серверы Google”

Эта задача из книги «Достаточно ли Вы умны, чтобы работать в Google”. Это руководство как успешно пройти собеседование в Google.

Даже если Вам не туда, то книга помогает во многом в прохождении собеседований в другие топовые компании. Уже готовлю для Вас главные инсайты книги.

❗️А вот и вопрос❗️

«В вашем распоряжении 10 тысяч серверов в дата-центре с возможностью удаленного управления и один день, чтобы получить миллион долларов. Что вы для этого сделаете»?

Подборка полезных ссылок:

SQL:
-Интерактивный курс по SQL
-Язык SQL
-Учебник по SQL

Архитектура:
-Монолитная и микросервисная архитектура. Сравнение
-Микросервисная архитектура, ее паттерны проектирования и особенности
-Памятка РП. Микросервисная архитектура
-Архитектура "файл-сервер".
-Концепты P2P социальные сетей и Diaspora
-Клиент-серверная архитектура в картинках
-Сравнение микросервисной и монолитной архитектур
-Просто о микросервисах

Выбор компаний, собесы, трудоустройство:
-Как выбрать работодателя в сфере IT: на что обратить внимание?
-Полный гайд по собеседованиям в IT
-Международный мультивендорный Digital-интегратор
-Как провалить собеседование в IT? 7 типичных ошибок (и как их избежать
-«Забудь про скромность и недостаток опыта»: 5 рекомендаций, как проходить собеседования в ИТ
-Как пройти собеседование в IT на позицию джуна⁠⁠
-Как пройти собеседование, если вы — новичок в IT. Советы по подготовке

Когортный анализ в Tableau

Когортный анализ – это метод аналитики, при котором изучаются отдельные группы (когорты) людей. Чаще всего пользователи объединяются по какому-то действию и времени, в которое его совершили. Его можно реализовать в любой BI-системе. В этом видеоуроке автор подробно разбирает, как это сделать на платформе Tableau.

Смотреть это видео на youtube: youtu.be/xtJREIRahaw

🎯 Приоритизация задач: Метод MoSCoW - must have, should have, could have, won't have 🚀

Привет, управляющие в IT! 👋

Как расставить приоритеты в огромном списке задач? Как понять, что действительно важно, а что можно отложить? На помощь приходит метод MoSCoW – простой и эффективный способ приоритизации, который поможет вам и вашей команде сосредоточиться на самом главном.

Что такое MoSCoW?

MoSCoW – это аббревиатура, которая означает четыре категории приоритетов:

• Must have (Обязательно): Критически важные требования, без которых проект не имеет смысла. Если эти требования не будут реализованы, проект будет считаться проваленным.
• Should have (Желательно): Важные требования, которые необходимо реализовать, если это возможно. Без них проект будет работать, но не так эффективно.
• Could have (Может быть): Желаемые, но не критичные требования. Реализация этих требований улучшит продукт, но их отсутствие не повлияет на успех проекта.
• Won't have (Не будет): Требования, которые не будут реализованы в текущем итерации/релизе. Они могут быть рассмотрены в будущем.

Как использовать MoSCoW?

1. Составьте список всех задач и требований.
2. Обсудите каждый пункт с командой и заинтересованными сторонами.
3. Присвойте каждому пункту одну из категорий (Must have, Should have, Could have, Won't have).
4. Сосредоточьтесь на реализации Must have требований.
5. Реализуйте Should have требования, если позволяет время и ресурсы.
6. Реализуйте Could have требования, если они не мешают реализации более важных требований.
7. Задокументируйте принятые решения и причины выбора приоритетов.

Пример применения для списка задач по разработке новой функции:

Предположим, вы разрабатываете новую функцию "Умный поиск" для интернет-магазина:

• Must have:
• Возможность поиска товаров по названию.
• Вывод результатов поиска в виде списка.
• Should have:
• Фильтрация результатов поиска по категориям.
• Сортировка результатов поиска по цене, рейтингу и популярности.
• Could have:
• Подсказки при вводе запроса.
• Автоматическое исправление опечаток.
• Won't have:
• Поиск товаров по изображению (отложено на будущие релизы).

Преимущества метода MoSCoW:

• Простота и понятность.
• Легко вовлекает заинтересованные стороны в процесс приоритизации.
• Помогает сосредоточиться на наиболее важных задачах.
• Повышает прозрачность процесса принятия решений.

Какие методы приоритизации вы используете? Что работает лучше всего в вашей команде? Поделитесь в комментариях!