А как же KPI менеджера, который не смог спланировать трудозатраты, что пришлось "спасать" проект? Его же за это по головке не гладят

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

Скорее не так: в скраме загрузка специалистов неравномерна

это ведь не троллинг? Менеджер в проекте живёт от договора до договора - ему нужно договор закрывать с одной стороны, а с другой стороны приносить необходимую прибыль. Так вот он овертаймы скорее всего закладывает в бюджет (как риски - ведь всё равно нужно будет овертаймить - эта штука всем понятная - и заказчку, и боссам). Поэтому менеджер как правило гонит сроки и экономию бюджета (отсюда редкие RnD  в проекте, прототипы и прочее). И это не только госовые проекты. Просто в негосовых ещё более жёстко с бюджетами 😊.

Не видел в природе таких KPI

+

Хм, но Time-to-market в скраме как раз фиговый, минимум три спринта от задачи до деплоя.

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

кстати, вот какая мысль пришла в голову -  на около технических конференция бывают доклады из разряда как продать бизнесу <какая-то штука, которая более менее понятна технарям или около> (рефакторинг, архитектура, код-ревью, автотесты).
Вот хорошо, если бы на около бизнес конференциях были выступления на тему "как купить у технаря не кота в мешке" 😊

А какие вы встречали kpi у менеджеров?

По степени утилизации, например

ну да, но интересно было бы понять, а сколько реально проектов (или серий проектов, если первые проекты - это инвестиции) (в процентном соотношении) выходят с нулевой прибылью). В моей практике почти не было таких (опять же если проценты смотреть - это на вскидку что-то около 5%)

А как вы делите, что вот это - инвестиция, а это - проект, который должен приносить прибыль? Тогда надо смотреть не прибыль по конкретному проекту, а прибыль по всей серии.

А что такое прибыль? Если аутсорс разработка на заказ, то понятно. А если инхаус продуктовая разработка?

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

Я переадресую вопрос к Евгению

Мне как-то пытались придумать такой хитрый KPI, чтобы с одной стороны бизнес любил ИТ и с горячей любовью о нас отзывался, а с другой стороны, не давать бизнесу раздувать бюджет на разработку, если денег в продукте не видно. Изложил близко к оригинальной постановке.

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

Посыл такой - если ИТ тратит много денег, а бизнес не зарабатывает, бизнес придумает миллион причин, почему виновато ИТ.

Имел дело и с тем и с другим)