Вернусь опять к рынку труда на базе ежемесячного отчета Краткий обзор рынка труда за июнь 2025 от ХХ.
Основное:
🟣 hh индекс снизился на одну десятую и теперь составляет 5.5 (соотношение количества активных резюме к количеству активных вакансий)
🟣 Среднее число активных вакансий снизилось еще на 2% и составляло в июне 27% к уровню предыдущего года, а среднее число активных резюме составило 27%
🟣 Среднее число активных вакансий увеличилось на 4%, а резюме на 1% по сравнению с маем

По ритейлу и по ИТ, имеем:
📌 В ритейле сохраняется острый дефицит кадров ( hh индекс показывает 1.8)
📌 В ИТ дефицит вакансий немного уменьшился, но не значительно (hh индекс 12.5 против 12.8 в прошлом месяце)
📌 Число вакансий в ИТ уменьшилось на 31% по сравнению с маем прошлого года
📌 Число соискателей увеличилось на 28% за тот же период
📌 Число соискателей и число вакансий в ИТ практически не изменилось по сравнению с маем 2025 года. Вакансии увеличились на 1%, а соискатели уменьшились на тот же 1%.

Зона турбулентности не пройдена и непонятно, где и когда она закончится. Пока "идем по приборам". Многие компании на рынке начали серьезные преобразования своего ИТ ландшафта, меняя команды, подходы, открывая и закрывая проекты, что добавляет движа на рынке. По моим наблюдениям - аппетиты соискателей начали снижаться, становится более адекватными. Важно - серьезного спеца за три копейки не купить, но и космических требований уже не будет.
#подбор #разработка #development #управление #HR #development #рыноктруда #войтивит

Недавно в комментариях упоминали такой вид систем, как Self Contained System (SCS). Зачастую их даже путают с микросервисами. Давайте повнимательнее посмотрим на этот класс систем и разберемся, зачем они нужны и где их применять.

SCS - это подход, при котором большая система делится на независимые, автономные модули, каждый из которых:
✔️ полностью отвечает за конкретную бизнес-функцию
✔️ имеет собственную UI, логику, базу данных
✔️ не зависит от других модулей во время выполнения
Каждая такая система может разрабатываться и разворачиваться самостоятельно, а зачастую даже разными командами.

На понятийном уровне - SCS может быть микросервисом (в плане предоставления API для функционирования других частей ИТ ландшафта), но микросервис в "чистом" виде не является SCS.

Из преимуществ SCS:
📌 Изоляция: каждый SCS работает максимально независимо. Проще разворачивать и обновлять
📌 Целостность: одна команда отвечает полностью за весь "колодец" - фронт, бэк, БД
📌 Простота: нет нужды в сложной оркестрации, как в микросервисах

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

Подход Self Сontained Systems не является заменой микросервисного подхода, скорее он органично дополняет его и предоставляет альтернативу, в случае нехватки времени или компетенций. Очевидно, что разделив огромный легаси монолит на SCS можно идти дальше и уже разваливать SCS на микросервисы. А можно и не идти, а построить масштабируемую, автономную архитектуру на SCS, сохранив при этом относительную простоту. Уж лучше несколько самодостаточных SCS систем, чем десятки плохо спроектированных микросервисов.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны

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

🟣 Ежедневно по всему миру происходит более 2200 кибератак
🟣 Число кибератак в мире выросло на 30% по сравнению с прошлым годом
🟣 1636 организаций еженедельно подвергаются кибератакам
🟣 Наибольшее количество атак приходится на образовательные организации и исследовательские центры: в неделю регистрируется 3341 инцидент
🟣 Больше всего атак на организации было зафиксировано в Африке - в среднем 2960 в неделю
🟣 Абсолютным лидером среди кибератак стали атаки шифровальщиков - 68% всех атак.
🟣 Лидером по числу атак с использованием шифровальщиков стал производственный сектор, на долю которого пришлось 29% инцидентов
🟣 Расходы на киберстрахование выросли на 28%.

Вроде выглядит неприятно, но мы же любим большие цифры. А если посмотреть по-другому - 2200 кибератак в день значит, что каждые 39 секунд в мире происходит одна атака. С этой стороны смотреть гораздо веселее.

По фишингу:
🔵 Фишинг отвечает примерно за 22 % всех утечек данных
🔵 Почти 83 % компаний сталкивались с фишинг-атаками
🔵 3,4 млрд фишинговых писем рассылается ежедневно — это 1,2 % от всех отправляемых ежедневно e-mail
🔵 90 % всех кибератак начинаются с фишинга

Повышается осведомленность о киберугрозах. А раз повышается осведомленность, то все идут защищаться. Инвестиции в кибербез растут. И к 2030 году объем мирового рынка кибербеза превысит 500 млрд вечнозеленых, хотя еще в 2022 году он не дотягивал до 300.

В общем киберугрозы в 2025 году стали масштабнее, агрессивнее и разнообразнее. Каждую минуту кого-то атакуют. Для нас это значит, что защита инфраструктуры, повышение киберграмотности и внедрение стратегий безопасности должны стать приоритетом для любой организации, вне зависимости от масштаба и отрасли.
#итбезопасность #кибербезопасность #ИТбез #разработка

Поговорим сегодня про абстрактные требования. Не знаю как у вас, а у меня уже даже глаз перестал дергаться на требования типа: "Система должна быть быстрой", "Производительность должна быть высокой" или "Пользователь не должен долго ждать". К сожалению, все еще многие люди именно так формулируют "требования". Почему требования в кавычках? Да потому, что это ни разу не требования, а надежда на то, что "все будет хорошо" или "все будет работать как-то нормально". А в инженерии надежды не работают. Работают конкретные метрики.

Чтобы метрики стали конкретными, зачастую надо проявить занудство и педантичность сотого уровня. Но не всем хватает на это терпения и в команды уходит что-то непонятное. Из моего опыта - минимум 50% всех проблем не случилась бы, если бы требования были сформулированы четко и измеримо. Потому что быстро - для каждого по разному. Одному это 10 секунд, другому - 2, а третьему 200 мс.

Что получается, когда конкретных требований нет:
✅ Разработчик все делает "на глаз"
✅ Тестировщик считает, что все так и было задумано
✅ Бизнес вообще и продакт в частности считает, что "все будет летать"
✅ А CTO на совете директоров рассказывает, почему в пике Черной пятницы весь еком лежал лицом вниз

Как может выглядеть нормальное требование: 95% запросов к /api/search должны обрабатываться не дольше 700 мс при нагрузке до 1500 RPS (все цифры условны, а совпадения - случайны).
Указаны:
🟡 Конкретный сервис или бизнес-операция (/api/search)
🟡 Целевой перцентиль (95% успеха или 5% неуспеха)
🟡 Пороговое время отклика (700 мс)
🟡 Пороговая нагрузка (1500 RPS)

И тут уже понятно, как разрабатывать и как тестить. Ну и неприятная для бизнеса история - сколько это все будет стоить. Но зато в проде у вас будет система удовлетворяющая бизнес, а не слепая вера в чудо, что "все будет быстро". Если требование нельзя замерить, то оно не имеет смыла.
#development #впоискахсеребрянойпули #антипаттерны #CX #услышановкулурах #мнения

Начнем эту неделю с открытия ящика Пандоры и развязывания холивара на тему Agile. Для тех, кто не помнит или не знает несмотря на то, что последние лет 10 я работаю по гибким методологиям разработки, я не являюсь фанатичным их сторонником. Просто я работаю в таких сферах, где их применение более чем оправдано. Я отношусь к Agile, как к специализированному инструменту, необходимому в одних случаях и не применимому в других. Как и к водопаду и к другим методикам разработки.

Наткнулся в каналах в телеграме на посты (один и второй), посвященные "смерти Agile"

На последней конференции AgileDays один из отцов-распространителей Agile в России Асхат Уразбаев выступил с провокационным докладом "Аджайл умер! Да здравствует пост-аджайл!". Видео пока не выложено, но презентацию можно посмотреть.

Если свести тезисы из презентации и постов, то получаем:
📌 ИИ и современный технологический стек делают Agile... Устаревшим
📌 Если у вас зрелые инженеры, способные думать продуктово, то ежедневные стендапы, покерная оценка и ведение бэклогов начинают тормозить получение результата
📌 Scrum-мастера и Agile-коучи идут под сокращения первыми
📌 На уровне команд фокус смещается с T2M на производительность
📌 Сдвиг в асинхронный формат работы (меньше встреч, документация вместо обсуждений, работа в удобное время)
📌 Использование AI
📌 Подход "Просто делай и выкатывай!" без формальной методологии
📌 Если вы хотите быть гибкими — не изучайте Scrum Guide, а научитесь мыслить через цели OKR

Я когда первый раз прочитал все это, реально начал искать сноску на "Вредные советы". Потому, что более действенного способа разрушить разработку - не существует. Конечно, если мы говорим про стартап, в котором работает 10 человек, то все это может и взлетит. А вот когда мы говорим про ИТ производство в серьезной коммерческой организации - подход типа "Просто делай и выкатывай!" может закончиться печально.

"Зрелые инженеры" - тоже хорошо, но где же их взять? На рынке джуны или "волчары". Отказ от бэклога - супер, но как работать с задачами и приоритетами? Покерная оценка - да 80% рынка и так планирует в человеко-часах. Покер то можно выбросить, а вот оценку - не уверен. AI - это инструмент, который может помочь, а может и загубить. Работа в удобное время - вообще огонь, даже через документацию синхронизация будет занимать века. Scrum-мастера и Agile-коучи не нужны - так это и не должность, а роль, которую могут выполнять члены команд.

В общем непонятный движ, можно было бы подумать, но если присмотреться, то можно заметить то, что ребята пытаются продавать что-то еще. Например OKR. Судя по всему, Agile и Scrum уже не продается, а кушать хочется. Вот и приходится хайпить…
#разработка #цифроваятранформация #agile #development #продуктоваяразработка #впоискахсеребрянойпули

В чем различие между опытными ИТ-директорами и новичками? И те и те наступают на грабли, но первые делают это уже на профессиональном уровне 🥋😅

Каждый бывалый солдат знает, что любое минное поле — это всего лишь дело техники и небольшой доли удачи. Взять хотя бы MDM-проекты. На первый взгляд - ну что может быть проще, взял и внедрил, залил данные и пользуйся. А вот и нет. Я этот путь проходил трижды. При этом два из них - в одной и той же компании. Вот уж где полегло много бравых директоров и экспертов! Почему? Давайте разбираться и по пути подбирать разбросанные грабли.

Топ ошибок при внедрении MDM системы:
🕺Начать внедрять MDM потому что СД услышал это слово на модной конфе
🐙Верить во всемогущество MDM при работе (сама всё почистит, соберет данные, структурирует и еще кофе заварит)
👊🏻Выдать палки и бросить специалистов ИТ-отдела одних разбираться с системой
💾Выбрать стиль интеграции и архитектуру, которую друг Серега посоветовал

Разобрали с DTT, какие бомбы замедленного действия запрятаны в MDM-проекте и как их дезактивировать.

Загибайте пальцы те, кто уже успел напороться☝️
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны

"Не успел закончится первый круг, как сразу начался второй…." И снова к рынку труда на базе ежемесячного отчета Краткий обзор рынка труда за июль 2025 от ХХ.
Основное:
🟡 hh индекс повысился на пол пункта до 6 (соотношение количества активных резюме к количеству активных вакансий) - до абсолютного минимума за последние 5 лет в 3.4 - еще далеко, а вот до абсолютного максимума в 6,9 гораздо ближе.
🟡 Среднее число активных вакансий и активных резюме в июле осталось на уровне июня - 27% к уровню предыдущего года
🟡 Среднее число активных вакансий не увеличилось, а количество резюме увеличилось на 9% по сравнению с июнем

По ритейлу и по ИТ, имеем:
🔵 В ритейле сохраняется острый дефицит кадров, хотя чуть-чуть подотпустило ( hh индекс показывает 2 вместо 1.8 в прошлом месяце)
🔵 В ИТ дефицит вакансий опять бьет рекорды (hh индекс 13.7 против 12.5 в прошлом месяце)
🔵 Число вакансий в ИТ уменьшилось на 34% по сравнению с июлем прошлого года
🔵 Число соискателей увеличилось на 28% за тот-же период
🔵 Число соискателей в ИТ увеличилось на 6%, а количество вакансий уменьшилось на 3% по сравнению с июнем этого года

Количество соискателей медленно, но верно растет, чего нельзя сказать про количество вакансий. Если по приколу, то мы скоро дойдем до уровня 2020 года на пике пандемии и самоизоляции. Делаем выводы и затягиваем пояса…
Есть надежда на осеннее оживление рынка труда, что компании выйдут из отпусков и откроют поиск, но это не точно….
#подбор #разработка #development #управление #HR #development #рыноктруда #войтивит

В последние годы накал страстей вокруг микросервисов поутих, но тем не менее они продолжают восприниматься как единственно прогрессивное решение для тех, кто хочет двигаться по пути прогресса. А "неудачникам" остается монолит и легаси.

В реальности все выглядит немного иначе. Несмотря на то, что есть на рынке компании (я сейчас не беру в расчет технологических гигантов) у которых получилось, многие компании наломали немало дров и потеряли немало денег на пути в микросервисы. Давайте разбираться, почему так произошло и что было не учтено:

1️⃣ Высокая операционная сложность и накладные расходы (overhead). Вы платите значительным увеличением сложности инфраструктуры и эксплуатации за гибкость разработки:
🟡 DevOps/Platform Engineering: жизненным циклом сервисов надо управлять, что требует соответствующих недешевых специалистов, плюс поддержание самой платформы тоже требует ресурс
🟡 Мониторинг и логирование: одним лог-файлом уже не обойтись и поэтому необходимы сложные системы централизованного сбора логов и распределенного
🟡 Сетевое взаимодействие: в распределенной системе появляются проблемы задержек, надежности сети, необходимости реализовывать механизмы устойчивости, что добавляет сложности как в код, так и в инфраструктуру

2️⃣ Сложность разработки и отладки. Разработка и отладка замедляется из-за проблем, присущих распределенным системам:
🟡 Согласованность данных: обеспечить согласованность данных (ACID-транзакции) в распределенных сервисах практически невозможно, поэтому надо использовать сложные паттерны (SAGA, двухфазный коммит), которые могут быть источниками ошибок
🟡 Сетевая надежность: разработчики должны постоянно помнить, что любой вызов между сервисами может завершиться неудачей и писать код, устойчивый к сетевым сбоям
🟡 Сложная отладка: без продвинутых инструментов трейсинга отладка будет невозможна или будет похожа на поиск иголки в стоге сена
🟡 Межсервисные контракты: без строгого контроля версионности API любое изменение может привести к неработоспособности

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

Ни одна система не улучшает качество данных, попадающих в нее…
Еще в 1957 году в статье об американских военных математиках и их работе с компьютерами прозвучало:

…небрежно запрограммированные входные данные неизбежно приведут к неверным выводам…

Так появился принцип GIGO (Garbage In - Garbage Out). Внедрение MDM системы тоже не поможет, если в компании не реализованы процессы работы с Master Data или проще - Нормативно Справочной информацией (НСИ). Ошибки здесь могут стоить дорого:
✖️ пересортица и простои на производстве/складах/магазинах
✖️ срывы поставок
✖️ путаница в отчетности
✖️ миллионные потери

Все компании проходят этот путь по разному, собирая различные проблемы и набивая свои собственные шишки. Коллеги подготовили встречу экспертов, которые уже проходили этот путь. На встрече 10 сентября в 10:00 они поделятся тем, что сами хотели бы услышать 1–3–5 лет назад:
✅ какие проблемы с НСИ сильнее всего бьют по бизнесу
✅ как меняется подход к управлению данными на разных этапах
✅ какие роли в проекте действительно незаменимы
✅ как оценить окупаемость и не потратить годы впустую
Присоединяйтесь, чтобы получить ответы на ваши вопросы.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны

Вспомнилась мне недавно история пятнадцатилетней давности об ожиданиях бизнеса от ИТ и о методах взаимодействия.

Дано - в крупной компании есть склад, на складе есть WMS система, которую вендор снял с поддержки и развития и ее надо менять. Обсуждаем с бизнесом - они готовы, главным по "тарелочкам" т.е. бизнес процессам на складе назначается директор логистического комплекса. Просим его сформулировать в письменном виде потребности, чтобы начать работу, а в ответ получаем - "…я знаю есть такие люди - бизнес-аналитики, вот пусть они придут ко мне, я им буду рассказывать, а они запишут…". Немая сцена, Гоголь.

Не спорю, что формирование бизнес-требований и проведение интервью является частью работы аналитика, но аналитик - не стенографист "потока сознания" бизнес-пользователя. Попробую объяснить, что происходит, если бизнес не структурирует свои пожелания:
🖇 Размывание ответственности. Ставьте лайк, кто сталкивался с "мы не так говорили", "аналитик неправильно понял" и хит сезона - "мы думали это будет работать по-другому"
🖇 Аналитик не всегда обладает глубокими знаниями в предметной области и может не акцентироваться на действительно важных вещах, которые очевидны для бизнеса
🖇 Скорость обработки неструктурированной информации - затягивание сроков проекта
🖇 Отслеживание изменений - нет изначального документа - нет точки отсчета, есть вероятность попасть в хаос. Ну и смотри пункт первый про размывание ответственности

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

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

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

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

Есть один тренд, который я наблюдаю в профессии аналитиков в последние 10-15 лет - это постепенное сращивание функций бизнес-аналитика и системного аналитика с появлением такого персонажа как фул-стек аналитик. Бизнес уже научился формулировать требования в удобоваримом виде, а разработчики уже не просто кодеры и не требуют детальной инструкции без вариаций вправо и влево. Это дает возможность одному аналитику закрыть промежуток между бизнесом и разработкой, т.е. происходит диффузия. Если в команде один фул-стек аналитик, то при увеличении нагрузки есть два варианта дальнейшего масштабирования - взять второго фул-стека или взять второго аналитика и разделить между ними обязанности - кто будет БА, а кто - СА.

Забавно, что какого-то стандарта в области анализа нет - каждая компания видит эту зону ответственности по-своему. Открытием для меня стало то, что даже в больших и технологических компаниях зачастую роль аналитика - вырождена. Т.е. эта роль выполняется 50/50 продактом и тим или тех лидом. Такой подход тоже имеет право на существование, но странен для меня - я приверженец подхода "Нету ТЗ, в результате - ХЗ"
#разработка #впоискахсеребрянойпули #антипаттерны #development #анализ

Тема сегодняшнего поста - Cloud Native. Давайте разбираться, что это за зверь и с чем его едят. Cloud Native это подход к проектированию, разработке и управлению работой приложений, который встроен в облака и использует все преимущества облачных вычислений. По определению Cloud Native Computing Foundation (CNCF):

Cloud native технологии позволяют организациям создавать и запускать масштабируемые приложения в современных динамических средах, таких как публичные, частные и гибридные облака. Это включает контейнеры, service meshes, мультитенанты, микросервисы, неизменяемая инфраструктура и декларативный API но не ограничивается этим.

Из чего состоит Cloud Native:
✅ Контейнеры, в которые упаковывают приложения или сервисы со всеми зависимостями, чтобы исполнять одинаково в любой среде
✅ Оркестраторы - автоматизирующие запуск, масштабирование и поддержание работоспособности контейнеров
✅ Service Mesh - инструмент, контролирующий и управляющий взаимодействием между микросервисами, обеспечивающий надёжную, безопасную и управляемую коммуникацию между сервисами
✅ Immutable Infrastructure - гарантирует неизменность инфраструктуры при разворачивании, повышает надежность и предсказуемость
✅ Инфраструктура как код или IaS - описание целевого состояния системы в виде конфигурации, чтобы инфраструктура сама приводилась к этому состоянию

Понятно, что описанное выше это ничтожная толика того, что включается в понятие Cloud Native. Но и этого уже достаточно, чтобы понимать, что если "вкрячить" монолит в облако и даже если он будет работать, то он не станет автоматически Cloud Native. Работать он будет, но не всегда оптимально по ресурсам или скоростям или…….
Если вам интересна карта ландшафта Cloud Native, подготовленная CNCF, то смотреть можно здесь.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны

Вот наткнулся на занятную статью на тему ИИ. Оказывается, многие разработчики в Штатах сейчас… активно "притворяются", что используют ИИ в работе - такая вот массовая "имитация оргазма" при работе с ИИ.

Цифры, которые приводятся, просто фееричны. Согласно опросу, проведённому среди работников интеллектуального труда:
🟡 Каждый шестой тех-специалист признаётся, что имитирует использование ИИ - инструментов
🟡 Опасения вызывают как сами ИИ (способные потенциально заменить человека), так и люди, их использующие (как более продуктивные)
🟡 Причина имитации - показать следование тренду, не казаться "застрявшим в прошлом" и чтобы сохранить свои позиции

А дальше - серьёзнее. Руководители прямо заявляют, что "они с большей вероятностью уволят разработчика, который не использует ИИ, в пользу того, кто его использует". Жёсткая, но вполне себе рыночная логика. Так что да, игнорировать тренд становится опасно для карьеры. Таким темпом мы скоро придем к тому, что вопрос использования ИИ станет не столько вопросом эффективности, сколько базовой профессиональной гигиены и соответствия рынку.

Пока мне видится, что все "спекуляции" вокруг ИИ говорят только о факте его использования, но пока реальная глубина и эффективность зачастую остаются за кадром или как минимум, преувеличиваются. Поэтому спешить хоронить человеческий мозг, на мой взгляд, слегка рановато. Пока что именно он - со своим критическим мышлением, креативностью и способностью видеть продукт в целом лидирует в этом тандеме. ИИ - супер, мега, гига мощный помощник, но главным зодчим пока являемся мы.
#мнения #AI #ChatGPT #чтотампроchatgpt #data #данные

Архитектурные дороги, которые мы выбираем (почти по О.Генри). Сегодня попробую сформировать "шпаргалку" для начинающих, которая может помочь двинуться по пути от монолита к микросервисам и далее.

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

6️⃣ Монолит (опенспейс или казарма) - все живут в одном общем помещении, говорят одновременно, если все сгрудились в коридоре, то никто уже пройти не сможет. Масштабировать монолит можно только целиком.
2️⃣ Микросервисный монолит (коммунальная квартира) - комнаты уже появились, но стены тонкие и есть места общего пользования. Это хитрый переходный этап. Команды учатся работать автономно и пишут код так, как будто у них уже есть микросервисы , но технически всё ещё работает как один большой монолит (например, есть общая база данных). Рискованный этап, но необходимый для перехода.
3️⃣ Микросервисная архитектура (отдельные квартиры) - коммуналку расселили по отдельным квартирам, но семьи активно общаются друг с другом в домовом чате. Вот здесь происходит настоящее разделение. Каждый логический блок (например, "платежи", "поиск", "корзина") становится независимым сервисом (микросервисом). У каждого своя база данных и своя зона ответственности.

В принципе здесь можно уже и остановится. Такая архитектура позволяет быстро и эффективно решать задачи. Но есть проблема - такая архитектура хорошо понятна ИТшникам , но непонятна бизнесу, который не до конца понимает, что он получает от 100500 микросервисов и как из них можно сделать новый продукт. Поэтому можно пойти дальше.

4️⃣ Бизнес сервисы и их оркестрация (город) - это тоже микросервисы, но уже сгруппированные не по техническим функциям, а вокруг бизнес-задач (Business Capabilities). Поскольку каждый сервис дает возможность решать бизнес-задачу полностью, то их можно объединять в сложные последовательности с помощью оркестраторов, роль которых могут играть BPM движки. Можно настраивать сложные сценарии и быстро создавать новые последовательности.

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

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

Я не буду говорить про истории успеха, о компаниях, которые действительно трансформировались, глубоко изменили свою бизнес-модель, процессы и корпоративную культуру, тут все очевидно и можно только снять шляпу. Поговорим про тех, кто на волне "первомая" кинулся трансформироваться. Для очень многих история цифровой трансформации это попытка построить роскошный небоскреб на фундаменте от старого дедовского сарая. Да, облака, большие данные, цифровые двойники и интернет вещей - это круто, стильно, модно и молодежно. Но! Если бухгалтерия до сих пор сидит наполовину в Excel, а Биг Дата используется для того, чтобы выгрузить отчет, который потом финансисты докручивают руками, то грош цена такой трансформации.

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

Как по мне все состоит из трех шагов:
1️⃣ Автоматизация рутины, наведение порядка в данных и процессах. Базовых процессах, смею заметить.
2️⃣ Цифровизация. А именно - перевод аналоговых данных и процессов в цифровой вид.
3️⃣ Цифровая трансформация - как глубокое изменение бизнес-моделей, процессов и корпоративной культуры с помощью цифровых технологий. И это не быстрая победа, а долгая и сложная перестройка всего и вся в компании

Так что, прежде чем закупать нейросети, блокчейн и прочий ЖПТ, возможно, стоит для начала разобраться с тем, как у вас работает планирование, документооборот и учёт. Если сталкивались с примерами попыток "трансформироваться" без наведения базового порядка, то делитесь опытом в комментариях!
#впоискахсеребрянойпули #цифроваятранформация #agile #антипаттерны #управление

Новости рынка труда на базе ежемесячного отчета Краткий обзор рынка труда за август 2025 от ХХ.
Основное:
✔️ Спрос на сотрудников практически не изменился - hh индекс (соотношение количества активных резюме к количеству активных вакансий) повысился на одну десятую пункта и составляет теперь 6.1 против 6.0 в июле - потихонечку движемся к пандемийным максимумам 2020 года.
✔️ Среднее число активных вакансий и активных резюме в августе стабильно остается на июньском и июльском уровне - 27% к уровню предыдущего года
✔️ Среднее число активных вакансий опять не увеличилось, а количество резюме выросло на 3% по сравнению с июлем

По ритейлу и по ИТ, имеем:
📌 В ритейле сохраняется дефицит кадров, стабильно ( hh индекс показывает 2.1 вместо 2.0 в прошлом месяце)
📌 В ИТ вакансий как не было, так и нет (hh индекс уже вырос до 14.9 против 13.7 в прошлом месяце)
📌 Число вакансий в ИТ уменьшилось на 36% по сравнению с августом прошлого года, а число соискателей увеличилось на 25% за тот же период
📌 Число соискателей в ИТ увеличилось на 4%, а количество вакансий уменьшилось на те же 4% по сравнению с июлем этого года

Есть конечно слабая надежда, что сентябрь принесет перелом, т. к. наверняка откроется осеннее окно найма и переходов, что может поменять ситуацию на рынке. Но что-то мне вещует, что даже если окно найма откроется, то на общую картину это не повлияет. Скорее всего переходы и поиски будут точечными, под конкретные позиции для сильных кандидатов. Но уже скоро мы это увидим.
#подбор #разработка #development #управление #HR #development #рыноктруда #войтивит