Закон Брукса

Закон Брукса — спостереження щодо управління програмним проектом, згідно з яким додавання робочої сили до програмного проекту, який відстає від графіка, затримає його ще більше. Його придумав і описав Фред Брукс у своїй книзі «Міфі́чний люди́но-мі́сяць або Як ство́рюють програ́мні систе́ми» (англ. The Mythical Man-Month) 1975 року. За словами Брукса, за певних умов додаткова особа, додана до проекту, відтермінує виконання проекту, а не пришвидшить його.

Пояснення

Фред Брукс виділяє декілька факторів для пояснення закону:

1. Проекти програмного забезпечення — це складні інженерні розробки, і нові працівники проекту повинні спочатку отримати знання про роботу, яка передувала етапу їх залучення до проекту. Брукс називає це часом «наростання». Процес отримання знань, повязаних з проектом від інших співробітників приведе до зносу ресурсів останніх і зменшення їх продуктивності, оскільки їх увага буде розсіюватись. Кожен новий працівник також має інтегруватися з командою, що складається з кількох інженерів, які мають навчати нового працівника у своїй галузі день за днем. Окрім зменшення внеску досвідчених працівників (через необхідність навчання нових співробітників), нові працівники можуть навіть зробити негативний внесок, наприклад, якщо вони введуть помилки, які відтермінують завершення проекту.
2. Витрати на спілкування збільшуються зі збільшенням кількості людей. Завдяки комбінаторному вибуху кількість різних каналів зв'язку швидко зростає зі збільшенням кількості людей. Витрати на спілкування збільшуються зі збільшенням кількості людей, оскільки кількість різних каналів зростає. Кожен, хто працює над тим самим завданням, має підтримувати синхронізацію, тому чим більше людей додається, тим більше вони витрачають більше часу, щоб дізнатися, що роблять усі інші.
3. Додавання більшої кількості людей до завдання, яке дуже поділено, наприклад прибирання номерів у готелі, зменшує загальну тривалість завдання (аж до моменту, коли додаткові працівники заважають один одному). Однак інші завдання, включаючи багато спеціальностей у проектах програмного забезпечення, менш подільні. Брукс вказує на цю обмежену подільність іншим прикладом: хоча одній жінці потрібно дев'ять місяців, щоб народити одну дитину, «дев'ять жінок не можуть народити дитину за один місяць».

Винятки та можливі рішення

У законі Брукса є кілька ключових моментів, які допускають наявність винятків та відкривають двері для можливих рішень. По-перше, слід зазначити, що закон Брукса застосовується лише до проектів, в яких вже минув термін закінчення. Проекти можна тримати під контролем, якщо заздалегідь додавати людей. Також важливо визначити, чи справді проект порушує графік виконання, чи з самого початку графік був надто оптимістичним. Помилки в плануванні є причиною великої кількості протермінованих проектів. Виправлення графіка є найкращим способом мати значущі та надійні часові рамки для завершення проекту.

Необхідно також враховувати кількість і роль людей, доданих до проекту, а також якість їх професійних знань. Один із простих способів обійти закон про перевитрачений проект — додати більше людей, ніж потрібно, таким чином, щоб додаткова потужність компенсувала витрати на навчання та спілкування. Набираючи людей з вищим професійним рівнем знань можна зекономити з витратами на навчання.

Хороша сегментація допомагає мінімізувати накладні витрати на спілкування між членами команди. Менші проблеми вирішує менша команда, а команда верхнього рівня відповідає за системну інтеграцію. Щоб цей метод спрацював, сегментація завдання повинна бути виконана правильно — якщо це зробити неправильно, це може погіршити проблему, а не покращити, перешкоджаючи спілкуванню між програмістами, які працюють над частинами проблеми, які насправді тісно пов'язані, навіть якщо план проекту постановив, що це не так.

Прикладом сегментації є шаблони проектування, які спрощують розподіл роботи, оскільки вся команда може виконувати свою частину в рамках, передбачених цим шаблоном. Шаблон проектування визначає правила, яких дотримуються програмісти, спрощує спілкування завдяки використанню стандартної мови та забезпечує послідовність і масштабованість.
План Бермудських островів (англ. Bermuda Plan), згідно з яким більшість розробників проекту видаляються («відправляються на Бермудські острови»), а решта залишаються для завершення програмного забезпечення, був запропонований як спосіб обійти закон Брукса.

Див. також

• Управління розробкою програмного забезпечення
• Менеджер продукту
• Закон Лінуса
• Антипатерн