Использование семи смертных грехов для мотивации персонала

Автор оригинала: Evil Coach
  • Перевод
Привет, Хабр! Представляю вашему вниманию ироничную вариацию на тему семи смертных грехов. На этот раз, в контексте управленческих практик. Перевод статьи Evil Coach.

Итак, в вашей организации внедряются практики Agile и ведутся бирюзовые разговоры о “коллаборации” между командами? Вы, как биг босс, начинаете ощущать собственное бессилие и потерю контроля над эффективностью ВАШИХ команд? Позвольте мне привести здесь несколько рекомендаций, которые позволят повернуть этот процесс вспять, с тем, чтобы все нити успеха привели обратно к Вам. Вы, как сильный лидер, этого заслуживаете!

image


Некоторые руководители пытаются выстраивать взаимодействие между командами и мотивировать сотрудников, но настоящий босс привык активно управлять трудовыми ресурсами. Вот стратегия сохранения контроля, основанная на многовековом опыте. Некоторые говорят, что контроль над трудовыми ресурсами — иллюзия… но они просто никогда не работали под началом настоящего босса. Секрет контроля — использование семи смертных грехов для мотивации ВАШИХ трудовых ресурсов. В конце концов, это именно то, что всегда двигало людьми, не так ли? Тогда приступим.

Гордыня


В течение некоторого времени не скупитесь на похвалу разработчикам. Пусть привыкнут к вашим комплиментам. Убедитесь, что они действительно гордятся своими достижениями и знаниями всего, что связано с их работой. Затем остановитесь. Это очень важно! Они начнут сомневаться в себе и работать вдвое больше, только бы услышать от вас доброе слово. Очень скоро они будут есть у вас с руки.

Жадность


Деньги — лучший драйвер. Финансовая мотивация — это классика! (Я знаю, есть исследования, якобы доказывающие, что это хорошо работает лишь для прогнозируемой, несложной деятельности, но предпочитаю игнорировать подобные измышления как пропаганду, оставшуюся со времен хиппи.) Выдавайте бонусы командам, которые успели реализовать все пользовательские истории, вошедшие в спринт. А чтобы стало еще интереснее — добавьте дополнительный бонус на случай, если они сделают больше, чем обещали. Только имейте ввиду: все это превосходно работает при низком базовом окладе. Если ваши разработчики могут достойно жить на оклад — эффективность снизится.

Кстати, почему бы не рассмотреть варианты с аутсорсингом, ведь скорей всего, вы и сами на нем? Выберите страну с дешевой рабочей силой, установите низкий базовый оклад, ну и, конечно, игнорируйте концепцию “тянуть, а не толкать” фичи в спринт. Теперь ВЫ все контролируете. И запомните: ВЫ должны решать, над чем им работать. Дешевые разработчики, которые много работают (но никогда не выполняют спринт целиком, т.к. это сделало бы их дорогими) будут отлично смотреться в ваших таблицах и отчетах. А что, вы сможете стать героем в компании, предложившим эффективную схему аутсорсинга. Таким путем можно даже продвинуться по карьерной лестнице, став директором направления по аутсорсингу. О, это будет большой успех — я обещаю!

Зависть


У вас должен быть специальный приз для команды, выполнившей больше всего работы за спринт. Он должен быть зримым и сохраняющимся на протяжении всего спринта — другие команды должны его наблюдать. Это создаст здоровую конкуренцию между командами, правда может иметь и побочный эффект в виде небольшого ухудшения качества сотрудничества, а в некоторых случаях и саботажа работы другой команды, но к этому следует относиться, как к запланированному риску. “Нельзя приготовить омлет, не разбив нескольких яиц.” (Максимилиан Робеспьер).

Чревоугодие


Разработчики питаются колой и пиццей, правильно? Убедитесь, что ваши команды имеет постоянный доступ к этим столпам здорового питания. (Время от времени можно раздавать витамины, если у них начнут выпадать зубы, или жидкость для полоскания полости рта с фтором, если зубы начнут разрушаться, ну, вы поняли идею.) Если вы обеспечите их едой и напитками, им будет не нужно ходить на обед. Если в офисе установить узкие дверные проемы, дополнительным бонусом через некоторое время станет то, что они вообще не смогут оттуда уйти. А значит у вас появятся ДЕЙСТВИТЕЛЬНО преданные своему делу сотрудники.

Гнев


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

Лень


Это немного более сложный в использовании драйвер, но не бесполезный. Как известно, “хороший разработчик — ленивый разработчик”. Если что-то можно сделать проще и быстрее, то так и следует поступать. Не тратьте время на то, за что клиент не платит деньги, например, на личную гигиену или контроль качества ПО. Если от разработчиков начнет пахнуть, если они будут выглядеть неопрятными, то дополнительным плюсом станет то, что они так и останутся свободными от личной жизни. А раз им не придется тратить время на семью или любимого человека, значит они смогут писать код еще эффективнее. Тренинги по сокращению непродуктивного использования времени следует проводить ежемесячно.

Похоть


Тоже немного сложно, учитывая разнородность рабочих мест, в которых обычно обитают группы разработчиков. Однако, всегда есть люди, с которыми им приходится сталкиваются практически ежедневно. Короче говоря, нанимайте только улыбчивых и симпатичных сотрудников на вспомогательные должности, такие как HR, техподдержка, ресепшн или экономический отдел. Хорошенькие РП или стейкхолдеры — тоже прекрасная идея. Просто помните о том, что в офисе должны быть представители всех полов и предпочтений, с тем чтобы охватить весь базис.

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

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

Удачи!
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    +1
    А в чем проблема с последним «грехом»?
      –1
      Они должны думать, что с этим проблем нет.)
      0
      Если всей семьей купаться
      Вы отправились к реке,
      Не мешайте папе с мамой Загорать на берегу.
      Не устраивайте крика,
      Дайте взрослым отдохнуть.
      Ни к кому не приставая,
      Постарайтесь утонуть.
        –2
        Норм последний грейх, можно будет еще и дело за харасмент в случае чего завести и шантажировать потом. Тогда вообще зп тогда получится отменить.
        Так то можно и наркотики подбрасывать еще как вариант.
          0

          Всё переусложнено. Ведь достаточно морковки: хорошим сотрудникам спереди, плохим — сзади :D

            0
            Плохим сотрудникам установим лампочки, а хорошим — кнопки
              0
              Прямо вижу ваш професианальный рост
              +1

              Статья конечно стёб, но ещё лет 10...15 широко и сейчас в узких кругах специфических компаний подобное не только практикуется, но и преподаётся на тренингах а-ля "Как управлять ресурсами".

                +1
                Вот тут это подано, как шутка, а я реально работал в компании, где управление командой разработчиков осуществлялось с применением подобных методик. Хорошо, что уволился оттуда, никому не советую работать в таких коллективах. Босс — который следует этим советам — плохой босс
                  +1

                  На мой вкус — сочная классификация. Весьма. Хоть и несколько хамовитая, но сочная. Правдивая. Вспомнились сразу ВСЕ мои предыдущие (и, я бы добавил, настоящий, офисы (и учреждения/организации), чтоб их...). К статье о тараканах — один движ. Я хоть не программист, а всего лишь инженер (добрый и не злобный) — однако вышеизложенная методика — СОЧНО (#амсосорри за тавтологию — таки тоже, видимо, грех), хотя повторение — мать {её} учения, как доказывает мой курятн… проектный отдел

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

                  Самое читаемое