Задача о премировании: почувствуй себя менеджером

Комментарии 33

  • 294bd2a69629401ff1c7a2d8290980f8_small.j

    10.09.17 в 14:15

    +1

    А можно опрос добавить опрос? Было интересно посмотреть статистику.

    • 10.09.17 в 14:39

      0

      Спасибо за полезное предложение, добавил

  • 10.09.17 в 14:25

    +10

    Нет, вторую команду не стоит премировать, руководствуясь данным правилом.
    Правило, правда, не слишком честное: новые продукты почти всегда более рискованные, менеджменту следует доработать правила премирования и учесть риски проекта при премировании, проведя SWOT-анализ проекта перед тем, как за него взяться.
    Однако, если руководство считает себя справедливым и сотрудники ценят это качество, следует выписать особую благодарность второй команде, вне стандартных правил премирования.
  • dd2fb9970ed380bfa47be704419adadb_small.j

    10.09.17 в 14:52

    +4

    Пункты 1 и 2 друг другу противоречат, судя по всему компания уделяет большое внимание соблюдению сроков и бюджетов проектов, а не мотивации

    • 10.09.17 в 15:10

      0

      Пункты 1 и 2 друг другу противоречат

      Менеджмент компании не разделял с вами эту точку зрения.

  • 8f2d7857e26384af36e7ae12b54316f4_small.j

    10.09.17 в 15:02

    +3

    Это история про MS Word, довольно известная
    • 10.09.17 в 15:09

      0

      Нет, но полагаю, что под рамки задачи подходит много реальных историй

    • 10.09.17 в 22:13

      +1

      А можно ссылочку на историю

    • 10.09.17 в 22:49

      0

      Подскажите пожалуйста, что за история

  • ec85acdf2c30aec871cbae9ddea1e59a_small.j

    10.09.17 в 15:04

    +6

    Да стоит, они вполне её заслужили.
    То что бюджет выше и сроки провалены, так это недоработка менеджера проекта, вот его премию можно им и отдать :)

    Хотя если решили демотивировать, то можно и не дать, но такие эксперименты уже не раз проводились и результаты известны, думаю дешевле о них почитать нежели ходить по тем-же граблям.

  • 10.09.17 в 16:01

    +5

    Депремировать тех, кто ввёл эту систему.

    • 10.09.17 в 17:02

      +1

      Это понятно, а с командой как поступите?

      • 10.09.17 в 17:32

        +2

        Я всё же не управленец, да и прочих деталей ситуации в фирме не знаю.
        Навскидку мысль: если нельзя премировать — надо искать другие пути поощрения. Зарплату повысить, например :-).

  • 10.09.17 в 16:48

    +1

    К сожалению, и запланированные сроки, и бюджет оказались превышены в разы.

    Депремировать сотрудника (ов), который согласован сроки и бюджет.
    • 10.09.17 в 17:01

      +1

      А с командой что делать?

      • 10.09.17 в 17:09

        +4

        Если в приоритете деньги, то депремировать еще и команду за срыв сроков и т.д. Не забудьте всячески скрывать, что проект оказался прибыльным. Именно по такой схеме организована работа в компании, где я работаю.
        Ну, а если же в приоритете люди, то необходимо показать, что труд команды не остался незамеченным. Не обязательно давать именно премию. Это могут быть и какие-то нематериальные блага.
        • 10.09.17 в 17:41

          0

          Считайте что скрывать нереально, а в приоритете у компании прибыль не только прямо сейчас, но и в будущем тоже.

          • 29e53121cd48691aada416add62b1db8_small.j

            10.09.17 в 22:49

            +4

            Безусловно премировать. В данном случае люди, стараясь сделать проект, рассматривали его как некий стартап, или голова в кустах или грудь в крестах. Если их за успех не премировать — это будет им и всем другим напоминанием о том, что руководству плевать на успехи команды, и следующий подобный проект будет реализовываться командой так чтобы а) уложиться в сроки и бюджет, и б) свалить вину за его кривизну и провал на кого то другого. Как вы понимаете, подобный вариант легко может похоронить как команду (ибо не все люди готовы работать по крысиным принципам), так и организацию в целом (ибо убытки могут быть так умно скрыты, что узнать о них будет затруднительно).
  • 6c970fa2e7fa03ffb45d344b2b6c94ad_small.j

    10.09.17 в 18:08

    +2

    Выдать надо. Но четко определить что эта перемия не связанна с премией за сдачу проекта в срок.
  • c259b6d17c312b99cb8ef1010bd66bf3_small.j

    10.09.17 в 18:30

    +2

    Между 1-м и 2-м пунктами, а также между 6-м и 7-м очень слабая связь. Мотивация сотрудников и сроки проекта друг с другом не особо пересекаются. Также просрочка нового проекта могла привести к уменьшению прибыли, хоть она всё равно и осталась рекордной. Собственно высокий результат вторая команда не показала, поэтому и премии ей давать не следует.
  • 10.09.17 в 19:28

    +7

    Депремировать того, кто придумал использовать одни и те же метрики для доработок зрелого проекта и для нового проекта с кучей резерча.

  • 10.09.17 в 20:03

    +3

    В рамках текущих правил премию-бонус не давать (и не надо путать с депремированием, свой фикс команда же получила?).
    Если «сверх прибыль» получилась в связи с тем что результат был действительно лучше планируемого и/или в следствии того что в процессе создания была создана технология/методика которые не входили в первоначальный план — тогда выдать «бонус» за данный героизм, но в сумме меньший чем за исполнение в срок.
    Т.е по другому — команда выполняла свою работу, получала ЗП, финансовые риски не несла, условия сдачи не выполнила => нет бонуса.
  • f1adbac3ea3be738241838375a0bdd70_small.p

    10.09.17 в 20:07

    +2

    Премировать нельзя. Если в компании не предусмотрены премии за «выстрелившие» проекты (по результатам прибыли / etc.), то и не за что премировать.
    Выдавая премию вы поощряете команды нарушать сроки / бюджет, а так же демотивируете первую команду. Один раз вам повезло и проект выстрелил, но нет никаких гарантий что такое повторится.
  • 10.09.17 в 20:32

    +1

    Мой друг и я купили квартиры в один день. Наняли бригады строителей для ремонта.
    У друга полы и стены оказались считай ровными. А у меня кривизна-кривая и строители ошиблись в расчете материалов, правда еще и часть материалов запороли — чтож ремонт закончить надо: пришлось докупить. Но только они еще и на 2 месяца дольше работали!, а мне жилье пока надо было снимать, и теща мозг выносила.
    Но строители молодцы- отремонтировали мою кривенькую квартиру, правда дороже вышло в разы и дольше в два раза. И вот они просят еще денег за то что полы кривые были сильно сразу. Как думаете платить им или так отпустить?
  • 10.09.17 в 20:38

    0

    Я бы премировал, списав провал сроков на кривое планирование сроков.
    Однако, при выдаче премии указал бы: премия была бы существенно больше. если бы сроки были соблюдены.

  • 217e4cec8035445d7fa43b917e7234db_small.j

    10.09.17 в 21:28

    +3

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

    Вводная прямо царство лжи и… ну хорошо, не лжи, а манипуляции, которая совершенно определенно склоняет к ответу «премировать». Столько моментов осталось за кадром, что принять взвешенное решение практически невозможно. Я просто оставлю перечень:
    1. Мы не знаем как качество разработки нового проекта повлияло на финансовую успешность. Даже кривые программы порой бывают коммерчески успешными если решают потребности пользователей.
    2. Мы не знаем как разработчики могли повлиять на оценку сроков и бюджета. Если бюджет и сроки спускаются сверху, то это просто «погода». Сегодня дождливо, бюджет 150 тысяч. Завтра солнечно — 3 миллиона.
    3. Мы не знаем как шел процесс разработки. Была ли эскалация со стороны разработчиков о прогнозируемом срыве сроков/бюджета.
    4. Мы не знаем менялся ли скоп разработки.
    5. Мы не знаем был ли у разработки Product Owner и его роль в проекте.
    6. Мы не знаем методологию разработки и в чем заключался bottleneck. Это могло быть и коммуникация, и аналитика, и разработка, и тестирование.
    7. Как мерили неподдельный энтузиазм? Не получилось ли так что команда решила освоить новый модный фреймворк и развлекала себя за счет работодателя?
    8. Как обстоят дела со стоимостью владения продуктом?

  • 10.09.17 в 21:51

    +1

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


    Причины:


    1. Все команды должны быть мотивированы на создание успешных продуктов.
    2. Сотрудников из команды, создавшей успешный продукт следует мотивировать продолжать работу над этим продуктом хотя бы первое время, пока команда не будет пополнена или замещена более другими кадрами, если имеющиеся не устраивают (новым требуется время для вникания в курс дела).
    • c259b6d17c312b99cb8ef1010bd66bf3_small.j

      10.09.17 в 22:21

      +1

      Не повлечёт ли это ситуацию, когда все будут хотеть на новый проект, который можно бесконечно пилить и ждать пока он выстрелит?
      • 10.09.17 в 23:21

        +1

        Рискованный проект может и не выстрелить вообще — если он провалится, или будет выдвинуто решение об отказе от продолжения разработки, тогда команду в любом случае оштрафуют или уволят.
        Многим разработчикам будет спокойнее сидеть на стабильном, пусть и не самом прибыльном проекте, на котором понятны условия получения премий и шаги, необходимые для их выполнения.
  • 10.09.17 в 22:44

    +1

    Я бы в таких условиях не премировал вторую команду за разработку. Но раз продукт оказался таким перспективным, я бы назначил им соответствующие премии за его дальнейшее развитие.
  • 10.09.17 в 23:22

    +1

    Здесь уже говорили умную мысль про пересмотр методики премирования… и я тоже согласен что именно в данных критериях премирования премию выдавать не стоит… По двум причинам:
    1. Это противоречит правилам премирования, а следовательно снизит прозрачность механизма премирования для сотрудников первой группы. Что так же может подорвать доверие сотрудников первой группы к руководству.
    2. Демотивация сотрудников первой группы. Но данный пункт скорее производная от первого чем самостоятельный пункт.

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

  • 10.09.17 в 23:22

    +1

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

  • 10.09.17 в 23:22

    +1

    Если команде было известно, что за успешно выполненный проект полагается премия — полагается премировать. И ином случае получите сильнейший демотиватор, я бы после такого начинал тихонько искать другую работу, просто из за отношения. Работать дальше с такой командой менеджмента нет совершенно никакого желания. Если не известно — скрывать, но вероятность что такое можно удержать в секрете мала. Поэтому — премировать в любом случае. Я бы в дополнение поставил под вопрос возможность решать этим людям, кого премировать, а кого нет. Под еще больший вопрос поставил бы такую схему премирования. Короче — команда ваша не долго проработает с таким отношением, помяните мой слово.

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

© Habrahabr.ru