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

Все мы когда-то были новичками. И многие ошибки - это классика жанра.
Вот ТОП-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.
Это цепочка:
зачем бизнесу ➡️ что нужно пользователю ➡️ что делает система ➡️ как она работает.

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

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

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

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

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

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

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

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

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

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

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

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

Артефакты аналитика: инструменты или музей экспонатов?

Когда только начинаешь работать аналитиком, хочется блеснуть:

"Сейчас нарисую BPMN, накидаю UML, составлю словарь терминов и напишу ТЗ на 40 страниц - вот тогда все поймут, что я профессионал".🤓🤓🤓

На деле половину этих артефактов никто не откроет.

Главный вопрос:
❓что реально помогает команде, а что остаётся "для галочки" ❓
〰️〰️〰️〰️〰️〰️〰️〰️
🎯 Рабочие артефакты:

✔️ Протоколы встреч

Спасают от фразы «я такого не говорил». Даже 5 строчек лучше, чем ничего.

✔️ Backlog и задачи в трекере

Живой организм. Если там бардак, винить будут именно тебя.

✔️ Описание требований

Основа для разработки и тестирования. Не фанфик, а понятные сценарии и критерии.

✔️ Схемы и прототипы

Иногда одна картинка экономит час разговора. Особенно если процессы сложно объяснить словами.

〰️〰️〰️〰️〰️〰️〰️〰️
🗿 Артефакты-музейные экспонаты

🔘Схемы, которые рисуются "для красоты" и пылятся в Конфлюенсе.
🔘Документы, написанные ради отчётности, а не для команды.
🔘ТЗ на десятки страниц, которые устаревают быстрее, чем их дочитали.

〰️〰️〰️〰️〰️〰️〰️〰️
🔑 Как понять, что артефакт нужен
Задай себе три вопроса:

1️⃣Им реально кто-то пользуется?
2️⃣Помогает ли он принять решение или избежать ошибок?
3️⃣Его легко обновить, если что-то изменилось?

Если хотя бы два ответа «да» ➡️ артефакт рабочий.
Если нет ➡️ это сувенир, а не инструмент.
〰️〰️〰️〰️〰️〰️〰️〰️
⏪Итог⏩

Артефакты - это не коллекция "смотрите, сколько всего я сделал".
Они нужны, чтобы упростить жизнь команде: зафиксировать договорённости, объяснить сложное простыми словами и держать процессы под контролем.

Всё остальное - просто музей аналитика.
Красиво, но бесполезно.🤷‍♀️

Аналитик и разработчик: как перестать говорить на разных языках

Представь ситуацию:
✍️ - Ты пишешь задачу: "Форма должна работать быстрее".
🧑‍💻 - Разработчик спрашивает: "Быстрее - это сколько секунд?"
✍️ - Ты: "Ну… быстрее".

И всё, дальше начинается бесконечная переписка и сюрпризы на демо...

🤯 Почему так?
🔴Аналитик мыслит словами "удобно, красиво, быстро".
🔴Разработчик - "таймаут, эндпоинт, обязательное поле".

И если не перевести с языка на язык, получится два параллельных мира

🛠 Что реально помогает:
📍 Говорить конкретикой. Не "отчёт", а "Excel с колонками X, Y, Z и фильтрами по дате".
📍 Прописывать критерии готовности. Например: "Если пользователь ввёл кривой email, показываем ошибку “Проверьте адрес”".
📍 Добавлять сценарии: как работает по плану, что делать при ошибке, что если пользователь сделал что-то странное.

📎На встречах важно не отбиваться от вопросов разработчиков.

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

📎Разработчиков реально бесят размытые фразы типа "сделайте красиво", "чтобы было удобно". 🤦‍♂️🤦‍♂️
Или когда аналитик говорит: "Ну вы же умные, сами придумаете".
А ещё хуже, когда посреди спринта прилетает: "Ой, давайте добавим ещё вот это". 🥺

📎Что они любят?
🙂Когда всё чётко и понятно.
🙂Когда аналитик на связи и быстро отвечает в чате.
🙂Когда есть не только "что сделать", но и "зачем это бизнесу".

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

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

🚀 Касательно этой темы подготовили мини-чеклист: как расти через общение с разработкой

1. Задавай «почему» и «как»
〰️ спрашивай у разработчиков не только "что сделать", но и "почему так" и "как это работает под капотом".

2. Фиксируй новые термины
〰️ API, кэш, индексы, нагрузка - записывай всё, что непонятно, и разбирайся. Через месяц твой словарь будет толще, чем у вчерашнего "джуна".

3. Учись предлагать варианты
〰️ когда понимаешь бизнес-цель и технические ограничения, можешь предложить компромисс. Это сразу выводит тебя на уровень миддл+ и выше.

©️ QA и аналитик: союзники или враги? ©️

Представь: ты написал требование➡️

Пользователь вводит телефон и жмёт “Сохранить”.

Приходит QA и спрашивает:
😐: А если пользователь введёт буквы вместо цифр?
😐: А если он нажмёт кнопку десять раз подряд?
😐: А если интернет пропадёт в этот момент?

Ты внутренне закатываешь глаза и спрашиваешь: "Ну кто так будет делать?" 🤦‍♂️
А QA отвечает: "Пользователь. Всегда". 🙂

Кажется, что тестировщик придирается. На самом деле он показывает дыры в требованиях.

©️Чем тестировщики полезны аналитику©️

🟡Находят серые зоны

Ты написал "валидируется",
а QA уточнит: "Что именно должно происходить?".

🟡Смотрят глазами пользователя

Пользователь любит всё ломать) QA проверяет это вместо тебя.

🟡Держат продукт в тонусе

Они вовремя находят ошибки, которые могли бы стать позором на проде..

©️Как работать с QA©️

🟢Зови их на обсуждения требований. Пусть зададут вопросы до того, как начнётся разработка.

🟢Прописывай happy path (успешный сценарий) и ошибки (что делать, если что-то пошло не так).

🟢Не воспринимай вопросы как атаку. QA не спорит с тобой лично - он спасает продукт как минимум от того, чтобы не возвращать задачу обратно аналитику.

©️Типичные конфликты©️

Ты не описал этот сценарий 👎

👉 Если можно понять по-разному, то они поймут неправильно. Пиши конкретнее.

Я проверил, оно работает не так ❌

👉 Твои слова - не аргумент. Требование должно быть однозначным.

Зачем ты придираешься? 😑

👉 QA не придирается, а показывает, где продукт сломается.

Это не моя зона ответственности 😑

👉 Если в требованиях нет логики, ответственность как раз твоя.

🧷Какие выводы мы можем сделать?

QA и аналитик часто спорят. Но это не конфликт, а совместная работа.
Аналитик думает о том, что должно работать.
QA думает о том, что может пойти не так.

Если слушать друг друга, продукт выйдет крепким, а не "идеальным только на бумаге".🎉

Изменения требований: бизнес снова 🌟передумал🌟

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

🤔 Почему так происходит

🟢 Бизнес живой: сегодня у компании одна цель, завтра другая.
🟣 Пользователи жалуются, находят неудобства и требуют доработок: приходится добавлять "костыли" прямо на ходу.
🟣 Детали вылезают позже: в начале кажется, что задача простая, а потом выясняется: "ой, там ещё миллион нюансов".

🤔 Что делать аналитику

💙Фиксируй всё
Нет записи = не было договорённости. Протокол встречи всегда будет твоим щитом)

💙Обозначай последствия
Скажи: "Хорошо, меняем. Но тогда сдвигаем срок/увеличиваем бюджет/откладываем часть задач".
Пусть их решение будет осознанным.

💙Не смешивай backlog с текущим спринтом
Новые идеи в идеале должны отправляться в backlog. Спринт пусть идёт по плану.

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

💙Уточняй приоритет
"Срочно" часто означает "очень хочется". Спроси: "Что случится, если сделать через неделю?".

🧨 Ошибки новичков

🔴 Соглашаются на всё сразу, а потом сроки (и жопки) горят, команда злится.
🔴 Правят задачи на лету и рушат планирование.
🔴 Не объясняют команде, зачем изменения и вследствие встречают сопротивление.

🙏 Фразы, которые спасут при изменениях

💚 "Я зафиксирую изменение и вернусь с оценкой влияния на сроки и бюджет".
💚"Чтобы добавить эту задачу, нужно решить: какую из текущих мы убираем?"
💚"Сделаем, но тогда часть фичи пойдёт в следующий релиз. Это ок для вас?"

💡Что мы с вами уяснили

Изменения требований - это не катастрофа, а часть жизни продукта.
И задача аналитика - это не бороться с ними, а управлять: фиксировать, согласовывать, объяснять.

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

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