У розробці програмного забезпечення, особливо коли йдеться про проекти, обмежені бюджетом та/або часом, існує п'ять характеристик, які мають взаємозалежну поведінку, яку часто ігнорують або не помічають. Я маю на увазі якість, час, бюджет, складність та обсяг.
Парадигма п'яти ниток — це метафора, яку ми використовуємо для опису взаємозв'язку між цими п’ятьма концепціями.
Уявімо, що кожна концепція представлена ниткою однакової довжини, і проект, який ми намагаємось побудувати, знаходиться в центрі, з'єднуючи всі п’ять ниток. Коли ви тягнете одну з них, інші неминуче змінюються, є тонкий баланс та взаємний вплив між п’ятьма.
Наприклад, уявімо, що ми хочемо прискорити проект. Тобто ми хочемо скоротити час, що означає, що потрібно тягнути з інших ниток: або проект стає дорожчим (більше людей в команді або більше додаткових годин); або ми зменшуємо його складність (наприклад,
одностадійний процес онбордингу користувачів проти керованого багатоступеневого онбордингу); або з меншою кількістю функцій (наприклад, не включаючи модуль підписок в обсяг робіт); або з нижчою якістю (наприклад, не розробляючи повний набір автоматизованих тестів).
Гнучкість
Деякі з цих ниток є більш гнучкими та еластичними, ніж інші. З нашого досвіду, ми знаємо, що якість, час і бюджет є найбільш негнучкими:
- Ніхто не хоче погано побудований продукт, незалежно від того, наскільки він дешевий.
Тому ми ніколи не жертвуємо якістю. - Гроші не ростуть на деревах, тому бюджет також є досить негнучким, особливо коли йдеться про MVP.
- І вікна можливостей на ринку не будуть відкриті вічно, чекаючи на нас, щоб ми випустили божественний продукт, тому, хоча час може бути трохи гнучкішим за попередні, кожен програмний проєкт має остаточний дедлайн, який не підлягає обговоренню.
Рішення(я)
Отже, залишаються дві маніпульовані нитки, якими можна керувати проєктом до успішного завершення: складність і обсяг.
Зазвичай ці нитки працюють разом, переплітаючись, але вони є окремими концепціями, і ми використовуємо два потужних інструменти для їхнього керування:
1) Фільтрація функцій: При розробці MVP ми класифікуємо функції на основні (головні функції, які визначають ваш продукт), бажані (функції, які можуть додати цінності, але не зупинять випуск MVP, якщо їх не буде) і поза обсягом (функції, які мали б сенс у майбутньому, але не будуть розроблятися в MVP).
Ми намагаємось перевести якомога більше функцій у категорії "бажано мати" і "поза обсягом", зосереджуючись на суті продукту.
2) Коригування обсягу: Ми докладаємо зусиль, щоб функція вписувалася у відведений час, не порушуючи її суті, завжди прагнучи надати завершений продукт. Завжди надавайте перевагу маленькій, але корисній функції замість незавершеної, складної, але не використовуваної функції.
Стреміться до простоти
Ми твердо віримо, що менше — це більше. Легше погодитися на все і в результаті отримати набір функцій, який збільшить довжину нитки часу, разом з іншими нитками (складність, обсяг і бюджет в більшості випадків). Хоча в цьому немає суттєвої проблеми, надзвичайно важливо знайти гармонію між ними.
Особливо коли ви будуєте MVP або будь-який інший продукт, де обмежені час (і іноді, бюджет).
Шлях до простоти зазвичай є хорошим способом знайти таку рівновагу.
Перекладено з: The five strings paradox