Сегодня был интересный ликбез на тему оргструктур, коммуникаций и управления командами, из которого я узнал про закон Конвея: "архитектура вашей системы будет копировать структуру коммуникаций в вашей команде". Мелвин Конвей сформулировал этот принцип в 1967 году: "Организации, которые создают системы, вынуждены создавать проекты, повторяющие структуру коммуникаций этих организаций". Ссылка на хабре
Практические следствия:
- Микросервисы = маленькие кросс-функциональные команды вокруг бизнес-возможностей. Каждая команда владеет своим сервисом от начала до конца
- Правило двух пицц Amazon: команда не должна быть больше, чем могут накормить две пиццы
- В инженерных компаниях, если дизайн, инженерия и производство работают изолированно — продукт страдает на стыках
- Обратный маневр: сначала спроектируйте архитектуру, затем реорганизуйте команды под неё
Тема показалась очень интересной, поэтому посмотрел ещё 9 важных принципов.
- 1️⃣ Закон Брукса
- Добавление людей в проект с нарушенным графиком только замедляет его
- Новым людям нужно время на обучение и вход в контекст
- Коммуникационные издержки растут квадратично с ростом команды
- "Бросить больше людей на проблему" — не работает в разработке
- Маленькие команды эффективнее больших для сложных задач
- 2️⃣ Обратный закон Конвея
- В долгосрочных организациях архитектура системы начинает диктовать структуру организации
- Устоявшиеся системы сопротивляются организационным изменениям
- Легаси-архитектура замораживает организационную структуру
- Сначала проектируйте архитектуру, потом реорганизуйте команды под неё
- Техдолг в коде = организационный долг в структуре команд
- 3️⃣ Закон Хайрама
- Всё наблюдаемое поведение вашей системы будет использоваться кем-то, независимо от документации
- Баги становятся фичами, если на них кто-то полагается
- Недокументированные API всё равно будут использованы
- Невозможно изменить поведение без breaking changes
- Каждая деталь реализации потенциально становится контрактом
- 4️⃣ Закон Паркинсона
- Работа заполняет всё время, отведённое на её выполнение
- Дедлайны мотивируют завершать задачи быстрее
- Timeboxing в Agile основан на этом законе
- Без ограничений по времени задачи раздуваются
- Короткие спринты эффективнее длинных
- 5️⃣ Закон Хофштадтера
- Любая задача занимает больше времени, чем ожидалось, даже если вы учитываете закон Хофштадтера
- Оценки сроков хронически оптимистичны
- Рекурсивная проблема: даже поправки на задержки не помогают
- Всегда закладывайте буфер на непредвиденное
- Планирование — это искусство работы с неопределённостью
- 6️⃣ Закон Теслера
- Для любой системы существует неснижаемый уровень сложности, который можно только перераспределить
- Упрощение для пользователя = усложнение для разработчика
- Нельзя устранить сложность, можно только переместить её
- Сложность распределяется между пользователем, приложением и платформой
- Хороший дизайн — это грамотное перераспределение сложности
- 7️⃣ Закон Гудхарта
- Когда показатель становится целью, он перестаёт быть хорошим показателем
- Измерение строк кода приводит к раздутому коду
- Фокус на количестве багов игнорирует их критичность
- Погоня за покрытием тестами игнорирует реальное качество
- Метрики нужны для понимания, а не для оптимизации
- 8️⃣ Закон Каннингема
- Люди активнее исправляют ошибки, чем отвечают на просьбы
- Критика мотивирует сильнее, чем просьба о помощи
- Юмористическое наблюдение о человеческой психологии
- Не системный закон разработки, а социальный паттерн
- 9️⃣ Закон Стерджена
- 90% всего - это хлам; качество - это исключение, а не правило
- Большая часть кода, идей и решений — низкого качества
- Это нормально — фокусируйтесь на поиске ценных 10%
- Не тратьте время на критику очевидно плохого
