Исправление ilinsky, (текущая версия) :
Экономически выгодно запускать некий mvp, и если продукт взлетает - писать все на спланированной архитектуре (которая кстати планируется с учетом опыта mvp, т.е после обкатки mvp вносятся коррективы или архитектура создается с нуля). Потом выкатывается обновленный продукт. Понятно что это в идеальном мире, но такой подход существует и вполне себе применяется.
Да, иногда удается выкатывать частями и переписывать продукт кусочками, что как раз является грамотно продуманным mvp (да да, над этим тоже нужно думать еще на начальном этапе). А если бизнес говорит что это стоит столько то и мы хотим бабла немедленно, ведь это взлетело - то тут стоит задуматься об адекватности бизнеса и о том как могут развиваться события дальше. В небольшой команде такие вещи решаемы путем общения с бизнесом или хотя бы с носителями его предметной области.
В более менее крупных проектах (если там диктуют по первому принципу), достучаться будет сложнее. Но это уже удел не самих программистов а вышестоящих (архитекторов, тимлидов, техлидов и и прочих лидов, в разных конторах по разному). Потому переписывать иногда хоть и дорого в один момент времени, но зачастую оправдано. И если есть человек который в цифрах сможет это обсновать - ты в хорошей команде. Если нет - страдай. Повторю, еще на этапах проектирования mvp нужно учитывать факт того что проект может взлететь а следовательно его придется пилить в полноценный продукт. Это нужно доносить до бизнеса на этапе проектирования mvp.
Исправление ilinsky, :
Экономически выгодно запускать некий mvp, и если продукт взлетает - писать все на спланированной архитектуре (которая кстати планируется с учетом опыта mvp, т.е после обкатки mvp вносятся коррективы или архитектура создается с нуля). Потом выкатывается обновленный продукт. Понятно что это в идеальном мире, но такой подход существует и вполне себе применяется.
Да, иногда удается выкатывать частями и переписывать продукт кусочками, что как раз является грамотно продуманным mvp (да да, над этим тоже нужно думать еще на начальном этапе). А если бизнес говорит что это стоит столько то и мы хотим бабла немедленно, ведь это взлетело - то тут стоит задуматься об адекватности бизнеса и о том как могут развиваться события дальше. В небольшой команде такие вещи решаемы путем общения с бизнесом или хотя бы с носителями его предметной области.
В более менее крупных проектах (если там диктуют по первому принципу), достучаться будет сложнее. Но это уже удел не самих программистов а вышестоящих (архитекторов, тимлидов, техлидов и и прочих лидов, в разных конторах по разному). Потому переписывать иногда хоть и дорого в один момент времени, но зачастую оправдано. И если есть человек который в цифрах сможет это обсновать - ты в хорошей команде. Если нет - страдай. Повторю, еще на этапах проектирования mvp нужно учитывать факт того что проект может взлететь а следовательно его придется пилить в полноценный продукт.
Исправление ilinsky, :
Экономически выгодно запускать некий mvp, и если продукт взлетает - писать все на спланированной архитектуре (которая кстати планируется с учетом опыта mvp). Потом выкатывается обновленный продукт.
Да, иногда удается выкатывать частями и переписывать продукт кусочками, что как раз является грамотно продуманным mvp (да да, над этим тоже нужно думать еще на начальном этапе). А если бизнес говорит что это стоит столько то и мы хотим бабла немедленно, ведь это взлетело - то тут стоит задуматься об адекватности бизнеса и о том как могут развиваться события дальше. В небольшой команде такие вещи решаемы путем общения с бизнесом или хотя бы с носителями его предметной области.
В более менее крупных проектах (если там диктуют по первому принципу), достучаться будет сложнее. Но это уже удел не самих программистов а вышестоящих (архитекторов, тимлидов, техлидов и и прочих лидов, в разных конторах по разному). Потому переписывать иногда хоть и дорого в один момент времени, но зачастую оправдано. И если есть человек который в цифрах сможет это обсновать - ты в хорошей команде. Если нет - страдай. Повторю, еще на этапах проектирования mvp нужно учитывать факт того что проект может взлететь а следовательно его придется пилить в полноценный продукт.
Исходная версия ilinsky, :
Экономически выгодно запускать некий mvp, и если продукт взлетает - писать все на спланированной архитектуре (которая кстати планируется с учетом опыта mvp). Потом выкатывается обновленный продукт.
Да, иногда удается выкатывать частями и переписывать продукт кусочками, что как раз является грамотно продуманной mvp (да да, над этим тоже нужно думать еще на начальном этапе). А если бизнес говорит что это стоит столько то и мы хотим бабла немедленно, ведь это взлетело - то тут стоит задуматься об адекватности бизнеса и о том как могут развиваться события дальше. В небольшой команде такие вещи решаемы путем общения с бизнесом или хотя бы с носителями его предметной области.
В более менее крупных проектах (если там диктуют по первому принципу). достучаться будет сложнее. Но это уже удел не самих программистов а вышестоящих (тимлидоа, техлидов и т.п, в разных конторах по разному). Потому переписывать иногда хоть и дорого, но зачастую оправдано. И если есть человек который в цифрах сможет это обсновать - ты в хорошей команде. Если нет - страдай.