Инженерная стратегия

15 марта 2024

Инженерная стратегия помогает связать текущие проблемы с решениями: что менять, почему и в каком порядке. Для ее обсуждения удобно выделить диагноз, руководящие принципы и согласованные действия. Эту рамку описал Richard Rumelt в «Good Strategy / Bad Strategy» (2011); Will Larson применяет ее к инженерной организации. В статье разобраны примеры, ошибки внедрения и способы проверить, помогает ли стратегия принимать решения.

Почему стратегии проваливаются: реорганизационный театр и зазор между декларацией и жизнью

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

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

Второй частый сценарий - стратегия как дорожная карта. Документ называется «Engineering Strategy 2026», но внутри - список проектов с датами и владельцами. Здесь нет диагноза: не объясняется, почему именно эти проекты, какая теория ситуации стоит за выбором, какие альтернативы были отвергнуты и по какому критерию. Команда читает такой документ как to-do list, спорит про конкретные сроки и не видит главного - что стратегия должна объяснять выбор, а не просто его фиксировать. Например, стратегия должна помогать решить, какой проект сократить первым, если бюджет уменьшится на 30%.

Третий сценарий - стратегия по метрикам. Команда выбирает несколько KPI (DORA-метрики, NPS, time-to-onboard) и объявляет их стратегией. Это работает в очень узком случае - когда метрики действительно отражают узкое место и есть теория, какие действия их сдвинут. В большинстве же случаев метрики становятся целью сами по себе: deployment frequency растет за счет того, что команды дробят задачи на тривиальные PR, lead time падает, потому что меряется только то время, которое легко измерить. Charity Majors в блоге Honeycomb много раз повторяет: метрика без causal model - это карго-культ. Хороший пример обратного - ее собственная аргументация observability как стратегии: метрика «time to understand a novel production issue» становится осмысленной только в связке с теорией о том, что современные системы сложнее, чем их monitoring предполагает.

Копирование чужой модели без учета условий компании не объясняет, какую проблему мы решаем. В эссе «Spotify’s Failed #SquadGoals» Jeremiah Lee описывает ограничения модели в Spotify. Это рассказ участника, а не доказательство, что такая структура всегда не работает. Для выбора нужны собственный диагноз и проверяемые ожидания от изменений.

Исторический контекст: от командно-контрольной модели к outcome-based

Подходы к управлению по-разному распределяют право ставить цели и выбирать способы их достижения. Короткий обзор ниже помогает сравнить эти подходы с рамкой «диагноз, принципы, действия».

В 1911 году Frederick Taylor опубликовал «The Principles of Scientific Management» - первая систематическая попытка превратить управление в инженерную дисциплину. Тэйлоризм опирался на два допущения: работу можно разложить на стандартные операции и менеджер знает оптимальный способ их выполнения. Стратегия в этой модели - это план, спущенный сверху, и все управление сводится к контролю исполнения. Эта модель отлично работала на конвейере Ford в 1920-х и плохо работала в любой работе, где оптимальный способ заранее не известен.

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

В 1975 году Frederick Brooks в «The Mythical Man-Month» (по итогам проекта IBM OS/360) ввел несколько идей, которые стали инфраструктурой всей последующей дискуссии о стратегии: добавление людей в опаздывающий проект задерживает его еще больше (Brooks's law); коммуникационные издержки растут квадратично от размера команды; концептуальная целостность важнее, чем сумма локальных оптимизаций. Стратегия в постBrooksовом мире уже не может быть просто планом ресурсов - она обязана учитывать, что организационные решения имеют нелинейные последствия.

В 1980-х и 1990-х доминирующей моделью стало MBO (Management by Objectives) Peter Drucker и его развитие в виде Balanced Scorecard (Kaplan, Norton, 1992). Цели каскадировались сверху вниз, каждая команда получала измеримые KPI, выполнение KPI становилось основой бонусов. Эта модель работала в стабильной среде (фарма, банки, ритейл) и плохо работала в среде с быстро меняющимися ограничениями. К 2000-м она начала ломаться в технологических компаниях по той же причине, по которой ломался Taylor: оптимальный способ достижения цели заранее не известен, а каскадированные KPI режут эксперимент и адаптацию.

Параллельно в 1999 году John Doerr принес OKR из Intel в Google. OKR - это не KPI: Objective формулируется как направление, Key Results - как наблюдаемые признаки прогресса, и от команды ожидается, что она сама выбирает, как двигаться к цели. Это сдвиг от командно-контрольной модели к outcome-based: руководство определяет, что должно быть достигнуто, команда определяет, как именно. Стратегия в этой модели становится не планом, а контрактом: «вот узкое место, вот руководящие принципы, вот зона свободы».

В 2001 году Agile Manifesto закрепил тот же сдвиг как культурный: working software over comprehensive documentation, responding to change over following a plan. На уровне организации это породило волну книг и практик 2010-х: Patty McCord «Powerful» (2018, по мотивам Netflix culture deck 2009 года), Camille Fournier «The Manager's Path» (2017), Lara Hogan «Resilient Management» (2019), Will Larson «An Elegant Puzzle» (2019) и «Staff Engineer» (2021). Все они исходят из общей предпосылки: в высокоменяющейся среде стратегия не может быть планом действий, она должна быть рамкой принятия решений в условиях неопределенности.

Этот подход описал Richard Rumelt в «Good Strategy / Bad Strategy» (2011). Эта книга вышла за пределы IT, но именно она стала структурным источником для всей последующей инженерной литературы о стратегии. Rumelt сформулировал «kernel of strategy» как тройку: diagnosis (теория ситуации), guiding policy (общий подход к решению), coherent actions (взаимоусиливающие действия). Эта тройка - не изобретение Will Larson, она пришла из военного и корпоративного стратегического мышления; вклад Larson и других инженерных авторов в том, что они показали, как эту рамку применить внутри инженерной организации.

Параллельно с этими управленческими моделями развивалась культурная инфраструктура, без которой современная инженерная стратегия не работает. В 2012 году Etsy под руководством John Allspaw и Mike Rembetsy ввели практику blameless post-mortem (см. эссе Allspaw «Blameless PostMortems and a Just Culture», codeascraft 2012). Идея простая: если человек ошибается, спрашивайте, какие свойства системы позволили ошибке привести к инциденту, а не «кто виноват». Это стало основой современной SRE-культуры и одной из предпосылок того, что стратегия может быть честной: без blameless нет диагноза, есть только защитные нарративы.

Если коротко суммировать, что менялось: от плана, который менеджер раздает исполнителям (Taylor) - к KPI, которые каскадируются вниз (Drucker, Kaplan-Norton) - к outcome-based рамкам, где команда автономна в выборе пути (OKR, Agile) - к диагноз-принципы-действия (Rumelt, Larson) как способу сделать эту автономию управляемой, а не превратить ее в фрагментацию. Современная инженерная стратегия живет в этой последней точке.

Учебный пример: от функциональных команд к продуктовым

Предположим, каждая новая функция требует участия backend, frontend и QA-команд. Если работа задерживается на передаче между ними, нужно выяснить причины: распределение ответственности, очереди, доступность экспертизы или технические зависимости.

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

Это учебный пример, а не реконструкция результатов Stripe или Shopify. Его задача - показать связь между диагнозом, принципами и действиями.

Трехчастная рамка через историю трансформации

Теперь, когда виден контекст, имеет смысл вернуться к трехчастной рамке как к инструменту. Источник - «Good Strategy / Bad Strategy» Richard Rumelt (2011), инженерная адаптация - Will Larson «Engineering strategies» (lethain.com/eng-strategies) и сборник «Engineering Strategy» (lethain.com, 2024). Диагноз объясняет выбор принципов, а действия показывают, как применить их на практике.

Часть	Описание	Вариант решения в учебном примере	Что в стилизованном B2B SaaS
Диагноз	Теория ситуации: что является узким местом и почему текущая структура его не решает	Функциональная структура стала bottleneck для продуктовой диверсификации	180 точек cross-team координации режут lead time
Руководящие принципы	Общий подход к решению с явными компромиссами и зонами свободы	End-to-end продуктовые команды + platform teams + общий стек	Четыре stream-aligned команды + Platform team + растворение QA
Согласованные действия	Конкретные взаимоусиливающие шаги, которые делают принципы материальными	Постепенный переход + Sorbet + tech bets + новый ритм решений	30 переходов + platform contract + новые роли + quarterly tech review

Диагноз - самая трудная часть. Он требует честно назвать, что не работает, и предложить теорию о том, почему именно это - а не следствия и симптомы. Опросы культуры, retro команд, данные из 1:1, дорожная карта, финансовый план, конкурентное давление - все это материал для диагноза, но не сам диагноз. Диагноз становится диагнозом только когда вы можете сформулировать причинно-следственную связь: «вот это - узкое место, вот по таким причинам, вот по таким признакам мы его опознаем». Без диагноза стратегия превращается либо в красивые принципы (fluff), либо в произвольный список действий.

Руководящие принципы - это не список ценностей, а описание подхода к решению с явными компромиссами. Хороший принцип режет варианты: он говорит не только что делать, но и от чего отказаться. «Поддерживаем соотношение 4 продуктовых инженера на 1 платформенного» - это принцип, потому что он отказывается от модели «платформа берет сколько надо» и от модели «нет выделенной платформы». «Стандартный стек или эскалация на Tech Review» - это принцип, потому что он отказывается и от «каждая команда выбирает что хочет», и от «вот единственно правильный стек, никаких исключений». Для каждого принципа нужно объяснить, как он применяется и кто следит за его соблюдением. Полезный принцип помогает принимать повторяющиеся решения.

Согласованные действия - это материализация принципов. Здесь критично слово «согласованные»: действия должны усиливать друг друга, а не растягивать команду в разные стороны. Если принцип «инвестируем в платформу», а действия - «нанимаем 20 продуктовых инженеров и 0 платформенных», действия не согласованы с принципом. Согласованность - главная проверка, легче всего ломающаяся в процессе бюджетирования и планирования.

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

Запрос на стратегию: когда она имеет смысл

Не каждое затруднение требует стратегии. Larson предлагает три проверочных вопроса, на которые нужно ответить «да», прежде чем браться за документ.

• Уверены ли вы в диагнозе? Или вы доверяете команде в этом вопросе? Если ни то, ни другое, имеет смысл сначала собрать данные, а не писать стратегию.
• Готовы ли вы обеспечить выполнение? Стратегия без enforcement рискует остаться на бумаге и подорвать доверие к будущим стратегиям.
• Создаст ли стратегия leverage? Стоит ли effort того результата? Если конкретное затруднение можно решить точечным решением, стратегия - излишне тяжелый инструмент.

Что делать, если у компании нет бизнес-стратегии

Сфокусируйтесь на неинженерных стратегиях, важных для инженерного отдела, и задокументируйте их самостоятельно, согласовав со стейкхолдерами. Не делитесь этим черновиком широко - чтобы не подменять собой бизнес-руководство и не подрывать его авторитет. Это рабочий документ для вас, а не публичная декларация. Полезные вопросы для проработки:

• Каковы целевые показатели денежного потока?
• Какова инвестиционная политика (R&D vs Sales vs G&A)?
• Кто пользователи? Как расставлены приоритеты между ними?
• Какие главные конкурентные угрозы?
• Что в текущей стратегии не работает?

Процесс написания и условия, при которых стратегия имеет смысл

Написание инженерной стратегии похоже на работу историка: посмотрите на то, как уже работает компания, запишите это и поделитесь записями. Larson описывает процесс из восьми шагов; ниже - его адаптация с пояснениями, что именно делается на каждом.

1. Напишите это сами. Не делегируйте. Процесс написания - это процесс понимания. Если вы не можете написать стратегию, скорее всего, вы ее еще и не сформулировали.
2. Определите стейкхолдеров. С кем нужно согласовать стратегию для того, чтобы она была устойчивой? Из них выберите 3-5 человек для ранней обратной связи, прежде чем расширять круг.
3. Напишите диагноз. Используйте текущую дорожную карту, конкурентное давление, финансовый план, опросы о культуре и продуктивности, проблемы из 1:1 и командных встреч. Цель - не описать все, а выделить узкое место и причинно-следственную связь.
4. Напишите руководящие принципы. Ответьте на ключевые вопросы (см. блок ниже).
5. Поделитесь с полным списком стейкхолдеров. Получите feedback. Здесь критично различать возражения по существу (уточнения диагноза, новые ограничения) и возражения по форме (терминология, тон).
6. Напишите согласованные действия. Конкретные шаги для реализации, явно привязанные к принципам.
7. Проведите 1:1 с потенциальными критиками. Найдите людей, которые скорее всего будут недовольны, и обсудите с ними заранее. Возражение, услышанное в 1:1, можно интегрировать; возражение, прозвучавшее на all-hands после публикации, обычно превращается в политический конфликт.
8. Опубликуйте и запланируйте Q&A. Дайте время на feedback и установите дату для оценки результатов (через 2 месяца - первая, через 6 - полная).

Структурирование руководящих принципов: три ключевых вопроса

Larson предлагает свести руководящие принципы к трем вопросам, на которые любая инженерная стратегия должна ответить явно.

1. Каковы приоритеты распределения ресурсов?

2. Какие правила обязательны для всех команд?

3. Как принимаются решения?

Согласованные действия: enforcement, эскалация, переходы

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

Обеспечение соблюдения

Эскалации

Переходы

Полный пример стратегии

Ниже - синтезированный пример инженерной стратегии для компании среднего размера. Он построен по трехчастной рамке и иллюстрирует, как принципы и действия связаны между собой. Это стилизованный пример на основе типичных паттернов; конкретные цифры выбраны так, чтобы показать связи, а не отражать конкретную компанию.

Диагноз

• В примере участвуют 300 инженеров, 40 менеджеров и 10 TPM.
• Три направления: потребительский (80% дохода), B2B (20%), новые эксперименты (0%).
• Ожидаем рост в B2B, потребительский ниже 15% в год.
• Планируем оставаться на нулевом денежном потоке (без роста команды).
• Главная проблема: стабильность тестов снизилась на 40%, каждая 3-я сборка падает.
• Опросы показывают нехватку информации о релизах других команд.

Руководящие принципы

Принцип	Обоснование
Соотношение 4:1 продуктовых к платформенным	Работает уже несколько лет. В следующей итерации добавим соотношения для security и data.
45% на B2B, 35% потребители, 10% эксперименты, 10% DevEx	Перераспределяем 20% в сторону B2B из-за роста. 10% на DevEx - для стабильности тестов.
Нулевой денежный поток	Избегаем найма. При конфликте с vendor-решениями - эскалация на CTO.
Стандартный стек или эскалация на Tech Review	Максимизируем инвестиции в DevEx, упрощаем переходы между командами, compliance.
Быстрая эскалация при неясности	Эскалации - это нормально. Медленные эскалации - наша проблема, не процесса.
Анонсы в #tech-updates и #shipped	Уменьшаем неожиданности от технических решений других команд.

Согласованные действия

• Реорганизация команд: перераспределяем около 10% продуктовых инженеров из потребительского в B2B. Несколько команд переходят между подразделениями, новые roles обсуждаются в 1:1 заранее.
• Рабочая группа по стабильности тестов: 10% времени продуктовых инженеров плюс приоритет №3 для платформенных (после security и site stability).
• Tech Spec Review - легкие асинхронные проверки. Запросы начинаются в чате, простые решаются асинхронно, сложные выносятся на еженедельную встречу.

Типичные ошибки при внедрении и как из них выходят

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

Ошибка 1. Объявили стратегию на all-hands и считают, что она внедрена. Через месяц команды живут как раньше, потому что нет регулярного обсуждения документа. Признак: на retro никто не цитирует стратегию; конфликты приоритетов разрешаются «по ситуации». Возврат: ввести квартальный strategy review (1-2 часа), на котором каждое крупное решение сопоставляется с принципами стратегии явно. Если решение противоречит принципу, это либо повод пересмотреть принцип, либо повод изменить решение.

Ошибка 2. Стратегия, на которую сложно сослаться. Документ существует в красивых слайдах, но нигде не зафиксирован в форме, на которую можно сослаться в PR-описании или в Tech Spec Review. Признак: нельзя дать ссылку на пункт принципа. Возврат: переписать стратегию в текстовый документ со ссылками на каждый принцип, и в Tech Spec Review-шаблон добавить поле «какой принцип стратегии затрагивает / нарушает / поддерживает».

Ошибка 3. Стратегия без эскалационного пути. Инженеры, работающие над задачами, видят, что принцип не работает в их кейсе, но не знают, как это поднять. В лучшем случае молча обходят, в худшем - копят раздражение. Признак: возражения слышны в курилке, но не в офисе. Возврат: явно описать процесс эскалации, опубликовать список людей, к которым можно эскалировать, и периодически проводить office hours принципала / staff engineer для именно таких разговоров.

Ошибка 4. Стратегия по метрикам без causal model. Команда выбрала несколько KPI и гонится за цифрами. Через два квартала метрики выросли, но опыт повседневной работы ухудшился. Признак: показатели улучшаются, а на ретроспективах команды продолжают обсуждать проблемы в работе. Возврат: к каждому KPI явно приписать теорию изменений (что должно произойти, чтобы KPI вырос правильным способом), и регулярно проверять, что движение KPI совпадает с этой теорией. Charity Majors про observability формулирует это как «metrics are not enough; you need to understand the causal chain».

Ошибка 5. Скопировали Spotify (или Amazon, или Netflix). Команда взяла готовую модель, не разобравшись, какой контекст ее делал работоспособной в исходной компании. Признак: люди не могут объяснить, почему именно эта модель, кроме «у успешных так». Возврат: либо явно сформулировать диагноз, для которого эта модель - решение, либо честно признать, что выбор был культурным, а не стратегическим, и пересмотреть.

Ошибка 6. Стратегия без компромиссы. Документ говорит «инвестируем в скорость, качество, инновации, эффективность и developer experience». По такому перечню трудно понять, как распределять ограниченные ресурсы. Признак: ни одна команда после прочтения стратегии не может сказать, какой из ее текущих проектов получает больше ресурсов и какой - меньше. Возврат: явно назвать, чему мы говорим «нет» в этом году. Стоит явно указать, какие задачи отложены ради выбранных приоритетов.

Ошибка 7. Стратегия не пересматривается. Документ написан год назад, контекст изменился (рынок, состав команды, продуктовые приоритеты), но стратегия по-прежнему висит в неизменном виде. Команды постепенно перестают на нее ссылаться. Признак: люди говорят «эта стратегия уже не отражает реальность». Возврат: поставить календарную точку (минимум раз в год, лучше раз в полгода) для пересмотра. Пересмотр стратегии позволяет учесть изменения в условиях работы.

Ошибка 8. Стратегия без отказа от старых обязательств. Новая стратегия добавилась поверх старой, старая не отменена. Команды получают противоречивые приоритеты или больше обязательств, чем могут выполнить. Возврат: при публикации новой стратегии явно назвать, какие предыдущие декларации она заменяет, и убрать их из мест, на которые ссылаются команды (handbook, OKR-шаблоны, страницы о ценностях).

Резюме

• Стратегия = диагноз + руководящие принципы + согласованные действия. Источник рамки - Richard Rumelt, инженерная адаптация - Will Larson.
• У вашей компании уже есть стратегия. Вопрос в том, записана ли она и совпадает ли с тем, что вы о ней думаете.
• Реорганизация без изменения правил, стимулов и информационных потоков - косметика. Это самый частый антипаттерн.
• Исторический сдвиг - от Taylor (план сверху) через Drucker и Kaplan-Norton (KPI) к OKR и Rumelt (outcome-based, диагноз-принципы-действия).
• Закон Конвея делает выбор оргструктуры выбором архитектуры продукта; игнорировать его в стратегии нельзя.
• Пишите сами - это процесс понимания. Делегированная стратегия редко становится понятой.
• Для выполнения стратегии нужно описать, как поддерживать принципы, обсуждать исключения и переходить к новой работе.
• Проводите 1:1 с потенциальными критиками заранее, до публикации.
• Эскалации - нормальный сигнал, что принцип ломается в конкретном кейсе. Их надо хотеть слышать.
• Пересматривайте стратегию минимум раз в год. Пересмотр позволяет учесть новые условия.
• Проверьте, понятно ли из черновика, от каких задач придется отказаться ради выбранных приоритетов.

Источники и смежные статьи

Книги и эссе

• Engineering strategies - Will Larson (lethain.com, 2018), пост, на который опирается практическая часть статьи.
• «An Elegant Puzzle» (2019) и «Staff Engineer» (2021) - Will Larson, более широкий контекст инженерного менеджмента и роли staff+.
• «Good Strategy / Bad Strategy» - Richard Rumelt (Crown Business, 2011). Структурный источник трёхчастной рамки diagnosis - guiding policy - coherent actions.
• «The Mythical Man-Month» - Frederick Brooks (Addison-Wesley, 1975, 20-е юбилейное издание 1995). Brooks's law, концептуальная целостность, нелинейность коммуникационных издержек.
• «The Manager's Path» - Camille Fournier (O'Reilly, 2017). Карьерная и организационная карта от tech lead до CTO.
• «Resilient Management» - Lara Hogan (A Book Apart, 2019). Практики устойчивого менеджмента и работа с командой в условиях изменений.
• «Powerful» - Patty McCord (Silicon Guild, 2018). Расширение исходного Netflix culture deck (2009).
• «The Five Dysfunctions of a Team» - Patrick Lencioni (Jossey-Bass, 2002). Полезен для диагноза проблем доверия и конфликта при внедрении стратегии.
• «Shape Up» - Ryan Singer (Basecamp, 2018). Альтернативная рамка планирования продуктовой работы; пример того, как контекст компании определяет, какая модель применима.

Статьи и публикации компаний

• Stripe Blog и Sorbet: A type checker for Ruby - Stripe Engineering (2019). Публичные следы стратегических решений Stripe о платформе и стеке.
• Shopify Engineering и серия постов с тегом «Black Friday» - история эволюции масштабируемости и архитектуры под пиковые нагрузки.
• Honeycomb Blog - Charity Majors и команда: тексты о том, как observability становится частью инженерной стратегии, а не отдельной функцией.
• Blameless PostMortems and a Just Culture - John Allspaw (Code as Craft, 2012). Подход к разбору инцидентов, который помогает обсуждать условия работы и причины ошибок.
• «Scaling Agile @ Spotify» - Henrik Kniberg (2012). Исходное описание Squad / Tribe / Chapter / Guild модели; стилизованный пример антипаттерна копипаста.
• Steven Yegge «Stevey's Google Platforms Rant» (2011) - публично известный текст о том, как promotion criteria и платформенная стратегия связаны в Google.
• Jeff Bezos memo о two-pizza teams и API-mandate (2002, public references) - стилизованный пример того, как стратегические принципы спускаются в обязательные для всех правила.

Смежные статьи на этом сайте

• Системный менеджмент - подробный разбор оргструктур, потоков ценности и закона Конвея.
• DORA и SPACE метрики - метрики, которые осмысленно использовать как часть инженерной стратегии (и как не превратить их в KPI-карго-культ).
• Принципы лидерства - связь между стратегией и личной практикой staff+ инженера или менеджера.
• Jeremiah Lee: Spotify’s Failed #SquadGoals