Трикутник Проекту: Незмінний Закон Всесвіту, Про який Повинен Знати Кожен Програміст (та Керівник!)
Привіт, геймери! Casey Byte тут, щоб розібратися з однією з тих фундаментальних істин, яка гризе кожного з нас, хто хоч колись стикався з розробкою: трикутник проекту (або, як я люблю його називати, “Закон двох”). Я не збираюся занурюватися в квантову фізику (хоча це було б весело), а просто розкажу про те, як зробити так, щоб ваші проекти не перетворилися на катастрофу рівня “код на вихідних”.
Що ж таке цей “Закон двох”?
Ваш бос дав вам завдання: “Зробити якісно, швидко і дешево!” Знайомо, так? Чи, може, ви мріяли про проект, який буде одночасно ідеальний, розроблений за лічені дні і при цьому взагалі не з’їсть бюджету? В такому випадку, ви потрапили за адресою.
У світі розробки (та й загалом майже будь-якої діяльності) ви отримуєте тільки два з трьох пунктів:
- Добре (якісно)
- Швидко
- Дешево
Вирішуйте, які два пункти для вас найважливіші, бо третього пункту у вас не буде. Це як E=mc², тільки для розробки програм.
Чому так? Давайте розберемось.
Уявіть собі кодовий проект. У нас є три основні параметри, з якими ми можемо гратися:
- Кількість людей в команді (headcount – скільки людей ми кидаємо на проект)
- Час (скільки часу у нас є на роботу над проектом)
- Швидкість (наскільки швидко ми повинні працювати, щоб отримати результат)
Тепер давайте подивимося, що відбувається, коли ми пробуємо “оптимізувати” (читай, “зламати”) ці параметри:
Сценарій 1: Кидаємо більше людей на проект
Уявіть, що ваш проект затримується. Що ви робите? Звичайно, наймаєте більше розробників!
- Потенційна вигода: “О, круто! Більше людей – більше коду! Швидше будемо!” Більше рук – легша робота (теоретично). Можливо, навіть покращимо якість, бо буде кому робити код рев’ю та краще пропрацювати дизайн проекту.
- Що піде не так: Команда розростається – зростають витрати. Більше людей = більше зарплат. Але, як каже народна мудрість, “сім няньок – дитя без ока”. Існує точка зменшення віддачі.
- Як казав Фред Брукс у своїй класичній книзі “Міфічний людино-місяць”, якщо для народження дитини потрібно дев’ять місяців, то це не означає, що дев’ять жінок можуть народити дитину за один місяць.
- Висновок: Більше людей може прискорити проект … до певної межі. Потім починається “накладний час” на координацію, комунікацію, навчання та розгубленість в коді. Більше людей – дорожче.
Сценарій 2: Даємо більше часу на проект
Затримки проекту? Нема проблем, просто дамо більше часу!
- Потенційна вигода: Більше часу = краща якість! Розробники зможуть краще продумати архітектуру, провести ретельне тестування та рефакторинг. А ще, у людей буде менше стресу, значить, менше помилок. Крім того, потенційно – дешевше, бо можна буде залучити менше людей, якщо часу більше.
- Що піде не так: Це, звичайно, буде не швидко. Від слова “зовсім”.
- Висновок: Більше часу – краща якість, потенційно дешевше, але точно не швидко.
Сценарій 3: Збільшуємо швидкість роботи.
Замовник хоче все “вчора”. Що робити? Натискаємо на педаль газу!
- Потенційна вигода: Швидкість! Ось вона, заповітна швидкість! І, можливо, дешево, бо, можливо, не доведеться наймати надто багато людей (хоча це ще питання).
- Що піде не так: Якість. Звичайно, якість. Коли ви женете зі швидкістю світла, ви неминуче пропускаєте важливі деталі, не встигаєте провести належне тестування, “забиваєте” на коментарі в коді та пишете код навмання, і намагаєтесь “викотити” його в реліз якнайшвидше.
- Висновок: Швидко і може бути дешево, але точно не добре.
Отже, що ми маємо?
У вас є три “системи координат”, але тільки дві з них можуть працювати одночасно. Вибирайте з розумом!
Як це застосувати на практиці?
- Розмовляйте з керівництвом: Покажіть їм це відео! Висловіть словами свою згоду з цими правилами. Переконайте їх. Поясніть, що ви не можете створити шедевр за два дні, якщо при цьому бюджет обмежений (або взагалі відсутній). Допоможіть керівництву зрозуміти пріоритети.
- Чітко визначайте пріоритети: Що найважливіше? Якість? Швидкість? Або ж вам потрібен проект “за копійки”? Від вашого вибору залежить усе.
- Реалістично оцінюйте терміни: Забудьте про “магічні” терміни на кшталт “два тижні на все”. Плануйте час на тестування, код рев’ю, рефакторинг.
- Уникайте “золотого трикутника”: Не намагайтеся отримати все і одразу. Це ніколи не спрацює.
- Говоріть “ні”: Не бійтеся відмовитися від неможливих вимог, якщо ваше керівництво все ж таки буде наполягати на “якісно, швидко і дешево”. Краще втратити проект, ніж втратити репутацію.
Підсумовуючи
Трикутник проекту – це не просто правила, а незмінна реальність, яку повинні розуміти всі, хто працює над реалізацією будь-яких проектів. Зрозумійте його – і ви зробите свої проекти успішними, а себе – щасливішими!
Тепер, якщо ви маєте ідеї, як зруйнувати Всесвіт і порушити цей закон (наприклад, можете працювати над проектом одночасно якісно, швидко та за копійки), пишіть у коментарях – я буду спостерігати з нетерпінням!
