📄 Интеграции, часть 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 должны знать, что и зачем меняется, чтобы потом ни для кого не было сюрпризов.

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

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

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

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

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

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

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

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

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

Системный аналитик: профессия, которая меняет жизнь

Если коротко: это одна из самых ✨интересных✨ и ✨благодарных✨ профессий в IT.
Ты в команде разработки, но не кодишь. Участвуешь в создании продукта, но не сидишь с бессонными ночами у компа.
Но в то же время ты остаёшься тем, кто понимает, как всё устроено и как связать бизнес, пользователей и разработчиков!🎂

🔑 Плюсы профессии

👉 Удалёнка 🪑

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

👉Высокая зарплата (туда же и премии) 💸

📎Аналитики востребованы и рынок это ценит. А уж хороший аналитик всегда в цене)📎

👉Бонусы от компании 🎉

📎ДМС, спортзал, оплата обучения, психологи - всё чаще это норма.📎

👉Гибкость в графике 💻

📎Если правильно выстроить процессы, реально работать 4–5 часов в день, а остальное время жить свою жизнь📎

👉Разнообразие задач 🍌

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

👉Рост 📞

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

🚀Почему это интересно?
Потому что это не подработка в кофейне, не смена на заводе и не "попробую продавать на ВБ".
Ты не привязан к кассе и не зависишь от капризов клиентов.
Ты получаешь больше свободы и роста:

👉Сам управляешь своим временем и не пашешь по 12 часов
👉Работаешь головой, а не на износ
👉Зарабатываешь больше и чувствуешь себя увереннее

И плюсик - каждый день узнаёшь, как устроены приложения и сервисы, которыми пользуются миллионы людей.
Это реально увлекает и даёт ощущение, что ты двигаешь прогресс, а не просто закрываешь смену)
🧷🧷🧷🧷🧷🧷🧷🧷🧷🧷🧷
А если хочешь стартовать быстро и с практикой, приходи на наш ➡️курс по системному анализу⬅️.
Там мы учим всему, что реально нужно в профессии на старте: от требований и диаграмм до общения с командой и заказчиками)

Софт-скиллы аналитика: без них никуда

SQL, интеграции и UML - это всё классно.
Но если ты не умеешь договариваться, то твоя карьера будет…как чайник без воды: шумит, но пользы нет 😔

Вот софт-скиллы, которые реально решают 👇

🗣 Задавай вопросы

Боишься показаться глупым? Хуже выглядеть умным и написать фигню.
Вот пример:
➡️ Заказчик говорит: "Надо ускорить процесс".
➡️ Ты уточняешь: "Что именно тормозит: ввод данных, согласование или сервер?".
Без уточнения разработчики будут оптимизировать вообще не то...

👂 Слушай

Закрой рот, открой уши!
Половина ответов всплывает сама, если дать человеку договорить. Иногда заказчик сам формулирует требование, пока проговаривает проблему. И твоя суперсила - не перебивать в этот момент)

🤝 Будь дипломатом

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

И да, иногда твой скилл "держать лицо" важнее, чем знание REST API.

🧠 Думай критически

"Добавьте кнопку" ≠ требование. Это костыль. А вот требование - это "сократить время оформления заказа".
Твоя задача докопаться до сути, а не бегать с кнопками по проекту.

🤔 Что мы поняли?
Аналитик без софт-скиллов это как рилс без звука: что-то происходит, но смысла никто не понимает...
Технику можно добить курсами и практикой. А вот умение слушать, уточнять и договариваться придётся качать каждый день как мышцы)

User stories и acceptance criteria: почему аналитики их любят

Новички часто думают:

Сейчас настрочу ТЗ на 40 страниц, вот это будет документ! 🤭

Но в реальности его никто его не читает. Максимум пролистают до картинок...
А вот короткие user stories и понятные acceptance criteria читают все: бизнес, разработка, тестировщики. И да, ещё иногда сами аналитики (редкость, но бывает).

👤 User story - как мини-рассказ на одну строчку.
Формула простая: как [кто] ➡️ хочу [что] ➡️ чтобы [зачем].

📎Например📎:
"Как покупатель, хочу оформить заказ в 1 клик, чтобы не вводить данные каждый раз".

Красота в том, что бизнесу сразу ясно: "ага, цель - это экономия времени клиента".

✅ Acceptance criteria ➡️ чек-лист счастья
Юзер стори без критериев - как сериал без финальной серии...Вроде интригует, но непонятно, чем кончилось.

📎Пример критериев приёмки📎

1️⃣Кнопка "Заказать в 1 клик" есть на странице товара.

2️⃣При клике подтягиваются сохранённые данные.

3️⃣Система формирует заказ и шлёт уведомление.

Теперь у QA есть сценарии, у разработчиков ориентир, у бизнеса гарантия, что сделали именно то, что хотели.

◽️ Почему это работает◽️

➡️ Разработчики понимают, что именно кодить, а не "сделайте удобно".
➡️ QA получают готовую основу для тестов.
➡️ Бизнес видит: цель достигнута.
И самое главное: их реально читают, в отличие от 40-страничного ТЗ, которое пылится в Confluence и пугает даже автора...
➿➿➿➿➿➿➿➿➿➿➿➿
И бонусом прилагаем 🫸ошибки🫷 в user stories, которые встречаются чаще всего, чтобы вы сразу узнали врага в лицо))

❌ "Как система, хочу.."

Система - не человек. У неё нет желаний. Это сразу минус карма.

❌Описывать слишком общо.

"Как пользователь, хочу удобный интерфейс".
Красиво, но что делать непонятно.

❌Забыли acceptance criteria.

Без них user story превращается в загадку: сделали или не сделали? Кто знает.😐

❌Копипаста ради галочки.

Когда все истории звучат одинаково: "Как пользователь, хочу кнопку, чтобы было хорошо".
Никто их не читает, даже ты сам)

🏳️‍🌈Интервью с выпускницей курса по системному анализу

📎Каждый студент курса мечтает об одном - устроиться на работу.
Сегодня у нас история Леры: ещё недавно она работала в образовании с низкой зп, а теперь она системный аналитик с зарплатой 160 тысяч.
Мы поговорили с ней о пути, трудностях и победах.

➡️ Чем занималась до курса и почему решила пойти в системный анализ?

Лера:
Ох...Занималась много чем, последнее место работы - в образовании. Давно хотела сменить курс.
В айти порекомендовал пойти брат. Купила курс скилбокс BI аналитик, после окончания начала искать работу, но как оказалось, что ты без опыта не нужен никому. А в Скилбокс не особо могли помочь...зп на старте максимум 30 тр.
И в процессе поиска случайно наткнулась на сайт ProSySTalent.
Написала, прошла обучение, собесы, устроилась на работу. Сейчас работаю по аутсорсу, зп 160 тр.

➡️ Что стало главным толчком?

Лера:
Тяжёлый труд и маленькая зарплата)).

➡️ Были сомнения "вдруг не получится" Как с ними справлялась?

Лера:
До сих пор есть!)) Постоянно нужно учиться и развиваться. Уверенность появилась только на работе, когда пошли первые положительные результаты.

➡️ Что было самым увлекательным на курсе?

Лера:
Для меня увлекательно было всё) Нравилось рисовать макеты, чертить схемы.

➡️ Сколько собеседований прошла?

Лера:
До десяти. Но именно второй собес "стрельнул".
Оффер был один, но меня в нём все устраивало, так что долго я не думала и никого с ответом не ждала.

➡️ Что почувствовала, когда получила оффер?

Лера:
Ура! Для меня собесы - это треш))

➡️ С какими трудностями столкнулась в начале и как их решала?

Лера:
Меня сразу кинули на задачи))
Причем API надо было сделать в Свагерре, просидела все выходные и ночи, чтобы изучить. На задачу было 4 дня.
Сдала в итоге вовремя, но чуть не сошла с ума) Ручка вышла на 2000 строк...
Ну и последующие задачи все были малознакомы, пришлось коммуницировать, уточнять.
По итогу всё не так и страшно. Косяки есть у всех, даже у людей с огромным опытом.

➡️ Можешь ли выделить, что больше всего нравится в профессии системного аналитика?

Лера:
На моём проекте мы не только СА, мы - фуллстек, нужно уметь делать все.
Последнее время были задачи по БА, там у меня вообще огонь!)
А из СА точно могу сказать, что рисовать схемы, стори и кейсы мне зашли больше.
Нравится, когда у тебя получается и положительный фидбек.

➡️ Сколько часов в день работаешь?

Лера:
Обычно не больше 8 часов, не нужно убиваться) Последние недели просто сидим, задачи все закрыли.

➡️ Что изменилось в жизни после выхода в профессию?

Лера:
Мне нравится то, чем я занимаюсь. И конечно с ростом бюджета появляется много возможностей)

➡️ Твой главный совет тем, кто сейчас учится и тем, кто задумывается начать обучение?

Лера:
Не бойтесь пробовать новое, у вас все получится, нужно немного сил и терпения.

➡️ Какие ближайшие планы?

Лера: Хотим купить дом) И отдыхать начали 2 раза в год, при условии, что у меня двое детей)

🖐В заключении 🖖

🔓История Леры - пример, что системный анализ открывает новую жизнь:
из образования ➡️ в IT с высоким доходом, удалёнкой и планами о собственном доме🔓

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

Аналитик и дизайнер: любовь, логика и пиксели

Сегодня поговорим о той самой связке, без которой любой проект рискует превратиться в миленький, но бардак 👉 об отношениях аналитика и дизайнера.
Потому что можно придумать самую логичную схему на свете, но если интерфейс не отражает логику, то пользователи точно пойдут не туда.

🎨 Когда логика встречает ✨эстетику✨

У начинающего аналитика часто появляется соблазн отойти в сторону:

Дизайн - не моя зона ответственности. Пусть дизайнер сам решает, где какие кнопки. 😄

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

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

👍 Почему аналитик должен участвовать в дизайне?
Потому что именно ты знаешь контекст задачи: кто пользователь, зачем он сюда пришёл, и чего мы вообще хотим добиться.
Без этого понимания дизайнеру тяжеловато: он рисует интерфейс 🖐по ощущениям 🖖, а не по логике.

📎Вот пример

Кнопка "Отправить" стоит до поля для ввода.
Нет обозначения обязательных полей.
Подсказка спрятана, потому что 🖐так красивее 🖖.

И всё, сценарий пошёл вообще не так, как надо....

💬 Как общаться с дизайнером и не устраивать пиксельные войны
Мы много раз видели, как аналитики спорят с дизайнерами до хрипоты.
А на самом деле всё решается одной привычкой - говорить про логику, а не вкусовщину.

📎Ещё пример:

👨‍🎨 Дизайнер: "Я уберу подсказку, она мешает".
💻 Аналитик: "Если её убрать, пользователь не поймёт, что поле обязательное. Система вернёт ошибку".

Но есть выход - вместе находим вариант, где и красиво, и работает.

🧠 Фразы, которые спасут ваши нервы

✔️"Супер выглядит! Можно я уточню сценарий?"

✔️"А давай посмотрим глазами пользователя?"

✔️"Мне нравится, но тут может сломаться бизнес-логика".

✔️"А если сделать вот так, что думаешь?"

И самая проверенная 😎

✔️"Заказчик сказал сделать так, значит придётся так"


Так что дружи с дизайнером.
Он поможет сделать твои схемы живыми, а ты - его макеты умными)

📁📂 Интеграция: с чего начать разбираться

Этот месяц посвятим интеграции - тому, как системы обмениваются данными и зачем всё это нужно бизнесу.

🟰 Что такое интеграция?

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

⏭ Пример ⏮

Представь, есть сайт, где пользователь оформляет заказ, и есть отдельная система склада.
Когда заказ создан, сайт должен передать данные о нём на склад, чтобы там зарезервировали товар.
Это и есть🟡интеграция🟡: сайт отправляет запрос, склад отвечает, что заказ принят.

📌 Передача может идти по-разному:

➡️ через API - когда один сервис обращается к другому по
HTTP-запросу
(например, POST /createOrder)
➡️ через обмен файлами - CSV, XML или JSON, которые передаются по расписанию.
➡️ через брокер сообщений - очередь, куда система кладёт события, а другая их читает.

📌 Зачем это нужно?

➡️ Чтобы не вводить одни и те же данные вручную и не терять информацию между системами.
Если интеграция выстроена правильно, то данные попадают туда, куда нужно, а пользователи даже не задумываются, что внутри происходят десятки обменов.

📌 Роль аналитика в интеграции

➡️ Аналитик описывает правила этого обмена.
Он отвечает за то, чтобы обе стороны одинаково понимали:

🔸какие поля передаются (и их типы)
🔸какие методы вызываются
🔸что возвращается в ответе
🔸как обрабатываются ошибки
(например, 400 Bad Request или 500 Internal Server Error).

✅ Также аналитик фиксирует три вещи:

🔸Триггер - что запускает интеграцию
(например, создание документа).
🔸Формат - как выглядит запрос и ответ
(JSON, XML, CSV).
🔸Условия синхронизации - когда и как часто данные передаются.

👀 Что будет дальше?
В следующих постах мы поговорим о подробнее о том,
🔸как читать API-спецификации и понимать структуру методов;
🔸чем REST отличается от SOAP
(и почему их часто сравнивают)
🔸зачем нужны брокеры сообщений и сервисные шины

⏭и как аналитик оформляет всё это в требованиях, чтобы разработчики понимали друг друга⏮

⚙️ API и спецификации: как в них не запутаться (часть 1)

⭐️Привет!⭐️
Продолжаем цикл про интеграции.
Сегодня разберёмся, что такое API и зачем аналитику вообще туда смотреть.

📎 Что такое API простыми словами

API - это способ, с помощью которого одна система обращается к другой.
Можно представить, что это меню в кафе:
Ты выбираешь блюдо (метод), добавляешь параметры (например, “без лука”), отправляешь заказ и ждёшь ответ.

Запрос выглядит примерно так:

POST /login
{
  "login": "user@mail.ru",
  "password": "1234"
}

А в ответ приходит:

{
  "status": "ok",
  "userId": 42
}

Вот и всё. Система сказала: "Принято, вот твой ID".

📎 Что хранится в спецификации

Чтобы все понимали, как вызывать методы и какие данные ждать, создают ⏭спецификацию⏮
В ней описано:
🔵адреса методов
(например, /login, /user),
🔵типы запросов
(GET, POST, PUT, DELETE),
🔵параметры
(обязательные и необязательные)
🔵структура тела запроса и ответа,
🔵коды ошибок и их расшифровка

➡️ Для REST-сервисов часто используют Swagger (он же OpenAPI) - можно открыть в браузере и прямо кликнуть по методу, чтобы увидеть пример.

➡️ Если же API работает через JSON-RPC, структура немного другая:

{
  "jsonrpc": "2.0",
  "method": "user.getInfo",
  "params": { "userId": 42 },
  "id": 1
}

А ответ приходит с тем же id и результатом внутри result.

📎Что важно аналитику

1️⃣Понимать источник данных.
Откуда метод берёт информацию и что возвращает: база, внешний сервис, кэш.

2️⃣Фиксировать форматы.
Например, дата может быть 2025-10-13 или 13.10.2025. Если не уточнить - потом будет весело...

3️⃣ Уточнять ошибки.
Что значит 400, 401, 500, и что делает система в каждом случае.

4️⃣ Следить за связями.
Методы редко работают поодиночке. Часто один вызывает другой, и важно понять цепочку.

📎 Что дальше?
В следующем посте разберём тело запроса и ответа детальнее:
где headers, где body, зачем нужны query-параметры и как по спецификации понять, что и откуда приходит.

📩 Если у тебя API вызывал страх или скуку - самое время разобраться!
Поставь напоминание на следующую часть, чтобы не потерять нить)