Comments 37
Тут и до всяких KPI дойти недолго, если обратный подход применять
Но я не уверен, что сложившееся у меня отношение к премии — это то, что ожидает руководство.
У нас ещё веселее. Сделал проект за 3 месяца (в 2 раза быстрее и в 2 раза меньшей командой, чем планировалось). Прошло 2 года, я уже уволиться успел, а проект всё ещё не закрыт и туда "подкидывают дровишек". Надо ли говорить, что никакой премии я так и не увидел? :-)
С домами всё чуточку не так, и если это ИЖС, то там налоги в течение десяти лет автоматом увеличатся в пять раз, по-моему.
Премию за сроки получает производство (применительно к ИТ — разработчики), а риски за эту скорость (скрытые дефекты) несёт эксплуатация у которой обычно никаких премий нет.
Просто из того, что эксплуатация это обычно операционные издержки с фиксированным бюджетом, а производство — нет (и тут может быть «недорасход бюджета»).
При этом у меня есть пример (это история не из ИТ) такая ситуация регулярно приводила к натуральному мордобою, когда премии уже распланированы, иногда даже потрачены, а приёмка изделия в эксплуатацию невозможна из-за наличия в изделии дефектов (ну или же полного отсутствия изделия как такового).
Премия за сдачу в срок скорее похожа на депремирование за несдачу, разве нет?
Кроме того, кто устанавливает сроки? Если от меня, как разработчика, беудет зависить определение сроков, что будет мне мешать постараться отодвинуть срок, чтобы уж точно не «депримировали»?
Мне кажется, другие критерии должны определять премии — качество, количество возвратов, к примеру.
Сейчас я скорее согласен с подходом, что премия вручается за успехи. Ну то если человек за год из 10 проектов все 10 сдал в срок — можно премировать за постоянное качество. Если занимался дополнительной деятельностью — проводил треннинги для новых сотрудников, изучал и презентовал новые технологии — ещё премия.
Ну и ещё можно вводить 13ую зарплату по итогам года, когда владельцы бизнеса делятся частью прибыли.
Премия за сдачу в срок скорее похожа на депремирование за несдачу, разве нет?
Мне кажется, что оттенок разный. Депремирование выглядит как наказание. Т.е. обычно ты получаешь X денег, а если проект сдашь не в срок, то X — k% денег. А наличие наказаний может негативно сказываться на лояльности сотрудников к компании, причем не важно попадал сотрудник под эти санкции или нет. Он будет помнить об этом.
что будет мне мешать постараться отодвинуть срок
Готовность заказчика заплатить указанную цену (как в денежном, так и временном эквиваленте). Если отказ заказчика от сотрудничества будет происходить часто, то скорей всего с таким сотрудником расстанутся. И адекватность сроков можно проверить, собрав не зависимую группу для оценки сроков.
качество, количество возвратов, к примеру
Количество параметров может начать расти как снежный ком, кто и как будет оценивать качество? Можно ли считать качественным продукт который соответствует указанной спецификации, но при этом абсолютно не расширяем? Если в процессе разработки программный продукт много раз возвращался на доработку разработчикам и в процессе эксплуатации ошибок найдено не было, то продукт качественный? И в конечном итоге, система оценки качества продукта может стать настолько запутанной, что проще будет "забить" на премию и делать как делается, без оглядки на премии.
Второй момент — после успешного или досрочного выполнения проекта, руководство может повышать планку (уменьшать сроки, увеличивать объемы). Тем самым делая стараясь получить отдачи больше за меньшие деньги.
Третий момент — провальный проект, далеко не всегда дело исполняющих сотрудников. Неправильные стратегические планы, выход на рынок, неправильная подготовка требований заказчиком и при этом соблюдения сроков, при этом как правило вина будет все равно на исполняющих сотрудниках — сделали недостаточно хорошо, приведет к демотивации — так как премии не будет, а сотрудники старались. Да или просто пообещал и не дал — после этого больше нет доверия к таким словам, и дальнейшая попытка стимулировать обещаниями уже ничего не даст.
Можно привести кучу примеров — и того что сотрудник может стараться быстрее все сдать и поставить галочку, и руководитель — чтобы максимально выжать подчиненных затратив меньше времени и т.д. Все это может привести как к плюсу так и к минусу. Всё должно быть тщательно просчитано — и все процессы хорошо отлажены.
А так конечно же, все мы за премию))). Сразу и побольше.
Оттуда: «Премии (или взятки) просто неэффективны на рабочем месте. Любой вид соревнований на рабочем месте, любая схема кнута и пряника, и даже старый трюк «поимки людей с поличным за деланием чего-то полезного с последующим награждением» — все они приносят больше вреда, чем пользы. Любая раздача пряников (например, церемониальное вручение мемориальных досок победителям соцсоревнования) подразумевает, что они работали, чтобы получить эту люситовую доску; то есть они не обладают достаточной самостоятельностью, чтобы работать не за пряник; это унизительно и обидно».
Премии неэффективны… Угу, пока, видимо, мы не говорим о руководстве и, особенно, топах. Для них почему-то премии не унизительны и эффективны.
Опять же зависит от конкретной компании и сферы.
Но почему-то это не подпадает под вышеуказанную цитату.
Наоборот, тьма материалов о премировании и премировании при хантинге топов, равно и про то, как рассчитать golden parachute.
Премии должны быть прозрачными. У всех, в том числе у топ.
ИМХО, премия должна даваться за то, что сделано сверх ТЗ (быстрые правки в срок) или за преодоление какого-то важного дедлайна по вине работодателя (увы, не редкость). Премия назначается индивидуально.
В случае постоянных премий за успешные проекты или по событиям (квартальная, годовая) — они начинают восприниматься частью денежной компенсации и действуют отрицательно в случае их невыплаты.
При этом нельзя забывать о том, что официальные премии — это ФОТ и их наличие влияет на размер отпускных и других выплат, а также с них платятся налоги как с ЗП.
А вот насчёт индивидуального премирования — не согласен. Отдел должен работать одной командой. Успех или неуспех должен быть общим. И премия тоже.
Да, мы все программисты и нам платят ЗП. Но мы, как программисты, отлично знаем, что то что планировалось в самом начале и то что получается в процессе разработки это достаточно часто разное! Как правило, выясняется очень много подводных камней, которые надо обходить, которые достаточно часто не обговаривались на стадии постановки задачи. Некоторые подводные камне вполне укладываются в рамки наших обязанностей, но также встречаются и те, что в список наших обязанностей не входит.
Вот и вопрос, если у меня есть навык сделать действие, которое приблизит к решеинию задачи и я могу это сейчас, то надо ли мне это делать? Я вполне могу сказать, что это не моя область и спихнуть на другого, в обязанности которого как раз и входит делать подобные вещи. Но при этом это будет отложено на неопределенный срок и поставить решение своей задачи на паузу до момента, когда смогу продолжить. Но могу и сделать это действие, тогда решение задачи будет получено быстрее! Потому что я еще помню контекст решаемой задачи и нахожусь в потоке.
Вот если меня не премировать, то зачем мне надо делать то, что входит в обязанности другого?
составляет большую часть з.п., которая в случае чего угодно может быть не выдана (такой вот инструмент держания сотрудников в повиновении)Поработал я в такой конторе. Руководитель руководить не умел совсем, а мне надоело сидеть там вечерами непонятно ради чего, и я просто стал уходить вовремя.
И вот в день зарплаты я узнал, что остался без премии, которая составляла треть зарплаты. Но мне как раз подвернулось новое место работы, и я написал заявление.
Цирк начался дальше — директор вернул мне премию, давил на опасность перебежек (чего в кризис будешь бегать, оставайся!), жаловался на то что новичка потом учить придётся. Заявление я, естественно, не забрал, и когда получил расчёт, снова недосчитался премии :)
А вы еще не платите премию за вовремя сделанные проекты?