Апгрейд на сеньора. Часть 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 мы закрываем, но шпаргалку оставляем с вами 😉
Сохраняй и возвращайся, когда нужно быстро освежить память!

🧠 Почему аналитикам важно учить SQL

"А я ведь не разработчик… Мне точно нужен SQL?" 🤔

спросил аналитик и в тот же день получил просьбу:

"Посмотри, плиз, в БД, почему клиент оформил заказ, но в системе он не появился".

〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
💡 SQL - это не про код, а про контроль.
⏪Контроль над тем, где лежат твои данные и что в них происходит⏩

✅ Аналитику SQL нужен, чтобы:

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

🔍 Пример из жизни:

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

Без SQL ты пишешь в командный чат: "Коллеги, кто может глянуть в базе?.." 🤦‍♂️
И дальше: ожидание, уточнение, 3 подхода к выгрузке и горящая попа...
А с SQL: открыл базу данных, написал JOIN, GROUP BY, HAVING, посмотрел результат и пошёл пить чай 🤓🤓🤓

👍 Что ты сможешь делать с SQL:

✔️искать «молчащих» пользователей (активны, но не конвертируются)
✔️считать повторные действия
✔️находить баги в данных
✔️трекать активность по времени и устройствам
✔️чувствовать себя не маленькой свинкой пеппой 🐹, а настоящим папой свином 🙂

📝 Базовый минимум по SQL, которые нужно знать аналитику:

✔️SELECT ➡️ выбрать нужные данные из таблицы
✔️WHERE ➡️ отфильтровать записи по условию
✔️JOIN ➡️объединить данные из разных таблиц
✔️GROUP BY + COUNT➡️ сгруппировать и посчитать
✔️ORDER BY + LIMIT ➡️отсортировать и показать только нужное
✔️Работа с датами ➡️ например, найти записи за последние 7 дней

💪 SQL - это как табличный Наруто.
С виду скучный, а внутри - мощнейший навык, если знаешь, как обращаться)

📎Сохрани себе этот пост и наконец начни учить SQL, а не только добавлять курсы в избранное. 👁

📚 Плюсы работы аналитиком: профессия для гуманитариев

Если ты когда-то выбирал между "журналистикой", "филфаком" и "что-нибудь творческое", а теперь пишешь ТЗ и делаешь выгрузки - поздравляем, ты прекрасный гуманитарий в мире данных.
И это не баг, а фича 😌

Вот почему аналитика - это идеальная профессия для гуманитариев:

💬 1️⃣Ты умеешь формулировать мысли

- кратко, понятно и по делу.
А это суперскилл, когда нужно объяснить, чего хочет бизнес, что делает система, и почему кнопка не просто серая, а неактивная при условии X.

💬2️⃣Ты привык работать с текстами

Ты не боишься прочитать 20 страниц требований, выделить из них 3 смысла и превратить это в 1 диаграмму.
Для тебя «прочитать всё» - это не пытка, а способ понять. У многих на этом уже всё ломается, так что ты молодец)

🎭3️⃣Ты умеешь ставить себя на место другого

Понимание пользователя - твой второй диплом.
Ты заранее чувствуешь: "А вот тут будет непонятно. А здесь точно забудут нажать".
И в этот момент рождается UX-аналитик, эмпат и спасатель фронтенда.

❓4️⃣Ты умеешь задавать вопросы

Не просто "а зачем?", а:
- "Правильно ли я понял(а), что пользователь может видеть только свои заказы?"
- "А если он не авторизован, мы что ему покажем?"

Это навык интервью, аналитического мышления и чистой коммуникации.

🧠 5️⃣Тебе не нужно быть технарём

Ты можешь выучить SQL, научиться читать схемы БД и понимать API без страха и лишней математики.
Тебе не нужно писать код, чтобы быть крутым аналитиком.
Нужно уметь думать, слушать и объяснять. А этого у тебя с избытком.

📎 Аналитика это не про "технарей с матаном".
А про людей, которые умеют разбираться, объяснять, связывать и упрощать.
А значит - гуманитарии, вэлком.
Мы тут нужны 🤗

🌀Как гуманитарию выучить SQL и не сойти с ума🌀
(и даже полюбить это дело, прости господи)
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Если ты:
*️⃣ на «филфаке» учил латынь
*️⃣ путаешь SELECT с DELETE
*️⃣ и слегка потеешь, когда видишь слово JOIN
То ты не один, мы все там были 🤥
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Вот как подойти к SQL по-гуманитарному
(и не травмироваться):

✏️ 9⃣Воспринимай SQL как язык.

Это правда язык, только вместо подлежащего ➡️SELECT, а вместо сказуемого ➡️ FROM users.
Ты буквально учишься писать запросы, как предложения:
➡️ "Выбери имена из таблицы, где возраст больше 30".

📚🔢Не учи всё сразу.

Тебе не нужно знать WINDOW FUNCTIONS в первую неделю.

Начни с минимума:
⏺SELECT, WHERE, JOIN,
⏺GROUP BY, HAVING, ORDER BY,
⏺COUNT, SUM, CASE WHEN - как грамматика, только чуть интереснее)

И всё, этого хватит, чтобы решать 80% задач.

🤓🔢Сразу учись на своих задачах.

Не запоминай синтаксис всухую.
Лучше возьми реальную задачу из работы или курса и реши её.
Тогда JOIN будет не страшным, а нужным.

👍🔢Ошибки - это нормально.

Ты будешь писать WHERE после GROUP BY,
забывать ON в JOIN,
удивляться NULL в фильтрах.

Это не признак тупости, просто мало практики)

💙 Ты гуманитарий. Ты умеешь работать с информацией, видеть структуру и объяснять сложное простым языком.
А SQL это просто ещё один язык и ты с ним справишься)

📎 Сохрани, если ты "анализируешь с душой, но пока без подзапросов".

📄 Интеграции, часть 3.
Как Дима научился читать API-доки и не бросил всё ради работы бариста
➿➿➿➿➿➿➿➿➿➿➿➿
После успешной интеграции с пиццерией Дима почувствовал себя уверенно.
Но вскоре пришёл новый вызов....😕

"Нужно подключить сервис хранения документов. У них есть API, разбирайся по документации 🖕"

😕 Он открыл первую API-доку в жизни…и закрыл через 10 секунд.

"Что за query? Что за bearer-token? Почему всё серым?..."

📘Что делать, когда API-дока кажется непреодолимой ❓
Вот как Дима подошёл к задаче, спокойненько и по шагам:

🔍1️⃣Определи, что тебе нужно сделать

Не читай всю документацию сразу, сначала посмотри на задачу:
➡️ “Нужно получить список загруженных документов по ИНН”.

Значит ищем методы типа getDocuments, searchByInn и т.п.
Фокус только на нужной бизнес-операции.

🧱2️⃣Разберись с авторизацией

Скорее всего, доступ по токену или ключу.
Уточни, где и как его получить, без этого тестировать запросы не получится вообще.

📝3️⃣Найди пример запроса и ответа

👍 Хорошая документация содержит:

🔴URL запроса
🔴HTTP-метод (GET, POST…)
🔴Заголовки (headers)
🔴Пример тела запроса/ответа (body)
🔴Пример ответа
🔴Пример ошибки

Если нет ➡️ ищи Swagger или Postman Collection.
Если и этого нет ➡️ смирись и пиши разработчикам)

💻 4️⃣Проверь, можно ли тестировать

У некоторых API есть песочница, у других боевой сервер, на который страшно даже смотреть.

Дима проверил тестовый ключ и получил ответ 403 Forbidden.🤨
Значит, идём к интеграторам и уточняем условия доступа.

⚠️ О чём никто не предупреждает

🔴 Документация может врать. Ну или устареть, такое часто бывает.
🔴 Примеры в документации могут не работать, например: кавычки не те, переносы лишние.
🔴 Некоторые поля - обязательные, но это нигде не указано.
🔴 Токен может жить 5 минут. Или 5 лет. Непредсказуемо.
🔴 Названия методов не всегда логичны.
🔴 Ответ может прийти в XML, а ты уже настроился на JSON.
🔴 Иногда сервер просто молчит, ни ошибки, ни ответа. И это нормально (нет).

✅Что понял Дима:

✔️ Начни с задачи.
✔️ Не бойся непонятных слов, всё гуглится.
✔️ Без понимания бизнес-сценария документация бесполезна.
✔️ Примеры важнее слов.
✔️ Ошибки - это нормально, главное знать у кого спрашивать.

📌Продолжение следует...
В следующей части Дима будет разбираться, как тестировать API и ловить баги раньше QA.

🤖 Интеграции, часть 4.
Как Дима тестировал API и ловил баги раньше QA
➿➿➿➿➿➿➿➿➿➿➿➿➿➿
Когда Дима только пришёл в проект, он думал, что API-интеграции это дело разработчиков.
Типа они напишут, QA потестит, ну а я, аналитик, просто опишу метод и свободен. 😅
Спойлер: ➿не свободен➿

Оказалось, что если хочешь, чтобы интеграция заработала не через боль и 7 итераций правок, то нужно самому лезть в Постман, проверять ответы и ловить баги.

📌 Что делает аналитик, когда тестирует API?

✅ Проверяет структуру ответа

В ТЗ написано clientName, а в ответе приходит ClientName (привет, капс)! 😎
Или поле вообще забыли отдать, а клиенту оно критично.

✅Сравнивает с документацией

Методу обещали возвращать status, date, id.
А возвращает ok, 1, true, ¯\_(ツ)_/¯.
Значит, где-то на этапе реализации что-то пошло не так и это нужно ловить до QA.

✅Проверяет бизнес-логику

Например, если передать пустое поле, метод должен отдать ошибку.
А он отдаёт: «200 ОК» 🙂 и сохраняет мусор.
😠 Это уже не только проблема фронта, но и возможная уязвимость.

✅Понимает, что фронту будет неудобно

Да, разработчик отдал JSON, но в нём сначала ID-шник, потом массив из 20 вложенных структур, потом статус на английском.
Фронт будет капризничать, а ты будешь в очереди на доработку.😢

🌀Держи в голове важные моменты🌀

⏺ Даже если всё "по спекам" - это не значит, что это удобно.
⏺ Не всё покрывает тестировщик, часто он проверяет "что работает", а не "что удобно или правильно".
⏺ Легче проверить сейчас, чем потом писать баг-репорт на свою же задачу.

🧠 Что использовать:

😊 Postman - любимая игрушка аналитиков.
😊 Swagger/ReDoc/Дока в Confluence - проверяй, совпадает ли описание с тем, что реально приходит.
😊 Логику и пару ложек паранойи - задавай себе вопрос:

"А если бы я был фронтом, смог бы я это использовать?" 🤨

➿➿➿➿➿➿➿➿➿➿➿➿➿➿
📣 Запомни:
⏪хороший аналитик не просто пишет ТЗ, он понимает, как работает система и проверяет, что она делает то, что от неё ждут.
Поэтому не бойся Postman, смотри на респонсы, задавай вопросы, даже если они "глупые".
Ведь лучше поймать баг до релиза, чем потом объяснять, почему ничего не работает.☺️⏩

🤝 Аналитик, UX и фронт:
почему мы не сходимся и как всё-таки договориться
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Если вы думаете, что аналитик написал требования и всё, можно рисовать и кодить, то… добро пожаловать в реальность.
Тут начинается самая весёлая часть: у каждого своя правда. 😅
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Откуда вообще берутся требования на дизайн? Не падают же они с неба.
Обычно они приходят ➡️

🔵от бизнеса: "хочу красиво и быстро, как у конкурента"
🔵от пользователей: "зачем тут три кнопки, я путаюсь"
🔵от аналитика: "у нас процесс вот такой, значит, нужны поля и статусы"

И в этот момент становится понятно, что все смотрят на задачу под разным углом. 😩

➿Пример➿

🎨 UX защищает пользователя

UX-дизайнер смотрит глазами обычного человека:
"Три поля на первом экране? Пользователь закроет форму через 5 секунд.
Давайте скроем два поля под расширенные настройки, а оставим только самое важное". 🙏

🤓 Аналитик защищает бизнес

"В требованиях написано: три обязательных поля, чтобы юристы были спокойны.
Да, пользователю это неудобно, но заказчик сказал: “без этих данных систему не примем”." 🙅‍♂️

👨‍💻 Фронт защищает реальность

Открывает макет, видит выпадающий список на 1000 элементов и поиск по мере ввода:
"Для этого нужен отдельный API. Или вы хотите, чтобы я из воздуха нарисовал данные? Может ограничим список хотя бы до 20 позиций?"😡

И вот здесь аналитик как дипломат. Его задача:
✔️ объяснить бизнесу, что "всё и сразу" = дорого и долго
✔️ показать UX, какие фичи критичны, а какие можно упростить
✔️ вместе с фронтом найти технически адекватный компромисс

🫂 Как в итоге подружиться:

😀 Начинайте вместе

Аналитик пишет требования ➡️ UX подключается и думает, как это воплотить ➡️ фронт проверяет, что это реально собрать.
Если включаются все по очереди, то жди правок бесконечно. 🥵

😀 Помни, кто за что отвечает:

✔️UX ➡️ за удобство, но может не знать про ограничения API
✔️Аналитик ➡️ за бизнес и процессы, но иногда забывает про кнопочку, которую все ждут
✔️Фронт ➡️ за то, чтобы всё это жило в коде, но может не понимать бизнес-логику

😀 Не спорьте ради спора

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

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

⚡️Вывод:
Аналитик + UX + фронт = три силы, которые вместе делают качественно.
Если держаться заодно, продукт будет и работать, и выглядеть классно)

😱 Кто есть кто в проекте для аналитика

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

«Вот это Product Owner, это Project Manager, это QA…»

И ты сидишь и думаешь: «А со всеми этими людьми как вообще разговаривать…?»

Держи мини-шпаргалку ⬇️
😀😀😀😀😀😀😀😀😀😀😀😀😀😀

👑 Product Owner (PO)

Представитель бизнеса внутри команды. Отвечает за то, что именно будем делать.
🟣Приносит идеи и хотелки от бизнеса.
🟣Решает, что попадёт в backlog, а что пока в стол.
🟣Может менять приоритеты (и будет).

Для аналитика PO - главный источник требований. С ним ты уточняешь цели, проверяешь ценность фичи и выбиваешь ответы на вопросы «а зачем?».

🎩 Project Manager (PM)

Человек, который следит за сроками, ресурсами и договорённостями.
🟣Планирует релизы, договаривается с бизнесом и командой.
🟣Может снять с тебя лишние запросы от стейкхолдеров.
🟣Помогает, если нужно объяснить бизнесу: «без аналитики и нормальных требований продукт не взлетит».

Для аналитика PM - не враг, а скорее защитник и координатор.

🧑‍💻 Разработчики (Dev)

Те, кто пишет код.
🟣Делают задачу ровно так, как ты её описал.
🟣Если описал мутно - вернутся с вопросами или сделают «по-своему».

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

🔍 QA (тестировщики)

Те, кто проверяет продукт на баги и несостыковки.
🟣Смотрят, работает ли фича так, как описано.
🟣Выявляют, что ты недосказал в требованиях.

Для аналитика QA - союзники. Если наладить контакт, они помогут поймать ошибки ещё до продакшна.

🎨👨‍🎨 UX/UI дизайнеры

Те, кто отвечает за то, как выглядит и ощущается продукт.
🟣Делают прототипы и макеты.
🟣Смотрят, чтобы сценарий был удобным для пользователя.

Для аналитика дизайнеры - зеркало здравого смысла: иногда «логично в ТЗ», но неудобно в интерфейсе.
Лучше обсуждать вместе, чем спорить постфактум.

🧘Scrum Master / Тимлид

🟣Следит за процессами и встречами (планирование, ретро,
🟣Руководит разработчиками, помогает с техническими решениями.

Для аналитика это опорные роли: помогут разрулить конфликт «что хочет бизнес» vs «что реально сделать».

🎯 Итог

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

Требования: что это вообще и зачем их делить

Первые месяцы в аналитике всё кажется простым:
Собрал хотелки ➡️ написал ТЗ ➡️ ⏮готово⏭

Но быстро выясняется, что требований несколько уровней, и если их не разделять, продукт превращается в лотерею "кому что повезёт получить". 👀

📌Разбираем основные уровни требований:

💼 Бизнес-требования

Что хочет бизнес и зачем проект вообще нужен

Примеры:
*️⃣сократить время оформления заказа
*️⃣увеличить продажи через сайт на 20%

🔑Зачем аналитику:
Поняв бизнес-цель, можно предложить другой способ реализации.
Иногда бизнес просит "новую форму", а решением окажется автозаполнение.

〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
👤 Пользовательские требования

Что должен уметь делать пользователь, чтобы бизнес получил выгоду

Примеры:
*️⃣покупатель может отслеживать статус доставки в ЛК
*️⃣менеджер может быстро находить заказ по номеру телефона клиента

🔑Зачем аналитику:
Помогает команде придумать более удобные сценарии.
Не всегда нужна сложная форма, иногда достаточно поиска "в одну строку".

〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
⚙️ Системные (функциональные) требования

Что должна делать система,
чтобы пользователь смог выполнить свой сценарий.

Примеры:
*️⃣хранить историю заказов пользователя
*️⃣отправлять уведомления о доставке на email

🔑 Зачем аналитику:
Даёт возможность обсудить с разработкой варианты реализации.
Иногда можно сделать MVP, а сложное решение отложить.

〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🛡 Нефункциональные требования

Как система должна работать, чтобы было стабильно.

Примеры:
*️⃣система должна обрабатывать 1000 запросов в минуту
*️⃣данные клиента должны храниться в зашифрованном виде

🔑Зачем аналитику:
Позволяет объяснить бизнесу, что "под капотом" тоже есть ценность.
Быстрая работа и безопасность напрямую влияют на клиентов.

〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🤯 Ошибки новичков

👎Пишут сразу системные требования, не понимая бизнес-целей.
👎Смешивают всё в одну кучу: и бизнес, и пользователя, и систему.
👎Забывают про нефункциональные требования, пока что-то не сломалось.
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Итог

Требования - это не просто список задач в Jira.
Это цепочка:
зачем бизнесу ➡️ что нужно пользователю ➡️ что делает система ➡️ как она работает.

Разделяя уровни, аналитик перестаёт быть "писателем ТЗ" и становится тем, кто помогает находить лучшие решения)

Интервью с заказчиком: как не уйти с пустым блокнотом

Один из первых навыков аналитика ➡️ умение разговаривать с заказчиком.
На бумаге это звучит просто: "задавай вопросы и слушай". ✍️
На практике ➡️ заказчик говорит быстро, уходит в сторону, использует термины "для своих", а ты сидишь с блокнотом и думаешь: "Я вообще ничего не понял..".😪

Чтобы встреча приносила пользу, нужно знать не только что спрашивать, но и как.

📝 Подготовка
〰️〰️〰️〰️〰️〰️
📎 Разберись в теме заранее: кто заказчик, чем живёт бизнес.
📎 Составь список вопросов: про цели, проблемы, пользователей.
📎 Подготовь инструмент записи (ноут, блокнот, диктофон). Память подводит, особенно на второй час разговора.

❓Какие вопросы использовать
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
Полезно комбинировать разные форматы:
✔️ Открытые:
"Что для вас главное в этом процессе?" ➡️ человек расскажет больше.
✔️ Закрытые:
"Эта функция обязательна?" ➡️ быстро получаешь конкретику.
✔️ Уточняющие:
"Когда вы говорите “ускорить работу”, о какой части процесса речь?"
✔️ Контрольные:
"Правильно ли я понял, что…"

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

🤨 Как вести себя на встрече
〰️〰️〰️〰️〰️〰️〰️〰️〰️〰️
🙂 Слушай больше, чем говоришь.
🙂 Не спорь, а уточняй.
🙂 Перефразируй услышанное, чтобы проверить, что понял правильно.
🙂 Не стесняйся "простых" вопросов - часто они вытаскивают самые важные детали.

🖊 Как фиксировать
〰️〰️〰️〰️〰️〰️〰️〰️
📎 Делай заметки в процессе, не пытайся запомнить всё.
📎 Если встреча длинная - лучше записать встречу.
📎 После встречи оформи резюме: "мы договорились о том-то" и пришли заказчику.
Это твоя страховка от фразы "я такого не говорил".

⏪ Какой вывод ⏩

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

Аналитик, который понял бизнес-контекст, превращается из писателя ТЗ в адвоката продукта. 😎😎