The post has been translated automatically. Original language: Russian
Imagine a classic situation: there is a month left before the deadline, the project is on fire, the team does not have time. The management makes a "logical" decision at first glance — to urgently involve three more strong developers from the neighboring department in the task. It seems that now things will go twice as fast. But in practice, the opposite happens: the project begins to slow down even more, and the deadlines shift even further.
This phenomenon in engineering was described back in 1975 and is called Brooks' Law: "If you add human resources to a project that is already behind schedule, it will only increase its backlog."
Why doesn't simple arithmetic work in IT?
- Tax on onboarding and training: A new person, no matter how cool an engineer they may be, cannot start writing code on the very first day. He needs to deploy the environment, understand the architecture and understand the business logic. And who teaches him all this? Your most experienced developers, whom you take away from performing critical tasks for a week.
- Exponential growth of communications: If there are three people in a team, there are only 3 communication channels between them. If there are seven people, there are already 21 communication channels. Instead of writing code, the team starts spending hours on endless phone calls, synchronizations, code review disputes, and Git conflict resolution.
- Indivisibility of tasks: Not every task can be decomposed into several people. As the famous IT joke says, "Nine women won't be able to have a baby in one month." If an architectural module has to be written sequentially, the three developers will only interfere with each other, creating chaos.
- Task Indivisibility: Not every task can be broken down and shared among multiple people. If one worker is digging a trench that is only one meter wide, it is physically impossible to fit three more people there — they will just hit each other with shovels and hinder the work. If an architectural module must be written sequentially, multiple developers will simply block one another.
How to save projects correctly?
If the project does not meet the deadline, a strong manager or team leader does not look for new people, but ruthlessly cuts the scope of tasks. Focus only on the mission-critical functionality (MVP), without which the system will not be able to start. Move minor features to the next sprint, optimize processes, and let the current team calmly get things done without too much noise and chaos.
The main conclusion is that The speed of development in IT is measured not by the number of hands on the keyboard, but by the effectiveness of the architecture and the transparency of communications within the team.
Представьте классическую ситуацию: до дедлайна остался месяц, проект горит, команда не успевает. Руководство принимает «логичное» на первый взгляд решение — срочно подключить к задаче еще трех сильных разработчиков из соседнего отдела. Кажется, что теперь дело пойдет в два раза быстрее. Но на практике происходит обратное: проект начинает тормозить еще сильнее, а сроки сдвигаются еще дальше.
Этот феномен в инженерии описан еще в 1975 году и носит название Закона Брукса: «Если добавить человеческие ресурсы в проект, который уже отстает от графика, это только увеличит его отставание».
Почему в IT не работает простая арифметика?
- Налог на онбординг и обучение: Новый человек, каким бы крутым инженером он ни был, не может начать писать код в первый же день. Ему нужно развернуть окружение, понять архитектуру и разобраться в бизнес-логике. А кто его всему этому обучает? Ваши самые опытные разработчики, которых вы на неделю отрываете от выполнения критических задач.
- Экспоненциальный рост коммуникаций: Если в команде три человека, между ними существует всего 3 канала связи. Если людей становится семеро — каналов связи становится уже 21. Вместо написания кода команда начинает тратить часы на бесконечные созвоны, синхронизации, споры на код-ревью и распутывание конфликтов в Git.
- Физическая неделимость задач: Далеко не каждый процесс можно распараллелить. Если один строитель копает траншею шириной в один метр, то поставить туда еще трех человек физически невозможно — они будут только бить друг друга лопатами и мешать работе. Если архитектурный модуль должен быть написан последовательно, несколько разработчиков просто заблокируют друг друга.
Как спасать проекты правильно?
Если проект не успевает к сроку, сильный менеджер или тимлид не ищет новых людей, а безжалостно режет скоуп задач. Фокусируйтесь только на критически важном функционале (MVP), без которого система не сможет запуститься. Перенесите второстепенные фичи на следующий спринт, оптимизируйте процессы и дайте текущей команде спокойно довести дело до релиза без лишнего шума и хаоса.
Главный вывод: Скорость разработки в IT измеряется не количеством рук на клавиатуре, а эффективностью архитектуры и прозрачностью коммуникаций внутри команды.
Share
