зависит от... Утрированный пример: выкатили что-то на прод и есть опасения что будут ошибки и нужно будет среагировать. Разработчик занят, делает другую функциональность и сможет среагировать с задержкой (часы, дни). Лучше, чтобы он сидел и ждал (условно, ничего не делая), но в случае необходимости сразу бы подключился к решению проблем. Пример синтетический, но, думаю, мысль понятна

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

Никто и не спорит с тем, что серебрянной пули нет.

А что делать с утверждением, что из максимальной эффективности каждого элемента системы не следует максимальная эффективность системы в целом?

смириться с этим утверждением

Это более верно для производства табуреток

Обычно имеет смысл на 'основную деятельность' брать узких специалистов. А на побочную - универсалов. Ну и аутсорсить )

А какие-то аргументы будут? Контрпримеры?

Ни одно из этих утверждений никак не связано с требованием к универсальности. И не является абсолютным благом.

+ это и хотел написать)

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

Я конечно не говорю о действительно табуреточных задачах, типа там вебсервисы пилить массово )

Думать - это как раз профильный процесс. А фигово тестировать вместо QA - непрофильный.

Мы исходим из разных ценностей, потому бесперспективно обсуждать, оба варианта работают.  Для меня сотрудник это не только  компетенция и часы в проекте. Это мне напомнило откуда то спертое:

В чем разница между проджектом и продактом?

1. Проектный подход — фокусировка на том, что должны сделать мы. Что? За какой срок? С какими ресурсами?

2. Продуктовый подход — фокусировка на том, что должны получить другие. Что наш пользователь должен суметь сделать? С каким качеством? Насколько просто?

3. Проджекты обычно просирают задачи пользователей. Продакты — намеченные планы.

И мы отклонились от темы чата)

И те, и другие практически бесполезны, когда в дело вступает ArchOps.

Это который ещё и на дуде?

А расскажите, что вы знаете про архопс?

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

+++

Долго. Дорого. Охуенно.