GetAnalyst - Старт карьеры в IT • Системный аналитик • Бизнес-аналитик

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

Если вы ещё новичок в системном анализе и только погружаетесь в слэнг, команда GetAnalyst собрала самые популярные термины из сферы IT, чтобы вам было легче понимать коллег и снизить градус неловкости при общении.

Сохраняйте пост и пользуйтесь при необходимости.

Аттачить — прикреплять файл
Апрув — подтверждение
Апнуться – улучшить навык, получить повышение
Баг — дефект, отклонение
Бэкап — резервное копирование
Бэклог — список задач, требований или идей, которые предстоит выполнить
Валидный — подходит по критериям
Дебажить — проводить анализ ошибок
Зарелизить — выпускать обновление
Костыль — временное решение проблемы, которое не считается идеальным
Митинг — собрание
Логи — файл-отчёт о действиях пользователя/программы
Онбординг — процесс адаптации нового сотрудника
Отревьюить — проверить
Пушить — заставлять, принуждать
Синк — короткая встреча для синхронизации команды
Таска — задача
Тэдэшка — техническая документация
Фиксить — исправить логику, откорректировать процесс, починить
Фича — новая функциональность или возможность системы
Эскалировать — поднять вопрос на более высокий уровень для решения проблемы

Если упустили какие-то слова, то пишите в комментариях — вместе дополним наш словарь 🙂

⭐️ ФТ vs НФТ: повторить перед собеседованием на СА ⭐️

👉 Функциональные требования (ФТ) — это про то, ЧТО делает система.

Для сервиса доставки еды это могут быть:

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

+ Пользователь может искать блюда с учетом фильтров по названию, цене и наличию ингредиентов, а также сортировать результаты поиска.

+ Пользователь может добавить блюдо в корзину.

+ Пользователь может добавить удалить блюдо из корзины.

+ Пользователь может оформить заказ, когда наполнил корзину.

+ Пользователь может оплатить заказ банковской картой или с использованием электронного кошелька.

ФТ — фундамент любой системы.



👉 Нефункциональные требования (НФТ) — это про то, КАК система работает.

❗️ Любое НФТ должно быть проверяемым: либо в фукнциональных/авто-тестах, либо нагрузкой. Непроверяемые формулировки — просто "вода". Это не нужно.

Есть несколько основных видов НФТ, которые вы должны помнить всегда. Рассказываем про них с примерами:

1) Производительность - скорость работы системы.
👎 Система работает быстро.
✅ Время обработки запросов к системе не должно превышать 900 мс при 150 RPS и 300 одновременных пользователей.

2) Доступность и отказоустойчивость - время работы без сбоев.
👎 Обеспечить для системы высокую доступность.
✅ Публичный API должен быть доступен 99.9% в месяц.
✅ Регламентные окна ≤2 ч/мес.
✅ Допустимое время восстановления сервиса после сбоя (RTO) ≤ 15 мин.
✅ Допустимая потеря данных во времени при восстановлении (RPO) ≤ 1 мин для заказов и платежей.

3) Масштабируемость - способность расти в зависимости от нагрузки.
👎 Система должна легко и быстро масштабироваться при увеличении нагрузки от пользователей.
✅ В часы пик 12:00–15:00 и 18:00–21:00 по Мск входящий трафик возрастает в 3 раза относительно базовой нагрузки. Сервисы каталога товаров, заказов и платежей, должны автоматически масштабироваться, увеличивая количество активных инстансов (работающих экземпляров) в 4 раза без простоя.

4) Безопасность
👎 Обеспечить защиту данных.
✅ Система должна поддерживать аутентификацию по OAuth2/OIDC с обязательным PKCE для мобильных клиентов.

А ещё:
5) Целостность
6) Надежность
7) Удобство использования
😍 Эффективность
9) Переносимость
и другие виды НФТ.

Подробнее познакомиться с теорией и примерами по НФТ можно в подкасте:
🔗 Нефункциональные требования: пример для медицинской системы

Пример, когда не учтенные НФТ положили систему:
🔗 Миграция БД, индексы и импортозамещение ПО: как положить прод и поднять обратно

❗️ НФТ считаются одними из самых сложных для понимания аналитиков. Поэтому собрали для вас как примеры, так и реальные примеры их влияния на системы.



Обязательно повторите этот материал перед собеседованием на Junior/Middle позиции. Всегда будьте готовы объяснить разницу и привести примеры 🤝

🧐 ИЗ ЧЕГО СОСТОИТ ТЗ? 🧐

Чаще всего ТЗ содержит следующие информационные блоки:

1️⃣ Введение
Где представлена общая информация о проекте, его целях, контексте и описанием текущей проблемы или потребности.

2️⃣ Список участников проекта
То есть тех, кто принимает участие в проектировании решения. Зачастую достаточно заказчика, менеджера проекта, ответственного аналитика и разработчика.

3️⃣ Глоссарий
с указанием терминов и сокращений, которые используются в документации, — так читатели ТЗ будут в едином контексте.

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

5️⃣ Требования к документации
Где фиксируется, что будет разработан пакет руководств-инструкций, ПМИ, протокол ПСИ и так далее.

6️⃣ Архитектура и дизайн.
В этой части — общая архитектура системы, используемые технологии, платформы, инструменты, описание модулей, интерфейсов и так далее.

7️⃣ Интеграции и взаимодействия
Где указаны требования и протоколы для взаимодействия с другими системами, API, форматы данных и схемы коммуникации.

8️⃣ Порядок контроля и приёмки,
который содержит тестовые сценарии, ожидаемые результаты и критерии приёмки.

9️⃣ Стадии и этапы разработки, а также сроки их выполнения.

🔟 Возможные риски
Где описаны сложности или негативные последствия, которые могут повлиять на проект. Тут же указаны планы по их снижению или управлению.

Также ТЗ может содержать приложения с артефактами в виде диаграмм, прототипов, описания API и другой документации. В зависимости от правил оформления ТЗ в компании, а также от сложности проекта, вам понадобятся все блоки из списка или только их часть.


🧐 ПРО СТАНДАРТЫ ТЗ 🧐

Шаблон для написания ТЗ в разных компаниях отличается, но часто он базируется на каком-то из стандартов. Всего существует три группы стандартов:

❣️Международные (ISO, IEEE)
❣️Российские (ГОСТ 19, ГОСТ 34)
❣️Стандарты из областей знаний (BABOK, Вигерс, RUP и другие)

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

🎯 Чек-лист навыков Бизнес-Аналитика 2026: полная и актуальная версия 🎯

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

8 ключевых блоков:

▪️ Soft Skills
▪️ Сбор требований
▪️ Анализ требований
▪️ Фиксация требований
▪️ Прототипирование и моделирование
▪️ Работа с данными
▪️ Управление командой
▪️ Hard Skills

Ничего лишнего, что обычно любят подкидывать нейросети.
Только реальные и актуальные требования к БА.


👉 Как использовать чек-лист
1. Распечатайте / Скачайте PDF
2. Напротив каждого навыка отмечайте «умею / пробовал / нет»
3. Выбирайте 2–3 точки роста на каждый месяц 2026 (могут повторяться: например, два месяца фокусируетесь на одних и тех же навыках)
4. Сверьтесь в конце года и насладитесь прогрессом.


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


Сохраняйте и пользуйтесь 🔖


Оставайтесь с нами, чтобы забирать самые актуальные и практические знания для аналитиков 🚀

Друзья, с первым днём лета ☀️

И с началом новой рабочей недели)

И такое бывает 🙈 #GAhahaha

💎 Хореография и оркестрация микросервисов: практика [6–9 июня] 💎

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

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

На новом практическом занятии разберём, как проектировать такие процессы и показывать их на архитектурных схемах.


💎 Хореография и оркестрация микросервисов: практика проектирования процессов
📅 Доступ 6 - 9 июня (сб-вт)
🕘 Время на обучение: ~4 часа
🎯 Формат: урок в записи, можно смотреть в удобное время

🔗 Зарегистрироваться


👉 План:
1. Основы архитектуры систем: монолит и микросервисы
2. Разработка схемы архитектуры
3. Оркестрация процессов: практика
4. Введение в брокеры (RabbitMQ, Kafka)
5. Хореография процессов: практика


👉 Практикум полезен, если вы:
✔️ уже работаете с API и интеграциями, но хотите глубже понимать микросервисную архитектуру
✔️ готовитесь к интервью на Middle+/Senior системного аналитика;
✔️ часто слышите на проектах “Kafka”, “RabbitMQ”, “события”,“микросервисы”, но хотите разложить это в понятную систему
✔️ стремитесь работать с более сложными архитектурными задачами, а не только с экранами, CRUD и простыми API.


Есть планы разбираться в интеграциях микросервисов?
Регистрируйтесь и смотрите практикум в удобное время с 6 по 9 июня 👍

Что делать, если требования изменились❓

Главное правило: не паникуйте!

1️⃣ Обсудите варианты реализации изменений
В некоторых случаях изменения можно выпускать доработкой к ранее согласованному решению. А иногда всё таки придётся остановить разработку и откатить работу на этап аналитики, где требования будут переписаны.

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

2️⃣ Если есть возможность, работайте по гибкой методологии
Когда всё ПО проектируется постепенно в виде постоянных небольших доработок, изменениями проще управлять.

Во-первых, всегда есть возможность договориться о переносе новых требований в последующие итерации.

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

3️⃣ Обращайтесь к авторитетам
Если требования меняются из-за того, что заказчиков несколько и они не могут договориться между собой (что тоже бывает, итс лайф 🤷‍♀️🤷), находите стейкхолдера, который имеет большее влияние на ту часть бизнеса, в которой планируется внедрять решение.

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

4️⃣ Фиксируйте результаты изменения требований
Помимо фиксации изменений в документации, обязательно выносите факт изменения внутри решения до проектной команды.

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

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

😊 Благодаря опыту мы растём, как специалисты, и можем управлять ситуацией в случае её повторения.

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

⚡ Требования изменились ⚡

Даже если требования были хорошо собраны и согласованы, в какой-то момент они могут стать неактуальными. И это нормальная часть работы аналитика.

Причины обычно делятся на две группы:
🔹 Внутренние
Например:
• заказчик изменил решение;
• требования были поняты неоднозначно;
• разработка реализовала задачу иначе.

🔹 Внешние
Например:
• изменилось законодательство;
• поменялись бизнес-процессы;
• проект или интеграция потеряли актуальность.

Чтобы снизить риск потери актуальности требований, аналитику важно⤵️

1️⃣ Фиксировать итоги встреч письменно
После обсуждений лучше отправлять краткое резюме с договорённостями, решениями и открытыми вопросами на согласование. Это помогает избежать ситуаций, когда участники встречи по-разному запомнили договорённости.

2️⃣ Поддерживать документацию актуальной
Любые изменения важно сразу отражать в ТЗ, спецификациях и других артефактах. Команда должна работать с актуальной версией требований.

3️⃣ Не дублировать требования в разных местах
Чем больше копий требований существует, тем сложнее поддерживать их в актуальном состоянии. Лучше хранить единый источник документации и ссылаться на него из задач.

4️⃣ Обсуждать требования с командой
Недостаточно просто передать документацию. Грумминги и совместные обсуждения помогают заранее выявить вопросы, противоречия и снизить количество ошибок ещё до начала разработки.

Изменение требований — стандартная практика в проектах.
Главное — выстроить процесс так, чтобы быстро адаптироваться к изменениям и сохранять контроль над требованиями 👍
#hardGetAnalyst

📚 «12 недель в году» — книга о том, как перестать жить в режиме «успею потом» и начать действительно двигаться к целям.

Авторы предлагают систему, в которой год условно превращается в 12 недель. За счёт более короткого горизонта планирования появляется больше фокуса, задачи меньше откладываются и становится проще переходить к действиям.

Книга особенно откликнется тем, кто любит «включаться» только перед дедлайном 😅

➡️ Главная мысль книги — большинство людей не ленивы, а просто отвлекаются, растягивают сроки и откладывают важное на потом. Но когда времени остаётся мало, внезапно находится энергия и получается закрыть огромное количество задач.

Авторы объясняют, как выстроить такой рабочий ритм и сделать его частью системы.

В книге много практики: планирование, работа с приоритетами, система оценки прогресса и подходы, которые помогают меньше уходить в прокрастинацию 👌
#hwGetAnalyst

С началом новой рабочей недели 🙌

Когда компания выбирает «Дизайн REST API» для своей команды: опыт корпоративного обучения ✅

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

Так на программу «Дизайн REST API» попала Анастасия: её и коллег из разных департаментов направили на корпоративное обучение, чтобы усилить навыки работы с API.

Особенно ценно, что Анастасия уже работала с REST API до курса.
Поэтому в отзыве — не просто впечатления новичка, а взгляд специалиста, который смог сравнить обучение со своей реальной практикой и увидеть, что можно улучшить в своей работе.
#студентыGetAnalyst ➡️

Мы собираем требования и проектируем системы с внутренними подсказками:

✔️ Пользователям необходимо решить такую-то проблему, для этого система...
✔️ Я, как пользователь, хочу, чтобы....
✔️ Чтобы пользователь получил результат, ему необходимо выполнить следующие шаги...

Идем по прямым сценариям 📈

А работаете ли вы с обратной стороной проектирования? Помните про реальный мир? Как не должна себя вести в случае, если на нее нападут миллионы разъяренных пользователей в погоне за маркетинговой акцией? Или если сервера откажут? Много внимания уделяете этим вопросам?

И любимый вопрос: "Что тут может пойти не так?" 🙃

Техники сбора требований ✍️

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

Требования помогают:
• определить границы проекта;
• понять цели и ожидания стейкхолдеров;
• зафиксировать, что именно нужно реализовать;
• договориться с заказчиком и командой.

Собрали основные техники, которые помогают аналитику собирать требования ⤵️

1️⃣ Интервью
Одна из самых популярных техник. Аналитик заранее готовит вопросы и общается с заказчиком, пользователями или другими участниками процесса. Интервью может быть как индивидуальным, так и групповым.

Например, если нужно доработать личный кабинет сотрудника тех поддержки, аналитик уточняет:
— какие действия он выполняет чаще всего;
— где возникают сложности;
— какие данные важно видеть в первую очередь.

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

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

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

Например:
«Какие действия в системе занимают у вас больше всего времени?»
«Оцените удобство интерфейса от 1 до 5»

3️⃣ Наблюдение
Аналитик наблюдает, как пользователь работает в реальной среде:
• какие шаги выполняет;
• где задерживается;
• что делает вручную;
• какие дополнительные таблицы или инструменты использует.

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

Например, сотрудник говорит, что «просто оформляет заявку», а на практике копирует данные из трёх систем, сверяет их в Excel и только потом вносит в программу.


4️⃣ Анализ документации
Аналитик изучает существующие материалы:
регламенты компании, инструкции, ТЗ, описания процессов, API-документацию внедренных систем, схемы.
Так он быстрее погружается в предметную область, может понять ограничения и увидеть, как процесс устроен сейчас.

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

5️⃣ Mind Map - как инструмент для сбора требований
Карта мыслей (Mind Map) помогает разложить информацию по блокам и увидеть связи между частями системы или процесса. Её удобно использовать на старте проекта, когда информации много и она ещё не структурирована.

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

6️⃣ Мозговой штурм
Подходит для генерации идей и поиска вариантов решений.
В обсуждении могут участвовать аналитики, заказчики, разработчики, дизайнеры и пользователи.
На первом этапе важно собрать как можно больше идей, а уже потом оценивать их по пользе и реализуемости.

Например, если команда ищет способ снизить количество ошибок при оформлении заявки, на штурме могут предложить:
• автозаполнение полей;
• подсказки в интерфейсе;
• проверки данных;
• изменение процесса согласования.

7️⃣ Анализ конкурентов
Помогает понять, как похожие задачи решены в других продуктах.
Аналитик изучает:
• функциональность;
• пользовательские сценарии;
• интерфейсные решения;
• ограничения и особенности продукта.

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


В реальной работе аналитик редко использует только одну технику. Чаще всего хороший результат даёт именно комбинация подходов. Сначала изучаются документы, затем проводятся интервью, после этого строится mind map, а детали уточняются через наблюдение или анкетирование.

Чем больше техник аналитик умеет применять на практике, тем точнее он выявляет реальные потребности бизнеса и пользователей ✅

🩵💖❤️‍🔥 С днём рождения, GetAnalyst — 5 лет 5️⃣🎉

Кажется, это уже тот возраст, когда можно перестать говорить:
«ну я тут маленький проект делаю» 😅

5 лет назад GetAnalyst начинался с эфиров на несколько человек, страха говорить в пустоту и ощущения:

Я вообще не понимаю, зачем кому-то это может быть нужно. Всё же очевидно...

А потом оказалось — нужно.

Нужно объяснять архитектуру без академического тумана и абстрактных примеров.
Нужно разбирать API не на уровне «ну там JSON».
Нужно показывать, как писать требования, проектировать интеграции и думать системно.
Нужно демонстрировать, как эффективнее всего использовать ИИ.


❤️‍🔥 За эти 5 лет GetAnalyst стал не просто очередным проектом с курсами.

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

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


🎯 Миссия GetAnalyst с первого дня:

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

И самое кайфовое, что она работает.


Спасибо, что читаете, спорите, приходите на эфиры, приносите свои вопросы, задачи, проекты и карьерные победы.

Я всё ещё очень радуюсь каждому сообщению в стиле:
«Катя, я наконец-то поняла»
или
«у меня оффер +100к!»

Ради этого, кажется, всё и было.



Спасибо, любимая команда, что вы со мной 🩷
Также сегодня, 19 мая, я хочу поздравить с днём рождения мою дорогую и незаменимую Зарину, которая со мной с первого года жизни проекта, с которой контактировал каждый наш студент.
Мы прошли вместе не мало сложных и счастливых моментов. Люблю тебя до безумия!


С маленьким юбилеем нас 💙
GetAnalyst, с днём рождения! 🎂


О проекте
История Екатерины Ананьевой
Отзывы


Сообщество GetAnalyst основано 18 мая 2021 года