🎭 Если можешь не создавать — не создавай!
Вчера была на премьере в Театре Ленсовета.
«Театральный роман». По Булгакову. Спектакль соединивший в себе "Записки покойника" и "Белую гвардию".

И знаете — не понравилось.
Для меня это попытка упростить «Турбиных». Убрать нюансы, добавить пафоса и лишней буффанады и увести в сторону.
Но! Я не могу сказать, что спектакль не навел ни на какие мысли. Как раз наоборот — навел. И довольно точно.

Иногда мы сами становимся авторами. Не обязательно книг или пьес.
Архитектура. Продукт. Код. Процесс. Тест. Да что угодно.
И вот ты что-то делаешь. А рядом есть другие люди — не всегда из твоей сферы.
Они что-то советуют. Исходя из своего опыта, своих целей, и своей политики.

И ты как тот герой из Булгакова — можешь:
— переписать в угоду критикам,
— упереться и остаться в столе,
— или искать третий путь, где ни ты, ни твое детище особо никому не нужны.

💬 Я вспомнила старое интервью Саши Васильева (группа «Сплин»).
На вопрос «как сделать хит?» он ответил:

«Для меня есть только один способ добиться успеха – писать сильные интересные яркие песни»

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

Завтра выхожу из мини-отпуска — и начинается ВСЕ: работа, встречи, дорога домой на Кипр.
Плюс размышления: ехать ли на Highload или TeamLead? И если ехать, то с чем? Потому что тема, которая моя, личная, любимая — не всегда укладывается в формат доклада. Зато может стать курсом, а я вместо написания книги/курса пишу небольшие статьи...

Так что, наверное, пора перестать страдать и просто начать делать.
А пост, возможно, прежде всего для себя.

А еще я вписалась в конкурс Tg-каналов от ребят из TG Contest, в котором участвуют экспертные каналы с авторским контентом. Цель: "слет юных блогеров" и помощь друг другу в поиске релевантной аудитории. Я в секции «Разработка и управление командой» и вот тут можно даже за меня голосовать (за что я конечно же буду вам признательна: ссылка на голосование 👍).

🗂А еще мы собрали папочку со спикерами нашего "направления" - думаю, что большую часть "молодых/да бодрых" вы знаете, но возможно найдете для себя новые интересные имена: ПАПОЧКА.

🛡 Навеянное питерской погодой 🛡

Лето. Кому-то полегчало. А кто-то говорит страшную фразу на 1:1: «Сейчас-то я еще держусь. А вот как осенью — не знаю…»
Мы не всегда можем «победить». Не всегда справляемся. Но можно пройти этот путь иначе.
Наткнулась на интересную модель ARMOR — она показалась очень человечной.

ARMOR — не про устойчивость, а про не развалиться. Ребята из Lenny’s Newsletter по итогам исследования о выгорании ITшников (полная версия по подписке), составили стратегию борьбы с выгоранием.

A: Autonomy (автономия)
1. Контроль за временем.
Свободное время под важное не появится само.
Люди, прошедшие через выгорание, расчищают календарь, бронируют слоты на фокус и убирают все, что мешает.
2. Доверие не просят — его зарабатывают.
Ты не получаешь автономию — ты ее создаешь делами. Выполняй обещания. Работай прозрачно. Это будет самый сложный пункт, так как в выгоревшем состоянии держать слово - сложно!
3. Словами через рот - проговаривать вслух ВСЕ.
Что делаешь, как работаешь, где твои границы.
Не просто «что», а и «как». Про это напишу как-нибудь отдельно.
Автономия — не вседозволенность. Это возможность работать долго, стабильно и без внутреннего перегрева.

R — Resilience (Незыблемые границы)
1. Границы нужны всегда — даже микроскопические.
«Заканчиваю в 18:00», «Не больше 3 приоритетных задач в день», отказ от мессенджеров вне рабочего времени, выключение всего в отпуске. Это не слабость — это осознанность.
2. Слово «нет» — твой щит.
Каждое «да» чему-то — это «нет» чему-то другому.
Умение аргументированно отказывать спасает фокус, энергию и уважение к себе.
3. Настоящие перерывы — не прокрастинация, а защита.
Регулярные, восстанавливающие, с переключением контекста.
Когда в ресурсе — выкладывайся. Но дай себе право на передышку.
Границы — не про стену. Это возможность жить и работать структурно.

M — Maintenance rituals (Ритуалы ухода за собой)
1. Сон — твой главный алерт.
Если ты плохо спишь две ночи подряд — это инцидент.
Люди, пережившие выгорание, не героствуют: они отлаживают режим, уменьшают шум перед сном, идут к специалисту, если не справляются сами.
2. Движение — как обязательный health-check.
Прогулки, разминки, тренировки — не опция, а гигиена психики и тела.
Даже 15 минут активного тела — это минус тревога, плюс ясность.
3. Питание и терапия — часть архитектуры устойчивости.
Люди, умеющие не сгорать, не пропускают приемы пищи и не игнорируют психотерапевта/иную врачебную помощь. Это профилактика падения вашего продакшена.
Maintenance — не про баловство. Это настройка системы, в которой ты — и есть система.

O — Original Thinking (Собственная система убеждений)
1. Осознанность границ ответственности.
Плохая оргструктура? Токсичный процесс? Это не твоя вина. И не твоя зона контроля.
Если ты видишь, что кто-то рушит компанию, но ты не ее собственник, возьми попкорн и наблюдай. Дай людям совершить ошибки. Главное будь в безопасности!
2. Разрешить себе быть несчастным.
Не надо «быть молодцом» каждый день. Не надо улыбаться на стендапах, когда выгорел внутри.
Люди, сохранившие себя, умеют признавать эмоции и не тушат их насильно.
3. Меньше «я должен», больше «я могу»/«я хочу».
Разберись в том, что для тебя важно и делай именно это!
Original thinking — внутренний фрейм: как ты воспринимаешь себя и свою работу.

R — Role Architecture (Архитектура карьеры)
1. Выбирай не логотип, а людей.
Хороший бренд — это красиво, но поддержка в команде важнее.
Безопасная атмосфера = лучший инструмент от выгорания.
К сожалению, я проверила эту гипотезу на себе. И могу ее подтвердить на все 100!
2. Тест на воскресенье.
Если по воскресеньям тебя «пучит» от мысли о завтра — меняй работу.
Идти туда, где тебе легче дышать!
3. Позиция должна соответствовать масштабу.
Размытые задачи и неясные ожидания выжигают хуже переработок.
Архитектура роли — про понимание: где твоя зона влияния и где заканчивается твоя ответственность.

При кажущейся простоте за каждым пунктом скрывается уйма работы. Но цифра >50% выгоревших - пугает...

А я заметила, что без солнца больше думаешь про тщетность бытия!

#people_management

🧩 А что такое домен, простите?

Я тут вернулась после 2х недель командировок, конференций и мини-отпуска и пока меня окунает в омут всего скопившегося. И немножечко меня окунуло в DDD.

DDD — вроде бы про язык. Про общее понимание между бизнесом и разработкой. Про то, чтобы сложное стало чуть понятнее. А теперь откройте любую из «каноничных» книг по DDD. Хотите у Эванса, хотите у Вернона. Хотите даже у Хононова. А теперь найдите там внятное определение домена. 🙃

Сюрприз: его там… нет. Есть

Domain (noun)
a sphere of knowledge, influence, or activity.
(сфера знаний, влияния или деятельности)
Словарь Мерриам-Вебстера

И есть «реальность бизнеса». Есть «область, где компания зарабатывает деньги». И вроде бы звучит хорошо — но когда ты на митапе или на курсе начинаешь объяснять, «что такое домен», и люди в зуме кивают, а потом кто-то говорит, что у него домен — это API, ты понимаешь, что все не так просто.

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

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

Звучит сухо, но очень помогает. Вот убрать «платежи» — и остальное работает, просто не зарабатывает. А вот убрать «логистику» — и часть бизнеса встанет, но остальное будет жить. Значит, это отдельные домены. А вот «авторизация» — это не бизнес-домен, а скорее техническая компонента, обвязка.

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

Хотя термин «домен» в контексте DDD порой размытый, важно явно договариваться о его значении в каждом конкретном случае. Авторы основных книг по DDD – Эванс, Вернон, Хононов – закладывают понимание домена как предметной области бизнеса, но уровень этой области может различаться (весь бизнес vs. отдельная функция). Если мы уточним, что домен – это обособленная часть бизнеса с самостоятельной ценностью, то получим более четкую основу для стратегического дизайна.

💬 А вы как определяете «домен» в своей работе? И как объясняете это команде?

#architecture

👍 Утренняя рекомендашка! 👍

В эту субботу моя подруга и мой трекер Юля Балдина проводит бесплатный мастер-класс про бизнес-процессы и операционку.

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

Юля именно такая. Много лет работает по ту сторону процессов — там, где их собирают, чинят и масштабируют.
И она умеет показать:
— где у тебя в компании зарыты деньги,
— как перепрошить кейсы на рост,
— и почему «ну вроде работает» — это не норм.

📌 Даже если ты не операционный директор — будет полезно. Потому что посмотреть на процессы глазами операционки — это вообще отдельный скилл.

📎 Вот пост с записью на бесплатный МК

Идите. Потом спасибо скажете.

🧠 Что дает DDD на этапе сбора требований и всех этапах взаимодействия с бизнесом?

1. Сбор требований — это не просто список хотелок
В DDD важно не просто услышать, что «нужно сделать кнопку», а понять, в каком домене живет эта кнопка, какую бизнес-ценность она несет, и какой словарь у людей, которые ее хотят.
Наша задача — достроить ментальную модель бизнеса, а не просто получить бэклог.
🧩 Инструменты: Event Storming, Domain Storytelling, бизнес-интервью на основе Ubiquitous Language.

2. Единый язык (Ubiquitous Language)
Если у разных ролей (аналитики, архитекторы, продакты, пользователи) — разный словарь, проект обречен на баги из-за недопонимания.
Именно на этапе сбора требований надо:
— фиксировать термины, особенно амбигуозные (например, «клиент» может быть и физлицом, и юридическим лицом, и API-интегратором)
— называть вещи бизнес-словами, а не «экран 3», «процесс 5», «где-то там фильтр»
— не бояться обсуждать, что такое “правильно” в глазах бизнеса
🎯 DDD здесь учит нас: не просто спросить “что сделать”, а выяснить “какое поведение считается корректным” и “почему именно так”.

3. Проектирование — это уже часть коммуникации
На этапе общения с бизнесом может (и должно!) рождаться проектное мышление:
— а как это будет разделено на bounded context-ы?
— это новая подсистема или расширение существующей?
— а эта функция — чей юрисдикции, какого домена?
⛓️‍💥DDD позволяет сразу задать границы, чтобы избежать каши из связей и зависимостей в будущем.

4. Поиск доменных экспертов — не пункт в чеклисте, а процесс
Если вам повезло и у вас есть живой domain expert — берегите его! Но чаще всего их приходится выращивать внутри компании.
DDD говорит: доменный эксперт — это не титул, а функция.
Это может быть продакт, клиент, юрист, кастомер-саппорт — тот, кто лучше других понимает бизнес-правила в конкретной области.
🧩 На этапе сбора требований это значит:
— слушать больше,
— задавать наводящие вопросы,
— и замечать, кто из собеседников реально может объяснить, почему система устроена именно так.

5. Где сложности?
💭 Бизнес не привык мыслить через модели. Ему нужно «чтобы работало», а не «bounded context с единым языком».
🤢 Слово “домен” часто вызывает отторжение. Его путают с “сферой” или ДАЖЕ “базой данных”.
🤝 Нет привычки к коллаборации. Распространена модель «продукт пишет ТЗ → разработка делает».
DDD требует совместного проектирования.

6. Коллаборация — главный инструмент
Если на этом этапе вы не сделали язык совместным, никакой code-first не спасет.
Поэтому:
– Стенормьте встречи с разными ролями
– Пробуйте фасилитации (Event Storming прекрасно заходит с бизнесом)
– Делайте схемы, рисуйте!
– И фиксируйте все: термины, допущения, ограничения, цели

Следующий пост (завтра) — про архитектуру и проектирование.
💬 А пока расскажите: на вашем проекте язык между командами был единым? Или каждый понимал по-своему?

#architecture #ddd

🏗 Как DDD помогает на этапе архитектуры и проектирования

1. Делит по смыслу, а не по слоям
DDD предлагает смотреть на систему как на совокупность смысловых контекстов, а не просто «вот тут сервис, вот тут контроллер».
Архитектура строится по бизнес-логике, а не по технологическим паттернам.
→ Вместо «сервис каталога» — «управление товарными категориями».
→ Вместо «бэк-офис» — «расчет комиссий».
📦 Это дает:
— ясные границы владения данными и логикой,
— меньше связей между частями системы,
— выше устойчивость к изменениям.

2. Позволяет не смешивать несовместимое
Если в одном модуле встречаются и бизнес-логика, и интеграции, и админ-панель, и метрики — это все пахнет монолитом боли (но не всегда! И, да, только на длительной дистанции!).
DDD подсказывает: все, что живет по разным правилам — должно жить в разных контекстах.
🧠 Пример: расчет пеней по кредитам и формирование/выдача индивидуальных кредитов — разные контексты. Разный язык, разная частота изменений, разные источники истины.

3. Как мешает (если применять неправильно)
— Переусложнение на старте
Выделять bounded context ради bounded context — вредно.
Если вы на MVP стадии и продукт еще не понял сам себя — не надо ваять архитектуру на 100 лет вперед.
— Слишком формально
DDD — это не UML и не жесткий шаблон.
Если вы пишете спецификацию на каждый value object, но не можете поговорить с бизнесом — это не DDD, это бюрократия.

4. Связь с языком и контекстами
Каждое архитектурное решение должно проходить через язык:

— Как называется эта часть?
— Какие слова в ней допустимы?
— В каком контексте они значат то, что значат?

Если внутри одного bounded context у вас есть «user», который одновременно и платит, и нанимает, и модератор — это уже тревожный звонок.
🎯 Проверка: можно ли без ошибок перевести требования бизнеса в термины архитектуры?

5. Как проверять деление на домены и замкнутость контекстов
— Есть ли своя модель данных?
— Есть ли уникальные бизнес-правила?
— Меняются ли эти правила независимо от других частей?
— Понимает ли одна и та же команда, как это работает?
— Можно ли заменить этот контекст без масштабного рефакторинга всей системы?
Если «да» — у вас скорее всего здоровый bounded context.

🤔 Всегда ли нужно?
Нет. Если у вас микропроект на 3 человека — достаточно здравого смысла.
Но если проект растет, появляется несколько команд, увеличивается сложность, разрастается предметная область — без архитектурных принципов DDD вы начнете тонуть в хаосе.

Практические примеры (финтех):
Интернет-банк разбивается на контексты: «Accounts» (Счета), «Payments» (Платежи), «Loans» (Кредиты), «Cards» (Карты), «Analytics/Reporting» (Отчеты). Каждый из них соответствует своей части бизнеса и управляется отдельной командой. Например, команда контекста Payments владеет всем, что связано с переводами: у них свой словарь (платеж, транзакция, комиссионные и т.д.) и своя кодовая база. В другом контексте Accounts – свой словарь (баланс, счет, клиент и т.п.). Эти команды работают параллельно, а взаимодействуют их сервисы через четко определенные API. При этом термин «Transaction» в контексте платежей имеет одно значение (конкретное движение денег), а в контексте аналитики, скажем, это может быть абстрактный объект для агрегированной статистики. Благодаря DDD эти понятия разведены: без выделения контекстов компания получила бы единую громоздкую систему, где разные отделы говорили бы «транзакция» о разном и путали друг друга. 
В этом примере команда Accounts и команда Payments могут работать автономно, выпуская изменения независимо – изменение в сервисе счетов не сломает сервис платежей, если контракт (например, API запроса баланса) остался прежним.

В понедельник поговорим про разработку и реализацию, а пока:
💬 Ваша архитектура отражает бизнес? Или просто похожа на «все как у людей»?

#architecture #ddd

💻 Что значит “разработка по DDD”?

Продолжаю серию постов по DDD. А если пропустили, то: пост1 и пост2.

Внезапно DDD не про «сделать микросервис» или «назвать package domain».
DDD в на уровне реализации — это когда код говорит на том же языке, что и бизнес, и этот язык не ломается по дороге от требования до продакшна.
Да, та самая проекция бизнеса на код!

1. Что это дает:
🧠 Проекция модели
Главый постулат: бизнес-логика в коде = бизнес-логика в головах.
Сервис PaymentLimitChecker вместо SomeUtils.calculate() — и уже ясно, о чем речь.
📚 Код как документ
Не надо искать ТЗ или копаться в Confluence. Код читается как описание предметной области — потому что оно и есть.
А еще проще онбодинг, а вся компания на шаг ближе к обезличенному коду.
🧩 Модулярность не по слоям, а по смыслу
Если бизнес-правило живет в отдельной сущности, его легче тестировать, изменять и обсуждать.
А если вся логика в контроллере — нет ни контроля, ни логики.

2. Когда DDD мешает:
— если вы «наслоили паттернов», но никто не понимает, зачем эти ValueObject и Aggregate;
— если всt ради красоты — но бизнес до сих пор зовет кнопку «фильтр» там, где в коде OperationController.

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

4. DDD != антипаттерн слоев, как и DDD != слои
Если ваша архитектура:
- слой контроллеров
- слой сервисов
- слой API
…и все это в одном Bounded Context — это еще не DDD.
Так же как и запиленный небольшой монолитик, но если он Bounded Context вполне может быть DDD.

Бизнес говорит: «нельзя переводить больше 300 000₽ в сутки».
Вы:
1) не хардкодите «300000» в 5 местах,
2) создаете TransferLimit и Policy,
3) называете метод canTransferToday(amount)
И этим создаете язык, на котором можно говорить с бизнесом — в коде.

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

Завтра — про тестирование: как проверять поведение, а не строки.
💬 А у вас код с бизнесом на одном языке?

#architecture #ddd

Добавим в интеллектуальное немного 🤏 «веселенького»…

Делюсь любимыми шуточками про DDD:

DDD — это когда ты потратил 3 месяца, чтобы объяснить бэкенду, что «заказ» и «подписка» — не одно и то же.
И еще 3 месяца — чтобы поверить в это самому.

— У нас 4 команды, один домен.
— Это не DDD, это shared trauma.

Когда архитекторы говорят "bounded context", они имеют в виду "давайте разойдемся и не будем пересекаться".

🧪 Тесты при DDD — инструмент контроля поведения.

1. Тестируется поведение, а не реализация
Мы не проверяем, что метод вернул массив из 4 элементов.
Мы проверяем, что при таких входных данных InvoiceLimitPolicy запрещает оплату.
Это называется specification by example — описание бизнес-логики через конкретные кейсы.


2. Тест в связке с бизнес-языком
Тест test_cannot_exceed_limit_for_vip_clients читается без перевода.
Никаких «тестируем что метод х вызвал метод у». Мы проверяем бизнес-правила, а не детали реализации.

3. Плюсы:
✅ Повышается устойчивость к изменениям — вы можете менять реализацию, пока поведение не ломается.
✅ Тесты = документация. Для нового разработчика часто тест — первый вход в контекст.
✅ Бизнес понимает, о чем речь, а еще им можно «сплавить» проверку тестовых сценариев (и они их проверяют лучше команды разработки).

4. Минусы:
− Это требует времени и дисциплины. Легче протестировать функцию, чем поведение домена.
− Иногда сложно определить границы — а это уже вопрос к архитектуре.

5. Качество ≠ Тесты
Тестов может быть много, а система — неудобной, сложной, не отражающей суть бизнеса.
В DDD качество = насколько хорошо система отражает домен:
− насколько точно реализованы правила,
− насколько понятно поведение,
− насколько просто объяснить, что делает система.
И здесь тестирование — лишь один из инструментов обеспечения качества, наряду с ubiquitous language, совместным проектированием и проверками модели.

6. А при чем тут TDD?
TDD (Test-Driven Development) идеально сочетается с DDD:
− сначала описываешь поведение,
− потом реализуешь,
− потом рефакторишь, не боясь поломать.
Но важно: TDD — это не про «сперва написать тест», а про мышление через поведение.
DDD-тесты не про проверку кода, а про проверку бизнес-правды.
Когда пользователь говорит: «у нас нельзя так делать», а ты открываешь тест и видишь — да, нельзя. Или, наоборот, понимаешь, что это поведение вытекает из старой логики и требует пересмотра.

Завтра — финальный пост: пост-документация и ее смысл в DDD.
💬 А у вас тесты — это safety net или описание модели?

#architecture #ddd

📚 Что такое пост-документация в DDD?

Все, финальная часть про DDD.
Весь путь: про стейкхолдеров и бизнес, про проектирование, про разработку, про тестирование.

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

1. Зачем вообще она нужна?
📉 Модели теряются. Через 6 месяцев никто не помнит, почему Transaction и Adjustment — это два разных агрегата.
💬 Команда меняется. Новичкам сложно въехать в неочевидные решения.
🧩 Интеграции множатся. Без явной документации контексты путаются, границы стираются, начинается ад из «просто использовали не по назначению чужую сущность».
🤒 Клиенты (любых видов) не должны страдать. А значит им нужна своевременная и понятная документация на их языке.

2. Что фиксируем:
Bounded Context-ы:
— их границы, название, бизнес-смысл
— где их API, с кем они взаимодействуют
Ubiquitous Language:
— глоссарий терминов
— амбигуозности
— кто как называет “клиента” и “транзакцию” — и почему
Доменные модели:
— диаграммы (в т.ч. Event Storming)
— паттерны, которые вы внедрили
— архитектурные компромиссы, которые пришлось принять
Бизнес-решения:
— почему поведение системы именно такое
— какая гипотеза лежала в основе
— что было сделано «временным решением» (и когда его пересматривать)

3. В чем особенность DDD-документации:
Она пишется на языке бизнеса, а не только техническом.
Она живет рядом с кодом — в wiki, в ADR-нотах, в репозиториях, а не в спрятанных PDF.
Она строится по мере развития модели, а не «в конце проекта».

4. А в чем сложность?
– Нужен тот, кто будет ее писать! Бизнес считает, что документация — дело разработчиков. Разработчики считают, что это «долго и не нужно».
– Стоимость! Никто не хочет платить за «ничего» — а ведь пост-документация и есть ваш антидолг. Она сохраняет знания, которые иначе потеряются.
В DDD документация логично завершает каждый виток моделирования.

Отдельно про финтех: Финансовые организации зачастую должны готовить документацию для регуляторов или партнеров. DDD здесь – палочка-выручалочка, потому что наличие четкой модели и терминологии позволяет сравнительно легко написать необходимые описания. Например, для сертификации PCI DSS может потребоваться описать потоки данных карточных транзакций – команда, имея на руках контекстную диаграмму и описание событий, подготовит такой документ быстрее.

#architecture #ddd

🤷‍♀️ «Делегируй или умри» — продолжаю обучение на курсе Стратоплана

Лучше поздно, чем никогда — мой обзор 2ой трехдневки на курсе для CTO от Стратоплана.
Тема звучала мощно: «Делегируй или умри»...
На деле... нам делегировали изучить делегирование.
А теперь по порядку!

Почему не писала раньше?
Во-первых, я и сам модуль слушала в разъездах — из Кипра через Ереван в Россию (СПб, МСК, СПб) и обратно. И еще в этих разъездах работала + ProITFest. А потом... просто все накопилось и навалилось!
Во-вторых, это пока самый спорный модуль для меня. А о спорном писать сложно! А я стараюсь писать честно, а не по инерции (на эмоциях).

Разбор по дням:
День 1 — про delivery, организацию поставки, каналы взаимодействия.
Неплохо, но делегирования не было. Просто не было.
День 2 — про процессы, работу с CEO (если он в командировках или на сцене), баланс между хаосом и структурой.
👉 Самый сильный день (спасибо Роме Иевлеву!). Именно за такими штуками я и пришла на курс — когда делятся живыми историями, когда видно, как оно «бывает на самом деле».
День 3 — про операционку, модель Cynefin, ITSM, ITIL.
Мы читали стандарты, обсуждали, зачем они нужны… но зачем нам это было здесь и сейчас — я так и не поняла. А главное: зачем "мы читали то, что мы уже читали"?

Что не зашло:
◾️ Ощущение разбалансировки между названием модуля и его содержанием.
◾️ Дискуссии в чате в конце модуля свелись к вопросу: а где тут вообще про делегирование?..
◾️ Геймификация — выглядит странно. Есть правильный ответ, и даже если ты можешь логично и уверенно обосновать другой — тебе говорят: «Ну, CEO (в игре) решил иначе». И ты не прав.
Да, это правда жизни. И такое бывает! Но в реальной жизни у тебя есть шанс влиять. А тут — нет. И это не обучает, а фрустрирует.
◾️ В кейсах мало обратной связи и мало обсуждения реальных решений. Просто: вот кейс, вот «правильный» ответ. Все.

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

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

Так что ждем!
Может, просто модуль был не мой...
В любом случае — двигаемся дальше.
👀 Посмотрим, что будет.

👨‍🦳 Возрастной парадокс найма 👵

На последней 3хдневке Стратоплана Рома Ивлиев сказал фразу, которая у меня до сих пор не отпускает:

«Люди достигают точки, когда им необходимо либо перепрофилироваться, либо не менять среду, в которой они находятся».

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

Возрастной парадокс найма — штука, которую многие чувствуют, но редко называют.
С одной стороны, входной порог профессий объективно снижается: благодаря ИИ стажеры могут делать относительно сложные штуки, не понимая даже, как именно они работают.
С другой — компании все равно жалуются, что некого нанимать.
И тут уже не только про навыки, но и про демографию. Так как некогда молодая отрасль в которой мы привыкли к "детям" стареет, а вместе с ней и "дети" становятся "бабушками и дедушками"!

🔹 В США уже 34% рабочей силы — старше 50 лет.
🔹 В странах EU к 2031 году терть сотрудников будет 55+.
🔹 В среднем по OECD 41% работающих — в возрастной группе 45–64.
🔹 И все это — устойчивый рост. Молодых становится меньше, старших — больше. И живут они дольше.

Но теперь парадокс.
На фоне этих цифр компании все еще проектируют процессы так, как будто их сотрудникам 25:
open space, перегруженные чаты, культура always-on, срочные дедлайны под шумный тимбилдинг и мотивация пуфиком.
И полное игнорирование тех, кто пережил не одну трансформацию и мог бы много рассказать — если бы их вообще спросили.

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

🔍 OECD прямо пишет:
если компании хотят выжить в демографическом сдвиге — придется адаптироваться!
Это не абстрактное уважение к старшим.
Это:
— нормальные условия (свет, кресла, возможность сосредоточиться),
— гибкий график и разумная гибридность,
— переобучение и мобильность,
— и вообще-то — пересборка культуры.

Потому что в одной компании уже сейчас работают:
— Инженер, который автоматизировал заводы еще в 90-х и до сих пор хранит скрипты на bash на флешке
— Team lead, которому 34, у него синдром самозванца, коуч, и чек-лист «как не выгореть снова»
— Джуниор-дизайнер, выросший на Figma и TikTok, и не понимающий, зачем вообще бывают PNG без прозрачности
— CISO, у которого два диплома, военная выправка и привычка делать бэкапы всего, включая календарь совещаний
И никакой HR-квест их не склеит.
А вот экосистема микрокультур, в которой каждому найдется язык и место — может.

Но пока большинство компаний еще делает вид, что у всех сотрудников — одна скорость, одна мотивация и один ритм.

💬Не знаю, как вас, но меня цифры, зацепили... Ведь я тоже не молодею...

🤡 Немного кринжовый пост про ТолстоБорова 🐗

Сегодня слегка комичный пост — навеян личными событиями и флешбеками былого. Когда я была юной и амбициозной (и немного наивной), один из первых руководителей дал мне совет, который до сих пор считаю золотым:

✨ ОТКЛЮЧИ НОТИФИКАЦИИ ВЕЗДЕ.

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

🔕 1. Никаких текстов в нотификациях. НИ-Г-ДЕ.
Только имя отправителя. Без текста. Без превью. Ни в Telegram, ни в Slack, ни на экране телефона.
Почему? Потому что однажды, когда я ходила по министерствам РФ (да-да, было и такое), во время переговоров у коллеги всплыло сообщение на экране ноутбука:

«Ну че там ТолстоБоров (кулуарное имя некого пухлого человека из некого министерства)?»

Скажем так: ничто так не добавляет любви представителя министерства, как слово "ТолстоБоров" крупным шрифтом на ноуте, аккуратно поставленном перед ним. С тех пор — нотификации только с именами. И никаких подробностей. Даже на часах и телефоне!

💬 2. ВСЕГДА проверяй, в какой чат ты пишешь.
Это не шутка. Это спасло мне карьеру пару раз.
Один раз я, уставшая, увидев в чате вопрос: «Ну че там?», в ответ написала:

«Да они, как всегда п.......»

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

«попросили время на ответ, поэтому мы зависли в ожидании решения».

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

🔇 3. Вяканье — враг. Выключай звук. ВЕЗДЕ.
Телефон. Ноутбук. Браузер. Slack. Все в молчаливом режиме. Потому что хуже, чем вякающий Telegram в момент демо перед СЕО, может быть только одно — вякающий Telegram, когда ты пытаешься что-то серьезное сказать и делаешь умное лицо.
Исключение — PagerDuty или аналог. Но только при условии, что у вас хорошо настроен инцидент-менеджмент, и не орет каждый раз, когда кто-то упал тест.

🎂 4. Дни рождения. Telegram — спасибо.
Я вообще не любитель поздравлений по календарю (да и без календаря...). Но Telegram теперь показывает, у кого др, и я завела привычку кидать пару строк тем, кого знаю. Иногда добавляю:

«О, помню, как мы тогда в Питере в мае 2022...»

Работает! Люди отвечают. Вспоминают. Нетворк оживает. Просто, эффективно и никакой LinkedIn не нужен.

🪞 5. Обратная связь — прямо в лицо.
Если кандидат не подходит — говорю сразу, прямо на собеседовании. Без «мы подумаем». Почему? Потому что кандидат — не идиот. Он и сам понимает, что «мы перезвоним» чаще значит «нет».
То же самое в обратную сторону: если я понимаю, что с компанией у нас не складывается (а собеседуют меня), то говорю это HR напрямую. Без танцев с бубнами. Все мы хорошие, но не друг для друга. И это нормально.

👀 Думаю, этот список можно продолжать бесконечно. Вот мои дополнительные мини-правила:
– Никогда не пишу сообщение до первой чашки кофе. А то я не те буквы читаю!
– Переименовываю чаты, и людей, чтобы случайно не перепутать «босс» и «басс», не вспоминать кто такой AK (Коля, если ты это читаешь, то это про тебя).
– Не ставлю 👍 на сообщения, которые я на самом деле не прочла.
– В Zoom проверяю фон. Всегда. Потому что Пес и бардак сзади — еще ладно. А вот кружка с надписью «I hate meetings» — нет.

💬 Поделитесь своими, пжл!