Как менеджер команды разработчиков программного обеспечения из 20 человек, я хотел бы добавить в работу немного веселья. В основном это делается для того, чтобы обеспечить хорошую командную синергию, веселье, мотивацию и перекрестное общение в команде, которой не хватает всего этого.
Я сам просматривал видеоролики по геймификации , такие как лотерея Speed Camera, и меня вдохновило попробовать что-то подобное в моей команде. т. е. вознаграждать положительное поведение, а не ограничивать людей множеством параметров для их оценки.
То, что я хотел бы представить, — это система, в которой я могу дать толчок этому виду вознаграждения за положительное поведение веселыми способами. Например, сначала я бы начал с награждения всех инженеров начальным фондом баллов, скажем, по 100 каждому, и они должны были потратить, а также заработать баллы от других, помогая, общаясь или мотивируя других.
Например, в простом случае разработчик может отправить электронное письмо с вопросом, чтобы помочь ему или ей переформулировать вопрос, который он собирается задать клиенту, и установить значение, т. е. присудить 10 баллов каждому. кто помогает.
Помогите просмотреть это электронное письмо, которое я отправляю клиенту о функции Dashboard. 10 баллов будет начислено тому, кто поможет мне в этом. С уважением, -О
Я бы хотел, чтобы всем этим обменивались в системе электронной почты, но не возражайте, если это можно сделать с помощью существующего веб-решения. Важной частью является забавный элемент обмена баллов и обналичивания их мне в конце месяца, чтобы получить какой-то подарок или купон на обед. Я знаю, что идея становится проектом сама по себе, поскольку все остальные случаи должны быть обработаны.
Кто-нибудь внедрял такую систему на своем рабочем месте? Какие системы используются или что-то близкое к тому, чего я хотел бы достичь?
Я могу быть непонятен с точки зрения читателя, поэтому, пожалуйста, не стесняйтесь спрашивать меня о дополнительной информации. Заранее спасибо.
Геймификация по своей сути носит соревновательный характер, что противоречит концепции «добьешься успеха или потерпишь поражение как команда», которая лежит в основе многих гибких методологий. Это не значит, что это плохая идея; это просто означает, что он не подходит для использования с такими фреймворками, как Scrum или Extreme Programming. Ваш пробег может варьироваться в зависимости от других методологий.
Согласно одной статье в Википедии о методах геймификации (выделено мной):
Методы геймификации стремятся использовать естественное стремление людей к соперничеству, [личным] достижениям, статусу , самовыражению, альтруизму и закрытости.
Это может быть весьма полезным, но конкуренция или стремление к статусу противоречит самоорганизующейся, командной структуре Scrum. Сказав это, безусловно, можно структурировать систему баллов, которая вознаграждает за сотрудничество, наставничество, обмен знаниями, групповую работу и парное программирование, но по моему личному опыту я обнаружил, что команды, которые преследуют эти цели, часто находят практику своей. собственное вознаграждение.
Вместо того, чтобы поощрять индивидуальные достижения, я склонен сосредотачиваться на командных вознаграждениях. Особенно во время перехода от командно-административного управления к маневренности я часто находил полезным вознаграждать команду обедами вне дома или вечеринками с пиццей за такие вещи, как оценки с мертвой точки или скопление запоздалой истории со «всеми руками на палубе» в чтобы финишировать в текущем спринте.
Важно не поощрять неправильное поведение, например, занижение оценок или заметание неудовлетворительной работы под рубрикой командной работы. Тем не менее, об этом обычно заботятся, проводя регулярные, честные ретроспективы, которые включают оценку самих метрик.
Как и в случае любого другого контроля управления проектами, полезность этого метода варьируется между командами и организационной культурой. Вы также будете стремиться получить то, что измеряете, поэтому убедитесь, что правила игры соответствуют вашим намеченным целям, и постоянно проверяйте, работает ли элемент управления так, как задумано.
Если вы не являетесь Scrum-магазином или не проводите ретроспективы, вам могут понадобиться другие элементы управления для контроля за вашими элементами геймификации. Это не означает, что это не стоит делать, но это означает , что проблема, вероятно, будет более сложной, чем кажется на первый взгляд.
Как всегда в управлении проектами, ваш пробег может варьироваться.
Роберт Остин написал короткую разрушительную книгу « Измерение и управление эффективностью в организациях» , в которой четко показано, почему и как большинство систем личных измерений обречены быть либо в лучшем случае искажающими, либо в худшем — активно дисфункциональными.
Проблема в том, что вы вводите личные измерения. При определенных обстоятельствах это может сработать очень хорошо. Однако если есть хотя бы подозрение на намек на дуновение шанса на возможность того, что оно когда-либо будет привязано к какому-либо вознаграждению или наказанию, система будет сыграна. Когда система сыграна, у вас теперь есть две проблемы.
Во-первых, любая информация, полученная из системы, вводит в заблуждение. Он говорит вам вещи, которые не соответствуют действительности; если вы действуете в соответствии с ними, вы можете совершить дорогостоящие ошибки.
Во-вторых, вы искажаете набор выполняемой работы. «Что измеряется, то и делается». Если вы не сможете измерить все важные аспекты (Остин называет это «полным надзором»), вы исказите всю работу. Введение новых метрик не исправит этого, потому что на практике любое сочетание либо сведется к «истинным» метрикам, которым руководство явно отдает предпочтение; или создается индексная метрика, которую можно максимизировать, подгоняя активность к весам в индексной метрической функции.
Также, как указал CodeGnome, существует проблема конкуренции. Поскольку любая система устанавливает игру с нулевой суммой (чтобы я выиграл, кто-то другой должен проиграть), она создает рациональные препятствия для сотрудничества между игроками. Но программное обеспечение обычно является совместным предприятием.
Использование командных стимулов решит проблему с нулевой суммой, но не решит проблемы вводящей в заблуждение информации и искаженных усилий.
по четвергам
Тодд А. Джейкобс
один мир
один мир
Майк Петти