Представьте: вы смоделировали процесс, нажали кнопку, и он работает. Сам назначает задачи, сам контролирует сроки, сам правит данными. Это не фантастика, а реальность с исполняемыми процессами на Camunda. 23 сентября мы покажем, как это сделать на бесплатном вебинаре «Уровни моделирования бизнес-процессов. Исполняемый BPMN».
Что будет в эфире:
✔️ Живой разбор работы в Camunda: от установки до запуска.
✔️ Покажем, как программировать логику шлюзов и создавать пользовательские формы.
✔️ Ответим на вопрос: какую модель пойдет исполнять движок, а какую — нет.
🗓 Дата: 23 сентября
⏰ Время: 17:00–18:00 (Мск)
👨🎓 Спикер: Алексей Тарасов — аналитик с 10-летним опытом.
Когда «простой» бизнес-процесс превращается в хаос: правила всплывают на ходу, код становится хрупким, а бизнес недоволен…
Как этого избежать? Один из ответов — EventStorming. Метод, который помогает вытянуть скрытые требования, уточнить бизнес-правила и превратить размытые идеи в чёткие DDD-модели.
Про вайб и прочих ИИ агентов в ретроспективе "лихих 90-х"
90-е годы в новой демократической России, двигавшейся в правильном направлении неправильными путями, были эпохой расцвета местных и суверенных ERP-систем, многие из которых живы до сих пор.
Покупать готовые западные решения могли только самые прибыльные компании, но большинству платить тысячи долларов за каждую пользовательскую лицензию было не по карману. С другой стороны, в отрасль софтостроения влилось большое число выпавших из "оборонки" и бюджетных НИИ квалифицированных инженеров и научных работников, из тех, кто не "смазал лыжи", что позволило создавать очень интересные и масштабные продукты. Надо сказать, что известная многим 1С тогда вообще не воспринималась всерьёз ввиду ограничений масштаба применения, и процветала в нише бухгалтерских программ за счет движка и скриптового языка.
Будучи разработчиком одной из небрендовых ERP-систем, приходилось участвовать в предпродажных сессиях. Ярким воспоминанием остались контакты с "девопсом" потенциальных клиентов. Никаких "девопсов", конечно, тогда не было: инфраструктурой или, как иногда говорят, "ландшафтом" занимались системные администраторы, инженеры и ДБА.
Приходишь на презентацию, и видишь суровые скептические лица сисадминов, которые, не скрывая чувств, заявляют нечто вроде: "Жаль, времени нет, а то мы бы сами на Delphi за выходные написали бы, то что вы нам за деньги предлагаете..."
Когда сейчас натыкаешься на очередную "джинсу" по вайбкодингу и прочему агентскому клепанию "типа софта", нередко выясняется, что авторы - спецы в инфраструктуре. И тогда сразу становится ясен смысл написанного: "Да мы сами на выходных на Delphi сделаем, то что вы нам за немереные деньги пытаетесь впаривать".
Как связаны игра «Что? Где? Когда?» и работа в IT?
А вы знали, что методы легендарной интеллектуальной игры могут стать ключом к эффективной работе вашей команды? Рассказываем в нашей новой статье!
«За зеркальным столом я капитан команды, а на работе — бизнес-аналитик. Но в последнее время эти роли размываются, потому что параллели между поведением команды за столом и во время обсуждения рабочих задач…как-то уж очень близки. И однажды мне захотелось исследовать, как методы из игры работают в реальной жизни. Как оказалось, большинство моментов применимо» — пишет автор статьи Евдокия Аверина.
Если вдруг кто не знал, как я. Для обозначения графических схем архитектуры программного продукта, которые изображают маркетологи и продуктовые менеджеры в презентациях, т.е. те которые не совсем технические, существует термин - это "маркетектура".
В общем смысле, это представление программного продукта для не технических специалистов, фокусирующееся на преимуществах и выгодах для пользователей, а не на технических деталях.
Но это ещё не всё. То что мы привыкли считать технической архитектурой, т.е. описывающей компоненты и их взаимодействие, тоже имеет термин - это "тархитектура".
Давайте поделим пользователей на опытных и тех кто не любит читать FAQ
Меня уже очень долгое время беспокоит необходимость пробиваться через ботов и ИИ помощников чтобы получить ответ от поддержки. Это касается и телекома / банков / маркетплейсов и много кого еще.
Я разраб, поэтому чаще всего сначала обращаюсь к документации / читаю сайт или FAQ / ищу в интернете информацию до того, как написать. Я не хочу никого отвлекать. Кроме того, часто приходится ждать ответа долго.
Поэтому, про меня можно с уверенностью сказать, что я точно поискал информацию и ничего не нашел, раз пришел в поддержку. У меня не стандартный вопрос, поэтому мне сразу нужен оператор. Выбор из стандартно сгенерированных ответов или выбор из меню списка интересующих разделов мне не только не помогает, но и уменьшает мою лояльность бренду (или просто бесит).
Пытаюсь доказать пчеле что я искал информацию о приставке для аренды и мне нужен оператор (бот не знает про модель приставки и отдает стандартный ответ где я могу ее арендовать)
Давайте уже признаем, что есть люди, которые поискали сами и скорее всего им поможет только оператор! И бизнесу желательно с этим считаться... А вы как думаете?
Только синие и серые блоки в "C4 model" - это заблуждение. Модная нотация, которую мы привыкли изображать в основном в оттенках синего ди и серого тоже, оказывается так не задумывалась. Об это Саймон Браун писал и раньше в разделе "Notation" на своем ресурсе:
"Although you may see many example diagrams and tools that make use of blue and grey boxes, this isn’t something that is dictated by the C4 model, and you are free to use whatever colours you like!"
Продолжаем набор специалистов в ИТ-команду SSP SOFT
Привет Хабр! Уже конец лета и не пора ли серьезнее подумать о новой работе — а мы продолжаем нанимать. Предлагаем реальные задачи, прокачку скиллов и бенефиты «в рынке». Никакой бюрократии и скуки — мы нацелены на то, чтобы вы получали удовлетворение от работы.
✔️ Гарантируем интересные задачи ✔️ Для каждого нового сотрудника есть наставник ✔️ Центр компетенций помогает прокачивать навыки ✔️ С нами ты можешь работать из любой точки мира ✔️ Для экстравертов у нас есть офисы в Москве и Томске ✔️ Оптимальный Work Life Balance ✔️ ДМС со стоматологией, обучение от компании и бонусная программа.
📢 На этой неделе мы ищем (см. ссылки на описание вакансий у каждой позиции):
👉 Не обязательно откликаться через hh — присылайте резюме напрямую нашему HR в Telegram: @sspsoft или на почту: job@ssp-soft.com. Не забудьте сопроводительное письмо с фразой «Нашел вас на Хабр», чтобы резюме рассмотрели по-возможности быстрее.
Почему ваша архитектура ломается? Спросите у того, кто чинил десятки таких систем!
04.09.2025 в 15:00 (Мск) приглашаемна первую открытую AMA-сессию «Спроси меня о чем угодно» с Дмитрием Овчаренко — техническим директоромдепартамента«Разработка для финансового сектора» IBS и экспертом Учебного центра IBS по архитектуре ПО.
Что вас ждёт (и почему это не обычный вебинар):
✔️ Без воды — только честные ответы на ваши вопросы (даже на те, о которых стыдно спросить).
✔️ Разбор реальных косяков — как ломались системы и что с этим делали.
✔️ Карьерный лифт — что нужно, чтобы перейти из разработчика в архитекторы?
А еще конкурс:
Пришлите самый нестандартный, забавный или абсурдный вопрос в комментариях к этому посту. Автор лучшего получит приз!
Кому полезно?
➕ Разработчикам, которые хотят расти до архитекторов.
➕ Аналитикам, уставшим от абстрактных советов.
➕ Всем, кому интересно, как устроена «кухня» fintech.
💡 Статический сайт в облаке Gramax. Можно опубликовать свою документацию буквально за пару кликов, для этого не нужен сервер или хостинг. Достаточно нажать «Опубликовать в облако» и войти в почтовый аккаунт.
💡 Фильтр по содержимому. В каталоге можно создавать статьи и абзацы для разных сборок. На портале для чтения они будут фильтроваться с помощью переключателя.
💡 Браузерная версия на мобильном. Браузерную версию Gramax можно использовать на мобильном телефоне. Доступны все действия, как при работе на компьютере.
А также:
📌 Новая главная страница. Улучшили внешний вид главной страницы. Добавили возможность создавать вложенные группы.
📌 Транскрипция речи с помощью ИИ. Если в пространстве включены ИИ-функции, редактор может автоматически транскрибировать аудиозаписи в текст.
📌 Просмотр изменений после синхронизации. После синхронизации автоматически открывается окно сравнения ревизий: сравнивается новая версия каталога с версией до синхронизации.
Об этих и других изменениях читайте в Release Notes 🔥
Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Рабочие места в офисах в Москве (отличная локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.
📢 Кого мы сейчас приглашаем (это описание вакансий в hh, а ниже прямые контакты с нашим HR для быстрого отклика):
Мы ценим сотрудников — работа без лишней бюрократии — только задачи, которые приносят результат и удовлетворение от процесса, участие в реальных проектах, развитие профессиональных навыков.
🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.
👉 В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.
Пишите с резюме нашему HR в Telegram: @sspsoft Или присылайте резюме на почту: job@ssp-soft.com.
Как мы ускорили проверку документации с помощью AI-агента: от боли к решению
Привет, Хабр! Я — Мила Муромцева, системный аналитик в Альфа-Банке. Эту статью мы подготовили вместе с нашим разработчиком Мишей Буториным. Написали ее, чтобы поделиться нашим опытом и рассказать, как мы научили LLM проверять документацию для платформы Альфа-Онлайн — переписывали стандарт, боролись с токенами и немного с хаосом.
Самое ценное — детальное описание того, как команда поборола проблему потери данных при проверке огромных документов LLM. Вместо описания абстрактных алгоритмов кейс строится вокруг настоящей боли и решения, которые можно применить для своих корпоративных задач.
Статья «Как мы ускорили проверку документации с помощью AI-агента: от боли к решению» будет полезна тем, кто автоматизирует проверки, работает с большими данными и хочет, чтобы нейросети давали точные и надёжные ответы — даже при работе с очень громоздкой документацией. Внутри разбираем кейс командной интеграции LLM: от первых ошибок до финального формата отчета, который реально экономит токены и нервы!
🔥 Монолитный фронтенд тормозит ваш проект? Пора задуматься о микрофронтендах!
Если разработка кажется бесконечной, внедрение фич превращается в квест, а код стал клубком из зависимостей — вы не одни. Мы знаем эту боль не понаслышке!
Наш новый вебинар «Архитектурный перелом: что делать, когда фронтенд трещит по швам» — это честный разговор о реальном пути перехода от монолитного фронтенда к микрофронтендам. Никакой воды, только реальный опыт: когда сложность системы достигла критической точки, мы решились на глобальные перемены.
📅 Дата: 14.08.2025
⏰ Время: 17:00-18:00 (Мск)
👨🎓 Спикер: Акманова Елизавета — старший аналитик ГК «Юзтех», преподаватель школы системного анализа.
Что будет на эфире?
✔️ Разберем объективные причины, которые подтолкнули нас к смене архитектуры.
✔️ Реальные плюсы и минусы микрофронтендов.
✔️ Практические кейсы, неочевидные вызовы и решения.
✔️ Честные выводы и советы, чтобы ваш переход был максимально гладким.
Почему одиночкам тяжело расти? Как мы организовали сообщество системных аналитиков и что из этого вышло
В IT слишком часто «каждый варится в своём соку» — и специалисты теряют темп, а команда не получает новых идей.
Какие шаги помогли объединить экспертов из разных проектов, даже если зона ответственности не совпадает? Как совместные обсуждения, обмен опытом и единые подходы преобразили корпоративную культуру? Какие неожиданные инсайты и эффекты обнаружились уже через несколько месяцев — и почему это оказалось выгодно всем сторонам? Рассказываем в нашей статье «Как мы организовали сообщество системных аналитиков и что из этого вышло».
Только реальный опыт, этапы создания, сложности, примеры встреч, плюсы и подводные камни. Читайте статью, берите инструменты для своих команд и рассказывайте, помогает ли комьюнити решать задачи эффективнее у вас!
Говорим на языке событий: что даёт ивент-шторминг и как его правильно провести
Привет! Я Иван Чернов, системный архитектор, в этом посте расскажу про ивент-шторминг.
В Островке есть набор сервисов, который разбит на логические блоки так, чтобы в рамках блока можно было итерировать: Островок, Островок B2B и Островок Командировки. При этом запускать новые фичи, которые будут сквозь эти слои прорезаться.
Мы растём по количеству и продуктов, и людей, нанятых для их разработки. Недавно начали толкаться локтями: не понимали, как качественно контрибьютить в большие кодовые базы, как они должны эволюционировать. Поэтому пришли к ивент-штормингу.
Что это за практика? На встрече с одной стороны сажаем бизнес, с другой — разработку. Просим бизнес рассказать, что и как он делает в работе с клиентом.
Ивент-шторминг проводится с фокусом на цикличную реактивность: происходит событие, которое визуально меняет что-то для пользователя, тот принимает решение и отдаёт команду, команда приводит к новому событию.
На этих циклах фокусируемся на доске в Miro во время встречи.
В ивент-шторминге 3 этапа:
1. Сейлзы выстраивают по циклам цепочку событий: от «клиента у нас ещё нет» до «клиент нас окончательно покинул». Даже в простых цепочках 20–30 действий. В готовом таймлайне есть happy pass: клиент успешно прошёл весь путь. И альтернативные пути: что-то пошло не так.
2. Проходим по таймлайну с конца, ищем ошибки. Выделяем ключевые события, которые нельзя откатить: клиент зарегистрировался, совершил бронирование, провёл оплату. Здесь происходит стык сервисов. На стыках обогащаем цепочку. Пишем, кто и что делает: актор-клиент зарегистрировался, подключился сервис юзер-менеджмента.
3. Выявляем, какие агрегаты работают с событием. Мапим команды: клиент регистрируется, в работе участвует команда регистрации.
Цепочка готова, мы получили полезный контекст, все одинаково понимают процессы и видят, что нужно делать, чтобы их улучшить.
Во время встречи составляем словарик. Если сейлз говорит непонятное разработчикам слово — мы его добавляем в словарь, и оно просасывается в наш интерфейс и кодовую базу. Всё это учит разработчиков понимать, на какие рычажки они влияют своим кодом.
Поделюсь советами, как круто провести ивент-шторминг.
Онлайн-формат
● Для проведения онлайн достаточно доски в Miro.
● Разбивайте встречу на три части, каждая встреча — один этап.
● На последней встрече отпустите бизнес, выявите агрегаты и сервисы, задействованные в таймлайне с разработкой.
● Максимум людей для успешной фасилитации онлайн — 8–10 человек.
● Ищите представителей бизнеса в оргчате выбранного домена: спрашивайте у руководства, «кто тут самый инициативный».
● Вам нужны работники «с полей», которые лучше всего шарят в процессах, и тимлиды первого уровня.
● Берите людей из разных направлений домена.
● Бизнес-участники должны понимать: ивент-шторминг — процесс обучения, они эксперты, а разработка — ученики. Им нужно говорить на своём языке, а не подстраиваться под разработку.
● Дайте участникам базовый словарь. Четыре самых важных слова: актор, команда, событие, термин.
● Важны вводные по времени и цели: на сессию уйдёт суммарно 6–8 часов, она даст единое понимание процессов.
Фасилитация
● На старте не бойтесь повторить все вводные.
● Дайте сейлзсам 10 минут на то, чтобы каждый выстроил индивидуальный таймлайн, дальше начинайте мёржить таймлайны с общим обсуждением.
● Событие — факт в прошедшем времени, его не отмотать. Следите, чтобы так и записывали.
● Первым делом простройте happy pass, иначе у вас не выстроится цельное видение процесса. Альтернативные ветки обозначьте на первом этапе, а достраивайте на втором, проверяя таймлайн с конца.
● Если бизнес утверждает, что два события происходят одновременно, это важная точка обсуждения.
● Организуйте пост-процессинг: важно передать разработке результаты, объяснить, какие процессы у нас уже верно реализованы, а где нужно обновление и дополнительное внедрение.
Что такое архитектура ПО и почему она не про красивые диаграммы
Изображение сгенерировано при помощи DALL-E 3
🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.
Что это такое на самом деле? Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.
Зачем это нужно?
Снижает сложность системы через декомпозицию
Определяет рамки развития (чтобы не росло как раковая опухоль)
Помогает команде говорить на одном языке
Экономит нервы и деньги в долгосрочной перспективе
Под капотом архитектура отвечает за: ✅ Разбиение системы на модули (как LEGO, только для взрослых) ✅ Способы взаимодействия компонентов (REST, RPC, события) ✅ Распределение ответственности между модулями ✅ Выбор технологического стека
Простой пример: Представьте интернет-магазин. Без архитектуры у вас будет один гигантский файл на 50,000 строк, где корзина покупок живёт рядом с логикой оплаты, а пользовательские данные перемешаны с каталогом товаров. С архитектурой — отдельные модули: UserService, CatalogService, PaymentService, каждый со своей зоной ответственности.
🔧 Давайте разберём базовые понятия архитектуры, без которых никуда. Это как алфавит — скучно учить, но без него читать не получится.
Компонент — часть системы, выполняющая изолированную функцию. Думайте о нём как о сотруднике в компании: у каждого своя роль, свои обязанности, и если он заболел — его можно заменить.
Пример компонентов:
Authentication Service (следит, чтобы чужие не лезли)
Notification Service (шлёт уведомления)
Data Storage (хранит данные, очевидно)
Интерфейс — способ взаимодействия между компонентами. Это как протокол дипломатии: все знают правила игры, никто не лезет с кулаками.
Типы интерфейсов:
REST API (классика жанра)
Message Queue (асинхронные сообщения)
RPC (удалённые вызовы)
Database API (работа с данными)
Связи — физические или логические каналы передачи данных между компонентами. Это как дороги в городе: определяют, кто с кем может общаться и как.
Примеры связей:
HTTP-соединения (веб-траффик)
TCP/UDP сокеты (низкоуровневая связь)
Message Brokers (Apache Kafka, RabbitMQ)
Database connections (пул соединений с БД)
Модуль — логическая группировка компонентов по функциональности. Это как департаменты в компании: HR, IT, Бухгалтерия.
Примеры модулей:
User Management Module (всё что касается пользователей)
Payment Processing Module (платежи и транзакции)
Analytics Module (метрики и отчёты)
Сервис — автономная единица бизнес-логики с чётко определённой ответственностью. Это как мини-приложение внутри большого приложения.
Примеры сервисов:
Order Service (управление заказами)
Inventory Service (управление товарами)
Billing Service (выставление счетов)
Хранилище данных — компонент, отвечающий за персистентность информации. Это как склад или архив компании.
Типы хранилищ:
Реляционные БД (PostgreSQL, MySQL)
NoSQL (MongoDB, Redis)
Файловые системы (S3, локальные диски)
Кэши (Redis, Memcached)
SLA — характеристики работы сервиса. Это контракт: "обещаю работать 99.9% времени и отвечать за 200ms".
Зачем нужны SLA:
Понимание ожиданий от системы
Планирование мощностей
Определение критичности сервисов
Основа для мониторинга
Практический пример: Сервис авторизации должен:
Отвечать за 100ms в 95% случаев
Быть доступным 99.95% времени
Выдерживать 1000 RPS
Чеклист для правильного проектирования: ✅ Каждый компонент имеет чёткую ответственность ✅ Интерфейсы документированы ✅ Связи (способы взаимодействия) определены ✅ Деление на сервисы произведено ✅ Способ хранения данных определен ✅ SLA определены и измеряемы ✅ Зависимости между компонентами минимальны
Помните: хорошая архитектура начинается с понимания базовых элементов. Без этого ваша система превратится в спагетти-код корпоративного масштаба.
В SSP SOFT открыты новые вакансии в ИТ-команды: ищем мидлов, сеньоров и лидов
Мы в SSP SOFT — команда, которая занимается заказной разработкой и активно ведет проекты по модели ИТ-аутсорсинга. Наши специалисты помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.
Во 2-м полугодии 2025 года мы усиливаем несколько ключевых направлений. Если вы уверенно чувствуете себя как профи, цените системный подход и хотите работать в зрелой команде — присоединяйтесь.
Аналитика и системный анализ • Аналитик DWH • Аналитик 1С (Регламентированный учет) • Бизнес-аналитик (Промтех) • Системный аналитик (ИБ)
Разработка • Lead Python Developer • Android-разработчик (Senior) • Fullstack-разработчик (C#, React) • Разработчик 1С (ЗУП) • Разработчик Angular • Разработчик MS SQL • Data Engineer
Тестирование и поддержка • Automation QA Engineer • Automation QA Engineer (Python) • Automation QA Engineer (Java) • ITSM-инженер
Как мы подходим к найму:
В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.
🧩 Наши специалисты нередко входят в состав аутсорс-команд, работающих с внешними клиентами. Поэтому важно не только владение инструментами, но и софтскиллы: умение выстраивать коммуникацию, брать ответственность за сроки и качество своей работы.
🧭 Как устроен процесс найма и адаптации:
1️⃣ Собеседование с HR и руководителем направления, 2️⃣ Техническое интервью с нашими экспертами, 3️⃣ Индивидуальный план онбординга — с учетом ваших сильных сторон, 4️⃣ Испытательный срок — с поддержкой наставника, 5️⃣ Подключение к серьезным задачам — когда вы полностью готовы.
Представьте, что архитектура — это проект моста. Без аналитика строители видят только берега, бетон и металл. А потом выясняется, что по мосту должен проехать тяжёлый поезд, а не пешеходы. Опоздали...
Системный аналитик в архитектуре — это тот, кто ещё до первой строчки кода выясняет:
кто по мосту пойдёт;
когда он должен быть готов;
какой ветер дует в регионе;
и почему заказчик хочет на въезде логотип в стиле ар-деко.
Что делает аналитик:
Формализует требования. Не «нужно быстро», а «время отклика — до 300 мс для 95% запросов».
Собирает и декомпозирует требования: и бизнесовые, и технические.
Описывает процессы и данные, чтобы разработчики понимали, с чем работают.
Создаёт модели: ERD, BPMN, DFD, UML — чтобы было понятно и на митинге, и через год.
Выявляет противоречия. Если в одном месте говорится «реестр должен быть публичным», а в другом — «данные должны быть защищены по ФЗ-152», аналитик не ждёт багов — он их предотвращает.
Фиксирует ограничения: на инфраструктуру, бюджет, регуляторику.
Согласует архитектурные решения: чтобы бизнес понимал, почему микросервисы, а не монолит, и что это не «модно», а целесообразно.
Без него:
Архитектор опирается на предположения.
Команда упускает сценарии использования.
Нефункциональные требования (безопасность, отказоустойчивость, масштабируемость) игнорируются.
В итоге — технический долг с первого релиза и недовольный бизнес
И да, аналитик — не просто передатчик между бизнесом и технарями. Он переводчик с «хочу, чтобы было удобно» на «нужна интеграция с LDAP, SLA по логину — до 1 секунды».
Проект без аналитика — это как строить дом по фотографиям других домов. Кажется, понятно. А потом — сюрприз: у вас 12 ванных и ни одной кухни.
