meet.google.com/hvk-vnmq-ani

Через 11 минут ждем всех по ссылке!

🛠 Релизный план: как пережить большие релизы без хаоса 🛠

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

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

🤔 Что такое релизный план?
Обычно у релиза release-notes:
— что выкатываем (фичи и номера задач),
— план наката (как выкатывать),
— план отката (как возвращаться).

Релизный план — это полный сценарий, который превращает релиз в управляемый процесс.
В нем прописано:
1️⃣ Чеклист подготовки и проверки к началу релиза (предрелизник).
2️⃣ Определен ответственный за релиз.
3️⃣ Есть пошаговый сценарий с таймингами.
4️⃣ Назначена релизная команда и наблюдатели.
5️⃣ Подготовлен план наката и план отката, а еще и планы Б, В и тп.
6️⃣ Сделаны бэкапы.
7️⃣ Прописаны метрики успеха и критерии переходов между этапами плана.
8️⃣ Обозначен план коммуникации на все ситуации: кого, когда и как информируем.

👥 Кто разрабатывает релизный план?
Всегда есть ответственный. Это может быть:
— разработчик или QA-лид, который "курировал" основные изменения;
— техменеджер;
— релиз-инженер, если такая роль выделена.
Задача этого человека — собрать в план все и со всеми все проговорить и согласовать.

🧩 Кто такие "Релизная команда"?
1) DevOps, SRE, мониторинг;
2) разработчики и тестировщики (включая команды, которые "может цепануть");
3) бизнес-участники (саппорт, комплаенс) — если релиз затрагивает клиентов напрямую.
Но это те, кто будут контролировать и весь основной этап релиза. Если релиз много часовой и/или предполагается еще процесс багофикса, то стоит выделить сменные команды.

📊 Метрики и критерии
Ночью (в "запаре") у вас может не быть сил и мозгов, чтобы беспристрастно принимать решения о переходе на следующий этап релиза/откате/эскалации/смене плана на план Б. Поэтому в плане должно быть четко указано:
✅ что значит «шаг успешен»;
👉 какие критерии перехода к плану B;
🚫 когда откатываем релиз.
Если критерии не прописаны, в момент релиза может начаться спор — и будут потеряны драгоценные минуты.
Да, скорее всего, вы не будете соблюдать все критерии, но, как минимум у вас будет базис для принятия решений и чек-листы проверок!

🔍 Что "засунуть" в предрелизник?
Мысль, что релиз начинается задолго до деплоя — не нова! Но, "продолбаться" очень легко и вот то, что обязательно необходимо проверить:
— уведомлены ли все бизнес подразделения;
— а маркетинг? И не запускают ли они в параллель какаую-то внешнюю активность?
— оповещены ли клиенты (стоят ли заглушки)?
— точно ли никто не будет катить и фриз установлен заблаговременно?
— кроме того, что нужны бекапы свежие, еще и нужны люди, кто умеет бекапы быстро разворачивать
— есть ли скрипт у support на период релиза?
— если аффектим нормативно-правовое поле - "подстелена ли соломка" в виде писем в контролирующие органы?
Очевидное: инфра, миграшки, рубильники, продуманные канарейки и каскадинги, заглушки всех мастей...

Релизный план — это не бюрократия. Это инструмент, который позволяет пережить самые сложные и рискованные изменения без паники.
Да, возможно вы счастливчики и вам еще просто не доводилось "катать" подобное. Но, штука в хозяйсвте полезная...

А в ближайшие дни расскажу о любимом подходе мужа: разделении релизов и деплоев!

🚀 Код уже на проде, а пользователи его не видят? Это не bug!

Продолжу тему про релизы (начало тут). И напомню, что возникла она от нашего с Темой Пулявиным "батла" на рупоре и кейсовой задачки (видео).

Очень часто путают два понятия:
🔹 Деплой — это когда код выкатывается на продакшн. Он там есть, но выключен, пользователи его не видят.
🔹 Релиз — это момент, когда фича включается и становится доступна клиентам.

Почему классно разводить деплой и релиз:
– можно заранее проверить, что код живет на проде и ничего не ломает;
– баги отлавливаются безопаснее;
– релиз можно делать в удобное время (например, днем, а не в 3 ночи, когда нагрузка спала).

👨‍💻 У меня дома это прямо отдельная философия: муж много лет работает в процессинговых и интеграционных платформах, и там без такого подхода никак. Как только меняешь один кусок, задеваешь кучу функционала. Разделение деплоя и релиза спасает: выкатываешь код, проверяешь, а включаешь только тогда, когда уверен.

Когда помогает:
– быстрые гипотезы: включили на 1% пользователей, посмотрели метрики;
– highload-кейсы: можно откатывать или переключать группы;
– сокращение времени реакции на инциденты.

Когда не получится:
– если бизнес не готов к тому, что «фича на проде, но выключена».

🚨 Важно: Такой подход требует пересмотра архитектуры и инженерных практик. И его лучше закладывать заранее (да, это уже про бережливое проектирование), а не прикручивать потом.

Техники, которые помогают:
– Feature toggles (фичефлаги)
– Blue-green deployment
– Canary releases
– Trunk-based development

📎 Полезные материалы:
– Martin Fowler про Feature Toggles (одна из самых подробных и развернутых справок)
– Trunk Based Development
– Видео: На пути к TBD: как мы внедряли feature flags
– Видео: From Development to Deployment

💬 А вы видите минусы в разведении деплоя и релиза?

🗓 1 сентября: новый сезон 🎭

В каждом листе осени слышен шорох вечности
Борис Пастернак

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

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

🍂 Фокус. Хочу посвятить время книге и тому самому "справочнику" или "библиотеке полезняшек", где мои заметки и практики будут не разбросаны кусочками, а собраны в единый инструмент. Что это будет — сайт, сборник или что-то третье — пока не знаю. Но именно в эту сторону я сейчас "копаю лапками".

🍂 Жизнь вне работы. Впереди — отпуск. Непривычный формат. Те, кто знают, как осторожно и бережно появляются дружественные связи во взрослом возрасте, поймут: это отдельная ценность.

🍂 Учеба. Заканчиваю курс СТО от Стратоплана, продолжаю заниматься английским. Хочу еще "для души" курс баристы и наконец-то WSET1, но я впервые за пол года расчехлина карандаши и краски и не хочу снова "забросить" эту медитацию!

🌬 Что дальше: есть еще пара новостей и движух, но о них я расскажу ближе к середине сентября...

А пока у меня к вам вопрос.
Так как новый сезон — это время новых маршрутов, я хочу собрать от вас запросы:
— о чем стоит рассказать подробнее в канале?
— мб вы хотите какое-то открытое мероприятие?
— а вдруг у вас есть идеи для темы следующего винишника или Рупора?

Напишите в комментариях, пжл 👇
Я соберу идеи и разверну их в серии постов/мероприятий.

Сразу скажу, что в ближайшее время будет полезняшка с обновленным списком AI, которые я юзаю. Так как пришли ко мне в личку с таким запросом!

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

💵 Финансы для СТО: когда математика спорит с экономикой 🔢

Трехдневка в Стратоплане про "Финансы для СТО" стала для меня не только про деньги, а про разницу типов мышления. Я — математик: строю устойчивые модели, оптимизирую систему на длинном горизонте, свожу риски. Экономика в учебных задачах требовала обратного — короткой игры, быстрой прибыли, принятия волатильности как "платы за опцион" на результат.

🍦Кейc: "завод мороженого"
Начну рассказ с задачи, которую мы решали в один из дней.
Задача: за год заработать как можно больше.
Что сделала наша команда под моим влиянием (грех себя тут обелять): выстроила непрерывное производство, сняла узкие места, заняла большую долю рынка, заложила рост — но на 3-летнем горизонте. Результат за первый год — хуже всех. По факту я утащила команду в "красивую математику" и стратегию "в долгую" — и не выполнила KPI краткосрока.
Это симптом моей обычной жизненной стратегии: я плохо играю "в шорт", предпочитаю снижать риск и строить процессы, а не ловить всплески дохода на короткой дистанции.

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

все модели неверны, но некоторые полезны

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

Пример из истории времен моего выпуска из универа. 2010 год и выходит супер нашумевшая статья Ло и Мюллера из MIT "Физическая зависть". Как раз о том, как экономисты и финансисты стремяться создать предсказуемые модели как в физике. И с одной стороны, эта тяга приблизила весь мир к важным открытиям и достижениям, а с другой, в моменте поодило поколение "иллюзионистов".

Что говорит «операционка» (и почему меня тянет "к долгосроку")
Если смотреть глазами опердира, цель задачи должна быть другая: сначала устойчивый поток, потом прибыль. А если посмотреть глазами математика, то оно еще и на формулах подтверждается:
1️⃣ Закон Литтла: 𝐿 = 𝜆𝑊
Управляя входом и временем в системе, ты управляешь очередями/сроками. Эта формула — база аргументации за непрерывность производства.
2️⃣ Закон Райта:

себестоимость единицы продукции снижается на фиксированный процент с каждым удвоением кумулятивного объема производства

Этот закон объясняет, почему "непрерывка" и масштаб в "лонг" бьют точечные всплески.

⚠️То есть моя отмороженая модель была рациональна в логике операций и масштаба, но не соответствовала целевой метрике краткосрочной прибыли.

Что важного я унесла с 3хдневки
1️⃣ Инвест-политика нужна на 3 уровнях: компания → департамент → человек
— На корпоративном — портфель, рисковый бюджет, нормативы доходности.
— На уровне департамента (СТО/платформы) — правила trade-off между операционными улучшениями и "ставками на будущее".
— На личном — твой психотип риска и допустимая волатильность результатов.
И помним, что все меняется: закладываем право, а не обязанность продолжать; при неблагоприятных сценариях сворачиваем, при благоприятных — наращиваем.
2️⃣ Важно считать IT-инвестиции честно
Не путать Total cost и "цену разработки". Включать простои, скорость вывода фич, гибкость (опциональность) — именно это чаще двигает показывает окупаемость инвестиций, даже если косты на грани.
3️⃣ Нужно научиться сводить "лонгу операционки" с "шортами" задач по заработкам
На теории понимаю, на практике — могу ток объяснить теорию 🤓

Что осталось открытым
❓Как создать инвест-политику уровня департамента, чтобы это не было "мини-корпфином", но реально управляло цифрами и рисками?
❓Как расширить границы допустимых рисков с учетом собственной склонности к безрисковым моделям?

Вывод
Честно и очевидно: я не экономист — и это нормально. Моя сила — в моделировании и игре в долгую. Но надо научиться жить рядом с дисциплиной краткосрока: особенно если мир принебрег моей "красивой" функцией.

🌿 Команда — зеркало лидера

Я все больше убеждаюсь: команда очень часто зеркалит своего лидера.
Уберите слово «лидер» — и она будет зеркалить менеджера. И это проявляется на всех уровнях:
👉какой SEO — такая компания,
👉какой C-Level — такая стратегия,
👉какие линейные руководители — такие команды и такая культура внутри.

Есть старая фраза: «От осинки не родятся апельсинки». Да, есть вещи, которые в нас очень сложно изменить: базовые ценности, культурные установки, глубинные привычки. Но есть и то, на что мы реально можем влиять прямо сейчас: настроение, способность сохранять ресурс и не загонять себя и команду в бесконечные овертаймы.

У меня был опыт, которым я не горжусь! Мы с командрй работали буквально 24/7. Один заканчивал, другой начинал "смену", и так несколько месяцев подряд. Хочу ли я повторить это? Упаси Боже. Горжусь ли я этим? Нет. Но считаю ли я это важным опытом? Однозначно да. Потому что он помог мне понять: где мои границы, что для меня допустимо, а что — нет. И главное — что именно я транслирую команде своим состоянием.

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

Именно об этом мы поговорим на прямом эфире 10 сентября в 10:00 со стратегом и коучем UCF Ольгой Кочановой.
Тема звучит просто: «Команда — зеркало лидера».
Но внутри — разговор о вещах, которые решают гораздо больше, чем кажется:
– как внутреннее состояние руководителя отражается на команде;
– почему доверие важнее тотального контроля;
– что делать, если уже все горит и сил на стратегию нет;
– как строить лидерство так, чтобы хватало ресурса и на людей, и на себя.

➡️ Ссылка на подключение
Добавьте в календарь прямо сейчас, чтобы не забыть выпить утренний кофе за беседой и в уютной атмосфере!

А еще от Оли есть подарок: если подпишетесь на ее канал и напишете ей в личку с пометкой «ITКатя», получите бесплатную 30-минутную коуч-сессию.

До встречи утром в среду!

🌱 Почему иногда полезно отпустить лидера 🌿

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

Да, я фанатею не только по еде, вину, опере, но еще и по моде...

Для меня показательный пример — уход Марии Грации Кьюри из Dior. Да, она была одним из самых спорных директоров исторических модных домов. Но для меня, ее последний показ остался в сердце как красивое прощание — лебединая песня и дань дому. Были споры о ее работе, но дом живет дальше. Фамилия уходит, а дух и наследство остаются. И я уверена, что еще через несколько лет, уже будут в моде "заигрывания" с творениями Кьюри!

🐒 В эту же тему часто приводят байку про пять обезьян, банан и холодную воду: якобы ставили эксперимент, меняли обезьян, и новые тоже не лезли за бананом. Однако такого опыта не было — это городская легенда. История впервые всплыла в книге Competing for the Future (1994) с фразой "один наш друг рассказывал…" (Эллегантно, не правда ли!). Если хотите разобраться в настоящих исследованиях, обратитесь к статье “Cultures in chimpanzees” (Nature, 1999) — доступ к ней платный, но там собраны реальные данные за более чем вековой период наблюдения за шимпанзе!

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

Можно менять культуру и "снизу вверх", но это про "партизанщину" и преодоление. Смена "сверху вниз" дает шанс на эволюцию, а не революцию: плавный переход на следующий уровень без взрывов. Здесь уместно вспомнить спиральную динамику: модель предполагает, что движение по спирали возможны и вперед, и назад; люди и организации "не всегда движутся вверх", а иногда шаг назад — лучший ответ на изменившиеся условия (Ох, вспомните Микеле и коллекции в которых он отдавал должное Вудстоку).

☕️ Завтра (в среду 10/09/25) утром (в 10-00) за кофе будем обсуждать, как понять момент для таких шагов и чем они отличаются от "обезьяньих" запретов. Встреча по ссылке!

💬Вопрос к вам. А вы видели примеры, когда смена лидера помогла? Или усилия шли снизу вверх? Делитесь историями в комментариях — встретимся за кофе!

ссылка, если лень лезть в предыдущий пост

Работа с командой ? Работа с людьми

Иногда вопрос про команду — это не про людей. А про твой внутренний диалог с дьяволом. Таким, который не мешает особо, но постоянно нашептывает:

«А ты точно знаешь, зачем тебе команда?»
«А ты точно веришь в людей?»

Сейчас в моей голове 3,5 модели (слоя), в которых можно «собирать команду».
И у каждой — свои смыслы. Свои ловушки. И своя цена. Ни за одну из них не топлю, и ни одну не осуждаю!

1. Команда как люди. 🫰
Когда тебе хочется, чтобы всем было хорошо. Ты заботишься, подстраиваешься, делаешь по-человечески.
Это нормально. Особенно в начале карьерного «юношеского энтузиазма».
Но правда в том, что «делать хорошо для людей» и «делать хорошо для команды/компании» — это не одно и то же. И именно на этом уровне формируются «друзья с работы», с которыми пройдешь через годы.
Но в этой плоскости легко застрять. Или выгореть.

2. Команда как организм. 🧠
Когда ты собираешь не просто «хороших людей», а систему.
Понимаешь, где «печень», где «легкие», где «мозги» (очень важный орган) и как устроено взаимодействие между ними.
Понимаешь, что если «печень откажет» — будет желтуха. И больно будет всем. Как и «без мозгов» — можно, но сложно!
Сбор таких команд про cultural fit. Уже требует понимания, как все будут работать вместе, что два «желудка» — хорошо, но остальная пищеварительная тоже должна справляться!
В таких командах часто есть «клей», на котором все держится, который собирает команду под себя, и если «клей» убрать, то может все разрушиться!

2.5. Команда для начальства. 👨‍💻
Пока еще системно, вроде бы профессионально, похоже на «все хорошее, против всего плохого». Но с оглядкой.
Подбираешь людей так, чтобы все выглядело как надо. Шикарные контракты, правильные слова, красивые отчеты. Люди не должны «возникать» (у каждого начальника за этим словом скрыто «свое»), должны быть «удобны» и «по-яблочному красивы»!
Это хорошо для карьеры.
Но особенно приятно дьяволу — потому что тут легко забыть, что все это, да и все мы — временно. И ты, и они, и вся эта конструкция.

3. Команда как система под компанию. 🏢
Это уже про холодный расчет. Здесь нет сантиментов. Просто ментальное и физическое здоровье людей становится одним из базисов постройки!
Здесь понимание, что «все мы смертны», и твоя задача — чтобы команда пережила и тебя, и начальство, и изменения в оргструктуре.
Чтобы не cultural fit, а cultural add — тот, кто не похож на тебя, но дает системе выжить и расти.
Но вот что сложно:
Находить и признавать ценность в том, кто не похож — дорого. Не в деньгах. В усилиях. В зрелости. В умении понимать, что когда не по-твоему, это не факт, что плохо! НО это еще и про границы, про принятие того, что ты не лучше, не хуже, просто у каждого из вас своя специфика, и токсичность тут не поможет....
Это самый честный способ собирать команду.
И самый тяжелый. А главное, что очень часто несоразмерный компаниям.

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

И, да, посто навеян вчерашний кофием в эфире. Запись у Ольги (коуч и та, с кем кофейничали) в канале!

💭 Вот такие непозитивные анатомические мысли! Делитесь своими...

✨🦔 Ежики не станут белочками✨

Мы совершаем ошибки. Ошибаются и с нами.
Иногда это не про «плохо» или «хорошо», а просто про то, что cultural match не случился. Точка. Люди разные. Ценности разные. И это нормально.

Важно уметь признавать: «мы не подходим друг другу».
— без обвинений, без вины, без поиска «кто неправ».
Просто вовремя отпустить ситуацию — и себя.

🍷 Сейчас мы с мужем в отпуске. Сидим на винной дегустации в горах. Через час — спа, потом ужин. Весь этот ритуал — про перезагрузку. Во вторник был мой последний день работы в eCommPay, а уже в среду я выхожу в новую компанию. Третий раз буду работать с мужем: он — в процессинговой зоне, я — в KYC. И рядом собирается команда «бывше-нынешних» коллег.

Все последние посты и Рупор — это был не только мой взгляд как hiring manager, но и опыт человека, который сам проходит этап смены работы.

🥂 А еще, со 2 октября я снова иду на курсы по вину!

И тут ловлю себя на простых выводах:
— важно слышать себя и выбирать то, что подходит именно тебе;
— если что-то не твое — не мучай себя; мир огромен, в нем есть место для поиска;
— плевать на осуждения: «вино — не женское дело»? ха! «Пропустить конференции — значит потерять себя»? нет, значит найти;
— сменить работу, чтобы дышать свободнее? окей. Страдания точно не путь к созиданию прекрасного.

☀️ Обнимаю всех, кто боится сделать шаг! Вот вам лучики поддержки: ищите свое и не сдавайтесь.

P.S. Принимаем поздравления 🎉 Сегодня пришло приглашение ребенку в вуз. Он выбрал Кипр (в списке были еще Бельгия и Голландия). Так что скоро IT-шников на острове станет больше! На след. неделе прилетает из Франции 💙

А я сбежала в спа 🌿

🤮 Когда DDD «не очень» 🤢

Я часто пишу про архитектуру, но для меня это не только про «системы и сервисы». А про управление командами и про то, как мы вместе думаем и договариваемся.

И вот тут уместно поговорить про DDD (domain-driven design). Даже если вы не архитектор, а продакт или аналитик — этот подход помогает лучше понимать бизнес-домен, договориться о терминах и выстроить совместную работу.

Мы часто говорим, что практика «не очень». Но если присмотреться — чаще всего дело не в самой практике, а в том, что мы не научились с ней работать.

Я уже писала большую серию про DDD, а сегодня хочу чуть-чуть поговорить о том, как начинать «играть в DDD».

В финтехе, например, нередко можно услышать мнение, что DDD неприменим. И звучит оно не от случайных людей, а от очень экспертных ребят. Я придерживаюсь противоположного взгляда. Но я противница начинать DDD с самого популярного шага — event storming.

📌 Что такое event storming
Это фасилитированная сессия, на которой команда с помощью стикеров визуализирует ключевые события системы: что произошло → какие команды это вызвало → какие агрегаты в системе реагируют → какие внешние акторы задействованы. В идеале это способ «схватить» доменную модель живьем и быстро вскрыть области незнания.

На практике же есть нюансы!

Минусы event storming на старте
➖ Состав участников: вы собрали людей, но они не обязательно доменные эксперты. И даже не обязательно про нужные домены.
➖ Язык: люди могут использовать одни и те же слова, но вкладывать в них разный смысл. Кажется, что все согласны, а на деле — полный рассинхрон.
➖ Фасилитация: нужен сильный медиатор, и лучше с доменной экспертизой. Иначе он рискует выбесить всех, вмешавшись не в тот момент (например, когда спор наконец-то почти добрался до истины).
➖ Ожидания: многие приходят с установкой «нам что-то расскажут». Никто не готов быть активным участником.
➖ Нет плана: если у вас нет гипотезы или модели, которую вы хотите проверить/доработать, встреча превращается в борщ идей. Брейншторм — это круто, но брейнштормить тоже надо уметь.
➖ Скепсис: часть участников приходит с задачей «обкакать ваш праздник» и играть в «Бабу Ягу против».
➖ Критика ≠ демагогия: нужно уметь отличать конструктивную критику от неконструктивных набросов. Наброс на вентилятор — это не демократия. Это токсичность с примесью демагогии.

👀 Что еще стоит учитывать
Время: event storming легко превращается в многочасовой марафон без ощутимых результатов.
Сложность визуализации: доска со стикерами моментально становится кашей, если нет четкой структуры.
Наследие иерархии: иногда люди боятся говорить, если за столом их руководитель или «великий эксперт». В итоге важные наблюдения остаются невысказанными.
Ложное чувство завершенности: все постояли у доски, всё заклеили стикерами — и появляется ощущение, что «модель готова». Хотя на самом деле все только начинается...

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

А как именно можно начать «играть в DDD» по-другому — расскажу в следующей части.

PS Обратите внимание, что все указанные минусы только про «на старте»!
💬 А у вас есть опыт успешного захода в DDD с event storming? Поделитесь, пжл, что для вас эта практика!

#ddd

🎉 Розыгрыш билета на Аналитический марафон! 🎉

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

Я сама в этом году не выступаю, но рекомендую конференцию от всей души ❤️
И чтобы не быть голословной — вот мои доклады с прошлых марафонов:
👉 Вначале было слово - архитектура от словаря
👉 Бережливая архитектура: просто и пошагово

А теперь к приятному — у меня есть 🎟️ бесплатный билет, и я разыграю его среди подписчиков!

📅 Результаты будут в воскресенье, 21/09.

Что нужно сделать:
1️⃣ Подписаться на канал.
2️⃣ Оставить комментарий под этим постом (каждому комментарию присвоим номер).

🌀 Хочешь без ожидания и случайностей? Тогда вот промокод IT_Katia_15AM14 на скидку для самостоятельной покупки билета.

Не упустите возможность — конференция обещает быть очень насыщенной и полезной 🚀

🎉 Последняя трехдневка Школы СТО от Стратоплана 🎉

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

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

Последняя трехдневка соплава с еще одной датой: Стратоплан празднует 15 лет. В честь этого они до конца недели дают промокод Friends30 на скидку 30% на любой курс. Так что если вас долго душила жаба🐸 — вот отличный повод ее отодвинуть.

Я пошла доучиваться и доживать эти три дня, а потом вернусь к вам с большим ревью.
А вам всем — легкой пятницы и классных выходных! 🌿✨

PS А еще вот тут конкурс на бесплатный билетик на Аналитический марафон! Прям море халявы 😂 в чате, пока я осваиваюсь на новой работке!

🚀 Стартовал 7-й поток Mentor in Tech! 🚀

Я давно и с любовью поддерживаю Women in Tech Russia и Women in Big Data Russia ❤️.
И Mentor in Tech — это важная программа для помощи женщинам в развитии в STEM! И уже в разгаре набор участников в 7ой поток, в который еще можно успеть!

Я успела побывать в этой истории в разных ролях:
✨ участница «Ты — ролевая модель»
✨ спикер
✨ ментор

И каждый раз это не только про знания, но и про потрясающих людей! Здесь формируется сильное комьюнити, которое реально вытягивает, поддерживает и вдохновляет.
— 4 месяца активного менторинга
— 12 направлений — от Data Science до Product & Project Management
— воркшопы, вебинары, менторские сессии
— и в финале сертификат, который приятно добавить в LinkedIn 😉

📅 Заявки принимаются до 25 сентября.
📌 Заявка подается через чат-бот
✍️ Описание программы в канале Women in Tech Russia

А еще напоминание: сегодня вечером я подведу итоги розыгрыша билета на Аналитический марафон. Так что у кого пальчики скрещены — держите крепче 🤞😁

🎲 DDD: как в это играть (и почему не стоит верить «истине»)🃏

Я уже писала пост про почему event storming не всегда хорошая идея чтобы зайти в DDD.
Если вы решили «поиграть в DDD», начните с самого простого и самого важного: разобраться в предметной области. DDD — это не магия, не набор модных практик и не набор стикеров на стене.

С чего реально начинать:
1️⃣ Читайте законы. Они часто содержат «истину» о том, как вещи должны работать (особенно в финтехе, комплаенсе, KYC).
2️⃣ Делайте словарик терминов. Убедитесь, что слово «счет», «платеж», «операция» означает одно и то же для бизнеса, для юристов и для девов.
3️⃣ Собирайте проверяемые факты — не «чувства» и не домыслы.

☝️И самое главное — никому и ничему не верьте.
Почему? Потому что самая опасная вещь на старте — принять чью-то версию «истины» за окончательную. Если бы у вас была истина, вы бы не занимались DDD: вы бы просто поменяли процесс под истину и ВСЕ! Но вы пришли, чтобы проверять, фиксировать несоответствия и строить предкорректную модель — модель, на которой могут оперировать и бизнес, и разработка.

Что следует проверять (источники проверок):
Закон — как вещь должна работать по правилам государства. (сложнее менять)
Внутренние регламенты, политики, оферты, договоры — что официально декларировано внутри компании (проще менять, но пока действует — имеет силу).
Код и текущие реализации — как сейчас работает система на самом деле (источник реального поведения пользователей/системы).

Каждый «депозит» (слово бизнеса, кредит доверия, решение в архитектуре) требует проверки по этим источникам.

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

Практический алгоритм старта DDD:
1️⃣ Сбор первичных фактов (законы, регламенты, таблички из БД, примеры операций).
2️⃣ Составление простого словаря терминов — обсуждение и фиксирование.
3️⃣ Построение «предкорректной» доменной модели (HLD вам в помощь).
4️⃣ Проверка модели на реальных текущих примерах: боевые пользовательские сценарии (без использования ИС), законы.
🔄 Итерации: корректируем модель, снова проверяем, выстраиваем контракт между бизнесом и девами.

Про event storming:
не стартуйте с него, если вы не сделали первые три шага. Event storming — мощный инструмент, но без проверяемых фактов и без согласованного языка это всего лишь красивый брейншторм. А главное у вас должны быть доменные эксперты (а их еще и взять откуда-то надо) и эти товарищи должны уметь коллаборировать!

DDD — это не про быстрые победы. Это тот случай, когда вам нужно несколько раз «свериться с картой» и ее пофиксить, чтобы двигаться вперед. И даже не про модную аббревиатуру, а жаль! Это подход, позволяющий учиться видеть и проговаривать предметную область вместе с командой (в широком смысле этого слова).
И начинать стоит именно с простых шагов, а не с разноцветных стикеров!

Про то, как писать определения 👉 вот тут
Про то, как искать доменных экспертов 👉 вот тут

💬 А как у вас с таким подходом? Особенно откликнитесь, пжл, те, кто пишет определения!

#ddd #architecture