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

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

Три части стратегии

Если вас раздражает отсутствие инженерной стратегии в компании — она есть. Ваша стратегия — это то, как вы справляетесь с текущими проблемами. Вопрос в том, записана ли она и согласована ли между командами.

Эффективная стратегия состоит из трёх частей:

Часть	Описание	Пример
Диагностика	Теория, описывающая природу проблемы	Стабильность тестов снизилась на 40%, каждая третья сборка падает
Руководящие принципы	Подходы к решению с явными компромиссами	Соотношение 4:1 продуктовых инженеров к платформенным
Согласованные действия	Конкретные действия, продиктованные принципами	10% времени команд на улучшение стабильности тестов

Процесс написания

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

Шаги

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

Когда писать стратегию

Ответьте "да" на три вопроса:

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

Что делать, если нет бизнес-стратегии?

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

Полезные вопросы для проработки:

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

Структурирование руководящих принципов

Ответьте на три ключевых вопроса:

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

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

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

Проверка принципов

Каждый принцип должен быть:

• Применим — работает для реальных сложных сценариев
• Соблюдаем — вы готовы его enforce'ить
• Создаёт leverage — даёт мультипликативный эффект

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

Действия должны отвечать на вопросы:

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

Как будут поддерживаться правила?

Эскалации

Как оспаривать принцип, если он не работает?

Переходы

Как переходить от текущего состояния к новому?

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

Диагностика

• 400 человек в инженерном отделе (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. Несколько команд переходят между подразделениями.
• Рабочая группа по стабильности тестов: 10% времени продуктовых инженеров + приоритет #3 для платформенных (после security и site stability).
• Tech Spec Review: лёгкие асинхронные проверки. Запросы начинаются в чате, простые решаются асинхронно, сложные — на еженедельной встрече.

Резюме

Ключевые принципы:

• Стратегия = Диагностика + Принципы + Действия
• Пишите сами — это процесс понимания
• Стратегия без enforcement — не стратегия
• Проведите 1:1 с потенциальными критиками заранее
• Эскалации — это нормально и полезно
• Обновляйте стратегию минимум раз в год