Всем приветик!

Сегодня познакомимся с процессом собеседований и посмотрим ключики для их оптимального прохождения
🤓🤓🤓
Чуть позже рассмотрим правильное составление резюме и прохождение фильтров hr

HR скриннинг - фильтр на залетных
Вам позвонил hr. Что он спрашивает? 🤔

Вопросы о предыдущем месте работы
Например: Над чем работал, сколько человек было в команде и т.д.
🗝 Чтобы пройти этот этап, надо иметь цельную историю о предыдущем месте и давать социально одобряемые ответы.
Историю о пред. месте можно составить, посмотрев списки типичных hr вопросов или пару раз созвониться с hr)
Социально одобряемые ответы.
Почему ушел с предыдущего места работы?
Все зае❌ Я хотел развиваться, а на прошлом проекте были старые технологии ✔️

Базовые вопросы по вакансии
Например: Понимаете ли принципы работы rest/web сервисов, очередей сообщений.
🗝 На подобные вопросы всегда отвечаем да.
Или оцените свой навык владением технологией от 1 до 5. 🗝 Тут ставим не ниже 4.
Могут быть открытые вопросы по базовым темам - тут необходимо или знать, или пользоваться сторонними источниками)

Технический собес - практикуемся в технологиях⌨️

Абстрактные вопросы по предыдущей работе
Например: Какую самую сложную задачу Вы делали, главное достижение на предыдущем месте работы.
🗝 Необходимо собрать список основных подобных вопросов и сформировать ответы, которые устроят работодателя.
В идеале - самая сложная задача состояла из технологий из вакансии.

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

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

Доброго времени суток, дорогие подписчики!
Продолжим наш обзор этапов собеседований

Знакомство с командой - фильтр на адекватность и вхожесть в команду😊
Самый последний этап, на котором надо не зафейлиться🤦‍♂️🤦‍♂️
На этом этапе, может быть пару технических вопросов - для повторной проверки компетенций.
Но в основном:

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

Вопросы про взаимодействие в коллективе и перспективы
Например: Как ты решал конфликтные ситуации? Кем ты видишь себя через 5 лет?
🗝 И снова давать социально одобряемые ответы + ответы, которые устроят работодателя.
Конфликты - неотъемлемая часть рабочего процесса, решал уточнением, чем недоволен оппонент + принимал его сторону или старался спокойно объяснить свою точку зрения.
Через 5 лет я бы хотел развиться в Вашей компании (например) до архитектора, выступать с докладами и менторить(обучать) младших коллег.
Для этапа знакомства с командой тоже будет плюсом ознакомиться со списком основных вопросов (например тут) и подготовить на них развернутые ответы, от которых работодатель будет прыгать от счастья.

Немного резюмируем
Учитесь продавать себя, давайте социально одобряемые ответы, Вы должны понравится работодателю🕺
Но главная идея отличного прохождения собеседования - десятки уже пройденных собеседований.
Собеседуйтесь и на следующих собесах будет проще! Да прибудет с Вами сила!😘

Добрый вечер, подписчики! 🤪
Сегодня порадуем вас постом о типичном дне системного аналитика. 😱
Коммерческий опыт нашего гостя 2 года, зп 250к на руки.

Утро

Мой рабочий день начинается в 9:00.
Я не из тех, кто встает заранее, делает зарядку, умывается и прочие инста процедуры.
У меня все просто, встал с кровати в 8:56, сел за комп и ,немного прищуриваясь, начинаю вспоминать, кто я вообще и зачем тут нахожусь.
Полноценно мой рабочий день начинает в 9:30.

Начало работы

9:30 — Просматриваю задачи, которые были сделаны прошлым днем, чтобы отдать их на ревью
10:00-10-30 — Провожу ревью задач других аналитиков
10:00-12:00 — Занимаюсь документацией задач, которые вышли в прод

Обэд

12:00-12:30 — Умываюсь и кушаю

ХардВорк

12:30-15:30 — Здесь уже зависит от многих факторов.
Например, из последнего, работа на большим проектом.
Погружение в бизнес требования для определенного процесса.
Проектирование системы, встречи с разработчиками и архитектором и т.д. до бесконечности. Зависит от конкретной задачи.
15:30-16:00 — Кушаю

Причесывание задач

16:00-17:00 — Привожу к хорошему виду всю проделанную работу, сделанную на этапе хардВорка.
Например — красиво по всем шаблонам оформить задачи на разработку.
17:00-18:00 — Статус встреча команды

Чилл

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

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

Что это такое в целом?
Интеграция - обмен данными между системами. Системами могут быть - сервисы, базы данных, внешние сервисы.💻

Зачем оно нужно?
1. Автоматизация процессов
Не нужно вручную переносить данные из одной системы в другую.
2. Целостность данных
Данные синхронизируются между системами. Например, остатки товаров в магазине и на складе всегда актуальны.
3. Быстрое масштабирование
Можно добавлять новые сервисы, не переписывая существующую систему.
4. Повышение производительности
Люди меньше таскают данные руками — системы делают это за них быстрее🏃‍♂️

Виды интеграций:

1. По способу взаимодействия
1.1 API - через запросы
1.2 Файловые - обмен файлами
1.3 Базы данных - смотрим данные в базе
1.4 Event-driven - реагируем на события

2. По архитектуре

2.1 PointToPoint(p2p) - одна система ходит к другой
2.2 Шина интеграции - все кладут в шину, все читают из шины
2.3 Микросервисная - микросервисы ходят друг к другу за данными
2.4 Integration Platform as a Service (iPaaS) - скидываем данные в облако, читаем из облака

На этом наш обзор закончен. Скоро расскажем про конкретные интеграции подробнее.
Не бойтесь интеграций!😊

Всем хай!!

Как выбрать компанию? 🥸

Рассмотрим их виды их отличительные черты.

Аутсорс/Аутстаф 🤨

Работа над проектом заказчика.

➕ Работа с различными технологиями - стек от проекта к проекту чаще различается
➕ Разнообразие сфер - из разных сфер
➕ Легкий вход - зачастую не требуют больших тех. скиллов
➖ Переработка - могут заставить поработать в пт. и выходные, в пн. уже закрывать проект 🤷‍♂️🤷‍♂️🤷‍♂️
➖Смена фокуса внимания - иногда работа на двух и более проектах
➖ Зп ниже рынка - т.к. вас "перепродают" заказчику
➖ Всегда будете загружены - после проекта, будет следующий

Вывод:
Быстрый рост в тех. скиллах, насмотренность, но высокая нагрузка и зп ниже рынка.

Маленькие продуктовые компании 👶

Работа над проектом компании, в небольшом коллективе.

➕ Возможность поучаствовать в запуске продукта
➕ Опыт "на все руки" - можно побыть и аналитиком и тестировщиком и дворником 😱
➕ Быстрый рост - в силу малой конкуренции проще расти
➕ Возможность влиять на продукт - проще согласовать свою идею
➖ Малая стабильность - могут завтра всех уволить
➖ Переработка - тоже можешь работать все выходные
➖ Зп ниже рынка - у маленькой компании нет много денег

Вывод:
Почти как аутсорс/аутстаф, но со своим продуктом и обозримой возможностью роста.

Компании побольше оставим на попозже. Всем бобра! 🦫

Всем привет! Закончим обзор компаний корпорациями.

Корпорации💪

Продуктовые компании "побольше".
Работа над крупными проектом с множеством команд.

➕ Высокая стабильность - постоянная зп, просто так не уволят
➕ Плюшки - страховки, иногда премии, обучения
➕ Большие проекты - большие нагрузки на систему + в опыт
➕ Хорошие зп - иногда выше рынка 🤑
➖ Сложно грейдится - в компании еще 150 человек на вакансию повыше, почему именно тебя повышать?
➕➖ Бюрократическая машина - иногда можно сидеть без задач, потому что ее еще не согласовали.
Но если что то надо сделать быстро, то это недостаток
➕➖ Нет обширности технологий - ты работаешь только над своей областью ответственности.
Но нет и широты рабочих задач - тестировать функционал будет тестировщик.

Вывод:
Стабильность, плюшки, иногда чиллово, но нет быстрого роста.

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

Собеседуйтесь и вы обязательно найдете себе компанию по душе! 😍

Доброго времени суток, подписчики!

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

На вас поставили задачу. Ваши дальнейшие действия?
Если у вас нет четкого плана - сейчас сделаем и будем на него опираться в будущем 😎

1️⃣ Прочитайте постановку несколько раз.

Определи чего не хватает и что непонятно.
Уточни это у автора задачи или у коллег, которые могут это знать.
Вуаля - у нас полная постановка ☺️

2️⃣ Какой результат должен получиться?

Что будет результатом - документация, работающая интеграция, составленное тз?
Непонятно? Идем к автору. Или сделаем не то, что нужно 😳

3️⃣ Слона есть по кускам.

Если задача большая и непонятная - разбей ее на пункты 🤓
Как можно более подробные. Для небольших задач - также рекомендуется.

4️⃣ Обязательно фиксируй процесс выполнения.

По списку из 3 пункта ставьте галочки напротив всех выполненных задач ➕
Так процесс выполнения станет нагляднее и достижимее. И на дейлике будет что сказать.

5️⃣ Найди похожие задачи.

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

6️⃣ Собери всю необходимую информацию.

Если это взаимодействие с другой системой - изучи документацию или распроси коллег.
Если тз - уточни требования 👨‍💻

7️⃣ Совсем не вяжется? Начни с простого.

Если не получается идти по плану из 3 пункта - начни с простого ❓
Почитай доку, сделай набросок тз, спроси коллегу.
В процессе ты погрузишься в задачу и будет проще ее выполнение.

8️⃣ Коллеги - наши главные помощники.

Если застряли с чем-то больше, чем на пол часа - идите к коллегам.
Не бойтесь обращаться за помощью. Это упрощает и ускоряет работу.
И все знать невозможно 🤝

9️⃣ Записывай все, что может быть полезно.

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

И помни - ты все сможешь! Делай все последовательно и все выполнится.
Особенно, когда есть план действий 🌱

Хочешь стать сеньором? Надо пройти собес на сеньора.
Всё. 🧠

Нет, серьёзно. Ни один руководитель не назначит тебя сеньором по внутреннему ощущению или табличке в Confluence с твоими успехами.
Сеньор - это не звание, а уровень. Уровень задач, ответственности и стрессоустойчивости. 😳

Что нужно, чтобы пройти собес на сеньора?
1. Опыт.

Да, тупо надо поработать.
Но не сводить всё к "сделал таску - свободен". Надо ещё:
⚡️Разруливать хаос
⚡️Объяснять другим, почему "так делать не надо"
⚡️Иногда - тащить проект в одиночку, пока другие в отпуске

2. Спокойствие.

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

3. Истории.

Будь готов рассказать:
⚡️ Как спас проект
⚡️ Как облажался (и что сделал потом)
⚡️ Как общался с разработкой, когда они “не так поняли”

4. Здравый смысл.

"А зачем усложнять согласование, если можно просто добавить чекбокс?"
Если такие вопросы для тебя - норма, то ты на правильном пути. 🍌

5. Тренируйся на реальных собесах.

Чем чаще ты собеседуешься, тем лучше звучит твоя “легенда”.
Собес - это как прокачка: чем больше собесов, тем крепче броня.
🤓🤓🤓

А что точно не нужно?

🎭 Сайт-визитка с вашим лицом в круге 🤡
🎓 Сертификат “Аналитик будущего. Интенсив за 3 дня”

В следующем посте мы поглубже копнём в сам процесс собеседования:

⚡️Что чаще всего спрашивают
⚡️Как не зависнуть на вопросе “А чем вы гордитесь?”
⚡️И почему SQL - это как вишенка на торте 🍒

Оставайся - будет интересно! 😉

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

Собес - это всегда немного экзамен с элементами шоу.🎪

Ты два часа рассказываешь, какой ты молодец.
Говоришь: "всё зависит от бизнес-контекста", киваешь, улыбаешься, делаешь умное лицо.🤓
Половина сказанного - просто чтобы звучать уверенно.
Вторая половина - чтобы выжить. Потому что вопросы будут.

Что спрашивают почти всегда

❓ Как собирал требования, если заказчик говорил
"там всё просто и очевидно"
❓ Что делал, когда система №1 говорила одно, система №2 - другое, а пользователь - третье
❓ Как писал ТЗ - по шаблону, по наитию или по боли
❓ Как объясняли заказчику, что его хотелка - это 3 месяца и новая команда?
❓ Как оценивал объём задач - и что делал, когда всё поехало

А теперь - хлеб с маслом: интеграции.

😑 : "А вы работали с интеграциями?"
😑 : "А какие типы знаете?"
😑 : "А как в вашем проекте происходил обмен данными между системами?"

На сеньора это спрашивают почти всегда. Потому что интеграции - это как взрослая жизнь:

всё сложно, всё где-то ломается, всё зависит от кого-то.😭

И, конечно, SQL.

😑"А какие запросы вы писали?"
😑"На что способен? JOIN, подзапрос, оконные?"
😑"А прямо сейчас можешь - вот тут, на доске?"

Почему это спрашивают?
SQL - это универсальный язык данных. Он показывает, умеешь ли ты работать с реальными таблицами, можешь ли сам вытащить нужное, и насколько глубоко понимаешь, что лежит под капотом у продукта.
А ещё... ну просто все обожают поспрашивать SQL. Такой собесный фетиш 😳

А как не завалиться?

⚡️Подготовь 2-3 истории: спас проект, косякнул, вытащил
⚡️Освежи: где ты реально принимал решения, а не просто “вёл задачу”
⚡️Вспомни: как выглядело ТЗ, как ты работал с багами, как решал конфликты
⚡️Посмотри свои старые проекты - там есть всё, о чём тебя спросят
⚡️И если истории нет - придумай 😁. Уверенность в голосе важнее, чем реальность событий.

Главное правило:

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

Знаешь, кому пора апгрейднуться до сеньора? Отправь ему этот пост, пусть готовится без иллюзий.😂

Апгрейд на сеньора. Часть 3 - про факапы

“Расскажите про неудачный опыт” - самый неожиданный и коварный вопрос на собесе. 😳
Не потому что у тебя не было факапов, а потому что ты не хочешь о них вспоминать...

Но вот правда:

❗️ Если у тебя не было факапов - ты либо ничего не делал, либо врёшь.🤓
❗️ Факап - это не позор. Это элемент взросления.
❗️ И да, на собесе это спрашивают почти всегда - особенно на сеньора.

Зачем вообще про это спрашивают?☹️

✅ Понять, умеешь ли ты признавать ошибки
✅ Посмотреть, что ты делал, когда всё пошло по одному месту
✅ Проверить, умеешь ли вырулить, не обвиняя всех вокруг
✅ И главное - чему ты научился

Как рассказать про неудачи и не утонуть?

📌Расскажи контекст - где был, что делал
📌 Опиши проблему - честно, но спокойно
📌 Скажи, что ты предпринял - переобулся, упростил, перезаключил, признал и спас.
📌 Сделай вывод - один. Без этого факап остаётся просто факапом. С выводами - становится ростом.💪

Примеры реальных факапов

😢Собрал требования не с теми людьми - сделали всё по ТЗ, только не то, что реально нужно бизнесу.
😢 Заказчик сказал “ничего сложного” - а там 4 системы, и у всех разная правда.
😢 Не зафиксировал в письме устное решение, а потом: “кто сказал?”, “а у нас в протоколе нет” и ты крайний.
😢 Забыл добавить одно поле в API - и весь фронт потом падал как подкошенный

Что говорить нельзя

🤥 «У меня не было факапов» - сразу минус 10 к доверию
🤥 «Это был не я, это разработка» - опытные аналитики так не говорят
🤥 «Я не помню» - ну тогда и работай джуном дальше

✨Итог✨:

Хорошо рассказанный факап - это не про слабость.
Это про зрелость.
Ты не просто пережил провал - ты из него вышел умнее.
И вот за это тебя и хотят нанять.

Не помнишь ни одного факапа, но на собесе спрашивают?
В следующей части разберём:
😏 как красиво врать, если всё реально забыл
😏 и топ-5 фраз, чтобы факап звучал как подвиг

Оставайся на связи - будет мощно 😎😎

Вам одобрили оффер - зарплата выше, чем вы мечтали.
Но что-то не даёт нажать "принять". Интуиция не ошибается. Иногда высокая зп - это не награда, а компенсация за ад. 🔥

Вот 5 сигналов, что с оффером что-то не так:
➿➿➿➿➿➿➿➿➿➿➿➿➿➿➿
1. Нет аналитиков - вы первый.

Вас зовут "построить аналитику с нуля", "выстроить процессы", "подружиться с продуктом и техом".
Но по факту - вы просто будете бегать между отделами, у которых вообще нет понимания, зачем вы тут.👁

2. Говорят: "Нам нужен универсал".

На собесе спрашивают и про SQL, и про BPMN, и как вы рисуете макеты.
Спойлер: вы будете и аналитиком, и дизайнером, и QA, и иногда менеджером. Плюс играть на баяне на демо.👍
Без шансов на фокус и рост.

3. Никто не может объяснить, чем вы будете заниматься.

"Проектов много, найдём чем заняться", "мы ещё финализируем задачи" - это значит, вы входите в бардак, где ни целей, ни понимания.
А потом ещё и виноватым сделают, если не получилось.🙈

4. Подозрительно тихо про команду.

Вы спрашиваете: кто продукт, кто тех, с кем взаимодействие - а вам отвечают "ну, команда гибкая, распределённая".🫠
Скорее всего, люди там выгорели или текучка лютейшая.

5. Собес - это сплошной стресс.

Если с вами 2 часа грубо разговаривают, перебивают, валят кейсами, а потом говорят "мы любим честность и прямоту" - бегите.
Это не про честность. Это про культуру, в которой вы не выдержите и месяца.

➿➿➿➿➿➿➿➿➿➿➿➿➿➿➿
Высокая ЗП - это круто. Но только если ты за неё не платишь психикой.
Иногда +80к - это надбавка за токсичность, бардак и отчаяние.

Почувствовал что-то похожее в своём оффере?
Скинь этот пост другу - пусть проверит, не заманивают ли тебя в антипроект..😭

⚡️DevTools - суперспособность аналитика⚡️

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

Когда DevTools выручает аналитика?
➿➿➿➿➿➿➿➿➿➿➿➿
1️⃣ Проверить текст и интерфейс

✅ Заказчик говорит: “Тут не тот текст.”
➡️ Открываешь вкладку Elements, находишь нужное место и видишь, что там на самом деле написано.
✅ Нужно показать другой заголовок или текст?
➡️ Меняешь прямо в браузере ➡️ делаешь скрин ➡️ все счастливы 👍

2️⃣ Понять, куда летят запросы

✅ Форма не сохраняется, страница ничего не показывает.
➡️ Открываешь Network ➡️ смотришь, какие запросы уходят и что приходит в ответ.
❕ Видишь ошибку 500 - значит, это проблема на сервере, а не в кнопке. 🆗

3️⃣ Вытащить данные “из воздуха"

✅ Нужно срочно проверить, какие данные приходят на сайт. 🤔
➡️ В Network можно скопировать JSON-ответ и сохранить в файл. Без доступа к БД или API. 👍

4️⃣ Тестировать гипотезы прямо в браузере

Хочешь проверить, как сайт поведёт себя с другими данными?
➡️ В Console можно менять тексты, скрывать или показывать элементы, чтобы быстро посмотреть, как выглядел бы интерфейс или что сломано.
Например:
🖇заменить текст кнопки на более понятный
🖇убрать баннер, который закрывает половину экрана
🖇посмотреть, какие данные прилетают в ответ от сервера
Всё это помогает не ждать ответа от разработчиков неделями и самому понять, где проблема.

➿➿➿➿➿➿➿➿➿➿➿➿
Почему аналитику стоит уметь DevTools?
🖇Быстрее разбираться в проблемах
🖇Понимать, как устроен интерфейс и что там реально происходит
🖇Говорить с командой на одном языке
☺️Да и вообще звучит круче, чем
“я просто всё спрашиваю у разработчиков"

DevTools - это не магия и не только для фронтов. Это твоя суперспособность понимать, что происходит в системе. 🙂

Пусть кнопки слушаются тебя, а баги боятся! 🖥 🎟️

Котики передают:
🥇 «Вперёёёёд, добрячки!» 🥇
➿➿➿➿➿➿➿➿➿➿➿
🔺Но только до 18:00!
Потому что выходные уже рядом и даже самый мощный добрячковый котик (ты💗) заслужил отдых.

💬И помни💬:
🟣если захочется кого-то прибить на созвоне - вспомни про выходные
🟣если всё горит - подуй
🟣если грузят задачками - кивай, улыбайся… и думай про отдых

И чилловой тебе пятницы!💃

Как соблюдать work-life balance, если ты аналитик
💭💭💭💭💭💭💭💭💭💭💭💭
Баланс - это не столько про «работать мало», сколько про
«не вымотаться к середине недели и не начать мечтать о смене профессии на бариста в кофейне»😕

Вот реальные советы именно для аналитиков⬇️

📞 Созвоны - это тоже работа

У аналитика всегда есть свои задачи.
Но в любой момент может прилететь:
🟡созвон «просто чтобы быть в курсе»
🟡консультация по другому сервису
🟡просьба помочь разобраться в смежной теме

Эти встречи могут занимать час-полтора - и это нормально, хоть и слегка выматывает.
Не нужно думать, что они «украли твой рабочий день».
Созвоны и переписки тоже часть жизни аналитика. ☹️

🙏 Не гони себя: анализ - это не спринт

Приходит новая задача ➡️хочется поскорее сесть писать ТЗ, чтобы «не тормозить разработку».💊
Но если тема новая, не прыгай в ТЗ с разбега:
🟡посёрфи документы
🟡поспрашивай коллег
🟡посоставляй схемки

Лучше потратить больше времени на анализ, чем потом сто раз переписывать ТЗ.
Спешка - главный поставщик бессонных ночей и нервного тика. 😳

🔫 Принимай, что день не будет идеальным

Ты садишься за работу с планом:
🟡 закрыть таску
🟡написать кусок ТЗ
🟡допилить диаграмму

А тут вдруг:
🔺прилетает задача "Срочно посмотреть инцидент"
🔺заказчик заявляет: "Мы всё переосмыслили и хотим по-другому"
🔺или разработчик говорит: "У тебя тут в требованиях ошибка"

И всё...твои задачи остались на завтра. А в голове крутится:
"Блин, я не успел сделать свою работу, за которую вообще-то сел!" 🤬

Запомни: аналитик - это не только про таски, но и про решение вопросов.
Не вини себя. Всё идёт по плану. Просто не по твоему.😁

❌ Не сравнивайся

У каждого разная скорость работы.
Не гони себя мыслями: "Я торможу проект" или "Другие всё делают быстрее”.
Это путь к стрессу, бессонным ночам и мечтам об отъезде в лес сторожем...

🧘 Заботься о теле - это тоже часть работы

🟡Нормальный сон, если можешь.
🟡Зарядка утром или хотя бы короткая разминка днём.
🟡Потому что при сидячей работе быстрее болят спина, шея, голова… и душа 🙄

Это не мелочи - от этого тоже быстро заканчивается свага заряд энергии.

📝 Планируй день, чтобы не сойти с ума

Утром выдели 10-15 минут, чтобы прикинуть:
🟡какие задачи горят
🟡что обязательно закрыть сегодня
🟡что можно послать в бэклог до лучших времён 😈

Так голова будет чище, а тревожное “что же я ещё забыл?” будет приходить реже.

😵 Делай перерывы

Не сиди три часа, забыв дышать.
Все люди в офисе или на удалёнке тоже делают паузы:
🟡налить чаю
🟡пройтись или залипнуть в рилсы
🟡сыграть каточку в доту или форзу

Никто не работает нон-стоп восемь часов. Даже тот, кто говорит, что работает.🤥

💬🔤🔤🔤🔤🔤💬

Хороший аналитик - это тот, кто умеет беречь себя, чтобы быть полезным завтра.🧠
Работай в радость - и живи тоже, кчааау!😉

⭐ Интеграции, часть 2.
История о Диме, пицце и API.

Жил-был Дима. Работал аналитиком.
Всё у него было хорошо, пока однажды лид не сказал:

Дим, нам срочно нужна интеграция с сервисом доставки пиццы.
Чтобы наш сайт показывал клиенту, сколько времени ждать пиццу!🍕😱

Дима вспотел.... Что такое эта ваша интеграция? Но потом сел, погуглил и понял, что интеграция через API - это как чатиться, только между системами.

💬 Как работает этот «чат»? Вася представил себе ситуацию:

Он пишет пиццерии в Telegame:
- Привет! Сколько времени ждать пиццу №123?

Пиццерия отвечает:
- 23 минуты, курьер уже выехал!

💻 Вот и API работает так же:

📩наш сайт 🔜 шлёт запрос (request)

📨сервис пиццы 🔜 шлёт ответ (response)

📬 Что в этом сообщении?

Запрос - это как письмо, у которого есть:
🔵Адрес (URL) ➡️ куда писать?
🔵Метод ➡️ что хочу сделать? (узнать, добавить, изменить, удалить)
🔵Заголовки (headers) ➡️ «пароль» или формат письма
🔵Тело (body) ➡️ если передаём подробности, например номер заказа

📝 И в каком формате они болтают?
Пиццерия обычно отвечает JSON-ом. Это как смс, только для программ:

{
  "orderId": 123,
  "status": "В пути",
  "waitTime": "23 минуты"
}

Иногда вместо JSON могут прислать XML, но это уже как бумажные письма - слишком олдскульно.

😱 А если что-то пошло не так?
Дима узнал, что пиццерия может ответить странным сообщением:

🔵ошибка 400 ➡️ «Ты прислал фигню, я ничего не поняла»

🔵ошибка 401/403 ➡️ «У тебя нет доступа сюда, брат»

🔵ошибка 500 ➡️ «У нас пожар на кухне, перезвони позже»

И Дима понял: надо описать в ТЗ, что делать, если пиццерия молчит или ругается....😱

⚠️ А как же безопасность?
Пиццерия не разговаривает с кем попало.
Ей нужен пароль или токен.
Дима разобрался в OAuth и API-ключах и почувствовал себя шпионом. 🥷🏼

🤓И ещё лимиты…
Пиццерия сказала:

- Дим, не пиши нам 1000 раз в минуту. Иначе в чёрный список! 😡

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

🎯 Чему научился Дима?
Теперь он знает, что в ТЗ надо написать:

✅какие данные нужны
✅куда стучаться (URL)
✅каким методом
✅что получим в ответе
✅как ловить ошибки
✅нужен ли токен
✅сколько раз можно спрашивать

✨ И всё! ✨
В следующей части узнаем, как он учился читать документацию API, чтобы не сойти с ума!) 👍

❌ Ошибки, которые совершают начинающие аналитики

Все мы когда-то были новичками. И многие ошибки - это классика жанра.
Вот ТОП-5 граблей, на которые чаще всего наступают начинающие аналитики
⬇️⬇️⬇️

1️⃣ Бояться задавать вопросы
➿➿➿➿➿➿➿➿➿➿➿➿
Новичок сидит и думает:
"Я спрошу и все поймут, что я ничего не знаю..." 😓

А реальность такая: если не спросишь ➡️ сделаешь не то.

Вопросы это твоя суперсила.
Даже опытные аналитики постоянно спрашивают.
И именно здесь начинается рост критического мышления и уверенности в себе! 🤓🤓🤓

2️⃣ Писать слишком абстрактно
➿➿➿➿➿➿➿➿➿➿➿➿
Фраза в ТЗ ➡️ "Система должна быть удобной и функциональной."
И всё... 🤷‍♀️

Но что такое "удобная"? Для кого? Где кнопка? Какая логика?
Хорошее ТЗ - это конкретика и без "воды"

3️⃣Не думать о пользователе
➿➿➿➿➿➿➿➿➿➿➿➿
Новичок может увлечься диаграммами, базами данных, API…🧑‍💻
А потом оказывается, что конечный пользователь психует:
«Я вообще не понимаю, что нажимать!»😡

Аналитик всегда должен думать: «Как это увидит человек?»
Именно это развивает софт-скиллы: умение общаться и ставить себя на место других.

4️⃣ Не фиксировать договорённости
➿➿➿➿➿➿➿➿➿➿➿➿
✔️"Ну, мы же на созвоне обсудили..."
✔️"Они же сами говорили, что так хотят..."

Нет бумажки - нет договорёнки. 😏
Всё ключевое фиксируй письменно: в ТЗ, письме, чате.

Это спасёт тебя при спорных ситуациях, когда уже никто ничего не помнит. И релизах.

5️⃣ Бояться "технических" тем
➿➿➿➿➿➿➿➿➿➿➿➿
Новичок часто думает:
"Ох ё...это баги, сервера и коды ошибок - пусть разработчики сами разберутся."
Но нет! Даже если ты не пишешь код, нужно понимать, как работают API, базы, архитектура.
Чтобы правильно писать требования и разруливать дискуссии, защищая своё мнение.

Разбираться в таких темах помогает чувствовать себя увереннее и шире смотреть на задачу.👍

😄🤨😄😉😆
➿➿➿➿➿
Ошибки совершают все.
Главное - это учиться и переставать их повторять.

🛠 Пусть ваши ТЗ будут понятными, а пользователи довольными!

✏️Почему диаграммы BPMN - это не больно, а удобно
(Часть 1)

Когда аналитик слышит слово BPMN, у него два варианта реакции:

😱 "Хоспади, эти кружочки, ромбики, стрелки...я никогда это не освою"

😎"BPMN? Легко. Сейчас как забабахаю!"

🧐Что за зверь - BPMN?

BPMN - это язык описания бизнес-процессов.
Представь, что твой проект - это квест.
У каждого действия есть правила и последовательность.
Вот BPMN и нужен, чтобы всё это нарисовать наглядно и понятно.

🖋Зачем вообще рисовать процессы?

✅Чтобы все поняли логику, а не только ты один.
✅Чтобы заказчик сказал: "Ага, теперь вижу, где лишние согласования"👍
✅Чтобы разработчик понял, в каком порядке строить систему.
✅Чтобы тестировщик понял, где искать баги.

💬 Пример из жизни: Заказ кофе

Без BPMN это звучит так:
Клиент заказывает кофе. Если бариста уточняет сорт, то клиент выбирает. Если всё ок - готовят. Если чего-то нет - предлагают другое.

А в BPMN всё выглядит как чёткий маршрут:
Начало ➡️ Заказ кофе ➡️Проверка ассортимента ➡️ Если есть ➡️ готовим ➡️ конец
❗️ Если нет ➡️ предлагаем альтернативу ➡️ возвращаемся к выбору или конец

И вот тут аналитик понимает: BPMN - это просто инструкция, как пройти этот процесс понятнее.

🔠🔠🔠🔠🔠
🔠🔠🔠🔠🔠🔠 🔠🔠🔠🔠🔠

Не надо бояться кружочков и стрелочек.
BPMN - это как карта метро: сначала страшно, но потом не заблудишься.

💡 Во второй части разберём главные элементы BPMN и лайфхаки, как рисовать диаграммы, чтобы их понимали не только аналитики.🙂

😎 Как писать задачи в Jira, чтобы тебя не возненавидели
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Если ты думаешь, что написать задачу в Jira - это "ну написать же просто", то знай:
так думал каждый, кто однажды получил от разработчика фразу:
"А что именно ты хотел тут?"🤔

Писать задачи - это как завязывать шнурки.
Можно кое-как, можно крепко, а можно по технике "красиво и не развяжется")

✍️Что важно писать в задаче:

✅ Краткое и понятное название

Не надо поэмы. "Добавить фильтр по дате в отчёт" звучит лучше, чем "Сделать штуку для выбора периода, чтобы оно как-то там фильтровалось".

✅Описание задачи

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

✅Что сделать (ToDo)

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

✅Ожидаемый результат

Что должно измениться, появиться или заработать.
Можно прям скриншот или формулировку: «Пользователь видит кнопку "Скачать PDF" справа вверху».

✅Связанные задачи

Если задача - часть фичи, не забудь привязать её к эпику или к другим задачам.

🗂 А где подробности? 🥹 Они в ТЗ)

Задача в Jira - это не роман на 12 страниц. Она должна давать чёткий ответ:
что сделать, зачем это нужно, и где искать детали.
Остальное будет в прикреплённом ТЗ по ссылке на Confluence. Главное - чтобы оно было и было понятно, как его найти.

✨ Бонус от старших аналитиков ✨

👎Не превращай задачу в боль для разработчика.

Если после прочтения задачи хочется задать три вопроса:
"Где это?", "Что делать?" и "Зачем вообще это нужно?" - значит, она написана плохо...
Пиши задачи так, чтобы разработчик мог сразу приступить к работе, а не играть в «угадай контекст».

📌 Добавляй метки и компоненты

Станешь любимчиком своего лида и PM. 😻

🧠 Прочитай задачу сам, как будто ты её получаешь впервые.

Всё понятно? Или хочется задать вопрос? Если второе - доработай.

📎 К посту добавили чеклист для самопроверки, чтобы не тратить время команды на выяснение, "что ты имел в виду", удачи!

✏️ Почему диаграммы BPMN - это не больно, а удобно
(Часть 2)

Продолжаем говорить про BPMN - язык, который помогает описывать процессы не в виде простыни текста, а в виде понятных диаграмм.

Если ты аналитик, то рано или поздно столкнёшься с задачей визуализировать процесс.
И лучше сделать это грамотно - так, чтобы и бизнес понял, и разработка.

🟣Для этого и существует BPMN - язык визуального описания бизнес-процессов🟣

💡 Он помогает:
⏺объяснить, как работает процесс, без лишней воды
⏺сделать требования понятнее для разработчиков и тестировщиков
⏺выявить пробелы и лишние шаги
⏺быстро показать бизнесу, что, где и как происходит

❗️У BPMN простая и логичная структура:

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

🧠Если хочешь разобраться подробнее, то мы подготовили для тебя шпаргалку по BPMN)
Там всё по полочкам: термины, примеры, инструменты.

📎А ещё в конце бонусный блок: что кратко и уверенно ответить про BPMN на собеседовании, чтобы показать, что ты реально шаришь.

На этом тему BPMN мы закрываем, но шпаргалку оставляем с вами 😉
Сохраняй и возвращайся, когда нужно быстро освежить память!