Да, все верно - это одно и то же место в проекте, чинил он его 2 раза или в абзаце про "костыль" детализируется его багфикс - не принципиально, смысл один и тот же: "одно починишь - в других местах сломается"
Я сам лично видел менеджера, который навязывал компании услуги
либо это был менеджер по продажам, либо недобросовестный менеджер проекта с KPI на бюджетах проекта) если владелец продукта не понимает ничего в технике, а такому менеджеру "дать волю" - действительно может произойти впаривание ненужного и избыточного решения, к сожалению..
А Вы типа контора-спаситель, которая все переписывает с нуля?Всегда?
Странный вывод! Конкретно в данной статье описывается история, в которой заново сделать проект дешевле и целесообразнее, чем пытаться исправить текущий. Разумеется, это не относится к каждому проекту. Приходит новый проект - проводим тех. аудит и принимаем решение, по какому пути идем дальше. В практике всегда бывают случаи продолжения тех. поддержки и доработок без переработки с нуля, если архитектура и стек заложены изначально верно, тех.долг описан и поддается планированию его закрытия и поддержки.
Типа "предыдущий разработчик - мудак"?
В нормальной ситуации оценка разработчиков, в т.ч. и предыдущих, производится в другой плоскости. И в статье я привожу пример вполне нормальной и рабочей схемы, при которой MVP разрабатывается джунами-мидлами, с короткими сроками и малыми деньгами - это ни в коем случае не делает их "нехорошими людьми".
Ценность автомобильной ретро-техники понятна - это история, эстетика и демонстрация инженерного таланта в условиях примитивности технологий и материалов. Только технике этой почетное место в музее, на выставках, либо исторических автопробегах/ралли. Мы же говорим о промышленной коммерческой эксплуатации в современных реалиях, с современными требованиями по производительности и безопасности.
Что касается ресурсов - нет ни одного проекта, который не упирался бы в производственные ресурсы. И любой владелец ИС всегда имеет цель оптимизации ресурсов на поддержку и доработки системы. Иначе он был бы неэффективен.
Вы описываете ситуацию с новыми непрофессиональными и/или недобросовестными подрядчиками (я не просто так в чеклисте указывал про senior-архитектора). Тогда конечно смену подрядчика можно охарактеризовать фразой "шило на мыло". Чтобы этого не было, лучше всего в команде инхаус иметь порядочного и преданного делу технаря (чем выше скиллы тем лучше) - он бы помог менеджменту избежать описанной вами ситуации.
Все верно, тестов не было. Более того, в моем примере (он близок к реальному из моей практики) воркфлоу и регламенты разработки были в таком запущенном состоянии на проекте, что зачастую и ручной регресс не выполнялся.
Да, все верно - это одно и то же место в проекте, чинил он его 2 раза или в абзаце про "костыль" детализируется его багфикс - не принципиально, смысл один и тот же: "одно починишь - в других местах сломается"
либо это был менеджер по продажам, либо недобросовестный менеджер проекта с KPI на бюджетах проекта) если владелец продукта не понимает ничего в технике, а такому менеджеру "дать волю" - действительно может произойти впаривание ненужного и избыточного решения, к сожалению..
Странный вывод! Конкретно в данной статье описывается история, в которой заново сделать проект дешевле и целесообразнее, чем пытаться исправить текущий. Разумеется, это не относится к каждому проекту. Приходит новый проект - проводим тех. аудит и принимаем решение, по какому пути идем дальше. В практике всегда бывают случаи продолжения тех. поддержки и доработок без переработки с нуля, если архитектура и стек заложены изначально верно, тех.долг описан и поддается планированию его закрытия и поддержки.
В нормальной ситуации оценка разработчиков, в т.ч. и предыдущих, производится в другой плоскости. И в статье я привожу пример вполне нормальной и рабочей схемы, при которой MVP разрабатывается джунами-мидлами, с короткими сроками и малыми деньгами - это ни в коем случае не делает их "нехорошими людьми".
Ценность автомобильной ретро-техники понятна - это история, эстетика и демонстрация инженерного таланта в условиях примитивности технологий и материалов. Только технике этой почетное место в музее, на выставках, либо исторических автопробегах/ралли. Мы же говорим о промышленной коммерческой эксплуатации в современных реалиях, с современными требованиями по производительности и безопасности.
Что касается ресурсов - нет ни одного проекта, который не упирался бы в производственные ресурсы. И любой владелец ИС всегда имеет цель оптимизации ресурсов на поддержку и доработки системы. Иначе он был бы неэффективен.
Вы описываете ситуацию с новыми непрофессиональными и/или недобросовестными подрядчиками (я не просто так в чеклисте указывал про senior-архитектора). Тогда конечно смену подрядчика можно охарактеризовать фразой "шило на мыло". Чтобы этого не было, лучше всего в команде инхаус иметь порядочного и преданного делу технаря (чем выше скиллы тем лучше) - он бы помог менеджменту избежать описанной вами ситуации.
Все верно, тестов не было. Более того, в моем примере (он близок к реальному из моей практики) воркфлоу и регламенты разработки были в таком запущенном состоянии на проекте, что зачастую и ручной регресс не выполнялся.