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

Как написать стратегию, которая работает

15 марта 2024

Большинство письменных инженерных стратегий не работают, потому что описывают идеальное будущее, а не путь от текущих проблем к желаемому состоянию. Настоящая стратегия - это не видение и не дорожная карта, а связка из трёх частей: честный диагноз ситуации, явные руководящие принципы с компромиссами и конкретные согласованные действия. Эту структуру в 2011 году описал Richard Rumelt в книге «Good Strategy / Bad Strategy», и почти всё, что Will Larson и другие инженерные авторы пишут про стратегию, - адаптация этой рамки к контексту инженерной организации. Статья разбирает, почему стратегии чаще всего проваливаются, как менялись управленческие модели за последние полвека, как выглядит реальный сдвиг от функциональной к продуктовой структуре, как в этой логике читается трёхчастная рамка и на каких типичных моментах команды спотыкаются при внедрении.

Почему стратегии проваливаются: реорганизационный театр и зазор между декларацией и жизнью Исторический контекст: от командно-контрольной модели к outcome-based Кейс-стади: переход от функциональной к продуктовой структуре Трёхчастная рамка через историю трансформации Процесс написания и условия, при которых стратегия имеет смысл Полный пример стратегии Типичные ошибки при внедрении и как из них выходят Резюме Источники и смежные статьи

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

Если вас раздражает отсутствие инженерной стратегии в компании - она у компании уже есть. Стратегия - это то, как организация на самом деле справляется с текущими проблемами: какие команды получают людей, какие проекты режутся первыми, как разрешаются конфликты приоритетов между security и delivery. Вопрос не «есть ли стратегия», а «совпадает ли она с тем, что вы думаете о ней, и записана ли она так, чтобы её можно было обсуждать». Will Larson в эссе «Engineering strategies» (2018) формулирует это резко: декларированная стратегия - это часто PowerPoint, лежащая стратегия - это бюджет и календарь рилизов. Зазор между ними и есть основной источник фрустрации старших инженеров и менеджеров.

Самый распространённый сценарий провала - реорганизационный театр. Симптом виден: delivery замедляется, инциденты учащаются, технический долг растёт. Руководство объявляет реорганизацию: новые названия команд, перетасовка людей, новый оргчарт в Confluence. Через два-три квартала симптом возвращается, потому что правила, метрики и стимулы остались прежними. Команда A по-прежнему меряется по количеству зарелиженных фич, команда B по-прежнему держит SLA по uptime, конфликт между ними по-прежнему уходит на VP. Изменился только список имён в репортинге. Этот паттерн настолько распространён, что в книге «Good Strategy / Bad Strategy» Richard Rumelt отдельно описывает «bad strategy» как сочетание fluff (красивых лозунгов), failure to face the problem (отказ называть реальные ограничения) и mistaking goals for strategy (постановка целей вместо описания пути).

Второй частый сценарий - стратегия как дорожная карта. Документ называется «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 предполагает.

Четвёртый сценарий - копипаст чужой модели. В 2012 году Henrik Kniberg опубликовал статью «Scaling Agile @ Spotify», где описал модель Squad / Tribe / Chapter / Guild. Документ был настолько визуально привлекательным, что десятки компаний приняли его как готовый шаблон без понимания контекста. Спустя несколько лет Spotify сами публично отказались от этой модели как от описания текущего положения дел; сооснователь Jeremiah Lee и другие инженеры, прошедшие через это, открыто писали, что внутри Spotify «Spotify model» работала меньше времени, чем компании, которые её копировали. Это не значит, что модель плохая, - это значит, что копировать структуру без копирования контекста (продуктовый рынок, культура автономии, размер компании, устройство платформы) бесполезно. То же самое часто происходит с «Amazon two-pizza teams», «Netflix culture deck», «Basecamp Shape Up» - в исходной компании это работало как часть согласованной системы, в чужой компании это становится фрагментом без opora.

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

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

Идея «инженерной стратегии» в её современном виде появилась поздно. Чтобы понять, почему именно трёхчастная рамка (диагноз - принципы - действия) стала дефолтом для технологических компаний, полезно посмотреть, какие модели управления ей предшествовали и почему они перестали работать.

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

В 1968 году Melvin Conway сформулировал то, что сегодня известно как закон Конвея: «организации проектируют системы, которые копируют структуру коммуникации этой организации». Применительно к стратегии это означает, что выбор оргструктуры - это уже выбор архитектуры продукта. Если у вас функциональные подразделения (отдельный backend, отдельный frontend, отдельный QA), вы получите систему, в которой границы модулей совпадают с границами команд, а каждое сквозное изменение требует трёх согласований. Стратегия, которая игнорирует Конвея, обречена: вы можете сколько угодно объявлять «product-centric culture», но если структура подчинения функциональная, продукт всё равно будет фрагментирован.

В 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) как способу сделать эту автономию управляемой, а не превратить её в фрагментацию. Современная инженерная стратегия живёт в этой последней точке.

Кейс-стади: переход от функциональной к продуктовой структуре

Самый поучительный пример эволюции инженерной стратегии в open-source литературе - история Stripe, которую публично разворачивали Patrick Collison, Brandur Leach и инженерное руководство компании в постах stripe.com/blog и в подкастах. Полную внутреннюю стратегию никто наружу не выкладывал, но связка из «How we built it: Stripe Capital» (Brandur Leach, 2019), «Sorbet: A type checker for Ruby» (Stripe Engineering Blog, 2019), материалов о tech bets и Patrick Collison «Reading list» позволяет восстановить логику переходов. Ниже - реконструкция, основанная на этих публично доступных источниках; точные цифры - там, где они называются в официальных постах, остальное помечено как качественное.

Ранний Stripe (2011-2014) был организован функционально: API, Dashboard, Infra. Это была классическая структура для startup до 50 инженеров: глубина экспертизы важнее, чем end-to-end ownership, а потоки ценности достаточно простые, чтобы handoff между функциями не превращался в очередь. Платежи as a service - один основной поток, его поддерживает функциональная вертикаль.

К 2016-2017, по мере роста до нескольких сотен инженеров и расширения продуктовой линейки (Connect, Atlas, Sigma, Radar, Issuing, Terminal), функциональная структура начала ломаться. Признаки были типичными для такой стадии: каждый новый продукт требовал координации между API, Dashboard и Infra, координация уходила на week-level lag, embedded фичи у крупных клиентов начинали стопориться на согласованиях между командами. Команда, которая отвечает за Connect (платежи для платформ-маркетплейсов), не могла самостоятельно выкатить нужный API, потому что приоритеты API определялись общей API-командой.

Stripe начали постепенно переходить на продуктовую структуру с stream-aligned командами, где каждый продукт получал свою связку backend + frontend + data + иногда отдельных infra-инженеров, ответственных за этот продукт. Платформенные функции (developer infrastructure, data platform, security, observability) выделились в отдельные platform teams, чьим клиентом стала не внешняя аудитория, а продуктовые команды Stripe. Brandur Leach в постах подробно описывает, как это решение мотивировалось не модной концепцией, а конкретными узкими местами: latency решений, координационные издержки, отсутствие end-to-end ответственности за продуктовые метрики.

Что в этом сдвиге было «стратегией» в трёхчастном смысле:

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

Похожий по структуре, но с другим контекстом сдвиг сделал Shopify к Black Friday Cyber Monday 2018-2020 годов. По публикациям shopify.engineering, к Black Friday 2020 платформа обработала пиковую нагрузку 10 978 заказов в минуту и около $5.1 млрд GMV за weekend; в 2022 году пик уже превысил 75 млн запросов в минуту. Это было результатом многолетней стратегии «pods + shop-aware load balancing + Kafka-based order pipeline + аккуратная работа с MySQL шардами», описанной в постах Shopify Engineering (см. подборку «Tags: Black Friday» на shopify.engineering). Стратегия и здесь не была объявлена как реорг: она формулировалась как последовательность tech bets, каждая из которых решала конкретное узкое место предыдущего пика.

Чтобы у читателя не осталось ощущения, что эти истории - частные особенности конкретных компаний, стоит дать и стилизованный пример, который ближе к среднему B2B SaaS.

Стилизованный пример на основе типичных паттернов, который я наблюдал в нескольких B2B SaaS на 80-200 инженеров. Цифры приближены к реальности, конкретная компания не подразумевается.

B2B SaaS, 120 инженеров, четыре года продукту, ARR около $25M, два основных сегмента клиентов (SMB и mid-market). Структура - функциональная: backend (45), frontend (30), mobile (15), QA (15), DevOps (10), data (5). Lead time от идеи фичи до production вырос с 3 недель до 9 за полтора года. Каждая средняя по сложности фича требует координации трёх-четырёх команд, координация уходит на 2-3 спринта. CSAT по mid-market сегменту падает, потому что enterprise-фичи стопорятся на «договорённости backend и frontend о контракте».

Диагноз, который команда зафиксировала после двух месяцев интервью: узкое место - не отсутствие людей, а количество cross-team handoffs на каждый поток ценности. Продуктовая дорожная карта на год вперёд содержит около 60 значимых initiative, каждая требует 3+ команд, итого ~180 точек координации.

Руководящие принципы, которые из этого вывели: переходим на четыре stream-aligned команды (SMB Acquisition, SMB Retention, Mid-Market Core, Mid-Market Enterprise) с end-to-end ownership; выделяем Platform team из бывших backend/devops; QA-функция растворяется в продуктовых командах с одной центральной QA-architect ролью для guild; mobile остаётся отдельной командой, поскольку shared между всеми сегментами.

Согласованные действия за 6 месяцев: 30 инженеров переведены в новые stream-aligned команды; написан platform contract документ, фиксирующий, что Platform team поставляет (CI/CD, observability, secrets, deploy automation) и какой SLA даёт; прежние функциональные tech leads становятся либо tech leads продуктовых команд, либо principal engineers с горизонтальными ролями; quarterly tech review, где стратегические сдвиги обсуждаются явно.

Через два квартала после полного перехода: lead time на «среднюю» фичу сократился с 9 до 4 недель; среднее количество команд, вовлечённых в фичу, упало с 3-4 до 1-2; CSAT по mid-market вернулся к уровню двухлетней давности; около 8% инженеров ушло в первые полгода (типичная цифра для такого масштаба переходов). Это не «успех реорганизации» в смысле «всё стало лучше» - это иллюстрация того, что стратегия с явным диагнозом и понятной теорией изменений даёт измеримый сдвиг, тогда как косметическая реорганизация без диагноза - не даёт.

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

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

Часть Описание Что в кейс-стади Stripe Что в стилизованном 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» - это принцип, потому что он отказывается и от «каждая команда выбирает что хочет», и от «вот единственно правильный стек, никаких исключений». Принципы должны быть применимыми, обеспечиваемыми (enforceable) и создавать leverage - в том смысле, что один принцип помогает разрешить десятки конкретных решений.

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

Larson отдельно подчёркивает, что между принципами и действиями всегда должно быть три ответа: как обеспечивается соблюдение (enforcement), как происходит эскалация (что делать, если принцип не работает в конкретном случае), как выглядит переход (как мы движемся от текущего состояния к новому). Без enforcement стратегия становится декларацией. Без эскалации команды учатся обходить её молча. Без описанного перехода стратегия повисает между «как сейчас» и «как должно быть» и в этом промежутке умирает.

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

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

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

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

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

Написание инженерной стратегии похоже на работу историка: посмотрите на то, как уже работает компания, запишите это и поделитесь записями. 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. Каковы приоритеты распределения ресурсов?

Пример формулировки: Поддерживаем соотношение 4 продуктовых инженера на 1 платформенного (security, надёжность, инфраструктура, DevEx). Дополнительно выделяем 10 инженеров на MFA и 10 на миграцию JS на TypeScript.

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

Пример формулировки: Вся разработка использует стандартный стек (Go для backend, TypeScript для frontend, Aurora PostgreSQL). Исключения требуют одобрения Tech Spec Review и CTO.

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

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

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

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

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

Пример: Tech Spec Review проходит еженедельно и рассматривает запросы на исключения из стандартного стека. Без записи в Tech Spec Review исключение считается несанкционированным.

Эскалации

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

Переходы

Пример: Сворачиваем миграцию на микросервисы, возвращаемся к модульному монолиту. Структура команд не меняется, но приоритеты пересматриваются: освободившиеся 6 человеко-кварталов идут на стабильность тестов и observability.

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

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

Диагноз

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

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

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

Финальный шаг: Q&A на инженерном all-hands плюс канал #eng-ask-anything для вопросов. Ревью через 2 месяца, полная оценка - через 6.

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

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

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

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

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

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

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

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

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

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

Все эти ошибки имеют общую природу: стратегия живёт как декларация, а не как контракт. Превращение её в контракт - это всегда некоторое количество скучной операционной работы (ритм review, шаблон Tech Spec, явный список «что не делаем»). Без этой работы любая, даже технически грамотно написанная стратегия превратится в очередной документ в Confluence, на который никто не ссылается.

Резюме

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

Книги и эссе

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

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