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

😰 Уволить или обучать? 😰 Жёсткий, но очень честный вопрос для любого руководителя. Отвечаю. Проблема не всегда в том, что человек «чего-то не знает». Есть вещи, которые обучением почти не лечатся. ✅ Ошибся, признал и пришёл с вариантом исправления. Или обсудить, как такое не допустить в будущем? Обучать. Потому что ошибка — это не катастрофа. Катастрофа — это когда человек защищает ошибку до последнего, перекладывает ответственность на разработчиков, тестировщиков, заказчика, ретроградный Меркурий и «непонятный контекст». ✅ Медленный, но внимательный и с горящими глазами? Обучать. Скорость приходит с практикой. Особенно, если человек умеет задавать вопросы, принимает обратную связь и не боится сложных задач. ✅ Мало знает, но хочет расти? Обучать. Навыки наращиваются: API, интеграции, БД, микросервисы. Главное, чтобы человек не делал вид, что уже всё знает. 🚩 Ноет, что всё плохо? Уволить. Если человек видит риски и аргументирует — это ценно. Если человек просто разрушает энергию команды и заражает всех ощущением «ничего не получится» — это проблема. 👉 Системный аналитик должен видеть проблемы. Но зрелый аналитик приносит не только проблему, а ещё и варианты решения. 🚩 Сдал задачу в разработку = снял ответственность. Уволить. Потому что аналитик — это не человек, который «написал документ и ушёл». Он связывает бизнес, разработку, тестирование, поддержку. Если он не помогает команде переводить с бизнесового на разработческий — он не выполняет ключевую часть своей роли. 🚩 Даёт результаты, но токсичен в общении? Уволить. Можно быть сильным специалистом, но если после каждого созвона команда выгорает, разработчики боятся задавать вопросы, а тестировщики получают ответы в стиле «ну это же очевидно» — это разрушает рабочую среду. Высокий уровень экспертизы не даёт права быть токсичным. 🚩 Оспаривает каждое решение? Уволить. Если аналитик спорит аргументированно, защищает качество системы и помогает найти слабые места — это плюс. Если спорит ради спора, чтобы показать свою ценность, саботирует договорённости и не может принять командное решение — это уже не критическое мышление, а управленческая проблема. 🚩 Умный, но не разделяет миссию продукта или компании. Уволить. Потому что аналитик влияет на решения. Он участвует в формировании требований, архитектурных обсуждениях, приоритизации, коммуникации с бизнесом. Если человек внутренне не верит в то, что команда строит, он будет постоянно тормозить движение. Иногда не специально. Просто потому что у него другая картина мира. Я более 7 лет руковожу проектами на 1млн+ пользователей. Я более 3 лет веду свой бизнес с командой на 20+ человек. Я не хочу быть вовлеченной в задачи своих сотрудников, сидеть как «курица наседка» и следить за каждым. 👉 Уволить или заменить? Мой вывод такой:

Обучать стоит тех, у кого не хватает навыков, но есть ответственность, честность, интерес и желание расти.

А расставаться стоит с теми, кто разрушает команду: токсичностью, вечным негативом, отсутствием ответственности или саботажем общего направления. Потому что сильная команда строится не только на hard skills. Иногда один человек с хорошими навыками, но плохим отношением к людям наносит системе больше ущерба, чем джун, который пока путает POST и GET, но хочет разобраться 🙌

🔴 21 задача аналитика, которую можно ускорить с ИИ 🤖🚀 Искусственный интеллект (ИИ) уже меняет работу системного и бизнес-аналитика. ИИ сегодня — это полноценный рабочий инструмент, который можно указывать в резюме. Задачи, решение которых можно ускорить с ИИ: ▫️ анализ требований, ▫️ исследование предметной области, ▫️ написание БТ, ФТ и НФТ, ▫️ разработка User Stores + критериев приемки, ▫️ разработка обычных и интеграционных Use Case, ▫️ BPMN-диаграммы, ▫️ UML-диаграммы, ▫️ проектирование БД (ERD), ▫️ SQL-запросы, ▫️ анализ API внешних систем для интеграций, ▫️ проектировать REST API, SOAP API, gRPC, GraphQL, WebSocket API, SSE API, ▫️ разработка контрактов REST API в OpenAPI (Swagger), ▫️ постановки задач на Backend, Frontend и Mobile по корпоративным шаблонам, ▫️ проработка архитектуры, ▫️ схемы архитектуры в нотации C4, ▫️ прототипирование UI, ▫️ задачи на настройку RabbitMQ и Kafka, ▫️ переписка с коллегами и заказчиками, ▫️ работа в международных командах (английский) И всё это — не в одном чате, а через связки инструментов, переиспользуемые промпты и грамотный промптинг под разные типы задач. Но дальше — ещё интереснее. Следующий уровень для СА и БА — это уже разработка агентных AI-систем, самостоятельное создание приложений под свои рабочие задачи и их деплой без необходимости разработчиков и DevOps 😍 То есть аналитик может не просто пользоваться AI для отдельных артефактов, но и: ✔️ собирать полноценные AI-решения, ✔️ автоматизировать процессы команды, ✔️ автоматизировать рутину, ✔️ и делать рабочие MVP своими руками.

💳 9 типовых Use Case для Интеграции с платежной системой 💳 Разбираемся, какие Use Case охватывает интеграция с платёжной системой (PSP), и какие методы понадобятся для её реализации на примере API ВТБ 👇 1️⃣ Создание транзакции Отправляем сумму и детали заказа. Получаем ссылку на платёжную форму, id и другие параметры платежа. Перенаправляем пользователя по ссылке. Пользователь вводит данные карты на форме оплаты. Оплата завершается. --- Метод: Регистрация заказа 2️⃣ Подтверждение оплаты (Webhook) Платёжная система сама сообщает статус оплаты. Надо делать метод на стороне нашей системы, чтобы его вызвала платежная система. --- Метод: Уведомления обратного вызова 3️⃣ Проверка статуса платежа (Polling) Если webhook не сработал (т.е. у нас в БД статус платежа всё ещё "ожидание оплаты"), то прежде чем показать пользователю итоговый статус платежа, надо перепроверить его на стороне платежной системы. --- Метод: Статус заказа 4️⃣ Отмена платежа Пока деньги не списаны, пользователь в любой момент может прервать оплату --- Метод: Отмена заказа 5️⃣ Возврат средств Полный или частичный, если надо удержать комиссию. Нужен, если пользователь отказывается от оказания услуги --- Метод: Возврат средств 6️⃣ Сохранение платёжных данных Для One-Click и подписок. Чтобы пользователю не надо было вводить карту при последующих покупках. Важно! На стороне нашей системы хранится только id платежного средства, а все данные карты (номер, CVV, дата окончания) будут храниться безопасно, на стороне платежной системы. --- Метод: обычно внутри первой оплаты 7️⃣ Повторное списание Автоплатежи без участия пользователя --- Метод: Рекуррентный платеж 8️⃣ Формирование отчётов Всё для бухгалтерии и бизнеса. Обычно на основании внутренних данных, которые сохранялись в нашей системе по итогам платежей. 9️⃣ Работа с чеками Иногда делают такие доп. сценарии. Зависит от потребностей бизнеса Сохраняйте, если работаете над задачами с оплатой или только собираетесь вникать в платёжные сценарии 👌 #hardGetAnalyst

Опыт есть опыт! 😀 Всех с началом новой рабочей недели)

Как жить, если случилось выгорание ☹️ Друзья, существует миф, что выгорают только те люди, которые занимаются нелюбимым делом. На самом деле чаще выгорают те, кто как раз занимается тем, что ему нравится, от чего горят глаза! Почему так происходит? Вы увлечены! 👉 Когда мы занимаемся любимым делом, то часто возникает желание достичь максимальных результатов. В этом состоянии забываем про отдых, обед, начинаем перерабатывать. 👉 Работа становится хобби, границы между профессиональной и личной жизнью размываются. Сложно отключиться от работы даже в свободное время. Кто-то начинает избегать общения с коллегами, друзьями и семьёй. Это увеличивает уровень стресса. 👉 Увлечённые люди часто сильно эмоционально привязаны к делу. Они становятся более уязвимыми к разочарованиям и неудачам, что в итоге приводит к выгоранию. Если заметили у себя несколько из этих признаков, важно предпринять действия. О них читайте в картинках к посту. #softGetAnalyst

💥 Как работает mTLS: практика в Postman, которая заменит 10 статей по теории 💡🔐 Что такое mTLS и как это работает? Изучайте не в теории, а на практике! 👉 mTLS часто пугает не сложностью, а ощущением, что ты попал в чужую зону ответственности. Сертификаты, цепочки, OpenSSL, clientID, clientSecret, access token — и непонятно, за что хвататься первым. Но на деле всё становится яснее, когда смотришь, как это делается руками. 🔗 Статья с доп. материалами К концу выпуска понятно не только как это настроить mTLS, но и почему он так работает. Отдельно разобрали, как системному аналитику описать требования к mTLS-аутентификации и что могут спросить про TLS/mTLS на собеседовании. Выпуск будет полезен тем, кто проектирует интеграции с защищёнными API, пишет требования к API-аутентификации, готовится к собеседованию на Middle/Senior системного аналитика, а также всем, кто хочет разобраться с mTLS один раз — и больше не бояться сертификатов. Видео с демо решения: ⏯ YouTube ⏯ RuTube ⏯ VK Video ⏯ Telegram Аудио: ⏯ Apple Podcast ⏯ Яндекс.Музыка ⏯ Castbox ⏯ Звук ⏯ Spotify 💚 GetAnalyst — сообщество для тех, кто хочет глубже разбираться в системном анализе, архитектуре и реальных задачах проектов 📱 Tg | 💙 ВК | 💬 Max

Не ждите идеальной идеи. Начните с той, которая есть сегодня, и дайте ей возможность вырасти во что-то большее✨   С началом новой недели👌

Ребята, делитесь, а какие у вас планы на лето?😄

📖 Подборка книг по Архитектуре и Микросервисам 📖 Когда я только начала знакомиться с архитектурой, то одной из первых и любимых книг сразу стала: 📚 Domain Driven Design. Предметно-ориентированное проектирование, Эрик Эванс Благодаря ей я, как системный аналитик, еще раз пересмотрела подходы к проектированию и описанию требований, структурировала знания, и начала осознанно использовать рекомендации из нее. Особенно она помогла в подходах к определению сервисов и микросервисов системы, границ их функциональности. В дополнение к ней: 📚 Release it! Проектирование и зайн ПО для тех, кому не все равно, Майкл Нейгард (тоже мой фаворит!) 📚 Создание микросервисов, Сэм Ньюмен 📚 Микросервисы. Паттерны разработки и рефакторинга, Крис Ричардсон 📚 Высконагруженные приложения, Мартин Клеппман 📚 Чистая архитектура. Искусство разработки программного обеспечения, Роберт Мартин 📚 Эволюционная Архитектура, Нил Форд, Ребекка Парсонс, Патрик Куа 📚 DDD - предметно ориентированное проектирование, Влад Хононов Ставьте реакцию, если сохранили подборку! 😊❤️‍🔥 #hwGetAnalyst

Встречаем новую рабочую неделю👌😁 Желаем успешно разобраться со всеми задачами)

🧡 [6–9 июня] Хореография и оркестрация микросервисов: открытый практикум для аналитиков 🧡 В простых задачах всё понятно: Frontend → Backend → БД. Но в распределённой архитектуре один процесс может затрагивать сразу несколько сервисов, брокер сообщений и внешние системы. И аналитику нужно решить: ▫️ кто запускает процесс ▫️ какой сервис отвечает за каждый шаг ▫️ где использовать прямой API-вызов ▫️ где передавать события через Kafka или RabbitMQ ▫️ когда нужна оркестрация, а когда — хореография ▫️ как всё это показать на архитектурной схеме 👉 Этому и посвящён новый практикум по хореографии и оркестрации микросервисов. На занятии вы разберёте: ✔️ как устроены процессы в микросервисной архитектуре; ✔️ как проектировать оркестрацию и хореографию; ✔️ какую роль играют RabbitMQ и Kafka; ✔️ как отображать взаимодействия сервисов на схемах. Подойдёт системным аналитикам, которые уже работают с интеграциями и проектированием систем и хотят глубже разобраться в микросервисной архитектуре, событийном взаимодействии и построении сложных процессов. 🧡 Хореография и оркестрация микросервисов: практика проектирования процессов 📅 Доступ 6 - 9 июня 🕘 Время на обучение: ~4 часа 🎯 Формат: урок в записи, можно пройти в удобное время 🔗 Зарегистрироваться Это полноформатный вводный урок к практической программе «Проектирование архитектуры» для системных аналитиков, которая стартует 9 июня. Если к активному осеннему найму хотите увереннее работать с архитектурой, проектировать сложные процессы и претендовать на более сильные позиции — присоединяйтесь 🙌 Вопросы? Пишите @getanalyst или на info@getanalyst.ru.

Как разобраться в микросервисной архитектуре: реальный опыт студентки GetAnalyst 👩‍🎓 Ирина пришла на программу «Проектирование архитектуры» с конкретным запросом: разобраться в микросервисах и интеграциях. За плечами — 8 лет в IT и глубокая экспертиза в 1С. Впереди — поиск новой работы, Kafka и архитектура, которую нужно было освоить быстро. Вот что из этого вышло #студентыGetAnalyst

У вас бывало ощущение неловкости, когда приходишь в новый коллектив или в новую тусовку, а там используют совершенно неизвестные вам слова? Мозг усердно пытается догадаться о чём речь, но без гугла сложно. Если вы ещё новичок в системном анализе и только погружаетесь в слэнг, команда 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 и другие) Все они специализируются на разных предметных областях, поэтому брать можно как готовый стандарт, так и его адаптированную версию.