В общем случае нет. На этапе разработки MVP любой "костыль и велосипед" (с) лучше, чем его отсутствие.

👍

угу

удобных любят(

а если нанять перфекциониста, который будет давить на то, что "мы же пишем говнокод, надо с этим заканчивать, срочно поднимаем 3 дополнительных стенда и покрываем все тестами"

Даже для MVP. С "as appropriate"  не надо вести везде за ручку, достаточно дать направление и сам все сделает, даже на MVP, соблюдая рациум.
Если value от кода на выброс достаточен, то у меня большие вопросы к проекту и его фин модели.

Тогда не хватит времени или денег.
Этап MVP - это те самые олимпиадники. Главное, чтобы все понимали - этот код на 100% (ок на 80) - технический долг самом незамутненном понимании этого термина.

Я не спорю. Lead/architect должен быть толковым, это не обсуждается.
Рядовые исполнители вполне могут быть "на троечку". Их код будет выкинут вместе с ними после проверки гипотез.

Еще нет фин модели. Как раз и надо проверить, сходится ли экономика, что важно для клиентов, а что - нет и т.д.

🙈🙈прям по моим болям идем((( это пиздец  так работать

Ибо "каждому овощу свое время".
Не надо нанимать людей в ту корпоративную культуру, которая им не подходит. "Поведенческое интервью" и вот это все в руки.

+

Немного про другое, для MVP важно за минимальное время и ресурсы проверить гипотезу.
Соотвественно, чем лучше разработчик знает область своих возможностей, тем быстрее он справится с задачей не теряя на коммуникациях, поиск инфы, лишние размышления, без свиданий с техническими граблями и просто пиная тех от кого он сам зависит. Это сильно увеличивает процент эффективного времени, а значит еще и меньшее кол-во людей нужно, что для MVP  также важно.

Хороший hr всегда найдёт, чем дополнить результат интервью. Не раз убеждался. И "задолбаетесь задачи ставить, он упрямый как....", и "профессионал бесспорно, но склонен к нарциссизму и самолюбованию, будете критиковать - будут скандалы". И  тимлиды задалбывались, и скандалы были)

Я с другим утверждением не согласен - что "плохенький" хуже "никакого".
Чаще всего это верно, но не всегда.

адизес наше все!

Большинство кейсов, про которые здесь идет флейм, связаны с неподходяшим профилем компетенций менеджеров, согласно теории Адизеса.
Или, вообще, с неправильным механистическим взглядом на управление производством ПО.
В этой сфере деятельности субъективный человеческий фактор очень важен. И игнорирование рекомендаций Адизеса практически всегда ведет к фиаско.

адизес никогда не был управленцем же 🙂

И что?

ну я бы не пошел к стоматологу, который только картинки в учебник рисовал