Как спроектировать организационную структуру и структуру команды?

Question

Accepted Answer

Проектирование организации — это **установление границ команд так, чтобы работа, которая меняется вместе, жила вместе** — минимизация кросс-командных зависимостей для вещей, которые движутся быстро. Структура должна следовать стратегии и системе, а не наоборот.

## Принципы

```text
1. TEAMS OWN OUTCOMES, not layers (a team owns a product/domain end to end)
2. MINIMIZE DEPENDENCIES — autonomous teams ship faster
3. CONWAY'S LAW — your architecture will mirror your org; design both together
4. CLEAR OWNERSHIP — every critical area has ONE owning team
5. RIGHT SIZE — ~5–9 people; two-pizza teams
6. COGNITIVE LOAD — don't give one team more domains than it can hold
```

## Потокоориентированное мышление

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

## Ловушки

- **Функциональные силосы** ("команда QA," "команда frontend"), которые вынуждают каждый функционал проходить через много передач.
- **Игнорирование закона Конвея** и удивление, что архитектура зеркалирует организационную схему.
- **Постоянная реорганизация**, которая каждый раз обнуляет доверие и ответственность.
- **Нечеткое владение**, где всем "владеют вместе" и поэтому никто не владеет.

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

Структура молча определяет скорость.

Плохие границы создают бесконечные координационные совещания и размытую ответственность; хорошие позволяют командам действовать независимо.

Из-за закона Конвея проектирование организации *это* проектирование архитектуры.

Если вы неправильно определили границы команды, никакое инженерное мастерство не сделает систему чистой.