Закон Брукса: почему нанять ещё людей — худшее решение, когда проект горит / Хабр

В 1975 году Фредерик Брукс выпустил книгу «Мифический человеко-месяц». Она появилась не потому, что он решил написать очередной учебник по менеджменту. До этого Брукс руководил разработкой операционной системы OS/360 в IBM - одного из самых масштабных программных проектов своего времени. Когда всё закончилось, ему было что рассказать.

Главная мысль книги звучала странно. Если проект начинает отставать от графика, добавление новых людей не ускорит его. Скорее наоборот - задержит ещё сильнее.

Прошло больше пятидесяти лет, а эту идею до сих пор называют законом Брукса.

Как IBM добавила тысячу программистов - и всё равно опоздала

В начале 1960-х IBM решила создать семейство компьютеров System/360. Идея была революционной: машины разной мощности должны были работать с одной архитектурой и одной операционной системой.

С железом всё шло относительно неплохо. Основные проблемы начались с программной частью.

Сроки начали сдвигаться. Руководство сделало то, что в такой ситуации кажется самым логичным: стало нанимать ещё людей. Над OS/360 одновременно работали больше тысячи программистов, но проект всё равно задержался.

Брукс наблюдал это изнутри и позже сформулировал вывод, который потом стал знаменитым:

«Adding manpower to a late software project makes it later.»

Собственно, отсюда и появился закон Брукса. Сам по себе пример IBM, конечно, ничего не доказывает. Можно возразить: «А вдруг без этих людей проект задержался бы ещё сильнее?»

Но ценность не в одной истории, а в объяснении механизма. Он показывает, почему в определённый момент новые люди начинают не ускорять команду, а создавать дополнительную работу для тех, кто уже в ней есть.

Почему так происходит

На первый взгляд идея кажется нелогичной.

Если один разработчик делает задачу десять дней, то два разработчика должны сделать её примерно за пять. Такая арифметика кажется очевидной. Проблема в том, что разработка почти никогда не работает как арифметика.

Во-первых, новый человек не начинает приносить пользу в первый же день. Ему нужно разобраться в проекте, получить доступы, понять архитектуру, познакомиться с процессами. Всё это время кто-то из опытных разработчиков отвечает на вопросы, показывает код и помогает войти в контекст. Получается интересная ситуация: вместо того чтобы добавить один ресурс, вы временно забираете часть времени у уже работающей команды.

Во-вторых, с ростом команды резко увеличивается количество коммуникаций. Количество потенциальных связей считается по формуле n × (n - 1) / 2.

На бумаге эта формула выглядит абстрактно. Но в жизни каждая новая связь превращается во вполне конкретные вещи: ещё один созвон, ещё одно согласование, ещё один человек, которого нужно держать в курсе изменений. Пока команда маленькая, это почти незаметно. Но после определённого размера люди начинают тратить всё больше времени не на работу, а на синхронизацию друг с другом.

Конечно, в реальной компании не все разговаривают со всеми. Для этого существуют менеджеры, тимлиды, зоны ответственности. Но это не отменяет проблему, а просто меняет её форму.

Часть информации начинает проходить через несколько уровней управления. Где-то она упрощается, где-то теряются детали, где-то её начинают понимать по-разному. При этом неформальные коммуникации никуда не исчезают. Разработчик всё равно пишет дизайнеру напрямую, аналитик идёт к разработчику без созвона с менеджером, потому что так быстрее.

В итоге вместе существуют сразу две структуры: официальная и настоящая. И поддерживать их становится всё сложнее.

Помимо этого, некоторые задачи в принципе нельзя распараллелить. Брукс объяснил это одной фразой, которая давно стала классикой:

Девять женщин не родят ребёнка за один месяц.

Если часть работы должна выполняться последовательно, дополнительные люди почти ничего не меняют.

Представьте, что до релиза осталась неделя. Команда из четырёх разработчиков уже знает проект вдоль и поперёк. В этот момент к ней присоединяются ещё четыре человека. Кажется, что скорость должна почти удвоиться. Но вместо этого старшие разработчики перестают писать код и начинают объяснять архитектуру, отвечать на вопросы, проверять изменения и помогать избежать ошибок. Через неделю вполне может оказаться, что команда успела сделать меньше, чем успела бы без пополнения.

При этом Брукс вовсе не говорил, что большие команды - это плохо. Если проект только начинается, новые сотрудники успевают разобраться в системе и начинают приносить пользу. Если работа легко делится на независимые части - например тестирование, локализация или подготовка документации, - увеличение команды тоже вполне может ускорить процесс.

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

Обычно именно в этот момент закон Брукса и начинает работать.

Почему это актуально и сейчас

За последние пятьдесят лет разработка изменилась почти полностью.

Появились Agile, Scrum, облака, микросервисы, CI/CD, Copilot и десятки других инструментов, но проблема никуда не исчезла. Я бы сказал, что сегодня она стала ещё заметнее. Маленькая команда с хорошими AI-инструментами может делать объём работы, который несколько лет назад потребовал бы гораздо больше людей.

Поэтому главный вопрос уже звучит немного иначе - не «сколько людей нам нужно нанять», а «в какой момент каждый следующий человек начинает замедлять остальных».

Почему я поверил в закон Брукса

Если честно, раньше мне казалось, что Брукс немного преувеличивает. Потом мы сами через это прошли.

4 месяца назад в нашей команде было около десяти человек. Были разработчики, тестировщик, CTO, продукт, маркетинг. Все роли закрыты, процессы описаны, дважды в неделю проходят синки. Со стороны всё выглядело правильно, но на практике баги могли висеть неделями.

Маркетинг и продукт постоянно расходились в приоритетах. Любое решение требовало обсуждений, а пока все договаривались, ситуация уже успевала измениться.

Потом команда стала значительно меньше - сейчас нас трое. И работы меньше не стало. Наоборот, пользователей стало больше, запусков стало больше, а продукт развивается быстрее. Один человек отвечает за разработку и продукт, второй - за маркетинг, третий - за поддержку пользователей. Именно с этой командой мы сделали два самых успешных запуска по конверсии в покупку и продление подписки.

Конечно, дело не только в размере команды. Большую роль сыграли AI-инструменты - они закрыли часть задач, для которых раньше действительно нужны были отдельные люди, но самое интересное произошло не здесь. Исчезли бесконечные согласования, перестал теряться контекст между людьми, любая идея почти сразу превращается в действие. Все одинаково понимают, куда движется продукт.

Наверное, именно это оказалось самым большим выигрышем.

И всё-таки он был прав

Вообще я довольно скептически отношусь к универсальным законам менеджмента. Обычно они красиво звучат, пока не сталкиваются с первой же реальной ситуацией.

Но с законом Брукса получилось иначе. Он не говорит, что большие команды работают плохо и не утверждает, что людей никогда нельзя нанимать. Он говорит гораздо более неприятную вещь: если проект уже начал гореть, проблема, скорее всего, не в количестве людей. А попытка срочно усилить команду может только отвлечь тех, кто ещё способен вытащить проект.

За пятьдесят лет разработка изменилась до неузнаваемости. Появились Agile, облака, микросервисы, AI и десятки инструментов, о которых Брукс даже не мог представить. Но каждый раз, когда сроки начинают срываться, первая идея у многих руководителей остаётся прежней: «Давайте просто наймём ещё людей».

Именно поэтому «Мифический человеко-месяц» до сих пор рекомендуют читать менеджерам и тимлидам. Не потому, что это книга про программирование 70-х годов. А потому, что человеческая природа за это время почти не изменилась.