и все эти люди (если они профи) предпочитают не решать а координировать процесс сбора требований с внутренних заказчиков и утряски их с командой

слово-то какое ловкое, "координировать"

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

Всех надо сажать на процент и маленькую получку, только что бы с голоду не померли

быстро кандидаты кончатся

Чем выше должность тем жёстче, вон некоторые цео с 1 долларом живут и ок

ты предприниматель, ты риски и бери

Координировали-координировали, да не выкоординировали. Это все потому что госта у них свежего не было. Все по ТУ.

Чем выше должность тем больше должно быть предпринимательского духа

а некоторые цео миллионы получают, пойди разберись, кто лучше руководит

ну, если 1 бакс в качестве оклада назначить, тут-то сразу дух предпринимательский и заведется

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

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

выкатывать без простоя - не?

Колбасный принцип: Тем, кто любит колбасу и хостится в облаке, не стоит видеть, как делается то и другое

Почему не работают спринты?

Если в одном (или двух или даже нескольких) чатиках про техдирство/ техлидство/ тимлидство сказать слово "agile" или, упаси боже "скрам", сразу прибегает толпа свидетелей бесполезности спринтов и в подробностях рассказывает ужасы о сектантах скрама, эффективных менеджерах и закидывают ссылками на то, как они убили целый бизнес.

Начинаем разбираться, как они готовили ЭТО. У них есть спринты - обычно 2х-недельные и иногда 3х-недельные. На планировании берётся пачка задач из беклога. Демо и ретро обычно нет - времени на это нет. Ну зачем демо, если на прод выкатили и так всё видно. А на ретро пробовали пару раз, - всё что надо сказали, больше говорить нечего.  Пользы особо нет, - так зачем тогда всё это? А на серьёзных проектах так не то, что пользы, - сроки так и так утекают.

Да? Всё вот так вы себе представляете? Тут есть пара ключевых неточностей, которые постоянно ускользают от внимания уважаемых зубров разработки.

Скрам и agile - это история не про смузи, а спринты - это не про календарь. Спринт - это заранее сформулированное бизнес-языком измеримое улучшение продукта.

Это не "возьмём в спринт 100500 задач из беклога и попытааемся сделать, сколько успеем". Это про вполне структрированный список вида:

1. Запустить новый платёжный шлюз
2. Уменьшить скорость suggest поиска с 3 секунд до 1 секунды
3. Согласовать с product-owner-ом окончательный вид интерфейса анкеты кредитования

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

Чувствуете? Спринт - это про прозрачность того, к чему бежим. И в начале сразу понятно - всё ли сделали, чтобы добежать?

А в конце демо - показываем, что прибежали. И ретро - разбираемся, что делать, чтобы снять все те блокеры, что мешают работать!

Ну да, описал все плохие стороны скрама. Медленно, неэффективно и только для простых задач и для проектов без пользователей.

Это эмоции, а не аргументы) Давай фактуру!  От краткосрочного планирования, как инструмента «последней мили», требовать долгосрочных решений мне кажется не стоит.

Ну, смотри.
1. В спринт упаковываются уже задачи с точной оценкой. Значит есть отдельно задачи на точную оценку (ещё один спринт), так что в скраме time-to-market по твоему описанию не меньше трёх спринтов (декомпозиция, реализация, правка по результатам демо).
2. Но уже тут процесс не работает, так как декомпозиция и доработки не могут быть целью спринта.
3. Точные оценки - это только для простых задач. Для чего-нибудь сложного их не бывает.
4. Только про задачи без зависимостей. Тот же 'запустить шлюз' не может быть задачей спринта, там 90% времени уходит на внешние коммуникации, а не на написание кода.
5. Откладывание проблем на ретро - лучший способ забить на них.

6. Ну и багфикс в классический скрам не влезает, это не цель спринта )