Лично я не фанат “геймификации ради геймификации”, но если вы хоть раз запускали новый мир в Minecraft, то вы уже проживали старт продукта, но просто без Jira. Сначала всё просто: “давайте построим дом”, через 15 минут ночь, нет ресурсов, рядом кто-то шипит (спойлер: это крипер), а ты с деревянной киркой и амбициями уровня enterprise. Знакомое чувство?) 😎"Сейчас быстро сделаем" В начале любого проекта есть этот момент, полный энергии, уверенности, смотришь и “ну это же несложно”. И план есть, и требования есть, и даже сроки понятные. В Minecraft ты думаешь так: срублю пару деревьев, поставлю дом, всё ок, а потом выясняется, что: - ресурсов меньше, чем казалось; - инструменты ломаются; - темнеет быстрее, чем планировалось.

В разработке все ровно то же самое, не продумали зависимости, интеграции, интеграционные команды. И это не потому, что команда “слабая”, а потому что мозг склонен к оптимизму и это само по себе нормально.

Про это есть исследования по эффекту планирования, которое провели Канеман и Тверски, его суть в том, что люди системно недооценивают сроки даже зная прошлый опыт (https://www.kommersant.ru/doc/6634514). И это не потому что мы глупые, мы просто очень оптимистичные по своей натуре.

А ресурсы всегда ограничены, даже если бюджет большой. В Minecraft нельзя сразу сделать алмазную броню, сначала дерево, потом камень, потом железо. В проектах то же самое только вместо кирки: компетенции, доступы, инфраструктура, люди.

И тут важная мысль: Capacity — это не “как быстро мы хотим”, а “как быстро система может”. Сколько ты ни дави, пропускная способность команды не вырастет от желания, ведь она растет от: - опыта, - улучшений процесса, - снижения хаоса.

😎Ночь приходит всегда (релиз тоже) В Minecraft ночь неизбежна, ты можешь игнорировать ее, но мобы игнорировать тебя не будут. И в разработке релиз так же неизбежен, а если команда не подготовится, то начинается героизм, а это уже дорогой способ компенсировать плохую подготовку. Я не против переработок “иногда”, но если это становится системой, значит проблема не в людях, а в планировании.

😎 “В соло” можно выжить. Один игрок в Minecraft может построить дом, а вот город с фермами, шахтами - нет, тут уже нужна кооперация. В Scrum похожая история, но кросс-функциональность это не красивая формулировка из гайда, а необходимость, если продукт сложный. Если фронт не понимает бэк, если аналитика живёт отдельно, если тестирование подключается “в конце” вы строите дом из песка, пока он держится - будет красиво, а потом нет. И это самая частая ошибка строить красиво, а не устойчиво.

В Minecraft можно сделать стеклянный дворец, он впечатляет пока его не взорвали. В проектах это “идеальная архитектура на будущее”, “супер масштабируемость”, “давайте сразу сделаем правильно”. Иногда это оправдано, а иногда - это способ отложить проверку гипотезы. Также и MVP мы делаем не потому что “лень делать качественно”, а потому что сначала нужно понять, что вообще строим.

И вот что в этом всем важно: - Minecraft не про контроль мира, а про адаптацию. - Agile не про то, чтобы угадать все на старте, а про способность менять направление без разрушения системы. Проекты разваливаются не потому, что кто-то “плохо работал”, а чаще потому что недооценили ограничения, переоценили скорость или забыли, что ночь всё равно наступит. А иногда мы сами этот крипер, когда игнорируем очевидное, потому что “ну вроде все работает”.

😘 И если вы в итоге решите в это все поиграть то, помните: - стройте фундамент - считайте ресурсы честно - не надейтесь на героизм и не забывайте проверять, не темнеет ли уже.