А вы еще не платите премию за вовремя сделанные проекты?

    Беседовал я как-то с техническим директором одного из крупнейших банков России. В какой-то момент речь у нас зашла о премировании сотрудников. Тогда я ему говорю, что у нас в компании есть премирование сотрудников за вовремя сделанные проекты и задачи. Тут он завис секунд на пять, долгое молчание, недоумение в глазах:
    – Кхм… Так за это же программистам зарплату платят! – говорит он.
    – Да, платят. Но если изучить статистику успешных проектов в IT, становится грустно и хочется платить премию за выполненные в срок задачи.

    Попрощались мы, так и не придя к общему мнению по этому вопросу. В этой статье я и предлагаю разобраться, следует ли платить премию программистам за вовремя сделанные задачи и проекты. И вообще, когда стоит платить премии.

    Итак, еще Том Демарко и Тимоти Листер в своей известной книге «Человеческий фактор: успешные проекты и команды» указывали:

    Начиная с 1977 года мы ежегодно проводили исследования проектов разработки и анализ их результатов. … Около 15% всех проектов закончились ничем – были отменены, прерваны, отложены или их результатом стали никому не нужные продукты. В случае крупных проектов картина еще хуже – крах постиг 25% проектов.

    Вы можете сказать: «Ок, но это когда было! Сейчас все изменилось!»

    Согласно исследованиям The Standish Group только треть ИТ-проектов в последние годы заканчивается успешно. Статистика успешности ИТ-проектов приведена в таблице ниже:

    image

    Успешные проекты – проект сделан в рамках тройного ограничения, т.е. все цели проекта достигнуты в плановый срок и бюджет.

    Провальные проекты – проекты, остановленные без получения результата, то есть, по сути, деньги потрачены зря.

    Спорные проекты – те проекты, которые были завершены либо с превышением сроков, либо стоили дороже, чем планировалось, либо достигли лишь части целей.


    «Ок», – скажете вы, – «но это же большие проекты, а не задачи, которые делает один разработчик».

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

    Вы все еще не хотите платить премии разработчикам?

    По оценкам той же The Standish Group на так называемые «провальные» проекты потрачено $120 млрд. Если добавить еще перерасход бюджета спорных проектов, то получатся космические $200 млрд. Да это же 1/7 ВВП России за 2015 год или ВВП Португалии (список стран по ВВП).

    Надеюсь, что у вас более не осталось сомнений.

    Далее рассмотрим общие рекомендации по выплате премий.

    Избегайте премий, которые выплачиваются регулярно, например, квартальные премии. Любая периодичность сводит мотивационный эффект от премии на ноль. Причина этого проста – сотрудник ожидает премию, она не является для него сюрпризом, он не испытывает положительных эмоций при ее получении. Такая премия воспринимается как само собой разумеющееся и деньги распланированы уже за месяц до получения.
    У меня даже случай был, когда после объединения отделов, ко мне пришел новый сотрудник и спросил:
    – А квартальная премия в этом месяце будет, как обычно?
    – Какая квартальная премия?
    – Ну, которая платится в конце квартала.
    – Ты же уже получил премию за проект в прошлом месяце.
    – А квартальная?
    В общем, это было для сотрудника неожиданно, но он скоро привык к новым правилам.

    Разумно, если премию назначает непосредственный руководитель сотрудника. Ведь только он и знает о реальных достижениях сотрудника. Бывает так, что сверху спускают премию всему отделу, без учета, кто чего достиг и сделал в отдельности. Тогда перед руководителем два варианта: либо просто выдать премию без мотивационного посыла либо искать конкретно для каждого сотрудника, почему выплатили премию.

    Премию следует выдавать сразу, например, разработал программист крутую фичу качественно и вовремя – получи премию в конце месяца. Не нужно ждать окончания квартала, поощрение должно проходить, чтобы четко прослеживалась обратная связь.

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

    А у вас в компании за что платят премии?
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 37
    • +3

      Тут и до всяких KPI дойти недолго, если обратный подход применять

      • +4
        Премию следует выдавать сразу… чтобы четко прослеживалась обратная связь
        Выглядит как «чтобы чётко вырабатывался условный рефлекс»
        • +4
          Мне кажется это из той же области, почему игры «цепляют» — ты выполнил задание и тут же получил награду, это стимулирует выполнить и следующее задание. Условный рефлекс — пусть будет условный рефлекс, главное, чтобы все — и заказчик, и исполнитель, и посредник остались довольны друг другом.
        • +5
          +1 за «Премию следует выдавать сразу». У нас в компании есть проектные премии, но выплачиваются они после завершения проекта. Часто возникает ситуация, когда свою часть работы сделал, а до завершения проекта еще не скоро. А по прошествии полугода, я уже не могу вспомнить, что там было (можно конечно посмотреть какие задачи были в проекте, какие ты закрыл и восстановить картину, но лень) и просто воспринимаю это как приятную неожиданность :)
          Но я не уверен, что сложившееся у меня отношение к премии — это то, что ожидает руководство.
          • +1

            У нас ещё веселее. Сделал проект за 3 месяца (в 2 раза быстрее и в 2 раза меньшей командой, чем планировалось). Прошло 2 года, я уже уволиться успел, а проект всё ещё не закрыт и туда "подкидывают дровишек". Надо ли говорить, что никакой премии я так и не увидел? :-)

            • +4
              Как соотносится «сделал» и «еще не закрыт»?
              • 0
                Надо полагать, примерно так же, как в свое время минимизировали налоги на жилую собственность, когда дом по факту использовался по назначению, но считался не сданным в эксплуатацию по формальным признакам (грубо говоря, не установлен предусмотренный проектом шпингалет).
                • 0
                  Скорее всего, как у нас. Нехотя утвердили ТЗ, по которому расписано что и как. Указаны сроки. Делаешь в три раза быстрее, так как просят это сделать. На выходе имеем: затраченное время и… 100500 просьб доработать то и это, что не было оговорено никак в ТЗ. Вот и получается, что сдано и эксплуатируется, но не закрыт.

                  С домами всё чуточку не так, и если это ИЖС, то там налоги в течение десяти лет автоматом увеличатся в пять раз, по-моему.
                  • 0
                    А у нас уже третий год по ТЗ сделать не могут, второй год как эксплуатация идет, наконец-то до версионости доползли.
                    Причем программистам задачи уже полгода как ставим напрямую мы, заказчики. Еще раз: напрямую. То есть вот так и так делаем версионость, вот такие таблицы добавляем, вот такие столбцы в старых…
          • +6
            Есть интересный кейс который я много где замечал, в т.ч. (и особенно!) не в IT:
            Премию за сроки получает производство (применительно к ИТ — разработчики), а риски за эту скорость (скрытые дефекты) несёт эксплуатация у которой обычно никаких премий нет.
            Просто из того, что эксплуатация это обычно операционные издержки с фиксированным бюджетом, а производство — нет (и тут может быть «недорасход бюджета»).
            При этом у меня есть пример (это история не из ИТ) такая ситуация регулярно приводила к натуральному мордобою, когда премии уже распланированы, иногда даже потрачены, а приёмка изделия в эксплуатацию невозможна из-за наличия в изделии дефектов (ну или же полного отсутствия изделия как такового).

            • +1
              Не хватает статистики уровня: «в случае если существуют премия за соблюдение сроков, уровень успешности проектов на ХХ% больше».
              Премия за сдачу в срок скорее похожа на депремирование за несдачу, разве нет?
              Кроме того, кто устанавливает сроки? Если от меня, как разработчика, беудет зависить определение сроков, что будет мне мешать постараться отодвинуть срок, чтобы уж точно не «депримировали»?

              Мне кажется, другие критерии должны определять премии — качество, количество возвратов, к примеру.
              • +1
                Добавлю. Премирование — очень больная тема. Я помнювремена, когда годовая премия могла равняться 6-12 зарплатам для программистов. Но те времена прошли.
                Сейчас я скорее согласен с подходом, что премия вручается за успехи. Ну то если человек за год из 10 проектов все 10 сдал в срок — можно премировать за постоянное качество. Если занимался дополнительной деятельностью — проводил треннинги для новых сотрудников, изучал и презентовал новые технологии — ещё премия.
                Ну и ещё можно вводить 13ую зарплату по итогам года, когда владельцы бизнеса делятся частью прибыли.
                • +1
                  Премия за сдачу в срок скорее похожа на депремирование за несдачу, разве нет?

                  Мне кажется, что оттенок разный. Депремирование выглядит как наказание. Т.е. обычно ты получаешь X денег, а если проект сдашь не в срок, то X — k% денег. А наличие наказаний может негативно сказываться на лояльности сотрудников к компании, причем не важно попадал сотрудник под эти санкции или нет. Он будет помнить об этом.


                  что будет мне мешать постараться отодвинуть срок

                  Готовность заказчика заплатить указанную цену (как в денежном, так и временном эквиваленте). Если отказ заказчика от сотрудничества будет происходить часто, то скорей всего с таким сотрудником расстанутся. И адекватность сроков можно проверить, собрав не зависимую группу для оценки сроков.


                  качество, количество возвратов, к примеру

                  Количество параметров может начать расти как снежный ком, кто и как будет оценивать качество? Можно ли считать качественным продукт который соответствует указанной спецификации, но при этом абсолютно не расширяем? Если в процессе разработки программный продукт много раз возвращался на доработку разработчикам и в процессе эксплуатации ошибок найдено не было, то продукт качественный? И в конечном итоге, система оценки качества продукта может стать настолько запутанной, что проще будет "забить" на премию и делать как делается, без оглядки на премии.

                • +3
                  Есть несколько подводных камней — если объем премии для сотрудника определяет его руководитель, то количество подлиз сразу увеличится. Очень часто процесс распределение премий не всегда объективный. Поэтому без объективной оценки могут быть демотивированы хорошие специалисты.
                  Второй момент — после успешного или досрочного выполнения проекта, руководство может повышать планку (уменьшать сроки, увеличивать объемы). Тем самым делая стараясь получить отдачи больше за меньшие деньги.
                  Третий момент — провальный проект, далеко не всегда дело исполняющих сотрудников. Неправильные стратегические планы, выход на рынок, неправильная подготовка требований заказчиком и при этом соблюдения сроков, при этом как правило вина будет все равно на исполняющих сотрудниках — сделали недостаточно хорошо, приведет к демотивации — так как премии не будет, а сотрудники старались. Да или просто пообещал и не дал — после этого больше нет доверия к таким словам, и дальнейшая попытка стимулировать обещаниями уже ничего не даст.
                  Можно привести кучу примеров — и того что сотрудник может стараться быстрее все сдать и поставить галочку, и руководитель — чтобы максимально выжать подчиненных затратив меньше времени и т.д. Все это может привести как к плюсу так и к минусу. Всё должно быть тщательно просчитано — и все процессы хорошо отлажены.
                  А так конечно же, все мы за премию))). Сразу и побольше.
                  • 0
                    У Джоэля Спольски есть статья «О вреде премирования».
                    Оттуда: «Премии (или взятки) просто неэффективны на рабочем месте. Любой вид соревнований на рабочем месте, любая схема кнута и пряника, и даже старый трюк «поимки людей с поличным за деланием чего-то полезного с последующим награждением» — все они приносят больше вреда, чем пользы. Любая раздача пряников (например, церемониальное вручение мемориальных досок победителям соцсоревнования) подразумевает, что они работали, чтобы получить эту люситовую доску; то есть они не обладают достаточной самостоятельностью, чтобы работать не за пряник; это унизительно и обидно».
                    • 0
                      «мемориальная доска победителя соцсоревнования» и вознаграждение выраженное в денежном эквиваленте это немного разное. Ну и хотелось бы в кратце о вреде прочесть, раз уж упомянули.
                      • +1

                        Премии неэффективны… Угу, пока, видимо, мы не говорим о руководстве и, особенно, топах. Для них почему-то премии не унизительны и эффективны.

                        • 0
                          У топов, как и у продавцов, иная система мотивации, не как у программистов.
                          Опять же зависит от конкретной компании и сферы.
                          • 0
                            А почему? Берем какого-нибудь VP of engineering, который бок о бок с программистами в общем-то будет жить и работать, договариваться с командами, внедрять стандарты, процессы. И премии, чаще всего, у него будут. И за сдачу проекта качественно в том числе.
                            Но почему-то это не подпадает под вышеуказанную цитату.
                            Наоборот, тьма материалов о премировании и премировании при хантинге топов, равно и про то, как рассчитать golden parachute.
                      • +1

                        Премии должны быть прозрачными. У всех, в том числе у топ.

                        • 0
                          Прозрачное — это то, что невидимо?
                        • +2
                          Крайне сложный вопрос, на самом деле. Причём со многих сторон: психологической, мотивационно-лояльной и юридической.

                          ИМХО, премия должна даваться за то, что сделано сверх ТЗ (быстрые правки в срок) или за преодоление какого-то важного дедлайна по вине работодателя (увы, не редкость). Премия назначается индивидуально.

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

                          При этом нельзя забывать о том, что официальные премии — это ФОТ и их наличие влияет на размер отпускных и других выплат, а также с них платятся налоги как с ЗП.
                          • 0
                            Любой инструмент (в данном случае премии) нужно использовать умело.

                            За комментарий спасибо, поставил плюсик!
                          • +1
                            Размер и наличие премии зависит от жадности работодателя. Был опыт работы в режимего нон-стоп в течение 10 месяцев, ввиду обстоятельств непреодолимой силы (покупка работодателем 2-х сопоставимых с ним бизнесов в течение 2 месяцев). Были жуткие по моим текущим меркам переработки, я работал по 60 часов в неделю. При этом я был на окладе и когда по успешному завершению проекта я попросил премию в размере 3-х окладов — мне ее выплатили, но предупредили, чтобы такие расходы я согласовал до начала проекта. Других проектов у этого работодателя у меня больше не было.
                            • +1
                              Насчёт установки прямой связи «повышенный результат -> премия» верно. Народ за хорошую работу должен сразу получить хорошую награду.

                              А вот насчёт индивидуального премирования — не согласен. Отдел должен работать одной командой. Успех или неуспех должен быть общим. И премия тоже.
                              • 0
                                Не всегда это возможно. Все люди индивидуальны. Кто-то сейчас в некой апатии\депрессии и делает работу столько, чтоб не стыдно было ЗП получать, а кто-то наоборот решил с головою уйти в работу.
                              • +1
                                Конечно, нужно премировать за во время полученный результат.

                                Да, мы все программисты и нам платят ЗП. Но мы, как программисты, отлично знаем, что то что планировалось в самом начале и то что получается в процессе разработки это достаточно часто разное! Как правило, выясняется очень много подводных камней, которые надо обходить, которые достаточно часто не обговаривались на стадии постановки задачи. Некоторые подводные камне вполне укладываются в рамки наших обязанностей, но также встречаются и те, что в список наших обязанностей не входит.

                                Вот и вопрос, если у меня есть навык сделать действие, которое приблизит к решеинию задачи и я могу это сейчас, то надо ли мне это делать? Я вполне могу сказать, что это не моя область и спихнуть на другого, в обязанности которого как раз и входит делать подобные вещи. Но при этом это будет отложено на неопределенный срок и поставить решение своей задачи на паузу до момента, когда смогу продолжить. Но могу и сделать это действие, тогда решение задачи будет получено быстрее! Потому что я еще помню контекст решаемой задачи и нахожусь в потоке.

                                Вот если меня не премировать, то зачем мне надо делать то, что входит в обязанности другого?
                                • 0
                                  Такие вещи необходимо согласовывать с непосредственным руководителем. Если это выходит за рамки вашей работы по проекту и некому это перепоручить, то он должен дать добро на вашу дополнительную работу, которая оплачивается отдельно. Вот только это будет не премия.
                                  • +1
                                    Да, если это крупные действия. А если мелкие? А сколько в нашей профессии мелочей? Которые вроде пустяшные, но когда их очень много, то это уже далеко не пустяк! Нужно отчетливо понимать, где можешь справиться и без указки сверху, а где действительно нужно уведомить начальство.
                                • 0
                                  Есть еще вариант, когда пообещали премию, но не дали. Начальство заявило, что если запустим новый функционал до нового года, то выпишут премию. Мы сами хотели закончит эту крупную задачу, выкатили за две недели до нг.
                                  • 0
                                    Тут тоже вопрос интересный. Хотя, на мой не совсем уж профессиональный взгляд, это похоже на попытку убийства мотивации к следующим проектам в сложившейся команде.
                                  • 0
                                    Особо-то большую не ожидали, но до сих пор как-то неприятно.
                                    • 0
                                      О премии нужно договариваться заранее, до начала проекта.
                                      • +1
                                        Мне платят премию, за вовремя сданную спецификацию с приемлемым качеством. Что кстати подняло уровень наших услуг. Премия уходит команде полностью.
                                        • +1
                                          Пока одни жалуются на нерегулярную/необоснованную премию, у других она составляет большую часть з.п., которая в случае чего угодно может быть не выдана (такой вот инструмент держания сотрудников в повиновении). В целом, все это, на мой взгляд — пустая суета, ведь в работе намного более важную роль играют интересные проекты, адекватные коллеги и начальство, стабильность. И слишком мало где все это есть, чтобы так беспокоиться по поводу такого второстепенного вопроса, как премирование.
                                          • 0
                                            И да, у нас в компании премия — просто ежемесячная надбавка к з.п., варьирующаяся от 0 до 255% (видимо чтобы ровно в один байт влезала).
                                            • +1
                                              составляет большую часть з.п., которая в случае чего угодно может быть не выдана (такой вот инструмент держания сотрудников в повиновении)
                                              Поработал я в такой конторе. Руководитель руководить не умел совсем, а мне надоело сидеть там вечерами непонятно ради чего, и я просто стал уходить вовремя.
                                              И вот в день зарплаты я узнал, что остался без премии, которая составляла треть зарплаты. Но мне как раз подвернулось новое место работы, и я написал заявление.
                                              Цирк начался дальше — директор вернул мне премию, давил на опасность перебежек (чего в кризис будешь бегать, оставайся!), жаловался на то что новичка потом учить придётся. Заявление я, естественно, не забрал, и когда получил расчёт, снова недосчитался премии :)

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.