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

Сегодня был интересный ликбез на тему оргструктур, коммуникаций и управления командами, из которого я узнал про закон Конвея: “архитектура вашей системы будет копировать структуру коммуникаций в вашей команде”. Мелвин Конвей сформулировал этот принцип в 1967 году: “Организации, которые создают системы, вынуждены создавать проекты, повторяющие структуру коммуникаций этих организаций”. Ссылка на хабре

Практические следствия:

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

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

1️⃣ Закон Брукса Добавление людей в проект с нарушенным графиком только замедляет его

• Новым людям нужно время на обучение и вход в контекст
• Коммуникационные издержки растут квадратично с ростом команды
• “Бросить больше людей на проблему” — не работает в разработке
• Маленькие команды эффективнее больших для сложных задач

2️⃣ Обратный закон Конвея В долгосрочных организациях архитектура системы начинает диктовать структуру организации

• Устоявшиеся системы сопротивляются организационным изменениям
• Легаси-архитектура замораживает организационную структуру
• Сначала проектируйте архитектуру, потом реорганизуйте команды под неё
• Техдолг в коде = организационный долг в структуре команд

3️⃣ Закон Хайрама Всё наблюдаемое поведение вашей системы будет использоваться кем-то, независимо от документации

• Баги становятся фичами, если на них кто-то полагается
• Недокументированные API всё равно будут использованы
• Невозможно изменить поведение без breaking changes
• Каждая деталь реализации потенциально становится контрактом

4️⃣ Закон Паркинсона Работа заполняет всё время, отведённое на её выполнение

• Дедлайны мотивируют завершать задачи быстрее
• Timeboxing в Agile основан на этом законе
• Без ограничений по времени задачи раздуваются
• Короткие спринты эффективнее длинных

5️⃣ Закон Хофштадтера Любая задача занимает больше времени, чем ожидалось, даже если вы учитываете закон Хофштадтера

• Оценки сроков хронически оптимистичны
• Рекурсивная проблема: даже поправки на задержки не помогают
• Всегда закладывайте буфер на непредвиденное
• Планирование — это искусство работы с неопределённостью

6️⃣ Закон Теслера Для любой системы существует неснижаемый уровень сложности, который можно только перераспределить

• Упрощение для пользователя = усложнение для разработчика
• Нельзя устранить сложность, можно только переместить её
• Сложность распределяется между пользователем, приложением и платформой
• Хороший дизайн — это грамотное перераспределение сложности

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

• Измерение строк кода приводит к раздутому коду
• Фокус на количестве багов игнорирует их критичность
• Погоня за покрытием тестами игнорирует реальное качество
• Метрики нужны для понимания, а не для оптимизации

8️⃣ Закон Каннингема Люди активнее исправляют ошибки, чем отвечают на просьбы

• Критика мотивирует сильнее, чем просьба о помощи
• Юмористическое наблюдение о человеческой психологии
• Не системный закон разработки, а социальный паттерн

9️⃣ Закон Стерджена 90% всего - это хлам; качество - это исключение, а не правило

• Большая часть кода, идей и решений — низкого качества
• Это нормально — фокусируйтесь на поиске ценных 10%
• Не тратьте время на критику очевидно плохого