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