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

V_S>>Забудь.
V_S>>Если программист — (со)владелец фирмы, то ему причитается доля прибыли пропорционально его доле в уставном капитале, независимо от всех остальных факторов. Если же программист — просто наемный служащий, то ему причитается зарплата — hourly rate, оклад..., поскольку он просто продает 8 часов своего времени в день работодателю за фиксированную цену, и насколько эффективно используются эти 8 часов — не его проблемы, а забота работодателя.

M>спасибо. теперь многое стало ясно в таком ракурсе.

Ну, еще можно добавить, что программистам можно давать премии по закрытию проекта. Есть разные схемы, вот одна:
Три доли — первая определяется финансовым результатом всей компании, вторая — вклад рабочей групы, третья — личный вклад (последние две вещи — субъективно).

Есть формализованный подход, который может применяться для рассчета премий для сотрудников — KPI. Это обширная тема, но можно упростить — сузим понятие KPI к предельно простой и тупой штуке — формуле рассчета премии. Это, наверное, неправильно, но зато просто и удобно. Примеры:

KPI для продавцов очень простой — процент от оборота.
KPI сисадмина — допустим, состоит из нескольких компонент (выдумываю на ходу — что для нас наиболее важно в его работе). Нет отказов сети и сервисов за месяц + 50 баксов. Нет задержек более дня по реакции на запросы пользователей — еще +100 баксов.

А вот для программистов KPI ввести непросто... Казалось бы, плотность дефектов найденных тестерами (меньше — лучше) — отличный KPI. Однако, он стимулирует программиста не браться за сложную и рискованную работу. KPI завязанный на продуктивность "строки в час" — стимулирует писать тонны кода, не особо думая о дизайне. Точность планирования — стимулирует людей отказываться от задач с высокими рисками, и выбирать "дубовые", но предсказуемые подходы. Короче, науке не известен хороший KPI для инженера, который не имел бы вредной оборотной стороны.

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