Закон Брукса⏰ — 13 июля 2026 г. в 06:05:18.686
Закон Брукса⏰ Пошел учиться на системное мышление наконец-то. Откладывал эту часть 2 года и вот оно наконец-то случилось. Кайфую. Сейчас копаю основные законы, которые работают в различных системах, один из них называется закон Брукса. Встречал его кучу раз на практике, но не знал, что так называется. Суть Добавляя больше людей на поздних стадиях проекта, чтобы спасти сроки, вы еще сильнее в них не попадете. Фредерик Брукс сформулировал этот закон еще в 1975 году в своей культовой книге «Мифический человеко-месяц». Казалось бы, математика начальной школы: если 2 копают яму за 4 часа, то 4 выкопают за 2. Почему в IT это не работает? Потому что Проект — это не просто сумма людей, это система связей. Когда мы добавляем в нее новые элементы на поздних этапах, происходит следующее: 1.Коллапс коммуникации Количество связей в команде растет не линейно, а экспоненциально по формуле N(N-1)/2 Команда из 5 человек — это 10 каналов связи. Команда из 10 человек — уже 45. Больше людей = больше митингов, согласований, конфликтов при слиянии кода и потери контекста. 2. Стоимость онбординга Новый человек на проекте не начнет приносить пользу в первые дни. Его нужно ввести в курс дела, показать архитектуру, выдать доступы. Кто это делает? Ваши самые опытные сеньоры, которые вместо спасения релиза теперь работают няньками. Скорость команды в моменте упадет. 3.Неделимость задач Это про «Девять женщин, которые не смогут выносить ребенка за один месяц»*. Некоторые задачи строго последовательны. Вы не можете ускорить процесс компиляции, тестирование сложного флоу или продумывание архитектуры просто посадив за это больше людей. Пара примеров закона Брукса Разработка. Делаете сложную интеграцию с платежным шлюзом, дедлайн через неделю, не успеваете. Если добавите в команду еще одного бэкендера, текущему лиду придется потратить 3 дня на то, чтобы объяснить ему легаси и бизнес-логику. В итоге потеряете время лида и не получите выхлопа от новичка. QA. Перед релизом накопилась гора багов. Перекидываете на проект трех тестировщиков из соседней команды. Они не знают ваш продукт, заводят дубликаты багов, дергают разработчиков доп.вопросами, парализуя процесс фикса критов. Мой пример Помню как тащили гигантский проект и вышли на финал, где последние 3 месяца нужно было просто фигачить и дотаскивать. Тревожность менеджмента повышалась, все хотели заглянуть глубже в команду. Мы понимали, что если не защитить ребят от митингов и разговоров точно вылетим за сроки. В итоге, взяли удар на себя по паре раз в неделю устраивали чеки, синки и давали актуальный статус. Команда работала, никто не отвлекал, затащили💪 Нюансы Закон Брукса часто понимают слишком буквально и совершают ошибки. Моменты, о которых важно помнить: 1. Закон применим к *отстающим* проектам на *поздних* стадиях. Если вы только стартовали или находитесь на раннем этапе, масштабирование команды работает отлично. 2. Исключение закона - идеально изолированные задачи. Если вы можете выделить кусок работы, который вообще не пересекается с основным функционалом (например, ручная разметка датасета, перевод текстов интерфейса на другой язык), добавление людей реально ускорит процесс. 3. Ловушка «никогда не нанимай». Иногда добавить людей в горящий проект *нужно*. Да, краткосрочно сроки сдвинутся еще сильнее, и вы должны открыто сказать об этом стейкхолдерам. Но стратегически, если проект долгий, через пару месяцев эти новички втянутся и вытащат вас из ямы. Главное — не ждать от них чуда «здесь и сейчас». Итого Думайте, когда добавляете людей на поздних этапах проектах. Точно ли оно того стоит! P.S. Напишите в комментариях ловили ли на себе закон Брукса? #рекомендуетсяизучить