Техническая стратегия, дорожная карта, архитектурные решения, управление техническим долгом
Время освоения: ~40 минут Цель: Научиться создавать и реализовывать техническую стратегию, которая связывает бизнес-цели с инженерными решениями и позволяет команде двигаться осознанно
| Компонент | Что включает | Горизонт |
|---|---|---|
| Принципы | Ценности и правила принятия решений | Постоянно |
| Видение | Куда движется архитектура через 2–3 года | 2–3 года |
| Дорожная карта | Конкретные инициативы и приоритеты | 6–18 месяцев |
| ADR | Документация архитектурных решений | По мере принятия решений |
| Risk Register | Реестр технических рисков | Квартально |
| Горизонт | Период | Что планировать | Детализация |
|---|---|---|---|
| Now | 0–3 месяца | Текущий квартал, sprint backlog | Высокая |
| Next | 3–6 месяцев | Следующий квартал, крупные инициативы | Средняя |
| Later | 6–18 месяцев | Стратегические направления | Низкая |
## Контекст
Где мы сейчас, какие проблемы решаем
## Цели
Что достигнем за горизонт планирования (измеримо)
## Принципы принятия решений
Правила, которыми руководствуемся при trade-off'ах
## Инициативы
Конкретные проекты с приоритетами и ресурсами
## Риски
Что может пойти не так, как реагируем
## Метрики успеха
Как поймём, что стратегия работает
Техническая стратегия — это мост между бизнес-целями и инженерными решениями. Без неё команды работают реактивно: тушат пожары, накапливают технический долг, принимают изолированные решения, которые со временем противоречат друг другу.
Почему стратегия нужна:
Кто создаёт техническую стратегию: обычно Engineering Manager или Principal Engineer вместе с командой. Стратегия, написанная в одиночку «в башне», не работает — нужен input от людей, которые будут её реализовывать.
💡 Ключевая мысль: Хорошая техническая стратегия — это не 50-страничный документ. Это несколько ясных принципов и приоритетов, которые помогают каждому инженеру принимать правильные решения самостоятельно.
Не весь технический долг одинаков. Мартин Фаулер предложил матрицу:
| Намеренный | Ненамеренный | |
|---|---|---|
| Рассчитанный | «Мы знаем лучший подход, но пока нет времени» | «Мы не знали лучшего подхода» |
| Безрассудный | «Давайте без дизайна, времени нет» | «Что такое слои приложения?» |
Рассчитанный намеренный долг — нормальная бизнес-практика. MVP запускают быстро, потом рефакторят. Главное — зафиксировать долг явно.
Устаревший долг — самый опасный: система эволюционировала, а части кода остались в прошлом. Люди, которые их писали, ушли. Документации нет.
Случайный долг — незнание лучших практик. Лечится обучением и код-ревью.
Фиксировать явно: каждый элемент техдолга — задача в бэклоге с тегом tech-debt. Невидимый долг не управляется.
Оценивать по влиянию: не всё надо чинить. Приоритизировать по формуле: влияние на скорость × вероятность наступления проблемы.
Правило бойскаута: при касании кода — оставь его чище, чем нашёл. Маленькие улучшения накапливаются.
Выделять % мощности: 15–20% capacity спринта на технический долг. Без явного выделения его не будет — всегда найдётся «более срочное».
Debt ceiling: если долг превышает порог (например, 30% задач в бэклоге — tech-debt), объявить «debt sprint» только для рефакторинга.
Трёхгоризонтная модель помогает управлять неопределённостью:
Now (0–3 месяца): детальный план. Конкретные задачи, ответственные, сроки. Здесь работает sprint planning.
Next (3–6 месяцев): понятные направления с умеренной детализацией. «В Q3 мигрируем на PostgreSQL» — без разбивки на спринты.
Later (6–18 месяцев): стратегические ставки с низкой детализацией. «К концу года перейдём на микросервисы» — без жёстких сроков.
Не пытайтесь детализировать горизонт Later так же, как Now — это ложная уверенность.
Техническая дорожная карта должна быть синхронизирована с продуктовой. Инструменты:
При выборе между инициативами задай три вопроса:
Приоритет = Ценность × Риск / Усилие
ADR — лёгкий формат документации архитектурных решений. Решает проблему «мы не помним, почему так сделали».
Структура ADR:
# ADR-001: Использование PostgreSQL вместо MongoDB
## Статус: Принято
## Контекст
Нам нужна база данных для хранения заказов. Рассматриваем PostgreSQL и MongoDB.
## Решение
Выбираем PostgreSQL.
## Обоснование
- Структурированные данные с жёсткими связями → реляционная модель подходит лучше
- Команда знает SQL, нет эксперта по MongoDB
- Транзакционность критична для финансовых операций
## Последствия
+ Привычный стек, быстрый старт
- Горизонтальное масштабирование сложнее, если понадобится
Фитнес-функции — автоматические проверки архитектурных ограничений. Примеры:
Это «исполняемая архитектура»: архитектурные принципы проверяются автоматически, а не на словах.
Инженеры говорят о микросервисах, бизнес — о росте выручки. Тимлид должен уметь переводить:
| Бизнес-цель | Техническая инициатива |
|---|---|
| Выйти на новый рынок за 3 месяца | Сделать систему мультитенантной |
| Снизить стоимость операций на 30% | Автоматизировать ручные процессы |
| Уменьшить время онбординга клиентов | Улучшить API интеграций |
| Обеспечить 99.9% SLA | Внедрить circuit breakers, redundancy |
Objective and Key Results помогают сделать технические цели измеримыми:
Objective: Повысить надёжность платформы
KR1: MTTR < 1 часа (сейчас: 4 часа)
KR2: Change Failure Rate < 5% (сейчас: 12%)
KR3: 99.9% uptime (сейчас: 99.5%)
Хороший инженерный OKR: амбициозен, измерим, привязан к бизнес-ценности.
Реестр рисков — простая таблица для управления:
| Риск | Вероятность | Влияние | Score | Владелец | Митигация |
|---|---|---|---|---|---|
| Падение базы данных | Средняя | Критическое | Высокий | DevOps lead | Read replicas, backups |
| Уход key developer | Низкая | Высокое | Средний | EM | Документация, парное программирование |
Score = Вероятность × Влияние
Оба нужны. Только mitigation — наивность. Только contingency — отказ от профилактики.
| Ошибка | Почему это плохо | Как исправить |
|---|---|---|
| Стратегия написана тимлидом в одиночку | Команда не понимает и не принимает стратегию, реализация страдает | Включать команду в разработку: workshop, ретро, brainstorm |
| Технический долг не документируется | Невидимый долг накапливается, потом взрывается кризисом | Каждый элемент долга — задача в бэклоге с тегом tech-debt |
| Дорожная карта детализирована на 2 года вперёд | Ложная уверенность, документ устаревает быстрее, чем обновляется | Now детально, Next средне, Later направление без дат |
| Архитектурные решения не документируются | «Почему мы так сделали» — никто не помнит, решения повторяются | Ввести ADR: 1 страница на каждое значимое решение |
| Техническая стратегия не связана с бизнес-целями | Инженеры работают «в вакууме», бизнес не видит ценности | Каждая инициатива должна иметь бизнес-обоснование |
| Риски не отслеживаются | Риски материализуются как «внезапные» кризисы | Вести risk register и пересматривать его ежеквартально |
Проведи инвентаризацию технического долга в своей команде:
Вспомни архитектурное решение, принятое за последние 6 месяцев (выбор инструмента, паттерна, подхода):
Далее: Метрики