Привязка оплаты к результату - как вариант - оценкой PM произв. команде за спринт, влияющей на премиальную часть доходов.

Всем привет.

Кейс такой: разработчик уровня senior и с ним teamlead. Дают оценки с рисками закладываясь-перезакладываясь и все равно не попадают в оценки. По результатам оказывается тут забыли сказать, там забыли сделать и под передачу в qa оказывается что часть функционала вообще не раьочая и нужно доп время. Скоуп не меняется:). Частыми статусами вопрос не решается.

Цель: попадать в оценки, увеличить качество продукта.

Кто как решает такие проблемы?:) поделитесь

Всем привет.

Кейс такой: разработчик уровня senior и с ним teamlead. Дают оценки с рисками закладываясь-перезакладываясь и все равно не попадают в оценки. По результатам оказывается тут забыли сказать, там забыли сделать и под передачу в qa оказывается что часть функционала вообще не раьочая и нужно доп время. Скоуп не меняется:). Частыми статусами вопрос не решается.

Цель: попадать в оценки, увеличить качество продукта.

Кто как решает такие проблемы?:) поделитесь

Есть такая практика как принятие/непринятие списанных на проект трудозатрат решением PM.
Мое личное мнение - перерасход 10% - норм., до 15% - нехорошо, потрудитесь объяснить, wtf, что сверх - не принимаю, и точка.
Да, и в любом случае сообщайте о превышении до, а не после.
Бывают ситуации, когда производственная команда делает группу задач, ну тогда можно заключать пакетное соглашение - всего потратьте столько-то, а если здесь больше, там меньше, это без разницы.

В заказной разработке ПО превышение трудозатрат на 10% - это замечательный результат.

А зачем вам попадать в оценки и почему не меняется скоуп?

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

Спринт? А в кейсе разве сказано что работают спринтами?

Попадать в оценки = попадать в бюджет. Он не рещиновый. Продукт для внешнего заказчика. Бизнес-модель не готов озвучивать:)

Попадать в оценки = попадать в бюджет. Он не рещиновый. Продукт для внешнего заказчика. Бизнес-модель не готов озвучивать:)

Кто помешает домыслить... 😊😊

Есть такая практика как принятие/непринятие списанных на проект трудозатрат решением PM.
Мое личное мнение - перерасход 10% - норм., до 15% - нехорошо, потрудитесь объяснить, wtf, что сверх - не принимаю, и точка.
Да, и в любом случае сообщайте о превышении до, а не после.
Бывают ситуации, когда производственная команда делает группу задач, ну тогда можно заключать пакетное соглашение - всего потратьте столько-то, а если здесь больше, там меньше, это без разницы.

Не готовы модель, озвучьте ваш внутренний производственный процесс.

Я правильно понимаю, у вас жесткая «цеховая» структура. Цех аналитиков, цех UI/UX, цех разрабов, цех qa. То есть реальной кросс-функциональной команды нет?

Ну вот они не попадают и могут на 50% увеличить трудозатраты. Принять/не принять - ок. В нашей компании такая практика тяжело идет. Приходится на уровне команды разруливать ситуациб «попадания в оценки»

Спринт? А в кейсе разве сказано что работают спринтами?

Про модель Киневин слышали? Может проблема что вы «не в том домене»?

Это скорее не домысел, а ценный совет.  Например, работать по спринтам в кроссфункциональной команде. Короче, заметить скрам или подобие.

Отделы да. Из отделов выделяются специ в команду проекта

Обычная водопадная модель.