Анализ и проектирование систем *

Проблема: Кадровый голод по специалистам, и при этом рекордные количества откликов на вакансии.

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

Общее решение: Изменить процесс наема так чтобы он помогал нанять специалиста для решения задач бизнеса.

Конкретные варианты решения:

1. Использовать зарекомендовавшие себя решения в других воронках\процессах получения чего-либо. Например сарафанное радио и нетворкинг, кумовщину и рефералки, при этом отказаться от существующих фильтров в пользу доверия на старте.

2. Устранить причину мешающую текущему процессу наема. Например сократить цепочку ЛПР-ов на пути соискателя до оптимума.

   (Сейчас это авто-скрипт, эйчар(или ряд эйчаров), собеседующий специалист(или ряд специалистов), представитель команды(или ряд представителей), опционально тут еще какие-то посредники, и вот тут уже можно выйти на работу и работать 😁. Причем на каждом этапе у лже-ЛПР-ов есть цель отсеять человека на основании формального фильтра. Тогда как лучшие работники обычно "неформалы" ибо они про работу работать как Стив Возняк, а не про продукт(себя) продавать как Стив Джобс. Очевидно что не каждая птица долетит даже до середины.. 😢)

   Оптимум - это ван ту ван, один ЛПР-соискатель на одного ЛПР-нанимателя. Собеседовать можно сколько угодно, но в конце один ответственный человек собирает всю информацию в кучу (и это не оценки и выжимки специалистов, а прям сесть и посмотреть портфолио, видео собеседования, пересказ нейронки прочитать как минимум по этому видео, переписку, на свою текущую ситуацию по задачам и срокам посмотреть и т.д.) и на основе всех имеющихся данных принять полноценное решение.

   ЛПР - это тот кто принимает решение что считает лучшим на этот момент, а не тот который работает по прописанному скрипту (иначе это не ЛПР, а человек которого настоящий ЛПР назначил отрабатывать строго по скрипту 😜).

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

P.S. Все 3 варианта решения на самом деле про одно и то же, только заход с разных сторон: убрать не то что мешает обрабатывать заявки на чиле, в пол уха, левой пяткой, а убрать то что действительно мешает нанять сотрудника для решения конкретных задач. (Да стало много спама, ну и что? Разве то что много спама говорит о том что среди спама нет специалистов способных делать работу? Нет. Как раз таки в этом и заключается задача\работа нанимателя - нанять сотрудника в этих конкретных условиях. Ну да, придется поработать. Соискатель, наниматель и работодатель в одной лодке как ни крути, если кто-то не хочет грести, то далеко ли уплывет такая лодка?🛶)

Хорошего дня, наема и трудоустройства!

Обнял 🤗

Представьте: вы смоделировали процесс, нажали кнопку, и он работает. Сам назначает задачи, сам контролирует сроки, сам правит данными. Это не фантастика, а реальность с исполняемыми процессами на Camunda. 23 сентября мы покажем, как это сделать на бесплатном вебинаре «Уровни моделирования бизнес-процессов. Исполняемый BPMN».

Что будет в эфире:

✔️ Живой разбор работы в Camunda: от установки до запуска.

✔️ Покажем, как программировать логику шлюзов и создавать пользовательские формы.

✔️ Ответим на вопрос: какую модель пойдет исполнять движок, а какую — нет.

🗓 Дата: 23 сентября

⏰ Время: 17:00–18:00 (Мск)

👨‍🎓 Спикер: Алексей Тарасов — аналитик с 10-летним опытом.

Превратите свои диаграммы в работающие механизмы!

➡️ Зарегистрироваться⬅️

Когда «простой» бизнес-процесс превращается в хаос: правила всплывают на ходу, код становится хрупким, а бизнес недоволен…

Как этого избежать? Один из ответов — EventStorming. Метод, который помогает вытянуть скрытые требования, уточнить бизнес-правила и превратить размытые идеи в чёткие DDD-модели.

18 сентября в 15:00 (Мск) приглашаем на бесплатный вебинар «EventStorming: провоцируем взаимопонимание между бизнесом и разработкой».

Что будет на вебинаре:

✔️ Мини-сессия EventStorming на примере FoodTech-платформы GourmetHub: процесс назначения курьера «под микроскопом»;

✔️ Пошаговый разбор — от «наивной» модели до выявления «горячих точек»;

✔️  Как события и команды превращаются в агрегаты и сервисы DDD;

✔️ Практика проектирования масштабируемых и надёжных микросервисов.

📅 Дата: 18.09.2025

🕒 Время: 15:00–16:00 (Мск)

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

Про вайб и прочих ИИ агентов в ретроспективе "лихих 90-х"

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

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

Будучи разработчиком одной из небрендовых ERP-систем, приходилось участвовать в предпродажных сессиях. Ярким воспоминанием остались контакты с "девопсом" потенциальных клиентов. Никаких "девопсов", конечно, тогда не было: инфраструктурой или, как иногда говорят, "ландшафтом" занимались системные администраторы, инженеры и ДБА.

Приходишь на презентацию, и видишь суровые скептические лица сисадминов, которые, не скрывая чувств, заявляют нечто вроде: "Жаль, времени нет, а то мы бы сами на Delphi за выходные написали бы, то что вы нам за деньги предлагаете..."

Когда сейчас натыкаешься на очередную "джинсу" по вайбкодингу и прочему агентскому клепанию "типа софта", нередко выясняется, что авторы - спецы в инфраструктуре. И тогда сразу становится ясен смысл написанного: "Да мы сами на выходных на Delphi сделаем, то что вы нам за немереные деньги пытаетесь впаривать".

Как связаны игра «Что? Где? Когда?» и работа в IT?

А вы знали, что методы легендарной интеллектуальной игры могут стать ключом к эффективной работе вашей команды? Рассказываем в нашей новой статье!

 «За зеркальным столом я капитан команды, а на работе — бизнес-аналитик. Но в последнее время эти роли размываются, потому что параллели между поведением команды за столом и во время обсуждения рабочих задач…как-то уж очень близки. И однажды мне захотелось исследовать, как методы из игры работают в реальной жизни. Как оказалось, большинство моментов применимо» — пишет автор статьи Евдокия Аверина. 

Если хочется идти дальше стандартных подходов и строить по-настоящему слаженную команду — статья «Что? Где? Когда?» и эмоциональный интеллект в бизнес-команде для вас!

Если вдруг кто не знал, как я. Для обозначения графических схем архитектуры программного продукта, которые изображают маркетологи и продуктовые менеджеры в презентациях, т.е. те которые не совсем технические, существует термин - это "маркетектура".

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

Но это ещё не всё. То что мы привыкли считать технической архитектурой, т.е. описывающей компоненты и их взаимодействие, тоже имеет термин - это "тархитектура".

Давайте поделим пользователей на опытных и тех кто не любит читать FAQ

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

Я разраб, поэтому чаще всего сначала обращаюсь к документации / читаю сайт или FAQ / ищу в интернете информацию до того, как написать. Я не хочу никого отвлекать. Кроме того, часто приходится ждать ответа долго.

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

Давайте уже признаем, что есть люди, которые поискали сами и скорее всего им поможет только оператор! И бизнесу желательно с этим считаться... А вы как думаете?

Типичные ошибки при сборе требований в условиях цейтнота:

• Сразу прыгать в детали и терять суть проблемы.

• Собирать «всё подряд» вместо приоритизации.

• Не договариваться о критериях успеха с заказчиком.

• Документировать так, что разработка всё равно задаёт десятки уточняющих вопросов.

  Знакомо?

На бесплатном вебинаре «Методы сбора требований в условиях ограниченного времени» расскажем, как избежать этих ловушек и работать быстро, но результативно:

• разберём техники для экспресс-анализа,

• поделимся инструментами быстрой фасилитации встреч,

• научим фиксировать требования так, чтобы их можно было сразу отдавать в разработку.

• Дата: 11 сентября

• Время: 15:00–16:00 (Мск)

Будет полезно:

• бизнес-аналитикам,

• системным аналитикам,

• техлидам.

👉 Регистрируйтесь и узнайте, как собирать требования под жёстким дедлайном без потери качества!

Только синие и серые блоки в "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!"

Теперь об этом явно на главной странице https://c4model.com

Продолжаем набор специалистов в ИТ-команду SSP SOFT

Привет Хабр! Уже конец лета и не пора ли серьезнее подумать о новой работе — а мы продолжаем нанимать. Предлагаем реальные задачи, прокачку скиллов и бенефиты «в рынке». Никакой бюрократии и скуки — мы нацелены на то, чтобы вы получали удовлетворение от работы.

✔️ Гарантируем интересные задачи
✔️ Для каждого нового сотрудника есть наставник
✔️ Центр компетенций помогает прокачивать навыки
✔️ С нами ты можешь работать из любой точки мира
✔️ Для экстравертов у нас есть офисы в Москве и Томске
✔️ Оптимальный Work Life Balance
✔️ ДМС со стоматологией, обучение от компании и бонусная программа.

📢 На этой неделе мы ищем (см. ссылки на описание вакансий у каждой позиции):

1️⃣ Ритейл-аналитика (http://vk.cc/cOMUS1)
2️⃣ Аналитика DWH (http://vk.cc/cOMUTJ)
3️⃣ Аналитика 1С (http://vk.cc/cOMUVn)
4️⃣ Тестировщика 1C (http://vk.cc/cOMUXx)
5️⃣ QA Auto Java (http://vk.cc/cOMUYQ)

👉 Не обязательно откликаться через hh — присылайте резюме напрямую нашему HR в Telegram: @sspsoft или на почту: job@ssp-soft.com.
Не забудьте сопроводительное письмо с фразой «Нашел вас на Хабр», чтобы резюме рассмотрели по-возможности быстрее.

Ждем вас в команду SSP SOFT!

Почему ваша архитектура ломается? Спросите у того, кто чинил десятки таких систем!

04.09.2025 в 15:00 (Мск) приглашаем на первую открытую AMA-сессию «Спроси меня о чем угодно» с Дмитрием Овчаренко — техническим директором департамента «Разработка для финансового сектора» IBS и экспертом Учебного центра IBS по архитектуре ПО.

Что вас ждёт (и почему это не обычный вебинар):

✔️ Без воды — только честные ответы на ваши вопросы (даже на те, о которых стыдно спросить).

✔️ Разбор реальных косяков — как ломались системы и что с этим делали.

✔️ Карьерный лифт — что нужно, чтобы перейти из разработчика в архитекторы?

А еще конкурс: 

Пришлите самый нестандартный, забавный или абсурдный вопрос в комментариях к этому посту. Автор лучшего получит приз!

Кому полезно?

➕ Разработчикам, которые хотят расти до архитекторов.

➕ Аналитикам, уставшим от абстрактных советов.

➕ Всем, кому интересно, как устроена «кухня» fintech.

➡️ Зарегистрироваться ⬅️

P.S. Такого у нас еще не было — будет жарко! 🔥

Новая версия Gramax!

Приглашаем вас протестировать экспериментальные функции:

• 💡  Статический сайт в облаке Gramax. Можно опубликовать свою документацию буквально за пару кликов, для этого не нужен сервер или хостинг. Достаточно нажать «Опубликовать в облако» и войти в почтовый аккаунт.

• 💡  Фильтр по содержимому. В каталоге можно создавать статьи и абзацы для разных сборок. На портале для чтения они будут фильтроваться с помощью переключателя. 

• 💡  Браузерная версия на мобильном. Браузерную версию Gramax можно использовать на мобильном телефоне. Доступны все действия, как при работе на компьютере.

А также:

• 📌  Новая главная страница. Улучшили внешний вид главной страницы. Добавили возможность создавать вложенные группы.

• 📌 Транскрипция речи с помощью ИИ. Если в пространстве включены ИИ-функции, редактор может автоматически транскрибировать аудиозаписи в текст.

• 📌 Просмотр изменений после синхронизации. После синхронизации автоматически открывается окно сравнения ревизий: сравнивается новая версия каталога с версией до синхронизации.
  

Об этих и других изменениях читайте в Release Notes 🔥

Обновляем список актуальных вакансий в SSP SOFT

Напомним, кто мы: компания SSP SOFT занимается заказной разработкой и IT-аутсорсингом. Наши спецы помогают внешним клиентам реализовывать задачи в e-commerce, финтехе, медтехе, управлении инфраструктурой и других отраслях.

Рабочие места в офисах в Москве (отличная локация в ЦАО) и в Томске, а также у нас много сотрудников, которые работают удаленно из разных регионов России. Формат «онлайн» или «оффлайн» обсуждаем.

📢 Кого мы сейчас приглашаем (это описание вакансий в hh, а ниже прямые контакты с нашим HR для быстрого отклика):

1️⃣ Разработчика и аналитика 1C
2️⃣ Разработчика Angular
3️⃣ Middle Java Developer
4️⃣ Системного аналитика
5️⃣ Бизнес-аналитика

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

🎁 Наши бонусы: ДМС со стоматологией, обучение за счет компании, бонусная программа.

👉 В SSP SOFT мы рассматриваем найм не как «закрытие вакансии», а как включение нового человека в команду — с вниманием к развитию и прицелом на долгосрочную совместную работу.

Пишите с резюме нашему HR в Telegram: @sspsoft
Или присылайте резюме на почту: job@ssp-soft.com.

Всегда актуальные вакансии на https://hh.ru/employer/5648224:

📍 Мы открыты к диалогу и ценим честные и профессиональные резюме (без накруток опыта).

Как мы ускорили проверку документации с помощью AI-агента: от боли к решению

Привет, Хабр! Я — Мила Муромцева, системный аналитик в Альфа-Банке. Эту статью мы подготовили вместе с нашим разработчиком Мишей Буториным. Написали ее, чтобы поделиться нашим опытом и рассказать, как мы научили LLM проверять документацию для платформы Альфа-Онлайн — переписывали стандарт, боролись с токенами и немного с хаосом.

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

Статья «Как мы ускорили проверку документации с помощью AI-агента: от боли к решению» будет полезна тем, кто автоматизирует проверки, работает с большими данными и хочет, чтобы нейросети давали точные и надёжные ответы — даже при работе с очень громоздкой документацией. Внутри разбираем кейс командной интеграции LLM: от первых ошибок до финального формата отчета, который реально экономит токены и нервы!

🔥 Монолитный фронтенд тормозит ваш проект? Пора задуматься о микрофронтендах!

Если разработка кажется бесконечной, внедрение фич превращается в квест, а код стал клубком из зависимостей — вы не одни. Мы знаем эту боль не понаслышке!

Наш новый вебинар «Архитектурный перелом: что делать, когда фронтенд трещит по швам» — это честный разговор о реальном пути перехода от монолитного фронтенда к микрофронтендам. Никакой воды, только реальный опыт: когда сложность системы достигла критической точки, мы решились на глобальные перемены.

📅 Дата: 14.08.2025

⏰ Время: 17:00-18:00 (Мск)

👨‍🎓 Спикер: Акманова Елизавета — старший аналитик ГК «Юзтех», преподаватель школы системного анализа.

Что будет на эфире?

✔️ Разберем объективные причины, которые подтолкнули нас к смене архитектуры.

✔️ Реальные плюсы и минусы микрофронтендов.

✔️ Практические кейсы, неочевидные вызовы и решения.

✔️ Честные выводы и советы, чтобы ваш переход был максимально гладким.

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

Почему одиночкам тяжело расти? Как мы организовали сообщество системных аналитиков и что из этого вышло

В IT слишком часто «каждый варится в своём соку» — и специалисты теряют темп, а команда не получает новых идей.

Какие шаги помогли объединить экспертов из разных проектов, даже если зона ответственности не совпадает? Как совместные обсуждения, обмен опытом и единые подходы преобразили корпоративную культуру? Какие неожиданные инсайты и эффекты обнаружились уже через несколько месяцев — и почему это оказалось выгодно всем сторонам? Рассказываем в нашей статье «Как мы организовали сообщество системных аналитиков и что из этого вышло».

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

Ахиллесова пята патента на промышленный образец

Допустим, ваша компания что-то производит. К примеру, корпуса для серверных шкафов или детские площадки.

Скорее всего, с внешним видом изделия вы работаете в два этапа:

Первый. По вашей просьбе художник создает дизайн изделия и передает вам право на получение патента.

Второй. Вы получаете патент на промышленный образец и запускаете изделие в работу.

Вам кажется, что все законно.

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

Возникают два вопроса:

1. Возможны ли ситуации, когда у дизайна изделия появляется еще один автор?

2. Защищает ли вас патент на промышленный образец от притязаний "нового" автора?

Ответ на первый вопрос: да, такие ситуации возможны.

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

В этом случае на свет появляется соавтор вашего дизайна. Он не давал вам разрешение на получение патента и защищает свои интеллектуальные права.

Другой пример. Ваш дизайнер фактически ничего не создавал: он подсмотрел внешний вид изделия в интернете и выдал его за свой труд.

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

Ответ на второй вопрос: в описанной ситуации промышленный образец вас не защищает.

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

Разные правовые режимы не заходят на половину друг друга.

В примере выше налицо авторское право. Вы будете отбиваться от претензии, используя главу 70 Гражданского кодекса РФ.

Важно! Разборки с подателем претензии сами по себе не повлекут аннулирование вашего патента.

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

Попадались ли вам в интернете картинки, похожие на дизайн ваших изделий?

Говорим на языке событий: что даёт ивент-шторминг и как его правильно провести

Привет! Я Иван Чернов, системный архитектор, в этом посте расскажу про ивент-шторминг.

В Островке есть набор сервисов, который разбит на логические блоки так, чтобы в рамках блока можно было итерировать: Островок, Островок B2B и Островок Командировки. При этом запускать новые фичи, которые будут сквозь эти слои прорезаться. 

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

Что это за практика? На встрече с одной стороны сажаем бизнес, с другой — разработку. Просим бизнес рассказать, что и как он делает в работе с клиентом.

Ивент-шторминг проводится с фокусом на цикличную реактивность: происходит событие, которое визуально меняет что-то для пользователя, тот принимает решение и отдаёт команду, команда приводит к новому событию.

На этих циклах фокусируемся на доске в Miro во время встречи. 

В ивент-шторминге 3 этапа: 

1. Сейлзы выстраивают по циклам цепочку событий: от «клиента у нас ещё нет» до «клиент нас окончательно покинул». Даже в простых цепочках 20–30 действий. В готовом таймлайне есть happy pass: клиент успешно прошёл весь путь. И альтернативные пути: что-то пошло не так.

2. Проходим по таймлайну с конца, ищем ошибки. Выделяем ключевые события, которые нельзя откатить: клиент зарегистрировался, совершил бронирование, провёл оплату. Здесь происходит стык сервисов. На стыках обогащаем цепочку. Пишем, кто и что делает: актор-клиент зарегистрировался, подключился сервис юзер-менеджмента. 

3. Выявляем, какие агрегаты работают с событием. Мапим команды: клиент регистрируется, в работе участвует команда регистрации. 

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

Во время встречи составляем словарик. Если сейлз говорит непонятное разработчикам слово — мы его добавляем в словарь, и оно просасывается в наш интерфейс и кодовую базу. Всё это учит разработчиков понимать, на какие рычажки они влияют своим кодом. 

Поделюсь советами, как круто провести ивент-шторминг.

Онлайн-формат

● Для проведения онлайн достаточно доски в Miro.

● Разбивайте встречу на три части, каждая встреча — один этап.

● На последней встрече отпустите бизнес, выявите агрегаты и сервисы, задействованные в таймлайне с разработкой.

● Максимум людей для успешной фасилитации онлайн — 8–10 человек.

Подбор людей и подготовка

● Соотношение участников: 70% бизнеса, 30% разработки.

● Ищите представителей бизнеса в оргчате выбранного домена: спрашивайте у руководства, «кто тут самый инициативный».

● Вам нужны работники «с полей», которые лучше всего шарят в процессах, и тимлиды первого уровня.

● Берите людей из разных направлений домена. 

● Бизнес-участники должны понимать: ивент-шторминг — процесс обучения, они эксперты, а разработка — ученики. Им нужно говорить на своём языке, а не подстраиваться под разработку.

● Дайте участникам базовый словарь. Четыре самых важных слова: актор, команда, событие, термин.

● Важны вводные по времени и цели: на сессию уйдёт суммарно 6–8 часов, она даст единое понимание процессов.

Фасилитация

● На старте не бойтесь повторить все вводные.

● Дайте сейлзсам 10 минут на то, чтобы каждый выстроил индивидуальный таймлайн, дальше начинайте мёржить таймлайны с общим обсуждением.

● Событие — факт в прошедшем времени, его не отмотать. Следите, чтобы так и записывали. 

● Первым делом простройте happy pass, иначе у вас не выстроится цельное видение процесса. Альтернативные ветки обозначьте на первом этапе, а достраивайте на втором, проверяя таймлайн с конца.

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

● Организуйте пост-процессинг: важно передать разработке результаты, объяснить, какие процессы у нас уже верно реализованы, а где нужно обновление и дополнительное внедрение.

Что такое архитектура ПО и почему она не про красивые диаграммы

🏗️ Архитектура программного обеспечения — это не просто модное слово для повышения ставки на собеседовании. Это фундамент, на котором строится вся система.

Что это такое на самом деле?
Архитектура ПО — это структура компонентов системы, их взаимосвязи, взаимодействия с внешней средой и принципы разработки. Звучит скучно? А вот и нет! Это как план города: без него у вас получится не Москва, а какая-то деревня Гадюкино с кривыми улочками.

Зачем это нужно?

• Снижает сложность системы через декомпозицию

• Определяет рамки развития (чтобы не росло как раковая опухоль)

• Помогает команде говорить на одном языке

• Экономит нервы и деньги в долгосрочной перспективе

Под капотом архитектура отвечает за:
✅ Разбиение системы на модули (как 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 года мы усиливаем несколько ключевых направлений. Если вы уверенно чувствуете себя как профи, цените системный подход и хотите работать в зрелой команде — присоединяйтесь.

Актуальные вакансии на https://hh.ru/employer/5648224, а прямая ссылка на контакт с нашим HR отделом ниже:

Аналитика и системный анализ
• Аналитик 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️⃣ Подключение к серьезным задачам — когда вы полностью готовы.

Пишите нашему HR в Telegram: @sspsoft
Или присылайте резюме на почту: job@ssp-soft.com.

📍 Мы открыты к диалогу и ценим честные и профессиональные резюме (без накруток опыта) с вами как потенциальными коллегами.