Салют! Пишу этот пост с первой рабочей чашкой чая, глядя на экран ноутбука, который последние две недели в основном использовался для новогодних фильмов.
Назовем этот пост: «Первый день после праздников на удалёнке или как вернуться в работу без паники»
Первый рабочий понедельник после самых долгих выходных в году. Лента чатов уже трепещет от сообщений, в календаре мигают забытые встречи, а в почте — ворох писем, часть из которых уже устарела. Такая же история и после отпусков🤯
Раньше я в такие дни пыталась с порога взять всё под контроль: сразу отвечать на все, браться за старые задачи и параллельно вникать в новое. К вечеру я была морально опустошена и была как выжатый🍋 , а чувство вины («не успела, не всё сделала») только росло.
За годы работы (особенно на удалёнке) я выработала для себя стратегию «мягкой посадки» в рабочий режим. Это не про гендер, это про заботу о своей продуктивности и психике. Делиться ею — особенно к месту сегодня.
Мой главный принцип на сегодня: День 1 — это не спринт, а разведка перед боем. Не нужно наваливаться на всё сразу. Нужно сначала понять, что вообще происходит.
Поэтому ловите «Мой чек-лист для первого дня на удалёнке и не только»‼️
1️⃣ Утро понедельника: Режим «Наблюдателя-читателя».
- Первые 1.5-2 часа, как раз за чашкой чая — только на погружение в контекст.
Открываю почту, мессенджеры, Jira/YouTrack.
Моё правило: НЕ ОТВЕЧАТЬ. Только читать, листать, изучать, что-то вспоминать.
- Составляю «Карту происшествий»: в заметках структурирую:
· Какие проекты вышли на финишную прямую, а какие только стартовали?
· Какие изменения в требованиях или сроках произошли?
· Кто и по какому вопросу меня искал? (Составляю список для обратной связи).
2️⃣ Вторая половина дня: Первые шаги и планирование.
- Свожу все задачи (старые и новые) в единый список. Визуализация помогает.
- Пользуюсь матрицей Эйзенхауэра (Срочно/Важно). Часто 70% «горящих» задач после праздников на деле оказываются просто «громкими».
- Выбираю 2-3 микро-задачи, которые можно закрыть за 20-30 минут: отправить короткий ответ, подтвердить время созвона, обновить комментарий в задаче. Эти быстрые победы дают чувство прогресса и, как минимум, мой список дел сокращается.
- Назначаю короткие sync-встречи (15-20 мин) на завтра с тимлидом, проджектом или ключевыми разработчиками. Цель — услышать актуальный контекст живым голосом, а не додумывать.
3️⃣ Если фокус не приходит, и прокрастинация побеждает:
- Метод Pomodoro — спасение. 25 минут работы, 5 минут — отойти от экрана, сделать растяжку, полить цветок.
- Начинаю с самого лёгкого или приятного. Не с прототипирования сложной логики, а с приведения в порядок диаграмм или документации.
❌ Чего НЕ делаю в первую неделю:
1. Не ставлю на понедельник жёстких дедлайсов. По возможности, переношу сложные задачи на вторник-среду.
2. Не пытаюсь «разгрести» все долги одним махом. Распределяю их по дням недели.
3. Не игнорирую усталость. Удалёнка стирает границы, поэтому особенно важно в 18:00-19:00 закрыть все рабочие вкладки и чаты. Мозгу нужен чёткий сигнал об окончании дня.
💎 Мысль для любого ИТ-специалиста:
Наша ценность — в ясности мышления и понимании контекста.
После долгого перерыва, контекст нужно бережно восстановить, а не угадать. Потраченные на это первые несколько часов — лучшая инвестиция в качество вашей работы на ближайшие недели. Они сэкономят кучу времени на переделках и извинениях.
Дайте себе 2-3 дня на полноценную «раскачку». Эффективность не в том, чтобы сразу выдать 200%, а в том, чтобы плавно выйти на стабильные и устойчивые 100%.
Коллеги, а как вы справляетесь с возвращением после долгих выходных? Особенно на удалёнке? Делитесь лайфхаками в комментариях, или ставьте реакции, если что-то схожее с моим чек листом.
Источник: @ba_and_sa
Назовем этот пост: «Первый день после праздников на удалёнке или как вернуться в работу без паники»
Первый рабочий понедельник после самых долгих выходных в году. Лента чатов уже трепещет от сообщений, в календаре мигают забытые встречи, а в почте — ворох писем, часть из которых уже устарела. Такая же история и после отпусков
Раньше я в такие дни пыталась с порога взять всё под контроль: сразу отвечать на все, браться за старые задачи и параллельно вникать в новое. К вечеру я была морально опустошена и была как выжатый
За годы работы (особенно на удалёнке) я выработала для себя стратегию «мягкой посадки» в рабочий режим. Это не про гендер, это про заботу о своей продуктивности и психике. Делиться ею — особенно к месту сегодня.
Мой главный принцип на сегодня: День 1 — это не спринт, а разведка перед боем. Не нужно наваливаться на всё сразу. Нужно сначала понять, что вообще происходит.
Поэтому ловите «Мой чек-лист для первого дня на удалёнке и не только»
- Первые 1.5-2 часа, как раз за чашкой чая — только на погружение в контекст.
Открываю почту, мессенджеры, Jira/YouTrack.
Моё правило: НЕ ОТВЕЧАТЬ. Только читать, листать, изучать, что-то вспоминать.
- Составляю «Карту происшествий»: в заметках структурирую:
· Какие проекты вышли на финишную прямую, а какие только стартовали?
· Какие изменения в требованиях или сроках произошли?
· Кто и по какому вопросу меня искал? (Составляю список для обратной связи).
Цель: не сделать дело, а понять поле деятельности.
- Свожу все задачи (старые и новые) в единый список. Визуализация помогает.
- Пользуюсь матрицей Эйзенхауэра (Срочно/Важно). Часто 70% «горящих» задач после праздников на деле оказываются просто «громкими».
- Выбираю 2-3 микро-задачи, которые можно закрыть за 20-30 минут: отправить короткий ответ, подтвердить время созвона, обновить комментарий в задаче. Эти быстрые победы дают чувство прогресса и, как минимум, мой список дел сокращается.
- Назначаю короткие sync-встречи (15-20 мин) на завтра с тимлидом, проджектом или ключевыми разработчиками. Цель — услышать актуальный контекст живым голосом, а не додумывать.
- Метод Pomodoro — спасение. 25 минут работы, 5 минут — отойти от экрана, сделать растяжку, полить цветок.
- Начинаю с самого лёгкого или приятного. Не с прототипирования сложной логики, а с приведения в порядок диаграмм или документации.
1. Не ставлю на понедельник жёстких дедлайсов. По возможности, переношу сложные задачи на вторник-среду.
2. Не пытаюсь «разгрести» все долги одним махом. Распределяю их по дням недели.
3. Не игнорирую усталость. Удалёнка стирает границы, поэтому особенно важно в 18:00-19:00 закрыть все рабочие вкладки и чаты. Мозгу нужен чёткий сигнал об окончании дня.
Наша ценность — в ясности мышления и понимании контекста.
После долгого перерыва, контекст нужно бережно восстановить, а не угадать. Потраченные на это первые несколько часов — лучшая инвестиция в качество вашей работы на ближайшие недели. Они сэкономят кучу времени на переделках и извинениях.
Дайте себе 2-3 дня на полноценную «раскачку». Эффективность не в том, чтобы сразу выдать 200%, а в том, чтобы плавно выйти на стабильные и устойчивые 100%.
Коллеги, а как вы справляетесь с возвращением после долгих выходных? Особенно на удалёнке? Делитесь лайфхаками в комментариях, или ставьте реакции, если что-то схожее с моим чек листом.
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
❤25🔥13👍7
Салют! Топ-материалов, которые вышли у нас в 2025 году📌
«Повторение - мать учения»!!
📝Требования:
- Работа со стейкхолдерами/заказчиками
- Мои советы по сбору требований
- «Разработка требований» Вигерса, самый краткий разбор
- Инструменты для документирования требований
- Качеств требований в ИТ проектах
- Зачем и как писать ТЗ
- Как начинающему аналитику собрать требования
- Как правильно формулировать нефункциональные требования
- От «хочу» к ТЗ – как системный аналитик превращает хаос в чёткие требования
- Use-Case 3.0: краткое руководство
- Руководство по Use Cases
📌Проектирование | Моделирование | Нотации:
- Краткий гайд по написанию Бизнес-процессов
- Шпаргалка по подходам в зависимости от целей Бизнес-процесса
- Модель Кано
- SMART, INVEST, MoSCoW - простыми словами для новичков
- Руководство по UML с моих уст
- Разговорный UML: как говорить с командой на одном языке
- Руководство по BPMN с моих уст
- Первые шаги в BPMN. Типы диаграмм
- BPMN умер, все сделает ИИ
⚙️ Интеграция | Архитектура ПО:
- Подборка статей по интеграции систем для аналитика
- Модели OSI и TCP/IP + Шпаргалка
- Сборка статей про модели OSI и TCP/IP
- Event Sourcing: что это и зачем его знать системному аналитику
- Зачем аналитику знать Kafka
- Введение в API-интерфейсы для самых маленьких
- API для системного аналитика
- Курс по документированию REST API
- Работ с API по моему примеру
- Проектирование GraphQL API
- Шпаргалка по проектированию REST API
- ACID, BASE, CAP: Фундамент архитектуры распределительных систем
- Архитектура ПО для аналитика: зачем разбираться и как применять с моих уст
- Вопросы с собеседований по архитектуре ПО
🛠️SQL и базы данных:
- Основы БД с моих уст
- Шпаргалки по БД
- Гайд, с чего начать путь работы с данными
- SQL JSONs шпаргалка
🧑💻 Собеседование:
- Мои советы, как пройти Техническое собеседование на роль ИТ-аналитика
- Как подготовиться к собесу
- Тестовое задание на роль СА. И уточняющие вопросы к нему
✅ Разное:
- Нужно ли системному аналитику разбираться в программировании?
- Как не скатиться в имитацию: о роли системного аналитика на проекте
- Эволюция профессии БА|СА
- Влияние ИИ на профессию БА|СА
- UX/UI для системного аналитика и Шпаргалка
- Выгорание на рабочем месте и совета как это избежать. Что делать если уже выгорел, как выйти с этого состояния
Мой мини курс:
- часть 1: Введение в системный анализ
- часть 2: Выявление требований
- часть 3: Интеграция систем
Источник: @ba_and_sa
«Повторение - мать учения»!!
📝Требования:
- Работа со стейкхолдерами/заказчиками
- Мои советы по сбору требований
- «Разработка требований» Вигерса, самый краткий разбор
- Инструменты для документирования требований
- Качеств требований в ИТ проектах
- Зачем и как писать ТЗ
- Как начинающему аналитику собрать требования
- Как правильно формулировать нефункциональные требования
- От «хочу» к ТЗ – как системный аналитик превращает хаос в чёткие требования
- Use-Case 3.0: краткое руководство
- Руководство по Use Cases
📌Проектирование | Моделирование | Нотации:
- Краткий гайд по написанию Бизнес-процессов
- Шпаргалка по подходам в зависимости от целей Бизнес-процесса
- Модель Кано
- SMART, INVEST, MoSCoW - простыми словами для новичков
- Руководство по UML с моих уст
- Разговорный UML: как говорить с командой на одном языке
- Руководство по BPMN с моих уст
- Первые шаги в BPMN. Типы диаграмм
- BPMN умер, все сделает ИИ
- Подборка статей по интеграции систем для аналитика
- Модели OSI и TCP/IP + Шпаргалка
- Сборка статей про модели OSI и TCP/IP
- Event Sourcing: что это и зачем его знать системному аналитику
- Зачем аналитику знать Kafka
- Введение в API-интерфейсы для самых маленьких
- API для системного аналитика
- Курс по документированию REST API
- Работ с API по моему примеру
- Проектирование GraphQL API
- Шпаргалка по проектированию REST API
- ACID, BASE, CAP: Фундамент архитектуры распределительных систем
- Архитектура ПО для аналитика: зачем разбираться и как применять с моих уст
- Вопросы с собеседований по архитектуре ПО
🛠️SQL и базы данных:
- Основы БД с моих уст
- Шпаргалки по БД
- Гайд, с чего начать путь работы с данными
- SQL JSONs шпаргалка
- Мои советы, как пройти Техническое собеседование на роль ИТ-аналитика
- Как подготовиться к собесу
- Тестовое задание на роль СА. И уточняющие вопросы к нему
- Нужно ли системному аналитику разбираться в программировании?
- Как не скатиться в имитацию: о роли системного аналитика на проекте
- Эволюция профессии БА|СА
- Влияние ИИ на профессию БА|СА
- UX/UI для системного аналитика и Шпаргалка
- Выгорание на рабочем месте и совета как это избежать. Что делать если уже выгорел, как выйти с этого состояния
Мой мини курс:
- часть 1: Введение в системный анализ
- часть 2: Выявление требований
- часть 3: Интеграция систем
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19❤8👍8🤣2
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Как я навайбкодил сервис генерации диаграмм: 2 недели от идеи до реализации
В данной статье под "вайбкодингом" понимается прохождение всего ЖЦ разработки проекта с использованием ИИ-агентов, без самостоятельного написания программного кода. Проблематика Большинство...
Салют! Когда приходишь на новую работу часто возникает вопрос: «Я ничего не понимаю и как не сойти с ума» 🤯 Сегодня как раз об этом и поговорим))
Что ты видишь в первый рабочий день?:
Вокруг — незнакомые лица, в ушах — непонятные акронимы, в задаче — туман, а в голове — панический внутренний диалог: «Я не справлюсь. Все уже давно в теме, а я даже с чего начать не знаю. Они сейчас поймут, что я — фейк».
Делиться своими лайфхаками.
Страх №1:🤔 «Я ничего не знаю о продукте/домене»
Совет, который меня спас: «не пытайся проглотить слона целиком»
1️⃣ Найди «ядро».
В первые дни я задаю себе один вопрос: «Какую одну главную проблему решает этот продукт/модуль для одного главного пользователя?». Все остальное — фичи, исключения, нюансы — будет нанизываться позже на этот стержень. Я прошу коллег или руководителя нарисовать эту самую простую, базовую схему на доске. Это фундамент.
2️⃣ Составь глоссарий.
В отдельный документ (я люблю OneNote или просто текстовик) начинаю записывать каждое новое слово, аббревиатуру, имя системы. Рядом — расшифровку и контекст, как оно используется.
Это твой личный переводчик. Через месяц в него будет страшно заглянуть — настолько это станет для тебя родным языком.
3️⃣ Изучай не «все», а «от задачи».
Не читай всю документацию подряд. Возьми одну ближайшую небольшую задачу (багфикс, маленькое улучшение) и изучай ровно то, что нужно для ее решения. Так знания укладываются в практический контекст и лучше запоминаются.
Страх №2:🧑💻 «Я не знаю процессов и людей»
Здесь правило простое: первая неделя — не для выдачи результата, а для настройки радаров.
1️⃣ Составь карту stakeholders.
В тихой обстановке я рисую простую схему: кто Product Owner, кто тимлид, кто ключевые разработчики, тестировщики, архитектор. Рядом с именами — пару слов о зоне их ответственности и как они коммуницируют (задает много вопросов? любит лаконичные сообщения?). Это моя социальная карта местности.
2️⃣ Назначь «ознакомительные» чаты.
Я прямо так и говорю: «Привет, я новенькая, хотела бы на 15 минут созвониться, чтобы просто познакомиться и понять твою роль в проекте». Люди почти всегда идут навстречу. Эти 15 минут спасают от недель непонимания, «кому какой вопрос задать».
3️⃣ Уточни ритуалы.
Не стесняйся спросить: «Как у вас принято проводить ревью требований? Куда выкладывать схемы? Как проходит приемка?».
Лучше 10 раз спросить вначале, чем один раз сделать «не по-уставу» и получить недовольство.
Страх №3:😨 «Я не знаю, с чего начать и боюсь сделать ошибку»
Мой главный принцип: показать путь, а не сразу результат.
1️⃣ Декомпозируй страх.
Страшно начать большой эпик? Разбей его на шаги:
1) найти всю существующую документацию
2) провести интервью с 2 экспертами
3) нарисовать AS-IS процесс
4) записать уточняющие вопросы.
2️⃣ Делитесь «сырыми» мыслями раньше.
Вместо того чтобы неделю в тишине копать и бояться, что идея неидеальна, я делаю набросок — в Miro, в виде простого списка вопросов или грубой схемы. И показываю его коллеге со словами: «Вот как я сейчас это вижу, правильно ли я двигаюсь?».
Это снимает груз «создать шедевр с первого раза» и сразу направляет тебя верным курсом.
3️⃣ Задавай «глупые» вопросы.
Это суперсила. Часто именно вопрос «А почему это вот так?» вскрывает устаревшее бизнес-правило или скрытую проблему. Фраза «Пожалуйста, объясните мне, как пятилетнему» — мой секретный ключ к сложным системам.
‼️ Главное, что я уяснила за годы:
· Первые 30 дней — это легальный период «незнания». От вас ждут не готовых решений, а правильных вопросов и активного погружения.
· Ты пришла не как «всезнайка», а как «проводник». Твоя задача — не помнить все, а уметь найти, структурировать и прояснить.
· Страх и дискомфорт — признак роста. Если тебе комфортно и все понятно, значит, ты не учишься новому. Эта первая фаза хаоса — обязательная ступенька к экспертизе.
Если знакомо - поддержи реакциями или расскажи свои советы в комментариях)))
Источник: @ba_and_sa
Что ты видишь в первый рабочий день?:
Вокруг — незнакомые лица, в ушах — непонятные акронимы, в задаче — туман, а в голове — панический внутренний диалог: «Я не справлюсь. Все уже давно в теме, а я даже с чего начать не знаю. Они сейчас поймут, что я — фейк».
Расслабьтесь. Это нормально. Я проходила через это не раз, и с каждым разом училась превращать этот страх из врага в топливо.
Делиться своими лайфхаками.
Страх №1:
Совет, который меня спас: «не пытайся проглотить слона целиком»
В первые дни я задаю себе один вопрос: «Какую одну главную проблему решает этот продукт/модуль для одного главного пользователя?». Все остальное — фичи, исключения, нюансы — будет нанизываться позже на этот стержень. Я прошу коллег или руководителя нарисовать эту самую простую, базовую схему на доске. Это фундамент.
В отдельный документ (я люблю OneNote или просто текстовик) начинаю записывать каждое новое слово, аббревиатуру, имя системы. Рядом — расшифровку и контекст, как оно используется.
Это твой личный переводчик. Через месяц в него будет страшно заглянуть — настолько это станет для тебя родным языком.
Не читай всю документацию подряд. Возьми одну ближайшую небольшую задачу (багфикс, маленькое улучшение) и изучай ровно то, что нужно для ее решения. Так знания укладываются в практический контекст и лучше запоминаются.
Страх №2:
Здесь правило простое: первая неделя — не для выдачи результата, а для настройки радаров.
В тихой обстановке я рисую простую схему: кто Product Owner, кто тимлид, кто ключевые разработчики, тестировщики, архитектор. Рядом с именами — пару слов о зоне их ответственности и как они коммуницируют (задает много вопросов? любит лаконичные сообщения?). Это моя социальная карта местности.
Я прямо так и говорю: «Привет, я новенькая, хотела бы на 15 минут созвониться, чтобы просто познакомиться и понять твою роль в проекте». Люди почти всегда идут навстречу. Эти 15 минут спасают от недель непонимания, «кому какой вопрос задать».
Не стесняйся спросить: «Как у вас принято проводить ревью требований? Куда выкладывать схемы? Как проходит приемка?».
Лучше 10 раз спросить вначале, чем один раз сделать «не по-уставу» и получить недовольство.
Страх №3:
Мой главный принцип: показать путь, а не сразу результат.
Страшно начать большой эпик? Разбей его на шаги:
1) найти всю существующую документацию
2) провести интервью с 2 экспертами
3) нарисовать AS-IS процесс
4) записать уточняющие вопросы.
Вместо того чтобы неделю в тишине копать и бояться, что идея неидеальна, я делаю набросок — в Miro, в виде простого списка вопросов или грубой схемы. И показываю его коллеге со словами: «Вот как я сейчас это вижу, правильно ли я двигаюсь?».
Это снимает груз «создать шедевр с первого раза» и сразу направляет тебя верным курсом.
Это суперсила. Часто именно вопрос «А почему это вот так?» вскрывает устаревшее бизнес-правило или скрытую проблему. Фраза «Пожалуйста, объясните мне, как пятилетнему» — мой секретный ключ к сложным системам.
· Первые 30 дней — это легальный период «незнания». От вас ждут не готовых решений, а правильных вопросов и активного погружения.
· Ты пришла не как «всезнайка», а как «проводник». Твоя задача — не помнить все, а уметь найти, структурировать и прояснить.
· Страх и дискомфорт — признак роста. Если тебе комфортно и все понятно, значит, ты не учишься новому. Эта первая фаза хаоса — обязательная ступенька к экспертизе.
Если знакомо - поддержи реакциями или расскажи свои советы в комментариях)))
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
👍54❤28🔥9
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Как работают микросервисы. Сравниваю с биологией
Привет, меня зовут Диана, я системный аналитик, но биолога и препода так просто из себя не вытравить. Поэтому вернулась к вам с ещё одной статьёй. И это будет большая статья-размышление, так что...
🔥4❤2
Салют! Сегодня у нас наболевшая тема для многих: «Как не бояться менять работу и с легкостью выходить из зоны комфорта»
Коллеги, если бы мы так же боялись обновлять устаревшие системы, как боимся менять работу, мы бы до сих пор работали на Windows XP.
За 12+ лет карьеры от бизнес-аналитика на производстве до лида в IT я сменила не мало компаний. И каждый раз это было страшно — независимо от того, собиралась я в офис или оставалась работать из дома.
Но сегодня я точно знаю: страх перемен — это просто плохо задокументированный процесс миграции.
🤔 Почему мы платим такую высокую цену за «стабильность»?
Неважно, офис или удаленка — механизмы страха одинаковы:
🏢 В офисе вы боитесь:
· Потерять привычный маршрут «дом-работа»
· Потерять свою «рабочую семью», так как вы каждый будний день проводите в офисе со своими коллегами, к которым привязываетесь
· Не вписаться в новый коллектив
· Оказаться под микроскопом начальства
🏠 На удаленке вы боитесь:
· Нарушить свой идеально выстроенный режим дня
· Попасть под тотальный контроль через камеру
· Стать «невидимкой» в новой команде
‼️ Но реальная цена бездействия всегда выше:
· Финансовая: Зарплата ниже рынка на 20-50%
· Профессиональная: Устаревшие технологии в портфолио
· Эмоциональная: Выгорание от бессмысленных задач
✅ Трехэтапный план: от осознания до действия
Этап 1. Диагностика
Создайте «таблицу боли»:
Что меня не устраивает➡️ Оценка 1-10 ➡️ Что это мне стоит
Пример:
ЗП ниже рынка➡️ 8 ➡️ Могу заработать на +300т.р больше (в год)
Опишите в ней то, что вас не устраивает на прежнем месте работы и проанализируйте результаты (у вас может быть своя таблица), может вы вовсе преувеличивайте и все у вас хорошо))
Этап 2. Подготовка
1️⃣ Финансовая подушка:
Мой совет «Сначала поиск и получение оффера - потом увольнение» поиск никак не должен влиять на ваш доход. Без него будет тяжело, либо у вас должны быть накопления минимум на 3-6 мес.
2️⃣ Профессиональный аудит:
Просто составь список вопросов и найди на них ответы:
1. Какие 3 главных навыка ценятся на рынке сейчас?
2. Какой 1 навык мне не хватает?
3. Где взять 5 часов в неделю на его прокачку?
3️⃣ Практическое упражнение:
Раз в неделю ходите на 1 собеседование «для разминки». Это как load-тестирование своих навыков.
Обнови свое резюме и посмотри, где ты вырос, а где нужно подкачаться.
Этап 3. Поиск (системно, а не панически)
- Обновить LinkedIn и резюме. Ключевой фокус — на результатах, а не на обязанностях.
- Активный отклик на вакансии (3-5 в день).
- Интервью + решение тестовых заданий.
И в конце: Принятие решения и оффер + вежливый уход.
💡 💡 Главные инсайты, которые стоили мне 10 лет карьеры
1. Идеальной работы не существует — будет компромисс. Но вы можете выбрать, чем сознательно пожертвовать (в основном это коллектив).
2. Ваша зона комфорта — это навык, а не место — умение быстро создавать эффективную среду там, где оказались.
3. Самый дорогой страх — это страх потерять то, что вас уже не устраивает — парадокс, который держит миллионы людей на нелюбимой работе.
4. Каждая новая работа даёт не только новый опыт, но и новую перспективу — вы начинаете видеть индустрию с другой точки.
Когда я оглядываюсь назад, я не жалею ни об одном переходе. Жалею только о том, что иногда слишком долго колебалась, теряя время, деньги и профессиональную актуальность.
Ваша карьера — ваш самый важный продукт. Вы — и продукт-менеджер, и разработчик, и тестировщик. Не позволяйте страху стать критическим багом в вашей системе принятия решений.
Следующая работа — не обязательно последняя. Это просто следующий спринт. И как в любом спринте — в нём будут свои challenges, свои победы и свой ретроспектив, после которого вы станете сильнее.
Страх — это не противопоказание к действию. Это требование к более тщательному планированию. А планирование — это то, что мы умеем делать лучше всего.
‼️ Решитесь. Спроектируйте свой переход. Запустите миграцию. Ваша следующая, лучшая версия себя уже ждёт в следующей компании. Даже если пока не знает об этом.
Источник: @ba_and_sa
Коллеги, если бы мы так же боялись обновлять устаревшие системы, как боимся менять работу, мы бы до сих пор работали на Windows XP.
За 12+ лет карьеры от бизнес-аналитика на производстве до лида в IT я сменила не мало компаний. И каждый раз это было страшно — независимо от того, собиралась я в офис или оставалась работать из дома.
Но сегодня я точно знаю: страх перемен — это просто плохо задокументированный процесс миграции.
Неважно, офис или удаленка — механизмы страха одинаковы:
🏢 В офисе вы боитесь:
· Потерять привычный маршрут «дом-работа»
· Потерять свою «рабочую семью», так как вы каждый будний день проводите в офисе со своими коллегами, к которым привязываетесь
· Не вписаться в новый коллектив
· Оказаться под микроскопом начальства
· Нарушить свой идеально выстроенный режим дня
· Попасть под тотальный контроль через камеру
· Стать «невидимкой» в новой команде
· Финансовая: Зарплата ниже рынка на 20-50%
· Профессиональная: Устаревшие технологии в портфолио
· Эмоциональная: Выгорание от бессмысленных задач
Этап 1. Диагностика
Создайте «таблицу боли»:
Что меня не устраивает
Пример:
ЗП ниже рынка
Опишите в ней то, что вас не устраивает на прежнем месте работы и проанализируйте результаты (у вас может быть своя таблица), может вы вовсе преувеличивайте и все у вас хорошо))
Этап 2. Подготовка
Мой совет «Сначала поиск и получение оффера - потом увольнение» поиск никак не должен влиять на ваш доход. Без него будет тяжело, либо у вас должны быть накопления минимум на 3-6 мес.
Просто составь список вопросов и найди на них ответы:
1. Какие 3 главных навыка ценятся на рынке сейчас?
2. Какой 1 навык мне не хватает?
3. Где взять 5 часов в неделю на его прокачку?
Раз в неделю ходите на 1 собеседование «для разминки». Это как load-тестирование своих навыков.
Обнови свое резюме и посмотри, где ты вырос, а где нужно подкачаться.
Этап 3. Поиск (системно, а не панически)
- Обновить LinkedIn и резюме. Ключевой фокус — на результатах, а не на обязанностях.
- Активный отклик на вакансии (3-5 в день).
- Интервью + решение тестовых заданий.
И в конце: Принятие решения и оффер + вежливый уход.
1. Идеальной работы не существует — будет компромисс. Но вы можете выбрать, чем сознательно пожертвовать (в основном это коллектив).
2. Ваша зона комфорта — это навык, а не место — умение быстро создавать эффективную среду там, где оказались.
3. Самый дорогой страх — это страх потерять то, что вас уже не устраивает — парадокс, который держит миллионы людей на нелюбимой работе.
4. Каждая новая работа даёт не только новый опыт, но и новую перспективу — вы начинаете видеть индустрию с другой точки.
Когда я оглядываюсь назад, я не жалею ни об одном переходе. Жалею только о том, что иногда слишком долго колебалась, теряя время, деньги и профессиональную актуальность.
Ваша карьера — ваш самый важный продукт. Вы — и продукт-менеджер, и разработчик, и тестировщик. Не позволяйте страху стать критическим багом в вашей системе принятия решений.
Следующая работа — не обязательно последняя. Это просто следующий спринт. И как в любом спринте — в нём будут свои challenges, свои победы и свой ретроспектив, после которого вы станете сильнее.
Страх — это не противопоказание к действию. Это требование к более тщательному планированию. А планирование — это то, что мы умеем делать лучше всего.
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18❤13🔥8
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍2
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Хабр
Говорят ли LLM на языке BPMN? Оценка их возможностей моделирования процессов на основе качественных метрик
Panagiotis Drakopoulos, Panagiotis Malousoudis, Nikolaos Nousias, George Tsakalidis, Kostas Vergidis Аннотация Большие языковые модели (LLM) становятся мощными инструментами для автоматизации...
❤7👍4🔥3
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
Салют! Часто слышу:
На деле это — фундамент, на котором держится весь проект. Неверный сбор требований — это как строить дом без чертежей: вроде всё есть, но жить нельзя.
Вот мой проверенный подход, который спасает от бесконечных правок и «я не это имел в виду».
🧠 Шаг 0: Подготовка и погружение (Самое важное!)
Прежде чем задать первый вопрос:
1. Пойми контекст.
Что за бизнес? Какая его боль? Не «хотим чат в приложении», а «клиенты теряются на этапе выбора услуги, хотят мгновенной консультации».
2. Найди всех, кто «в теме».
Ключевые стейкхолдеры (заинтересованные лица): бизнес-заказчик, будущие пользователи, технические специалисты, поддержка, юристы. У каждого — своя правда.
3. Выучи язык бизнеса.
Говори с финансистами о KPI и ROI, с поддержкой — о нагрузке, с пользователем — о простоте.
📋 Какие бывают требования? (Держи классификацию в голове)
1. Бизнес-требования (Зачем?) — Цели верхнего уровня.
Пример: «Увеличить долю повторных продаж на 15% в следующем квартале».
2. Пользовательские требования (Что?) — Что должны делать пользователи в системе.
Пример: «Возможность оформить возврат товара в личном кабинете за 3 клика».
3. Функциональные требования (Как?) — Конкретные функции системы.
Пример: «Система должна отправлять email-подтверждение при создании возврата».
4. Нефункциональные требования (Каким образом?) — Свойства системы: скорость, безопасность, надёжность.
Пример: «95% страниц кабинета должны загружаться менее чем за 2 секунды при 1000 одновременных пользователей». Часто про них забывают, а потом система «падает».
🛠️ Как собирать? Инструментарий аналитика
Нет одного волшебного метода. Использую комбинацию:
- Интервью (основа) — Готовь вопросы заранее, но будь готов/а уйти вглубь. Спрашивай «почему?» до тех пор, пока не докопаешься до истинной потребности.
- Воркшопы (мозговые штурмы) — Когда нужно собрать разных людей и быстро набросать процессы или идеи. Идеально использовать доску (Miro, Mural и др).
- Наблюдение (погружение в день пользователя) — Посмотри, как люди работают сейчас. Чаще всего лучшие инсайты — между строк и в обход «как должно быть»
- Анализ существующих данных и документов — Что уже есть? Старые системы, отчёты в Excel, письма поддержки, документация — кладезь информации.
- Прототипы и wireframes (иногда картинка говорит громче слов) — Быстро набросай экраны на бумаге или в Figma. Это мгновенно выявляет недопонимание: «А, поле даты нужно здесь? И оно в таком формате?»
📝 Правила фиксации: чтобы поняли все и не было двоякого толкования
- Пиши просто и однозначно. Не «Система должна быстро работать», а «Операция поиска клиента по номеру телефона должна выполняться ≤ 1 секунды».
- Используй стандартные шаблоны (User Stories, Use Cases, диаграммы процессов BPMN). Это как общий язык для команды.
- Всегда указывай источник требования (Кто и на какой встрече это сказал).
- Веди единый реестр требований (в Excel, Jira, Confluence — неважно). Главное — один источник правды, доступный всем.
🚨 Красные флаги (того, что всё пошло не так)
- «Это и так очевидно» (ничего не очевидно).
- Заказчик говорит только в абстракциях («дружелюбный интерфейс») и не может привести пример.
- Требования начинают меняться ежедневно без приоритизации (нужен срочный контроль изменений).
- Техническая команда не задаёт уточняющих вопросов (значит, они что-то додумывают сами).
‼️ Итог: Идеальных требований не бывает
Задача аналитика — не записать каждую мелочь под диктовку, а выявить истинные потребности, договориться о приоритетах и зафиксировать договорённости так, чтобы и бизнес, и разработка поняли друг друга.
Ваш успех — это не когда вы сдали «в точности как в ТЗ», а когда решили бизнес-задачу и пользователи стали работать эффективнее.
В след раз будем разбирать требования на примере, а на каком именно, выбирать вам))) позже сделаю опросник
Источник: @ba_and_sa
«Собрать требования — это же просто сесть и записать, что хочет заказчик?»
На деле это — фундамент, на котором держится весь проект. Неверный сбор требований — это как строить дом без чертежей: вроде всё есть, но жить нельзя.
Вот мой проверенный подход, который спасает от бесконечных правок и «я не это имел в виду».
Прежде чем задать первый вопрос:
1. Пойми контекст.
Что за бизнес? Какая его боль? Не «хотим чат в приложении», а «клиенты теряются на этапе выбора услуги, хотят мгновенной консультации».
2. Найди всех, кто «в теме».
Ключевые стейкхолдеры (заинтересованные лица): бизнес-заказчик, будущие пользователи, технические специалисты, поддержка, юристы. У каждого — своя правда.
3. Выучи язык бизнеса.
Говори с финансистами о KPI и ROI, с поддержкой — о нагрузке, с пользователем — о простоте.
📋 Какие бывают требования? (Держи классификацию в голове)
1. Бизнес-требования (Зачем?) — Цели верхнего уровня.
Пример: «Увеличить долю повторных продаж на 15% в следующем квартале».
2. Пользовательские требования (Что?) — Что должны делать пользователи в системе.
Пример: «Возможность оформить возврат товара в личном кабинете за 3 клика».
3. Функциональные требования (Как?) — Конкретные функции системы.
Пример: «Система должна отправлять email-подтверждение при создании возврата».
4. Нефункциональные требования (Каким образом?) — Свойства системы: скорость, безопасность, надёжность.
Пример: «95% страниц кабинета должны загружаться менее чем за 2 секунды при 1000 одновременных пользователей». Часто про них забывают, а потом система «падает».
🛠️ Как собирать? Инструментарий аналитика
Нет одного волшебного метода. Использую комбинацию:
- Интервью (основа) — Готовь вопросы заранее, но будь готов/а уйти вглубь. Спрашивай «почему?» до тех пор, пока не докопаешься до истинной потребности.
- Воркшопы (мозговые штурмы) — Когда нужно собрать разных людей и быстро набросать процессы или идеи. Идеально использовать доску (Miro, Mural и др).
- Наблюдение (погружение в день пользователя) — Посмотри, как люди работают сейчас. Чаще всего лучшие инсайты — между строк и в обход «как должно быть»
- Анализ существующих данных и документов — Что уже есть? Старые системы, отчёты в Excel, письма поддержки, документация — кладезь информации.
- Прототипы и wireframes (иногда картинка говорит громче слов) — Быстро набросай экраны на бумаге или в Figma. Это мгновенно выявляет недопонимание: «А, поле даты нужно здесь? И оно в таком формате?»
📝 Правила фиксации: чтобы поняли все и не было двоякого толкования
- Пиши просто и однозначно. Не «Система должна быстро работать», а «Операция поиска клиента по номеру телефона должна выполняться ≤ 1 секунды».
- Используй стандартные шаблоны (User Stories, Use Cases, диаграммы процессов BPMN). Это как общий язык для команды.
- Всегда указывай источник требования (Кто и на какой встрече это сказал).
- Веди единый реестр требований (в Excel, Jira, Confluence — неважно). Главное — один источник правды, доступный всем.
🚨 Красные флаги (того, что всё пошло не так)
- «Это и так очевидно» (ничего не очевидно).
- Заказчик говорит только в абстракциях («дружелюбный интерфейс») и не может привести пример.
- Требования начинают меняться ежедневно без приоритизации (нужен срочный контроль изменений).
- Техническая команда не задаёт уточняющих вопросов (значит, они что-то додумывают сами).
Задача аналитика — не записать каждую мелочь под диктовку, а выявить истинные потребности, договориться о приоритетах и зафиксировать договорённости так, чтобы и бизнес, и разработка поняли друг друга.
Ваш успех — это не когда вы сдали «в точности как в ТЗ», а когда решили бизнес-задачу и пользователи стали работать эффективнее.
В след раз будем разбирать требования на примере, а на каком именно, выбирать вам))) позже сделаю опросник
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍33💯10❤9🙏3
На примере чего будем собирать требования?
Anonymous Poll
39%
Котиков
11%
Собачек
3%
Ручки
17%
Чайника
27%
Мне все равно, главное пример
3%
Другое
Салют! Вчера подняли тему сбора требований и по результатам опроса, требования мы будем собирать на «Котика»
Да, вы можете спросить «Зачем?» и «Как это поможет на работе?», но давайте, все же разберем мой подход. Это не только про котов, но и про то, как принимать любые взвешенные решения.
🎯 Шаг 1. Бизнес-требования - Спросите себя: «Зачем?»
Это самый важный вопрос. Без цели любой проект обречен. «Хочу котика» — это не цель, это просто хотелка.
➖ Плохо: «Чтобы было не скучно».
➖ Хорошо: «Для повышения эмоционального фона в семье и снижения уровня стресса после рабочего дня».
✅ Отлично: «Для создания новых семейных ритуалов (вечерняя игра, совместный отдых) и получения опыта ответственной заботы о другом существе».
Ваш итог: Сформулируйте 1-2 главные цели. Например: «Чтобы ребенок научился ответственности» или «Чтобы в пустой квартире было чувство, что тебя ждут».
💁🏼Шаг 2. Пользовательские требования: Поймите «пользователей»
Кто будет взаимодействовать с котом? У каждого — свои потребности.
- Вы (взрослый): «Хочу, чтобы кот снимал стресс, был ласковым, но не будил в 5 утра».
- Ребенок: «Хочу играть и чтобы кот был другом».
- Пожилой родственник: «Хочу тихого компаньона, который будет спать на коленях».
- Аллергик в семье: «Мне важно, чтобы была минимальная линька».
Ваш итог: Запишите сценарии из жизни: что будет делать каждый член семьи с котом утром, днем, вечером.
⚙️ Шаг 3. Функциональные требования: Список «умений»
Что котик должен конкретно делать, чтобы выполнить цели выше?
1️⃣ Использовать лоток с наполнителем. (Критично важно!)
2️⃣ Есть 2 раза в день из миски, не воровать еду со стола.
3️⃣ Проявлять игровую активность (хотя бы 15 минут в день).
4️⃣ Подавать признаки ласки (мурчать, тереться).
5️⃣ Адекватно переносить одиночество в течение рабочего дня.
Это — ваша базовая «инструкция по эксплуатации».
📊 Шаг 4. Нефункциональные требования: Портрет «идеала»
А вот тут самое интересное. Каким должен быть кот?
1️⃣ Характер (Производительность):
- Гиперактивный котенок.
Или
- Спокойный флегматик.
Нужна золотая середина.
2️⃣ Здоровье и надежность:
- Котенок должен быть привит, обработан, без наследственных болезней.
Мы же хотим друга на 15+ лет.
3️⃣ Внешний вид и уход (Дизайн):
Длина шерсти = вашей готовности убирать.
- Шерсть котенка должна быть:
- Длинная — красиво, но везде шерсть.
- Короткая — практичнее.
- Лысый — экзотично, но нужен особый уход.
- Окрас котенка должен быть:
- Белый - маркий.
- Черный - не видно ночью в темноте😉
4️⃣ Совместимость:
- Должен любить (или терпеть) детей, других животных.
5️⃣ Происхождение (Архитектура):
- Породистый (предсказуемый характер, но дорого и возможны болезни)
ИЛИ
- «Дворянин» из приюта (сюрприз, но крепкое здоровье и благодарность).
🎁 Что в итоге? Идеальный кандидат!
По этим требованиям мой «идеальный кандидат» выглядел так:
💡 Главный вывод (и для жизни, и для работы)
Сбор требований — это не бюрократия. Это инструмент, чтобы отфильтровать эмоции и понять истинные потребности.
Хотите кота? Не ищите «милого». Ищите того, кто подходит под ваш ритм жизни.
Хотите новую работу? Не ищите «просто высокую зарплату». Определите ценности, атмосферу, задачи.
Хотите купить квартиру? Составьте список обязательных критериев (метро, этаж, планировка) и свойств (светлая, тихая).
Такой подход экономит время, нервы и спасает от ошибок.
Если понравился пост - ставьте реакции. Буду делать другие примеры.
Источник: @ba_and_sa
Да, вы можете спросить «Зачем?» и «Как это поможет на работе?», но давайте, все же разберем мой подход. Это не только про котов, но и про то, как принимать любые взвешенные решения.
Это самый важный вопрос. Без цели любой проект обречен. «Хочу котика» — это не цель, это просто хотелка.
Ваш итог: Сформулируйте 1-2 главные цели. Например: «Чтобы ребенок научился ответственности» или «Чтобы в пустой квартире было чувство, что тебя ждут».
💁🏼Шаг 2. Пользовательские требования: Поймите «пользователей»
Кто будет взаимодействовать с котом? У каждого — свои потребности.
- Вы (взрослый): «Хочу, чтобы кот снимал стресс, был ласковым, но не будил в 5 утра».
- Ребенок: «Хочу играть и чтобы кот был другом».
- Пожилой родственник: «Хочу тихого компаньона, который будет спать на коленях».
- Аллергик в семье: «Мне важно, чтобы была минимальная линька».
Ваш итог: Запишите сценарии из жизни: что будет делать каждый член семьи с котом утром, днем, вечером.
Что котик должен конкретно делать, чтобы выполнить цели выше?
Это — ваша базовая «инструкция по эксплуатации».
А вот тут самое интересное. Каким должен быть кот?
- Гиперактивный котенок.
Или
- Спокойный флегматик.
Нужна золотая середина.
- Котенок должен быть привит, обработан, без наследственных болезней.
Мы же хотим друга на 15+ лет.
Длина шерсти = вашей готовности убирать.
- Шерсть котенка должна быть:
- Длинная — красиво, но везде шерсть.
- Короткая — практичнее.
- Лысый — экзотично, но нужен особый уход.
- Окрас котенка должен быть:
- Белый - маркий.
- Черный - не видно ночью в темноте
- Должен любить (или терпеть) детей, других животных.
- Породистый (предсказуемый характер, но дорого и возможны болезни)
ИЛИ
- «Дворянин» из приюта (сюрприз, но крепкое здоровье и благодарность).
По этим требованиям мой «идеальный кандидат» выглядел так:
Взрослый (3-5 лет), короткошерстный, здоровый, приученный ко всему, с уравновешенным характером кот из приюта.
Сбор требований — это не бюрократия. Это инструмент, чтобы отфильтровать эмоции и понять истинные потребности.
Хотите кота? Не ищите «милого». Ищите того, кто подходит под ваш ритм жизни.
Хотите новую работу? Не ищите «просто высокую зарплату». Определите ценности, атмосферу, задачи.
Хотите купить квартиру? Составьте список обязательных критериев (метро, этаж, планировка) и свойств (светлая, тихая).
Такой подход экономит время, нервы и спасает от ошибок.
Если понравился пост - ставьте реакции. Буду делать другие примеры.
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
👍30🔥17❤4🤣2🦄1
Салют! Сегодня у нас подборка материалов по сбору требований
- Определение требований: что это такое и как его применять?
- Требования к ПО на пальцах
- Бизнес-требования. Назначение
- Документ бизнес-требований: Что это такое и как его составить [+5 шаблонов]
- Сбор и формирование бизнес-требований для сайта интернет-магазина
- Бизнес-функциональные требования (БФТ): особенности работы и реализации
- Как писать функциональные требования
- Алгоритм описания функциональных требований к системе в формате Use Case
- Нефункциональные требования к программному обеспечению.
Источник: @ba_and_sa
- Определение требований: что это такое и как его применять?
- Требования к ПО на пальцах
- Бизнес-требования. Назначение
- Документ бизнес-требований: Что это такое и как его составить [+5 шаблонов]
- Сбор и формирование бизнес-требований для сайта интернет-магазина
- Бизнес-функциональные требования (БФТ): особенности работы и реализации
- Как писать функциональные требования
- Алгоритм описания функциональных требований к системе в формате Use Case
- Нефункциональные требования к программному обеспечению.
Источник: @ba_and_sa
❤11🔥8👍4
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Первый System Design: Паника, салфетка и инсайт 👇
Салют! Помню свой ужас, когда на собеседовании сказали: «Спроектируйте Instagram». В голове — пустота, а в руках — маркер. Я же аналитик, а не архитектор! Оказалось, это и был ключ.
Главная ошибка: Я начала рисовать сразу.
«Сервер, БД, кеш…» Интервьюер мягко остановил: «А для скольких пользователей? Что важнее — мгновенная загрузка или 100% сохранность фото?» …
Я не задала ни одного уточняющего вопроса.
Старт был провальным.🥲
‼️ Что спасло: Я сделала паузу и сказала:
«Позвольте начать заново. Мне нужно понять задачу». И засыпала вопросами:
- MVP или готовая система?
- Фокус на загрузке или ленте?
- Консистентность или скорость?
Мой главный инсайт: Проверяли не знание технологий, а структуру мышления.
✅ Теперь мой чек-лист (и вам советую):
1. Сначала вопросы, потом линии.
Уточняйте ВСЁ: scope, пользователей, приоритеты (консистентность/скорость/доступность). Это 50% успеха.
2. Считайте «на салфетке».
1 млн пользователей × 2 фото/день = 6 ТБ данных. (Цифры могут повлиять, на архитектуру, дизайн и тд)
3. Рисуйте ядро, а не всю вселенную.
Клиент → балансировщик → API → БД → кеш. Покажите логику, а не каждую технологию.
4. Найдите «больное место» и копайте там.
Для Instagram — это массовая загрузка фото и формирование ленты. Говорите об очередях, кешировании, шардировании.
5. Говорите о компромиссах (trade-offs) вслух.
«Здесь мы жертвуем мгновенной консистентностью ради скорости отклика, используя кеш».
6. Не бойтесь говорить «не знаю, но…».
«Я не уверена в деталях Kafka, но понимаю, что нам нужна устойчивая очередь для обработки фото».
🏁 Итог: Я прошла. Получила фидбэк: «Отлично структурировала задачу, показала product mindset».
System Design для аналитика — это про умение разбирать хаос на части. Не зубрите схемы — тренируйтесь задавать вопросы и считать. Вы умеете это делать каждый день, просто на другом уровне.
Источник: @ba_and_sa
Салют! Помню свой ужас, когда на собеседовании сказали: «Спроектируйте Instagram». В голове — пустота, а в руках — маркер. Я же аналитик, а не архитектор! Оказалось, это и был ключ.
Главная ошибка: Я начала рисовать сразу.
«Сервер, БД, кеш…» Интервьюер мягко остановил: «А для скольких пользователей? Что важнее — мгновенная загрузка или 100% сохранность фото?» …
Я не задала ни одного уточняющего вопроса.
Старт был провальным.
«Позвольте начать заново. Мне нужно понять задачу». И засыпала вопросами:
- MVP или готовая система?
- Фокус на загрузке или ленте?
- Консистентность или скорость?
Мой главный инсайт: Проверяли не знание технологий, а структуру мышления.
1. Сначала вопросы, потом линии.
Уточняйте ВСЁ: scope, пользователей, приоритеты (консистентность/скорость/доступность). Это 50% успеха.
2. Считайте «на салфетке».
1 млн пользователей × 2 фото/день = 6 ТБ данных. (Цифры могут повлиять, на архитектуру, дизайн и тд)
3. Рисуйте ядро, а не всю вселенную.
Клиент → балансировщик → API → БД → кеш. Покажите логику, а не каждую технологию.
4. Найдите «больное место» и копайте там.
Для Instagram — это массовая загрузка фото и формирование ленты. Говорите об очередях, кешировании, шардировании.
5. Говорите о компромиссах (trade-offs) вслух.
«Здесь мы жертвуем мгновенной консистентностью ради скорости отклика, используя кеш».
6. Не бойтесь говорить «не знаю, но…».
«Я не уверена в деталях Kafka, но понимаю, что нам нужна устойчивая очередь для обработки фото».
System Design для аналитика — это про умение разбирать хаос на части. Не зубрите схемы — тренируйтесь задавать вопросы и считать. Вы умеете это делать каждый день, просто на другом уровне.
Источник: @ba_and_sa
Please open Telegram to view this post
VIEW IN TELEGRAM
👏26👍17🔥10❤1