ну эт норма )

почему мутанты? Проекты большие, одного человека не хватает, удобно сохранять фокус на одной части вместо всего целиком

ну здорово. Много ресурсов тратите на коммуникацию команд между собой?

и против их попыток превратиться в героев басен Крылова?

Обычно тут работает то, что люди хотят расширять набор интересных задач.  Ну и , иногда, реально проще 1 человеку все делать.  Например: у вас есть набор тривиальных багов, которые фиксятся в основном на бэкенде, и совсем немного на фронтенде.  При этом, фронтенд можно вообще не знать, какая нибудь ошибка формативания или неправильное свойство у DOM , whatever.  Такое реально проше пофиксить бэкендеру, если он хотя бы немного сечет, чем напрягать двух людей.

нет. команда выделяется только когда область задач становится очень большой. и достаточно автономной.

но опять же без конкретной ситуации - пытаться найти тут адекватность будет крайне проблематично )

Согласен, что в команде не должно быть ярлыков по специализациям, но это не значит, что не должно быть специализации. Она должна быть органической, то есть диктаваться не названием должности, менеджером или ещё как-то, а формироваться органически. То есть человеку может нравиться писать SQL запросы и он чаще берёт на себя такие таски и углубляет тем самым свои знания в этой области. Но это не значит, что если нет задач по SQL, которые надо делать сейчас, то он должен сидеть и плевать в потолок, или делать неважные задачи на будущее. Он вполне может, например, поковыряться и в джаваскрипте, если это на данный момент самая важная из свободных задач, а "спецы" по джаваскрипту заняты. Если такая ситуация будет повторяться часто, то ненужные специализации будут отваливаться сами собой, а нужные, наоборот автоматически прокачиваться

Но ведь наши утверждения на самом деле не противоречат друг другу!

Только в оценочной части. "Хорошо" или "неизбежное зло"

)))

Но в данном случае "хорошо" эквивалентно моему "экономически оправдано"

+

да, тут вопрос слаженности команды, адекватности архитектуры и т д.

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

но всегда есть исключения, где что то идет не так и начинаются проблемы )

Да, сейчас как никогда актуален вопрос "культура"  vs "культура в заложниках у $". Соблюсти этот баланс - тоже есть высокая культура, помойму :)

>Конечно если у нас код пишут 5 человек, а надо админить 1000 серверов, то на админство надо 10 чел

это кстати неправда. Количество серверов не масштабируется на количество людей. Масштабируются только неавтоматизированные проблемы.
i.e. при хорошем процессе на 1000 серверов может вообще не потребоваться админа, только разработчик для настроек облака и разработчик для деплоя/диагностики проблем

это был пример )) конечно не правдла. я знаю команду из 7 чел которая админит 5000 серверов )
просто цифры были взяты для наглядности

в этом и ошибка. Вы оправдываете неэффективный менеджмент размером команды, вместо рассмотрения проблемы out of box

короче, я бы подытожил так: каждая огранизация или менеджер по своему понимают, кто такой разработчик и какие у него должны быть обязанности в плане их состава. Если ваши ожидания совпадают с ожиданиями менеджера - это прекрасно.  Обратное - тоже не всегда плохо.

я предлагаю на это смотреть как на кейс, где коммуникация дороже самостоятельного решения

разбирать вопрос без конкретного кейса - будет слишком долго, весело и бестолково )

Ну вот у нас был кейс : Do I need DevOps