Здравствуйте, enji, Вы писали:

E>Спасибо за развернутый ответ. Хотелось бы узнать еще пару моментов
E>* Если Петя — юниор, а Миша — сеньор — они все равно получат 50 и 20%? Или есть какие-то коэффициенты?

Да, все нюансы я не писал, у нас целый большой алгоритм все считает.
Суть какая — менеджер проекта + директор по качеству в конце проекта ставят оценки всем участникам. 1 — работал как ожидается. Можно поставить 1.2 (можно любое число) — тогда доля человека в премиальном фонде увеличится на 20%. Может поставить 0.5 — тогда премия человека уменьшится в 2 раза, а остаток соответственно распределиться по остальным участникам. По сути эти оценки просто перераспределяют премию между участниками, тогда как общая премия проекта не меняется.
По факту практчиески никогда оценки не ставят, у всех 1. Но если кто-то проштрафился — ему могут поставить и 0.7 и даже 0.4. Или если кто-то хардкорил, работал по ночам, ему могут поставить даже 2. Все подобные оценки я лично одобряю/заворачиваю, чтобы не было несправедливостей особых.

Так вот, юниорам система автоматом ставит оценку 0.25. Когда их переводят в категорию не юниоров, то уже оценка по умолчанию становится 1.


E>* Как быть с поддержкой? В продукте обнаружена бага — как это учитывается? Все доработки — по отдельной смете, как отдельный проект?

Проекты поддержки у нас тоже — отдельные проекты. Прелесть в том, что за поддержку клиенты платят хорошие деньги, и там обычно кроме самой поддержки еще и много доработок за деньги.
Вот и получается, что например клиент платит 40 тыс.р. в мес поддержку + потратил за полугодие 1 млн. на доработки. Из этих 1.24 млн и считается премия, за вычетом себестоимости. Собственно багфиксы просто увеличивают себестоимость.

E>Наша ситуация — встроенное и обслуживающее ПО для оборудования, т.е. самостоятельной ценности оно не имеет. При этом обычно ПО пишется и потихоньку совершенствуется, продаются новые экземпляры оборудования. Как бы ты считал "деньги полученные от клиента" в таком случае? Это некий аналог вашего проекта развития? Но как считается его смета — т.е. начальство заинтересовано премии по нему снизить, программисты — завысить?

Ну да, это аналог нашего проекта развития. Я бы считал так. Скажем на выпуск новой версии нужно (допустим) 5000 часов. Собственно у нас это было бы аналог 12 млн.р., полученных от клиента. Этот бюджет проекта я бы и вбил в систему.
Тут ключевое — это правильно спланировать трудозатраты.

Здравствуйте, enji, Вы писали:

E>Спасибо за развернутый ответ. Хотелось бы узнать еще пару моментов
E>* Если Петя — юниор, а Миша — сеньор — они все равно получат 50 и 20%? Или есть какие-то коэффициенты?

Да, все нюансы я не писал, у нас целый большой алгоритм все считает.
Суть какая — менеджер проекта + директор по качеству в конце проекта ставят оценки всем участникам. 1 — работал как ожидается. Можно поставить 1.2 (можно любое число) — тогда доля человека в премиальном фонде увеличится на 20%. Может поставить 0.5 — тогда премия человека уменьшится в 2 раза, а остаток соответственно распределиться по остальным участникам. По сути эти оценки просто перераспределяют премию между участниками, тогда как общая премия проекта не меняется.
По факту практчиески никогда оценки не ставят, у всех 1. Но если кто-то проштрафился — ему могут поставить и 0.7 и даже 0.4. Или если кто-то хардкорил, работал по ночам, ему могут поставить даже 2. Все подобные оценки я лично одобряю/заворачиваю, чтобы не было несправедливостей особых.

Так вот, юниорам система автоматом ставит оценку 0.25. Когда их переводят в категорию не юниоров, то уже оценка по умолчанию становится 1.

Есть еще нюансы. Опять же, полезные. Например, скажем, себестоимость часа Васи — 1000р. Но если он работал в этом месяце не 184 часа а 200 часов, то стоимость его часа для компании будет 920 рублей (снизится) а вклад в проект наоборот увеличится (все 200 часов, а не 184 часа). Это приводит к косвенной оплате переработок по сути через систему премий, т.к. мы явно переработки не оплачиваем.


E>* Как быть с поддержкой? В продукте обнаружена бага — как это учитывается? Все доработки — по отдельной смете, как отдельный проект?

Проекты поддержки у нас тоже — отдельные проекты. Прелесть в том, что за поддержку клиенты платят хорошие деньги, и там обычно кроме самой поддержки еще и много доработок за деньги.
Вот и получается, что например клиент платит 40 тыс.р. в мес поддержку + потратил за полугодие 1 млн. на доработки. Из этих 1.24 млн и считается премия, за вычетом себестоимости. Собственно багфиксы просто увеличивают себестоимость и снижают премию.

E>Наша ситуация — встроенное и обслуживающее ПО для оборудования, т.е. самостоятельной ценности оно не имеет. При этом обычно ПО пишется и потихоньку совершенствуется, продаются новые экземпляры оборудования. Как бы ты считал "деньги полученные от клиента" в таком случае? Это некий аналог вашего проекта развития? Но как считается его смета — т.е. начальство заинтересовано премии по нему снизить, программисты — завысить?

Ну да, это аналог нашего проекта развития. Я бы считал так. Скажем на выпуск новой версии нужно (допустим) 5000 часов. Собственно у нас это было бы аналог 12 млн.р., полученных от клиента. Этот бюджет проекта я бы и вбил в систему.
Тут ключевое — это правильно спланировать трудозатраты. Конфликт интересов конечно есть, но если руководители хотят создать действующую систему мотивации то найдут правильный баланс.