System Nomad | by Aslaleyev

🏎 Запускаем F1 (Freedom One) — AI-резидентуру для сильных студентов Салем! Вы знаете, что я всегда топлю за школьников и студентов: образование, стажировки, джун-позиции. И вижу проблему — рынок сейчас нанимает сеньоров, а сильных новичков просто некуда девать. Хотя если уметь с ними работать, они делают очень много. Талантливой молодёжи у нас полно — не хватает правильного пути и сопровождения. Особенно сейчас, когда с ИИ и вайб-кодингом карьеру можно построить в разы быстрее, чем 5 лет назад. Поэтому вместе с Freedom AI Lab и моим другом Куанышем (тех. руководитель Freedom Speech) мы запускаем F1. Название — двойная отсылка: Формула 1 (быстрые и талантливые, отбор лучших) и наша любимая метрика F1-score 🙂 Что это такое Резидентура на 3 месяца. После отбора вы работаете над реальной задачей — из AI Lab или из экосистемы Freedom. Это может быть AI-ресёрч под индустриальную задачу или новый ИИ-продукт. В конце — защита. По итогам защиты сильные получают оффер в команду. 💰 И да — резидентура оплачиваемая, все участники получают стипендию. Чему мы НЕ учим Мы не учим писать код. Сильный студент с современными инструментами уже пишет его быстрее, чем большинство джунов пять лет назад. Дефицит в другом: выбрать правильную задачу, разобраться в грязных данных, понять, что метрика врёт, довести модель до прода, доказать, что она работает на живых пользователях. Этому не учат лекциями — только на реальном продукте, с инженером рядом. Поэтому в F1 нет лекций. Есть задача Freedom, ментор из прод-команды и три месяца. Сам буду помогать с продуктовым мышлением и подходами. В первом потоке всего 10 студентов. Дальше — больше. Как попасть 1️⃣ Подать заявку на сайте → https://freedom-one.kz 2️⃣ С 17 августа вам на почту придёт информация о первом туре и доступ в Kaggle-соревнование 3️⃣ Первый тур идёт до 30 августа — решение нужно отправить до этой даты 4️⃣ Кто покажет хорошие результаты — идёт на второй этап, интервью Совет: зарегистрируйтесь на Kaggle заранее и посмотрите, что и как там устроено — потеряете меньше времени на старте. Буду благодарен, если распространите по вузам и студенческим чатам 🙏 Всем удачи! Ақ жол!

Всем привет! Кажется, пора честно проговорить одну вещь: быстрый вкат в системный анализ закончился. Не профессия закончилась. Не аналитики больше не нужны. Не "все ушло в ИИ". Закончилась история, где человек проходил курс, учил слова REST, SOAP, BPMN, Kafka, пару раз рисовал sequence diagram и через месяц шел выбирать между офферами. Сейчас рынок другой ! 😲 Компании стали осторожнее. Денег на "давайте вырастим человека с нуля" меньше. Вакансий меньше. Откликов больше. Размытые роли режут первыми. А если роль не показывает понятный вклад в деньги, сроки, риски или качество - к ней начинают присматриваться особенно внимательно. Это неприятно, но не смертельно. Просто теперь системному аналитику надо продавать не "я хочу развиваться", а "я умею снижать неопределенность". Вот как это выглядит на практике. 👎Плохо: "Я изучал BPMN, UML, SQL, REST API, Agile, Scrum, Jira, Confluence". 👍Нормально: "Я умею разбирать интеграционный процесс: фиксирую участников, события, контракты, ошибки, ретраи, статусы, ограничения и критерии приемки. Могу принести пример спецификации". 👎Плохо: "Хочу работать в сильной команде и расти". 👍Нормально: "На прошлом проекте я описал процесс возврата платежа: нашел 6 спорных бизнес-правил, вынес их на согласование, добавил таблицу статусов и негативные сценарии. После этого разработка перестала дергать бизнес по каждому кейсу". Сейчас выигрывает не тот, кто знает больше терминов, а тот, кто может показать кусок реальной работы. Что делать, если опыта мало❓❓❓ Собрать портфолио из 3-4 нормальных кейсов. Не "я нарисовал красивую диаграмму", а именно аналитические артефакты: 1. Интеграция через REST 💕 описание процесса; 💕 endpoint; 💕 request/response; 💕 ошибки; 💕 идемпотентность; 💕 retry logic; 💕 sequence diagram; 💕 критерии приемки. 2. Процесс в BPMN 💕 стартовое событие; 💕 роли; 💕 gateways; 💕 альтернативные ветки; 💕 исключения; 💕 что автоматизировано, а что вручную. 3. Модель данных 💕 сущности; 💕 связи; 💕 обязательность полей; 💕 статусы; 💕 audit fields; 💕 soft delete или archive, если объект нельзя просто удалить. 4. Небольшой SQL-разбор 💕 выборка; 💕 join; 💕 группировка; 💕 оконная функция; 💕 объяснение, почему запрос написан именно так. И да, искать работу теперь тоже надо как процесс, а не как настроение. Я бы вел простую таблицу: 🔂 дата отклика; 🔂 компания; 🔂 вакансия; 🔂 требования; 🔂 версия резюме; 🔂 был ли ответ; 🔂 причина отказа, если есть; 🔂 что поправить. Если на 50 откликов нет ни одного разговора - проблема не в ретроградном Меркурии. Скорее всего, резюме не попадает в ожидания рынка. Если интервью есть, но дальше не зовут - проблема может быть в рассказе об опыте, глубине технических ответов или неумении объяснять свои решения. Если доходите до финала и проигрываете - возможно, вы нормальный кандидат, но рынок перегрет и надо продолжать. Главное - не ждать идеального сезона. Осенью вместе с вами проснутся все, кто решил "начну потом". И вы попадете в ту же воронку, только с большим количеством людей. Системный анализ жив. Просто он снова стал профессией, а не билетом в теплое кресло по промокоду. ENJOY!⭐

Всех с понедельником)

2️⃣1️⃣ Всем привет! 👋 Разбор собеса Вакансия: Системный аналитик Уровень: Senior Сфера: Аутстаффинг (проект в производственном секторе) 📝 Секция «Общие вопросы»: 🔵Что не устраивает на текущем месте. (Классика) 🔵Доводилось ли тебе проектировать с 0 функционал сервиса/модуля. (Бывает) 🔵Почему ищешь работу. (Классика) 👣 Секция «API/HTTP/Интеграции»: 🔵Какие события бывают при интеграции по WS соединению. (Первый раз) 🔵Был ли опыт работы с WebSocket (WS). (Часто) 🔴Кейс: Есть ресурс. У него есть идентификатор и описывающие его параметры: {"age":20,"name":"Pavel"}. Я делаю PATCH запрос, передавая идентификатор ресурса и параметр age со значением 30. Что произойдет с ресурсом? А что будет, если я отправлю такой же запрос, но используя метод PUT? 🖥 Секция «Базы данных»: 🔵С какими БД довелось поработать. (Классика) 🔵Для чего нужна денормализация данных. (Бывает) 🔵Доводилось ли сталкиваться с триггерами. (Редко) 🔵Какие 2 типа представления есть в PostgreSQL. (Первый раз) 🔵Используя какие инструменты подключался к БД. (Редко) 🔵Для чего нужна нормализация данных. (Классика) 🔵Для чего нужен materialized view. (Редко) 🖥 Секция «Брокеры»: 🔵Доводилось ли работать с Kafka. (Классика) 🔵Pull vs Push модель интеграции. (Бывает) 🔵Что такое: Offset, producer, partition, topic, consumer group. (Бывает) ⚙️ Секция «Архитектура»: 🔵Как понять потребует ли реализация нового функционала отдельного микросервиса или можно просто доработать текущий. (Кажется, первый раз) 🔨 Итог: Были нетипичные вопросы, хотя по факту речь про базовую теорию, ничего шибко сложного тут нет. Очевидно, кому-то такой вопрос не зайдет, но лично мне понравилось, так как у собеса есть своя изюминка. ENJOY!⭐

Всем привет! Сегодня хочу разобрать боль, через которую, кажется, проходил каждый аналитик (пока был junior спецом). Вы написали задачу ➡️ Отдали в разработку ➡️ Разработчик вернул с вопросами ➡️Вы дописали ➡️ Он снова вернул. И где-то внутри уже начинает закипать мысль: "Да что тебе еще надо? 😡😡😡" Но если речь про интеграционную задачу, очень часто разработчик не придирается. Он просто не может писать код по постановке, где половину решений надо додумать самому. Допустим, у нас есть задача: "Передавать заявку клиента во внешнюю скоринговую систему". ❌Плохое описание: Система должна отправить данные заявки во внешнюю систему и обработать ответ. На первый взгляд нормально. А теперь представим разработчика. Он открывает задачу и у него сразу вопросы: ❓какие данные отправлять? ❓какое поле куда маппить? ❓что делать, если поле пустое? ❓какой timeout? ❓что делать при 500? ❓что делать при 401? ❓повторять запрос или нет? ❓что если скоринг ответил "на проверке"? ❓кто увидит ошибку? И все. Задача поехала обратно. 🤝Что обязательно должно быть в такой постановке? 1️⃣ Маппинг данных Не так: ❌ "Передать данные клиента". А так: | Наше поле | Поле внешней системы | Тип | Обяз. | Правило | | application.id | request_id | string | да | UUID заявки | | client.iin | person.tax_id | string | да | 12 символов | | client.phone | contacts.phone | string | да | формат E.164 | | income.amount | income.monthly_amount | decimal | нет | если нет данных, не передавать | И сразу появляется вопрос: Если income.amount пустой, мы передаем null или вообще не отправляем поле? Это маленькая деталь, но именно из таких деталей потом рождаются баги. 2️⃣ Контракт запроса и ответа Пример запроса: { "request_id": "9f3b7c1e-1000-4c7a-9f11-85b8c0000001", "person": { "tax_id": "900101300000", "full_name": "Иванов Иван" }, "contacts": { "phone": "+77010000000" } } Пример ответа: { "request_id": "9f3b7c1e-1000-4c7a-9f11-85b8c0000001", "status": "APPROVED", "score": 742, "decision_id": "dec-7788" } 3️⃣ И отдельно надо описать статусы. 🔴APPROVED - заявка одобрена. 🔴DECLINED - отказ. 🔴MANUAL_REVIEW - нужна ручная проверка. 🔴PENDING - решение еще не готово. Без этого разработчик может решить, что все кроме APPROVED ошибка. А бизнес потом скажет: нет, MANUAL_REVIEW должен уходить оператору. 4️⃣ Ошибки и повторные попытки Фраза "обработать ошибки" - это не требование. Нормально: | Ситуация | Действие | | HTTP 400 | не повторять, сохранить текст ошибки, перевести заявку в SCORING_REJECTED_BY_VALIDATION | | HTTP 401 | обновить токен и повторить 1 раз | | HTTP 429 | повторить через 30 секунд, максимум 3 попытки | | HTTP 500 | retry с backoff: 1 мин, 5 мин, 15 мин | | timeout 5 сек | считать временной ошибкой, повторить | И еще вопрос: Что видит пользователь? Потому что "мы ретраим в фоне" - это хорошо. Но пользователь не должен сидеть перед вечным спиннером. Например: "Заявка принята. Решение появится в течение нескольких минут." 5️⃣ Частичный успех Это прям любимая тема интеграций. 😉 Отправили пакет из 1000 заявок - 997 обработались - 3 упали. Это успех или провал? Если не описать заранее, потом каждый будет прав по-своему. Я бы писал так: ⏺Успешным считается пакет, в котором обработано не менее 95% записей. ⏺Ошибочные записи сохраняются в реестр ошибок. ⏺Для каждой ошибочной записи фиксируется errorCode, errorMessage, attemptCount. ⏺Оператор может запустить повторную отправку только по ошибочным записям. Вот это уже поведение системы. 6️⃣ Логи и аудит Минимум: ✔️ id заявки ✔️ id внешнего запроса ✔️ время отправки ✔️ время ответа ✔️ статус ответа ✔️ код ошибки ✔️ номер попытки Только не надо логировать персональные данные и секреты. Потом безопасники придут, и будет уже не до красивой аналитики.🚨 ИТОГО: Если интеграционная задача возвращается из разработки, это не всегда конфликт. Иногда это сигнал: в требованиях не хватает решений, которые нельзя оставлять на усмотрение разработчика. ENJOY! ⭐️

Всем привет! 👋 Я уже писал, что Kafka лучше всего начинает пониматься не после очередной статьи, а когда вы локально подняли ее через Docker, открыли Offset Explorer и сами посмотрели на топики, сообщения, ключи и офсеты. Сегодня хочу продолжить эту тему, но уже со стороны требований. Потому что в постановках часто вижу такое: "После создания заказа отправить событие в Kafka". И вроде звучит технически солидно. Kafka есть, событие есть, можно расходиться. Но для разработки и эксплуатации этого мало. 🎉 Давайте на примере: Есть интернет-магазин ➡️ Пользователь оплатил заказ. Нам нужно отправить событие, чтобы: 📌 склад начал сборку 📌 сервис уведомлений отправил push 📌 аналитика посчитала продажу 📌 антифрод сохранил факт оплаты 👎Плохая постановка: Отправить событие order_paid в Kafka. 👍Хорошая постановка начинается с вопросов: 1. Что это за событие? 2. Когда оно считается произошедшим? 3. Кто владелец события? 4. Какой ключ партиционирования? 5. Сколько хранить событие? 6. Можно ли переобработать событие? 7. Что делать, если потребитель временно недоступен? Как можно описать событие: 💕Topic: orders.payment.events 💕Event: OrderPaymentSucceeded 💕Момент публикации: После успешного подтверждения оплаты в платежном шлюзе и фиксации статуса заказа в нашей БД. 💕Ключ сообщения:orderId ⏺Почему не userId? Потому что нам важно сохранить порядок событий в рамках одного заказа: created ➡️ payment_started ➡️ payment_succeeded ➡️ sent_to_fulfillment Если ключ будет случайный, события одного заказа могут разлететься по разным партициям, и порядок уже не гарантируется. Пример payload: { "eventId": "evt-20260630-000001", "eventType": "OrderPaymentSucceeded", "occurredAt": "2026-06-30T14:25:00+05:00", "orderId": "ord-100500", "userId": "usr-7788", "payment": { "paymentId": "pay-9911", "amount": 15990, "currency": "KZT", "method": "CARD" }, "source": "order-service", "schemaVersion": 1 } Что здесь важно? 1️⃣eventId нужен для идемпотентности. Если потребитель получил событие второй раз, он должен понять: "Ага, я это уже обрабатывал". 2️⃣occurredAt - время бизнес-события. Не всегда равно времени публикации в Kafka. Это важно для аналитики, аудита и разборов. 3️⃣schemaVersion - чтобы потом не страдать, когда мы добавим новые поля. Что еще я бы добавил в ТЗ: 💕Метрики: ✅ consumer lag по каждой consumer group ✅ количество сообщений в минуту ✅ количество ошибок обработки ✅ количество повторных обработок ✅ возраст самого старого необработанного сообщения 💕Правила ошибок: ✅ если payload невалидный - отправить в DLQ ✅ если временная ошибка внешнего сервиса - retry с backoff ✅ если ошибка бизнес-валидации - сохранить причину и не ретраить бесконечно Пример DLQ-события: { "originalTopic": "orders.payment.events", "eventId": "evt-20260630-000001", "errorCode": "INVALID_AMOUNT", "errorMessage": "Payment amount must be greater than zero", "failedAt": "2026-06-30T14:26:10+05:00" } ИТОГО: Kafka в требованиях - это не строчка "отправить событие". Это договоренность: 🔴какое событие произошло, 🔴кто его публикует, 🔴как потребители его читают, 🔴как долго оно живет, 🔴можно ли его переиграть, 🔴как мы видим проблемы, 🔴и что делаем, если что-то пошло не так. Если это описать заранее, разработке будет проще, QA будет понятно что проверять, а эксплуатации будет понятно на что ставить алерты. Аналитик не обязан быть Kafka-админом. Но он обязан понимать жизнь события от бизнес-факта до последнего потребителя. ENJOY! ⭐️

Всем привет! 👋 Есть маленькая SQL-подстава 🤬, на которую очень легко наступить, особенно когда работаешь с фильтрами, логинами, внешними ID и всякими reference number. Речь про LIKE и символ нижнего подчеркивания: _ Кажется, что если мы пишем: SELECT * FROM users WHERE login LIKE 'user_1'; то база должна найти именно user_1. Но нет 👿 В SQL символ _ внутри LIKE — это не просто нижнее подчеркивание. Это спецсимвол, который означает: «любой один символ» То есть запрос выше может вернуть: 🛑user_1 🛑user-1 🛑userA1 🛑user91 И вот тут начинается самое интересное. Представьте, что у вас в системе есть внешние идентификаторы платежей: 🛑PAY_1001 🛑PAY_1002 🛑PAY-1001 🛑PAYA1001 И аналитик/разработчик делает фильтр: WHERE external_id LIKE 'PAY_1001' Он думает: «ищу конкретный ID». А база думает: «ага, на месте _ может быть любой один символ». В итоге в отчет, сверку или расследование инцидента могут попасть лишние операции. Для системного аналитика это важный момент, потому что такая мелочь легко превращается в странный баг: — в UI показываются не те записи — поиск по ID работает “примерно” — отчет не сходится — саппорт видит чужие операции — разработчик говорит: “ну SQL же отработал нормально” Как правильно? Если нужно искать именно символ _, его надо экранировать. Например так: SELECT * FROM users WHERE login LIKE 'user!_1' ESCAPE '!'; Что здесь происходит: 1️⃣ user!_1 — мы говорим базе: нижнее подчеркивание здесь обычный символ 2️⃣ ESCAPE '!' — назначаем ! как символ экранирования То есть ! перед _ отключает магию wildcard. Еще пример ближе к реальности: SELECT * FROM payments WHERE external_id LIKE 'PAY!_%' ESCAPE '!'; Так мы ищем все ID, которые реально начинаются с PAY_, а не PAYA, PAY- или PAY9. Итог: Если в требованиях есть поиск через LIKE, обязательно уточняйте: мы ищем “по шаблону” или “точное значение, где могут быть спецсимволы”? Потому что %, _ и прочие символы в SQL — это не просто текст. Иногда это маленькая дверца в очень неприятный баг. ENJOY! ⭐️

Всем привет! Возвращаюсь в строй написания постов) 😉 Если вы долго работали с REST, то мозг привыкает к простой связке: 🔴200 — все хорошо. 🔴400 — клиент накосячил. 🔴401 — не авторизован. 🔴404 — не нашли. 🔴500 — серверу плохо. И потом вы приходите в GraphQL, отправляете запрос, получаете HTTP 200 OK и думаете: "Ну, значит успешно". А вот тут начинается веселье. В GraphQL HTTP 200 может прийти даже тогда, когда внутри ответа есть ошибки. 😱 Например, запрос: query { client(id: "123") { id fullName accounts { id balance } } } Ответ: { "data": { "client": { "id": "123", "fullName": "Ivan Petrov", "accounts": null } }, "errors": [ { "message": "Accounts service unavailable", "path": ["client", "accounts"], "extensions": { "code": "ACCOUNTS_SERVICE_UNAVAILABLE" } } ] } HTTP status при этом может быть 200. Почему? ⁉️ Потому что GraphQL-запрос как запрос обработался. Сервер понял query, выполнил часть резолверов, часть данных вернул, а часть не смог. То есть ошибка живет не только на уровне HTTP, но и внутри GraphQL-response. Для аналитика это важный момент. Если в ТЗ написать: "При успешном ответе 200 отобразить данные клиента" - можно случайно пропустить сценарий, где клиент пришел, а счета не пришли. И UI такой: ⏺️ФИО есть. ⏺️Счетов нет. ⏺️Ошибки нет. Пользователь думает: "У меня пропали деньги?" Не очень хороший UX, мягко говоря. 😈 GraphQL — классный инструмент, но он требует другой дисциплины требований. Там недостаточно смотреть на HTTP status. Нужно смотреть на data, errors, path, extensions.code и на то, как система живет с частичными данными. Если REST учит нас думать endpoint-ами, то GraphQL заставляет думать графом данных. И да, 200 OK в GraphQL — это не всегда OK. Иногда это просто вежливый способ сказать: "Я сделал что смог, дальше разбирайтесь сами". ENJOY! ⭐️

Цель: Снизить количество обращений в поддержку по статусу заявки на 30% за 3 месяца │ ├── Актор: Клиент, который подал заявку │ │ │ ├── Влияние: Самостоятельно понимает текущий статус заявки без обращения в поддержку │ │ ├── Результат: Экран со статусом заявки в личном кабинете │ │ └── Результат: Отображение следующего ожидаемого шага по заявке │ │ │ └── Влияние: Получает уведомление при изменении статуса заявки │ ├── Результат: Push-уведомление при смене статуса │ └── Результат: Email/SMS-уведомление, если push недоступен │ ├── Актор: Оператор поддержки │ │ │ └── Влияние: Быстрее отвечает на вопросы по заявке без обращения к смежным командам │ ├── Результат: Просмотр истории изменения статусов заявки в админке │ └── Результат: Отображение причины отклонения или задержки обработки │ └── Актор: Сотрудник бэк-офиса │ └── Влияние: Своевременно фиксирует результат обработки заявки в системе ├── Результат: Обязательное указание финального статуса при завершении обработки └── Результат: Валидация причины отказа перед переводом заявки в финальный статус Что здесь важно увидеть: ➡️ мы не начинаем с решения “давайте сделаем экран статуса” ➡️ сначала формулируем бизнес-цель ➡️ потом определяем акторов, которые влияют на эту цель ➡️ дальше описываем, как должно измениться их поведение ➡️ и только после этого предлагаем конкретные решения То есть правильная логика такая: Хотим снизить обращения в поддержку → клиент должен сам понимать статус заявки → для этого нужен экран статуса и уведомления А не так: Давайте сделаем пуши, потому что пуши звучат современно ➖➖➖ Когда использовать Impact Mapping? На мой взгляд, особенно полезно использовать: ✅ при запуске нового продукта ✅ при планировании большой фичи на несколько спринтов ✅ когда в обсуждении участвуют продукт, аналитики, разработка, маркетинг и продажи ✅ когда бэклог огромный, но никто не понимает, что реально важно ✅ когда команда делает много функций, но бизнес-результат не меняется Impact Mapping хорошо помогает на старте, когда надо не сразу бежать писать задачи, а сначала понять: Куда мы вообще идем и кто должен начать вести себя иначе? ➖➖➖ Когда лучше не использовать? Не всегда надо натягивать Impact Mapping на всё подряд. Не очень подходит для: ❌ исправления багов ❌ технических задач без изменения поведения пользователей ❌ compliance-задач, где просто надо выполнить требование регулятора ❌ инфраструктурных работ типа обновления БД или миграции серверов ❌ маленьких задач, где и так понятно, что нужно сделать Не надо делать карту ради карты. Аналитики и так умеют создавать артефакты, которые потом никто не открывает. Не будем увеличивать популяцию таких документов 😅 ➖➖➖ ИТОГО: Impact Mapping — это хороший способ проверить, не строим ли мы фичи ради фич. Он помогает связать: бизнес-цель → людей → изменение поведения → конкретные решения Главная мысль простая: Мы не просто делаем функциональность. Мы пытаемся изменить поведение акторов так, чтобы достичь бизнес-результата. Если решение не влияет на поведение и не двигает нас к цели — возможно, это просто еще одна задача, которая красиво выглядит в бэклоге, но никому особо не нужна. 📎 Материалы для погружения: 🔴 Impact Mapping на практике https://habr.com/ru/articles/246401/ 🔴 Как создать работающий Impact Map https://habr.com/ru/articles/652577/ 🔴 Impact Mapping на практике https://www.slideshare.net/slideshow/impact-mapping-46088549/46088549 ENJOY!⭐️

Всем привет! 🤝 Связи с семейными обстоятельствами немного выпал из написания постов, прошу прощения) Сегодня хочу разобрать тему, которая помогает не превращать бэклог в склад хотелок — Impact Mapping. Если простыми словами, Impact Mapping — это техника планирования, которая помогает связать требования, фичи и задачи с реальным бизнес-результатом. Потому что сделать много функций — не значит принести пользу бизнесу. Иногда это просто красиво оформленный хаос в Jira 😅 ➖➖➖ ❓ В чем идея Impact Mapping? Impact Mapping отвечает на 4 главных вопроса: 1️⃣ Зачем мы это делаем? - Это цель. 2️⃣ Кто может повлиять на достижение цели? - Это акторы. 3⃣ Как должно измениться их поведение? - Это влияние. 4️⃣ Что мы можем сделать, чтобы вызвать это изменение? - Это результат / решение / фича. Если совсем коротко: Цель → Акторы → Влияние → Решения И вот это важно ☝️ Мы не просто придумываем функции. Мы думаем, чьё поведение должно измениться, чтобы бизнес получил нужный результат. ➖➖➖ ❓ Какую проблему решает Impact Mapping? Очень часто требования приходят в формате: 🔴 “Сделайте кнопку” 🔴 “Добавьте фильтр” 🔴 “Нужен новый экран” 🔴 “Хотим уведомления” 🔴 “А еще отчетик, желательно вчера” И вроде бы звучит как работа, но есть маленькая проблема: непонятно, зачем это всё нужно. В итоге получаем: 🔴 бэклог раздут 🔴 приоритеты ставятся “по ощущениям” 🔴 команда превращается в feature factory 🔴 функций много, а бизнес-результата нет Impact Mapping заставляет нас задать неприятный, но полезный вопрос: А это решение реально влияет на цель? Если нет — возможно, его и делать не надо. Да, звучит больно. Особенно для тех, кто уже нарисовал красивый экран в Figma. ➖➖➖ 1️⃣ Цель Цель — это не “улучшить UX” и не “сделать удобнее”. Это слишком размыто. Хорошая цель должна быть измеримой. ❌ Плохо: Улучшить пользовательский опыт ✅ Лучше: Снизить количество обращений в поддержку по статусу заявки на 30% за 3 месяца Почему так? Потому что если нет метрики, то потом невозможно понять, сработало решение или мы просто дружно похлопали себе за активность. ➖➖➖ 2️⃣ Акторы Акторы — это люди или группы людей, которые могут помочь или помешать достижению цели. Важно: актор — это не API, не база данных и не микросервис. Актор — это тот, у кого есть поведение. Примеры акторов: ⏺ клиент ⏺ оператор поддержки ⏺ сотрудник бэк-офиса ⏺ менеджер продаж ⏺ администратор системы ⏺ партнер То есть нас интересуют не компоненты системы, а роли, которые что-то делают. ➖➖➖ 3⃣ Влияние Влияние — это изменение поведения актора. И вот здесь часто путаются. ❌ “Показать пользователю экран статуса” — это не влияние. Это решение. ✅ “Клиент самостоятельно понимает текущий статус заявки без обращения в поддержку” — вот это влияние. То есть влияние отвечает на вопрос: Как должно измениться поведение человека? Примеры: ⏺ клиент реже обращается в поддержку ⏺ оператор быстрее решает обращение ⏺ сотрудник бэк-офиса своевременно фиксирует результат обработки ⏺ пользователь завершает оформление заявки без помощи менеджера Хорошее влияние можно наблюдать и измерить. Если нельзя понять, изменилось поведение или нет — скорее всего, это не влияние, а красивая абстракция. ➖➖➖ 4️⃣ Решения / результаты Решения — это уже то, что делает команда: ⏺ фича ⏺ API ⏺ экран ⏺ отчет ⏺ уведомление ⏺ пользовательская история ⏺ изменение процесса Но решение попадает на карту только тогда, когда оно напрямую поддерживает влияние. То есть логика должна быть такая: Если мы сделаем X, то актор начнет вести себя иначе, и это поможет достигнуть цели. Если цепочка не сходится — решение можно смело отправлять в музей “хотели как лучше”. ➖➖➖ 📌 Пример Impact Mapping Допустим, у нас есть сервис подачи заявок, например, на открытие банковского продукта. Проблема: пользователи часто пишут в поддержку с вопросом: “А что с моей заявкой?” 🎯 Цель: Снизить количество обращений в поддержку по статусу заявки на 30% за 3 месяца

Всем Привет! Недавно увидел такое объявление о митапе "Применение ИИ в системном анализе", думаю будет интересно Меня тоже очень зацепила тема про ИИ в работе системных аналитиков. Буду подключаться онлайн к мероприятию МТС Web Services 14 мая, чтобы послушать, как эксперты из MWS и Orion Soft видят трансформацию профессии, использование Cursor в повседневной работе и внедрение ИИ в архитектуру решений. Кажется, будет полезно не только аналитикам, но и всем, кому интересно, как ИИ уже меняет IT-процессы. Так что зовите своих и присоединяйтесь к онлайн-трансляции, послушаем вместе. Ссылка для регистрации ENJOY! ⭐️

Всем привет! Недавно мне в личку написали с просьбой показать на примере как описывать интеграцию с gRPC. (Через это проходит каждый, кто впервые сталкивается с gRPC.) Разбираемся. ➖➖➖ Возьмем для примера запрос на создание заказа. Как бы мы его описали в REST? endpoint POST /api/v1/orders Запрос: { "user_id": 12345, "product_id": "SKU-001", "quantity": 2 } Ответ: { "order_id": "ORD-9876", "status": "created", "total": 3500.00 } Все привычно А как это может выглядеть в gRPC в формате .proto: text syntax = "proto3"; message CreateOrderRequest { int64 user_id = 1; string product_id = 2; int32 quantity = 3; } message CreateOrderResponse { string order_id = 1; string status = 2; int64 total = 3; } service OrderService { rpc CreateOrder(CreateOrderRequest) returns (CreateOrderResponse); } На первый взгляд выглядит непривычно, однако, по сути всё то же самое. Просто другой стиль описания. Что тут что? 1️⃣ message = наш JSON-объект. Только каждое поле имеет строгий тип (int64, string, double) и уникальный номер. 2️⃣ service + rpc = наш эндпоинт. Вместо POST /orders пишем rpc CreateOrder. 3️⃣ Номера полей (= 1, = 2) это не значения. Это идентификаторы для сериализации. Их нельзя менять местами после релиза, можно дополнять новыми полями. ➖➖➖ Нужно ли нам с вами это описывать самостоятельно ручками? И да, и нет. Все зависит от договоренностей между вами и разработчиками. Есть разные варианты: ✔️ Описать контракт сразу в .proto формате, но самый неудобный для нас вариант, так как требует развитых навыков. Да и если, мы как-то прокосячим, то разработке будет сложнее с этим разбираться. ✔️ Описать таблицей: • поле, • тип, • обязательность, • описание. Обычная табличка с входными или выходными параметрами, которые мы с вами описываем в постановках на API. Разработчик сам переведёт в .proto Тут с нас грамотная постановка по пунктам и мы не трогаем реализацию. ✔️ Описать в привычном JSON-стиле, но указать типы строго. Не number, а int или decimal или float. Ну вы поняли. Это то, о чем я всегда говорю. ➖➖➖ Надеюсь ответил на вопрос 😉 Понятное дело, что если есть желание разобраться, то надо копать еще глубже, потому что там будут еще нюансики с типами и с обработкой ошибок. Было полезно, ставь 🔥 ENJOY!⭐️

Друзья всем привет! Приглашаю всех на ежегодную IT-конференцию beetech conf 2026 23 мая в NARXOZ University в 9:00. Вас ждут 24 отобранных доклада в 3 стримах: management, data & AI, engineering, speed-менторинг, квартирники и нетворкинг — всё, что ценит IT-комьюнити. Сейчас самый выгодный момент взять билет только до 20 апреля по ссылке: https://beetech.kz early bird — всего 15 000 тг, а через приложение Freedom — 12 150 тг с кэшбэком. Приходите, этот день вдохновит вас на целый год 🔥 ENJOY!⭐️

Всем привет! Сегодня хочу расписать тему 🗄Файловый обмен через DMZ: как это устроено на практике Я сам работал с банковским проектом, где между внешними контрагентами и внутренними системами был выстроен файловый обмен. Архитектор постоянно говорил: «файл из грязной зоны», «файл пойдет в чистую зону», и поначалу это звучало странно. Но логика абсолютно понятная, когда разбираешься. Вот как выглядит путь файла: * Файл приходит снаружи → попадает в DMZ Внешний контрагент загружает файл на FTP-сервер или в папку обмена. Этот сервер живет в DMZ - не внутри, не снаружи, а «в буфере». Внутренние системы его еще не видят, пока он там не пройдет все прокерки ** Файл проходит проверки прямо в DMZ Это самый важный момент. Файл не пускают дальше, пока он не пройдёт контроль. Что именно проверяется: 🦠Антивирусное сканирование - обязательно. Файл проверяется на наличие вредоносного кода, макросов, встроенных скриптов 📋 Валидация формата - ожидаем CSV, а пришёл .exe под видом .csv? Уже отказ. Проверяется не только расширение, но и реальный тип файла 📏 Проверка размера и структуры - файл соответствует ожидаемой схеме? Все обязательные поля на месте? Кодировка правильная? 🔍 Проверка контента - в особо серьезных случаях проверяется содержимое: нет ли там персональных данных, которые не должны были попасть в этот канал, или чего-то ещё, что нарушает политику. ❗️Много лет назад, работая в Сбере, я переслал себе из внутреннего контура во внешний файл со своими перс данными. Мне сразу пришло сообщение, что файл улетел на проверку в отдел безопасности, на следующий день я писал пояснение / объяснительную руководителю для отдела безы, зачем и что я пересылал, т.к. это нарушение. ❗️Еще нельзя было на свою личную почту что-то с внутреннего контура пересылать. Это типичная история для корпоратов и критических проектов *** Файл либо пропускают в чистую зону, либо нет Прошел все проверки - файл перекладывается во внутреннюю папку, откуда его забирает уже внутренняя система. Не прошел - файл остается в DMZ (или уходит в карантин), а нужные отделы получают уведомление И в обратную сторону, когда файл уходит из чистой зоны наружу, он тоже проходит через DMZ. Здесь уже проверяют другое: нет ли в файле конфиденциальных данных, которые не должны покинуть периметр. Это называется Data Leakage Prevention DLP 💡Почему это важно знать системному аналитику? Потому что когда вы проектируете интеграцию с внешней системой или внутри одной системы вытаскиваете фронт/мобилку наружу, вы неизбежно столкнетесь с вопросом: а где живет точка обмена? Кто контролирует вход? Что происходит с данными до того, как они попадают в систему? Если в проекте есть безопасники или сетевые архитекторы, аналитик может с ними коммуницировать, рассказывать требования и ожидать рекомендаций по передаче данных. И гораздо лучше, если вы уже заранее понимаете, о чем речь, и сразу закладываете в требования: какие проверки нужны на входе, какой формат ожидается, что делать с «плохим» файлом, кто получает алерт и т д. ENJOY!⭐️

2️⃣0️⃣ Всем привет! Очередной разбор с собеса, в этот раз моя НЕ любимая сфера бизнеса - Igaming | Солидный оффер и непринужденная беседа Вакансия: Системный аналитик Уровень: Senior Сфера: Igaming 📝 Секция «Общие вопросы»: 🔵Расскажи про свой опыт: проекты, роли, стек. (Классика) 🔵Было ли разделение BA/SA? Как взаимодействовали. (Часто) 🔵Почему уходишь с текущего проекта. (Бывает) 🔵Как выстраиваешь рабочий день и приоритезируешь задачи. (Часто) 📝 Секция «Требования и Нотации»: 🔵Приведи пример реально US из своего опыта. (Бывает) 🔵Критерии качества US и требований в целом. (Бывает) 🔵В каком формате описываешь спецификации/постановки. (Классика) 🔵С какими видами требований доводилось сталкиваться на практике. (Классика) 🔵Как декомпозируешь эпики. (Редко) 🔵Какие техники сбора требований используешь на практике. (Классика) 🔵Какие виды UML диаграмм чаще всего используешь на практике. (Классика) 🔴Кейс: Опиши вкратце одну из самых больших созданных тобою BPMN диаграмм. Для чего она создавалась и какую задачу решала. 🔴Кейс: Нашей системой пользуются 100 внутренних сотрудников. Необходимо собрать с них требования. Как построить процесс постоянного сбора требований с такого количества пользователей. 👣 Секция «API/HTTP/Интеграции»: 🔵Как проектировала REST-API. Чем был обоснован выбор того или иного HTTP метода. (Классика) 🔵В каком формате описывала обработку ошибок, алгоритм работы метода. (Бывает) 🔵С какими типами интеграций сталкивалась на последнем проекте. (Классика) 🔵Расскажи про самую сложную интеграцию, которую тебе доводилось проектировать. (Очень люблю задавать такой вопрос. Посредством рассказа про самую сложную/интересную таску можно нащупать наличие реальной эмоциональной привязки кандидата к описываемому им кейсу и понять реальный это опыт или нет) 🔵Руководствуясь чем выбирала синхронный/ассинхронный тип интеграции. (Часто) 🖥 Секция «Базы данных»: 🔵Расскажи про свой опыт проектирования БД. (Классика) 🔵В чём разница между LEFT JOIN и RIGHT JOIN. (Классика) 🔵Ты упомянула, что работа с Redis и PostgreSQL. Чем был обоснован выбор технологии в том или ином случае. (Бывает) 🖥Секция «Брокеры»: 🔵Объясни принцип работы Kafka. (Бывает) 🔨 Итог: Легкий и непринужденный во всех смыслах собес. Интервьюер органично встраивает вопросы в ходе диалога. Но есть одна занятная тенденция, почему-то начинают спрашивать все чаще и чаще за выбор стека (Хотя казалось бы, причем тут СА). В итоге оффер получен, но не использован ENJOY!⭐

Друзья, всем привет! 🤚 Долгое время у меня была мечта, найти время и написать небольшой , полезный, а главное БЕСПЛАТНЫЙ курс по бизнес анализу. И слава Богу, успел дописать курс в Священный месяц Рамадан (т.к. писал порядка 3 месяцев) и выкладываю в первую очередь его тут для вас. Тут есть два составляющих фактора: 1. курс можете пройти как сами, так и делиться им со своими знакомыми, друзьями - кто хотел попасть в IT и не знал с чего начать, курс в открытом доступе. 2. меседж к аналитикам с опытом, если среди вас будут кто захочет его пройти, и вдруг вы найдете у меня где-то ошибки или я что-то не так написал - огромная просьба сообщите мне пожалуйста об этом, буду исправляться (контактные данные там есть) Ну на этом все, достаточно слов Вот ссылка на курс по Бизнес анализу ENJOY! ⭐