# Закономерности управления

> Сегодня был интересный ликбез на тему оргструктур, коммуникаций и управления командами, из которого я узнал про закон Конвея: "архитектура вашей системы будет копировать структуру…

Статья · Алексей Ишманов · 3 февраля 2026 · https://aleksishmanov.ru/blog/zakonomernosti-upravleniya/

Сегодня был интересный ликбез на тему оргструктур, коммуникаций и управления командами, из которого я узнал про закон Конвея: "архитектура вашей системы будет копировать структуру коммуникаций в вашей команде". Мелвин Конвей сформулировал этот принцип в 1967 году: "Организации, которые создают системы, вынуждены создавать проекты, повторяющие структуру коммуникаций этих организаций". [Ссылка на хабре](https://habr.com/ru/companies/engelbart/articles/432972/)

Практические следствия:
-  Микросервисы = маленькие кросс-функциональные команды вокруг бизнес-возможностей. Каждая команда владеет своим сервисом от начала до конца
-  Правило двух пицц Amazon: команда не должна быть больше, чем могут накормить две пиццы
-  В инженерных компаниях, если дизайн, инженерия и производство работают изолированно — продукт страдает на стыках
-  Обратный маневр: сначала спроектируйте архитектуру, затем реорганизуйте команды под неё

Тема показалась очень интересной, поэтому посмотрел ещё 9 важных принципов.

1️⃣ Закон Брукса
Добавление людей в проект с нарушенным графиком только замедляет его
-  Новым людям нужно время на обучение и вход в контекст
-  Коммуникационные издержки растут квадратично с ростом команды
-  "Бросить больше людей на проблему" — не работает в разработке
-  Маленькие команды эффективнее больших для сложных задач

2️⃣ Обратный закон Конвея
В долгосрочных организациях архитектура системы начинает диктовать структуру организации
-  Устоявшиеся системы сопротивляются организационным изменениям
-  Легаси-архитектура замораживает организационную структуру
-  Сначала проектируйте архитектуру, потом реорганизуйте команды под неё
-  Техдолг в коде = организационный долг в структуре команд

3️⃣ Закон Хайрама
Всё наблюдаемое поведение вашей системы будет использоваться кем-то, независимо от документации
-  Баги становятся фичами, если на них кто-то полагается
-  Недокументированные API всё равно будут использованы
-  Невозможно изменить поведение без breaking changes
-  Каждая деталь реализации потенциально становится контрактом

4️⃣ Закон Паркинсона
Работа заполняет всё время, отведённое на её выполнение
-  Дедлайны мотивируют завершать задачи быстрее
-  Timeboxing в Agile основан на этом законе
-  Без ограничений по времени задачи раздуваются
-  Короткие спринты эффективнее длинных

5️⃣ Закон Хофштадтера
Любая задача занимает больше времени, чем ожидалось, даже если вы учитываете закон Хофштадтера
-  Оценки сроков хронически оптимистичны
-  Рекурсивная проблема: даже поправки на задержки не помогают
-  Всегда закладывайте буфер на непредвиденное
-  Планирование — это искусство работы с неопределённостью

6️⃣ Закон Теслера
Для любой системы существует неснижаемый уровень сложности, который можно только перераспределить
-  Упрощение для пользователя = усложнение для разработчика
-  Нельзя устранить сложность, можно только переместить её
-  Сложность распределяется между пользователем, приложением и платформой
-  Хороший дизайн — это грамотное перераспределение сложности

7️⃣ Закон Гудхарта
Когда показатель становится целью, он перестаёт быть хорошим показателем
-  Измерение строк кода приводит к раздутому коду
-  Фокус на количестве багов игнорирует их критичность
-  Погоня за покрытием тестами игнорирует реальное качество
-  Метрики нужны для понимания, а не для оптимизации

8️⃣ Закон Каннингема
Люди активнее исправляют ошибки, чем отвечают на просьбы
-  Критика мотивирует сильнее, чем просьба о помощи
-  Юмористическое наблюдение о человеческой психологии
-  Не системный закон разработки, а социальный паттерн

9️⃣ Закон Стерджена
90% всего - это хлам; качество - это исключение, а не правило
-  Большая часть кода, идей и решений — низкого качества
-  Это нормально — фокусируйтесь на поиске ценных 10%
-  Не тратьте время на критику очевидно плохого