Архитектура

Как принять 4 проекта в архитектурное курирование и не свихнуться

Системный подход к приёмке проектов: от хаоса к процессу из 6 фаз, чеклистам и автоматической валидации.

Проблема

Четыре проекта одновременно. Разные команды, разные стеки, пересечения функциональности непонятны. “Разберись” - единственная инструкция.

Классическая ситуация: руководитель делегирует, архитектор берёт ответственность, а как принимать проекты системно - непонятно.

Вопросы:

  • С чего начать?
  • Что проверить в первую очередь?
  • Как не упустить критичное?
  • За сколько дней уложиться?

Держать всё в голове бесмысленно. Нужен процесс.

Симптомы хаоса

Когда нет процесса приёмки, начинается хаос.

Симптом 1: Археологические раскопки

Архитектор тратит неделю на поиск документации. Слак, конфлюенс, гугл-драйв, wiki - информация размазана. Часть устарела год назад. Половину приходится восстанавливать из кода.

Результат: 5 дней впустую.

Симптом 2: Неожиданные проблемы

Через месяц после приёмки всплывает: мониторинга нет, тесты не покрывают критичные пути, CI/CD собирается на костылях. Исправлять поздно - проект уже в продакшене.

Результат: Firefighting вместо курирования.

Симптом 3: Конфликты с командой

Архитектор начинает править код без контекста. Tech Lead сопротивляется: “Мы так делаем уже год, зачем менять?”

Результат: Потеря доверия.

Диагноз: нужна система

Проблема не в проектах. Проблема в отсутствии процесса.

Приёмка проекта - это не про код. Это про:

  1. Сбор контекста (бизнес, техно, операционный)
  2. Оценку зрелости (архитектура, код, процессы)
  3. Согласование ожиданий (с PM, Tech Lead, командой)
  4. План улучшений (приоритизация и timeline)

Без формального процесса каждый раз изобретаешь велосипед.

Решение: процесс из 6 фаз

Изучил индустриальные практики (Futurice, TOGAF, Harvard EA) и собрал процесс приёмки.

Фазы процесса

1
2

[Инициация] -> [Kickoff] -> [Сбор инфо] -> [Аудит] -> [Решение] -> [Онбординг]
   1 день       1-2 часа      3-5 дней     3-7 дней    1 день      ongoing

Общее время: 7-14 дней.

Фаза 1: Инициация (1 день)

Цель: Получить базовую информацию и доступы.

Действия:

  1. Запросить вводную у PM:

    • Что за проект?
    • Какие проблемы решает?
    • Кто Tech Lead?

  2. Запросить доступы:

    • Репозитории (GitHub/GitLab)
    • Мониторинг (Grafana/Prometheus)
    • Документация (Confluence/Notion)
    • CI/CD (Jenkins/GitLab CI)

  3. Назначить kickoff встречу.

Результат: Базовое понимание проекта, все доступы на месте.

Фаза 2: Kickoff (1-2 часа)

Цель: Синхронизация с PM и Tech Lead.

Участники:

  • PM (бизнес-контекст)
  • Tech Lead (техническая картина)
  • Архитектор (приёмка)

Agenda:

  1. Бизнес-контекст (10 мин)

    • Зачем проект?
    • Кто пользователи?
    • Какие метрики успеха?

  2. Техническая картина (30 мин)

    • Архитектура (компоненты, интеграции)
    • Стек (языки, фреймворки)
    • Операционка (деплой, мониторинг, инциденты)

  3. Ожидания от курирования (20 мин)

    • Что нужно от архитектора?
    • Как часто синки?
    • Code review/Design review?

  4. Следующие шаги (10 мин)

    • Сбор документации
    • Даты аудита
    • Формат отчёта

Результат: Все на одной волне, согласован план.

Фаза 3: Сбор информации (3-5 дней)

Цель: Собрать всё нужное для аудита.

Что собираем:

1. Документация

  • Архитектура (C4, ADR)
  • API спеки (OpenAPI/Swagger)
  • Бизнес-процессы (BPMN)
  • Инциденты (postmortems)

2. Код

  • Структура репо
  • Покрытие тестами
  • Качество кода (линтеры, code review)

3. Инфраструктура

  • CI/CD пайплайн
  • Деплой (Kubernetes/Docker)
  • Мониторинг (метрики, алерты)
  • Логи (структурированность, retention)

4. Операционное

  • SLA (uptime, latency)
  • История инцидентов
  • Процессы эскалации

Результат: Папка с материалами для аудита.

Чек-лист сбора:

1
2
3
4
5
6
7
8

- [ ] Архитектурная документация (C4, ADR)
- [ ] API спецификации (OpenAPI)
- [ ] Схема БД (ER-диаграмма)
- [ ] CI/CD pipeline (конфиги)
- [ ] Мониторинг (дашборды Grafana)
- [ ] История инцидентов (постмортемы)
- [ ] Покрытие тестами (coverage report)
- [ ] Процессы команды (code review, standup)

Фаза 4: Аудит (3-7 дней)

Цель: Понять текущее состояние проекта.

Уровни аудита:

Уровень 1: Обзор архитектуры (1-2 дня)

  • Структура системы (компоненты, слои)
  • Bounded contexts (если микросервисы)
  • Интеграции (синхронные/асинхронные)
  • Tech debt map

Уровень 2: Глубокое погружение (2-4 дня)

  • Код (запахи, сложность, дубликаты)
  • Тесты (покрытие, качество, хрупкость)
  • CI/CD (скорость, надёжность, rollback)
  • Мониторинг (полнота, алертинг, observability)

Уровень 3: Операционное (1 день)

  • SLA vs факт
  • Инциденты (частота, время восстановления)
  • Процессы команды (code review, ADR, standups)

Инструменты для аудита:

Я собрал шаблон аудита совместно с Claude Code (~3882 строк конфига). Вычитывал и редактировал.

Что получилось:

  1. Чеклист (11 секций, 80+ пунктов)
  2. Шаблон отчёта (12 разделов)
  3. Автоматическая валидация (215 метрик)

Пример валидации:

1
2
3
4
5
6
7
8
9

# Проверка покрытия тестами
$ archlint validate --template system-audit --project ./my-project

✓ Test coverage: 78% (target: >70%)
✗ Critical paths coverage: 45% (target: >80%)
✓ CI/CD pipeline: green
⚠ Monitoring: missing SLO alerts

Score: 7/10 (acceptable with improvements)

Результат аудита:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# Отчёт по аудиту проекта {ProjectName}

Дата: YYYY-MM-DD
Архитектор: {Name}

## Executive Summary
- Состояние: Acceptable with improvements
- Критичных проблем: 3
- Требует внимания: 12
- Score: 7/10

## Критичные проблемы (P0)
1. Нет мониторинга SLO
2. Покрытие критичных путей <50%
3. Отсутствует процесс ADR

## Требует внимания (P1)
...

## Рекомендации
...

Фаза 5: Согласование плана улучшений (1 день)

Цель: Договориться о плане действий с командой.

Формат: Встреча с PM и Tech Lead (1 час).

Agenda:

  1. Презентация отчёта (30 мин)
  2. Обсуждение критичных проблем (20 мин)
  3. План улучшений (10 мин)

Три типа плана в зависимости от состояния:

План 1: Стабильный проект

  • Проблемы некритичные
  • План улучшений на квартал
  • Фокус: развитие и оптимизация

План 2: Нужны быстрые фиксы

  • Есть критичные проблемы
  • План фиксов: 2-4 недели (приоритет)
  • Затем план улучшений на квартал

План 3: Требуется стабилизация

  • Множественные критичные проблемы
  • План стабилизации: 1-3 месяца
  • Курирование в режиме пожаротушения
  • После стабилизации - переход к развитию

Результат: Согласованный план действий с приоритетами и сроками.

Фаза 6: Онбординг (ongoing)

Цель: Интегрироваться в команду.

Действия:

  1. Добавиться в коммуникации:

    • Slack/Teams каналы
    • Стендапы
    • Ретро

  2. Настроить регулярные touchpoints:

    • Weekly sync с Tech Lead (30 мин)
    • Design review (по запросу)
    • ADR review (по факту)

  3. Определить точки контроля:

    • Code review критичных изменений
    • Approval ADR
    • Review перед релизом

Результат: Архитектор интегрирован в команду.

Артефакты процесса

Весь процесс оформил в виде шаблонов.

Что создал:

  1. Процесс приёмки (6 фаз)

    • Описание каждой фазы
    • Временные рамки
    • Шаблоны коммуникаций

  2. Чеклист приёмки (11 секций, 80+ пунктов)

    • Бизнес-контекст
    • Системная аналитика
    • Архитектура
    • Код и тесты
    • CI/CD
    • Мониторинг
    • …

  3. Шаблон аудита (12 разделов)

    • Структура отчёта
    • Критерии оценки
    • Формат рекомендаций

  4. Автоматическая валидация (215 метрик)

    • Проверка по чек-листу
    • Scoring (1-10)
    • Автоматический отчёт

Где посмотреть:

Метрики успеха

Как понять что процесс работает?

Метрика 1: Время приёмки

  • Цель: < 2 недель
  • Измеряем: от инициации до онбординга
  • Почему важно: быстрый старт курирования

Метрика 2: Закрытие критичных проблем

  • Цель: > 80% за квартал
  • Измеряем: процент закрытых P0 из отчёта
  • Почему важно: реальное влияние на качество

Метрика 3: Удовлетворённость Tech Lead

  • Цель: > 4/5
  • Измеряем: опрос после 3 месяцев курирования
  • Почему важно: доверие команды

Метрика 4: Участие в design review

  • Цель: > 90%
  • Измеряем: процент review где архитектор участвовал
  • Почему важно: вовлечённость в процесс

Пример использования

Пока теория. На следующей неделе начинаю приёмку 4 проектов - посмотрим что сломается в реальности.

План:

  1. Неделя 1: Инициация + kickoff для всех 4 проектов
  2. Недели 2-3: Сбор информации и аудит (параллельно)
  3. Неделя 4: Решение + онбординг

Буду фиксировать:

  • Где процесс затупил
  • Какие пункты чек-листа оказались бесполезными
  • Сколько времени заняла каждая фаза
  • Какие проблемы не выявил

После завершения - напишу вторую статью с реальным опытом и подводными камнями.

Итоги

Что сделано:

  • Процесс приёмки из 6 фаз (7-14 дней)
  • Чеклист (11 секций, 80+ пунктов)
  • Шаблон аудита (12 разделов)
  • Автоматическая валидация (215 метрик)

Почему это важно:

  • Системный подход вместо хаоса
  • Воспроизводимый процесс
  • Контроль критичных аспектов
  • Измеримые метрики успеха

Что дальше:

  1. Обкатать на 4 проектах
  2. Собрать feedback
  3. Улучшить процесс
  4. Написать вторую статью с реальным опытом

Как вы принимаете проекты? И юзаете ли AI для аудита?

Ссылки

© 2025 - 2026 Михаил Шогин
Создано при помощи Hugo
Тема Stack, дизайн Jimmy