Я уже давно хочу поделиться уникальной мотивацией для разработчиков, которую создал и внедрил. Постараюсь рассказать без воды, кратко и по делу.
Данная мотивация позволит не заставлять сотрудников работать, если они этого не хотят. А так же быстро выявить неэффективных сотрудников, которые тянут команду к дну.
Наша команда работает in-house в Москве и Воронеже и удалено по разным городам России. Эта мотивация применима для всех, кто работает в компании full-time, в независимости от местонахождения. Отдельно хочу отметить высокую эффективность в случае работы с удаленными сотрудниками.
На текущий момент, в компании работает больше 10 разработчиков. У нас 10 купонных сервисов, 2 мобильных приложения, агрегатор kupon.ru, ERP-система, рассыльщик, который рассылает более 8 миллионов писем в день, и, совместный проект, аналитический сервис gtmix.ru. Каждый разработчик участвует в 2 и более проектах. Работает it-отдел по SCRUM в Trello. Ежедневные митинги разделены по проектам и проходят в точно назначенное время.
Эффективность разработчика измеряется в баллах. Для удобства сбора результатов, мы используем плагин для trello: Scrum for Trello. Балл формируется из коэффициента скорости команды и времени, затраченного на задачу. Есть простая, наглядная табличка:
Из практического опыта, оптимальный коэффициент скорости команды составляет 1,6. Чтобы вы понимали, это 5 часов работы сотрудника в день или 1 балл. 1 человек/час — это время потраченное на написание кода и обмозгование задачи. Время затраченное на чтение книг, кофе, чай и тому подобное не считается.
Баллы делятся на предполагаемые и потраченные. Предполагаем баллы — это сколько разработчик собирается потратить на задачу. Потраченные баллы — это сколько разработчик фактически затратил времени. Важно, что оценка, которая влияет на зарплату измеряется в потраченных баллах.
Команда работает поитерационно. Итерация составляет 2 недели. В неделю сотрудник должен набрать 5 баллов. В итерацию, соответственно, 10 баллов. По окончанию 2 итераций, мы проводим демку, где команда менеджеров отчитывается перед всей компанией за результаты. В сумме за 2 итерации сотрудник должен набрать 20 баллов.
Вот так может выглядеть табличка:
В нашей культуре достаточно жестко прописано, что мы ожидаем от сотрудника отличных результатов. От баллов зависит напрямую увеличение его заработной платы. В зависимости от результата формируется коэффициент, на который увеличивается зарплата:
Основная идея заключается в том, что сотрудник получает фиксированно только половину зарплаты. Данная мотивация может применяться, если сотрудник хочет полностью белую зарплату, но не на столько эффективно.
Переходим к самому интересному. К названию «Мотивация каратистов», почему и откуда оно взялось? Как мы понимаем, недостаточно подсчитать баллы для определения эффективности разработчика. Для субъективной оценки были придуманы пояса. Пояс представляет из себя уровень разработчика. Чем выше его уровень, тем выше пояс. Рассмотрим на примерах, если сотрудник претендует на зарплату в 80000 рублей, я могу предложить ему пояс: 5кю. При этом после испытательного срока, мы можем договориться о повышение до 90000 рублей (6кю). Если разработчик будет показывать отличные оценки по баллам, и его результаты будут удовлетворять нашим ожиданиям, то мы можем договориться о его повышения через 3 месяца после прохождения испытательного срока до 100000 рублей (7кю).
Система поясов для регионов:
В компании гибкий график, при этом сотрудник должен быть на связи не меньше 8 часов в день. Это важное правило, которое позволяет не волноваться о том, что ваш сотрудник не сможет прореагировать, когда вам нужна будет от него помощь. К примеру, Иван работает с 9:00 до 18:00, в это время я ожидаю, что он будет на связи. В данном случае, мне необязательно контролировать его по задачам, так как я уверен, что он отметит выполненные баллы по итогу дня. А на ежедневном митинге расскажет про свои успехи.
Итак, что мы имем:
— объективную оценку, которую отмечает сам разработчик по окончанию задачи, выраженную в потраченных баллах.
— субъективную оценку, которую формируется на основании реальных успехов сотрудника, его соответствию культуре компании и других факторов.
Возможно вы все сталкивались с тем, что разработчик не хочет отмечать время и перетаскивать сделанные задачи в trello. Теперь вы можете спать спокойно, он напрямую заинтересован в этом. А если у вас есть stage и code review, то введите одно важное правило: задачи, которые не вылиты на production, засчитаны не будут, как сделанные. В итоге, по окончанию демки, на презентации вы сможете показать реальные результаты, не заставляя разработчиков вылить хоть что-нибудь.
Вот таблица с реальными результатами наших сотрудников:
Данная мотивация позволяет очень быстро выявить неэффективных сотрудников. Так как они не любят отмечать свои успехи, и как результат, готовы смириться с низкими баллам, что, конечно же, не устраивает компанию.
Из собственных наблюдений хочу отметить, чтобы большинство сотрудников честно отмечают свои баллы. Возможно вы столкнетесь с некорректной оценкой задачи, но это скорее нюансы, которые должен быстро выявлять эффективный менеджер.
Делюсь ссылкой на презентацию.
Данная мотивация позволит не заставлять сотрудников работать, если они этого не хотят. А так же быстро выявить неэффективных сотрудников, которые тянут команду к дну.
Наша команда работает in-house в Москве и Воронеже и удалено по разным городам России. Эта мотивация применима для всех, кто работает в компании full-time, в независимости от местонахождения. Отдельно хочу отметить высокую эффективность в случае работы с удаленными сотрудниками.
На текущий момент, в компании работает больше 10 разработчиков. У нас 10 купонных сервисов, 2 мобильных приложения, агрегатор kupon.ru, ERP-система, рассыльщик, который рассылает более 8 миллионов писем в день, и, совместный проект, аналитический сервис gtmix.ru. Каждый разработчик участвует в 2 и более проектах. Работает it-отдел по SCRUM в Trello. Ежедневные митинги разделены по проектам и проходят в точно назначенное время.
Эффективность разработчика измеряется в баллах. Для удобства сбора результатов, мы используем плагин для trello: Scrum for Trello. Балл формируется из коэффициента скорости команды и времени, затраченного на задачу. Есть простая, наглядная табличка:
Из практического опыта, оптимальный коэффициент скорости команды составляет 1,6. Чтобы вы понимали, это 5 часов работы сотрудника в день или 1 балл. 1 человек/час — это время потраченное на написание кода и обмозгование задачи. Время затраченное на чтение книг, кофе, чай и тому подобное не считается.
Баллы делятся на предполагаемые и потраченные. Предполагаем баллы — это сколько разработчик собирается потратить на задачу. Потраченные баллы — это сколько разработчик фактически затратил времени. Важно, что оценка, которая влияет на зарплату измеряется в потраченных баллах.
Команда работает поитерационно. Итерация составляет 2 недели. В неделю сотрудник должен набрать 5 баллов. В итерацию, соответственно, 10 баллов. По окончанию 2 итераций, мы проводим демку, где команда менеджеров отчитывается перед всей компанией за результаты. В сумме за 2 итерации сотрудник должен набрать 20 баллов.
Вот так может выглядеть табличка:
В нашей культуре достаточно жестко прописано, что мы ожидаем от сотрудника отличных результатов. От баллов зависит напрямую увеличение его заработной платы. В зависимости от результата формируется коэффициент, на который увеличивается зарплата:
- Удовлетворительный (<14 баллов): не увеличивается зарплата
- Нормальный (14-16 баллов): зарплата увеличивается в 1,5 раза
- Хороший (17-18 баллов): в 1,7 раза
- Отличный (>19): в 2 раза
Основная идея заключается в том, что сотрудник получает фиксированно только половину зарплаты. Данная мотивация может применяться, если сотрудник хочет полностью белую зарплату, но не на столько эффективно.
Переходим к самому интересному. К названию «Мотивация каратистов», почему и откуда оно взялось? Как мы понимаем, недостаточно подсчитать баллы для определения эффективности разработчика. Для субъективной оценки были придуманы пояса. Пояс представляет из себя уровень разработчика. Чем выше его уровень, тем выше пояс. Рассмотрим на примерах, если сотрудник претендует на зарплату в 80000 рублей, я могу предложить ему пояс: 5кю. При этом после испытательного срока, мы можем договориться о повышение до 90000 рублей (6кю). Если разработчик будет показывать отличные оценки по баллам, и его результаты будут удовлетворять нашим ожиданиям, то мы можем договориться о его повышения через 3 месяца после прохождения испытательного срока до 100000 рублей (7кю).
Система поясов для регионов:
В компании гибкий график, при этом сотрудник должен быть на связи не меньше 8 часов в день. Это важное правило, которое позволяет не волноваться о том, что ваш сотрудник не сможет прореагировать, когда вам нужна будет от него помощь. К примеру, Иван работает с 9:00 до 18:00, в это время я ожидаю, что он будет на связи. В данном случае, мне необязательно контролировать его по задачам, так как я уверен, что он отметит выполненные баллы по итогу дня. А на ежедневном митинге расскажет про свои успехи.
Итак, что мы имем:
— объективную оценку, которую отмечает сам разработчик по окончанию задачи, выраженную в потраченных баллах.
— субъективную оценку, которую формируется на основании реальных успехов сотрудника, его соответствию культуре компании и других факторов.
Возможно вы все сталкивались с тем, что разработчик не хочет отмечать время и перетаскивать сделанные задачи в trello. Теперь вы можете спать спокойно, он напрямую заинтересован в этом. А если у вас есть stage и code review, то введите одно важное правило: задачи, которые не вылиты на production, засчитаны не будут, как сделанные. В итоге, по окончанию демки, на презентации вы сможете показать реальные результаты, не заставляя разработчиков вылить хоть что-нибудь.
Вот таблица с реальными результатами наших сотрудников:
Данная мотивация позволяет очень быстро выявить неэффективных сотрудников. Так как они не любят отмечать свои успехи, и как результат, готовы смириться с низкими баллам, что, конечно же, не устраивает компанию.
Из собственных наблюдений хочу отметить, чтобы большинство сотрудников честно отмечают свои баллы. Возможно вы столкнетесь с некорректной оценкой задачи, но это скорее нюансы, которые должен быстро выявлять эффективный менеджер.
Делюсь ссылкой на презентацию.
