Закон Брукса
Закон Брукса — это принцип, согласно которому добавление рабочей силы в опаздывающий проект разработки ПО лишь увеличивает задержку. Сформулирован Фредериком Бруксом (Frederick Brooks) в книге «The Mythical Man-Month» («Мифический человеко-месяц», 1975), написанной по итогам руководства проектом OS/360 в IBM — одной из первых крупных операционных систем для мейнфреймов.
«Adding manpower to a late software project makes it later.» — Fred Brooks, The Mythical Man-Month (1975)
Ключевая идея книги и самого закона — концепция «мифического человеко-месяца»: человеко-месяцы не являются взаимозаменяемой единицей измерения. Брукс показал, что нельзя механически компенсировать задержку наймом людей, потому что стоимость их включения в проект часто превышает их вклад на ранних этапах.
Почему закон работает
Брукс выделял три фактора, из-за которых добавление людей замедляет опаздывающий проект:
- Неделимость задач (task indivisibility). Не каждую задачу можно распараллелить. Беременность одной женщины длится девять месяцев, и её нельзя ускорить, поставив к ней ещё девятерых: часть работ принципиально последовательна.
- Обучение и адаптация новичков. Каждый новый член команды требует времени на введение в курс дела — знакомство с архитектурой, конвенциями, историей проекта. На это отвлекаются опытные участники, продуктивность которых временно падает.
- Коммуникационные накладные расходы. С ростом команды количество связей между участниками растёт по формуле n(n−1)/2: для 5 человек это 10 связей, для 50 — уже 1225. Всё больше времени уходит на синхронизацию, согласования и совещания, а не на непосредственную разработку.
Что делать
Закон Брукса не означает полный отказ от расширения команды — некоторые проекты действительно требуют увеличения числа участников. Но при принятии решения необходимо учитывать скрытые затраты:
- Не нанимать сразу много людей. Лучше расширять команду постепенно, давая каждому новичку время на интеграцию.
- Использовать разделение работы на подзадачи и делегировать их участникам с соответствующими компетенциями, чтобы параллельная работа была возможна.
- Организовать процесс найма так, чтобы бюрократия и собеседования не отвлекали ключевую команду.
- Вводить новичков через наставничество и документацию, сокращая период низкой продуктивности.
Практический вывод
Расширение команды может иметь как положительные, так и отрицательные последствия: оно увеличивает суммарную пропускную способность, но одновременно замедляет проект из-за накладных расходов. Правильно организованный процесс найма, фокус на постепенной интеграции и распределении ответственности помогает минимизировать эти риски и повысить производительность работы.
