Техническая стратегия команды: во что вкладывать инженерное время

Понедельник. Продакт принёс три фичи на квартал и говорит, что все три обещаны. Сеньор второй месяц просит разрешения вынести биллинг из монолита. Платформенная команда объявила о выключении старого кластера в ноябре. Безопасность прислала список библиотек с истёкшей поддержкой. Джун спрашивает, почему тесты идут сорок минут. У вас пять человек и тринадцать недель.

Это и есть предмет главы. Техническая стратегия команды — не про то, какие технологии вы любите, а про то, во что вы вложите ограниченное инженерное время и от чего откажетесь вслух.

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

Оговорка про доказательства

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

• Связь инженерных практик со скоростью поставки. DORA и книга Forsgren, Humble, Kim Accelerate (2018) показывают устойчивую корреляцию между набором практик (непрерывная интеграция, слабо связанная архитектура, автотесты) и метриками поставки. Оговорки, которые в пересказах теряются: данные опросные и срезовые, метрики самооценочные, участники самоотобраны — это не доказательство «внедрите практику, получите результат». Разбор — в главе про DORA.
• Продуктивность измеряется на уровне системы, а не человека — позиция авторов SPACE framework (ACM Queue, 2021): единица измерения эффекта — поток работы команды, а не выработка отдельных людей.
• Закон Конвея. Melvin Conway, «How Do Committees Invent?» (1968): система повторяет структуру коммуникаций организации; гипотеза «зеркалирования» проверялась эмпирически (MacCormack, Rusnak, Baldwin, 2012). Вывод: архитектурное решение, противоречащее границам команд, обычно проигрывает — см. главу 13.
• Метрика, ставшая целью, перестаёт быть метрикой — формулировка Мэрилин Стратерн (1997) для закона Гудхарта. Объясняет, почему любая ваша измеримая цель начнёт разлагаться примерно через квартал после объявления.

Всё остальное ниже — отраслевая практика и рамки для рассуждения: их ценность не в доказанности, а в том, что после них видно, кто платит и что произойдёт при нарушении.

Что такое стратегия и что ею не является

Самое полезное определение — у Ричарда Румельта (Good Strategy / Bad Strategy, 2011): стратегия состоит из диагноза (что именно у нас не так и почему), направляющей политики (общий подход) и согласованных действий (которые не противоречат друг другу). Убрать любую часть — получится не стратегия. Признаки плохой узнаются в инженерном мире мгновенно:

Быстрый тест на пух. Напишите противоположное утверждение. «Мы делаем надёжный сервис» → «мы делаем ненадёжный сервис»: никто такого не скажет, значит, первое не было решением. А вот «жертвуем скоростью фич ради предсказуемости релизов» имеет живую противоположность.

Три разграничения, которые экономят месяцы споров. Стратегия ≠ список технологий: «переходим на Kubernetes» — действие без диагноза («выкатка занимает два часа ручной работы, за квартал это 60 часов и три инцидента из-за расхождения окружений»). Стратегия ≠ роадмап: роадмап живёт в продуктовом контуре (приоритизация, стратегия продукта), а ваша задача — ответить, какая способность команды должна вырасти, чтобы он был выполним. Стратегия ≠ архитектура: решения — следствия, их место в ADR и дизайн-ревью (архитектурные решения), а стратегия отвечает, какие вопросы мы в этом квартале вообще открываем.

Ваш горизонт — один-два квартала. Стратегия компании («уходим в облако», «выбираем корпоративный стек») не ваш уровень: попытка написать её за компанию заканчивается документом, который никто не исполняет. Границы полномочий — в обзорной главе.

Единственный бюджет, которым вы правда распоряжаетесь

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

Пять корзин, в которые раскладывается почти всё:

1. Продуктовые обязательства — то, за что вас нанимали, видимое снаружи.
2. Дефекты и поддержка — баги, запросы от других команд, «посмотри, у нас не работает».
3. Дежурства и операционка — то, что Google SRE называет toil: ручная повторяющаяся работа без долговременной ценности, растущая линейно с нагрузкой (SRE book).
4. Вложения в способность — тесты, инструменты, платформа, разбор долга, обучение. Единственная корзина, которая меняет ёмкость остальных.
5. Координация и переключения — встречи, согласования, ожидание ответа, контекст-свитчи. Самая недооценённая: в задачи она не попадает никогда, а съедает заметную долю.

Как замерить, не строя тайм-шиты

Точность здесь не нужна и вредна: достаточно отличить 60/20 от 20/60. Дешёвый вариант — ретро-оценка, когда команда раскладывает по корзинам прошедшие две недели (полчаса, большая погрешность, уклон в «мы много делали фич»). Надёжнее — поле «корзина» в трекере плюс грубая оценка в днях. Точнее всего выборочный дневник, но дольше двух недель его не просите — устают.

# Распределение инженерного времени по корзинам: вход — выгрузка задач за период
# (корзина + грубая оценка в днях). Цель не бухгалтерия, а порядок величин.
from collections import defaultdict

BUCKETS = ("product", "defects", "ops", "capability", "coordination")


def allocation(issues, coordination_days=0.0):
    """Доли по корзинам и доля неразмеченного. Время O(n), память O(k) по корзинам.

    coordination_days — оценка координации ИЗВНЕ трекера (встречи, ожидание,
    переключения): в задачи она не попадает, и без неё картинка врёт. Если
    неразмеченного больше трети, замер бесполезен — чинить надо разметку.
    """
    spent = defaultdict(float)
    for issue in issues:
        bucket = issue.get("bucket") if issue.get("bucket") in BUCKETS else "unclassified"
        spent[bucket] += float(issue.get("days") or 0.0)

    spent["coordination"] += coordination_days
    total = sum(spent.values())
    if total == 0:
        return {}, 1.0

    shares = {name: round(days / total, 3) for name, days in sorted(spent.items())}
    return shares, shares.get("unclassified", 0.0)

Два предупреждения. Не превращайте замер в учёт рабочего времени: как только цифра влияет на оценку людей, она перестаёт быть измерением — ровно по Гудхарту (см. главу про слабый результат). И считайте прерывания: дежурный с девятью обращениями за неделю не имел недели работы, у него было девять фрагментов — см. дежурства и инциденты.

Диагноз: от жалобы к проверяемой формулировке

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

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

Признак того, что диагноз не сделан: на вопрос «что будет, если мы этого не сделаем в этом году» команда отвечает «ну, будет плохо». Правильный ответ: «регрессия съест ещё 18 дней, и мы не успеем к интеграции с партнёром в ноябре».

Направляющая политика — это набор отказов

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

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

Портфель: четыре корзины вложений и потолки вместо квот

Дальше идёт распределение. Полезно думать не про список задач, а про портфель с разными профилями риска: обязательства (обещано наружу, объём обычно обсуждаем), надёжность и операционка (растёт сама, если не ограничивать), способность (единственное, что меняет ёмкость остальных корзин) и риск с соответствием (EOL, уязвимости, лицензии — не приносит ничего видимого, но однажды взрывается целиком).

Правый верх — начинайте отсюда: эффект виден за недели, ошибка дешева. Левый верх — то, ради чего стратегия и нужна: сильный эффект, но проверить его можно только через квартал, а значит, нужны защищённое время, письменный тезис и точка ревизии. Левый низ опаснее всего: туда попадает «перепишем на другом языке», и при такой цене проверки нужен диагноз посильнее эстетического.

Почему «20% времени на техдолг» обычно не работает

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

Что работает надёжнее (отраслевая практика, не исследование): потолок на операционку — у Google SRE это «не более 50% времени на toil» с эскалацией при превышении, и потолок отличается от квоты тем, что срабатывает сам; одна крупная инвестиция за квартал, доведённая до конца — лучше одна законченная, чем три наполовину; привязка к потоку работы, а не к календарю — не «пятница на рефакторинг», а «правим модуль — приводим его в порядок в той же задаче»; и явная строка в плане квартала с владельцем, ожидаемым эффектом и датой проверки. Механика самого долга — учёт, классификация, разговор с бизнесом — в следующей главе.

Решение по конкретному вложению

Когда приходит предложение («давайте вынесем биллинг»), полезно иметь один и тот же проход по вопросам. Не потому, что процесс важен, а потому, что одинаковый проход делает ваши отказы предсказуемыми — а предсказуемый отказ команда переносит гораздо легче случайного.

Два узла важнее прочих. «Записать в осознанный отказ»: незаписанный отказ возвращается каждый месяц и обсуждается заново; запись занимает три строки — что предложили, почему сейчас нет, при каком условии вернёмся. «Дверь в одну сторону» — эвристика Джеффа Безоса из письма акционерам Amazon: для обратимых решений долгий анализ дороже ошибки; для необратимых (формат данных, публичный API, разделение базы) цена ошибки — годы, и там уместны дизайн-док и ревью.

Инвестиция — это гипотеза, у которой есть конец

Главная патология технических инициатив не в том, что их не начинают, а в том, что их не заканчивают. Незавершённая миграция — самое дорогое состояние: живут две системы, знания разделены, новички учат обе, каждая правка делается дважды.

Петля на «двойном состоянии» — не украшение диаграммы, а самый частый исход технических инициатив там, где стратегия не доведена до правил завершения. Предотвращают её три правила:

1. Миграция без даты выключения старого — не миграция, а добавление ещё одной системы. Дата называется до начала работ и стоит в том же документе, что и цель.
2. Критерий успеха формулируется до пробы. Иначе после раскатки всегда найдётся объяснение, почему получилось хорошо. «Время прогона пайплайна на main ниже 10 минут в 9 случаях из 10 в течение двух недель» проверяемо; «стало удобнее» — нет.
3. У инициативы один владелец с именем, а не «команда». Владелец без выделенного времени — это уже отказ, просто вы его ещё не признали. Инструмент, придуманный ровно для того, чтобы миграция шла кусками и каждый кусок завершался, — fig-душитель; его типичная поломка та же: прослойку поставили, два куска перенесли, а дальше приоритет ушёл.

Как это выглядит на бумаге

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

# Техническая стратегия команды «Платежи», Q3
диагноз:
  наблюдение: "От merge до прода 9 рабочих дней, из них 6 — ручная регрессия"
  механизм: "Регрессию делает один человек, она блокирует релизный поезд"
  цена: "За квартал 18 человеко-дней и 2 сорванных срока из 5; замер по 42 задачам"

политика:
  делаем: "Автоматизируем регрессию по 3 критичным сценариям оплаты"
  не_делаем:
    - "Не выносим биллинг в отдельный сервис до конца года"
    - "Не обновляем мажорную версию фреймворка в этом квартале"
    - "Не берём новые интеграции сверх двух уже обещанных"

действия:
  - что: "Автотесты на 3 сценария + прогон в пайплайне"
    владелец: "Аня"
    время: "12 человеко-дней"
    готово_когда: "Релиз собирается без ручного шага регрессии"
  - что: "Тестовые данные для платёжного контура"
    владелец: "Сергей"
    время: "5 человеко-дней"

цена:
  кто_платит: "Продукт: интеграция с партнёром сдвигается на октябрь"
  согласовано_с: "Продакт, руководитель направления — 14 июля"

проверка:
  признак_успеха: "Время от merge до прода ниже 3 дней на 4 релизах подряд"
  контр_признак: "Доля упавших релизов не выросла"
  дата_ревизии: "1 октября"
  если_не_сработало: "Возвращаем ручной шаг, разбираем причину"

Две строки, которых обычно нет: кто_платит превращает документ из списка желаний в решение, а если_не_сработало защищает инициативу от превращения в вопрос вашей репутации — исход «не сработало», названный заранее, не стыдно объявить.

Торговля за инженерное время

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

Аргумент переводится в валюту собеседника. Продакту не нужно «нам надо на техдолг». Ему нужно: «регрессия стоит 18 дней за квартал — это одна фича из четырёх; предлагаю потратить 12 дней сейчас, чтобы вернуть 18 в следующем квартале; проверим на релизе 1 октября». Руководителю нужно: риск, срок, что перестанет делаться. Разговор наверх разобран отдельно в главе про managing up.

Вы приносите решение, а не проблему. «Что делать с техдолгом?» — вопрос, который возвращается вам же; «вот два варианта, у каждого своя цена, я рекомендую первый» — разговор на пять минут. Ответ «нет» — нормальный исход: зафиксируйте письменно, что предлагали и что решили (не как угрозу, а как учёт), назовите, что теперь не будет сделано, и вернитесь с тем же тезисом после первого инцидента, который он предсказывал.

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

Стратегия и люди: кто её делает

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

Стратегия, которую делаете лично вы, не переживёт вашего отпуска. Лид сам пишет дизайн, сам делает ключевой кусок, сам следит за миграцией — а через два месяца никто не знает, зачем это. Инициатива без второго человека, способного её объяснить, — не инициатива (см. делегирование).

Стратегия не может быть тайной. Команда, не знающая политики, будет каждый раз принимать локально разумные решения, из которых не складывается ничего. Рабочий критерий: спросите через месяц у мидла, что мы в этом квартале решили не делать. Не назовёт три вещи — политики нет, есть документ. И разногласия обсуждаются до решения, а не после: «не согласен, но берусь» — здоровая позиция, молчаливый саботаж — нет (см. конфликты и коучинг команды).

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

Полноценно — никак: причинность недоступна. Доступны прокси-сигналы, дающие вместе достаточную уверенность.

Правило: держите два-три сигнала, а не двенадцать, и всегда рядом с историями. Цифра без истории не объясняет, история без цифры не проверяется. И помните про Гудхарта: сигнал, объявленный целью и связанный с оценкой людей, начнёт улучшаться отдельно от реальности. Ревизия — раз в квартал, три вопроса: что из обещанного сделано и подтвердился ли признак успеха; что изменилось в диагнозе; от чего отказываемся дальше и кто платит. Стратегия, которую не пересматривают, через два квартала описывает несуществующую систему.

Типичные способы всё сломать

• Решение без диагноза. «Переходим на Kubernetes» вместо «выкатка руками стоит 60 часов в квартал». Проверка: попросите число. Нет числа — вы обсуждаете вкус.
• Стратегия без отказов. Документ, где всё важно: ни одно предложение после него не будет отклонено, значит, он ни на что не влияет.
• Миграция без даты выключения старого и фиксированные 20% на долг как ритуал — обе ошибки разобраны выше; вместе они дают квартал занятости без результата.
• «Перепишем с нуля». Разбор — у Джоэла Спольски, Things You Should Never Do (2000): переписывание выбрасывает годы накопленных исправлений редких случаев. Иногда это верное решение, но критерий не «код плохой», а «не можем поставлять, и постепенный путь дороже».
• Resume-driven development. Технология выбирается по интересности; распознаётся по аргументам без числа («современно», «все переходят»). Лечится вопросом «какую нашу проблему это закрывает».
• Противоречие между документом и вашими ежедневными вопросами. Объявили фокус на надёжности, а на синках спрашиваете только про сроки фич — команда верит вопросам, а не документам.

Границы: что вы не решаете

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

Практическое следствие: стандарт, который руководитель нарушает первым «в порядке исключения, релиз горит», перестаёт существовать в тот же день. Самая частая ошибка в исполнении технической стратегии — и единственная, которая целиком в вашей власти.

Мини-итог

• Техническая стратегия команды — решение о распределении единственного ресурса, которым вы распоряжаетесь: инженерного времени. Не список технологий и не второй роадмап. Её структура: диагноз с числом и механизмом, направляющая политика, согласованные действия.
• Политика — это набор отказов. Непонятно, как выглядит нарушение, и неизвестно, кто платит, — значит, лозунг. Фиксированная квота на долг хрупка: надёжнее потолок на операционку и одна доведённая до конца инвестиция за квартал.
• Обратимые решения проверяются пробой, необратимые требуют документа и разговора наверх. Миграция без даты выключения старого превращается в двойное состояние — самое дорогое.
• Времени вам не дадут — его можно только обменять: аргумент в валюте собеседника, отказ письменно, тайных работ не бывает. Стратегические задачи при этом ещё и дефицитный ресурс роста.

Источники

• Rumelt, R. Good Strategy / Bad Strategy (2011) — ядро стратегии и признаки плохой.
• Forsgren, N., Humble, J., Kim, G. Accelerate (2018) и DORA — корреляция инженерных практик со скоростью поставки; помните про опросную природу данных. Там же — The SPACE of Developer Productivity, ACM Queue, 2021.
• Google. SRE book: Eliminating Toil — toil и правило потолка в 50%.
• Conway, M. How Do Committees Invent? (1968); MacCormack, Rusnak, Baldwin (2012) — эмпирическая проверка гипотезы зеркалирования.
• Fowler, M. StranglerFigApplication; Spolsky, J. Things You Should Never Do (2000); Bezos, J. Letter to Shareholders; ADR — формат фиксации решений и отказов.
• Larson, W. lethain.com и An Elegant Puzzle (2019); Strathern, M. (1997) Improving ratings: audit in the British University system — формулировка закона Гудхарта.

Что дальше

Самая тяжёлая корзина в портфеле — «вложения в способность», и самая спорная строка внутри неё — технический долг: его невозможно предъявить бизнесу в том виде, в каком он существует в коде. Следующая глава — про то, как превратить его в управленческий объект с учётом, ценой и очередью: Технический долг как управленческая задача.