Книжный куб

[2/2] Communication Patterns: A Guide for Developers and Architects (Паттерны коммуникации: руководство для ИТ-разработчиков и архитекторов) (Рубрика #Management) Продолжая рассказ о паттернах коммуникации, расскажу про вторую половину книги, в которой речь идет про передачу знаний и эффективную удаленную работу. 3️⃣ Передача знаний (Communicating Knowledge) - как управлять знаниями в команде и организации. - Глава 10. Принципы управления знаниями (Knowledge Management Principles). Разница между данными, информацией и знаниями. Почему wiki-системы превращаются в свалку и как этого избежать. - Глава 11. Знания и люди (Knowledge and People). Как люди усваивают информацию и почему "шаринг знаний" часто не работает. Психология обучения взрослых применительно к инженерным командам. - Глава 12. Эффективные практики (Effective Practices). Конкретные инструменты: от ведения ADR (Architectural Decision Records) до проведения воркшопов и сессий совместного моделирования. 4️⃣ Удаленная работа (Remote Communication) - специфика общения в распределенных командах. - Глава 13. Фактор времени при удаленной работе (Remote Time). Паттерны для асинхронной коммуникации и работы в разных часовых поясах. Как сохранить контекст и темп работы, когда команда разбросана по миру. - Глава 14. Принципы дистанционного общения (Remote Principles). Здесь речь про создание четких коммуникационных каналов, протоколов, а также про адаптацию стиля общения в зависимости от нужд команды. На эту тему есть хорошая книга "Remote Team Interactions Workbook" (о которой я уже рассказывал) от авторов книги "Team Topologoies". - Глава 15. Методы дистанционного общения (Remote Channels). Здесь автор рассказывает про установление культуры открытой и честной обратной связи, а также использование технологий для улучшения коммуникации и поддержания связи между членами команды. Кстати, про открытую и честную обратную связь можно почитать в книге "Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity", о которой я уже рассказывал. #Thinking #Writing #Leadership #Management #DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #Writing #Speaking

[1/2] Communication Patterns: A Guide for Developers and Architects (Паттерны коммуникации: руководство для ИТ-разработчиков и архитекторов) (Рубрика #Management) Забавная вышла история у этой книги - я начинал ее читать еще на английском в формате early preview на платформе O'Reilly, а закончил уже в формате книги на русском, которую перевело и выпустило издательство "БХВ". Вообще, книжка мне понравилась - она про успешные коммуникации для инженеров и технических руководителей, которые уже привыкли к использованию шаблонов в проектировании, разработке и оргдизайне. Автор книги - Джеки Рид (Jacqui Read) - архитектор решений (Solution & Enterprise Architect) из Великобритании. Она начинала как full-stack разработчик, а позже перешла в архитектуру и продвигает идею, что коммуникация - это такой же навык, как написание кода, и его можно систематизировать. Вместо советов "будьте понятнее", она предлагает конкретные паттерны (проверенные решения) и антипаттерны (типичные ошибки). Если говорить про струткру книги, то она разделена на 4 части и 13 глав, которые последовательно закрывают все каналы передачи информации: от визуальных схем до асинхронной работы. 1️⃣ Визуальная коммуникация (Visuals) - здесь разбирается, как создавать диаграммы, которые действительно читают и понимают. - Глава 1. Основы коммуникации (Communication Essentials). Здесь закладывается фундамент книги: принцип "знай свою аудиторию" и управление уровнями абстракции. Объясняется, почему нельзя смешивать бизнес-контекст и детали реализации на одной схеме. - Глава 2. Устранение шума (Clarify the Clutter). Здесь автор рассказывает как очистить диаграммы от лишних элементов, которые отвлекают внимание. Рассказывается про борьбу с визуальным мусором для повышения читаемости. - Глава 3. Доступность (Accessibility). Это важная тема, которую часто упускают: как делать схемы понятными для людей с дальтонизмом или особенностями восприятия (например, не полагаться только на цвет). Интересно, что про это иногда забывают и в потребительских продуктах - Глава 4. Повествование (Narrative). Диаграмма должна рассказывать историю. Паттерн "Сначала общая картина" (The Big Picture Comes First) учит погружать зрителя в контекст перед тем, как топить его в деталях. Кстати, у меня есть подборка книг про сторителлинг и истории - Глава 5. Нотация (Notation). Глава о том, как выбирать уровень формальности нотации в зависимости от задачи, и почему легенда к схеме обязательна. - Глава 6. Композиция (Composition). Принципы визуальной иерархии: как располагать элементы так, чтобы взгляд зрителя скользил по схеме в правильном порядке, считывая логику системы. 2️⃣ Письменная и устная коммуникация (Written, Verbal, and Non-verbal) - переход от картинок к словам и выступлениям. - Глава 7. Письменная коммуникация (Written Communication). Паттерны для документации и переписки. Как писать лаконично, структурировать технические тексты и избегать "стены текста". Здесь говорится и про пирамиду Минто, о которой я рассказывал раньше. - Глава 8. Вербальная и невербальная коммуникация (Verbal and Nonverbal Communication). Глава о том, как наши жесты, тон и поза влияют на восприятие технических решений. Как считывать реакцию аудитории во время презентации. - Глава 9. Риторический треугольник (The Rhetoric Triangle). Адаптация античного принципа Аристотеля (Этос, Патос, Логос) для инженеров. Как балансировать между логикой (фактами), авторитетом и эмоциями для убеждения стейкхолдеров. Подробнее в отдельном посте Об оставшейся книге я расскажу в продолжении этого поста. #Thinking #Writing #Leadership #Management #DistributedSystems #Architecture #SoftwareArchitecture #SystemDesign #Software #Writing #Speaking

Как смотреть кино (Рубрика #ForKids) Периодически я покупаю книги для детей и так у меня на столе оказалась эта крутая книга Антона Долина и Константина Бронзита, что вышла в серии Альпина.Дети. Первое издание было в 2019 году, а мне досталось переиздание, в котором большими буквами на обратной стороне обложки написано, что Долин стал за это время стал иностранным агентом, но на качество книги это не повлияло, так как оба автора профессионалы - Антон Долин - кинокритик и создатель Youtube канала "Радио Долин", что отвечал за текст книги - Константин Бронзит - аниматор и двухкратный номинат на премию "Оскар" за мультики "Уборная история - любовная история" и любимый мной "Мы не можем жить без космоса" (что я уже упоминал при рассказе о детской книге "Ракета стартует"). В этой книге Константин отвечал за бомбические иллюстрации, что совместно с текстом делают книгу красочной В этой книге соавторы приглащают научиться смотреть кино по‑настоящему, а не "на фоне". Изначально книга была задумана как детская, но она получилась глубже и ее интересно читать и взрослым (я проверил это на своем опыте). Долин начинает с "простых правил": - Зачем по возможности ловить фильмы на большом экране - Чем поход в зал отличается от домашнего просмотра - Почему важно замечать не только сюжет, но и картинку, звук, монтаж Есть вопросы поглубже - Можно ли "застраховаться" от разочарования - Надо ли делить кино на "искусство" и "развлечение" - Почему старые фильмы не обязательно лучше новых В книге есть короткие главы с каверзными вопросами, что могут выступать темами для обсуждения с ребенком. Это позволяет развивать критическое мышление, риторикку, а также лучше понять что нравиться ребенку в кино и почему. Последняя часть книги посвящена краткой анталогии кинематографа и позволяет начать знакомство с классикой - эта часть учит как не потеряться в бесконечных списках, почему стоит смотреть не только голливудские хиты, но и авторское кино, документальные ленты и анимацию. Долин даёт базовые ориентиры и помогает превратить хаотичный выбор фильмов в осознанный маршрут. Книга отлично подойдет для - Подростков (от 10 лет и старше) - Родителей, которые хотят говорить с детьми о кино глубже, чем "понравилось/не понравилось" - Любителей кино, кто хочет почитать доступно о том, как его смотреть #ForParents #ForKids

Meta looks to power trading supports its AI energy needs (Рубрика #AI) В ноябре 2025 года стало известно о нетривиальном шаге запрещенной в России компании Meta, которая получила разрешение американских регуляторов на торговлю электроэнергией на оптовом рынке. Такой шаг призван удовлетворить стремительно растущий спрос ее центров обработки данных (ЦОД) на электричество для решений искусственного интеллекта (AI). По сути, Meta создает собственное направление энерготрейдинга, чтобы напрямую закупать электроэнергию, заключать долгосрочные контракты с электростанциями и при необходимости перепродавать излишки мощности на рынке. Интересно, что в документе "Meta’s Hyperscale Infrastructure: Overview and Insights", что я разбирал раньше, было рассказано как раз о энергии, как о главном лимитирующем факторе для датацентров и инфры (условно, железо можно и обновить, а вот новые мощности по питанию обеспечить сложнее) Тезисы тут примерно такие - Сейчас мы наблюдаем взрывной рост потребности в энергии для AI, которые требуют огромных вычислительных ресурсов - Существующая энергосистема с трудом справляется с такими темпами роста нагрузки, что уже вызвало в отдельных регионах США рекордный рост цен на мощность на оптовых аукционах - Традиционных подходов к закупке энергии недостаточно - разработчики новых электростанций нуждаются в “якорных” покупателях, готовых брать на себя долгосрочные обязательства по закупке энергии. Например, Meta для своего нового ДЦ в Луизиане потребовалось вкладываться в строительство трех газовых станций, чтобы запитать ДЦ (они закоммитились только на это потратить 1.6 млрд $) - А закупая электричество оптом можно не только снижать издержки за счет оптовых закупок, но и получать прибыль в периоды избытка продавая её обратно в сеть по пиковым ценам В итоге, Meta создала дочернюю компанию Atem Energy LLC и получила разрешение на торговлю электроэнергией оптом от федеральной комиссии по регулированию энергетики США (FERC). Компания планирует изначально сотрудничать с опытными партнёрами-трейдерами и сконцентрироваться на работе на рынке США Интересно, что Meta пошла по стопам других корпораций, получавших аналогичные лицензии. На оптовом рынке уже есть Google Energy, Apple Energy, Energy LLC, Amazon Energy. В общем, Meta не прокладывает абсолютно новый путь, но масштаб её усилий в энергетике - один из крупнейших на сегодня в Big Tech. Если подумать, то для инфраструктуры ЦОДов это может значить следующее - Снятие энергетических ограничений на рост ИИ - раньше именно энергия была лимитирующим фактором - Увеличение капитальных затрат на дата-центры - теперь при планировании новых центров обработки данных компаний уровня Meta или Google необходимо учитывать и строительство параллельной энергоструктуры (это приведет к росту стоимости ЦОД проектов) - Ограничения энергоснабжения могут влиять и на дизайн будущих дата-центров - появляется стимул размещать их ближе к источникам энергии: например, строить кампусы рядом с зонами богатых ВИЭ-ресурсов (ветер, солнце) или возле действующих крупных электростанций, чтобы минимизировать нагрузку на сети. - Новые стандарты надежности и устойчивости - включение дата-центров в активное управление энергопотреблением (через торги, регулирование нагрузки) повышает устойчивость энергосистем, но и задаёт новые стандарты самим ЦОД. Например, Google уже заключает demand response-контракты с энергокомпаниями, согласившись переносить часть вычислений на непиковое время во избежание перегрузок сети В сумме, инициатива Meta сигнализирует всему ИИ-сектору: эры дешёвого и гарантированного электричества больше нет, и дальнейший прогресс ML/AI тесно увязан с энергетической инфраструктурой. Те, кто сумеют интегрироваться с энергосистемой (через инвестиции или партнерства), получат фору в гонке ИИ, а те, кто проигнорируют - рискуют столкнуться с энергетическим дефицитом, замедляющим их инновации. #Infrastructure #PlatformEngineering #Architecture #DistributedSystems #SystemDesign #Engineering #AI #Economics

AI changes *Nothing* — Dax Raad, OpenCode (Рубрика #AI) Посмотрел интересный доклад Dax Raad из OpenCode на конференции AI Engineer, где создатель популярного coding agent выступил с провокационным тезисом: несмотря на весь ажиотаж вокруг AI, фундаментальные вызовы построения успешного продукта остаются прежними. В общем, AI не решает волшебным способом те проблемы, что раньше требовалось решать для развития продуктов. Основных тезисов в выступлении всего три 1️⃣ Маркетинг - это про "крутость", а AI слишком корявый Dax утверждает, что настоящий top-of-funnel маркетинг - это способность создать что-то, чем люди захотят поделиться. Это не стандартные блог-посты о релизах или оплаченные упоминания у инфлюенсеров. Вам нужно вызвать у пользователя такую реакцию, чтобы он захотел показать это коллегам или друзьям со словами "можете в это поверить?".​ Проблема в том, что AI инструменты генерации контента выдают слишком банальные и/или корявые результаты. Они не способны создать крутые штуки, которые цепляют эмоционально. Даже используя AI как brainstorming-партнёра, Dax не получил ни одной действительно хорошей идеи. Маркетинг требует креативности, а AI пока не может её обеспечить.​​ В итоге, лучше не поручать маркетинг AI, а придумывать идеи самим, чтобы иметь ненулевой нулевой шанс стать вирусными.​ 2️⃣ Aha-момент: безжалостное устранение фрикций Второй критический этап - это aha-момент: момент в journey пользователя, когда он наконец "понимает" ценность продукта. Вы должны определить единственный самый важный момент озарения и безжалостно устранить все препятствия на пути к нему.​​ Кстати, про это рассказывал Петр Савостин, мой коллега, что занимается у нас развитием мобильных продуктов для физических лиц. Суть в том, что на каждом лишнем шаге customer journey вы теряете 10-20% пользователей и до aha-момента часто большинство пользователей не добираются. В итоге, это не про то, чтобы сделать много фич, а про то, чтобы сделать вылизанные фичи, где пользователь сразу чувствует ценность. Например - ChatGPT: пустое поле ввода, куда можно написать что угодно и получить человекоподобный ответ - мгновенное понимание ценности​ - Facebook (retention): добавление 7 друзей в первые 10 дней коррелировало с долгосрочным удержанием​ - Spotify: прослушивание 10 песен в первые 2 часа​ AI не помогает с решением этой проблемы - создание правильного aha-момента требует глубокого понимания problem space, позиционирования, ясности в том, что вы делаете уникально. Это требует куса, который не может быть делегирован алгоритму. 3️⃣ Retention: примитивы важнее фич Здесь Dax развенчивает миф о том, что продукт может быть либо простым, либо мощным. На самом деле никакого trade-off нет - можно и нужно строить оба качества одновременно.​ Суть в том, чтобы не строить сложные фичи сходу, а в том, чтобы создавать deep primitives (глубокие примитивы), которые можно собрать в нужную функциональность. Сначала проектируете мощный, широкий слой примитивов, а затем собираете из них простой опыт для 99% пользователей. Когда пользователи становятся более продвинутыми, они получают прямой доступ к этим примитивам и могут настраивать продукт под себя, никогда его не перерастая.​ Но с этим не справляются AI инсутрменты, так как проектирование правильных примитивов - это процесс exploration. Чтобы даже объяснить AI, что вы хотите, нужно самому очень хорошо это понимать. Задача - понять проблему настолько глубоко, чтобы спроектировать правильный набор примитивов. AI здесь бесполезен.​​ В итоге, автор отмечает, что AI - это мощный инструмент для технической работы, но он не решает фундаментальных задач создания успешного продукта: маркетинга (креативность), onboarding (taste и фокус) и retention (архитектурное мышление). Технические лидеры должны продолжать инвестировать в человеческие навыки и не попадаться на иллюзию, что AI сделает крутые продукты автоматически. Hard work, хороший вкус, и человеческая изобретательность остаются необходимыми - и это хорошая новость.​​ #ProductManagement #Software #SoftwareDevelopment #AI #Engineering #Management #Leadership

C-Connect от Yandex Был вчера на мероприятии Яндекса для CTO и CPO, которое оказалось топовым. И я решил поделиться своими мыслями о том, почему у ребят получилось: - Гостей было немного, но они были действительно на около c-level позициях - Место было уютное, были залы для обшения по темам, главный зал, а также места для нетворкинга рядом с баром - Были дискуссии на 15-20 человек, где участвовали все участники, а не только пара людей, что вещают со сцены - Были лекция про physical AI (или, проще говоря, про роботов), а также дискуссия с популяризаторами науки и директорами из Я про искуственный и естественный интеллект и как они влият друг на друга - Напоследок в официальной части программы был IT стендап и он был действительно смешной ... и заставляющий задуматься А потом официальная программа закончилась и мы перешли к неформальному общению, что перешло в обсуждение глобальных сбоев и их координацию, а также к обсуждению реоргов и технологических стратегий разных компаний. В общем, домой я попал только в 2 утра уставший, но довольный. Спасибо орнанизаторам и участникам, что сделали вчерашний день настолько крутым. #AI #Software #Management #Leadership

Риторика Аристотеля (Рубрика #Speaking) Я часто оказываюсь в ситуации, когда мне нужно донести мои мысли максимально эффективно до слушателей, будь то публичное выступление или совещание внутрии компании. Обычно я строю свой рассказ и тезисы на рациональном и логичном подходе, похожем на пирамиду Минто, но это не всегда срабатывало, поэтому я решил обратиться к методам классиков. Оказалось, что первым систематическим руководством в данной области был трактат Аристотеля "Риторика", в котором он рассказывал про три опоры успешного убеждения, отвечающим на разные вопросы - Этос (кому я верю?) - тут важно доверие к спикеру: его репутация, компетентность - Пафос (что я чувствую?) - тут важно эмоциональное состояние и мотивация аудитории: страх, энтузиазм, скука, усталось - Логос (насколько это логично?) - тут важны факты, метрики, диаграммы, расчеты, причинно-следственные связи между аргументами По Аристотелю для успеха нужна комбинация факторов, но ее очень сложно достичь. Например, у меня с детства хорошо получалось опираться на логос, потом во взрослом возрасте добавился этос (за счет репутации эксперта), а вот пафос мне до сих пор дается с трудом (но я работаю над прокачкой своего эмоционального интеллекта). Интересно, что во времена Аристотеля книга помогала успешно выступать на судах, народных собраниях и так далее, где ему было важно убедить аудиторию здесь и сейчас без каких-то подручных материалов: презентаций, раздаток, видеотрейлеров. А сейчас в технологических компаниях у нас есть целый набор разнообразных задач в разных контекстах и модель как будто становится богаче. Например, есть встречи, письма, часты, RFC/ADR, code-review, design review, business review, ... В итоге, кроме цели убеждения появляются цели синхронизировать людей, сняять тревогу, построить доверие, протащить изменения ... Сейчас эту модель с этосом, пафосом и логосом можно разложить примерно так 1️⃣Этос сегодня - это про то, а как понять: "Поверят ли этой оценке/предложению именно от меня?" Этос развивается через следущие факторы - Качество ваших решений и прогнозов (обещали — сделали) - Честное признание рисков и неизвестных - Прозрачность: "вот, что я проверил, вот, чего не знаю" - Уважительный тон, даже когда спорите 2️⃣ Пафос сегодня - это про то, а как понять: "Что люди чувствуют, когда это слышат/читают?" На практике это можно проявлять так - Не объявлять изменения “сухим” языком, игнорируя тревогу (“ещё один приоритет сверху”) - Показывать, как это влияет на нагрузку, карьеру, интерес к работе - Помогать людям перейти от “ой, кошмар” к “ок, это имеет смысл, давайте попробуем” 3️⃣ Логос сегодня - это про то, а как понять: “Понятна ли логика и достаточно ли она надёжна для решений?” На практике это можно проявлять так - Открыто говорить про допущения и границы модели: “эта оценка без учёта интеграции с X”, - Использовать визуализации логики: диаграммы, таблицы, модели - Показывать сравнение альтернатив с использованием понятных критериев На практике перед любой важно коммуникацией можно задать себе три блока вопросов, которые помогут сделать эту коммуникацию лучше Логос: сначала "основа" - В чём основное утверждение? (1–2 фразы) - Какие данные и факты это поддерживают? - Какие есть альтернативы и почему они хуже? - Какие допущения вы делаете? Если вы не можете это чётко сформулировать — проблема в логосе, а не в “плохой аудитории”. Этос: почему должны поверить вам - Что вы уже проверили/сделали сами? - Чей опыт/экспертизу вы учли (SRE, безопасность, продукт, финансы)? - Как показать, что вы не проталкиваете “своё любимое решение”, а действительно ищете лучшее? Иногда достаточно добавить буквально пару фраз. Пафос: эмоциональная цель - Какое состояние аудитории вам нужно? - Есть ли сейчас страх, усталость, скепсис? Чем их можно “снизить”? - Как показать людям, что вы на их стороне? Например, вместо “надо перерабатывать”: “Наша цель — избавиться от ночных пожарных релизов. Предлагаемый план как раз уменьшит количество авралов”. #Thinking #Writing #Leadership #Management

Modern Architecture 101 for New Engineers & Forgetful Experts - NDC Copenhagen 2025 (Рубрика #Architecture) Отличное выступление Jerry Nixon, product manager из команд SQL Server и Data API Builder, в котором он говорит, что архитектура - это не про "best practices", а про контекстные решения и смелость говорить "нет". Фактически, Никсон разрушает мифы и дальше показывает как строить архитектуру под любой масштаб с учетом вашего контекста. А начинает он с провокации, говоря, что термин "best practice" используют как оправдание отсутствия аргументов. Единственная настоящая best practice - не использовать SQL injection. Все остальное зависит от: - Политики и бюджета компании - Уровня команды (джуниоры vs эксперты) - Наследия систем и ограничений от объединения разных систем - Возможности "платить за ошибки" (Twitter может себе позволить глупости, а вы - нет) Дальше он показывает "годовые кольца" технологий: spaghetti code 90-х, трехуровневые приложения 2000-х и микросервисы 2010-х, а дальше заключает, что все это работает до сих пор. В итоге, architecture shaming - это просто неуважение к контексту, в котором были приняты прошлые архитектурные решения. По Никсону роль архитектора быть хранителем простоты. Ведь архитектор отвечает за самые дорогие решения, которые нельзя отложить. Это не тот, кто рисует схемы в начале проекта, а тот, кто постоянно решает, что оставить за бортом. Главная задача - не добавлять компоненты, а защищать систему от лишнего - это очень похоже на тезис Антуана де Сент-Экзюпери

Совершенство достигается не тогда, когда нечего добавить, а когда нечего убрать

После этого спикер начинает показывать как можно начинать проектировать решение с базы и постепенно наращивать сложность по мере появления доп требований - Client → Database - Client → API → Database (добавили интерфейс) - Write API → Primary DB (синхронизация через логи) и Read API → Read replica. Логика в том, что вы масштабируете запись и чтение независимо за счет простого изменения connection string, а также за счет eventual consistency (и вам сразу становитсья важно понимать модели консистентности) - Дальше появляется API Manager (APIM) / Gateway для управления API, версионирования, балансировки нагрузки, постепенной раскатки и a/b тестов - Дальше появляется история про мониторинг (Никсон советует OpenTelemetry), кеши и service bus - Ну и вообще асинхронность - это способ работы на масштабе: CQRS (Command Query Responsibility Segregation), Queue для работы со спайками нагрузки - И так далее В общем, выступление очень интересное. Основные мысли примерно такие - Все компромиссы исходят из реальности, а не идеологии - Архитектор - это тот, кого винят. Ваши решения будут судить через 5 лет, когда проект покинете - Сложность должна оправдываться. Каждый добавленный компонент (service bus, cache, gateway) - это еще одна система, за которую вы отвечаете. Ну и напоследок тезис от автора, что меня сначала повеселил, а потом заставил задуматься

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

#Architecture #DistributedSystems #Management #Software #Leadership #Patterns #SystemDesign

Пирамида Минто или как структурировать свои тексты (Рубрика #Management) Я читаю много документации, как на работе, так и в свободное время. И я расстраиваюсь от ситуаций, когда для понимания сути вопроса требуется преодолевать страницы текста, а не следовать за размышлениями автора. Особенно бывает грустно, когда вопрос важный, а время ограниченно. В этот момент хочется, чтобы документ был структурирован в формате: сначала главная идея, потом доказательства. Именно такой принцип популяризировала c 1970х годов Барбара Минто, консультант из McKinsey. Мне очень нравится этот подход, поэтому я решил сегодня про него рассказать. Шаблон использования этого принципа выглядит так: введение (контекст и вопрос) → главное утверждение (ответ) → аргументы (подтверждающие детали). А дальше мы разберем каждую часть этого шаблона. 1️⃣Вводная часть по Минто должна задать сцену и проблему Для этого можно использовать паттерн SCQA (Situation–Complication–Question–Answer): описать ситуацию и контекст, указать основную проблему или сложность, логично вытекающий из неё вопрос - и плавно привести читателя к вашему ответу, то есть к главному тезису. Например: "В компании Х задерживаются релизы (ситуация). Причина - хаос в требованиях (проблема), встаёт вопрос: как навести порядок? Решение: ввести чёткий процесс спефикации и управления задачами (ответ)." После такого вступления читатель уже понимает, о чём пойдёт речь, и готов воспринять ваш основной тезис. 2️⃣ Главная идея (тезис) - это вершина пирамиды Именно эту мысль вы хотите донести. Минто советует формулировать её сразу после введения, чтобы читатель не гадал, куда вы клоните. В деловой переписке такой прямой подход экономит кучу времени: адресат сразу видит, в чём дело, и не расходует лишней умственной энергии на поиски смысла между строк. Суть в том, что у читателя ограничен запас ментальной энергии: часть тратится на чтение слов, ещё часть - на увязывание идей между собой, и только то, что останется, идёт на понимание сути. Поэтому чем яснее и логичнее подача, тем больше шансов, что смысл дойдёт до адресата. Пирамида Минто как раз освобождает мозг читателя от необходимости самому структурировать кашу из фактов - вы делаете это за него заранее. 3️⃣ Аргументы и детали - основание пирамиды Здесь приводятся факты, данные, объяснения, поддерживающие главный тезис. Важно, что они не вываливаются списком, а группируются логично. Барбара Минто сформулировала три правила для структуры пирамиды - Обобщение снизу вверх: идеи на каждом уровне должны обобщать материалы уровня ниже. Верхушка пирамиды - квинтэссенция идей снизу, каждый подпункт - резюме своих под-подпунктов и т.д.. Благодаря этому читатель может прочесть только верхние уровни и уже получить связную картину. - Однородность идей: в одной группе аргументы должны быть одного типа и порядка. Если вы перечисляете, скажем, три причины проблемы, все три должны быть именно причинами (а не две причины и одно следствие вперемешку). Однородности идей можно достигнуть используя примерно одинаковый уровень абстракции, а также принцип MECE (Mutually Exclusive, Collectively Exhaustive) для перечислений. - Логичный порядок: идеи в каждой группе упорядочены по какому-то разумному признаку - например, по важности, хронологии или структуре. Нелогичная последовательность сбивает с толку. Минто вообще называла хаотичное изложение "плохими манерами" по отношению к читателю. Хороший автор проведёт читателя по своим аргументам шаг за шагом. Следуя этим правилам, вы выстраиваете пирамиду снизу вверх при подготовке текста (сначала собираете и группируете идеи), а излагаете сверху вниз. Результат - стройная логическая конструкция, где читателю сначала дают карту маршрута, а потом уже ведут по пунктам. Если вдруг какой-то аргумент отпадает или оспаривается, общая мысль всё равно удержится на остальных опорах. P.S. Барбара написала целую книжку про этот принцип, которая вышла в далеком 1987 году. С тех пор книга много раз переиздавалась. #Thinking #Writing #Leadership #Management

Minecraft в режиме творчества (Рубрика #ForKids) Minecraft в нашей жизни уже давно - когда-то в него рубился мой старший сын Паша, которому уже девятнадцать, потом покорял Minecraft средний сын Максим, которому сейчас десять, а последний год Vайнкрафтом увлекается мой младший сын Кирилл, которому недавно исполнилось 5. Кирилл слушает аудиосказки про майнкрафт, смотрим разборы блоггеров, даже торт на день рождения у него был в стиле майнкрафта. Но мне стыдно призняться, что я в Minecraft не слишком много понимаю. Именно поэтому я решил купить Кириллу (и себе) книжку "Minecraft в режиме творчества, где изложена база по этой игре, а также рассказывается как спланировать постройку, как подобрать цветовую гамму, как правильно подобрать освещение и так далее. В общем, мне понравилось читать эту книгу сыну на ночь - я сам узнал многое про майнкрафт, а он про то, как проектировать и планировать выполнение строительных проектов:)) #ForKids #ForParents

How AI will change software engineering (Рубрика #Engineering) Посмотрел интересное интервью Martin Fowler о том, что реально меняется для инженеров и тимлидов из‑за LLM и coding‑агентов. Мартин давал интервью Гергели Орошу в рамках подкаста Pragmatic Engineer. Сам разговор получился плотным (в самый раз для просмотра на 2x скорости) и ключевыми тезисами были следующие 🤖 AI - крупнейший сдвиг в разработке со времён высокоуровневых языков Фаулер ставит нынешнюю волну ИИ в один ряд с переходом от ассемблера к Fortran/C: это новая парадигма работы с кодом, а не “ещё один инструмент в IDE”. 🎲 Код становится недетерминированным - нужно мыслить “допусками” LLM не гарантирует одинаковый результат на один и тот же запрос. Фаулер предлагает заимствовать из классической инженерии мышление про допуски и запас прочности: заранее решать, где вариативность допустима, а где нужна жёсткая детерминированность и дополнительные проверки (особенно в безопасности). 👩‍💻Тесты важнее, чем когда‑либо Тесты теперь страхуют и людей, и модель. Любой сгенерированный LLM код должен проходить такой же, а лучше - более жёсткий, набор автотестов, статического анализа и quality‑checks. Без этого “ускорение” от ИИ превращается в отложенный технический долг. На эту тему рекомендую почитать книгу "AI Engineering" и конкретно главы "Evaluation Methodology" и "Evaluate AI Systems", что я уже разбирал в подкасте с обзором книги 🤖 AI + детерминированные инструменты > AI в одиночку Один из ключевых паттернов: LLM генерирует черновой код, а предсказуемые инструменты делают массовые и безопасные трансформации - миграции, рефакторинги, форматирование. 👾 LLM особенно полезны для легаси и рефакторинга AI показывает отличные результаты в рефакторинге старых монолитов, демонстрируя понимание странных зависимостей, генерируя первые варианты рефакторинга и миграций (например, на новый фреймворк или архитектурный паттерн). Но именно люди решают, куда систему развивать и какой “целевой дизайн” считать приемлемым. 💯 Vibe coding - режим прототипов, а не продакшена Vibe coding - это создание решения, когда вы в основном говорите с агентом/IDE, почти не читая получившийся код. Это даёт огромную скорость для прототипов и одноразовых проектов, но переносить такой код в прод без ревью и тестов - гарантированные баги, уязвимости и проблемы с поддержкой. 📚 Список ключевых навыков инженера не поменялся Несмотря на хайп вокруг ИИ, по мнению Фаулера, всё ещё решают: понимание домена, умение строить абстракции и архитектуру, делать осознанные trade-offs коммуницировать с бизнесом и командой. LLM усиливают сильных инженеров, но не подменяют сами навыки. 🔁 Agile по‑прежнему про обратную связь и обучение - просто цикл стал быстрее Основные принципы Agile (короткие итерации, работа с заказчиком, постоянное обучение) остаются валидными. LLM‑инструменты лишь ускоряют цикл “придумал → набросал → проверил → переписал”, но не заменяют живую обратную связь, парное программирование и ретро. 🧠 ИИ не отменяет необходимость самому учиться программировать Фаулер подчёркивает: разработка - это всегда процесс обучения. Если постоянно “аутсорсить” мышление ИИ, не формируется внутренняя модель системы, и команда быстро прилетает в maintenance‑cliff: код есть, понимания нет. Инструменты могут ускорять, но не могут “выучить за вас”. 🚀 Совет тимлидам: начинайте с низкорисковых сценариев Внедрять ИИ лучше начать с документации, тестов, сниппетов, миграций и работы с легаси, а не с критических бизнес‑флоу. Параллельно вкладываться в автотесты, observability и инженерную культуру - тогда выгода от ИИ не будет одноразовым “демо‑эффектом”. 🌱 Совет джунам: не становитесь просто “операторами промптов” Для начинающих разработчиков ИИ - отличный репетитор: можно просить объяснить незнакомый код, показать альтернативные решения, придумать упражнения. Но если ограничиться промптами и никогда не разбираться в том, что под капотом, - роста до middle/senior не будет. Нужны свои попытки, ошибки и рефакторинги. #Architecture #Software #AI #Engineering #ML #Data #SystemDesign

⚡️ Как мы внедряем ИИ в SDLC и зачем это нужно За последний год мы систематически внедрили ИИ-инструменты во все этапы жизненного цикла разработки и активно делимся нашим опытом, проблемами и их решениями. Например, недавно рассказывали про то, как измерять продуктивность инженеров. А вчера открыли запись на early access к нашему ИИ‑агенту для разработчиков. Сегодня делимся, как ИИ уже помогает нам в разработке, какие технологии используем и каких результатов достигли. ↗️ Основные сценарии — в карточках, а больше деталей — в статье на Хабре. #AI4SDLC

Отличный рассказ про опыт Т-Банка о внедрении AI в процессы разработки. Для любителей можно почитать карточки, а подробности есть в статье Коли Бушкова

«Экономика не выживет»? Тревожный звонок для России / Олег Вьюгин о налогах, рубле и ипотеке (Рубрика #Economics) Иногда я смотрю нашу передачу "Деньги не спят", в которой ведущие с гостями обсуждают экономические темы очень динамично и наглядно. А конкретно этот выпуск был интересен тем, что в нем обсуждались текущее состояние и перспективы российской экономики на 2025-2026 годы. Для разбора этой темы в гости к Рине Ахмадулиной пришел Олег Вьюгин - заслуженный экономист, профессор ВШЭ, бывший первый замглавы Минфина и ЦБ РФ, экс-председатель наблюдательного совета Мосбиржи. Они говорили больше часа и успели обсудить множество тем, среди которых основными были следующие 📉🧾 Налоговое давление и стагнация В экономике сохраняется высокая налоговая нагрузка, признаки стагнации и риска недобора налогов, несмотря на их повышение, бюджет "затянут"​ 📈🏭 Высокая ставка и проблемы бизнеса Ключевая ставка остаётся высокой, её снижение в ближайшие месяцы маловероятно, что увеличивает проблемы предприятий, провоцируя рост проблемных кредитов.​ 🏦💰 ФНБ и бюджет Средства ФНБ не планируют тратить для покрытия дефицита бюджета - рассчитывают на альтернативные источники дохода, но в случае серьёзного недобора возможен пересмотр.​ 💹🇷🇺 Состояние рубля Крепкий рубль - результат снижения импорта и устойчивого экспорта; курс стабилен и его искусственное ослабление не планируется.​ 🤑🏦 Банковский сектор Банки - главные бенефициары инфляции и высокой ставки, однако их доходы сократятся при замедлении инфляции. Дополнительные налоги на банки не рассматриваются, чтобы не создавать дополнительных рисков для системы.​ 🏭⚠️ Отрасли под риском Под ударом - угольная промышленность, металлургия, автопром. Устойчивы - премиум-недвижимость, ритейл. IT и медицина также теряют льготы, развитие затруднено.​ 💵📊 Долговой рынок и инвестиции Банки переводят заёмщиков на облигационный рынок, инвесторам стоит быть осторожнее, особенно в уязвимых отраслях. Большие портфели - в недвижимости, облигациях, немножко - в акциях, золоте. 🏡🔑 Перспективы ипотеки и недвижимости Рынок недвижимости устойчив, цены в Москве растут за счёт сокращения объёмов новостроек и управления ценами.​ #Economics #Management

EventStorming (Рубрика #Architecture) Сегодня провел день в роли фасиллитатора сессии event storming, которая была посвящена домену a/b экспериментов. Это было занимательно и утомительно:) Этот подход придумал Alberto Brandolini для того, чтобы пошарить знания между экспертами доменной области и разработчиками максимально эффективно. В итоге, техника представляет из себя воркшоп из следущего набора шагов (часто глубина проработки может быть не такой детальной) - Unstructured exploration — на этом шаге в режиме брейншторма все участники группы самостоятельно накидывают на доску domain events - Timelines — сгенерированные на предыдущем шаге domain events выстраиваются в хронологическом порядке, начиная с happy path - Commands — на этом шаге добавляются commands, которые описывают что именно триггерит событие или поток событий. У части команд есть actor, который и запускает выполнение команды - Policies — на этом шаге идет разбор команд, которые не имеют actor. У таких команд есть policy, когда запускается такая команда, обычно она завязана на наступление какого-то другого domain event - External systems — на этом шаге модель расширяется внешними системами, которые не являются частью домена, что разбирается, но которые участвуют в процессе, например, исполняют command или получают нотификации о domain events - Aggregates — когда все команды и события на месте, участники могут начать задумываться об оптимизации и выделении aggregates, которые получают команды и генерируют события - Bounded contexts — на последнем шаге время посмотреть на всю картину. Группы тесно связанных aggregates являются естественными кандидатами на определение границ для bounded contexts На приложенных фотографиях 1. Кусочек получившейся сегодня схемы - ребята отлично поработали, собрали timeline сложного процесса, выделили actors и проработали разделение на bounded contexts 2. Примерная поэтапная схема проведения воркшопа P.S. У автора подхода есть книга, которая уже много лет написана на 70%. Я ее даже как-то читал:) Есть куча выступлений с описанием подхода: - с конференции GOTO в 2018 - с конференции DDD Europe в 2019 - с конференции USI Events в 2021 #DDD #Architecture #Processes #EventStorming

10x engineer - Midlife crisis (Рубрика #Humor) Вышел свежий скетч про кризис среднего возраста легендарного 10x инженера, где юмор построен на иронии и сарказме в отношении стереотипов и типичных ситуаций из жизни разработчика, который считается гиперпродуктивным, но при этом ведет себя эксцентрично. Мы видим примеры абсурдности технологического мира, гиперболизации умственных способностей, чрезмерного цинизма и отчуждение героя от обычных людей (он зовет их NPC - неигровыми персонажами). Вот несколько примеров шуток

- Look at all these NPCs sinking their souls into whatever cloud has the brightest gradient. They don't even know. I'm really big intelligent. I see what's going on. - NPCs using free products, thinking it's freedom, giving up their brain, their liberty, seeking connection. They don’t even know there’s a zero day in their connection. - Everyone's just mind control, you know, AI is coming. They don't even know. - Look at all these NPCs sitting there walking, getting controlled. We're not NPC. I'm not NPC. You and me, brother. - Sometimes they realize the force behind everything is nothing but people. Simple people. A human conversation can give you hope.

Один из популярных комментариев под видео звучит так "The new season of Mr. Robot looks different, but I'll take it" и действительно послевкусие от видео похоже на сериал Mr. Robot, чей первый сезон вышел 10 лет назад. #Software #Engineering #Humor #Productivity

Стратсессия в Ереване (Рубрика #Strategy) Улетел на 3 дня в Ереван, чтобы с коллегами поговорить про результаты и стратегию отдела, что занимается на всю компанию продуктовой аналитикой, a/b экспериментами, расчетом метрик и т.д. Это очень важные темы, которые позволяют крупной комапнии оптимизировать свои продукты и процессы опираясь на данные, а не на мнения самых высокооплачиваемых людей (HiPPO, Highest Paid Person's Opinion). Именно поэтому нашу систему для экспериментов мы назвали HiPPO:) Кстати, с Андреем Цыбиным, руководителем отдела мы уже записывали серию подкаста "Code of Leadership", где мы обсуждали часть про продуктовую аналитику (систему Statist), а вскоре запишем новую серию про a/b платформу. Но вообще, наша a/b платформа основывается методологически на книге Доверительное a/b тестирование (Trustworthy Online Controlled Experiments), что написали - Ron Kohavi (Fellow & VP @ Microsoft), Diane Tang (Fellow @ Google), Ya Xu (head of DS @ LinkedIn). В начале стратсессии я рассказал про важность работы с данными и получения инсайтов на примере Netflix - они в 2023 году на появившуюся позицию CTO назначил руководителя блока Data & Insight. Этим руководителем была Элизабет Стоун (про подкаст с которой я рассказывал раньше). Собственно, для нашей компании с большим количеством зрелых продуктов, экосистемных эффектов, разным подходам при работе с сегментами, эти подходы важны не меньше, чем тому же Netflix. Ну и во время стратсессии мы планируем провести сессию event storming, которая позволяет пошарить понимание процессов работы над экспериментами, статистикой и так далее. Это позволит нам понять как дальше улучшать user experience наших коллег при работе в этом домене. P.S. Последний раз в Ереване я был 2 года назад, когда на открытии нашего офиса рассказывал про RnD в крупных компаниях. С тех пор я заметил, что парк машин обновился и в такси приезжают новенькие BYD:) #Culture #Management #Leadership #Processes #Engineering #Software #Metrics #Strategy

[2/2] Про Netflix - Инфраструктура, архитектура и AI (Рубрика #Engineering) Продолжая рассказ про Netflix, надо рассказать про технические основы компании. Netflix целиком работает в облаке и использует передовую распределённую архитектуру. Все серверные системы Netflix развернуты на AWS - компания завершила полный переход в облако Amazon в 2016 году и с тех пор не владеет собственными дата-центрами. Сегодня инфраструктура Netflix насчитывает сотни и тысячи микросервисов, работающих в нескольких регионах AWS и обслуживающих более 230+ млн аккаунтов по всему миру. Приложения разделены по функциональным сервисам (от профиля пользователя и системы рекомендаций до системы платежей или каталога видео), которые общаются друг с другом через API. Такой переход на микросервисную архитектуру был начат ещё в 2009–2012 годах, когда Netflix разрезал свою монолитную систему на отдельные сервисы для повышения масштабируемости Netflix построил целый набор внутренних платформенных решений поверх AWS, чтобы упростить жизнь своим разработчикам. Среди них - Собственная система оркестрации Titus (внутренний проект, потом open source). Titus интегрирован с AWS (управляет EC2-инстансами), позволяя инженерам деплоить свои сервисы в контейнерах без необходимости вручную оперировать виртуальными машинами. - Собственная система CD Spinnaker (внутренний проект, потом open source). Она работает поверх Titus и автоматизирует развёртывание микросервисов сразу по всем регионам (мульти-регионные деплойменты) - Собственный API Gateway Zuul (внутренний проект, потом open source). В обновлённой версии Zuul 2 он построен на неблокирующей Netty и выдерживает огромные объемы соединений, выступая первым рубежом масштабирования - Собственный circuit breaker Hystrix (внутренний проект, потом open source). Интересно, что внутри Netflix от него потом отказались - Практика chaous engineering и инструменты Chaos Monkey, Simian Army: Latency Monkey, Chaos Kong и др. Архитектура данных Netflix распределена и масштабируема - Apache Cassandra используется для высоконагруженных онлайн-хранилищ, где огромные объемы и требуется горизонтальное масштабирование - Поверх различных хранилищ Netflix реализовал абстрактный слой KV Storage, унифицирующий доступ для разработчиков и инкапсулирующий детали репликации данных - Для кеширования часто запрашиваемых данных (профили, списки рекомендаций и пр.) в нескольких датацентрах применяется собственный сервис EVCache (поверх memcached) - Потоковые данные обрабатываются через стриминговую платформу Mantis (внутренний проект, потом open source). Платформа способна в реальном времени фильтровать и агрегировать миллионы событий - Для пакетных задач big data используется комбинация решений: Keystone - стриминг поверх Kafka, и Genie - оркестратор задач в Hadoop/Spark кластерах (последний релиз в open source был 3 года назад) - В 2020-х Netflix открыла исходники Conductor - своего оркестратора бизнес-воркфлоу для микросервисов - В 2024 году выложила в open-source и новую версию оркестратора data/ML-пайплайнов Maestro. Хотя вычислительные сервисы Netflix работают в AWS, для доставки видео-трафика компания построила собственную CDN-сеть Netflix Open Connect. Эта инфраструктура решает задачу стриминга гигантских объёмов данных (сотни Tbps) с оптимальным качеством. Open Connect представляет собой флот физических caching-апплиансев, которые Netflix устанавливает в узлах интернет-провайдеров по всему миру Если говорить про AI/ML, то - Опыт пользователя персонализирован, рекомендации, обложки фильмов - При помощи AI/ML оптимизируется инфраструктура сервисов, чтобы снизить косты - AI используется для производства контента, а также, например, для создания трейлеров В итоге, видно, а почему Netflix считается технологической компанией. #Culture #Management #Leadership #Processes #Engineering #Software

[1/2] Про Netflix - Бизнес-планы и оргструктура (Рубрика #Business) После просмотра подкаста с Элизабет Стоун, техническим директором Netflix, мне стало интересно, а как они в общем поживают, куда смотрит бизнес, как выглядит оргструктура и как выглядит инженерная культура и как дела с архитектурой. В первом посте мы обсудим все кроме архитектуры. Netflix делает ставку на следующие направления 1️⃣ Основной бизнес стриминга - Здесь увеличиваются инвестиции в оригинальный контент, развиваются инструменты для кинопроизводства - Совершенствуется персонализация сервиса и монетизируется совмстное использование (платный шеринг) - Успешно движется пилотирование прямых трансляций - Идут работы по приросту подписчиков, например, за счет тарифных планов с рекламой 2️⃣ Рекламный бизнес - Изначально компания быстро вышла на рынок рекламы вместе с Microsoft - Спустя полтора года после запуска тарифов с рекламой Netflix объявил о создании собственной ad-tech платформы - Цель - самостоятельно контролировать рекламные технологии, чтобы предлагать брендам более таргетированные и персонализированные объявления для ~270 млн пользователей. 3️⃣ Рынок видеоигр и облачного гейминга - Начиная с 2021 года Netflix включил мобильные игры в подписку - В 2024 году Netflix назначил президента по играм Алена Таскана, экс-руководителя студии Epic Games, чьей целью было сделать так, чтобы "играть на Netflix было так же легко, как стримить кино в пятницу вечером" - В 2025 году Netflix зашла на рынок облачного гейминга и стартовала интеграции игр непосредственно в приложение Netflix на ТВ: пользователь выбирает игру на экране телевизора, а смартфон используется в роли контроллера. Таким образом, Netflix устранняет лишние препятствия для казуальных игроков - За первые 10 месяцев 2025 года уже есть результаты - количество загрузок игр выросло на 17% (до ~74,8 млн) по сравнению с аналогичным периодом 2024 года. Если говорить про оргструктуру, то технологическое подразделение играет стратегическую роль. В январе 2023 года сооснователь Рид Хастингс отошёл от оперативного управления, и руководство перешло к двум со-CEO: Тед Сарандос отвечает за контентное направление, а Грег Питерс - за продуктово-техническое. Грег Питерс ранее многие годы возглавлял development и продуктовую организацию Netflix, и с его повышением до co-CEO технологическая повестка получила ещё более высокий приоритет на уровне высшего менеджмента. В конце 2023 года Netflix обновил высший технический состав - Появилась позиция CTO и на пост главного технического директора назначили Элизабет Стоун (про подкаст с которой я рассказывал раньше). Стоун пришла в Netflix в 2020 году и руководила командой Data & Insights (департамент продуктовой аналитики и науки о данных). Наверное, это назначение подчёркивает, что компания видит свое будущее в тесном симбиозе технологий и анализа данных - Параллельно должность Chief Product Officer (CPO) заняла Юнис Ким, отвечающая за пользовательский продукт (интерфейсы, рекомендации, игровой UX и т.д.) По словам Грега Питерса, эти два лидера “будут возглавлять чрезвычайно важную часть нашего сервиса” - то есть всю техническую платформу и пользовательский опыт, улучшая возможности поиска и открытия контента (фильмов, сериалов и игр) для аудитории. Таким образом, на уровне топ-менеджмента создан тандем, в котором технологии и продукт находятся в фокусе развития Netflix. Если же говорить про инженерную культуру, то ее отлично описала Элизабет в уже упоминавшемся подкасте. А в следующем посте я расскажу про инфраструктуру и архитектуру Netflix (по-крайней мере про то, о чем они рассказывали публично за последние 10-15 лет). #Culture #Management #Leadership #Processes #Engineering #Software

[2/2] Китайская модель. Почему Китай отставал от Запада, а теперь его обгоняет (Рубрика #Economics) Продолжая рассказ про китайскую модель развития, расскажу про шестиэтапную модель развития Китая по Попову 1️⃣ Политическая и социальная стабильность Создание сильной центральной власти, единства страны и базового равенства (недопущение крайних форм неравенства) - то, что Китай реализовал после потрясений первой половины XX века, установив жесткую государственную систему и порядок 2️⃣ Мобилизация инвестиций Обеспечение чрезвычайно высокой нормы накопления - государство изымает и концентрирует значительную часть прибылей в бюджете и направляет их на централизованные инвестиции в развитие. Исторически это происходило, например, через коллективизацию и госрегулирование при Мао, позволившие направить ресурсы на индустриализацию 3️⃣ Повышение эффективности экономики Внедрение рыночных механизмов и стимулов технического прогресса, чтобы вложения начали давать отдачу. Этот этап - реформы Дэн Сяопина с конца 1970-х, когда сохраняется сильное государство, но допускается конкуренция, частное предпринимательство, иностранные инвестиции и т.д., что резко повысило продуктивность. 4️⃣ Экономический суверенитет Защита внутреннего рынка и развитие собственных производств посредством импортозамещения и разумного протекционизма. Китай последовательно выращивал национальную промышленность - от стали и автомобилей до высоких технологий - ограждая её на ранних стадиях от уничтожающей конкуренции извне. 5️⃣ Выход на внешние рынки Ориентация на экспорт и глобальную конкурентоспособность. Достигнув достаточного промышленного потенциала, Китай сделал ставку на захват внешних рынков - благодаря дешёвой рабочей силе и искусственно заниженному курсу юаня его товары стали сверхконкурентоспособны на мировом рынке, что привело к многолетнему экспорту-буму. Кстати, про это можно почитать историю компании Haier, которую упоминает Попов и книгу о которой я уже разбирал 6️⃣ Адаптивность политики и институтов Постоянное приспособление системы под меняющиеся условия. Китайские власти гибко реагируют на новые вызовы - будь то мировые кризисы, торговые войны или внутренние социальные проблемы. Меняются приоритеты (например, сейчас больший упор на внутреннее потребление и инновации), усиливается или ослабляется госрегулирование в разных сферах по мере необходимости. Эта адаптивность позволяет модели не застаиваться. Странам, что хотят повторить китайскую модель развития, нужно искать свой баланс между государственным управлением и рыночными механизмами, опираясь на сильные институты, инвестируя в развитие и действуя стратегически. Китай прошёл путь от бедности к силе за одно поколение – и в его истории можно найти ориентиры, как сочетать стабильность с реформами, национальные интересы с глобальной конкуренцией. Именно такой комплексный, этапный подход к развитию, по мнению Попова, может стать рецептом успеха и для других стран. #Economics #Strategy #Processes #History #PopularScience