🏗 Как 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 вы начнете тонуть в хаосе.
В понедельник поговорим про разработку и реализацию, а пока:
💬 Ваша архитектура отражает бизнес? Или просто похожа на «все как у людей»?
#architecture #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
👍9❤2
📚 Как Катя учит язык 🚉
Я вас тут начала грузить постами про DDD и, кажется, они даже кому-то заходят. Но по-настоящему, конечно, все фанатеют от моих постов про то, как я учу язык. Так вот — выходной, значит, давайте про язык.
На этой неделе я узнала несколько отличных слов — причем интересных не только с точки зрения английского, но и с точки зрения русского.
Во-первых: «вокзал». Весь мир использует слово station — это железнодорожная станция, точка на маршруте. А только в русском есть специальное слово для здания при станции — «вокзал».
Что особенно забавно: это заимствование из английского — но искаженное и переосмысленное. История такая: в 1830-х, когда строили первую железную дорогу от Петербурга до Царского Села, англичане поставляли чертежи и оборудование. На одном из чертежей было написано Vauxhall Station — по названию района в Лондоне. Русские инженеры решили, что «Vauxhall» — это не название, а общее слово для здания при станции. И с тех пор у нас появился «вокзал».
Это один из тех примеров, когда слово, попадая из одного языка в другой, приобретает новое значение, которого в исходном языке не было. Отсюда — логичный мостик ко второй теме: словам, которые описывают двойственность.
Если вы читали мой первый пост про DDD, вы могли заметить термин «амбигуозность». Если вы попытаетесь загуглить его, Google вежливо поправит: «Вы имели в виду амбициозность?» — Нет, не имеете! Так как слово такое действительно существует!
Ambiguity / ambiguous — это устойчивый английский термин, особенно в юридическом и инженерном контексте. Он обозначает неопределенность, двусмысленность, невозможность однозначной трактовки. Например: ambiguous clause в контракте, который допускает разные интерпретации. В русском же языке почти никто не говорит «амбигуозный». Вместо этого — «неясность формулировки», «двойственное толкование», «правовая коллизия», а иногда — «аморфность».
Но есть одно слово (тоже связано с двойственностью), которое в русском и английском совпадает — это «амбивалентность».
Первоначально это химический термин: он описывает элемент, способный проявлять разные валентности — то есть, присоединять различное число связей, в зависимости от условий. Например, железо может быть Fe²⁺ или Fe³⁺ — это разные степени окисления, то есть разные валентности.
Позже термин перекочевал в психологию, и уже там приобрел значение одновременного наличия противоположных чувств или оценок к одному объекту. Амбивалентность — это когда вы любите и злитесь одновременно. Или — хотите перемен, но боитесь. То есть снова — двойственность, но на уровне эмоций и восприятия.
Вот такой вот мир языковых и смысловых сдвигов.
А на фото — та самая станция Vauxhall и Витебский вокзал, с которых все и началось.
Я вас тут начала грузить постами про DDD и, кажется, они даже кому-то заходят. Но по-настоящему, конечно, все фанатеют от моих постов про то, как я учу язык. Так вот — выходной, значит, давайте про язык.
На этой неделе я узнала несколько отличных слов — причем интересных не только с точки зрения английского, но и с точки зрения русского.
Во-первых: «вокзал». Весь мир использует слово station — это железнодорожная станция, точка на маршруте. А только в русском есть специальное слово для здания при станции — «вокзал».
Что особенно забавно: это заимствование из английского — но искаженное и переосмысленное. История такая: в 1830-х, когда строили первую железную дорогу от Петербурга до Царского Села, англичане поставляли чертежи и оборудование. На одном из чертежей было написано Vauxhall Station — по названию района в Лондоне. Русские инженеры решили, что «Vauxhall» — это не название, а общее слово для здания при станции. И с тех пор у нас появился «вокзал».
Это один из тех примеров, когда слово, попадая из одного языка в другой, приобретает новое значение, которого в исходном языке не было. Отсюда — логичный мостик ко второй теме: словам, которые описывают двойственность.
Если вы читали мой первый пост про DDD, вы могли заметить термин «амбигуозность». Если вы попытаетесь загуглить его, Google вежливо поправит: «Вы имели в виду амбициозность?» — Нет, не имеете! Так как слово такое действительно существует!
Ambiguity / ambiguous — это устойчивый английский термин, особенно в юридическом и инженерном контексте. Он обозначает неопределенность, двусмысленность, невозможность однозначной трактовки. Например: ambiguous clause в контракте, который допускает разные интерпретации. В русском же языке почти никто не говорит «амбигуозный». Вместо этого — «неясность формулировки», «двойственное толкование», «правовая коллизия», а иногда — «аморфность».
Но есть одно слово (тоже связано с двойственностью), которое в русском и английском совпадает — это «амбивалентность».
Первоначально это химический термин: он описывает элемент, способный проявлять разные валентности — то есть, присоединять различное число связей, в зависимости от условий. Например, железо может быть Fe²⁺ или Fe³⁺ — это разные степени окисления, то есть разные валентности.
Позже термин перекочевал в психологию, и уже там приобрел значение одновременного наличия противоположных чувств или оценок к одному объекту. Амбивалентность — это когда вы любите и злитесь одновременно. Или — хотите перемен, но боитесь. То есть снова — двойственность, но на уровне эмоций и восприятия.
Вот такой вот мир языковых и смысловых сдвигов.
А на фото — та самая станция Vauxhall и Витебский вокзал, с которых все и началось.
🔥11👍9😁5❤4
💻 Что значит “разработка по 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.
DDD в реализации — не стиль кода. Это инструмент для мышления, который позволяет писать системы, которые будут жить, а не сползать в баги и затычки.
Завтра — про тестирование: как проверять поведение, а не строки.
💬 А у вас код с бизнесом на одном языке?
#architecture #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
Telegram
ITKatya: культурные паттерны в IT
🧠 Что дает DDD на этапе сбора требований и всех этапах взаимодействия с бизнесом?
1. Сбор требований — это не просто список хотелок
В DDD важно не просто услышать, что «нужно сделать кнопку», а понять, в каком домене живет эта кнопка, какую бизнес-ценность…
1. Сбор требований — это не просто список хотелок
В DDD важно не просто услышать, что «нужно сделать кнопку», а понять, в каком домене живет эта кнопка, какую бизнес-ценность…
👍6❤5✍1
Добавим в интеллектуальное немного 🤏 «веселенького»…
Делюсь любимыми шуточками про DDD:
Делюсь любимыми шуточками про DDD:
DDD — это когда ты потратил 3 месяца, чтобы объяснить бэкенду, что «заказ» и «подписка» — не одно и то же.
И еще 3 месяца — чтобы поверить в это самому.
— У нас 4 команды, один домен.
— Это не DDD, это shared trauma.
Когда архитекторы говорят "bounded context", они имеют в виду "давайте разойдемся и не будем пересекаться".
😁9👍1💯1
🧪 Тесты при 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
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
👍6❤4🤓1
📚 Что такое пост-документация в 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
Все, финальная часть про 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
❤3👍3
С нами все хорошо!
Сегодня была самая сложная и самая страшная ночь на Кипре.
На острове трагедия! Случились 2 пожара, один из которых рекордный. Но, сейчас огонь взят под контроль.
Очень сложно описать чувства, когда вы следите всю ночь за распространением огня, ждете, что к вам в любую минуту могут приехать друзья, кого эвакуируют, пытаетесь понять нужно ли будет эвакуироваться вам.
Но сейчас-утро, и все хорошо. Остров восстановится и отстроится. А внутри только очень много благодарности и признательности тем, кто всю ночь противостоял стихии!
Сегодня была самая сложная и самая страшная ночь на Кипре.
На острове трагедия! Случились 2 пожара, один из которых рекордный. Но, сейчас огонь взят под контроль.
Очень сложно описать чувства, когда вы следите всю ночь за распространением огня, ждете, что к вам в любую минуту могут приехать друзья, кого эвакуируют, пытаетесь понять нужно ли будет эвакуироваться вам.
Но сейчас-утро, и все хорошо. Остров восстановится и отстроится. А внутри только очень много благодарности и признательности тем, кто всю ночь противостоял стихии!
🙏34😢2👀1🙈1
🤷♀️ «Делегируй или умри» — продолжаю обучение на курсе Стратоплана
Лучше поздно, чем никогда — мой обзор 2ой трехдневки на курсе для CTO от Стратоплана.
Тема звучала мощно: «Делегируй или умри»...
На деле... нам делегировали изучить делегирование.
А теперь по порядку!
Почему не писала раньше?
Во-первых, я и сам модуль слушала в разъездах — из Кипра через Ереван в Россию (СПб, МСК, СПб) и обратно. И еще в этих разъездах работала + ProITFest. А потом... просто все накопилось и навалилось!
Во-вторых, это пока самый спорный модуль для меня. А о спорном писать сложно! А я стараюсь писать честно, а не по инерции (на эмоциях).
Разбор по дням:
День 1 — про delivery, организацию поставки, каналы взаимодействия.
Неплохо, но делегирования не было. Просто не было.
День 2 — про процессы, работу с CEO (если он в командировках или на сцене), баланс между хаосом и структурой.
👉 Самый сильный день (спасибо Роме Иевлеву!). Именно за такими штуками я и пришла на курс — когда делятся живыми историями, когда видно, как оно «бывает на самом деле».
День 3 — про операционку, модель Cynefin, ITSM, ITIL.
Мы читали стандарты, обсуждали, зачем они нужны… но зачем нам это было здесь и сейчас — я так и не поняла. А главное: зачем "мы читали то, что мы уже читали"?
Что не зашло:
◾️ Ощущение разбалансировки между названием модуля и его содержанием.
◾️ Дискуссии в чате в конце модуля свелись к вопросу: а где тут вообще про делегирование?..
◾️ Геймификация — выглядит странно. Есть правильный ответ, и даже если ты можешь логично и уверенно обосновать другой — тебе говорят: «Ну, CEO (в игре) решил иначе». И ты не прав.
Да, это правда жизни. И такое бывает! Но в реальной жизни у тебя есть шанс влиять. А тут — нет. И это не обучает, а фрустрирует.
◾️ В кейсах мало обратной связи и мало обсуждения реальных решений. Просто: вот кейс, вот «правильный» ответ. Все.
Что осталось в голове?
Честно? Немного.
И не потому, что я слушала в дороге. А потому, что не зацепило.
Не то, чтобы это было плохо. Просто это не то, что мне нужно.
Не «мякотка», как я называю — когда люди рассказывают, как у них было по-настоящему, а не как в книжке. Когда ты можешь сравнить, переосмыслить, задать вопрос, получить фидбэк.
А дальше?
Сегодня начинается новая трехдневка — про бизнес и тех-стратегии.
Вот на нее у меня очень большие ожидания.
Потому в компаниях, где я работала, я строила техническую стратегию — в связке с культурой, продуктом, бизнес-целями.
И мне очень хочется увидеть, как это делают другие.
Какие у других границы между тех и бизнес-частью. Как они миксуют.
Какие паттерны используют, а какие — обожглись и больше не трогают.
Так что ждем!
Может, просто модуль был не мой...
В любом случае — двигаемся дальше.
👀 Посмотрим, что будет.
Лучше поздно, чем никогда — мой обзор 2ой трехдневки на курсе для CTO от Стратоплана.
Тема звучала мощно: «Делегируй или умри»...
На деле... нам делегировали изучить делегирование.
А теперь по порядку!
Почему не писала раньше?
Во-первых, я и сам модуль слушала в разъездах — из Кипра через Ереван в Россию (СПб, МСК, СПб) и обратно. И еще в этих разъездах работала + ProITFest. А потом... просто все накопилось и навалилось!
Во-вторых, это пока самый спорный модуль для меня. А о спорном писать сложно! А я стараюсь писать честно, а не по инерции (на эмоциях).
Разбор по дням:
День 1 — про delivery, организацию поставки, каналы взаимодействия.
Неплохо, но делегирования не было. Просто не было.
День 2 — про процессы, работу с CEO (если он в командировках или на сцене), баланс между хаосом и структурой.
👉 Самый сильный день (спасибо Роме Иевлеву!). Именно за такими штуками я и пришла на курс — когда делятся живыми историями, когда видно, как оно «бывает на самом деле».
День 3 — про операционку, модель Cynefin, ITSM, ITIL.
Мы читали стандарты, обсуждали, зачем они нужны… но зачем нам это было здесь и сейчас — я так и не поняла. А главное: зачем "мы читали то, что мы уже читали"?
Что не зашло:
◾️ Ощущение разбалансировки между названием модуля и его содержанием.
◾️ Дискуссии в чате в конце модуля свелись к вопросу: а где тут вообще про делегирование?..
◾️ Геймификация — выглядит странно. Есть правильный ответ, и даже если ты можешь логично и уверенно обосновать другой — тебе говорят: «Ну, CEO (в игре) решил иначе». И ты не прав.
Да, это правда жизни. И такое бывает! Но в реальной жизни у тебя есть шанс влиять. А тут — нет. И это не обучает, а фрустрирует.
◾️ В кейсах мало обратной связи и мало обсуждения реальных решений. Просто: вот кейс, вот «правильный» ответ. Все.
Что осталось в голове?
Честно? Немного.
И не потому, что я слушала в дороге. А потому, что не зацепило.
Не то, чтобы это было плохо. Просто это не то, что мне нужно.
Не «мякотка», как я называю — когда люди рассказывают, как у них было по-настоящему, а не как в книжке. Когда ты можешь сравнить, переосмыслить, задать вопрос, получить фидбэк.
А дальше?
Сегодня начинается новая трехдневка — про бизнес и тех-стратегии.
Вот на нее у меня очень большие ожидания.
Потому в компаниях, где я работала, я строила техническую стратегию — в связке с культурой, продуктом, бизнес-целями.
И мне очень хочется увидеть, как это делают другие.
Какие у других границы между тех и бизнес-частью. Как они миксуют.
Какие паттерны используют, а какие — обожглись и больше не трогают.
Так что ждем!
Может, просто модуль был не мой...
В любом случае — двигаемся дальше.
👀 Посмотрим, что будет.
❤7👍7🔥4
ITKatya: культурные паттерны в IT pinned «🤷♀️ «Делегируй или умри» — продолжаю обучение на курсе Стратоплана Лучше поздно, чем никогда — мой обзор 2ой трехдневки на курсе для CTO от Стратоплана. Тема звучала мощно: «Делегируй или умри»... На деле... нам делегировали изучить делегирование. А теперь…»
👨🦳 Возрастной парадокс найма 👵
На последней 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-квест их не склеит.
А вот экосистема микрокультур, в которой каждому найдется язык и место — может.
Но пока большинство компаний еще делает вид, что у всех сотрудников — одна скорость, одна мотивация и один ритм.
💬Не знаю, как вас, но меня цифры, зацепили... Ведь я тоже не молодею...
На последней 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-квест их не склеит.
А вот экосистема микрокультур, в которой каждому найдется язык и место — может.
Но пока большинство компаний еще делает вид, что у всех сотрудников — одна скорость, одна мотивация и один ритм.
💬Не знаю, как вас, но меня цифры, зацепили... Ведь я тоже не молодею...
🔥19❤16👍4❤🔥2🤗1
🤡 Немного кринжовый пост про ТолстоБорова 🐗
Сегодня слегка комичный пост — навеян личными событиями и флешбеками былого. Когда я была юной и амбициозной (и немного наивной), один из первых руководителей дал мне совет, который до сих пор считаю золотым:
И вот с тех пор у меня накопился список цифровых правил выживания, которые я применяю всегда и везде, независимо от должности, компании и градуса хаоса вокруг. Делюсь.
🔕 1. Никаких текстов в нотификациях. НИ-Г-ДЕ.
Только имя отправителя. Без текста. Без превью. Ни в Telegram, ни в Slack, ни на экране телефона.
Почему? Потому что однажды, когда я ходила по министерствам РФ (да-да, было и такое), во время переговоров у коллеги всплыло сообщение на экране ноутбука:
Скажем так: ничто так не добавляет любви представителя министерства, как слово "ТолстоБоров" крупным шрифтом на ноуте, аккуратно поставленном перед ним. С тех пор — нотификации только с именами. И никаких подробностей. Даже на часах и телефоне!
💬 2. ВСЕГДА проверяй, в какой чат ты пишешь.
Это не шутка. Это спасло мне карьеру пару раз.
Один раз я, уставшая, увидев в чате вопрос: «Ну че там?», в ответ написала:
и ты уже чувствуешь, к чему идет, да?
Отправила это не коллеге, а человеку из той самой компании, про которую была речь. Слава богу, я поставила слишком много точек и моментально переписала:
Итог: выглядело, как будто я просто случайно нажала Enter недописав и заваж .............
Поэтому в чатах я теперь вначале дышу, потом жму ОТПРАВИТЬ. Не шучу.
🔇 3. Вяканье — враг. Выключай звук. ВЕЗДЕ.
Телефон. Ноутбук. Браузер. Slack. Все в молчаливом режиме. Потому что хуже, чем вякающий Telegram в момент демо перед СЕО, может быть только одно — вякающий Telegram, когда ты пытаешься что-то серьезное сказать и делаешь умное лицо.
Исключение — PagerDuty или аналог. Но только при условии, что у вас хорошо настроен инцидент-менеджмент, и не орет каждый раз, когда кто-то упал тест.
🎂 4. Дни рождения. Telegram — спасибо.
Я вообще не любитель поздравлений по календарю (да и без календаря...). Но Telegram теперь показывает, у кого др, и я завела привычку кидать пару строк тем, кого знаю. Иногда добавляю:
Работает! Люди отвечают. Вспоминают. Нетворк оживает. Просто, эффективно и никакой LinkedIn не нужен.
🪞 5. Обратная связь — прямо в лицо.
Если кандидат не подходит — говорю сразу, прямо на собеседовании. Без «мы подумаем». Почему? Потому что кандидат — не идиот. Он и сам понимает, что «мы перезвоним» чаще значит «нет».
То же самое в обратную сторону: если я понимаю, что с компанией у нас не складывается (а собеседуют меня), то говорю это HR напрямую. Без танцев с бубнами. Все мы хорошие, но не друг для друга. И это нормально.
👀 Думаю, этот список можно продолжать бесконечно. Вот мои дополнительные мини-правила:
– Никогда не пишу сообщение до первой чашки кофе. А то я не те буквы читаю!
– Переименовываю чаты, и людей, чтобы случайно не перепутать «босс» и «басс», не вспоминать кто такой AK (Коля, если ты это читаешь, то это про тебя).
– Не ставлю 👍 на сообщения, которые я на самом деле не прочла.
– В Zoom проверяю фон. Всегда. Потому что Пес и бардак сзади — еще ладно. А вот кружка с надписью «I hate meetings» — нет.
💬 Поделитесь своими, пжл!
Сегодня слегка комичный пост — навеян личными событиями и флешбеками былого. Когда я была юной и амбициозной (и немного наивной), один из первых руководителей дал мне совет, который до сих пор считаю золотым:
✨ ОТКЛЮЧИ НОТИФИКАЦИИ ВЕЗДЕ.
И вот с тех пор у меня накопился список цифровых правил выживания, которые я применяю всегда и везде, независимо от должности, компании и градуса хаоса вокруг. Делюсь.
🔕 1. Никаких текстов в нотификациях. НИ-Г-ДЕ.
Только имя отправителя. Без текста. Без превью. Ни в Telegram, ни в Slack, ни на экране телефона.
Почему? Потому что однажды, когда я ходила по министерствам РФ (да-да, было и такое), во время переговоров у коллеги всплыло сообщение на экране ноутбука:
«Ну че там ТолстоБоров (кулуарное имя некого пухлого человека из некого министерства)?»
Скажем так: ничто так не добавляет любви представителя министерства, как слово "ТолстоБоров" крупным шрифтом на ноуте, аккуратно поставленном перед ним. С тех пор — нотификации только с именами. И никаких подробностей. Даже на часах и телефоне!
💬 2. ВСЕГДА проверяй, в какой чат ты пишешь.
Это не шутка. Это спасло мне карьеру пару раз.
Один раз я, уставшая, увидев в чате вопрос: «Ну че там?», в ответ написала:
«Да они, как всегда п.......»
и ты уже чувствуешь, к чему идет, да?
Отправила это не коллеге, а человеку из той самой компании, про которую была речь. Слава богу, я поставила слишком много точек и моментально переписала:
«попросили время на ответ, поэтому мы зависли в ожидании решения».
Итог: выглядело, как будто я просто случайно нажала Enter недописав и заваж .............
Поэтому в чатах я теперь вначале дышу, потом жму ОТПРАВИТЬ. Не шучу.
🔇 3. Вяканье — враг. Выключай звук. ВЕЗДЕ.
Телефон. Ноутбук. Браузер. Slack. Все в молчаливом режиме. Потому что хуже, чем вякающий Telegram в момент демо перед СЕО, может быть только одно — вякающий Telegram, когда ты пытаешься что-то серьезное сказать и делаешь умное лицо.
Исключение — PagerDuty или аналог. Но только при условии, что у вас хорошо настроен инцидент-менеджмент, и не орет каждый раз, когда кто-то упал тест.
🎂 4. Дни рождения. Telegram — спасибо.
Я вообще не любитель поздравлений по календарю (да и без календаря...). Но Telegram теперь показывает, у кого др, и я завела привычку кидать пару строк тем, кого знаю. Иногда добавляю:
«О, помню, как мы тогда в Питере в мае 2022...»
Работает! Люди отвечают. Вспоминают. Нетворк оживает. Просто, эффективно и никакой LinkedIn не нужен.
🪞 5. Обратная связь — прямо в лицо.
Если кандидат не подходит — говорю сразу, прямо на собеседовании. Без «мы подумаем». Почему? Потому что кандидат — не идиот. Он и сам понимает, что «мы перезвоним» чаще значит «нет».
То же самое в обратную сторону: если я понимаю, что с компанией у нас не складывается (а собеседуют меня), то говорю это HR напрямую. Без танцев с бубнами. Все мы хорошие, но не друг для друга. И это нормально.
👀 Думаю, этот список можно продолжать бесконечно. Вот мои дополнительные мини-правила:
– Никогда не пишу сообщение до первой чашки кофе. А то я не те буквы читаю!
– Переименовываю чаты, и людей, чтобы случайно не перепутать «босс» и «басс», не вспоминать кто такой AK (Коля, если ты это читаешь, то это про тебя).
– Не ставлю 👍 на сообщения, которые я на самом деле не прочла.
– В Zoom проверяю фон. Всегда. Потому что Пес и бардак сзади — еще ладно. А вот кружка с надписью «I hate meetings» — нет.
💬 Поделитесь своими, пжл!
❤13👍7🤣3😁2🔥1
📈 Зачем бизнесу люди, которые «не делают работу» 📉
В команде есть те, кто пишет код, делает дизайн, выпускает фичи. А есть те, кто… НИЧЕГО «физического» не делает: не коммитит в репу, не рисует интерфейсы, не продает.
Они проектируют, проверяют, удерживают фокус, работают с неопределенностью и упреждают ошибки.
Их часто считают «прослойкой».
📈 Почему «прослойку» критикуют?
(далее сугубо мои мысли и не претендую не на что...)
1) «Лишняя прослойка, которая только мешает». Ведь вместо прямого общения программиста с заказчиком появляется менеджер, который может искажать информацию, да и разработчики вполне могут сами общаться с клиентами, а появление продакта тормозит обратную связь.
2) «Бюрократия и замедление вместо гибкости». Ну и тут 2 обоснования:
– дополнительные роли вводят формальности, которые замедляют работу команды;
– каждый менеджер – это минус один разработчик.
3) Недостаток компетенций и размытие ответственности. Эффективность таких ролей сильно зависит от квалификации людей. Оппоненты указывают, что плохой аналитик или проектный менеджер не только бесполезен – он может навредить проекту.
4) «Для маленькой команды не нужны, сами справимся». Когда 5–7 человек вместе делают продукт, они могут совместно обсуждать требования, дизайн и архитектуру, без формальных позиций.
Что говорят исследования?
1) McKinsey «Developer Velocity Index» (2020)
Компании с наивысшей скоростью разработки (топ 25%) росли на 4–5 раз быстрее по выручке, чем аутсайдеры. Анализ показал, что на Developer Velocity значимее всего влияют инструменты, культура и качественный продукт-менеджмент. Иными словами, успешные организации не только имеют хороших инженеров, но и вкладываются в организационные практики: налаженный product ownership, эффективные внутренние платформы, обучение и пр.
2) McKinsey «The Business Value of Design» (2018)
Компании с сильными дизайн-практиками опережают рынок вдвое по темпам роста выручки. Под «сильной дизайн-практикой» подразумевается интеграция UX-дизайнеров, пользовательских исследований и ориентация на клиентский опыт на всех этапах разработки.
Результаты программы Enterprise Design Thinking в IBM (2021)
Эффективность разработки выросла на 75%, а совокупная отдача на инвестиции в дизайн превысила 300% ROI. Те, вложения в роли, отвечающие за пользовательский опыт, окупились в ТРОЕ за счет ускорения и повышения качества.
3) Отчеты Standish Group (Chaos Report) (2020)
Значительная доля провалов IT-проектов связана с неполными или неверными требованиями и отсутствием пользовательского участия. Исправление ошибки на этапе требований дешевле в десятки раз, чем на этапе готового продукта!
4) Stanford Graduate School of Business «Building Organizations That Work» (2012)
Команды, в которых полностью отсутствует формальная иерархия, часто приводят сотрудников в состояние дезориентации и неопределенности, особенно когда задачи нередко требуют координации или распределения ролей. Вывод: компании без иерархии приходят не к революционному равенству, а к усталости от неопределенности. Особенно это ощутимо в компаниях, где задачи сложны, межфункциональны или меняются динамично.
👀 А теперь главное:
Эти роли «прослойки» становятся особенно важны, когда:
— проект растет,
— неопределенность растет,
— когда команд больше одной.
В малой команде можно не иметь аналитика — пока вы в одной комнате.
В продакшене с миллионами пользователей — уже нельзя.
Это не прослойка. Это среда, в которой другие роли могут делать свою работу.
🙃 Да, такие роли раздражают, если сделаны плохо.
Если трекер — это просто микроменеджер.
А аналитик — это перекладыватель задач в Notion.
Но это не аргумент против ролей. Это аргумент против людей в этих ролях.
Когда работают — они дают кратный эффект. А когда нет — лучше бы их не было.
💬А вы: За/Против «прослоек»? Сами «прослойка»?
В команде есть те, кто пишет код, делает дизайн, выпускает фичи. А есть те, кто… НИЧЕГО «физического» не делает: не коммитит в репу, не рисует интерфейсы, не продает.
Они проектируют, проверяют, удерживают фокус, работают с неопределенностью и упреждают ошибки.
Их часто считают «прослойкой».
(далее сугубо мои мысли и не претендую не на что...)
1) «Лишняя прослойка, которая только мешает». Ведь вместо прямого общения программиста с заказчиком появляется менеджер, который может искажать информацию, да и разработчики вполне могут сами общаться с клиентами, а появление продакта тормозит обратную связь.
2) «Бюрократия и замедление вместо гибкости». Ну и тут 2 обоснования:
– дополнительные роли вводят формальности, которые замедляют работу команды;
– каждый менеджер – это минус один разработчик.
3) Недостаток компетенций и размытие ответственности. Эффективность таких ролей сильно зависит от квалификации людей. Оппоненты указывают, что плохой аналитик или проектный менеджер не только бесполезен – он может навредить проекту.
4) «Для маленькой команды не нужны, сами справимся». Когда 5–7 человек вместе делают продукт, они могут совместно обсуждать требования, дизайн и архитектуру, без формальных позиций.
Что говорят исследования?
1) McKinsey «Developer Velocity Index» (2020)
Компании с наивысшей скоростью разработки (топ 25%) росли на 4–5 раз быстрее по выручке, чем аутсайдеры. Анализ показал, что на Developer Velocity значимее всего влияют инструменты, культура и качественный продукт-менеджмент. Иными словами, успешные организации не только имеют хороших инженеров, но и вкладываются в организационные практики: налаженный product ownership, эффективные внутренние платформы, обучение и пр.
2) McKinsey «The Business Value of Design» (2018)
Компании с сильными дизайн-практиками опережают рынок вдвое по темпам роста выручки. Под «сильной дизайн-практикой» подразумевается интеграция UX-дизайнеров, пользовательских исследований и ориентация на клиентский опыт на всех этапах разработки.
Результаты программы Enterprise Design Thinking в IBM (2021)
Эффективность разработки выросла на 75%, а совокупная отдача на инвестиции в дизайн превысила 300% ROI. Те, вложения в роли, отвечающие за пользовательский опыт, окупились в ТРОЕ за счет ускорения и повышения качества.
3) Отчеты Standish Group (Chaos Report) (2020)
Значительная доля провалов IT-проектов связана с неполными или неверными требованиями и отсутствием пользовательского участия. Исправление ошибки на этапе требований дешевле в десятки раз, чем на этапе готового продукта!
4) Stanford Graduate School of Business «Building Organizations That Work» (2012)
Команды, в которых полностью отсутствует формальная иерархия, часто приводят сотрудников в состояние дезориентации и неопределенности, особенно когда задачи нередко требуют координации или распределения ролей. Вывод: компании без иерархии приходят не к революционному равенству, а к усталости от неопределенности. Особенно это ощутимо в компаниях, где задачи сложны, межфункциональны или меняются динамично.
👀 А теперь главное:
Эти роли «прослойки» становятся особенно важны, когда:
— проект растет,
— неопределенность растет,
— когда команд больше одной.
В малой команде можно не иметь аналитика — пока вы в одной комнате.
В продакшене с миллионами пользователей — уже нельзя.
Это не прослойка. Это среда, в которой другие роли могут делать свою работу.
🙃 Да, такие роли раздражают, если сделаны плохо.
Если трекер — это просто микроменеджер.
А аналитик — это перекладыватель задач в Notion.
Но это не аргумент против ролей. Это аргумент против людей в этих ролях.
Когда работают — они дают кратный эффект. А когда нет — лучше бы их не было.
💬А вы: За/Против «прослоек»? Сами «прослойка»?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11❤5🔥1🤔1
🛻 Поездка в другой город и кому это надо 🏘
Хожу сейчас на деврел-мастерскую от деврел-сообщества. Рассказывала вот в этом посте.
И все чаще думаю не о «каналах привлечения» и не о «тональности бренда», а вот о чем:
Когда ты выступаешь, рассказываешь, делаешь публичные шаги — у тебя появляется аудитория.
И рано или поздно появляется соблазн думать: раз люди реагируют, значит, это работает, значит... НИЧЕГО ЭТО НЕ ЗНАЧИТ 😁
🚌 И тут вспоминается парадокс Абилина. Его описал Джерри Харви в 70-х.
Вот это и есть парадокс — не потому что кто-то кого-то заставил, а потому что все подстроились, решив за других.
Но даже если ты в команде или комьюнити спросишь напрямую, все равно не факт, что получишь правду.
Есть еще такой феномен — фальсификация предпочтений.
Его описал Тимур Куран. Суть в том, что люди могут озвучивать не то, что думают, а то, что, по их мнению, социально приемлемо.
Они говорят «поддерживаю», хотя на деле — «лучше бы не надо, но вроде как все за».
Так появляется иллюзия согласия. И коллективно делается то, что никто не хочет, но все почему-то делают.
📍И это не только про деврел (или собственный канал). Это про любое лидерство. Про управление. Про изменение культуры. Про влияние.
Ты создаешь систему — а она под тебя изгибает других.
И да, часто получается не «плохо», а «вполне нормально». Люди даже могут сказать: «Да, нам подошло».
Но ты не знаешь — это осознанный выбор или эффект неозвученного согласия.
И вот честный вопрос:
Может быть, да. Потому что каждый поехал не из желания — а из подстройки.
И даже если все сложилось — это не отменяет того, что решение принималось на неверных основаниях.
💬 Мне эти мысли важны. Потому что работа с людьми — это не набор инструментов. Это внимание к динамике согласия.
Ты не можешь строить доверие, не умея слышать несогласие. И тут меня (не знаю как вас) начинает приследовать вопрос:
Хожу сейчас на деврел-мастерскую от деврел-сообщества. Рассказывала вот в этом посте.
И все чаще думаю не о «каналах привлечения» и не о «тональности бренда», а вот о чем:
Где граница между тем, что ты кого-то вдохновляешь — и тем, что просто затаскиваешь людей в собственную систему координат?
Когда ты выступаешь, рассказываешь, делаешь публичные шаги — у тебя появляется аудитория.
И рано или поздно появляется соблазн думать: раз люди реагируют, значит, это работает, значит... НИЧЕГО ЭТО НЕ ЗНАЧИТ 😁
🚌 И тут вспоминается парадокс Абилина. Его описал Джерри Харви в 70-х.
Семья сидит на крыльце, тесть говорит: «А может, в Абилин, поужинаем?»
Жена говорит: «О, звучит неплохо». Муж соглашается: «Ну, если все хотят, поехали». Теща поддерживает: «Да, давно не была».
Поехали, долго ехали, жарко, еда плохая. Вернулись.
А потом — внезапно выяснилось: никто не хотел. Просто каждый подумал, что остальные хотят.
Вот это и есть парадокс — не потому что кто-то кого-то заставил, а потому что все подстроились, решив за других.
Но даже если ты в команде или комьюнити спросишь напрямую, все равно не факт, что получишь правду.
Есть еще такой феномен — фальсификация предпочтений.
Его описал Тимур Куран. Суть в том, что люди могут озвучивать не то, что думают, а то, что, по их мнению, социально приемлемо.
Они говорят «поддерживаю», хотя на деле — «лучше бы не надо, но вроде как все за».
Так появляется иллюзия согласия. И коллективно делается то, что никто не хочет, но все почему-то делают.
📍И это не только про деврел (или собственный канал). Это про любое лидерство. Про управление. Про изменение культуры. Про влияние.
Ты создаешь систему — а она под тебя изгибает других.
И да, часто получается не «плохо», а «вполне нормально». Люди даже могут сказать: «Да, нам подошло».
Но ты не знаешь — это осознанный выбор или эффект неозвученного согласия.
И вот честный вопрос:
Если бы семья доехала до Абилина, и еда оказалась бы ок, и все бы не пожалели — это все еще парадокс?
Может быть, да. Потому что каждый поехал не из желания — а из подстройки.
И даже если все сложилось — это не отменяет того, что решение принималось на неверных основаниях.
💬 Мне эти мысли важны. Потому что работа с людьми — это не набор инструментов. Это внимание к динамике согласия.
Ты не можешь строить доверие, не умея слышать несогласие. И тут меня (не знаю как вас) начинает приследовать вопрос:
Это они хотят — или это я просто хорошо продаю?
🔥9❤4🤔2😁1
🧠SHAPE of you: от I до E 📏
В IT об этом говорят почти как о типе личности: «он T-shape», «а мне бы π-shape в команду», «а я вообще comb».
Вчера как раз в комментах к посту затронули вопрос: кто такой T-shape.
💡 Давайте разберемся в видах этой «геометрии», и в вопросе зачем нам столько фигур?!
С ростом сложности продуктов растет спрос не просто на экспертов, а на тех, кто может работать на стыке. А чтобы договариваться, понимать, подстраивать и собирать команды — нужна не только глубина, но и широта.
Поэтому полезла смотреть теорию, и оказывается, что ни одним T-shape едины! Вот базовые формы, на которые стоит смотреть не как на ярлыки, а как на инструменты навигации по профессиональной траектории.
🔹 I-shaped
Один навык — глубоко. Чистая экспертиза.
➕ мастерство, фокус
➖ узость, сложно коммуницировать с другими доменами
редкость в чистом виде сегодня
🔹 T-shaped
Одна вертикаль экспертизы + горизонтальная база по другим областям.
➕ кросс-функциональность, легче договариваться
➖ риск «не той глубины», если плохо сбалансирован
Первое упоминание: David Guest, 1991 — "The Hunt Is On for the Renaissance Man" (и я таки нашла скан этой статьи)
🔹 π-shaped
Две «ножки» экспертизы (π), например: разработка + UX, или бизнес + аналитика
➕ закрывает два домена, помогает работать на стыке
➖ высокая нагрузка, сложно поддерживать обе глубины
Введено Ashley Friedlein (2013), применялось сначала к digital-маркетингу
🔹 Comb-shaped
Несколько вертикалей экспертизы — «гребенка»
➕ суперуниверсал, может заменить нескольких человек
➖ часто страдает качество глубины
Применимо к DevOps, архитекторам, стартапам
Популяризировано Россом Доусоном (2013) (если не знакомы с «дядечькой» — рекомендую)
🔹 M-shaped
Три основные экспертизы. Иногда называют подвидом comb, но с четким фокусом на 3 ключевых опорах.
➕ баланс между широтой и глубиной
➖ все сложнее удерживать высокую планку в каждой области
🔹 E-shaped
Четыре составляющих: Expertise, Experience, Execution, Exploration
➕ не просто умеет — делает, думает, исследует, внедряет
➖ редкость, высокие требования
Это уже не про навыки, а про зрелость как профессионала
🌀 Зачем все это?
1️⃣ Форма — не шаблон, а язык для обсуждения развития. Не надо думать: «какой я буквы» — лучше спросить (хоть себя, хоть кандидатов на собесах(:
— где основная глубина?
— есть ли смежные области, в которых хорошо понимаешь других?
— куда развиваться — вширь или вглубь?
2️⃣ Ну, а если вы hiring-manager или вы занимаетесь развитием сотрудников, то еще и полезно понимать и не падать «в грязь лицом» при упоминании фигур 🤣
💬 А вы кто по форме? Или, может, уже в процессе «shape-shifting»?
Про меня: если до разбора букв была уверена, что T-shape, счас больше склоняюсь к тому, что π (а мб мне просто импонирует все математическое 🤣)
В IT об этом говорят почти как о типе личности: «он T-shape», «а мне бы π-shape в команду», «а я вообще comb».
Вчера как раз в комментах к посту затронули вопрос: кто такой T-shape.
💡 Давайте разберемся в видах этой «геометрии», и в вопросе зачем нам столько фигур?!
С ростом сложности продуктов растет спрос не просто на экспертов, а на тех, кто может работать на стыке. А чтобы договариваться, понимать, подстраивать и собирать команды — нужна не только глубина, но и широта.
Поэтому полезла смотреть теорию, и оказывается, что ни одним T-shape едины! Вот базовые формы, на которые стоит смотреть не как на ярлыки, а как на инструменты навигации по профессиональной траектории.
🔹 I-shaped
Один навык — глубоко. Чистая экспертиза.
➕ мастерство, фокус
➖ узость, сложно коммуницировать с другими доменами
редкость в чистом виде сегодня
🔹 T-shaped
Одна вертикаль экспертизы + горизонтальная база по другим областям.
➕ кросс-функциональность, легче договариваться
➖ риск «не той глубины», если плохо сбалансирован
Первое упоминание: David Guest, 1991 — "The Hunt Is On for the Renaissance Man" (и я таки нашла скан этой статьи)
🔹 π-shaped
Две «ножки» экспертизы (π), например: разработка + UX, или бизнес + аналитика
➕ закрывает два домена, помогает работать на стыке
➖ высокая нагрузка, сложно поддерживать обе глубины
Введено Ashley Friedlein (2013), применялось сначала к digital-маркетингу
🔹 Comb-shaped
Несколько вертикалей экспертизы — «гребенка»
➕ суперуниверсал, может заменить нескольких человек
➖ часто страдает качество глубины
Применимо к DevOps, архитекторам, стартапам
Популяризировано Россом Доусоном (2013) (если не знакомы с «дядечькой» — рекомендую)
🔹 M-shaped
Три основные экспертизы. Иногда называют подвидом comb, но с четким фокусом на 3 ключевых опорах.
➕ баланс между широтой и глубиной
➖ все сложнее удерживать высокую планку в каждой области
🔹 E-shaped
Четыре составляющих: Expertise, Experience, Execution, Exploration
➕ не просто умеет — делает, думает, исследует, внедряет
➖ редкость, высокие требования
Это уже не про навыки, а про зрелость как профессионала
🌀 Зачем все это?
1️⃣ Форма — не шаблон, а язык для обсуждения развития. Не надо думать: «какой я буквы» — лучше спросить (хоть себя, хоть кандидатов на собесах(:
— где основная глубина?
— есть ли смежные области, в которых хорошо понимаешь других?
— куда развиваться — вширь или вглубь?
2️⃣ Ну, а если вы hiring-manager или вы занимаетесь развитием сотрудников, то еще и полезно понимать и не падать «в грязь лицом» при упоминании фигур 🤣
💬 А вы кто по форме? Или, может, уже в процессе «shape-shifting»?
Про меня: если до разбора букв была уверена, что T-shape, счас больше склоняюсь к тому, что π (а мб мне просто импонирует все математическое 🤣)
🔥6👍2😁1
🗂 Даже ООН поняла, что их никто не читает 🤦♀️
Как и любой автор, я, конечно, хочу, чтобы посты читали, сохраняли, кивали, комментировали и пересылали друзьям.
Но понедельник — время честности, и вот вам прекрасная новость недели:
🔗 Статья на Reuters
📄 Суть отчета про отчеты:
– Совещаний много, отчетов еще больше.
– Их почти никто не читает.
– Это ставит под сомнение смысл всей этой работы.
– И, наконец, звучит здравое предложение: давайте встречаться реже и писать меньше.
📍По-моему, отличный повод в последние недели лета спросить себя:
— А мы точно не прозаседались?
— Не превращаем ли сами себя в машинку по производству невостребованного?
🤫 Или мы просто боимся перестать делать бесполезное?
Как и любой автор, я, конечно, хочу, чтобы посты читали, сохраняли, кивали, комментировали и пересылали друзьям.
Но понедельник — время честности, и вот вам прекрасная новость недели:
📉 даже ООН официально признала, что их отчеты почти никто не читает.
🔗 Статья на Reuters
📄 Суть отчета про отчеты:
– Совещаний много, отчетов еще больше.
– Их почти никто не читает.
– Это ставит под сомнение смысл всей этой работы.
– И, наконец, звучит здравое предложение: давайте встречаться реже и писать меньше.
📍По-моему, отличный повод в последние недели лета спросить себя:
— А мы точно не прозаседались?
— Не превращаем ли сами себя в машинку по производству невостребованного?
🤫 Или мы просто боимся перестать делать бесполезное?
👍13😁7👌1
🎭 Пьесы, в которых мы играем 🤫
Собеседования в 2025 году все чаще напоминают сцену из плохо написанной пьесы: роли выучены, реплики отрепетированы, только вот актеры не верят в происходящее.
Ты приходишь как нанимающий менеджер — не чтобы поговорить с живым человеком, а чтобы вычислить подлог. За эту неделю у меня было/будет больше 10 собеседований, и я все чаще ловлю себя на ощущении: мы не говорим о работе, мы играем в игру "угадай, кто настоящий". Особенно это чувствуется на сеньорских позициях — там, где ты ждешь зрелости, мышления, глубины. А получаешь — легенду, шаблон, шпаргалку. Ответы по систем-дизайну, выученные как молитва (в идеальном случае, а чаще тебе говорят прямым текстом: я сгенерил решение через AI), но без понимания сути. Я уже просто боюсь задавать вопросы!
Слайд из внутренней презентации Okko облетел соцсети: так работают схемы накрутки резюме. Иронично поблагодарив авторов, Антон Назаров (тот самый, который "волчара", и, да простите меня, но ссылку на Назаренко давать не будту) написал в LinkedIn, что это просто список хороших практик, которым они учат студентов — в рамках курса по карьерному росту и меркантильности. Мол, так и надо. Это — рынок. Это — игра. Ты должен уметь себя продать, кто бы ты ни был.
И вот тут возникает вопрос:
Можно долго спорить, кто виноват: кандидаты, которые приукрашивают? Компании, которые загоняют в бесконечные фильтры? Рынок, который требует три года опыта там, где важно мышление? Или просто мы все не договорились, во что играем.
Но факт остается фактом: сейчас ты собеседуешь не человека, а фасад. Ты слушаешь не про опыт, а про то, как пройти твое же интервью. Ты видишь слайд, где перечислены способы накрутки, и понимаешь — это не маргиналии, это мейнстрим. А честность и компетентность — это лотерея.
Может быть, нам стоит признать, что рынок поломался. Что слишком много ложных сигналов, слишком мало доверия, и слишком много усилий уходит не на работу, а на ролевую симуляцию.
И тогда у нас два пути.
1️⃣ Либо продолжать усложнять фильтры, усиливать проверки, создавать анти-фрод внутри собеседований.
2️⃣ Либо попробовать пересобрать систему так, чтобы честная игра снова имела шанс.
Например, убрать шаблонность. Давать задачи, где важна логика, а не память. Проводить интервью, где ценится конкретика, а не правильный тон. Работать с рекомендациями, а не только с резюме. Слушать не презентацию, а размышления. Боги (я даже реже материться и чаще к Богам взывать на собесах начала), встретить бы кандидатов, которые хотят того же!
Я не верю, что можно искоренить фальсификацию. Но я верю, что можно создать такую культуру найма, где быть настоящим выгоднее, чем быть маской.
Возможно, с этого стоит начать осень. С вопроса — не кого мы ищем, а как мы сами разговариваем. И не утратили ли мы уважение к собеседованию как к встрече взрослых людей, а не симуляторов.
💬 И почему сейчас найм похож на плач, где рыдают все?!
Собеседования в 2025 году все чаще напоминают сцену из плохо написанной пьесы: роли выучены, реплики отрепетированы, только вот актеры не верят в происходящее.
Ты приходишь как нанимающий менеджер — не чтобы поговорить с живым человеком, а чтобы вычислить подлог. За эту неделю у меня было/будет больше 10 собеседований, и я все чаще ловлю себя на ощущении: мы не говорим о работе, мы играем в игру "угадай, кто настоящий". Особенно это чувствуется на сеньорских позициях — там, где ты ждешь зрелости, мышления, глубины. А получаешь — легенду, шаблон, шпаргалку. Ответы по систем-дизайну, выученные как молитва (в идеальном случае, а чаще тебе говорят прямым текстом: я сгенерил решение через AI), но без понимания сути. Я уже просто боюсь задавать вопросы!
Слайд из внутренней презентации Okko облетел соцсети: так работают схемы накрутки резюме. Иронично поблагодарив авторов, Антон Назаров (тот самый, который "волчара", и, да простите меня, но ссылку на Назаренко давать не будту) написал в LinkedIn, что это просто список хороших практик, которым они учат студентов — в рамках курса по карьерному росту и меркантильности. Мол, так и надо. Это — рынок. Это — игра. Ты должен уметь себя продать, кто бы ты ни был.
И вот тут возникает вопрос:
А хотим ли мы жить в мире, где все только игра? Где резюме — не про опыт, а про правильно подобранные ключевые слова. Где интервью — не про разговор, а про проверку на вшивость. Где твоя задача — не быть компетентным, а казаться им. Для кого-то это адаптация. Для кого-то — деградация.
Можно долго спорить, кто виноват: кандидаты, которые приукрашивают? Компании, которые загоняют в бесконечные фильтры? Рынок, который требует три года опыта там, где важно мышление? Или просто мы все не договорились, во что играем.
Но факт остается фактом: сейчас ты собеседуешь не человека, а фасад. Ты слушаешь не про опыт, а про то, как пройти твое же интервью. Ты видишь слайд, где перечислены способы накрутки, и понимаешь — это не маргиналии, это мейнстрим. А честность и компетентность — это лотерея.
Может быть, нам стоит признать, что рынок поломался. Что слишком много ложных сигналов, слишком мало доверия, и слишком много усилий уходит не на работу, а на ролевую симуляцию.
И тогда у нас два пути.
1️⃣ Либо продолжать усложнять фильтры, усиливать проверки, создавать анти-фрод внутри собеседований.
2️⃣ Либо попробовать пересобрать систему так, чтобы честная игра снова имела шанс.
Например, убрать шаблонность. Давать задачи, где важна логика, а не память. Проводить интервью, где ценится конкретика, а не правильный тон. Работать с рекомендациями, а не только с резюме. Слушать не презентацию, а размышления. Боги (я даже реже материться и чаще к Богам взывать на собесах начала), встретить бы кандидатов, которые хотят того же!
Я не верю, что можно искоренить фальсификацию. Но я верю, что можно создать такую культуру найма, где быть настоящим выгоднее, чем быть маской.
Возможно, с этого стоит начать осень. С вопроса — не кого мы ищем, а как мы сами разговариваем. И не утратили ли мы уважение к собеседованию как к встрече взрослых людей, а не симуляторов.
💬 И почему сейчас найм похож на плач, где рыдают все?!
🔥16👍8💯4❤3
🧠 DDD и прочие матерные слова на собесах 🤬
Есть такие термины, которые начинались как великие идеи. А потом случилось... сообщество. Найм. Курсы. YouTube. Рынок.
Теперь ты слышишь «DDD» — и вместо уважения чувствуешь смущение.
Парадоксально, но я искренне люблю и продвигаю идеи DDD . Однако теперь при его упоминании все чаще хочется схватиться за голову!
В этот момент я сижу, моргаю и думаю: «Дорогой человек, какие же видео, статьи или книги ты читал? Как у тебя в голове сложилась такая картина мира?».
Вроде бы человек старался. Читал. С chatGPT разговаривал...
И проблема — не только в DDD. То же случилось с Agile, Scrum, Senior, T-shape, Microservices, System Design, DevOps…
Все эти слова сегодня звучат как:
Вроде бы звучит знакомая мелодия в голове, но буквы НЕ ТЕ!
Настя Штей (с которой че мы уже только вместе не делали) во вчерашнем своем посте (у нее вообще в канале много интересного) точно подметила: где, кто и как только не использовал слово "домен", что и к 1Сникам залетело, но легче не становится!
Термин относится к недоопределенной категории. А значит — требует мышления. Диалога. И уж никак не просто "влета" в резюме или собеседование.
Но вернемся с DDD к найму, который так у всех вчера бомбанул (см. пост выше).
Рынок стал быстрым. И людям некогда разбираться. Им надо «продавать себя», не погружаясь.
Собесы превратились в проверкуbuzzwords . А не в разговор о смысле. Фильтры стали шаблонными. Подробности важны только если ты прошел резюме-детектор.
80% кандидатов приукрашивают резюме (по данным StandOutCV — рекомендую, много занимательных цифр). И многие из них делают это с «правильными словами».
А дальше ты берешь сеньора — и оказываешься в ситуации, где за словами нет модели. За «доменацией» — нет смысла.
📌 В чем боль?
Найм — это не экзамен. Это попытка найти общее поле смысла. А если в нем одни клише — поле становится минным.
Ты не знаешь, на что человек реально способен. Ты не можешь понять, что он называет «системой», «ценностью», «архитектурой».
И в итоге начинаешь «копать». А это уже визуально: частично «БДСМ», частично «цирковое» шоу.
🦸♂️ Капитан-очевидно и ответ на вопрос: Что делать?
— Слушать не слова, а разбирать ход мысли.
— Спрашивать «почему», а не «что вы знаете о».
— Просить объяснить — не «по учебнику», а своими словами.
— И — страшное — уметь самим признаться, если мы тоже не понимаем. Потому что за красивыми словами прячемся не только кандидаты.
DDD — прекрасный подход. Когда в него вложен смысл, а не фасад. И хочется, чтобы мы вернули этому слову честь. И другим тоже.
Если не можете объяснить «что такое домен» — ничего страшного. Страшно, если вы не можете заметить, что не понимаете.
💬 А у вас какие термины стали «триггерами»? Особенно, если они с собесов по обе стороны...
Есть такие термины, которые начинались как великие идеи. А потом случилось... сообщество. Найм. Курсы. YouTube. Рынок.
Теперь ты слышишь «DDD» — и вместо уважения чувствуешь смущение.
Парадоксально, но я искренне люблю и продвигаю идеи DDD . Однако теперь при его упоминании все чаще хочется схватиться за голову!
Недавний случай на собеседовании:
даешь кандидату задачу на SD, а он уверенно заявляет: «Здесь можно выделить три домена – покупка, продажа, возврат». Стоп... доменов внезапно оказалось четыре, так как следом кандидат добавляет: «еще у нас есть авторизация».
В этот момент я сижу, моргаю и думаю: «Дорогой человек, какие же видео, статьи или книги ты читал? Как у тебя в голове сложилась такая картина мира?».
Вроде бы человек старался. Читал. С chatGPT разговаривал...
И проблема — не только в DDD. То же случилось с Agile, Scrum, Senior, T-shape, Microservices, System Design, DevOps…
Все эти слова сегодня звучат как:
Я знаю пароль, я вижу ананас. Я верю, что еноты придут спасать нас.
Вроде бы звучит знакомая мелодия в голове, но буквы НЕ ТЕ!
Настя Штей (с которой че мы уже только вместе не делали) во вчерашнем своем посте (у нее вообще в канале много интересного) точно подметила: где, кто и как только не использовал слово "домен", что и к 1Сникам залетело, но легче не становится!
Термин относится к недоопределенной категории. А значит — требует мышления. Диалога. И уж никак не просто "влета" в резюме или собеседование.
Но вернемся с DDD к найму, который так у всех вчера бомбанул (см. пост выше).
Рынок стал быстрым. И людям некогда разбираться. Им надо «продавать себя», не погружаясь.
Собесы превратились в проверку
80% кандидатов приукрашивают резюме (по данным StandOutCV — рекомендую, много занимательных цифр). И многие из них делают это с «правильными словами».
А дальше ты берешь сеньора — и оказываешься в ситуации, где за словами нет модели. За «доменацией» — нет смысла.
📌 В чем боль?
Найм — это не экзамен. Это попытка найти общее поле смысла. А если в нем одни клише — поле становится минным.
Ты не знаешь, на что человек реально способен. Ты не можешь понять, что он называет «системой», «ценностью», «архитектурой».
И в итоге начинаешь «копать». А это уже визуально: частично «БДСМ», частично «цирковое» шоу.
🦸♂️ Капитан-очевидно и ответ на вопрос: Что делать?
— Слушать не слова, а разбирать ход мысли.
— Спрашивать «почему», а не «что вы знаете о».
— Просить объяснить — не «по учебнику», а своими словами.
— И — страшное — уметь самим признаться, если мы тоже не понимаем. Потому что за красивыми словами прячемся не только кандидаты.
DDD — прекрасный подход. Когда в него вложен смысл, а не фасад. И хочется, чтобы мы вернули этому слову честь. И другим тоже.
Если не можете объяснить «что такое домен» — ничего страшного. Страшно, если вы не можете заметить, что не понимаете.
💬 А у вас какие термины стали «триггерами»? Особенно, если они с собесов по обе стороны...
Telegram
Нет глупых вопросов
❓ А ты знаешь, что такое "домен"?
Если честно, то я до сих пор нет, особенно если использовать этот термин применительно к 1С.
↪️ Как развивались события.
🌟 Где-то в году 2021 на Инфостарте я первый раз услышала этот термин от Ирины Гертовской, ИТ-аналитика…
Если честно, то я до сих пор нет, особенно если использовать этот термин применительно к 1С.
↪️ Как развивались события.
🌟 Где-то в году 2021 на Инфостарте я первый раз услышала этот термин от Ирины Гертовской, ИТ-аналитика…
❤8🔥5👍3