🧐 «Если не стыдно за первую версию продукта (MVP) — вы вышли на рынок слишком поздно», — писал Эрик Райс в своей книге «The Lean Startup».
❓ И после таких фраз меня часто спрашивают, где в этой всей философии качество. Agile, Scrum, продуктовый подход провоцируют создавать некачественный продукт. Во главу угла становится скорость, а где скорость, там появляется куча «костылей» (некачественных решений), которые в итоге когда-нибудь обрушат всё.
⚓️ И чтобы ответить на этот тезис, нужно понять, как же разрабатывается первая версия продукта (MVP — минимальный жизнеспособный продукт). Гонясь за скоростью, должны ли мы делать какие-то решения, менее качественно и отказываться от более сложных и качественных решений? Несомненно, да, но помимо этого мы должны взять на себя ДОЛГ.
💶 На стартап берут кредит, создавая денежный долг перед инвесторами и банками, с надеждой, что если продукт выстрелит, то мы его вернём из прибыли. Аналогично, делая MVP, пренебрегая качественными решениями, мы берём на себя «технический долг», который обязуемся реализовать, в случае если продукт станет успешным.
Технический долг — это метафора, обозначающая накопленные в программном коде или архитектуре проблемы, связанные с пренебрежением к качеству при разработке программного обеспечения и вызывающие дополнительные затраты труда в будущем.
💰 Тот, кто создаёт первую версию продукта, не беря на себя технический долг, по моему мнению, не отличается от того, кто взял деньги в банке и не готов равномерно платить проценты. Любой долг нужно отдавать, и самая лучшая схема закрытия любого долга — это регулярность.
🔥 Определённый бюджет в виде ресурса команды, или, по-другому сказать, «квота», заложенная на каждый равный промежуток времени, может перевести первую версию продукта от состояния стыда до состояния гордости, в течении нескольких итераций. Может быть, это будет 5 % времени команды, может быть, 10 %, а может быть, и все 50 %. Но если долг есть, его надо равномерно плавно сжигать.
📈 Бюджеты же на то, чтобы этот долг сжигать, появляются из уже запущенного, пускай очень сырого, но всё-таки работающего продукта. Делая очень качественный, но очень долгий продукт, можно увидеть, как рынок захватывают конкуренты, с менее качественным, но выпущенным ранее продуктом. И тогда все эти вложенные часы в качество точно никому не будут нужны.
🤝 В одном из следующих постов обязательно расскажу, какие же мероприятия позволяют управлять техническим долгом в Scrum-фреймворке
Если статья понравилась подписывайтесь на канал "Путь Agile" в телеграмм
