Пирамида Минто или как структурировать свои тексты (Рубрика #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

[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