Комментарии 5
Опять заминусят, но это какая-то шняга - отправлять фронтедеров пилить бэк.
По факту, вся проблема была в том, что тупо не наняли достаточно бэк разрабов. Причем, это было понятно далеко до факапа.
Разработчиков всегда будет не хватать. И можно нанимать их пока есть бюджеты, но вы никуда не денетесь от того, что при найме каждого следующего - вы будете терять в производительности из-за перестроения социальных связей. И по мере разрастания команды у вас будет множиться хаос. Гораздо разумней выстроить уже систему работы и дальше расшивать узкие звенья. А они в системе будут всегда и чаще всего это как раз производственные подразделения - разработка.
А еще держите в голове, что если у вас технология/язык программирования такой, что таких людей 3% в рынке, то у вас шансы нанимать сильно сокращаются. Конкретно в данном кейсе нанимают с привлечением разных агенств по 1 разработчику в год. И так происходит не из-за ограничений, просто в рынке мало таких компетенций.
Бизнесу всегда надо искать варианты максимизации своей ценности и в данной ситуации сработал такой подход.
Бесплатно заставили работать фронтов в качестве фуллстаков! Очень классно вышло!
Рад, что вы успели спасти проект по итогу
За полтора года так и не получилось предоставить минимально работающий продукт пользователям
Извините, а в этой команде Lead Time считался по закрытию задачи, не по поставке фичи пользователям? Тогда неудивительно.
Считаю, что дело как раз в том, что не все по "книжке" выстроено. Способ сбора метрик по задачам, а не фичам - лишь производная от клбчевой проблемы. В скраме каждый спринт мы делаем инкремент продукта за счет затаскивания нескольких сторей. Каждая сторя - это ценный для пользователя функционал (может быть частью некой большой фичи). Стало быть максимальный размер одной стори по длительности реализации - 1 спринт. У этой команды 1 задача делается за 1-2 спринта, что принимается за норму, при этом задача - это даже не стори, а именно техническая задача по реализации. То есть, на мой взгляд, здесь скрама нет - очень похоже на водопад, который пытаются унести при помощи спринтов. Причина: проблемы у команды (в первую очередь - владельца продукта) с пониманием, что такое инкремент и как его планировать с продуктовой точки зрения. Интересно, что на демо показывают каждый спринт, если одна задача может 2 спринта занять и при этом это не стори?! ?
Как простая ошибка в интерпретации lead time на два года задержала выпуск продукта на рынок