Пирамида Минто или как структурировать свои тексты (Рубрика #Management)

Я читаю много документации, как на работе, так и в свободное время. И я расстраиваюсь от ситуаций, когда для понимания сути вопроса требуется преодолевать страницы текста, а не следовать за размышлениями автора. Особенно бывает грустно, когда вопрос важный, а время ограниченно. В этот момент хочется, чтобы документ был структурирован в формате: сначала главная идея, потом доказательства. Именно такой принцип популяризировала c 1970х годов Барбара Минто, консультант из McKinsey. Мне очень нравится этот подход, поэтому я решил сегодня про него рассказать.

Шаблон использования этого принципа выглядит так: введение (контекст и вопрос) → главное утверждение (ответ) → аргументы (подтверждающие детали). А дальше мы разберем каждую часть этого шаблона.

1️⃣Вводная часть по Минто должна задать сцену и проблему
Для этого можно использовать паттерн SCQA (Situation–Complication–Question–Answer): описать ситуацию и контекст, указать основную проблему или сложность, логично вытекающий из неё вопрос - и плавно привести читателя к вашему ответу, то есть к главному тезису. Например: "В компании Х задерживаются релизы (ситуация). Причина - хаос в требованиях (проблема), встаёт вопрос: как навести порядок? Решение: ввести чёткий процесс спефикации и управления задачами (ответ)." После такого вступления читатель уже понимает, о чём пойдёт речь, и готов воспринять ваш основной тезис.

2️⃣ Главная идея (тезис) - это вершина пирамиды
Именно эту мысль вы хотите донести. Минто советует формулировать её сразу после введения, чтобы читатель не гадал, куда вы клоните. В деловой переписке такой прямой подход экономит кучу времени: адресат сразу видит, в чём дело, и не расходует лишней умственной энергии на поиски смысла между строк. Суть в том, что у читателя ограничен запас ментальной энергии: часть тратится на чтение слов, ещё часть - на увязывание идей между собой, и только то, что останется, идёт на понимание сути. Поэтому чем яснее и логичнее подача, тем больше шансов, что смысл дойдёт до адресата. Пирамида Минто как раз освобождает мозг читателя от необходимости самому структурировать кашу из фактов - вы делаете это за него заранее.

3️⃣ Аргументы и детали - основание пирамиды
Здесь приводятся факты, данные, объяснения, поддерживающие главный тезис. Важно, что они не вываливаются списком, а группируются логично. Барбара Минто сформулировала три правила для структуры пирамиды
- Обобщение снизу вверх: идеи на каждом уровне должны обобщать материалы уровня ниже. Верхушка пирамиды - квинтэссенция идей снизу, каждый подпункт - резюме своих под-подпунктов и т.д. Благодаря этому читатель может прочесть только верхние уровни и уже получить связную картину.
- Однородность идей: в одной группе аргументы должны быть одного типа и порядка. Если вы перечисляете, скажем, три причины проблемы, все три должны быть именно причинами (а не две причины и одно следствие вперемешку). Однородности идей можно достигнуть используя примерно одинаковый уровень абстракции, а также принцип MECE (Mutually Exclusive, Collectively Exhaustive) для перечислений.
- Логичный порядок: идеи в каждой группе упорядочены по какому-то разумному признаку - например, по важности, хронологии или структуре. Нелогичная последовательность сбивает с толку. Минто вообще называла хаотичное изложение "плохими манерами" по отношению к читателю. Хороший автор проведёт читателя по своим аргументам шаг за шагом.

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

P.S.
Барбара написала целую книжку про этот принцип, которая вышла в далеком 1987 году. С тех пор книга много раз переиздавалась.

#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

Риторика Аристотеля (Рубрика #Speaking)

Я часто оказываюсь в ситуации, когда мне нужно донести мои мысли максимально эффективно до слушателей, будь то публичное выступление или совещание внутрии компании. Обычно я строю свой рассказ и тезисы на рациональном и логичном подходе, похожем на пирамиду Минто, но это не всегда срабатывало, поэтому я решил обратиться к методам классиков. Оказалось, что первым систематическим руководством в данной области был трактат Аристотеля "Риторика", в котором он рассказывал про три опоры успешного убеждения, отвечающим на разные вопросы
- Этос (кому я верю?) - тут важно доверие к спикеру: его репутация, компетентность
- Пафос (что я чувствую?) - тут важно эмоциональное состояние и мотивация аудитории: страх, энтузиазм, скука, усталось
- Логос (насколько это логично?) - тут важны факты, метрики, диаграммы, расчеты, причинно-следственные связи между аргументами

По Аристотелю для успеха нужна комбинация факторов, но ее очень сложно достичь. Например, у меня с детства хорошо получалось опираться на логос, потом во взрослом возрасте добавился этос (за счет репутации эксперта), а вот пафос мне до сих пор дается с трудом (но я работаю над прокачкой своего эмоционального интеллекта).

Интересно, что во времена Аристотеля книга помогала успешно выступать на судах, народных собраниях и так далее, где ему было важно убедить аудиторию здесь и сейчас без каких-то подручных материалов: презентаций, раздаток, видеотрейлеров. А сейчас в технологических компаниях у нас есть целый набор разнообразных задач в разных контекстах и модель как будто становится богаче. Например, есть встречи, письма, часты, RFC/ADR, code-review, design review, business review, ... В итоге, кроме цели убеждения появляются цели синхронизировать людей, сняять тревогу, построить доверие, протащить изменения ...

Сейчас эту модель с этосом, пафосом и логосом можно разложить примерно так

1️⃣Этос сегодня - это про то, а как понять: "Поверят ли этой оценке/предложению именно от меня?"
Этос развивается через следущие факторы
- Качество ваших решений и прогнозов (обещали — сделали)
- Честное признание рисков и неизвестных
- Прозрачность: "вот, что я проверил, вот, чего не знаю"
- Уважительный тон, даже когда спорите

2️⃣ Пафос сегодня - это про то, а как понять: "Что люди чувствуют, когда это слышат/читают?"
На практике это можно проявлять так
- Не объявлять изменения “сухим” языком, игнорируя тревогу (“ещё один приоритет сверху”)
- Показывать, как это влияет на нагрузку, карьеру, интерес к работе
- Помогать людям перейти от “ой, кошмар” к “ок, это имеет смысл, давайте попробуем”

3️⃣ Логос сегодня - это про то, а как понять: “Понятна ли логика и достаточно ли она надёжна для решений?”
На практике это можно проявлять так
- Открыто говорить про допущения и границы модели: “эта оценка без учёта интеграции с X”,
- Использовать визуализации логики: диаграммы, таблицы, модели
- Показывать сравнение альтернатив с использованием понятных критериев

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

Логос: сначала "основа"
- В чём основное утверждение? (1–2 фразы)
- Какие данные и факты это поддерживают?
- Какие есть альтернативы и почему они хуже?
- Какие допущения вы делаете?
Если вы не можете это чётко сформулировать — проблема в логосе, а не в “плохой аудитории”.

Этос: почему должны поверить вам
- Что вы уже проверили/сделали сами?
- Чей опыт/экспертизу вы учли (SRE, безопасность, продукт, финансы)?
- Как показать, что вы не проталкиваете “своё любимое решение”, а действительно ищете лучшее?
Иногда достаточно добавить буквально пару фраз.

Пафос: эмоциональная цель
- Какое состояние аудитории вам нужно?
- Есть ли сейчас страх, усталость, скепсис? Чем их можно “снизить”?
- Как показать людям, что вы на их стороне?
Например, вместо “надо перерабатывать”: “Наша цель — избавиться от ночных пожарных релизов. Предлагаемый план как раз уменьшит количество авралов”.

#Thinking #Writing #Leadership #Management

C-Connect от Yandex

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

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

В общем, домой я попал только в 2 утра уставший, но довольный. Спасибо орнанизаторам и участникам, что сделали вчерашний день настолько крутым.

P.S.
Забыл сначала приложить ссылку на само мероприятие (там есть кнопка для подачи заявки на присоединение)

#AI #Software #Management #Leadership

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

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