Привет, друзья! 👋
А есть тут кто из Казахстана? 🇰🇿

Мы всерьёз задумались о проведении оффлайн-митапа в Алмате и хотим понять, есть ли у нас там местные и какой формат вам был бы интересен.

Если вы в Алмате или поблизости — очень ждём ваш голос! 🙌

PS. И если вам интересно помочь с организацией, поделиться советом или выступить на митапе — пишите Даше: @d_zherebtsova

📌 Архитектура без архитектора? Приходите обсудить!

Круглый стол для инженеров и техлидов — обсудим, где заканчивается зона ответственности разработчика и начинается архитектура. Что происходит, когда решения принимаются “де-факто”? И нужна ли вообще формальная роль архитектора?

📅 7 августа, 20:00 GMT+3
🎙 Ведущий: Антон Дворников, Principal Solution Architect
👥 Участники:
‣ Вячеслав Панасов, руководитель направления
‣ Артём Жильцов, Tech Lead в FinTech

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

На 126-м Архитектурном Трёпе обсудили текущее состояние рынка труда в IT, новые тренды в найме и использовании AI.

Вот краткая выжимка беседы:

📉 Текущая ситуация на рынке труда и тренды в найме

Рынок IT стал более конкурентным:

🔸На каждую вакансию теперь поступают сотни откликов
🔸Процессы собеседования усложнились и включают больше этапов даже в небольших компаниях
🔸Важность личного нетворкинга выросла в разы
🔸Компании используют автоматизированные системы отбора (ATS), поэтому критично включать правильные ключевые слова в резюме
🔸В Европе ужесточились языковые требования – часто обязательно владеть местным языком

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

🤖 ИИ и его влияние на разработчиков

AI уже плотно интегрирован в повседневную работу разработчиков и приносит существенные бонусы:

🔹Сильно ускоряет рутинные задачи и кодинг
🔹Ускоряет навигацию и поиск информации в больших проектах

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

Но участники выражают опасения о качестве сгенерированного кода:

Люди бездумно копируют код, сгенерированный AI, не понимая, как он работает. Это создаёт проблемы поддержки и качества продукта в долгосрочной перспективе

🛠 Новые требования к профессиональным навыкам разработчиков

🔸Высокий спрос на fullstack-специалистов с пониманием бизнеса и инфраструктуры
🔸Ценность разработчиков, умеющих эффективно интегрировать AI-инструменты в рабочий процесс
🔸Важность навыков системного и архитектурного мышления

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

🌍 Этические и культурные аспекты использования AI

Использование AI в коммуникациях и управлении сотрудниками поднимает важные этические вопросы:

🔹Проблемы доверия к автоматизированной коммуникации
🔹Ответственность за ошибки, допущенные при использовании AI
🔹Риск снижения творческого потенциала сотрудников

Если сотрудник узнает, что важный фидбэк был написан AI, это может серьезно подорвать доверие и внутреннюю культуру компании

⚡️ Практические советы для кандидатов и работодателей

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

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

ИИ — угроза или возможность?
Как меняется работа инженера под давлением искусственного интеллекта?

🗓 12 августа, в 20.00 GMT+3

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

Темы дискуссии
📉 Тренды и рынок:
– Что происходит с ИТ-вакансиями?
– Какие роли исчезают, а какие наоборот набирают вес?

🤖 Влияние ИИ:
– Какие задачи уже автоматизирует ИИ?
– Станет ли команд меньше? Как изменится найм?

🧩 Новые навыки:
– Какие компетенции становятся must-have в 2025?
– Нужно ли инженерам изучать Prompt Engineering и LLM?

🔁 Найм и карьера:
– Что определяет сильного кандидата сегодня?

🧭 Личное и системное:
– Как понять, что ты отстаёшь от рынка?
– Где искать точки роста — и как помогает комьюнити?

👉 Оставить свой вопрос и зарегистрироваться

Архитектурные катастрофы: уроки провальных проектов - Часть 2

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

🌩 Netflix – трёхдневный сбой, изменивший всю архитектуру

В августе 2008 у Netflix из-за серьёзной порчи базы данных лег почти на три дня, остановив отправку DVD-дисков подписчикам. Корень проблемы – монолитная система с единой точкой отказа.

Инженеры Netflix отказались от вертикально масштабируемого монолита с централизованной БД и перешли к распределённой облачной системе микросервисов, устранив «single point of failure».

За последующие годы Netflix постепенно перенёс все компоненты в AWS, добившись высокой отказоустойчивости и масштабируемости. Появилась «Chaos Monkey» – утилита, намеренно ломающая произвольные части системы в продакшене, чтобы убедиться, что всё выдержит падение любого узла.

Сегодня Netflix сегодня способен пережить отключение целого дата-центра без заметных последствий.

Урок: Если в системе есть единственные точки отказа, рано или поздно они обязательно откажут. Лучшая инвестиция – вовремя построить резервирование и гибкость архитектуры, пока сбой не обошёлся вам простоем или хуже.

🗑 Netscape – переписали с нуля и проиграли «войну браузеров»

В 1990-х браузер Netscape Navigator царил на рынке, но его кодовая база устаревала и обрастала проблемами. Вместо постепенного улучшения в 1998 руководство Netscape приняло решение: выбросить старый код и переписать браузер с нуля.

На это понадобилось больше двух лет, за которые конкуренты ушли далеко вперед. Internet Explorer от Microsoft (бесплатный и агрессивно продвигаемый) захватил пользователей, пока в Netscape работали над новой версией. Когда переписанный Netscape 6 наконец вышел, было поздно – аудитория уже ушла, доля рынка рухнула.

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

Netscape стал ярким примером Second System Syndrome, когда попытка создать «идеальный» второй вариант убивает рабочий первый.

Урок: Переписывание всей системы с нуля – крайне рискованный шаг. Чаще выгоднее рефакторить и эволюционно переделывать продукт, сохраняя накопленный опыт. Новая архитектура должна созреть постепенно; иначе можно потратить годы впустую, пока конкуренты захватывают рынок.

🏙 SimCity 2013 – «всегда онлайн», в который никто не смог играть

Релиз игры SimCity 2013 стал примером того, как неудачное архитектурное решение способно уничтожить репутацию продукта в первый же день. Компания EA заложила в архитектуру требование always-online: даже одиночная игра требовала постоянного подключения к серверу.

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

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

Оказалось, что ничего критичного в онлайне не было, и маркетинговые заявления EA были неправдой. Это подорвало доверие окончательно. Даже спустя время, когда патчи частично исправили ситуацию, игра уже потеряла аудиторию (которая перебралась в Cities: Skylines и другие проекты). Легендарная серия SimCity фактически похоронила себя этой неудачей.

Урок: Если вы закладываете жёсткие ограничения ради бизнес-целей, убедитесь, что ваша инфраструктура потянет. Архитектура должна служить интересам пользователя – навязывание неудобных решений (ещё и плохо реализованных) оборачивается катастрофой для продукта.

🚀 Как построить AI-инфраструктуру и не сойти с ума?

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

📅 Когда: 14 августа, 20:00 (GMT+3)

💡 В программе:

• Как подойти к проектированию AI-инфраструктуры на разных стадиях компании
• Лучшие практики, проверенные в боевых условиях
• Типичные ошибки и как их избежать
• Лайфхаки, которые экономят время и ресурсы команды

🎙 Формат: доклад + живое обсуждение — можно будет задать свой вопрос и разобрать реальные ситуации участников.

👤 Спикер: Данила Поддубный, Lead DevOps Engineer @ Intel. Специалист по высокопроизводительным вычислениям и инфраструктуре для ИИ-обучения

👉 Регистрация

📢 19 августа приглашаем на Круглый стол о роли технического лидера сегодня!

Вместе с выпускниками и выпускницей программ H&S Skills поговорим честно и без фильтров:
— какие вызовы стоят перед лидерами в 2025 году
— чему учатся и на чём ошибаются
— как внедряют новые технологии и при этом держат команду в фокусе

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

💬 Темы: путь в техлиды, роль и задачи, ошибки и инсайты, работа с AI, команда и процессы.
🎯 В финале: советы тем, кто хочет расти в новую роль, и тем, кто уже делает первые шаги.

🕗 Начало: 20:00 GMT+3

🙌 Регистрируйтесь по ссылке и оставляйте свои вопросы!

Эволюция API: совместимость, версии, депрекация

API неизбежно меняется. Задача техлида — сделать так, чтобы новые возможности не ломали клиентов и чтобы старое уходило предсказуемо. Ниже — концентрат практик для REST/gRPC/GraphQL.

📐 Правила контрактов (REST / gRPC / GraphQL)

REST. Добавляйте — не изменяйте: новые необязательные поля, стабильные коды и семантика. Не переиспользуйте поля, не меняйте форматы без явной версии. Идемпотентность для PUT/DELETE, ETag/If‑Match для конкуренции.

gRPC. В protobuf не трогайте номера полей, не меняйте типы/смысл, помечайте reserved для удалённых. Новое — через optional/поведенческие флаги. Версии — в package/service‑имени, параллельные реализации допускаются.

GraphQL. Расширяйте схему (новые поля/типы), не удаляйте и не переименовывайте. Используйте @deprecated(reason) и телеметрию по полям. Не ужесточайте nullability без major‑миграции.

🚦 Версионирование

Минимум версий — максимум совместимости.

REST: для breaking‑изменений — vN (лучше в header/mediatype; путь — допустимо, но грубо). Для additive — без версии.

gRPC: новая major — новый package/service; клиенты пинят контракт.

GraphQL: обычно одна активная схема; breaking — через параллельную схему/шлюз на время миграции.

🧰 Feature gates и capability‑договорённости

Включайте новые поведения по флагам (per-tenant/per-token). Клиент может передавать заголовок/параметр «хочу новую фичу», сервер — объявлять поддерживаемые возможности (capabilities) в метаданных/SDL.

⏳ Депрекация и sunset policy

Фиксируйте этапы: объявление → фриз → ограничение → отключение. Сигнализируйте в ответах (заголовки/метаданные, предупреждения в GraphQL), укажите дату sunset и альтернативу. Замерьте фактическое использование и держите окно поддержки (например, 6–12 месяцев).

🧪 Контрактное тестирование

Consumer‑driven подход: контракты клиентов выполняются против «будущей» версии (Pact/Spring Cloud Contract). Для REST — проверка OpenAPI/примеров/генерации SDK; для gRPC — buf breaking/lint; для GraphQL — проверки схемы, запроса и директив депрекации. Интегрируйте в CI, блокируйте breaking без явного major.

📣 Коммуникация с клиентами

Единый каталог API, changelog, рассылки/вебхуки о депрекациях, версии SDK и примеры миграции. SLA по окнам поддержки, статусная страница, канареечные релизы. Меряйте: кто вызывает устаревшее, какие поля/методы — и целенаправленно помогайте мигрировать.

✅ Чек‑лист эволюции API (REST / gRPC / GraphQL)

🔸 Контракт зафиксирован (OpenAPI/Protobuf/SDL), lint и «breaking‑скан» в CI.
🔸 Добавочные изменения — без версии; breaking — только через новую major.
🔸 Feature gates: план включения per‑client, откат и метрики.
🔸 Телеметрия по endpoint/методу/полю, дэшборды использования.
🔸 Sunset policy с датами, сообщениями и альтернативами.
🔸 Consumer‑driven контракты, авто‑ген SDK и примеры миграции.
🔸 Каталог API и понятный changelog; канареечный/теневой прогон.
🔸 План совместного существования версий и критерий выключения (0 трафика N дней).

🧭 План миграции без боли

🔹 Инвентаризация клиентов и их версий; включите метки клиентских приложений.
🔹 Запустите vNext совместимым (тени/dual‑write), соберите метрики.
🔹 Откройте feature gate избранным клиентам → канареечное расширение.
🔹 Заморозьте v1 (только багфиксы), объявите даты и гайды.
🔹 Переведите SDK/CLI и шаблоны; помогите ключевым клиентам руками.
🔹 После 0 трафика на v1 N дней — поэтапно отключайте, оставив «красную кнопку» отката.

Эволюция API – это не разовый "v2". Формализуйте правила, измеряйте использование, коммуницируйте заранее – и ваши изменения станут предсказуемыми для клиентов и безопасными для бизнеса.

Друзья, всех с пятницей!🕺

У нас к вам вопрос - мы хотим познакомиться ближе с теми, кто ведёт свои блоги, каналы или медиа на технические темы.

👉 Если у вас есть свой проект (в Telegram, LinkedIn, Medium или где угодно), вы публикуете что нибудь интересное или организуете мероприятия — онлайн или офлайн — делитесь ссылкой в комментариях.

Мы собираем список таких проектов, чтобы потом поискать классные идеи и возможности для коллабораций 💪

PS. или присылайте в личку Даше @d_zherebtsova

Переход в техлиды: как не потерять технические навыки

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

Шире зона ответственности – меньше hands‑on. Из‑за страха потерять форму многие тормозят переход. Поговорим о том, как сохранить технические навыки, когда на первый план выходит лидерство.

🧠 Какие технические навыки должны быть у техлида?

Это не только про написание кода. Технические навыки это еще: 

🔹 Читать и ревьюить PRы 
🔹 Проектировать архитектуру, которую смогут реализовать другие разработчики
🔹 Разбирать инциденты по метрикам/трейсам/логам
🔹 Понимать CI/CD и стоимость инфраструктуры
🔹 Управлять безопасностью и данными

Умение разбираться во всем этом даёт доверие команды, качество решений и возможность преодолевать кризисы, когда важны точные технические trade‑off’ы.

🛠Где углубляться, а где расширяться: T‑shape

Глубина – 1-2 ключевых вертикали вашего домена (например, платформа данных и производительность; надёжность и безопасность). Здесь вы задаёте стандарты и отвечаете за сложные решения. 

Ширина – грамотность в соседних областях: протоколы и интеграции, типы хранилищ, облака/сети, CI/CD, SLO и экономика эксплуатации. 

Суть T‑shape: вы обязаны видеть последствия решений соседей и ставить guardrails, но не становиться единственной «точкой знания» по всем стекам.

⌨️ Как поддерживать навыки написания кода и не стать bottleneck для команды

🔸 Квоты на код. Выделите 4–6 часов в неделю на low-risk задачи: техдолг, тест‑фиксы, внутренние утилиты. Малые PR, trunk‑based, без критического пути
🔸 Tracer‑bullets. Разрабатывайте быстрые прототипы для новых идей (1–2 дня), а затем передавайте другим исполнителям
🔸 Парное программирование. Вы сохраняете практику, команда растёт
🔸 On‑call с кодом. Ротация дежурств раз в квартал с «fix‑forward» правками: учит быстрому чтению незнакомого кода
🔸 Инфраструктурные библиотеки. Курируйте 1–2 общие библиотеки/шаблоны (логирование, ретраи, telemetry). Это регулярный hands‑on и мультипликатор для команды
🔸 Ограничьте блокировки. SLA на ревью (например, ≤24 часа), резервные ревьюеры, запрет «последней кнопки» деплоя у техлида

📏 Как измерять impact, когда не пишешь код?

Смотрите на результаты системы. DORA‑метрики показывают скорость delivery (lead time for changes, частота деплоя, time to recover, доля неуспешных изменений). 

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

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

⚠️ Ошибки и антипаттерны начинающих техлидов

🔹 Супер‑разработчик. Пишете ключевой код сами — команда ждёт. Решение: RACI, владение модулями у инженеров, вы — наставник и арбитр
🔹 Big‑bang переписывания. “Сделаем правильно с нуля”. Решение: эволюция, strangler pattern, поэтапные критерии успеха
🔹 Ревью bottleneck. Все PR через вас. Решение: стандарты кода, обучение ревьюеров, два параллельных потока ревью, авто‑чеки
🔹 24/7 митинги. Календарь съедает все рабочее время. Решение: тайм‑боксы, асинхронные ADR
🔹 Архитектура без эксплуатации. Решения без данных эксплуатации. Решение: дизайн‑сессии с on‑call, телеметрия и canary перед масштабированием

Друзья, наше сообщество растёт – к нам регулярно присоединяются новые участники🚀
Мы сделали этот пост-ориентир, где собрали всё самое важное о нас, наших форматах и возможностях.

⚙️ О нас

Hard&Soft Skills community – это объединение инженеров, для которых разработка – больше, чем код.
Мы создаём среду для ИТ специалистов, которые хотят расти шире кода – разбираться в архитектуре, процессах, продуктах и людях.

🎤 Наши форматы

Мы регулярно проводим онлайн мероприятия в разных форматах: Архитектурные Трепы, технические доклады, митапы, круглые столы, live-design cессии и др.

👉 Расписание ближайших событий смотрите в нашем календаре.

Но мы хотим не только встречаться онлайн, а ещё и знакомиться вживую 🕺

Этой осенью запускаем серию оффлайн-встреч в разных городах: Батуми, Минск, Алматы, Варшава. Первая встреча пройдет 18 сентября в Батуми, следите за апдейтами 👀

🤝 Как участвовать

Наши события часто рождаются силами сообщества.
Если вы хотите поделиться знаниями, опытом или интересными кейсами – заполните заявку. Мы всегда рады новым спикерам!

А ещё мы очень ценим вашу повседневную активность 🙌 Когда вы приходите на мероприятия, читаете посты, комментируете и ставите реакции – именно это делает наше комьюнити живым и ценным.

💬 Где общаемся

📢 Канал в Telegram (вы здесь!) – анонсы, полезные материалы, опросы.
💬 Чат в Telegram – задать вопроc, обсудить профессиональные трудности, поделиться новостями или найти поддержку.
▶️ YouTube-канал – записи всех встреч, которые вы могли пропустить.

📚 Лучшие посты и материалы в канале

[Компетенции разработчика: как найти свои слабые и сильные стороны?]
[Чек-лист техлида: все ли хорошо у вас на проекта?]
[Почему проектировать системы сложно?]
[Event Sourcing: что это, зачем нужно и когда применять?]
[Что мешает разработчику расти?]
[4 фундаментальные книги для техлида]
[Чек-лист: готовы ли вы стать архитектором?]
[4 must-read книги для архитектора]

📌 Сохраняйте этот пост, он будет вашим ориентиром. И добро пожаловать в комьюнити Hard&Soft Skills 🫂

Мы не успели обсудить тему поиска работы на прошлом Трёпе, поэтому по вашим запросам проводим её ещё раз 🙌

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

🗓 28 августа, 20:00 (GMT+3)
🎙 Архитектурный Трёп №127

Тема: Как мы ищем работу сегодня: обмен реальными кейсами

Поговорим о том, какие каналы реально работают, что только тратит время, насколько помогают нетворкинг и личный бренд, и разберём успешные кейсы трудоустройства в Европе и США.

👤 Модератор: Виктория Телюк

🔗 Регистрация

Друзья!

26 августа мы провели митап «Технический лидер», на который предварительно зарегистрировалось почти 700 участников!

К сожалению, из-за ограничений Google Meet не все смогли подключиться онлайн.
Мы приносим извинения за неудобства 🙏 и предлагаем вам посмотреть митап в записи:

🎥 Ссылка на запись митапа

📑 Ссылка на презентацию

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

А если у вас ещё остались вопросы – приглашаем на бесплатную консультацию с ex-Architect Miro и EPAM Павлом Вейником:
👉 Записаться на консультацию

Количество слотов ограничено, успейте забронировать!
Всем продуктивного дня ✨

Как мы ищем работу сегодня: обмен реальными кейсами - выводы Архитектурного трёпа #127

🎯 Где и как находят работу сегодня: новые требования к разработчикам

Сегодня выигрывают те, кто соединяют широту навыков с управляемым использованием AI: T‑shaped (бэк, фронт, немного DevOps) + умение объяснить промптинг и валидацию решений

Рабочие каналы – прямые сообщения нанимающим и рефералы. Они срабатывают лучше массовых откликов.

Границы между специальностями стираются… в одном человеке хотят фронт, бэк, шарить за DevOps – и опыт внедрения LLM в процессы

🌍 Состояние рынка по стекам и регионам: AI в работе и на собеседованиях

По стекам спрос смещается: где‑то «потише» по Java, местами активнее зовут на Go; full‑stack‑профили продаются легче, особенно в распределённых командах.

В Европе поиск работы часто упирается в юридические ограничения, а в Канаде и ряде стран – в узость нишевых стеков; зарплатные вилки скачут между странами и даже компаниями.

На лайвкодинге стали разрешать AI: в работе всё равно будете пользоваться; запрещать — всё равно что заставлять писать в текстовом редакторе

🎰 Процессы найма: как происходит, ATS и «лотерея» откликов

Типовой конвейер удлинился: скрининг → офлайн‑задача → live‑coding → финальный разговор; встречаются IQ/логические этапы и разношёрстные форматы в зависимости от страны и культуры компании.

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

Подался на 168 вакансий: ~67 зависли, ~70 – автодеклайн… в итоге пять офферов

📄 Резюме и личный бренд: pet‑проекты, сертификации, LeetCode

Резюме – до 2 страниц, последние 5 лет и измеримые результаты (формат STAR); актуальные технологии – компактным блоком.

Pet‑проекты позиционируйте как микро‑продукты (проблема → решение → метрика), open‑source даёт видимые артефакты и красивую строчку в резюме.

Сертификации окупаются там, где есть бизнес‑эффект (клауд‑партнёрства, CKA/CKAD для верификации глубины); общие бумажки по языкам редко конвертят.

LeetCode – инструмент по назначению: для корп‑циклов – структурная подготовка (Blind‑75/NeetCode), для продуктовых команд важнее чистый код и кейсовое мышление.

🛠 Практические стратегии поиска работы

Действовать лучше по чек‑листу, а не по вдохновению:

🔸 Ранний отклик (в первые сутки)
🔸 Зарплатные фильтры на площадках вроде Glassdoor/Genie
🔸 Ведение своей статистики воронки
🔸 Локализация коммуникации под страну (лексика, ожидания, формат интервью)
🔸 Использование программ для newcomers там, где они есть
🔸 Тактическая гибкость: при переезде допустим «вход» на пол‑грейда ниже с быстрым ростом внутри

Стратегия – это не список инструментов, а последовательность решений во времени

Коротко: рынок ценит управляемую широту (T‑shaped + AI‑грамотность), прозрачные решения на интервью, видимые артефакты в профиле и дисциплину стратегии — тогда даже длинные воронки и ATS‑фильтры превращаются из лотереи в прогнозируемый процесс

⚡️ Architecture as Code: как AI помогает проектировать и документировать архитектуру

Документация — боль: либо бесполезна, либо устаревает ещё до релиза. Но что, если AI возьмёт рутину на себя и поможет принимать решения прямо в IDE?

На воркшопе:

1. Мы начнём с неструктурированного документа с требованиями, выделим ключевые моменты и построим utility tree, который поможет расставить приоритеты.

2. Затем рассмотрим альтерантивны, оформим trade-off таблицы для наглядного сравнения вариантов и проверим, насколько выбранные решения соответствуют исходным целям.

3. В финале сгенерируем основу для cloud-native приложения на базе выбранной архитектуры.

👤 Спикер: Максим Аршинов, Solution Architect @ EPAM Spain
📅 4 сентября, 20:00 GMT+3

🔗Регистрация и подробная программа на сайте

🚀 Круглый стол с CTO — 9 сентября

Переход из инженерной роли в CTO меняет не только задачи, но и весь подход к работе. Меньше кода — больше стратегии, лидерства, взаимодействия с бизнесом и решений, влияющих на всю компанию.

Вместе с опытными CTO и Engineering Manager'ами обсудим:

🔸 CTO — это вообще про что?
Роль CTO в разных компаниях и почему это не «самый умный инженер».

🔸 Первый шок: переход из инженера в лидера
С какими трудностями сталкиваются в первые месяцы и как меняется стиль мышления.

🔸 Команда, бизнес, стратегия
Как совмещать технологическую глубину с бизнес-фокусом и строить отношения с CEO и командой.

🔸 Как подготовиться заранее?
Что стоит прокачать до перехода и какие советы дали бы себе действующие CTO.

📅 9 сентября, 20:00 GMT+3

👉 Регистрируйтесь и ставляйте свои вопросы участникам круглого стола по ссылке

Build vs Buy vs OpenSource: как CTO принимает решения о технологическом стеке

🎯 Что именно решаем и какие ограничения

Сначала фиксируем бизнес‑результат и жёсткие рамки

Какие целевые эффекты: time‑to‑market, рост выручки/ARPU, выполнение SLO/SLA, требования безопасности и регуляторики, data residency

Масштаб: текущая/пиковая нагрузка (RPS, throughput), сезонность, прогноз роста

Зависимости: смежные сервисы и контракты, команды, данные и интеграции

Вывод: без чёткого «что и зачем» сравнение Build/Buy/OSS превращается во вкусовщину

🧩 Где дифференциация и что считать core

Определите источник преимущества: уникальные алгоритмы, собственные данные/опыт, UX, платформенные способности (расширяемость, observability, DevEx). Commodity — стандартные функции, где важнее предсказуемость и скорость

Правило: Build — когда это сердцевина конкурентного преимущества; Buy/OSS — когда функция типовая и ценится скорость, надёжность и предсказуемая эксплуатация

💰 TCO и Time‑to‑Value на горизонте 3–5 лет

🔹 Build: FTE на разработку/поддержку, инфраструктура, тестирование/безопасность, «хвост» сопровождения (релизы, апдейты, инциденты), opportunity cost команды

🔹 Buy: лицензии/подписки и сверхлимиты, интеграции/кастомизации, типы саппорта (SLA/Premium), зависимость от roadmap вендора

🔹 OSS: интеграции и адаптация, hardening/безопасность, операционка (SRE, бэкапы, апгрейды), платная поддержка, риск bus factor

Точка безубыточности: при каком объёме трафика/данных и сроке владения суммарные CAPEX+OPEX Build пересекают стоимость Buy/OSS

Добавьте метрики: рост RPS ×2, удвоение данных, +20% к ценам вендора, текучесть команды

Time‑to‑Value — время до первых ощутимых бизнес‑метрик (например, MRR/конверсия, сокращение TTM), фиксируем целевой порог и окно (n недель)

🗜 Риски и lock‑in, и как их смягчать

🔸 Технические: масштабируемость, производительность, «узкие места». Смягчение: перф‑бюджеты, нагрузочные бенчмарки, профилирование, кэш/очереди, горизонтальное масштабирование, chaos/FAIL‑инъекции

🔸 Операционные: доступность, DR/BCP, комплаенс. Смягчение: SLO+error budget, много‑AZ/region, RTO/RPO, runbooks и учения DR, контроль доступа/секретов, аудит логов/трейсов

🔸 Юридические/лицензии: для OSS — MIT/Apache/GPL (совместимость, copyleft), SBOM и проверка зависимостей; для Buy — условия выхода, экспорт данных, аудит, escrow. Смягчение: юр‑ревью, DPA, право на выгрузку в открытом формате, escrow‑ключи/исходники, регулярные аудиты

🔸 Lock‑in: переносимость данных/контрактов. Смягчение: портируемое ядро, adapter/anti‑corruption layer, минимизация vendor‑specific кода, миграционный plan‑B: «переключаемся за N недель», оценка стоимости миграции, shadow‑traffic перед cutover

🧪 Как принимаем решение: POC → оценка → rollout → пересмотр

POC с чёткими критериями: целевые SLO (P95/P99), стоимость на транзакцию/RPS, скорость разработки, требования безопасности

Бенчмарки: холод/тёплый старт, деградации под пиком, отказоустойчивость, тесты интеграции и совместимости схем

Оценочная матрица (веса и баллы): fit‑to‑outcome, экономика (TCO, TTM, TTV), риск (тех/операц/юрид), орг‑влияние (штат, найм, процессы). Выбираем лучший взвешенный скор

Внедрение этапами: tracer‑bullets → пилот на ограниченном сегменте → canary/feature‑flags → прогрессивный rollout, обучение on‑call. Обязателен kill‑switch и детальный rollback

Регулярный пересмотр через ADR/RFC: раз в квартал пересчитываем экономику и риски, проверяем SLA/SLO, окна для renegotiation с вендорами, актуализируем exit‑plan

👉 Приходите на митап [Как CTO может влиять на бизнес: стратегия, архитектура, команда]. Разберём 12 зон ответственности CTO и их приоритизацию для ускорения роста и эффективности команды

📆 11 сентября
⏰ 19:00 GMT+3

Регистрируйтесь и приходите с вопросами!

🌊 Batumi is on!

Мы рады объявить первый офлайн-ивент!
18 сентября встречаемся в Батуми в офисе компании Andersen на совместном митапе.

📌 В программе:
🎙 Доклад от Стаса Степанова: инсайты о том, на что CTO продуктовой компании тратит своё время
🤝 Много времени для неформального общения, знакомств и обмена опытом
🎤 Ведущий встречи — Никита Щетько.

Но главное — это отличный шанс наконец-то встретиться вживую, познакомиться и пообщаться с комьюнити! 🥳

📍 Ждём вас 18 сентября в офисе Andersen в Батуми.
⚠️ Количество мест офлайн ограничено — успейте зарегистрироваться по ссылке!
Для всех остальных будет доступна онлайн-трансляция.

🔎 Зачем проекту архитектор?

Solution Architect — роль важная, но всё ещё окутанная мифами. Когда он действительно нужен, чем отличается от инженера и как понять, что архитектура работает?

📅 15 сентября (понедельник), 20.00 GMT+3
Тема митапа: «Зачем проекту архитектор? Измеряем и оцениваем работу Solution Architect»

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

👉 Присоединяйтесь к митапу и задайте свой вопрос спикеру