Прыжок с парашютом и управление рисками: как не сгореть на работе и приземлиться успешно

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

🔥 4 главных риска в проектах и как их избежать

➡️ Эмоциональное выгорание
Проблема: Команда «горит» из-за хронического стресса.
Решение:
➖Не превращайте марафон в спринт. Требуйте реалистичных сроков.
➖Мотивируйте: объясняйте цель, связывайте задачи с миссией проекта.
➖ Заботьтесь о быте: еда, перерывы, отдых после рывков.
«Героизм приберегайте для критических моментов — иначе команда не выдержит».

➡️ «Мертвые точки»
Проблема: Задачи, которые все упускают из виду.
Решение: Проведите «Pre-mortem» — совещание, где команда представляет, что проект уже провалился, и ищет причины.
➖Спрашивайте: «Что пошло не так?»
➖Выявляйте скрытые риски и упущенные этапы.
➖Назначьте ответственных за самые опасные пункты.

➡️ Уязвимые места
Проблема: «Бутылочное горлышко» — один участник не справляется с потоком задач (например, тестировщик на 4 разработчиков).
Решение:
➖ Создавайте команды с перекрывающимися навыками (бэкенд-разработчик может помочь с фронтендом).
➖ Используйте Agile-подходы (Kanban), где все помогают «разгрузить» узкие места.
➖ Делегируйте и не берите всё на себя.

➡️ Риски релиза
Проблема: Масштабное обновление «валит» систему.
Решение:
➖ Внедряйте изменения постепенно (бета-тестирование, поэтапный переход).
➖ Всегда имейте «путь отката» к старой версии.
➖ Не торопитесь: как парашют, продукт нужно тщательно проверять перед запуском.

Управление рисками — это не паранойя, а профессионализм. Как парашютист проверяет снаряжение, так руководитель должен:
✔️ Предугадывать угрозы,
✔️ Готовить команду к сложностям,
✔️ Действовать на опережение.

Желаю мягкой посадки в проектах❗️

А вы сталкивались с этими рисками? Делитесь в комментариях!

#it #управление #аналитика

55 лет тому назад буквы «LOG» были отправлены через ARPANET!

29 октября 1969 года в лаборатории Калифорнийского университета в Лос-Анджелесе (UCLA) Чарли Клайн набрал на клавиатуре буквы «LOG» — первые символы, отправленные через ARPANET. На другом конце страны, в Стэнфордском исследовательском институте, Билл Дюваль должен был подтвердить получение. Но система зависла после «G». Через час попытка повторилась. На этот раз «LOGIN» дошло целиком.

— Ларри, это работает! — крикнул Леонард Клейнрок, руководитель проекта, в трубку своему коллеге Ларри Робертсу из ARPA.
— Теперь мы можем соединить компьютеры, как людей, — ответил Робертс.
Так началась эпоха, изменившая мир.

➡️ Холодная война и мечта о сети
В 1960-х ARPA (Агентство передовых исследовательских проектов) искало способ сохранить связь в случае ядерной атаки. Идея пакетной коммутации, предложенная Полом Бэраном и Дональдом Дэвисом, стала ключом: данные разбивались на «пакеты», которые независимо шли к цели, избегая повреждённых узлов.

— Представьте почтовые голубей, несущих части письма, — объяснял Бэран военным. — Даже если часть не долетит, сообщение соберётся из остатков.
В 1969 году ARPANET объединил четыре университета. Но настоящий прорыв случился позже, когда Винт Серф и Боб Кан задумали универсальный «язык» для сетей — TCP/IP.

➡️ TCP/IP: Рождение интернета
— Боб, если сети не понимают друг друга, это тупик, — сказал Серф в 1973-м, обсуждая с Каном проблему совместимости.
— Нужен протокол, как конверт для писем: адрес отправителя, получателя и данные внутри, — ответил Кан.

Их идея разделить передачу данных (TCP) и маршрутизацию (IP) казалась безумием. Скептики ворчали: «Зачем усложнять? NCP (старый протокол ARPANET) работает!» Но 1 января 1983 года ARPANET официально перешёл на TCP/IP. Это стало «днём рождения интернета».

— Мы не просто соединили компьютеры. Мы создали пространство для идей, — позже скажет Серф в интервью Wired.

➡️ Наследие ARPANET
ARPANET закрыли в 1990-м, но его ДНК живет в каждом сайте, сообщении и стриме. От электронной почты (которая появилась в 1971-м благодаря Рэю Томлинсону) до облачных технологий — всё это ветви одного дерева.

— В 1969-м мы думали о надёжности, а не о соцсетях, — смеялся Клейнрок. — Но когда даёшь людям инструмент, они творят чудеса.
Сегодня, когда 5 млрд человек выходят онлайн, сложно представить, что всё началось с трёх букв «LOG». Но именно ARPANET доказал: информация хочет быть свободной. Или, как сказал Кан:
«Интернет — это не про технологии. Это про людей, которые нашли способ говорить через расстояния и границы».

Мы не строили будущее. Мы дали ему голос.
— Винт Серф.

#АйтишныеБайки #IT #история #интернет #ARPANET

REST: Представление ресурсов с помощью путей

Представим два ресурса API: каталог и товар. Пусть ресурс каталога представляет собой коллекцию ресурсов товара. Как спроектировать пути этих ресурсов❓

➡️ Путь к ресурсу REST должен быть уникальным.
🔚Чтобы идентифицировать каталог, мы могли бы использовать путь /c.
🔚В случае с товарами мы могли бы использовать ссылку на товар или технический идентификатор и создать с его помощью путь /{productId} (например, /P123). Такие переменные в путях называются параметрами пути.
Пути /c и /{productId} являются совершенно допустимыми путями REST, потому что они уникальны. Но давайте будем откровенны. Что бы вы подумали о таком интерфейсе, если бы увидели его в реальной ситуации❓

➡️ Он не очень удобен для потребителей. Мы всегда должны разрабатывать API для пользователей. Было бы лучше выбрать пути, которые явно указывают, что они обозначают. Почему бы просто не использовать /catalog для ресурса каталога и /product-{productId} для ресурса товара❓ Звучит хорошо, но эти пути не единственная возможность:
🔚/catalog/{productId} - я предмет из каталога
🔚/products/{productId} - я товар из коллекции товаров

➡️ Чтобы повысить удобство использования, связь между ресурсами каталога и товаром можно отобразить в путях наподобие иерархии папок в файловой системе.
🔚Каждый ресурс товара – это элемент в коллекции каталога, идентифицируемый как /catalog, поэтому мы можем выбрать путь /catalog/{productId} для обозначения товара.
🔚Мы также могли бы явно указать, что каталог – это коллекция ресурсов товара, используя путь /products, при этом товар из этой коллекции представлен путем /products/{productId}.
Вариантов много❗️Все они показаны на схеме.

➡️ С точки зрения чистого REST все эти варианты допустимы.
🔚Даже если мы уже отбросили непонятные пути, такие как /c и /{productId}, потому что они явно неудобны для потребителя, у нас все еще есть много возможностей.
🔚Каталог ресурса можно представить как /catalog или /products, а ресурс товара, как /product-{productId}, /catalog/{productId} или /products/{productId}.

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

➡️ Хотя официальных правил REST, касающихся проектирования путей к ресурсам (кроме уникальности), не существует, наиболее распространенным форматом является:
🔚/{имя, отражающее тип элемента коллекции во множественном числе}/{идентификатор элемента}

➡️ Использование путей к ресурсам, показывающих иерархию ресурсов, и использование имен во множественном числе для коллекций для отображения типа элемента коллекции стало де-факто стандартом REST. Поэтому в нашем примере каталог должен быть идентифицирован как /products, а товар – как /products/{productId}. Эту структуру можно расширить до нескольких уровней, например: /resources/{resourceId}/sub-resources/{subResourceId}.

#аналитик #навыкАналитика #API #REST #IT

Fresh IT — не про абстрактное лидерство, а про то, как реально вырасти из разработчика в сильного техлида.

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

📌 В постах найдешь:

— техники для тех, кто хочет не просто кодить, а управлять;

— ситуации из жизни тимлида и как из них выходить;

— мышление, подходы: всё по делу, с примерами и без воды;

— свежие новости и тренды в IT, которые помогут оставаться востребованным специалистом.

Хватит учиться на своих ошибках, когда можно учиться на чужих.
Fresh IT — твой быстрый путь от кода к команде. Подписывайся! 🚀

От хаоса к порядку: 6 шагов для создания идеального списка задач в сжатые сроки 🚀

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

✔️ Объявите и обсудите цель.
➖Ваша команда должна понимать, какой цели вы хотите достичь, когда список будет завершен.

✔️ Определите все задачи.
➖Спросите команду, что должно быть сделано для достижения цели, зафиксируйте все названные задачи.

✔️ Назначьте ответственного за каждую задачу.
➖Задайте вопрос: «Кто может это сделать?» или «Кто обладает необходимыми компетенциями, чтобы сделать это?»
➖Задайте вопрос: «Когда это может быть сделано?» или «Когда вы узнаете, когда это можно будет сделать?».

✔️ Определите зависимости для каждой задачи.
➖Спросите: «Должно ли что-то произойти до того, как это будет сделано?» или: «Можно ли это сделать параллельно с другими задачами?».
➖Если вы хотите проявить оригинальность, эту взаимозависимость вы можете представить полноценной диаграммой Ганта. Мне бывает достаточно занести эту информацию в графу примечаний.

✔️ Представьте информацию в обобщенном виде.
➖Зафиксируйте задачи, имена ответственных за выполнение, предполагаемые сроки.
➖Располагайте задачи в логической последовательности с учетом их зависимости друг от друга.

✔️ Проверьте список на предмет точности и полноты.
➖Пройдитесь по порядку по всему списку.
➖Задайте себе вопрос: нет ли пробелов, которые помешают команде в работе? Восполните эти пробелы. Каждый участник должен выразить согласие со списком задач.

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

#it #управление #аналитика #лайфхак #чек_лист

Сказ о том, как появился бизнес-аналитик.. 😆😂

#ITюмор #memes

(с) автор видео.

Подборка IT-мероприятий🗓

➡️ 21 апреля. Офлайн (Санкт-Петербург). 1й митап сообщества Путь СТО
➖ В программе доклады от участников сообщества на тему управления, панельная дискуссия, а также знакомство с нашим сообществом и нетворкинг. Митап будет интересен всем, кто связан с управлением в IT.

➡️ 22 апреля. Вебинар: Инструмент моделирования архитектуры предприятия СиММА
➖ Перед российскими предприятиями стоит задача импортозамещения таких инструментов, как Sparx, Aris, PowerDesigner, Archi. СиММА позволяет сделать такое замещение. В том числе это первое российское ПО, которое поддерживает нотацию Archimate, C4, UML и позволяет конструировать любые другие нотации, или смешивать нотации в произвольном порядке.

➡️ 22 апреля. Из аналитика в продакта #005
➖ Продакт в заказной разработке - такое вообще возможно? Где такое бывает и в чем особенности?
➖ Мыши, вагоны, деньги, психотерапевты.. - менять домены как перчатки и не терять в качестве. Как???
➖ Западные vs Российские корпорации взглядом продакта. В чем принципиальная разница?

➡️ 24 апреля. KARPOV.CONF 2025 Data-driven for Business — конференция для тех, кто хочет получать максимум из анализа данных: растить метрики и выводить бизнес в лидеры рынка.
➖ Лекции от экспертов Яндекса, Avito, МТС, Райффайзен Банка
➖ Разбор острых тем: Machine Learning, AI, LLM, BI-системы, Growth Analytics
➖ Кейсы и практики топовых компаний

➡️ 24 апреля. Воркшоп Reshape Analytics «Как избежать overstock и out-of-stock: балансировка запасов в условиях нестабильного спроса»
➖ как не допускать излишков и дефицита товаров даже в условиях неопределённости,
➖ как выглядит живой опыт решения этих задач в бизнесе,
➖ как продукт RPC помогает видеть картину заранее и принимать обоснованные решения,
➖ прямое общение с экспертами и ответы на ваши вопросы.

➡️ 24 апреля. Вебинар: От идеи до MVP: как создается архитектура ИТ-решения шаг за шагом
➖ На практике ведущая покажет, как спроектировать и собрать архитектуру ИТ-продукта от use-case диаграммы до MVP. Мы шаг за шагом разберём компоненты, архитектурные решения, базу данных, интеграции (почта, Telegram, вебхуки), события и покажем, как всё это работает как единое целое.

➡️ 24 апреля. 5 ошибок в дизайне REST API | Открытый вебинар
➖ Получите опыт работы с инструментом Postman.
➖ Сделаете рабочую Postman-коллекцию запросов к реальному API для личного портфолио.
➖ Будете знать типичные ошибки при дизайне REST API и как их избежать.
➖ Получите примеры корректных постановок задач на API-методы.

➡️ 25 апреля. Офлайн (Москва) и онлайн. Инструменты для тех, кто проектирует системы.
➖ Глеб Гончаров — придёт с инструментом архитектурных ката
➖ Денис Бесков — принесёт ИИ-мультитул аналитика
➖ Дмитрий Безгулый — JBTD-фреймворк для аналитиков и проектировщиков
➖ Максим Чернухин — раскроет принцип проектирования против легаси
➖ Дарья Мороз — придёт с UX-набором для документации

➡️ 29 апреля. Офлайн (Москва) и онлайн. Arch.Meetup by Sber
➖ управление доступом по принципам Zero Trust: от API Security до безопасности AI native ландшафта;
➖ доверенный и безопасный ИИ;
➖ архитектуру лицензирования: взлом, защита, снова взлом.

#мероприятия #аналитик #IT

😂😂😂

Всем хорошего настроения 😎 и продуктивной недели❗️

#юмор #memes

☀️

#путешествия #фотоблог #life

Подборка интересного из мира IT за неделю
⤴️

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

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

➖ Гайд по работе с бизнес-требованиями. На основе формата Use Case
Статья предлагает подробный гайд по использованию формата Use Case для структурирования бизнес-требований, разбирая элементы сценариев, типичные ошибки и практические советы для повышения ясности и эффективности взаимодействия между командами.
Полезно: бизнес-аналитикам, системным аналитикам, продуктовым менеджерам, разработчикам, тестировщикам и руководителям проектов, участвующим в формировании, реализации и контроле требований.

➖ Я устала писать документацию — и научила AI делать это за меня
В статье делится опытом QA-тимлида по автоматизации создания тестовой документации с помощью AI (DeepSeek), описывая шаги от настройки до экспорта, итерации и нюансы проверки, чтобы ускорить процесс без потери качества.
Полезно: QA-инженерам, тестировщикам, руководителям QA-команд и менеджерам по управлению разработкой, стремящимся оптимизировать рутинные задачи с помощью AI.

📱 Посты ТГ
➖ Ты борешься, пока веришь
➖ Балансировка нагрузки
➖ Фейл - это тест на профпригодность
➖ Lucidchart — современный инструмент для графического моделирования
➖ Draw.io: продолжаем знакомство с инструментами аналитиков
➖ REST, REST и еще раз REST!
➖ Как строить URL для REST API методов: разбираем на практике
➖ Элементы пагинации в REST API: что это, когда нужно, примеры
➖ С каких UML диаграмм начать, чтобы не потеряться?
➖ Как расти из сотрудника в руководителя и не сломаться по пути

👁 Видео:
➖ Уже тошнит искать работу — Максим Артёменко — Мы обречены Youtube | VK-видео
Прикинь, тебе под 40, ты весь такой из себя синьорный синьорище, все видел, все делал, все знаешь как работае..Плюешь на все идешь работать стажером за пару сотен баксов, просто чтобы — да хрен его даже знает чтобы что..

➖ Кто придумал интернет? / Информатика YOUTUBE
Мы все каждый день пользуемся интернетом. И мало кто понимает и знает, что из себя сегодня представляет этот самый интернет

➖ Делаем лендос компьютерного клуба UX (часть 2)

#подборка #аналитик #IT

🔣 Как выявлять упущенные требования

Даже опытные аналитики не документируют 100% требований.

➡️Наибольшую угрозу проекту несут два типа упущенных ожиданий:
🔚Подразумеваемые требования — очевидные для заказчика, но не озвученные явно. Предположим, в требованиях к форме регистрации указано: Пользователь должен ввести email.
Подразумеваемое требование: Система должна проверять корректность формата email (наличие символа @, домена и т.д.).
🔚Неявные требования — логически вытекающие из других, но не сформулированные. Например, требование — пользователь должен авторизовываться через логин и пароль, неявное требование: «Система должна предоставлять функцию восстановления пароля».
Разработчики неспособны реализовать функциональность, о которой они не знают.

➡️ Методы их выявления
🔚Вопросы-детекторы:
• «Что вы считаете само собой разумеющимся?»
• «Какой уровень точности необходим?»
• Используйте открытые вопросы вместо «да/нет».

🔚Анализ существующих систем
При замене legacy-решения изучите его функции — некоторые могут быть критичны, даже если не упоминались пользователями.

🔚Декомпозиция и проверка:
• Разбивайте высокоуровневые требования на элементарные компоненты.
• Проверяйте пограничные условия. Предположим, в требованиях указано: «Пользователи младше 14 лет не могут создавать аккаунт». 13 лет и 364 дня — система должна заблокировать регистрацию, а ровно 14 лет — система должна разрешить регистрацию.
• Применяйте CRUD-анализ: Create, Read, Update, Delete для сущностей данных, с которыми работает система.

🔚Визуализация и логика
• Используйте диаграммы и таблицы решений для выявления пробелов в сложных сценариях.
• Сверяйтесь с чек-листами стандартных функций: безопасность, отчетность, архивация и т.д.

➡️ Ловушки
🔚Паралич анализа — не пытайтесь охватить все, фокусируйтесь на приоритетных рисках.
🔚Неявные зависимости — проверяйте парные функции (сохранение → загрузка).

➡️ Практические шаги
1️⃣ Проанализируйте прошлые проекты: какие требования были упущены и почему?
2️⃣ Классифицируйте требования в текущей документации (бизнес-правила, атрибуты качества и т.д.)
3️⃣ Составьте список эффективных методов выявления для будущих проектов (интервью, моделирование, CRUD).

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

#it #аналитик #навыкАналитика #требования

25 лет тому назад мир впервые увидел Quake III Arena!
и при чем тут Быстрый обратный квадратный корень

19 сентября 1999 года мир впервые увидел Quake III Arena — игру, где виртуальные воины сражались в трёхмерных аренах. Но мало кто знал, что под капотом этой легенды скрывался алгоритм, навсегда изменивший представление о скорости вычислений.

В тот день в исходном коде id Software появилась функция с комментарием «зловещий хакинг чисел с плавающей запятой». Её авторы даже не подозревали, что их трюк станет легендой программирования:
i = 0x5f3759df - (i >> 1); // какого чёрта?

Этот код — сердце Fast Inverse Square Root, алгоритма для быстрого вычисления обратного квадратного корня. В эпоху, когда процессоры едва справлялись с 3D-графикой, он позволял рассчитывать освещение и траектории в десятки раз быстрее стандартных методов. Но как он работал? И почему до сих пор о нём говорят?

Тайна «магического числа»
В 2005 году исходный код Quake III стал открытым. Сообщество ахнуло: функция Q_rsqrt использовала битовые операции и загадочную константу 0x5f3759df. Программисты ломали голову: как преобразование целого числа в float может дать приближение обратного квадратного корня?

Объяснение звучало как магия:
1️⃣ Число с плавающей запятой разбирали на биты.
2️⃣ Сдвигали их вправо (делили на 2) и вычитали из «магического» числа.
3️⃣ Собирали обратно в float.

«Это как взять логарифм, умножить его на -0.5 и снова получить число», — шутили математики. Но за кулисами скрывался гениальный трюк: битовое представление float интерпретировали как целое число, что позволяло аппроксимировать результат через экспоненту и мантиссу.

Грег Уолш, создатель алгоритма, позже признался:
«Мы искали способ убрать деление. Оказалось, всё решила пара битовых операций и метод Ньютона».

«Касательная, которая спасла Quake»
Первое приближение было грубым. Чтобы уточнить его, разработчики использовали метод Ньютона-Рафсона — итерационную формулу:

y = y * (1.5 - (x * 0.5 * y * y));
Всего один шаг — и погрешность сокращалась с 2% до 0.001%. Этого хватало, чтобы рендерить 60 кадров в секунду на Pentium III.
«Пол, посмотри! Мы заменили сотни операций тремя строчками кода»
— возможно, так воскликнул программист id Software, запуская тесты.
В 1999 году алгоритм казался чудом. Но к 2020-м годам всё изменилось. Современные процессоры обзавелись инструкциями вроде rsqrtss, которые вычисляют обратный квадратный корень за такт. Тесты показали: на Intel Core i9 Fast Inverse Square Root в 4 раза медленнее аппаратной реализации.

Зачем тогда о нём помнить?
1️⃣ Гениальная простота. Алгоритм учит думать «вне рамок» — использовать биты как данные и как инструкции.
2️⃣ Исторический код. Без него игры вроде Quake III не смогли бы работать на слабых PC 90-х.
3️⃣ Вдохновение. Даже сегодня разработчики встраивают этот метод в микроконтроллеры без FPU.

Его алгоритм стал мостом между эпохами. В 1999-м он позволил железу выжать максимум, а сегодня напоминает: иногда гениальность кроется в одной строчке кода. Пусть даже с комментарием «какого чёрта?».

#АйтишныеБайки #IT #история #Quake

Как работать с информацией. Чек-лист.

✔️ Активно слушайте во время обсуждений.
➖Участвуйте в обсуждениях, задавая вопросы и внимательно выслушивая ответы.

✔️ Резюмируйте услышанное своими словами.
➖Подведите итог услышанному или попросите сделать это кого-то еще. Так вы убедитесь, что все поняли правильно и сможете с точностью передать информацию другим.
➖Представьте резюме именно так, как оно было сформулировано в результате обсуждения. На этом этапе не следует добавлять что-то от себя или выражать собственную точку зрения.

✔️ Соедините все фрагменты полученной информации и на этой основе сделайте выводы.
➖Развитие информации: дополните информацию собственным знанием или гипотезами и на этой основе сделайте выводы.
➖Выстраивание последовательности: представьте всю полученную информацию в логической или временной последовательности. Подумайте, не пропущены ли какие-либо шаги.
➖Сторителлинг: расскажите историю, объясняющую происходящее. Извлеките уроки, установив причинно-следственные связи.

✔️ Поделитесь синтезированным знанием, чтобы убедиться в правильности своих рассуждений.
➖Поделитесь выводами, сделанными на основе синтеза информации.
➖Позвольте другим поправить вас. Затем синтезируйте информацию снова — до тех пор, пока не придете к верным заключениям.
➖Зафиксируйте синтезированную информацию в письменном
виде и поделитесь ею, чтобы закрепить полученные знания.

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

#it #управление #аналитика #лайфхак

Проектирование API: от целей к REST API

REST API представляет свои цели, используя протокол HTTP. Цели переносятся в пары типа «ресурс и действие». Ресурсы идентифицируются путями, а действия представлены методами HTTP.
🔚Но как идентифицировать эти ресурсы и действия❓
🔚И как обозначать их, используя пути и методы HTTP❓

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

➖Рассмотри очень простой метод, состоящий из четырех этапов:
🔚Сначала мы должны идентифицировать ресурсы — функциональные концепции и их связь — как они организованы.
🔚Затем нужно определить доступные действия для каждого ресурса, их параметры и результаты.
🔚Как только это будет сделано, мы сможем перейти к фактическому проектированию программного интерфейса, создав пути к ресурсам.
🔚Затем выберем HTTP-методы для обозначения действий.
Смотрим схему.

Сейчас мы говорим только о номинальном случае, когда все в порядке – 200 OK.

➖Советы по проектированию
➡️Идентификация ресурсов:
🔚Пример ресурсов:
/users — пользователи
/orders — заказы.
🔚Пример связей:
Заказы принадлежат пользователю → /users/{userId}/orders.
➡️Важно:
🔚Используйте множественное число для имен ресурсов (/users, а не /user).
🔚Избегайте глаголов в путях (например, /getUsers — плохо).

➖Определение действий и параметров
🔚Для каждого ресурса продумайте:
🔚Какие действия возможны — CRUD: Create, Read, Update, Delete.
🔚Какие параметры передаются — в теле запроса, URL или заголовках.
🔚Что возвращает API — например, JSON-объект или статус.

➖Проектирование URL-путей
➡️Правила для URL:
🔚Иерархичность: /ресурс/{id}/подресурс.
🔚Пример: /users/{userId}/orders/{orderId}.

➡️Стабильность: Избегайте изменений путей после публикации API.

➡️Версионирование: Добавляйте версию в URL или заголовки

➖Выбор HTTP-методов
Сопоставьте методы HTTP с действиями:
Метод → Действие → Пример
GET → Чтение → GET /users
POST → Создание → POST /users
PUT → Полное обновление → PUT /users/{id}
PATCH → Частичное обновление → PATCH /users/{id}
DELETE → Удаление → DELETE /users/{id}

#аналитик #навыкАналитика #API #IT

Подборка IT-мероприятий🗓
➡️ 14 апреля. Почему ваши оценки проекта всегда ошибочны.
➖ Обсудим два подхода к оценке: классический менеджмент с диапазонами и буферами рисков vs Agile с фокусом на коротких отрезках и сравнением задач.
➖ Практические инструменты: как использовать стори поинты, «майки» и буферы рисков для более точного планирования.
➖ Кейсы из реальной практики: примеры, где ошибочные оценки привели к проблемам и как их можно было избежать.

➡️ 15 апреля. A/B-митап от hh ru.
➖ Как Process mining помогает улучшить процесс принятия решений в A/B-тестах
➖ Как в hh ru устроен пайплайн-расчет ETL в A/B-тестах
➖ A/B-тестирование, как метод полного контроля за принятием решений

➡️ 15 апреля. Аналитик данных: все, что нужно знать для старта в профессии.
➖ Преподаватель karpov.cоurses Анастасия Зеленова погрузит новичков в направление и расскажет, какие навыки нужны для старта карьеры в 2025 году. Посмотрите, чем занимается аналитик данных на работе каждый день, и решите, интересна вам сфера или нет.

➡️ 16 апреля. Онлайн-воркшоп по User Story Mapping: как получить верхнеуровневое понимание IT-продукта от Surf BA Team.
➖ Научишься использовать User Story Mapping для построения верхнеуровневой карты развития продукта.
➖ Получишь инструмент для понимания ключевых целей и пользователей, чтобы продукт развивался в правильном направлении.
➖ Научишься структурировать задачи и процессы на самом высоком уровне, сохраняя фокус на стратегическом видении.

➡️ 16 апреля (заявка). Хакатон МТС True Tech Hack 2025 и разработай решение на базе одной из ИТ-платформ МТС.

➡️ 17 апреля. Продуктовая аналитика «под капотом» сервиса быстрой доставки «Самокат»
➖ Как устроены дарксторы и логистические процессы, скрытые за интерфейсом приложения;
➖ Какие инструменты помогают курьерам доставлять заказы за минуты;
➖ Как аналитики улучшают операционные процессы и какими метриками пользуются;

➡️ 17 апреля. Вебинар: Постановка задач: как формулировать так, чтобы задачи выполнялись в срок и с нужным результатом.
➖ Что такое SMART, CSD, RACI и как выбрать подходящий метод
➖ Как переформулировать задачу так, чтобы её действительно сделали и в срок
➖ Как контролировать выполнение и отслеживать прогресс (канбан, чек-листы, дашборды, PDCA)
➖ Реальные примеры из жизни продуктовых и технических команд

➡️ 17 апреля. Офлайн: Москва, ВДНХ. BI Show 2025 – live-demo российских аналитических систем
➖ На одной сцене встретятся представители Visiology, PIX BI, Yandex DataLens и AW BI, чтобы показать свои лучшие стороны и возможности по созданию простых и сложных дашбордов.

➡️ 19-20 апреля. T-CTF хакатон от Т-Банка.
➖ Выберите Лигу разработки или Лигу безопасности по своим навыкам. Если участвуете впервые, можно потренироваться на демозаданиях.
➖ Подключайтесь онлайн или приходите офлайн — в ИТ-хаб Т-Банка в одном из 6 городов России.

➡️ 21 апреля (заявка). Weekend offer для аналитиков от red_mad_robot.
➖ red_mad_robot ищет бизнес и системных аналитиков, которые готовы запускать новые продукты и создавать продвинутые технологические решения

➡️ 25 апреля. Офлайн (Москва) и онлайн. Инструменты для тех, кто проектирует системы.
➖ Глеб Гончаров — придёт с инструментом архитектурных ката
➖ Денис Бесков — принесёт ИИ-мультитул аналитика
➖ Дмитрий Безгулый — JBTD-фреймворк для аналитиков и проектировщиков
➖ Максим Чернухин — раскроет принцип проектирования против легаси
➖ Дарья Мороз — придёт с UX-набором для документации

#мероприятия #аналитик #IT

Чайки и ОЧЕНЬ важный тех специалист

Всем хорошего настроения 😎 и продуктивной недели❗️

#ITюмор #memes

(с) автор видео.

Чек-лист: 4 ключа для слаженной работы команды

✔️ Согласуйте свои действия с куратором проекта
➖ Найдите куратора (спросите, кто имеет возможность отменить финансирование проекта).
➖ Установите с ним доверительные отношения, задавая вопросы, в том числе главный: «Почему этот проект важен?»
➖ Создайте постоянный открытый канал коммуникации.

✔️ Поставьте ясные цели
➖ Однозначность целей означает, что все понимают их
одинаково.
➖ Уточните с куратором цели во всех деталях и сообщите
их всем членам команды.

✔️ Проведите стартовое совещание
➖ Соберите всех участников проекта на совещание и проанализируйте цели, ответственность и логистику, чтобы
у всех было одинаковое понимание проекта.
• Цели: Как определить успешность/неуспешность реализации проекта?
• Контекст: Почему проект важен?
• Команда: Кто должен войти в команду?
• Логистика: Как будет организована совместная работа?
• Следующие шаги: Что уже сделано и каковы наши дальнейшие действия?

✔️ Свяжите ежедневную работу с главной целью
➖ Повторяйте цель часто и через все каналы коммуникации.
➖ Объясняйте, почему роль и задача каждого важны и как они ежедневно вносят вклад в достижение общих целей.

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

#чек_лист #IT #управление

Зеленоградск 📸

#путешествия #фотоблог #life

🤖 ChatGPT 5.5 генерирует код, голос и видео почти неотличимые от человеческих.

🔚ИИ от Google предсказывает болезни точнее врачей.

🔚А TikTok уже тестирует нейросетевые аватары вместо реальных блогеров.

Ты можешь использовать это для карьеры, бизнеса или запуска нового проекта. Главное — знать, где и как.

📁 В этой папке — проверенные инструменты, свежие инсайты и простые схемы:

👉 https://t.me/addlist/9Gmep-HxnaNiOTM6

• как внедрить ИИ в работу за 1 вечер,
• на чем сейчас зарабатывают ИТ/ИИ-специалисты,
• куда двигаются тренды (и как не отстать).

👉 https://t.me/addlist/9Gmep-HxnaNiOTM6

💬 Хочешь попасть в следующую экспертную подборку? Пиши: @RyabovaM

Подборка интересного из мира IT за неделю
⤴️
📖 Статьи
➖ Keycloak: как упростить аутентификацию и не сойти с ума?
Статья подробно разбирает Keycloak как инструмент для упрощения аутентификации и авторизации в IT-системах, рассматривая его функционал, преимущества, недостатки, интеграцию с протоколами OAuth 2.0, OpenID Connect и альтернативы.
Полезно для: системных аналитиков, архитекторов, backend-разработчиков и специалистов по информационной безопасности, работающих с аутентификацией в распределённых системах.

➖ Оценка задач в сторипоинтах по их декомпозиции: метод, который наконец-то работает.
Статья предлагает метод оценки задач в сторипоинтах через их декомпозицию на атомарные шаги, что повышает объективность и предсказуемость сроков, а также объясняет, как тимлиды могут конвертировать сторипоинты в дедлайны с учётом индивидуальной производительности.
Полезно для: руководителей проектов, тимлидов, Scrum-мастеров и Agile-коучей, занимающихся планированием спринтов, оценкой задач и управлением командной нагрузкой.

➖ Пример решения одной задачи с помощью модельно-ориентированного подхода.
Статья демонстрирует применение модельно-ориентированного подхода для создания кастомного инструмента моделирования данных с использованием Eclipse-инструментов, включая генерацию документации, SQL-скриптов и гибкое проектирование через метамодели, редакторы и преобразования.
Полезно для: системных аналитиков и архитекторов ПО, занимающихся проектированием сложных систем, автоматизацией генерации кода и документов, а также интеграцией модельно-ориентированных инструментов в процесс разработки.

➖ Как ИИ упрощает работу системного аналитика.
Статья описывает, как ИИ помогает системному аналитику автоматизировать рутинные задачи: генерация документации, создание UML-диаграмм, перенос данных в Git, сокращая время выполнения работ и улучшая качество документации.
Полезно для: Системных аналитиков, бизнес-аналитиков и руководителей IT-проектов.

📱 Посты ТГ
➖ System Design (системный дизайн) — процесс проектирования архитектуры системы.
➖ «Я учусь» или как топтаться на месте, так и не достигнув цели.
➖ Обзор нейросети для генерации изображений от я графического дизайнера.
➖ Виды HTTP-методов: не повторяйте эти ошибки.
➖ 12 важных терминов по API, которые нужны системным аналитикам.
➖ Модель Карпмана в проектных командах. Ни для кого не секрет, что в некоторых проектах обсуждение рабочих вопросов периодически переходит в эмоциональное противостояние.
➖ Окей, твоя взяла. Ты высказываешь идею — тебе в ответ: «Не, давай по-другому». Ты вздыхаешь: «Окей, как скажешь». Внутри — осадочек. Но конфликта нет. Или всё-таки есть?
➖ Про CustDev и магию общения
➖ Проблема не в фичах — проблема в том, что никто не думает за пользователя.

👁 Видео:
➖ Полный гид по AI для системных аналитиков: как выбирать нейросети и для каких задач использовать.
В новом эпизоде подкаста GetAnalyst вы найдёте обзор основных AI-инструментов для системных аналитиков. Разберётесь, чем они отличаются, какие возможности предлагают, что и для каких задач подходит лучше всего.

➖ Моковое собеседование на Middle системного аналитика | Solvery & На собесе как на танцполе
Мероприятие поможет вам погрузиться в процесс прохождения технического собеседования в компании, актуализировать знания в соответствии с рынком, а также получить советы и обратную связь от ментора и получать приглашения на собеседования.

➖ ГАЙД НА СОФТЫ: Как чесать языком на собесе, чтобы дойти до оффера, уметь продавать ему свой опыт и самому вести переговоры, а не идти по их воронке и плохо написанному скрипту скрининга.

➖ Простой баг, ChatGPT и 50 минут боли: как ИИ программистов заменял.

➖ Почему арендовать реальные железные серваки — круто. Антон Юрищев - продуктовый архитектор в Yandex Cloud: Youtube | VK-видео

➖ Кто НА САМОМ ДЕЛЕ придумал YouTube? / Информатика: Youtube | RUTUBE

➖ Так ли удобен dbt, как о нём рассказывают? | Алексей Разводов.

➖ AI-управляемые архитектуры данных в корпоративных системах.

#подборка #аналитик #IT

Базовые принципы HTTP
🤔
HTTP (HyperText Transfer Protocol) является основой обмена данными для Всемирной паутины. Это независимый от языка программирования протокол, предназначенный для обмена документами (ресурсами: HTML-страниц, изображений, JSON-данных и др.) между приложениями через интернет.

Протокол HTTP используется широким спектром приложений, наиболее известными из которых являются веб-браузеры. Веб-браузер использует протокол HTTP для связи с веб-сервером, на котором размещен сайт. Когда вы набираете URL-адрес например, https://www.ozon.ru/product/987654321/ в адресной строке браузера, он отправляет HTTP-запрос GET product/987654321/ на сервер, где находится ozon.ru, так же как когда потребитель API отправляет запрос на сервер REST API. Ответ, отправленный сервером, содержит код состояния 200 OK, за которым следует HTML-страница, соответствующая URL-адресу.

Браузеры используют этот протокол для извлечения любого типа ресурса (документа): HTML-страниц, CSS-файлов, файлов JavaScript, изображений и любых других документов, которые необходимы веб-сайту. Но это не единственное его использование. Когда вы, например, загружаете фотографию на сайт социальной сети, браузер использует протокол HTTP, но на этот раз для отправки документа на сервер. В этом случае браузер отправляет запрос POST /photos с телом, содержащим файл изображения. Поэтому протокол HTTP также может использоваться для отправки содержимого ресурса.

HTTP-запросы и ответы всегда выглядят одинаково независимо от того, что запрашивается и каков результат обработки запроса (см. схему).

Каким бы ни было его назначение, базовый HTTP-запрос содержит метод HTTP и путь к ресурсу. Метод HTTP указывает, что нужно сделать с ресурсом, который идентифицирует путь. Вы уже видели два HTTP-метода – GET, используемый для получения ресурса, и POST, используемый для его отправки, – позже вы узнаете больше. За этой первой частью запроса может следовать тело с содержимым ресурса, которое необходимо отправить на сервер, например для создания, обновления или замены ресурса. Это содержимое может быть любого типа: документ в формате JSON, текстовый файл или фотография.

Как упоминалось ранее, ответ HTTP, возвращаемый сервером, всегда содержит код состояния и поясняющую фразу. Это указывает на то, как прошла обработка запроса – была ли она успешной или нет. Пока вы видели только один код состояния HTTP, 200 OK, но позже познакомитесь с другими кодами (например, с известным кодом 404 NOT FOUND). За этой первой частью ответа может следовать тело с содержимым ресурса, которым манипулировал запрос. Как и тело запроса, тип этого содержимого может быть любым.
⬇️

➡️ Каждый запрос состоит из трех частей:
🔚Стартовая строка
[Метод] [Путь] [Версия протокола]
GET /product/987654321/ HTTP/1.1
Host: www.ozon.ru
Метод: Указывает действие (GET, POST, PUT, DELETE и др.).
Путь: Адрес ресурса на сервере (например, /product/987654321/).
Версия протокола: Обычно HTTP/1.1 или HTTP/2.

🔚Заголовки
Служебная информация для сервера:
User-Agent: Mozilla/5.0
Accept: text/html
Content-Type: application/json
🔚Тело запроса (опционально)
Данные для отправки (используется в POST, PUT). Например, JSON-объект или файл.

➡️Структура HTTP-ответа
Ответ сервера включает:
🔚Стартовая строка
[Версия протокола] [Код состояния] [Пояснение]
Пример:
HTTP/1.1 200 OK

🔚Заголовки
Content-Type: text/html
Content-Length: 1024
Set-Cookie: session_id=abc123
🔚Тело ответа
Запрашиваемый ресурс (HTML-страница, изображение) или сообщение об ошибке.

#аналитик #навыкАналитика #API #IT

Базовые принципы HTTP

HTTP является основой обмена данными для Всемирной паутины. Это независимый от языка программирования протокол, предназначенный для обмена документами (также называемыми ресурсами) между приложениями через интернет. Протокол HTTP используется широким спектром приложений, наиболее известными из которых являются веб-браузеры.
Веб-браузер использует протокол HTTP для связи с веб-сервером,
на котором размещен сайт. Когда вы набираете URL-адрес (например,
http://apihandyman.io/about) в адресной строке браузера, он отправляет
HTTP-запрос GET /about на сервер, где находится apihandyman.io, так
же как когда потребитель API отправляет запрос на сервер REST API. Ответ, отправленный сервером, содержит код состояния 200 OK, за которым следует HTML-страница, соответствующая URL-адресу.
Браузеры используют этот протокол для извлечения любого типа ресурса (документа): HTML-страниц, CSS-файлов, файлов JavaScript, изображений и любых других документов, которые необходимы веб-сайту.
Но это не единственное его использование. Когда вы, например, загружаете фотографию на сайт социальной сети, браузер использует протокол HTTP, но на этот раз для отправки документа на сервер. В этом случае браузер отправляет запрос POST /photos с телом, содержащим файл
изображения. Поэтому протокол HTTP также может использоваться для
отправки содержимого ресурса.
HTTP-запросы и ответы всегда выглядят одинаково независимо от
того, что запрашивается и каков результат обработки запроса (рис. 3.3).

35 лет тому назад родился WWW

12 марта 1989 года Тим Бернерс-Ли, скромный инженер в CERN, набросал на бумаге идею, которая перевернёт мир. Его документ «Информационный менеджмент: предложение» стал семенем, из которого выросла Всемирная паутина.

В те дни CERN напоминал вавилонскую библиотеку: тысячи исследователей со всего мира терялись в хаосе отчётов, баз данных и почтовых рассылок. Бернерс-Ли видел, как коллеги тратят месяцы на поиск данных.

— Представь, если бы каждый документ был связан невидимой нитью, — сказал он за обедом Роберту Кайо, своему соратнику. — Как паутина.
Кайо усмехнулся:
— Ты хочешь заставить физиков делиться? Это утопия.

Но Бернерс-Ли уже проектировал систему из трёх элементов: HTTP (протокол передачи), HTML (язык разметки) и URL (уникальные адреса). К 1990 году первый веб-сервер заработал на его компьютере NeXT. На экране вспыхнула страница с белыми буквами на чёрном фоне: «Добро пожаловать в info.cern.ch».

Руководство CERN скептически оценивало проект.

— Зачем нам ваша «паутина»? — спросил один из менеджеров. — У нас есть электронная почта.
— Потому что это свобода, — ответил Тим. — Знания должны быть как воздух: общие для всех.

Главный поворот случился, когда Бернерс-Ли отказался патентовать технологии. Коллеги не понимали:
— Ты мог бы стать миллиардером!
— Если бы я это сделал, веб стал бы ещё одной закрытой системой. Как телефонная сеть 19 века, — парировал он.

К 1993 году CERN опубликовал исходный код WWW как открытое ПО. Это решение взорвало планету. Учёные, студенты, предприниматели — все начали ткать свою часть паутины. К 1995-му интернет вышел за пределы лабораторий, породив Amazon, eBay и миллионы сайтов.

Сегодня, когда каждый клик — часть цифровой вселенной, сложно поверить, что её создатель не заработал ни цента на своём изобретении. Но Бернерс-Ли никогда не жалел:
— Веб — это не технология. Это акт веры в человечество.

Тим подарил миру инструмент, который стал общим достоянием. Без патентов, без роялти, без условий.

В 2004 году Бернерс-Ли получил рыцарский титул «за службу во благо глобальных компьютерных сетевых коммуникаций», журналисты спросили:
— Почему вы не стали патентовать свое изобретение?
— Потому что настоящая сила — не в контроле, — улыбнулся он. — А в том, чтобы дать силу другим.

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

В 2012 году Тим получил одну из лучших наград. Цитата из его первого сайта «Это для всех» была высвечена на зрительских местах церемонии открытия Олимпийских Игр в Лондоне, когда сам Тим, находился на газоне, работая за полной копией того самого компьютера, на котором начиналась создание современного нам интернета.


#АйтишныеБайки #IT #история #www

Знакомство с REST API

Чтобы научится проектировать интерфейсы, необходимо получить достаточное представление о REST API. Мы проанализируем вызов REST API, сделанный потребителем API-интерфейса онлайн-магазина для получения информации о товаре: GET /products/{productId} (смотри рисунок).

Чтобы получить информацию о товаре через REST API онлайн-магазина, клиент взаимодействует с сервером по протоколу HTTP. Рассмотрим пример запроса для товара с идентификатором “123”:
🔚Что происходит, когда потребитель хочет достичь цели «Получить товар»❓
🔚Или, говоря более конкретно, что происходит, когда он хочет получить подробную информацию о товаре с идентификатором “123” из каталога товаров с помощью REST API онлайн-магазина❓
Потребители должны обмениваться данными с сервером, на котором размещен API, используя протокол HTTP, как показано на рисунке.

Потребитель должен отправить HTTP-запрос GET /products/123 на сервер API онлайн-магазина. В ответ сервер возвращает ответ, 200 OK, за которым следует информация о запрашиваемом товаре. Обратите внимание, что мы упростили этот обмен данными по протоколу HTTP, чтобы сосредоточиться только на тех элементах, которые важны для нас сейчас.

Запрос состоит из HTTP-метода GET и пути /products/123.
🔚Путь – это адрес, идентифицирующий ресурс на сервере; в данном случае товар “123” находится в products.
🔚HTTP-метод указывает на то, что потребитель хочет сделать с этим ресурсом: GET означает, что он хочет получить ресурс.
➡️С функциональной точки зрения такой запрос означает что-то вроде: «Привет, могу ли я получить информацию о товаре с идентификатором 123?»
➡️Но с точки зрения протокола HTTP это означает: «Привет, могу ли я определить ресурс по пути /products/123?»

🔚Первая часть ответа состоит из кода состояния HTTP 200 и поясняющей фразы OK. Код состояния сообщает нам, как прошла обработка запроса. Благодаря поясняющей фразе мы можем догадаться, что код состояния HTTP 200 означает, что все прошло нормально.
🔚Вторая часть ответа называется телом ответа. Она содержит содержимое ресурса, идентифицированного путем в запросе, который в данном случае представляет собой информацию о товаре "123" в виде данных в формате JSON.

➡️С функциональной точки зрения ответ, возвращаемый сервером API, в основном означает: «Конечно, вот информация о запрашиваемом товаре».
➡️С точки зрения HTTP имеется в виду: «Нет проблем, вот содержимое запрошенного ресурса».

Теперь вы знаете, как потребители могут вызывать API онлайн-магазина, чтобы получить товар.

#аналитик #навыкАналитика #API #IT

Подборка IT-мероприятий🗓
➡️ 7 апреля. 15-й Российский форум по управлению интернетом (RIGF 2025).
➖ Вопросы цифровой безопасности.
➖ Механизмы международного сотрудничества.
➖ Проблемы безопасности детей в интернете.
➖ Развитие космических сервисов. 

➡️ 8 апреля. Топ-5 ошибок в моделировании требований системным аналитиком. IT Talks | Ошуркова Татьяна.
➖ Что необходимо знать о моделировании требований.
➖ Какие ошибки системный аналитик может допустить в работе.
➖ Как моделирование требований влияет на процесс разработки ПО.
➖ Как избежать ошибок и повысить качество требований.

➡️ 9 апреля. Менеджер и техническая терминология – враги или союзники?
➖ Обязательно ли знание технической терминологии для руководителя проекта.
➖ Что важно при сборе требований.
➖ Какие элементы важны для проектирования архитектуры.

➡️ 10 апреля. Выбираем способ связи между микросервисами: Sync vs Async.
➖ Как выбрать правильный способ связи между микросервисами в зависимости от требований вашего приложения.
➖ Преимущества и недостатки синхронных (REST, gRPC) и асинхронных (Kafka, RabbitMQ) методов взаимодействия.

➡️ 10 апреля. Офлайн: Новосибирск. Холиварные аналитические посиделки.
➖ Соберем системных, бизнес-, BI- и продуктовых аналитиков, чтобы не просто учиться, а прокачивать ключевые soft skills в интерактивных форматах.
➖ Мемное бинго – учимся анализировать ситуации через призму юмора и обмена опытом.
➖ Аналитический квиз – развиваем скорость мышления и умение работать с данными под давлением.
➖ Импровизационные кейсы – тренируем навык решения нестандартных задач.

➡️ 10 апреля. Сквозной процесс управления требованиями.
➖ К каким проблемами может привести неаккуратная работа с требованиями.
➖ Как выглядит сквозной процесс управления требованиями.
➖ Контрольные точки в процессе управления.
➖ Какие актуальные инструменты и методы могут применяться на разных этапах процесса.

#мероприятия #аналитик #IT

Всем хорошего настроения 😎 и продуктивной недели❗️

#ITюмор #memes

Подборка интересного из мира IT за неделю
⤴️
📖 Статьи
➖ Просто покажи: сила визуализации в аналитике
Статья раскрывает, как визуализация данных помогает системным аналитикам преобразовывать сложные требования в наглядные диаграммы (BPMN, UML и др.), улучшая коммуникацию, сокращая ошибки и ускоряя разработку, с примерами инструментов (Draw.io, Miro) и подходов для разных ролей.
Полезно: бизнес и системному аналитику.

➖ Как сделать хорошее API
Статья предоставляет практические рекомендации по проектированию REST API, включая использование DTO, асинхронных методов, правил HTTP, управления ошибками, безопасности и клиентских библиотек, с примерами кода и акцентом на масштабируемость и надежность.
Полезно: backend-разработчику, архитектору, системному аналитику.

➖ Модель C4, DFD и диаграмма Ганта на PlantUML
Статья демонстрирует создание диаграмм модели C4, DFD и Ганта с использованием PlantUML для визуализации архитектуры системы, потоков данных и планирования проектов, включая примеры кода и подключение внешних библиотек.
Полезно: системному аналитику, архитектору решений.

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

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

📱 Посты ТГ
➖ Заполненный шаблон реального интеграционного Use Case от GetAnalyst.
➖ Маппинг данных - что это и зачем?
➖ AI-хайп. Что такое AI-агенты и как работает RAG (Retrieval Augmented Generation)?
➖ Чтобы стать системным аналитиком недостаточно просто изучить технологии и методологии. Не менее важно научиться мыслить как системный аналитик.
➖ Как эффективно проходить финальные (они же) интервью и торговаться при получении оффера.
➖ 5 вопросов на собеседовании, которые раскроют твои софты.
➖ Про (не)простые типы данных или что в имени тебе моем?

👁 Видео:
➖ Kafka без боли для аналитиков: объясняем просто, на примерах и с практикой. Запись вебинара от “Системный анализ | Ольга Понамарева” ВКвидео | YouTube

➖ Хабр: разбираем зашквары крупнейшего IT-медиа | ТРЕЩИМ с Boomburum.

➖ Не 12 часов / Технологии, хайп и качество кода: как не попасть в ловушку инноваций.

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

➖ Юрий Тараторкин — разработчик всего в вебе и IT-авантюрист. Душевно поговорим о создании бота и приложения для сообщества, различиях в IT-индустрии России и Казахстана, о жизни между наймом и предпринимательством, ну и о провинциальном фрилансе нулевых. Заходите и смотрите!

#подборка #аналитик #IT

Все о карьере в IT

🔣 Собеседования
➖ Технические интервью: каждый провал — шаг к Seniorу
➖ Карьера как стартап — это стратегия, а не случай

🔣 Профессия аналитика
— Типы аналитиков в IT: обязанности, применение и необходимые качества. Вход в IT аналитиком
— Аналитик в IT: Как выбрать свой путь?

🔣 Личный рост
— Как начинать свой день
— Жизнь по алгоритму. Успешный сценарий end to end
— Искусство как Незаменимый Инструмент
— Что вас вдохновляет❓
— Нетворкинг и важность расширения социальных связей.
— Удалённая работа: свобода выбора и новые горизонты?
— Польза личного посещения конференций.

Управление командой

➖ Что значит руководить проектом?
• Принцип 1: руководитель проекта принимает на себя полную ответственность за его реализацию.
• Принцип 2: руководители проектов культивируют лучшие качества своих проектных команд.
• Принцип 3: лидер проекта – это клей, прочно скрепляющий команду
➖ Транзакционный налог в IT
➖ Что значит руководить проектом?
➖Ставьте цели, понятные всем членам команды
➖ Задавайте уточняющие вопросы
➖ Берите инициативу в свои руки

Чек-листы:
➖ Чек-лист для совещания
➖ Как провести продуктивное совещание | в файле
➖ Ведите заметки правильно.
➖ Чек-лист для идеальной дорожной карты проекта
➖ 4 ключа к слаженной работе команды
➖ Чек-лист: как задавать эффективные вопросы?

Навыки аналитика в IT

🔗 Навыки
🔚Карта навыков Аналитика BA/SA.
🔚Работа с требованиями: Виды и уровни требований.
🔚Правильная точка зрения для проектирования повседневных пользовательских интерфейсов.
🔚Проектирование API для пользователей. Определение целей API.
🔚 API создается, для того чтобы скрыть реализацию. Простая аналогия на API.
🔚 Как избежать влияния кода и бизнес-логики при проектировании API
🔚 Заинтересованные стороны в проекте. Как их определить?
🔚Техника SMART: как ставить цели, которые работают
🔚Зачем приоритизировать задачи?
🔚Методы выявление требований
🔚Проведение интервью с заказчиком
🔚Как понять, что сбор требований завершен

✔️ Чек-листы
🔚 Чек-лист: как задавать эффективные вопросы ❓
🔚 Чек-лист: Идеальные заметки после совещания (Minutes of Meeting)

⚙️ Инструменты
🔚 Зачем вам онлайн-доска❓
🔚 Excalidraw — это виртуальная доска, которая позволяет создавать различные схемы, наброски и графики.

Ведите заметки правильно. Чек-лист.

Худшие заметки — это отсутствие заметок.

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

🔠 Набирайте текст на самом удобном для вас устройстве
Работа на собственном устройстве наиболее комфортна, так вы чувствуете себя защищенным.

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

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

🔠 Не пытайтесь записывать слово в слово
Перефразируйте выводы или попросите кого-то другого переформулировать их, и только после этого записывайте. Этот прием также поможет всем присутствующим быть на одной волне и, кроме того, позволит полностью закрыть одну тему, перед тем как перейти к следующей.

🔠 Организуйте информацию по темам, а не в порядке обсуждения
Очень часто в ходе совещания приходится возвращаться то к одному, то к другому вопросу, поэтому не всегда следует фиксировать их в порядке обсуждения. Лучше относить их к определенной теме повестки. Если вы придерживаетесь иерархического формата записи, фиксируйте такие вопросы в форме подпунктов к соответствующим основным темам.

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

#чек_лист #IT #аналитика #управление #заметки

Балтийский закат 🌅

#путешествия #фотоблог #life

135 лет тому назад родился Михаил Александрович Бонч-Бруевич — человек, превративший эфир в голос❗️

Лампы, перевернувшие связь
1915 год. В крошечной квартирной лаборатории, заваленной стеклянными колбами и проводами, Михаил задыхался от паров ртути. Война бушевала на фронтах, а Россия зависела от иностранных радиоламп. «Катодное реле» — так он назвал свое творение — стало первой отечественной электронной лампой, усилившей сигнал втрое.

— Ваши лампы слышны от Твери до Парижа! — писали с фронта.
Но военные чины скептически качали головами:
— Зачем эти хрупкие «пузыри», если есть проверенная морзянка?
Ответ пришел в 1919-м.

Эфир заговорил
27 февраля 1919 года. Нижегородская лаборатория. Бонч-Бруевич, не спавший трое суток, кричит в микрофон: «Говорит Нижний Новгород!». В Москве телеграфист, услышав голос из ниоткуда, в падении опрокидывает стул:
— Аппараты сошли с ума!

Это был первый в истории России сеанс радиотелефонии. Через два года его передатчик транслирует оперу со двора Шуховской башни, а Ленин пишет: «Газета без расстояний — великое дело!». Но Михаил уже рвется дальше:

— Морзянка? Это прошлый век. Эфир должен нести не точки-тире, музыку!

Короткие волны, длинные последствия
1925 год. Коллеги не верят: радиосигнал на волне в 10 метров не может преодолеть океан. Но Бонч-Бруевич, экспериментируя с магнетронами собственной разработки, доказывает: короткие волны отражаются от ионосферы, покрывая тысячи километров.

— Это же революция! — восторгается помощник.
— Нет, — поправляет Михаил, — эволюция. Теперь корабли не заблудятся в тумане, а самолёты «увидят» землю сквозь облака.
Его «бесполезные» исследования легли в основу радаров, которые в 1941-м спасут сотни жизней в блокадном Ленинграде.

Наследие, которое слышно
Когда 7 марта 1940 года сердце учёного остановилось, его изобретения уже жили своей жизнью:

🔚«Новый Коминтерн» — мощнейший европейский передатчик — объединял страну голосом Левитана;
🔚Магнетроны стали «глазами» ПВО и основой будущих микроволновых печей;
🔚Радиолампы Бонч-Бруевича запустили эру телевидения.

— Он ненавидел, когда его называли гением, — вспоминал сын Алексей, создатель лазерных технологий. — Говорил: «Я просто дал эфиру язык».
Сегодня, когда спутники стримят 4K-видео в реальном времени, стоит вспомнить того, кто превратил безмолвный эфир в пространство диалога. Как писал сам Бонч-Бруевич: «Радио — это не волны. Это мост, где даже враги могут услышать друг друга».

#АйтишныеБайки #IT #история #Радиоэлектроника

https://t.me/boost/BalticAnalyst
Друзья, нужны ваши голоса для публикации сторис❗️

Карьера как стартап — это стратегия, а не случай

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

Ключевые принципы:
➖ Адаптируйтесь под рынок, как стартап ищет продукт-фит.
➖ Запускайте MVP знаний вместо бесконечной учебы.
➖ Экспериментируйте с нетворкингом и проектами.

➡️ Итеративный подход: ищите свой «продукт-фит»
Стартапы начинают с гипотезы, но не боятся её менять, пока не найдут product-market fit — момент, когда продукт точно удовлетворяет запросы рынка. Аналогично, ваша карьера требует постоянной корректировки навыков под актуальные требования.
➖ Анализируйте вакансии как стартап анализирует рынок. Откройте 10–20 вакансий в вашей целевой области (например, Data Scientist) и выделите повторяющиеся требования: Python, SQL, машинное обучение.
➖ Адаптируйте обучение. Вместо абстрактных курсов создавайте проекты, решающие конкретные задачи из вакансий. Например, если требуется опыт с Apache Spark, проанализируйте дата-сет из реального бизнеса и визуализируйте результаты.

➡️ MVP знаний: запускайтесь быстро, учитесь на фидбеке
Minimum Viable Product (MVP) — это версия продукта с минимальными функциями, достаточными для тестирования гипотез. В карьере ваш MVP — это демонстрация ключевых навыков через проекты, а не дипломы.
➖ Создайте 2–3 проекта за 1–2 месяца. Например, для аналитика создайте low-fidelity прототип экранов CRM для управления клиентами с описанием логики переходов, используя Wireframes в Figma или Miro.
➖ Не ждите «идеального момента».

«MVP позволяет собрать максимум знаний о клиентах с минимальными усилиями».
Ваш MVP — это «продающая» версия вас: резюме, LinkedIn и проекты.

➡️ Гроухакинг: стучитесь во все двери
Гроухакинг — это эксперименты для быстрого роста аудитории или прибыли. В карьере это означает активный поиск возможностей через нетворкинг, публичность и многозадачность.
➖ Правило 100 холодных сообщений. Рассылайте персональные предложения менеджерам в профильных телеграмм каналах.
➖ Участвуйте в хакатонах и митапах. 

«Рост достигается через постоянные эксперименты — даже 10% успешных идей дают прорыв».

➡️ Fail Fast: тестируйте, ошибайтесь, меняйте направление
Стартапы используют принцип fail fast — быстрое тестирование и отказ от неработающих идей. В карьере это означает: не бойтесь пробовать роли, уходить с неподходящих позиций и менять специализацию.

«Карьера — это стартап. Вы — CEO своей жизни».

Чем раньше вы начнете «продавать» свой MVP, тем быстрее найдете свою нишу. Время — ваш главный ресурс: не ждите, действуйте.

#собеседование #карьерныйТрек #IT

Розыгрыш MacBook Air

30+ экспертов из IT и digital собрались в одной папке, чтобы научить тебя оформлять кейсы, находить общий язык с заказчиками, управлять проектами и развивать личный бренд.

Подпишись на них и получи один из 3 призов:

🏆Главный приз — MacBook Air (M2).
🏆2 место: разбор карьерного трека от креативного директора Пиробайт.
🏆3 место: консультация по карьерному росту от секретного эксперта.

Как участвовать:

1. Подпишись на папку: https://t.me/addlist/fEvzl5khQT8yZTcy
2. Подтверди участие в боте
3. Отправь ссылку на бота своим друзьям — за каждого приглашённого человека ты получишь +1 призовой билет

🗓 26 апреля в прямом эфире узнаешь, какой приз достался тебе

Выполнил все условия? Тогда включай уведомления — и до связи 🚀

Участников: 1226
Призовых мест: 3
Дата розыгрыша: 10:00, 26.04.2025 MSK (6 часов)

Ставьте цели, понятные всем членам команды

Поучительную историю я слышала от своего приятеля, который живет на Гавайях. Он рассказал мне о тоннелях, которые в начале XIX века были проложены вручную китайскими рабочими близ полей сахарного тростника на острове Кауаи. Мой друг называет этот труд настоящим подвигом. Чтобы дело двигалось быстрее, рабочие получили распоряжение прокладывать тоннели сквозь горы одновременно с двух сторон. Удивительно, как им удалось встретиться на середине пути, соединив два тоннеля, — ведь у них не было современных технологий. Если бы расчет оказался неверным хотя бы для одной из сторон, ошибка была бы непоправимой.

Однако те китайские рабочие действовали не сами по себе. Ими руководили такие люди, как Кларенс С. Койке. В исторической книге «Семь восходов Аумакуа» говорится: «Первым заданием, которое [Кларенс] получил в Кекаа, было руководство рабочими, прокладывавшими тоннель в области Коки, где тогда одновременно строилось множество акведуков и каналов для отвода воды к тростниковым полям на склонах возле Маны, Кекаа и Ваймеа. Несколько тоннелей прокладывали одновременно с двух сторон — два отрезка должны были соединиться глубоко под землей. В обязанности Кларенса входило, спустившись в тоннель, при помощи компаса корректировать продвижение работ на обоих отрезках, чтобы в конечном итоге соединить их».

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

Книга Клей, автор: Ань Дао Фам, "Стань не заменимым в любом проекте".

#книжныйКлуб #цитаты #управление #АньДаоФам

Всем хорошего настроения 😂 и продуктивной недели❗️

#ITюмор #memes

Переменчивость Балтийской погоды суббота 🌞 /воскресенье ☔️.

#путешествия #фотоблог #life

Чувствуешь, что не хватает знаний технички для уверенности на работе?

Кажется, что перелопатила весь интернет, но так и не пришло понимания, а информация не сложилась в единый пазл? 🤔

СТОП ❌

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

то есть решение ✅

Канал Александра Нездемина, практикующего системного аналитика с 14летним опытом.

В его канале ты найдешь емкие и структурные разборы задач из собесов, реальные кейсы и понимание, как применять знания сразу на практике 🔥

➡️ Не упусти этот шанс!

Подписывайся на канал и переходи в закреп, там уже ждут разборы задач с собесов, после которых точно закрутятся шестеренки в твоей голове 👇🏻

https://t.me/+oYXwt_lKa9ljMDdi

❗️Настало время перестать теряться и начать уверенно двигаться вперед!

Подборка IT-мероприятий🗓
➡️ 1 апреля, онлайн и офлайн (Москва). Avito UX meetup: взаимодействие, метрики и мемы
➖ Как UX-исследователи меняют продуктовую культуру в Авито: про успехи и грабли
➖ Просчитался, но где? Как вырастить стажера в UX-исследователя
➖ Дорисовались: как мы в Авто.ру с дизайнерами общие процессы построили

➡️ 2 апреля, онлайн. Проектируем Kafka с умом
➖ Как посчитать, сколько места нужно под данные.
➖ Какие форматы сообщений использовать (Avro, JSON, Protobuf).
➖ Когда стоит использовать один топик, а когда — несколько.
➖ Какие параметры Kafka действительно важно понимать аналитику.

➡️ 2 апреля, онлайн. Вебинар: «ИИ как ETL» - революция в обработке данных
Как интегрировать ИИ в процесс ETL и сделать его не просто инструментом для обработки, но и настоящим катализатором изменений в бизнес-процессах? Вебинар «ИИ как ETL» даст ответ на этот вопрос и откроет для вас новые горизонты в сфере аналитики и автоматизации данных.

➡️ 3 апреля, онлайн. Postman. И с чем его едят.
Цель познакомить участников с функционалом Postman для эффективного API-тестирования, включая настройку окружения и автоматизацию тестирования.

➡️ 3 апреля, онлайн и офлайн (Москва). System Analysis Meetup SberHealth
➖ Как SA в СберЗдоровье описывают требования для мобильных приложений
➖ Книжный клуб системных аналитиков: как мы создали сообщество для обмена знаниями
➖ Мидл слой без хаоса: как сделать документацию понятной и живой

➡️ 5 апреля, онлайн. Вебинар: AI-управляемые архитектуры данных в корпоративных системах.
Вебинар посвящён тому, как проектировать и внедрять архитектуры ИИ в реальном времени с использованием событийного подхода, стриминга и современных инструментов.

➡️ 5 апреля, онлайн. 💸 Analyst Marathon #13. Практика и инструменты. Soft Skill ВА/SA
➖ Автономность или функциональная определенность в работе аналитика.
➖ Системный и бизнес-аналитик: как совмещать две роли в одном лице.
➖ Собираем арсенал инструментов для экспресс бизнес-анализа.

#мероприятия #аналитик #IT

Подборка интересного из мира IT за неделю
⤴️

📖 Статьи
➖ Как мы унифицировали техническое интервью системного аналитика.
Статья описывает опыт Альфа-Банка по созданию унифицированной модели технического интервью для системных аналитиков, включающей блоки знаний, уровни оценки и технические профили, что сократило время закрытия вакансий.
Полезно: Руководителям проектов, HR-специалистам в IT и системным аналитикам, участвующим в подборе команды или оптимизации процессов найма.

➖ Почему я использую doc-as-a-code
Статья обосновывает преимущества подхода doc-as-a-code перед традиционными инструментами вроде Confluence, акцентируя внимание на версионировании, автоматизации, согласованности процессов и снижении ошибок при разработке.
Полезно для: системного аналитика, руководителя проектов, разработчика, архитектора.

➖ Частые ловушки в экспериментах машинного обучения — рассказываем, что следует знать.
Статья описывает распространенные ошибки в экспериментах с машинным обучением (утечки данных, проблемы версионирования, несоответствие метрик) и предлагает практические решения для их предотвращения.
Полезно: Data Scientist, ML-инженерам, а также системным аналитикам, участвующим в проектировании ML-систем.

➖ Почему BPM-системы — это не про автоматизацию: мифы и реальность процессного управления.
Статья развенчивает мифы о BPM-системах, подчеркивая их ограничения в гибкости и адаптивности, и предлагает переход на low-code платформы для более эффективной автоматизации бизнес-процессов.
Полезно: Бизнес-аналитикам, системным аналитикам, руководителям проектов и владельцам продуктов, занимающихся оптимизацией процессов и выбором IT-инструментов для автоматизации.

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

📱 Посты ТГ
➖ Виды API: когда и какой выбрать.
➖ Чек-лист первого рабочего дня в IT.
➖ Tech Radar, радар используемых технологий в компании.
➖ Вот, что я понял за 25+ лет в IT (от Заметки на Техдирском).
➖ Зачем аналитику знать Kafka?
➖ Как выстраивать доверие с командой через повседневные диалоги?
➖ Удаленка - как не отлетать кукухой?
➖ Я не играю! Коллега язвит, босс давит, оппонент лезет напролом. Можно врубить драму, начать спор, бросаться доводами… а можно просто проигнорировать конфликт.

👁 Видео:
➖ САМОПРЕЗЕНТАЦИЯ: Да что эти компании реально хотят от вас услышать?
Самопрезентация — это рассказ не о вас, это рассказ о других. буквально презентация вашей услуги конкретному работодателю, то есть ее продажа. у вас должен быть свой сильный оффер в этом рассказе, который вы могли бы продать разным компаниям.

➖ Как Китайцы Наказывают Создателей ChatGPT (а те плачутся, как девчонки)
⤴️

➖ Как вырастить Telegram-канал до 100 000 подписчиков и не сломаться?
— как находить свою аудиторию в выжженном инфополе;
— почему кликбейт — это не всегда плохо;
— как выглядят посты, которые можно монетизировать;
— как ИИ действительно помогают делать контент.

➖ Особенности проектирования систем с высокой ценой ошибки. Григорий Алексеев, разработчик серверного ПО, представил доклад о проектировании систем с высокой ценой ошибки, акцентируя внимание на стратегиях снижения потерь, включая тестирование, чистый код, устойчивость, масштабируемость и CI/CD.

➖ Почему ты не будешь зарабатывать много в IT? Массовые увольнения!
Сегодня поговорим про зарплаты, увольнения и так ли все плохо на самом деле. Все ли зарабатывают миллионы в IT и как вообще стать успешным, если ты фронтендер? Разбираться будем с этим вместе с Глебом Михеевым - в данный момент руководителем в Сбере.

#подборка #аналитик #IT

Подборка интересного из мира IT за неделю
⤴️

📖 Статьи
➖ Как мы унифицировали техническое интервью системного аналитика.
Статья описывает опыт Альфа-Банка по созданию унифицированной модели технического интервью для системных аналитиков, включающей блоки знаний, уровни оценки и технические профили, что сократило время закрытия вакансий.
Полезно: Руководителям проектов, HR-специалистам в IT и системным аналитикам, участвующим в подборе команды или оптимизации процессов найма.

➖ Частые ловушки в экспериментах машинного обучения — рассказываем, что следует знать.
Статья описывает распространенные ошибки в экспериментах с машинным обучением (утечки данных, проблемы версионирования, несоответствие метрик) и предлагает практические решения для их предотвращения.
Полезно: Data Scientist, ML-инженерам, а также системным аналитикам, участвующим в проектировании ML-систем.

➖ Почему BPM-системы — это не про автоматизацию: мифы и реальность процессного управления.
Статья развенчивает мифы о BPM-системах, подчеркивая их ограничения в гибкости и адаптивности, и предлагает переход на low-code платформы для более эффективной автоматизации бизнес-процессов.
Полезно: Бизнес-аналитикам, системным аналитикам, руководителям проектов и владельцам продуктов, занимающихся оптимизацией процессов и выбором IT-инструментов для автоматизации.

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

📱 Посты ТГ
➖

👁 Видео:
➖

#подборка #аналитик #IT

Чек-лист для идеальной дорожной карты проекта
Продолжаем тему проектной работы. Как наладить работу команды мы с вами узнали в предыдущем посте.

➖ Создайте таблицу для дорожной карты
➖ Для нечетко определенной дорожной карты в верхней строке обозначьте сроки: сейчас, скоро, позже.
➖ Для дорожной карты, основанной на сроках, в верхней строке укажите недели, спринты, месяцы.
➖ В левую колонку внесите ресурсы или параллельные потоки.

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

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

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

➖ Учитывайте зависимости
Выстраивая последовательность эпиков, учитывайте параллельность или взаимозависимость тех или иных рабочих потоков.

Всегда придерживайтесь CALM: closely aligned, loosely managed — «максимально координировать и минимально контролировать». Название метода, созвучное английскому слову «спокойный», отражает эмоциональное состояние руководителя такого проекта Когда вы уверены в том, что работа скоординирована в соответствии с правильно расставленными приоритетами, и доверяете своей команде, как руководитель вы можете быть спокойны за проект.
Метод CALM эффективен в тех случаях, когда ответственная команда уже сложилась и имеет собственный стиль работы.
#чек_лист #IT #управление

4 ключа к слаженной работе команды: Практический чек-лист от постановки целей до ежедневных задач

Читайте у меня в Сетке ➡️ https://set.ki/post/hnf9Zsc

https://set.ki/post/hnf9Zsc

4 ключа к слаженной работе команды: Практический чек-лист от постановки целей до ежедневных задач

Читайте в сетке!

Тьюринг против «Энигмы»: Как безумец с кружкой чая переписал историю войн и машин

1940 год Блетчли-Парк
Алан Тьюринг, 28-летний математик в помятом пиджаке, уставился на шифровальную машину «Энигма». Нацисты считали её неприступной: каждый день настройки менялись, создавая 158 миллионов миллионов миллионов вариантов кода. Союзники теряли корабли, города и жизни.

— Вы уверены, что это возможно? — спросил коллега, глядя на чертежи странного аппарата с вращающимися барабанами.
— Возможно? — Тьюринг прищурился, поправляя очки. — Это необходимо.

Его идея казалась безумием: вместо людей-криптографов — машина, которая «переберёт» все настройки «Энигмы» за часы. Военные чины ворчали: «Механический бред!», но Тьюринг уже собирал прототип в сарае Блетчли-Парка. Его назвали «Бомба» — за тиканье, напоминающее часовой механизм бомбы.

Март 1941-го
Первая расшифровка. Немецкие сообщения о конвоях в Атлантике теперь читались как открытые письма. Адмиралтейство получило данные за сутки до атак.

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

Его «Бомба» работала. Но Алан думал уже о другом — о машине, которая могла бы любую задачу решать через алгоритмы. Ещё в 1936 году он описал абстрактное устройство с бесконечной лентой — «машину Тьюринга». Теперь, среди войны, он видел будущее: «Это будет не просто калькулятор. Оно сможет *мыслить*».

После войны 1950-е
Тьюринг писал код для первых компьютеров, проектировал ACE (Automatic Computing Engine) — машину с архитектурой, опередившей время на десятилетия. В статье «Вычислительные машины и разум» он бросил вызов миру:

— Может ли машина обмануть человека, что она живая?

Научное сообщество смеялось: «ИИ — фантастика!». Но Тьюринг верил — алгоритмы смогут учиться, играть в шахматы, даже любить.

Трагедия
В 1952 году его арестовали за «непристойное поведение» — в то время в Великобритании гомосексуальность была уголовно наказуемым преступлением. Суд предложил: тюрьма или химическая кастрация. Он выбрал уколы гормонов.

— Я превращаюсь в тень, — писал другу. — Но мои машины переживут меня.

7 июня 1954 года Тьюринг откусил яблоко, пропитанное цианидом. Ему было 41.

Наследие
Сегодня каждый смартфон, нейросеть и космический зонд несёт в себе частицу его гения. «Машина Тьюринга» — основа теории вычислений, тест Тьюринга — вызов для ИИ, а взлом «Энигмы» сократил войну на 2 года, спася миллионы.

— Мы не просто взломали код, — сказал бы Алан, глядя на ChatGPT и Mars Rover. — Мы взломали саму идею невозможного.

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


Вдохновлено книгой Уолтера Айзексона «Инноваторы: Как несколько гениев, хакеров и гиков совершили цифровую революцию.

#АйтишныеБайки #IT #история

Подборка IT-мероприятий🗓
➡️ 25 марта. DDD для аналитика. Как повысить свою ценность для всех.
➖ Активное изучение и применение методологии Domain Driven Design дает буст многим командам и продуктам.

➡️ 25 марта. Офлайн: г. Москва, Кутузовский пр-т 32, к. 3, башня А. Воркшоп «Внедрение технологии Process Mining в организации: опыт Сбера».
➖ Чек-лист по внедрению Process Mining в организации, а также живое общение, ответы на вопросы

➡️ 26 марта. API: Как работают gRPC и GraphQL.
➖ Альтернативные подходы к созданию API, такие как GraphQL, gRPC и HATEOAS, сравним их между собой, выявим их сильные и слабые стороны.

➡️ 27 марта. Zvuk Teamlead Meetup.
➖ Как экологично расстаться с сотрудником при увольнении — Никита Любицкий, Frontend Teamlead, Звук.
➖ Технический фитнес тимлида. Как тимлиду не просаживаться по техническим навыкам и знаниям — Никита Ульшин, Teamlead, Т-Банк.
➖ Как заонбордить одновременно 3 новые команды и не сгореть — Сергей Пиший Android Teamlead, Okko.
➖ Предотвращаем выгорание — объясняю на пальцах — Иван Шашов, руководитель веб-разработки, онлайн-кинотеатр START.

➡️ 27 марта. Как аналитику проводить интервью, которые действительно работают?
➖ Как превратить интервью в инструмент для раскрытия скрытых требований и получения точных ответов.

➡️ 1 апреля. Офлайн и онлайн. Avito UX meetup: взаимодействие, метрики и мемы.
➖ Как UX-исследователи меняют продуктовую культуру в Авито: про успехи и грабли.
➖ Просчитался, но где? Как вырастить стажера в UX-исследователя.
➖ Дорисовались: как мы в Авто.ру с дизайнерами общие процессы построили.

➡️ 2 апреля. «ИИ как ETL» — революция в обработке данных.
➖ Интеграция ИИ и ETL: почему это будущее?
➖ Практическое применение: реальный кейс с Conteq и демонстрация ИИ в действии.
➖ Технологические аспекты: как построить такой процесс без вызова внешнего ИИ, полностью внутри ETL.
➖ Инсайты от эксперта: как избежать общих ошибок и добиться максимально эффективных результатов.

#мероприятия #BA #SA #аналитик #IT

Как научиться собирать требования у заказчика, чтобы создать конкурентоспособный продукт?

Альбина Гараева - senior системный аналитик с 10-летним опытом, автор и спикер курса "Системный аналитик", знает, как этого добиться, и делится своими знаниями на канале.

А 25 марта в 20:00 проведет прямой эфир с бизнес-аналитиком, где вы узнаете, как правильно работать с требованиями, чтобы заказчик был доволен, как развивать критическое мышление и многое другое! Эфир будет полезен и начинающим, и опытным аналитикам.

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

➡️ Чек-лист идеального интервью с заказчиком
➡️ Подборка полезных материалов про API
➡️ ТОП-постов для подготовки к собеседованиям
➡️ Обзор реляционных СУБД с их отличиями и областями применения
➡️ Литература и советы по тайм-менеджменту

Не упустите возможность начать свой путь к успеху в IT уже сегодня!

erid: 2Vtzqusveat
Реклама. ИП Гараева А.М. ИНН 164909584601

Всем хорошего настроения 😂 и продуктивной недели❗️

#ITюмор #memes

Балтийское море в марте. Зеленоградск 🏖/Светлогорск 🏖️

#путешествия #фотоблог #life

Добрый пиар

🎯 Продуктовый дизайнер с душой предпринимателя
➡️ПОДПИСАТЬСЯ

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

🎯 Его зажигает:
• Проектирование брендов и сервисов
• Работа с пользовательскими эмоциями
• Создавать сервисы, от которых невозможно оторваться
• Развитие продуктов
• Заставлять пользователей влюбляться в продукт
• Изменение мира к лучшему через дизайн

🎨 Вдохновляет:
• Удачные рекламные кампании
• Фуд-фотография и видео
• Музыка группы “Мумий Тролль”
• Креативные решения в моде
• Хоккейные тактики
• Финансовые тренды

🟡 Присоединяйся к диалогу о продуктовом дизайне, предпринимательстве и создании крутых решений!

⬇️⬇️⬇️
Дизайн по-константиновски🙌
⤴️

#ДобрыйПиар

Подборка интересного из мира IT за неделю
⤴️

📖 Статьи
➖ Оптимизация работы с REST API: когда и как использовать пагинацию (+ простой пример на Python).
Статья объясняет важность пагинации для оптимизации работы REST API, рассматривает методы (offset-based, cursor-based, keyset) и демонстрирует их реализацию на Python с использованием Flask, подчеркивая снижение нагрузки на сервер и улучшение пользовательского опыта.
Полезно для: SA, архитекторов, PM,PO, backend разработчикам, заинтересованных в оптимизации API, масштабируемости и повышении устойчивости сервисов.

➖ 6 способов сэкономить место на дашборде, используя интерактивные функции в Tableau.
Статья описывает 6 интерактивных методов в Tableau: фильтры, заголовки, тултипы, иерархии, параметры и визуализации в тултипах для компактного размещения данных на дашбордах без потери информативности.
Полезно для: BA, SA, дата-аналитиков, BI-дизайнеров и руководителей проектов, занимающихся созданием или оптимизацией аналитических панелей в Tableau.

➖ Первые шаги в BPMN. Типы диаграмм.
Статья знакомит с основами BPMN, объясняя четыре типа диаграмм (Процесс, Взаимодействие, Диалог, Хореография), их визуальные элементы, отличия и применение для моделирования бизнес-процессов.
Полезно для: бизнес-аналитиков, системных аналитиков, проектных менеджеров и начинающих специалистов, работающих с оптимизацией процессов и межсистемными взаимодействиями.

➖ Как настроить уведомления из систем документооборота (СЭД) с помощью API.
Статья представляет собой практическое руководство по настройке автоматических уведомлений из систем электронного документооборота (СЭД) через API Exolve с примерами кода на Python и Node.js, рекомендациями по интеграции, обработке ошибок и логированию.
Полезно для: SA, разработчиков, DevOps-инженеров и руководителей IT-проектов, занимающихся интеграцией сервисов или автоматизацией бизнес-процессов.


📱 Посты ТГ
➖ PaaS, IaaS, SaaS, CaaS, FaaS
➖ Ты не успел войти в ИТ! / Что происходит с рынком?
➖ Как задействовать искусственный интеллект в работе над требованиями?
➖ Конфликт продаж и клиентского сервиса
➖ Управление ожиданиями в BI проектах
➖ Про оценки трудоемкости разработки софта
➖ Jira - это инструмент для управления задачами, или "таск-трекер" (task tracker).
➖ Виды авторизации в API: что нужно знать?
➖ Мультипотенциальный руководитель: проклятие или суперсила?
➖ HeadOfSales и картошка оптом
➖ Не хочу копаться в старом и чужом!

👁 Видео:
➖ ТИРЛИСТ ВСЕХ IT ПРОФЕССИЙ - лучшие айти специальности для старта в 2025. Профессии в IT по тирам - какие направления сейчас самые хайповые и перспективные, а какие потихоньку загибаются? Оценивал по четырем критериям - сложность в освоении, конкуренция, зарплаты и перспективы на глобальном рынке.

➖ Подкаст "обосную за инфру".
— Как обосновывать технические решения бизнесу
— Финансовое планирование для техдиров
— Презентация решений и бюджета

➖ Как построить карьеру в РФ и на международке: ошибки и лайфхаки. Тренд на снижение ЗП в ИТ, "тихие увольнения", крипта, adult и инвестирование, как самые высокооплачиваемые отрасти в ИТ.

➖ Закрытый стрим для респондентов исследования рынка аналитиков 2024. Инсайты исследования и экспертная оценка рынка труда аналитиков: продуктовых, дата-аналитиков, BI-аналитиков, маркетинговых аналитиков, системных и бизнес аналитиков

➖ Переезд с монолита на микросервисы: когда, зачем и как. Ключевые признаки, когда пора переходить на микросервисы, и как сделать это правильно.

➖ Архитектура в ИТ-стратегии. Ключевые аспекты архитектуры в ИТ-стратегии, включая классификацию архитекторов, применение фреймворка EA1P, а также методы бизнес-маппинга и архитектурные стили.

➖ «Скрипты и алгоритмы успеха» Радислава Гандапаса — читаем, размышляем, обсуждаем

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

#подборка #аналитик #IT

Хорошее завершение рабочей недели 🍔

Всем хороших выходных!😎

Как понять, что сбор требований завершен

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

Ключевые признаки завершения этапа:
1️⃣ Источники идей иссякают:
➖Пользователи перестают предлагать новые сценарии (use cases) или пользовательские истории, описывая их в порядке убывания важности.
➖Новые предложения либо дублируют существующие требования, либо выходят за рамки проекта (например, функциональность для будущих версий).

2️⃣ Требования стабилизируются:
➖Участники повторно обсуждают уже решенные проблемы, а не генерируют новые идеи.
➖Приоритет новых предложений становится низким (например, «можно реализовать позже» вместо «добавить в текущий релиз»).

3️⃣ Команда достигает консенсуса:
➖ Разработчики и тестировщики задают минимальное количество уточняющих вопросов, что свидетельствует о ясности документации.
➖Завершение этапа подтверждается формальным согласованием требований со стейкхолдерами.

❌ Почему полная завершенность недостижима?
➖ Динамичность целей: Даже в waterfall-подходах требования могут меняться из-за внешних факторов (рынок, законодательство).
➖ Когнитивные ограничения: Пользователи часто осознают свои потребности только в процессе взаимодействия с прототипом.
➖ Технические риски: Некоторые требования уточняются на этапе проектирования (НФТ).

Рекомендации для аналитиков
1️⃣ Фокусируйтесь на «достаточной» полноте. Цель — не собрать все требования, а достичь уровня, при котором риски пропущенных условий приемлемы для старта разработки.

2️⃣ Используйте структурированные методы:
➖Матрицы трассируемости для связи требований с бизнес-целями.
➖Воркшопы с пользователями для приоритизации (например, MoSCoW-анализ).

3️⃣ Подготовьтесь к изменениям. В Agile-проектах документируйте требования так, чтобы их можно было адаптировать без переписывания всей спецификации. Например, через атомарные user stories.

Завершение сбора требований — это не финальная точка, а момент, когда команда готова двигаться дальше с приемлемым уровнем неопределенности.
Agile-манифест — «Responding to change over following a plan»:
Готовность к изменениям, а не их избегание. Изменения улучшают проект, а не разрушают его, и отказ реагировать на них ради следования плану может привести к ухудшению качества.

#навыкАналитика #аналитик #IT

48 лет тому назад!

3 февраля 1976 года Билл Гейтс написал открытое письмо, навсегда изменившее отношение к программному обеспечению.

В тот день соучредитель Microsoft отправил послание в компьютерный клуб Homebrew Computer Club, где энтузиасты делились технологиями. Его текст стал манифестом ценности программирования:
Подавляющее большинство из вас ворует софт. Справедливо ли это?
...
Кто станет профессионально работать бесплатно?

Тогда, на заре эры ПК, программы воспринимались как нечто второстепенное. Железо стоило денег, а код копировали свободно, словно рецепт пирога. Гейтс и Пол Аллен разработали Altair BASIC, но их труд массово пиратили.

Пол, посмотри на эти отчеты — сотни копий, а платежей единицы. Мы работали не для этого.
— сказал Билл, листая письма пользователей.
Аллен вздохнул:
Если не остановим это, Microsoft не выживет.

Решение пришло резко. Гейтс опубликовал письмо, назвав копирование «кражей». Сообщество взорвалось. Один из хоббистов язвительно ответил: «Если Билл хочет денег, пусть паяет микросхемы, а не продаёт воздух».

Но Гейтс стоял на своём. Он верил, что ПО — это труд, а не данность. Его слова казались дерзкими, даже абсурдными в эпоху, когда код писали «для души». Однако время показало правоту Билла. Письмо стало точкой отсчёта: индустрия начала говорить о лицензиях, авторских правах и профессионализме.

Сегодня, глядя на триллионную капитализацию Microsoft, сложно представить, что всё началось с жаркого спора в крошечном клубе энтузиастов. Но именно тогда, в 1976-м, Гейтс заложил фундамент эры, где код стоит дороже железа.

Мы не просили благодарности. Мы требовали уважения
— позже скажет он в интервью. И мир услышал.

#АйтишныеБайки #IT #история

Технические интервью: каждый провал — шаг к Seniorу

I. Зачем вы ходите на интервью?
Если вы ходите на интервью только ради оффера, вы упускаете главное — возможность прокачать себя. Зачем регулярно ходить на интервью, рассказывает ➡️ Николай, старший системный аналитик в СБЕРе.

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

Умение ходить на интервью — это отдельный навык. Если вы умеете делать свою работу хорошо, не значит, что вы умеете ходить и проходить интервью. Как мы с вами знаем, любой навык тренируется практикой и только ей❗️ Если вы начинающей специалист, то интервью это прекрасный способ понять куда нужно расти и это источник информации гораздо важнее того, что вы видите на ютубе или читаете в книгах. Это "глаз рынка” — актуальные требования, которые диктует вам реальность здесь и сейчас. Прокаченный навык собеседования позволит вам быть устойчивым к любым кризисам.

II. Как извлечь максимальную пользу от технического интервью.
Поведение на собеседовании влияет на восприятие ваших навыков:
1️⃣ Сохраняйте спокойствие, даже если задача кажется сложной.
2️⃣ Думайте вслух, даже если ошибаетесь — интервьюер должен видеть ваш процесс
3️⃣ Задавайте уточняющие вопросы — это показывает аналитический подход и помогает вам найти нужный ответ. Иногда заданный вопрос может оказаться верным ответом.
4️⃣ Признавайте пробелы. Если не знаете ответа, честно скажите, но предложите гипотезу. В реальной работе невозможно знать все, но вы всегда сможете найти ответ на этот вопрос.
5️⃣ Когда на практической секции вы не знаете решения, то предложите альтернативу. Вы должны показать, что не сдаётесь и находите пути решения проблемы. Если вы не можете решить кейс с брокерами сообщений на интервью предложите решение с асинхронным использование REST’а.
6️⃣ Не бойтесь попросить подсказку, это не значит что вы глупый человек, это покажет вас как человека, который пытается решить поставленную задачу.
7️⃣ Если ответили на вопрос не правильно, то спросите правильный ответ. Расспросите интервьюера. Возможно с вами проводит интервью опытный специалист, который сможет привести практический пример. Особенно если вы не имеете практики и впервые ищете работу.

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

III. Анализ проведенного интервью.
Обязательно сразу после собеседования выделите время на анализ интервью. Используйте удобный Notion или Excel для записи:
➖ Даты интервью.
➖ Типы задач (теоретические, практические задачи, системный дизайн).
➖ Оценка своей работы по шкале 1–10.
➖ Новые задачи.
Дата / Тип задач / Оценка / Слабые стороны / План действий //
01.02.2025 / Системный дизайн / 6/10 / Не знаю Kafka / Пройти курс на Stepik

Зафиксируйте впечатления:
➖ Какие задачи вызвали трудности?
➖ Где вы замедлились?
➖ Какие вопросы оказались неожиданными?

Воспроизведите задачи. Решите их заново, без ограничения времени. Сравните с исходным решением.

Ищите паттерны ошибок:
➖ Слабые теоретические знания какой-то области?
➖ Незнание конкретных инструментов для моделирования процесса (UML, BPMN)?
➖ Слабые технические навыки для практики (мало практики написания SQL запросов)?
➖ Сложности в коммуникации?

Используйте SWOT-анализ:
➖ S (strengths) — сильные стороны: Что получилось идеально?
➖ W (weaknesses) — слабые стороны: Где были пробелы?
➖ O (opportunities) — возможности: Какие темы изучить?
➖ T (threats) — угрозы: Что может помешать в будущем?

Каждое техническое интервью — это урок. Анализируя свои ошибки, выстраивая систему подготовки, вы превращаетесь в сильного кандидата. Помните: даже “сеньоры помидоры” когда-то проваливали собеседования. Главное — не останавливаться!

#собеседование #карьерныйТрек #IT

Всем хорошего настроения и продуктивной недели 😎

#ITюмор #memes

Подборка IT-мероприятий🗓
➡️ 18 марта. Инструменты и технологии для инженера данных: как развиваться в профессии.
➖ СЕО и основатель дата-консалтинга и медиа LEFT JOIN Николай Валиотти погрузит в реальные задачи специалистов, расскажет о рынке труда в 2025 году.

19 марта, офлайн Санкт-Петербург. HR Tech Day IV.
➖ Прогнозирование выгорания сотрудников на базе ИИ;
➖ Продажа HR-проектов внутри компании: техники влияния и аргументации;
➖ Мастермайнд от Friendwork;
➖ Питчи HR Tech стартапов;

➡️ 20 марта. Погружаемся в мир А/В-тестирования: от гипотез до принятия решений.
➖ Продуктовый аналитик онлайн кинотеатра Okko Вера Багрова на примерах из своей практики покажет, как проводить А/Б тесты, чтобы они приносили результат. Какие есть лайфхаки и как избежать ошибок.

➡️ 20 марта, онлайн и офлайн. Yandex Product Party.
➖ Какие вопросы нужно себе задать, чтобы вывести новый продукт на высококонкурентный рынок.
➖ Как запустить и развить новый продукт внутри зрелой компании, преодолевая риски и внутренние барьеры.
➖ Как запуск партнёрской программы с агентами помог выйти на новый сегмент рынка.

➡️ 22 марта, офлайн Москва. Welcome Time для аналитиков: Рекламные технологии.
➖ Как работает аналитика в Коммерческом департаменте и Рекламных технологиях. 
➖ Как устроена аналитика антифрода рекламных систем.

➡️ 25 марта. ELMA Power Up! 2025 — управление процессами в компании: быстрее, дешевле, эффективнее.
➖ Как сократить издержки, ускорить процессы и повысить их прозрачность?

➡️ 27 марта. Zvuk Teamlead Meetup.
➖ Как экологично расстаться с сотрудником при увольнении — Никита Любицкий, Frontend Teamlead, Звук.
➖ Технический фитнес тимлида. Как тимлиду не просаживаться по техническим навыкам и знаниям — Никита Ульшин, Teamlead, Т-Банк.
➖ Как заонбордить одновременно 3 новые команды и не сгореть — Сергей Пиший Android Teamlead, Okko.
➖ Предотвращаем выгорание — объясняю на пальцах — Иван Шашов, руководитель веб-разработки, онлайн-кинотеатр START.

💸 Платные
29 марта. Next conf. Что вас ждет:
➖ мощный архитектурный блок: DDD, Event Storming, architecture as code.
➖ интеграционная архитектура: оркестрация, работа с данными, обеспечение отказоустойчивости.
➖ расчет нагрузки и обеспечение нефункциональных требований.
➖ поговорим о рынке и карьере аналитика.

#мероприятия #BA #SA #аналитик #IT

Подборка интересного из мира IT за неделю
⤴️
👁 Видео:
➖Конференция Flow. Как расти в карьере, налаживать связи и двигать проект вперед, если ты аналитик? YouTube | VK Видео
➖Конференция Flow. Роадмап развития мышления аналитика. YouTube | VK Видео
➖Проблемы в работе с задачами на интеграции: YouTube | Telegram
Погрузимся в проблемы разработки требований на интеграции систем, с которыми могут встретиться системные аналитики, а также обсудим варианты их решения.
➖ uv — швейцарский нож Python-разработчика: YouTube | VK Видео
➖ Идеальный контент убивает ваш бизнес: YouTube. Идеально вылизанные фото и бездумная погоня за подписчиками отлично работали пять лет назад. Но в 2025 они медленно и уверенно губят ваш бизнес.
➖ Как предприниматель смотрит на разрабов — Мы обречены. YouTube | VK Видео
➖ КАК нас ПРОСЛУШИВАЮТ крупные компании: YouTube
➖ ПЕРВЫЕ ДНИ на НОВОЙ РАБОТЕ! 10 ШАГОВ к УСПЕШНОЙ АДАПТАЦИИ: YouTube

📖 Статьи
➖ Почему мы построили монолит на чистой архитектуре. И почему это взбесило системных аналитиков. Статья описывает опыт внедрения чистой архитектуры в монолитном проекте на Django, что привело к рациональной оценке задач, сокращению time-to-market, улучшению структуры кода и наблюдаемости системы, но вызвало сложности у системных аналитиков из-за необходимости глубокого погружения в бизнес-логику и детализацию требований.
Полезно для: BA/SA, PM.

➖ Выявляем требования: онлайн-опрос как ключ к пониманию пользователя. Статья демонстрирует, как онлайн-опросы позволяют эффективно собирать требования пользователей, выявлять скрытые проблемы и формировать приоритеты для разработки, преодолевая ограничения через выбор инструментов, мотивацию участников и анализ результатов. Будет полезно: BA/SA, PO и UX-дизайнерам, работающим над улучшением пользовательского опыта и точным определением функциональных потребностей.

➖ Как мы автоматизировали обжарку кофе и доставляем 100 тысяч заказов в месяц почти без ошибок. Компания Tasty Coffee масштабировала доставку до 100 тысяч заказов в месяц с почти нулевой ошибкой благодаря QR-кодам, алгоритмам подбора упаковки, интеграции логистических систем и геймификации труда, сократив ошибки с 0,7% до 0,0039%.
Будет полезно: PM, PO в e-commerce, логистам и IT-специалистам, занимающимся автоматизацией процессов и оптимизацией цепочек поставок.

➖ Требования, еще требования, а какое стоп-слово? Работа системного аналитика с требованиями на разных этапах проекта. Статья раскрывает методы управления меняющимися требованиями в Agile-проектах, акцентируя важность обоснованного отказа ("нет") и гибкого подхода к согласованию изменений для соблюдения сроков и удовлетворенности заказчика.
Будет полезно: BA/SA и PM, сталкивающимся с постоянными изменениями требований и необходимостью баланса между гибкостью и дисциплиной в процессах.

➖ BPMN и оркестрация микросервисов. Часть 1 | Часть 2 Статья демонстрирует, как BPMN упрощает оркестрацию микросервисов через поддержку сложных паттернов (саги, компенсации, корреляции сообщений) и графические модели, обеспечивая кросс-функциональное взаимодействие между разработчиками, бизнес-аналитиками и операционными командами.
Будет полезно: SA, архитекторам, PM, внедряющим BPMN для автоматизации бизнес-процессов и управления распределенными системами.

📱 Посты ТГ
➖ Data Lake — метод хранения данных системой или репозиторием в сыром (неструктурированном) или частично обработанном виде.
➖ С чего начать погружение в профессию проектного менеджера.
➖ Я знаю, что ничего не знаю.
➖ Swagger - Open API - Практическое руководство.
➖ Инструменты системного аналитика для работы с API.
➖ Интеграции: краткий чек-лист по работе с задачами.
➖ User Stories: подход и применение в интеграциях.
➖ Когда использовать асинхронный REST.
➖ Зачем личный сайт руководителю?
➖ GigaChat MAX 2 — новая версия модели, которая выбивает топ-1 по MERA Бенчмарку на русском языке!
➖ Что делать, когда вас точно не слушают?
➖ Почему SEO-шник нужен на ВСЁМ пути разработки сайта?

#подборка #SA #BA #PO #PM #аналитик #IT

Просто хорошая музыка и хорошее фото, без всяких смыслов.
Всем хороших выходных! 🗓

🎵Fine Anyway — Rogér Fakhr: https://music.yandex.ru/album/14630981/track/78477328

🔥 Самая масштабная папка экспертов весны 2025: экономит месяцы поиска и сотни тысяч рублей

Мы собрали самую масштабную папку весны с проверенными экспертами в ИИ, IT, маркетинге и бизнесе. Это люди, которые уже сделали сильные проекты и знают, как решать задачи быстро и без лишнего шума.

➡️ https://t.me/addlist/T6mLvzCStz9kYzdi 🗂

🤖 ИИ, который реально продает

🚀 Маркетинг, который приносит прибыль, а не сливает бюджет

📈 IT-разработчики, которые не исчезают в момент дедлайна

🤑 Бизнес-эксперты, которые действительно умеют масштабировать

❌ Никаких «гуру», теории и пустых обещаний. Только те, кто делом доказал свою экспертизу.

➡️ https://t.me/addlist/T6mLvzCStz9kYzdi

Как избежать влияния кода и бизнес-логики при проектировании API

Код, управляющий данными – бизнес-логика реализации, – может влиять на проектирование API. Открытие доступа к такой логике через API может докучать не только потребителю, но и поставщику. На рис. 2.19 показан такой пример.

Допустим, что для реализации нашего API онлайн-магазина у каждого клиента есть один активный адрес. Но адреса в системе никогда не удаляются; вместо этого их статус становится неактивным, когда клиент не пользуется услугами сайта. Проектирование API, на который влияет эта бизнес-логика, может обеспечить следующие ориентированные на поставщика цели:
— составляем список адресов клиентов (активных и неактивных);
— добавляем адрес клиента;
— обновляем статус адреса (на активный или неактивный).
Слова, используемые для описания этих целей, понятны, но общее назначение целей может быть неочевидно для потребителя, который не знает точно, как система обрабатывает адреса. Эти цели показывают, как данные обрабатываются внутри; на рис. 2.20 показано, как их нужно использовать.

В левой части рисунка показано, как изменить адрес клиента с помощью этого API. Потребители должны перечислить существующие адреса, чтобы определить активный, обновить их, чтобы установить статус «неактивный», а затем добавить новый активный адрес. Довольно просто, нет? Вовсе нет! Это очень сложный процесс, и здесь легко что-нибудь может пойти не так. Что, если потребители не установят для предыдущего адреса значение «неактивный»? Это может стать катастрофой для целостности данных – здесь рискует поставщик.

К счастью, в правой части рисунка показано простое решение. Весь этот сложный и опасный беспорядок можно заменить простой целью «Обновить адрес клиента». Реализация может сделать все остальное, как если бы мы позволили схеме обрабатывать цикл включения/выключения магнетрона для API-интерфейса нашего кухонного радара 3000. Открытие доступа к внутренней бизнес-логике может затруднить использование и понимание API-интерфейса для потребителя и стать опасным для поставщика. Опять же, если вы будете использовать таблицу целей API и сосредоточитесь на том, что могут делать пользователи, это должно позволить вам с легкостью избежать подобных проблем разработки, но тем не менее они все же могут происходить.

ПОДСКАЗКА. При определении целей API всегда следует проверять, чтобы вы случайно не предоставили доступ к внутренней бизнес-логике, которая не касается потребителя и которая может быть опасной для поставщика.

Здесь мы имели дело только с одним программным компонентом.

Книга: Проектирование веб-API, автор: Арно Лоре.

#книжныйКлуб #цитаты #АрноЛоре #IT #api #аналитик

Чек-лист: Идеальные заметки после совещания (Minutes of Meeting)

✔️ Зафиксируйте повестку совещания и имена участников.
➖ Еще до начала совещания вы должны иметь на руках повестку и список участников. Если не вы организуете
совещание и повестка вам непонятна, обратитесь за информацией к организатору. Это поможет вам уловить суть предстоящего обсуждения.

✔️ Фиксируйте принимаемые решения.
➖ Отмечайте фразы типа «решено», «согласовано», «так и сделаем», «хорошая мысль», особенно произнесенные руководящими лицами.
➖ Услышав эти слова, уточните: «Правильно ли я поняла, что решение принято? Если да, не мог бы кто-нибудь подытожить сказанное?» После этого зафиксируйте итог. Обычно такие вопросы помогают присутствующим внести окончательную ясность в вопрос; кроме того, вы получаете сжатое резюме, которое отразится в ваших заметках.
➖Специально помечайте такие решения, чтобы их легче было находить при беглом просмотре (например, «Решение: двигаться дальше по варианту Б»).

✔️ Фиксируйте план действий.
➖ Фиксируйте намеченные действия всякий раз, когда слышите, что кому-то что-то поручено или кто-то соглашается выполнить задание.
➖ Бывает, что присутствующие на совещании вам незнакомы или вы не расслышали, кто именно будет выполнять задание. В этом случае зафиксируйте действие, поставьте знак вопроса там, где должно быть имя ответственного лица, и по окончании совещания уточните его.
➖ Помечайте запланированные действия особым образом, чтобы потом их можно было легко найти (например, «Поручение: Боря поговорит с Иваном, чтобы подтвердить решение»).

✔️ Прочтите аудитории свой отчет по итогам совещания и заполните пробелы.
➖ В конце совещания обратитесь к участникам: «Я хочу кратко подвести итоги сказанному». Прочтите вслух заметки, перечислите зафиксированные решения и действия. Участники могут внести свои исправления.
➖ Скорректируйте заметки, убедившись, что использовали те же фразы, которые употребляли участники, и внесите пропущенные пункты.
➖ Если рядом с действием не указано имя ответственного за его выполнение, уточните и внесите в записи.
➖ Когда все пробелы будут заполнены, вновь перечитайте заметки и спросите аудиторию, не было ли что-то упущено. Если все согласны, что самые важные моменты совещания записаны.
К сожалению, этот пункт редко получается в полной мере воплотить в жизнь, не всегда удается сразу вести структурировано заметки и выделить достаточно времени для подведения итогов. Главное не пропускайте подведение итогов совсем.

✔️ В течение одного дня после совещания разошлите отчет коллегам (чем быстрее, тем лучше).
➖ От ваших усилий не будет пользы, если вы не поделитесь с коллегами составленным отчетом. Разошлите его вскоре после совещания и не позднее чем через день после него. Чем быстрее вы это сделаете, тем лучше. Чем дольше вы ждете, тем больше вероятность, что информация устареет.
➖ Если это не короткий список заметок, перенесите записи в отдельный документ, а затем скопируйте последующие пункты непосредственно в тело письма. Обычно люди не читают отчет целиком, если только не ищут что-то конкретное. Также они просматривают его в поисках своего имени, чтобы не пропустить задачу, которой должны заняться.

#Статья #BA #SA #PO #PM #аналитик #навыкАналитика #чек_лист #войтиВit

Чек-лист: как задавать эффективные вопросы?
⬇️

✔️ Чтобы получить информацию и достичь взаимопонимания, задавайте уточняющие вопросы, мотивирующие собеседника.
➖ «Расскажите мне подробнее о…»
➖«Что бы вы порекомендовали?»
➖«Что вы думаете о…»

✔️ Чтобы стимулировать прогресс, всегда спрашивайте: «Каковы последующие шаги?»
Каждый шаг сопровождайте вопросом:
➖ Кто сделает это? / Кто может это сделать?
➖ Какова наша целевая дата? / Когда вы сможете назвать
целевую дату?

✔️ Задавайте четко сформулированные, однозначные вопросы с указанием целевой даты и обоснования — это
стимулирует к действию.
➖ Кто: адресуйте вопрос конкретному лицу. Если вам неизвестно, кто именно вам поможет, выберите того, кто с наибольшей вероятностью способен
дать ответ.
➖ Что: объясните, что именно вам нужно. Четко сформулируйте, что вам нужно, чтобы на ваш
вопрос было легче ответить.
➖ Когда: укажите желаемую дату выполнения. Назовите причину, по которой результат нужен к целевой дате, если такая причина имеется.
➖ Почему: расскажите, почему это важно. Если запрос исходит от человека, обладающего
большими полномочиями, чем вы, упомяните его.

✔️ Чтобы получить ответ быстрее, уменьшите объем работы, связанной с ответом.
➖ Сформулируйте утверждения, которые собеседник сможет оперативно скорректировать.
➖ Максимально упростите людям возможность ответить на
ваш вопрос или просьбу.

#Статья #BA #SA #PO #PM #аналитик #навыкАналитика #чек_лист #войтиВit

Разработайте курс для специалистов аналитики данных вместе с Яндекс Практикумом!

Сервис онлайн-образования Яндекс Практикум в поисках автора для курса расширенной аналитики данных.

Что делает автор курса?

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

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

Если вы в профессии уже более 3х лет и вы точно знаете «как это должно работать» — добро пожаловать!

Требования к кандидату описаны здесь, откликайтесь и давайте менять индустрию вместе!

Чек-лист: как задавать эффективные вопросы?
⬇️

✔️ Чтобы получить информацию и достичь взаимопонимания, задавайте уточняющие вопросы, мотивирующие собеседника.
➖ «Расскажите мне подробнее о…»
➖«Что бы вы порекомендовали?»
➖«Что вы думаете о…»

✔️ Чтобы стимулировать прогресс, всегда спрашивайте: «Каковы последующие шаги?»
Каждый шаг сопровождайте вопросом:
➖ Кто сделает это? / Кто может это сделать?
➖ Какова наша целевая дата? / Когда вы сможете назвать
целевую дату?

✔️ Задавайте четко сформулированные, однозначные вопросы с указанием целевой даты и обоснования — это стимулирует к действию.
➖ Кто: адресуйте вопрос конкретному лицу. Если вам неизвестно, кто именно вам поможет, выберите того, кто с наибольшей вероятностью способен
дать ответ.
➖ Что: объясните, что именно вам нужно. Четко сформулируйте, что вам нужно, чтобы на ваш
вопрос было легче ответить.
➖ Когда: укажите желаемую дату выполнения. Назовите причину, по которой результат нужен к целевой дате, если такая причина имеется.
➖ Почему: расскажите, почему это важно. Если запрос исходит от человека, обладающего большими полномочиями, чем вы, упомяните его.

✔️ Чтобы получить ответ быстрее, уменьшите объем работы, связанной с ответом.
➖ Сформулируйте утверждения, которые собеседник сможет оперативно скорректировать.
➖ Максимально упростите людям возможность ответить на ваш вопрос или просьбу.

#Статья #BA #SA #PO #PM #аналитик #навыкАналитика #чек_лист #войтиВit

Всем хорошего настроения и продуктивной недели 😎

#ITюмор #memes

Подборка IT-мероприятий🗓
➡️ 10 марта — 2 апреля. Онлайн кейс-чемпионат Changellenge >> Cup IT 2025.
➖ Быстрый карьерный старт на онлайн кейс-чемпионате.
➖ Решайте реальные задачи и прокачивайте ключевые навыки в одном из трех направлений: анализ данных, продуктовый менеджмент B2B и продуктовый менеджмент B2C.

➡️ 10 марта. Разработчик и аналитик: как понимать код без написания кода. Как системному аналитику разбираться в коде, выявлять ошибки и понимать разработчиков, не будучи программистом. Практические приёмы и полезные инструменты.

➡️ 11 марта. SQL как самый быстрый вход в профессию аналитика. Приходите на практикум, где вы напишите свой первый SQL-запрос и решите задачу на реальных данных Netflix.

➡️ 12 марта. Вебинар "Из аналитика в продакта.
➖ Зачем аналитику в продакты, и где подвох? - и не хочется ли потом вернуться к анализу?
➖ Analyst -> PO -> Product Manager -> Head of products -> - навыки, ответственность, риски - в чем разница?
➖ Насколько для продакта критичен домен? - например, из финтеха в фудтех и обратно - годно?

➡️ 13 марта в 18:00. Офлайн. Бизнес-лавочка.
➖ Группа компаний Innovative People и экспертный лейбл «Тишина» на «Бизнес-лавочку» — стендап-вечеринку для IT-специалистов.

➡️ 13 марта. Постановка: как делать и кому. Максим Цепков:
➖ Развитие ИТ накопило большой набор методов создания постановок для разработки софта: требования и проектирование от модели данных, описание бизнес-процессов, use case, user story и story mapping, domain driven design, c4-model, макеты интерфейсов, CJM, event storming и многое другое.
➖ Эти подходы создавались в разное время и для разных типов проектов, а также для разных представлений о разделении ответственности между командой и бизнес-заказчиком и ролями внутри команды. И при выборе метода работы, как и при выборе фреймворка разработки, стоит не брать то, что знакомо, а представлять спектр вариантов, их назначение и особенности.

➡️ 13 марта. ecom.teсh x keycloak community meetup.
➖ Refresh token в веб-приложениях: быть или не быть? — Андрей Кузнецов, архитектор.
➖ Тернистый путь OAuth: от 2.0 к 2.1 — Ирина Блажина, архитектор ИБ, Оператор Газпром ИД.
➖ Безопасность микросервисов: как защититься от уязвимостей аутентификации — Алексей Морозов, руководитель AppSec, ecom.teсh.

➡️ 18 марта. Офлайн. ML Party. В Санкт-Петербурге обсудим тренды, новые подходы и вызовы индустрии с экспертами в области машинного обучения. Будет экскурсия по офису, нетворкинг на темы LLM, RecSys, Speech и не только. 

➡️ 18 марта. Автоматизация документооборота в Enterprise за 1,5 месяца. Кейс Whoosh.
➖ Сокращение сроков и трудозатрат на выполнение процессов по документообороту;
➖ Минимизация убытков компании из-за несвоевременной подготовки договоров и их согласования;
➖ Единое пространство для коммуникации и наличие внешнего портала для работы с контрагентами;

➡️ 27 марта. Офлайн. Zvuk Teamlead Meetup.
➖ Как экологично расстаться с сотрудником при увольнении — Никита Любицкий, Frontend Teamlead, Звук.
➖ Технический фитнес тимлида. Как тимлиду не просаживаться по техническим навыкам и знаниям — Никита Ульшин, Teamlead, Т-Банк.
➖ Как заонбордить одновременно 3 новые команды и не сгореть — Сергей Пиший Android Teamlead, Okko.
➖ Предотвращаем выгорание — объясняю на пальцах — Иван Шашов, руководитель веб-разработки, онлайн-кинотеатр START.

#мероприятия #BA #SA #аналитик #IT

Подборка интересного из мира IT за неделю
⤴️
👁 Видео:
➖ Записи ArchDays’24 уже в открытом доступе! YouTube 📣 Если пропустил конференцию или хочешь пересмотреть крутые доклады — плейлист с видео уже доступен!

➖ Хардкорная веб-разработка: проектирование структуры БД VK Video

➖ Kafka: что нужно знать Системному аналитику YouTube | VK Video Вы узнаете, что важно учитывать при постановке задач разработчикам, познакомитесь с принципами работы распределенной архитектуры и асинхронным взаимодействием сервисов внутри системы на примере подсистемы технической поддержки.

➖ Системный дизайн: взгляд со стороны продуктовой разработки» VK Video Особенности продуктовых компаний, сценарии архитектурных сессий и язык системного дизайна. Рекомендации по развитию навыков специалистам бизнес-анализа и системного анализа.

➖ Разбор PMBOK 8: Революция отменяется? Rutube
— Что изменил PMI в восьмой редакции PMBOK? Хорошо это или плохо?
— Как подготовиться к изменениям?
— Когда будет опубликована новая редакция? Какие изменения в экзамене вступят в силу и когда?

➖ Individual Contributors, Site Reliability Engineering и надежность YouTube | VK Video
Новый выпуск подкаста Фичи Катятся с Сашей Поломодовым, техническим директором из Т-Банка!

📱 Посты ТГ
➖ REST: синхронное или асинхронное взаимодействие.
➖ Уровни кэширования.
➖ Как НЕ потерять все наработки после продуктивного мозгового штурма?
➖ 10 вопросов, которые волнуют новичков в IT.
➖ Как подготовиться к собеседованию в компанию мечты и получить оффер?
➖ Всё, что нужно знать про брокеры.
➖ 3 реальных задачи, которые решают брокеры сообщений.
➖ Удалёнка против офиса: разнос «аргументов».

📖 Статьи
➖ Именно эти умения и навыки делают меня аналитиком.
Автор статьи выделяет ключевые навыки системного аналитика: аналитическое мышление, умение задавать вопросы, находить решения, быстро адаптироваться к изменениям, системно мыслить, моделировать процессы и эффективно коммуницировать, подчёркивая, что успех зависит не от технических инструментов, а от гибкости, управления процессами и способности закрывать пробелы в команде. Особое внимание уделяется рефлексии, инициативности, которые позволяют предотвращать застои и обеспечивать слаженную работу даже в условиях неидеальных процессов.

➖ Канбан Метод: не магия, а логика. Наводим порядок в хаосе.
Статья развенчивает распространённые мифы о Канбан-методе, подчёркивая, что это не просто визуализация задач, а системный подход к управлению процессами через анализ данных, гибкую адаптацию и оптимизацию потоков работы в интеллектуальном труде.

➖ Почему Redis работает так быстро, несмотря на то, что он однопоточный?
Несмотря на однопоточную обработку запросов, Redis достигает высокой производительности за счёт работы в памяти, минималистичных операций и фоновой многопоточности для отдельных задач, а для масштабирования рекомендует кластеризацию вместо усложнения архитектуры.

➖ Руководство по Use Cases.
Статья представляет собой подробное руководство по созданию и применению Use Cases (сценариев использования), объясняя их роль в структурировании требований через описание взаимодействий пользователя с системой для достижения целей. В материале разбираются этапы разработки сценариев, шаблоны документации, инструменты моделирования процессов (BPMN), типичные ошибки и связь с другими UML-диаграммами, подчёркивая важность Use Cases для согласованной работы команды и тестирования функционала.

#подборка #SA #BA #аналитик #IT

Хорошо проведённый выходной - залог успешной рабочей недели💪
Предпочитаю куда-то выбираться на выходных, лишь бы не сидеть в четырёх стенах! А как вы проводите выходные ❓

#философияЖизни #life