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

Tue, 03 Feb 2026 00:00:00 +0000

Проблема

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

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

Вопросы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1
2


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

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

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

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

Действия:

Запросить вводную у PM:
- Что за проект?
- Какие проблемы решает?
- Кто Tech Lead?
Запросить доступы:
- Репозитории (GitHub/GitLab)
- Мониторинг (Grafana/Prometheus)
- Документация (Confluence/Notion)
- CI/CD (Jenkins/GitLab CI)
Назначить kickoff встречу.

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

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

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

Участники:

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

Agenda:

Бизнес-контекст (10 мин)
- Зачем проект?
- Кто пользователи?
- Какие метрики успеха?
Техническая картина (30 мин)
- Архитектура (компоненты, интеграции)
- Стек (языки, фреймворки)
- Операционка (деплой, мониторинг, инциденты)
Ожидания от курирования (20 мин)
- Что нужно от архитектора?
- Как часто синки?
- Code review/Design review?
Следующие шаги (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 строк конфига). Вычитывал и редактировал.

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

Чеклист (11 секций, 80+ пунктов)
Шаблон отчёта (12 разделов)
Автоматическая валидация (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:

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

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

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

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

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

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

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

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

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

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

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

Действия:

Добавиться в коммуникации:
- Slack/Teams каналы
- Стендапы
- Ретро
Настроить регулярные touchpoints:
- Weekly sync с Tech Lead (30 мин)
- Design review (по запросу)
- ADR review (по факту)
Определить точки контроля:
- Code review критичных изменений
- Approval ADR
- Review перед релизом

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

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

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

Что создал:

Процесс приёмки (6 фаз)
- Описание каждой фазы
- Временные рамки
- Шаблоны коммуникаций
Чеклист приёмки (11 секций, 80+ пунктов)
- Бизнес-контекст
- Системная аналитика
- Архитектура
- Код и тесты
- CI/CD
- Мониторинг
- …
Шаблон аудита (12 разделов)
- Структура отчёта
- Критерии оценки
- Формат рекомендаций
Автоматическая валидация (215 метрик)
- Проверка по чек-листу
- Scoring (1-10)
- Автоматический отчёт

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

Процесс приёмки: github.com/mshogin/archlint/templates/project-handover
Аудит систем: github.com/mshogin/archlint/templates/system-audit

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

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

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

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

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

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

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

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

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

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

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

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

План:

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

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

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

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

Итоги

Что сделано:

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

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

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

Что дальше:

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

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

Ссылки

Процесс приёмки - 6 фаз, шаблоны
Аудит систем - чеклисты, валидация
ADR шаблоны - Architecture Decision Records
Спецификации - для новых проектов

Процессы on Михаил Шогин