[Управление персоналом, Управление продуктом, Управление разработкой] Использование семи смертных грехов для мотивации персонала (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Привет, Хабр! Представляю вашему вниманию ироничную вариацию на тему семи смертных грехов. На этот раз, в контексте управленческих практик. Перевод статьи Evil Coach.
Итак, в вашей организации внедряются практики Agile и ведутся бирюзовые разговоры о “коллаборации” между командами? Вы, как биг босс, начинаете ощущать собственное бессилие и потерю контроля над эффективностью ВАШИХ команд? Позвольте мне привести здесь несколько рекомендаций, которые позволят повернуть этот процесс вспять, с тем, чтобы все нити успеха привели обратно к Вам. Вы, как сильный лидер, этого заслуживаете!
Некоторые руководители пытаются выстраивать взаимодействие между командами и мотивировать сотрудников, но настоящий босс привык активно управлять трудовыми ресурсами. Вот стратегия сохранения контроля, основанная на многовековом опыте. Некоторые говорят, что контроль над трудовыми ресурсами — иллюзия… но они просто никогда не работали под началом настоящего босса. Секрет контроля — использование семи смертных грехов для мотивации ВАШИХ трудовых ресурсов. В конце концов, это именно то, что всегда двигало людьми, не так ли? Тогда приступим.
Гордыня
В течение некоторого времени не скупитесь на похвалу разработчикам. Пусть привыкнут к вашим комплиментам. Убедитесь, что они действительно гордятся своими достижениями и знаниями всего, что связано с их работой. Затем остановитесь. Это очень важно! Они начнут сомневаться в себе и работать вдвое больше, только бы услышать от вас доброе слово. Очень скоро они будут есть у вас с руки.
Жадность
Деньги — лучший драйвер. Финансовая мотивация — это классика! (Я знаю, есть исследования, якобы доказывающие, что это хорошо работает лишь для прогнозируемой, несложной деятельности, но предпочитаю игнорировать подобные измышления как пропаганду, оставшуюся со времен хиппи.) Выдавайте бонусы командам, которые успели реализовать все пользовательские истории, вошедшие в спринт. А чтобы стало еще интереснее — добавьте дополнительный бонус на случай, если они сделают больше, чем обещали. Только имейте ввиду: все это превосходно работает при низком базовом окладе. Если ваши разработчики могут достойно жить на оклад — эффективность снизится.
Кстати, почему бы не рассмотреть варианты с аутсорсингом, ведь скорей всего, вы и сами на нем? Выберите страну с дешевой рабочей силой, установите низкий базовый оклад, ну и, конечно, игнорируйте концепцию “тянуть, а не толкать” фичи в спринт. Теперь ВЫ все контролируете. И запомните: ВЫ должны решать, над чем им работать. Дешевые разработчики, которые много работают (но никогда не выполняют спринт целиком, т.к. это сделало бы их дорогими) будут отлично смотреться в ваших таблицах и отчетах. А что, вы сможете стать героем в компании, предложившим эффективную схему аутсорсинга. Таким путем можно даже продвинуться по карьерной лестнице, став директором направления по аутсорсингу. О, это будет большой успех — я обещаю!
Зависть
У вас должен быть специальный приз для команды, выполнившей больше всего работы за спринт. Он должен быть зримым и сохраняющимся на протяжении всего спринта — другие команды должны его наблюдать. Это создаст здоровую конкуренцию между командами, правда может иметь и побочный эффект в виде небольшого ухудшения качества сотрудничества, а в некоторых случаях и саботажа работы другой команды, но к этому следует относиться, как к запланированному риску. “Нельзя приготовить омлет, не разбив нескольких яиц.” (Максимилиан Робеспьер).
Чревоугодие
Разработчики питаются колой и пиццей, правильно? Убедитесь, что ваши команды имеет постоянный доступ к этим столпам здорового питания. (Время от времени можно раздавать витамины, если у них начнут выпадать зубы, или жидкость для полоскания полости рта с фтором, если зубы начнут разрушаться, ну, вы поняли идею.) Если вы обеспечите их едой и напитками, им будет не нужно ходить на обед. Если в офисе установить узкие дверные проемы, дополнительным бонусом через некоторое время станет то, что они вообще не смогут оттуда уйти. А значит у вас появятся ДЕЙСТВИТЕЛЬНО преданные своему делу сотрудники.
Гнев
О, как же я люблю гнев! Нет другой эмоции, заключающей в себе столько потенциальной силы. Обозленный разработчик способен писать код сутками. Поощряйте конфликты между командами и между отдельными членами команды. Убедитесь, что они пишут действительно язвительные комментарии в код-ревью и публично награждайте авторов самых забавных из них. Также акцентируйте внимание всей команды на разработчике, сгенерировавшем самую серьезную ошибку. Публичный позор станет отличным триггером гнева и желания отомстить.
Лень
Это немного более сложный в использовании драйвер, но не бесполезный. Как известно, “хороший разработчик — ленивый разработчик”. Если что-то можно сделать проще и быстрее, то так и следует поступать. Не тратьте время на то, за что клиент не платит деньги, например, на личную гигиену или контроль качества ПО. Если от разработчиков начнет пахнуть, если они будут выглядеть неопрятными, то дополнительным плюсом станет то, что они так и останутся свободными от личной жизни. А раз им не придется тратить время на семью или любимого человека, значит они смогут писать код еще эффективнее. Тренинги по сокращению непродуктивного использования времени следует проводить ежемесячно.
Похоть
Тоже немного сложно, учитывая разнородность рабочих мест, в которых обычно обитают группы разработчиков. Однако, всегда есть люди, с которыми им приходится сталкиваются практически ежедневно. Короче говоря, нанимайте только улыбчивых и симпатичных сотрудников на вспомогательные должности, такие как HR, техподдержка, ресепшн или экономический отдел. Хорошенькие РП или стейкхолдеры — тоже прекрасная идея. Просто помните о том, что в офисе должны быть представители всех полов и предпочтений, с тем чтобы охватить весь базис.
Чтобы все это заработало как драйвер для разрабов, обозначенных выше сотрудников следует приглашать к участию в демонстрациях. Они там должны аплодировать и положительно отзываться о той версии, которая им больше придется по вкусу. Положительные отзывы должны быть адресованы конкретным разработчикам, дабы у них возникала иллюзия наличия шансов с людьми, которые не из их лиги.
Когда вы контролируете все бонусы и награды — вы управляете своими разработчиками как марионетками или ресурсами, которыми они в действительности и являются. Забудьте о них как о людях. Они здесь для того, чтобы ими манипулировать с целью получения бонуса. В конце концов, рабочее место — это не то место, где можно чувствовать себя счастливым, это место, где дела должны делаться.
Удачи!
===========
Источник:
habr.com
===========
===========
Автор оригинала: Evil Coach
===========Похожие новости:
- [IT-компании, Карьера в IT-индустрии, Управление персоналом, Учебный процесс в IT] Как стать тестировщиком: плюсы/минусы, интернатура, опыт
- [Визуализация данных, Открытые данные, Управление продуктом] Сим-сим, откройся! — Как мы запустили проект «Открытые данные»
- [AR и VR, Бизнес-модели, Управление персоналом, Финансы в IT] Швейцарский банк UBS перевел трейдеров в дополненную реальность из-за коронавируса
- [Управление персоналом, Читальный зал] Давайте дружить… Тараканами
- [Управление персоналом] Тысяча и один русский язык
- [Управление разработкой] Удаленка. Работающие принципы управления
- [Agile, Управление персоналом] Скрам-мастер — лидер-слуга (перевод)
- [Аналитика мобильных приложений, Дизайн, Дизайн мобильных приложений, Управление продуктом] Как продуктовому дизайнеру оценить свою работу
- [Развитие стартапа, Управление продуктом, Финансы в IT] Кайф трекерства в экспансии. Интервью с трекером Дмитрием Безнасюком
- [Управление разработкой, Управление персоналом] Как оцифровать разработчика или коротко о том, как сделать работу разработчиков более прозрачной для Компании
Теги для поиска: #_upravlenie_personalom (Управление персоналом), #_upravlenie_produktom (Управление продуктом), #_upravlenie_razrabotkoj (Управление разработкой), #_upravlenie_personalom (управление персоналом), #_upravlenie_personalom (
Управление персоналом
), #_upravlenie_produktom (
Управление продуктом
), #_upravlenie_razrabotkoj (
Управление разработкой
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:21
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Привет, Хабр! Представляю вашему вниманию ироничную вариацию на тему семи смертных грехов. На этот раз, в контексте управленческих практик. Перевод статьи Evil Coach. Итак, в вашей организации внедряются практики Agile и ведутся бирюзовые разговоры о “коллаборации” между командами? Вы, как биг босс, начинаете ощущать собственное бессилие и потерю контроля над эффективностью ВАШИХ команд? Позвольте мне привести здесь несколько рекомендаций, которые позволят повернуть этот процесс вспять, с тем, чтобы все нити успеха привели обратно к Вам. Вы, как сильный лидер, этого заслуживаете!  Некоторые руководители пытаются выстраивать взаимодействие между командами и мотивировать сотрудников, но настоящий босс привык активно управлять трудовыми ресурсами. Вот стратегия сохранения контроля, основанная на многовековом опыте. Некоторые говорят, что контроль над трудовыми ресурсами — иллюзия… но они просто никогда не работали под началом настоящего босса. Секрет контроля — использование семи смертных грехов для мотивации ВАШИХ трудовых ресурсов. В конце концов, это именно то, что всегда двигало людьми, не так ли? Тогда приступим. Гордыня В течение некоторого времени не скупитесь на похвалу разработчикам. Пусть привыкнут к вашим комплиментам. Убедитесь, что они действительно гордятся своими достижениями и знаниями всего, что связано с их работой. Затем остановитесь. Это очень важно! Они начнут сомневаться в себе и работать вдвое больше, только бы услышать от вас доброе слово. Очень скоро они будут есть у вас с руки. Жадность Деньги — лучший драйвер. Финансовая мотивация — это классика! (Я знаю, есть исследования, якобы доказывающие, что это хорошо работает лишь для прогнозируемой, несложной деятельности, но предпочитаю игнорировать подобные измышления как пропаганду, оставшуюся со времен хиппи.) Выдавайте бонусы командам, которые успели реализовать все пользовательские истории, вошедшие в спринт. А чтобы стало еще интереснее — добавьте дополнительный бонус на случай, если они сделают больше, чем обещали. Только имейте ввиду: все это превосходно работает при низком базовом окладе. Если ваши разработчики могут достойно жить на оклад — эффективность снизится. Кстати, почему бы не рассмотреть варианты с аутсорсингом, ведь скорей всего, вы и сами на нем? Выберите страну с дешевой рабочей силой, установите низкий базовый оклад, ну и, конечно, игнорируйте концепцию “тянуть, а не толкать” фичи в спринт. Теперь ВЫ все контролируете. И запомните: ВЫ должны решать, над чем им работать. Дешевые разработчики, которые много работают (но никогда не выполняют спринт целиком, т.к. это сделало бы их дорогими) будут отлично смотреться в ваших таблицах и отчетах. А что, вы сможете стать героем в компании, предложившим эффективную схему аутсорсинга. Таким путем можно даже продвинуться по карьерной лестнице, став директором направления по аутсорсингу. О, это будет большой успех — я обещаю! Зависть У вас должен быть специальный приз для команды, выполнившей больше всего работы за спринт. Он должен быть зримым и сохраняющимся на протяжении всего спринта — другие команды должны его наблюдать. Это создаст здоровую конкуренцию между командами, правда может иметь и побочный эффект в виде небольшого ухудшения качества сотрудничества, а в некоторых случаях и саботажа работы другой команды, но к этому следует относиться, как к запланированному риску. “Нельзя приготовить омлет, не разбив нескольких яиц.” (Максимилиан Робеспьер). Чревоугодие Разработчики питаются колой и пиццей, правильно? Убедитесь, что ваши команды имеет постоянный доступ к этим столпам здорового питания. (Время от времени можно раздавать витамины, если у них начнут выпадать зубы, или жидкость для полоскания полости рта с фтором, если зубы начнут разрушаться, ну, вы поняли идею.) Если вы обеспечите их едой и напитками, им будет не нужно ходить на обед. Если в офисе установить узкие дверные проемы, дополнительным бонусом через некоторое время станет то, что они вообще не смогут оттуда уйти. А значит у вас появятся ДЕЙСТВИТЕЛЬНО преданные своему делу сотрудники. Гнев О, как же я люблю гнев! Нет другой эмоции, заключающей в себе столько потенциальной силы. Обозленный разработчик способен писать код сутками. Поощряйте конфликты между командами и между отдельными членами команды. Убедитесь, что они пишут действительно язвительные комментарии в код-ревью и публично награждайте авторов самых забавных из них. Также акцентируйте внимание всей команды на разработчике, сгенерировавшем самую серьезную ошибку. Публичный позор станет отличным триггером гнева и желания отомстить. Лень Это немного более сложный в использовании драйвер, но не бесполезный. Как известно, “хороший разработчик — ленивый разработчик”. Если что-то можно сделать проще и быстрее, то так и следует поступать. Не тратьте время на то, за что клиент не платит деньги, например, на личную гигиену или контроль качества ПО. Если от разработчиков начнет пахнуть, если они будут выглядеть неопрятными, то дополнительным плюсом станет то, что они так и останутся свободными от личной жизни. А раз им не придется тратить время на семью или любимого человека, значит они смогут писать код еще эффективнее. Тренинги по сокращению непродуктивного использования времени следует проводить ежемесячно. Похоть Тоже немного сложно, учитывая разнородность рабочих мест, в которых обычно обитают группы разработчиков. Однако, всегда есть люди, с которыми им приходится сталкиваются практически ежедневно. Короче говоря, нанимайте только улыбчивых и симпатичных сотрудников на вспомогательные должности, такие как HR, техподдержка, ресепшн или экономический отдел. Хорошенькие РП или стейкхолдеры — тоже прекрасная идея. Просто помните о том, что в офисе должны быть представители всех полов и предпочтений, с тем чтобы охватить весь базис. Чтобы все это заработало как драйвер для разрабов, обозначенных выше сотрудников следует приглашать к участию в демонстрациях. Они там должны аплодировать и положительно отзываться о той версии, которая им больше придется по вкусу. Положительные отзывы должны быть адресованы конкретным разработчикам, дабы у них возникала иллюзия наличия шансов с людьми, которые не из их лиги. Когда вы контролируете все бонусы и награды — вы управляете своими разработчиками как марионетками или ресурсами, которыми они в действительности и являются. Забудьте о них как о людях. Они здесь для того, чтобы ими манипулировать с целью получения бонуса. В конце концов, рабочее место — это не то место, где можно чувствовать себя счастливым, это место, где дела должны делаться. Удачи! =========== Источник: habr.com =========== =========== Автор оригинала: Evil Coach ===========Похожие новости:
Управление персоналом ), #_upravlenie_produktom ( Управление продуктом ), #_upravlenie_razrabotkoj ( Управление разработкой ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 19:21
Часовой пояс: UTC + 5