Стратсессия в Ереване (Рубрика #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
Улетел на 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
❤15🔥7👍3
10x engineer - Midlife crisis (Рубрика #Humor)
Вышел свежий скетч про кризис среднего возраста легендарного 10x инженера, где юмор построен на иронии и сарказме в отношении стереотипов и типичных ситуаций из жизни разработчика, который считается гиперпродуктивным, но при этом ведет себя эксцентрично. Мы видим примеры абсурдности технологического мира, гиперболизации умственных способностей, чрезмерного цинизма и отчуждение героя от обычных людей (он зовет их NPC - неигровыми персонажами). Вот несколько примеров шуток
Один из популярных комментариев под видео звучит так "The new season of Mr. Robot looks different, but I'll take it" и действительно послевкусие от видео похоже на сериал Mr. Robot, чей первый сезон вышел 10 лет назад.
#Software #Engineering #Humor #Productivity
Вышел свежий скетч про кризис среднего возраста легендарного 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
YouTube
10x engineer - Midlife crisis
Look at all these NPCs 2025.
Not an ad.
Inspired & Music by @omalleyrock Slugs - https://www.youtube.com/watch?v=wYrNjPGgAAA
Not an ad.
Inspired & Music by @omalleyrock Slugs - https://www.youtube.com/watch?v=wYrNjPGgAAA
1😁6👍3🔥2
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
Сегодня провел день в роли фасиллитатора сессии 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
1👍16❤8🔥6
«Экономика не выживет»? Тревожный звонок для России / Олег Вьюгин о налогах, рубле и ипотеке (Рубрика #Economics)
Иногда я смотрю нашу передачу "Деньги не спят", в которой ведущие с гостями обсуждают экономические темы очень динамично и наглядно. А конкретно этот выпуск был интересен тем, что в нем обсуждались текущее состояние и перспективы российской экономики на 2025-2026 годы. Для разбора этой темы в гости к Рине Ахмадулиной пришел Олег Вьюгин - заслуженный экономист, профессор ВШЭ, бывший первый замглавы Минфина и ЦБ РФ, экс-председатель наблюдательного совета Мосбиржи. Они говорили больше часа и успели обсудить множество тем, среди которых основными были следующие
📉 🧾 Налоговое давление и стагнация
В экономике сохраняется высокая налоговая нагрузка, признаки стагнации и риска недобора налогов, несмотря на их повышение, бюджет "затянут"
📈 🏭 Высокая ставка и проблемы бизнеса
Ключевая ставка остаётся высокой, её снижение в ближайшие месяцы маловероятно, что увеличивает проблемы предприятий, провоцируя рост проблемных кредитов.
🏦 💰 ФНБ и бюджет
Средства ФНБ не планируют тратить для покрытия дефицита бюджета - рассчитывают на альтернативные источники дохода, но в случае серьёзного недобора возможен пересмотр.
💹🇷🇺 Состояние рубля
Крепкий рубль - результат снижения импорта и устойчивого экспорта; курс стабилен и его искусственное ослабление не планируется.
🤑 🏦 Банковский сектор
Банки - главные бенефициары инфляции и высокой ставки, однако их доходы сократятся при замедлении инфляции. Дополнительные налоги на банки не рассматриваются, чтобы не создавать дополнительных рисков для системы.
🏭⚠️ Отрасли под риском
Под ударом - угольная промышленность, металлургия, автопром. Устойчивы - премиум-недвижимость, ритейл. IT и медицина также теряют льготы, развитие затруднено.
💵 📊 Долговой рынок и инвестиции
Банки переводят заёмщиков на облигационный рынок, инвесторам стоит быть осторожнее, особенно в уязвимых отраслях. Большие портфели - в недвижимости, облигациях, немножко - в акциях, золоте.
🏡 🔑 Перспективы ипотеки и недвижимости
Рынок недвижимости устойчив, цены в Москве растут за счёт сокращения объёмов новостроек и управления ценами.
#Economics #Management
Иногда я смотрю нашу передачу "Деньги не спят", в которой ведущие с гостями обсуждают экономические темы очень динамично и наглядно. А конкретно этот выпуск был интересен тем, что в нем обсуждались текущее состояние и перспективы российской экономики на 2025-2026 годы. Для разбора этой темы в гости к Рине Ахмадулиной пришел Олег Вьюгин - заслуженный экономист, профессор ВШЭ, бывший первый замглавы Минфина и ЦБ РФ, экс-председатель наблюдательного совета Мосбиржи. Они говорили больше часа и успели обсудить множество тем, среди которых основными были следующие
В экономике сохраняется высокая налоговая нагрузка, признаки стагнации и риска недобора налогов, несмотря на их повышение, бюджет "затянут"
Ключевая ставка остаётся высокой, её снижение в ближайшие месяцы маловероятно, что увеличивает проблемы предприятий, провоцируя рост проблемных кредитов.
Средства ФНБ не планируют тратить для покрытия дефицита бюджета - рассчитывают на альтернативные источники дохода, но в случае серьёзного недобора возможен пересмотр.
💹
Крепкий рубль - результат снижения импорта и устойчивого экспорта; курс стабилен и его искусственное ослабление не планируется.
Банки - главные бенефициары инфляции и высокой ставки, однако их доходы сократятся при замедлении инфляции. Дополнительные налоги на банки не рассматриваются, чтобы не создавать дополнительных рисков для системы.
🏭⚠️ Отрасли под риском
Под ударом - угольная промышленность, металлургия, автопром. Устойчивы - премиум-недвижимость, ритейл. IT и медицина также теряют льготы, развитие затруднено.
Банки переводят заёмщиков на облигационный рынок, инвесторам стоит быть осторожнее, особенно в уязвимых отраслях. Большие портфели - в недвижимости, облигациях, немножко - в акциях, золоте.
Рынок недвижимости устойчив, цены в Москве растут за счёт сокращения объёмов новостроек и управления ценами.
#Economics #Management
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
«Экономика не выживет»? Тревожный звонок для России / Олег Вьюгин о налогах, рубле и ипотеке
Новый выпуск «Деньги не спят» в наших лучших традициях — местами страшный, но интересный!
В гостях — Олег Вьюгин, заслуженный экономист, банкир, профессор Высшей школы экономики. В прошлом занимал должности председателя наблюдательного совета Мосбиржи,…
В гостях — Олег Вьюгин, заслуженный экономист, банкир, профессор Высшей школы экономики. В прошлом занимал должности председателя наблюдательного совета Мосбиржи,…
1👍6👎6🔥4❤2👀2
Отличный рассказ про опыт Т-Банка о внедрении AI в процессы разработки. Для любителей можно почитать карточки, а подробности есть в статье Коли Бушкова
👍3
Forwarded from Код Желтый
За последний год мы систематически внедрили ИИ-инструменты во все этапы жизненного цикла разработки и активно делимся нашим опытом, проблемами и их решениями. Например, недавно рассказывали про то, как измерять продуктивность инженеров. А вчера открыли запись на early access к нашему ИИ‑агенту для разработчиков.
Сегодня делимся, как ИИ уже помогает нам в разработке, какие технологии используем и каких результатов достигли.
#AI4SDLC
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤9👍2🔥1
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
Посмотрел интересное интервью Martin Fowler о том, что реально меняется для инженеров и тимлидов из‑за LLM и coding‑агентов. Мартин давал интервью Гергели Орошу в рамках подкаста Pragmatic Engineer. Сам разговор получился плотным (в самый раз для просмотра на 2x скорости) и ключевыми тезисами были следующие
Фаулер ставит нынешнюю волну ИИ в один ряд с переходом от ассемблера к Fortran/C: это новая парадигма работы с кодом, а не “ещё один инструмент в IDE”.
LLM не гарантирует одинаковый результат на один и тот же запрос. Фаулер предлагает заимствовать из классической инженерии мышление про допуски и запас прочности: заранее решать, где вариативность допустима, а где нужна жёсткая детерминированность и дополнительные проверки (особенно в безопасности).
Тесты теперь страхуют и людей, и модель. Любой сгенерированный LLM код должен проходить такой же, а лучше - более жёсткий, набор автотестов, статического анализа и quality‑checks. Без этого “ускорение” от ИИ превращается в отложенный технический долг. На эту тему рекомендую почитать книгу "AI Engineering" и конкретно главы "Evaluation Methodology" и "Evaluate AI Systems", что я уже разбирал в подкасте с обзором книги
Один из ключевых паттернов: LLM генерирует черновой код, а предсказуемые инструменты делают массовые и безопасные трансформации - миграции, рефакторинги, форматирование.
AI показывает отличные результаты в рефакторинге старых монолитов, демонстрируя понимание странных зависимостей, генерируя первые варианты рефакторинга и миграций (например, на новый фреймворк или архитектурный паттерн). Но именно люди решают, куда систему развивать и какой “целевой дизайн” считать приемлемым.
Vibe coding - это создание решения, когда вы в основном говорите с агентом/IDE, почти не читая получившийся код. Это даёт огромную скорость для прототипов и одноразовых проектов, но переносить такой код в прод без ревью и тестов - гарантированные баги, уязвимости и проблемы с поддержкой.
📚 Список ключевых навыков инженера не поменялся
Несмотря на хайп вокруг ИИ, по мнению Фаулера, всё ещё решают: понимание домена, умение строить абстракции и архитектуру, делать осознанные trade-offs коммуницировать с бизнесом и командой. LLM усиливают сильных инженеров, но не подменяют сами навыки.
🔁 Agile по‑прежнему про обратную связь и обучение - просто цикл стал быстрее
Основные принципы Agile (короткие итерации, работа с заказчиком, постоянное обучение) остаются валидными. LLM‑инструменты лишь ускоряют цикл “придумал → набросал → проверил → переписал”, но не заменяют живую обратную связь, парное программирование и ретро.
🧠 ИИ не отменяет необходимость самому учиться программировать
Фаулер подчёркивает: разработка - это всегда процесс обучения. Если постоянно “аутсорсить” мышление ИИ, не формируется внутренняя модель системы, и команда быстро прилетает в maintenance‑cliff: код есть, понимания нет. Инструменты могут ускорять, но не могут “выучить за вас”.
Внедрять ИИ лучше начать с документации, тестов, сниппетов, миграций и работы с легаси, а не с критических бизнес‑флоу. Параллельно вкладываться в автотесты, observability и инженерную культуру - тогда выгода от ИИ не будет одноразовым “демо‑эффектом”.
🌱 Совет джунам: не становитесь просто “операторами промптов”
Для начинающих разработчиков ИИ - отличный репетитор: можно просить объяснить незнакомый код, показать альтернативные решения, придумать упражнения. Но если ограничиться промптами и никогда не разбираться в том, что под капотом, - роста до middle/senior не будет. Нужны свои попытки, ошибки и рефакторинги.
#Architecture #Software #AI #Engineering #ML #Data #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
How AI will change software engineering – with Martin Fowler
Martin Fowler is one of the most influential people within software architecture, and the broader tech industry. He is the Chief Scientist at Thoughtworks and the author of Refactoring and Patterns of Enterprise Application Architecture, and several other…
👍33❤11🔥7
Minecraft в режиме творчества (Рубрика #ForKids)
Minecraft в нашей жизни уже давно - когда-то в него рубился мой старший сын Паша, которому уже девятнадцать, потом покорял Minecraft средний сын Максим, которому сейчас десять, а последний год Vайнкрафтом увлекается мой младший сын Кирилл, которому недавно исполнилось 5. Кирилл слушает аудиосказки про майнкрафт, смотрим разборы блоггеров, даже торт на день рождения у него был в стиле майнкрафта. Но мне стыдно призняться, что я в Minecraft не слишком много понимаю. Именно поэтому я решил купить Кириллу (и себе) книжку "Minecraft в режиме творчества, где изложена база по этой игре, а также рассказывается как спланировать постройку, как подобрать цветовую гамму, как правильно подобрать освещение и так далее. В общем, мне понравилось читать эту книгу сыну на ночь - я сам узнал многое про майнкрафт, а он про то, как проектировать и планировать выполнение строительных проектов:))
#ForKids #ForParents
Minecraft в нашей жизни уже давно - когда-то в него рубился мой старший сын Паша, которому уже девятнадцать, потом покорял Minecraft средний сын Максим, которому сейчас десять, а последний год Vайнкрафтом увлекается мой младший сын Кирилл, которому недавно исполнилось 5. Кирилл слушает аудиосказки про майнкрафт, смотрим разборы блоггеров, даже торт на день рождения у него был в стиле майнкрафта. Но мне стыдно призняться, что я в Minecraft не слишком много понимаю. Именно поэтому я решил купить Кириллу (и себе) книжку "Minecraft в режиме творчества, где изложена база по этой игре, а также рассказывается как спланировать постройку, как подобрать цветовую гамму, как правильно подобрать освещение и так далее. В общем, мне понравилось читать эту книгу сыну на ночь - я сам узнал многое про майнкрафт, а он про то, как проектировать и планировать выполнение строительных проектов:))
#ForKids #ForParents
👍12🔥7❤5👎1
Пирамида Минто или как структурировать свои тексты (Рубрика #Management)
Я читаю много документации, как на работе, так и в свободное время. И я расстраиваюсь от ситуаций, когда для понимания сути вопроса требуется преодолевать страницы текста, а не следовать за размышлениями автора. Особенно бывает грустно, когда вопрос важный, а время ограниченно. В этот момент хочется, чтобы документ был структурирован в формате: сначала главная идея, потом доказательства. Именно такой принцип популяризировала c 1970х годов Барбара Минто, консультант из McKinsey. Мне очень нравится этот подход, поэтому я решил сегодня про него рассказать.
Шаблон использования этого принципа выглядит так: введение (контекст и вопрос) → главное утверждение (ответ) → аргументы (подтверждающие детали). А дальше мы разберем каждую часть этого шаблона.
1️⃣Вводная часть по Минто должна задать сцену и проблему
Для этого можно использовать паттерн SCQA (Situation–Complication–Question–Answer): описать ситуацию и контекст, указать основную проблему или сложность, логично вытекающий из неё вопрос - и плавно привести читателя к вашему ответу, то есть к главному тезису. Например: "В компании Х задерживаются релизы (ситуация). Причина - хаос в требованиях (проблема), встаёт вопрос: как навести порядок? Решение: ввести чёткий процесс спефикации и управления задачами (ответ)." После такого вступления читатель уже понимает, о чём пойдёт речь, и готов воспринять ваш основной тезис.
2️⃣ Главная идея (тезис) - это вершина пирамиды
Именно эту мысль вы хотите донести. Минто советует формулировать её сразу после введения, чтобы читатель не гадал, куда вы клоните. В деловой переписке такой прямой подход экономит кучу времени: адресат сразу видит, в чём дело, и не расходует лишней умственной энергии на поиски смысла между строк. Суть в том, что у читателя ограничен запас ментальной энергии: часть тратится на чтение слов, ещё часть - на увязывание идей между собой, и только то, что останется, идёт на понимание сути. Поэтому чем яснее и логичнее подача, тем больше шансов, что смысл дойдёт до адресата. Пирамида Минто как раз освобождает мозг читателя от необходимости самому структурировать кашу из фактов - вы делаете это за него заранее.
3️⃣ Аргументы и детали - основание пирамиды
Здесь приводятся факты, данные, объяснения, поддерживающие главный тезис. Важно, что они не вываливаются списком, а группируются логично. Барбара Минто сформулировала три правила для структуры пирамиды
- Обобщение снизу вверх: идеи на каждом уровне должны обобщать материалы уровня ниже. Верхушка пирамиды - квинтэссенция идей снизу, каждый подпункт - резюме своих под-подпунктов и т.д. Благодаря этому читатель может прочесть только верхние уровни и уже получить связную картину.
- Однородность идей: в одной группе аргументы должны быть одного типа и порядка. Если вы перечисляете, скажем, три причины проблемы, все три должны быть именно причинами (а не две причины и одно следствие вперемешку). Однородности идей можно достигнуть используя примерно одинаковый уровень абстракции, а также принцип MECE (Mutually Exclusive, Collectively Exhaustive) для перечислений.
- Логичный порядок: идеи в каждой группе упорядочены по какому-то разумному признаку - например, по важности, хронологии или структуре. Нелогичная последовательность сбивает с толку. Минто вообще называла хаотичное изложение "плохими манерами" по отношению к читателю. Хороший автор проведёт читателя по своим аргументам шаг за шагом.
Следуя этим правилам, вы выстраиваете пирамиду снизу вверх при подготовке текста (сначала собираете и группируете идеи), а излагаете сверху вниз. Результат - стройная логическая конструкция, где читателю сначала дают карту маршрута, а потом уже ведут по пунктам. Если вдруг какой-то аргумент отпадает или оспаривается, общая мысль всё равно удержится на остальных опорах.
P.S.
Барбара написала целую книжку про этот принцип, которая вышла в далеком 1987 году. С тех пор книга много раз переиздавалась.
#Thinking #Writing #Leadership #Management
Я читаю много документации, как на работе, так и в свободное время. И я расстраиваюсь от ситуаций, когда для понимания сути вопроса требуется преодолевать страницы текста, а не следовать за размышлениями автора. Особенно бывает грустно, когда вопрос важный, а время ограниченно. В этот момент хочется, чтобы документ был структурирован в формате: сначала главная идея, потом доказательства. Именно такой принцип популяризировала c 1970х годов Барбара Минто, консультант из McKinsey. Мне очень нравится этот подход, поэтому я решил сегодня про него рассказать.
Шаблон использования этого принципа выглядит так: введение (контекст и вопрос) → главное утверждение (ответ) → аргументы (подтверждающие детали). А дальше мы разберем каждую часть этого шаблона.
1️⃣Вводная часть по Минто должна задать сцену и проблему
Для этого можно использовать паттерн SCQA (Situation–Complication–Question–Answer): описать ситуацию и контекст, указать основную проблему или сложность, логично вытекающий из неё вопрос - и плавно привести читателя к вашему ответу, то есть к главному тезису. Например: "В компании Х задерживаются релизы (ситуация). Причина - хаос в требованиях (проблема), встаёт вопрос: как навести порядок? Решение: ввести чёткий процесс спефикации и управления задачами (ответ)." После такого вступления читатель уже понимает, о чём пойдёт речь, и готов воспринять ваш основной тезис.
2️⃣ Главная идея (тезис) - это вершина пирамиды
Именно эту мысль вы хотите донести. Минто советует формулировать её сразу после введения, чтобы читатель не гадал, куда вы клоните. В деловой переписке такой прямой подход экономит кучу времени: адресат сразу видит, в чём дело, и не расходует лишней умственной энергии на поиски смысла между строк. Суть в том, что у читателя ограничен запас ментальной энергии: часть тратится на чтение слов, ещё часть - на увязывание идей между собой, и только то, что останется, идёт на понимание сути. Поэтому чем яснее и логичнее подача, тем больше шансов, что смысл дойдёт до адресата. Пирамида Минто как раз освобождает мозг читателя от необходимости самому структурировать кашу из фактов - вы делаете это за него заранее.
3️⃣ Аргументы и детали - основание пирамиды
Здесь приводятся факты, данные, объяснения, поддерживающие главный тезис. Важно, что они не вываливаются списком, а группируются логично. Барбара Минто сформулировала три правила для структуры пирамиды
- Обобщение снизу вверх: идеи на каждом уровне должны обобщать материалы уровня ниже. Верхушка пирамиды - квинтэссенция идей снизу, каждый подпункт - резюме своих под-подпунктов и т.д. Благодаря этому читатель может прочесть только верхние уровни и уже получить связную картину.
- Однородность идей: в одной группе аргументы должны быть одного типа и порядка. Если вы перечисляете, скажем, три причины проблемы, все три должны быть именно причинами (а не две причины и одно следствие вперемешку). Однородности идей можно достигнуть используя примерно одинаковый уровень абстракции, а также принцип MECE (Mutually Exclusive, Collectively Exhaustive) для перечислений.
- Логичный порядок: идеи в каждой группе упорядочены по какому-то разумному признаку - например, по важности, хронологии или структуре. Нелогичная последовательность сбивает с толку. Минто вообще называла хаотичное изложение "плохими манерами" по отношению к читателю. Хороший автор проведёт читателя по своим аргументам шаг за шагом.
Следуя этим правилам, вы выстраиваете пирамиду снизу вверх при подготовке текста (сначала собираете и группируете идеи), а излагаете сверху вниз. Результат - стройная логическая конструкция, где читателю сначала дают карту маршрута, а потом уже ведут по пунктам. Если вдруг какой-то аргумент отпадает или оспаривается, общая мысль всё равно удержится на остальных опорах.
P.S.
Барбара написала целую книжку про этот принцип, которая вышла в далеком 1987 году. С тех пор книга много раз переиздавалась.
#Thinking #Writing #Leadership #Management
1🔥26❤13👍12