Данная мотивация позволит не заставлять сотрудников работать, если они этого не хотят. А так же быстро выявить неэффективных сотрудников, которые тянут команду к дну.
Наша команда работает 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, засчитаны не будут, как сделанные. В итоге, по окончанию демки, на презентации вы сможете показать реальные результаты, не заставляя разработчиков вылить хоть что-нибудь.
Вот таблица с реальными результатами наших сотрудников:
Данная мотивация позволяет очень быстро выявить неэффективных сотрудников. Так как они не любят отмечать свои успехи, и как результат, готовы смириться с низкими баллам, что, конечно же, не устраивает компанию.
Из собственных наблюдений хочу отметить, чтобы большинство сотрудников честно отмечают свои баллы. Возможно вы столкнетесь с некорректной оценкой задачи, но это скорее нюансы, которые должен быстро выявлять эффективный менеджер.
Делюсь ссылкой на презентацию.
Комментарии (124)
KoCMoHaBT61
19.10.2016 19:53+24Когда менеджеры нихрена не умеют, но амбиции зашкаливают — начинаются придумки идиотских ролевых игр.
Данная мотивация позволяет очень быстро выявить неэффективных сотрудников. Так как они не любят отмечать свои успехи, и как результат, готовы смириться с низкими баллам, что, конечно же, не устраивает компанию.
В результате компания теряет настоящих программистов, приобретая игроков в крысиные бега.
Вот, например, кем проводится оценка трудоёмкости задачи?poxu
20.10.2016 07:51+3Отдельно хочется отметить "мы работаем по SCRUM" и "мы проводим демку, где команда менеджеров отчитывается перед всей компанией за результаты". Зашибись, да.
И исследования уже есть, демонстрирующие, что привязка зарплаты к эффективности программиста ухудшает результаты и опыт крупных контор — всё пофигу в общем.
KoCMoHaBT61
20.10.2016 10:36+1Непонятно, что такое эта «эффективность программиста». Эффективных менеджеров мы знаем — подгрызть, понадкусать всё, что надкусывается, а потом быстренько свалить, когда конструкция начнёт падать.
Что такое «эффективный программист»? Программист выигрывающий в менеджерские игры? Программист-математик? Программист-архитектор? Программист-художник? Программист-оптимизатор? Программист-конвеерщик?
Кто из них «эффективный»?poxu
20.10.2016 11:29В экспериментах просто замеряли скорость выполнения задач с неочевидными решениями. У тех, кого премировали за время и у тех, кого не премировали.
Source
19.10.2016 20:04-17Отличная система! С адекватными параметрами.
Максимум эффективности находится в районе 100-110 эффективных рабочих часов в месяц. Что как раз соответствует 20 баллам по вашей системе. При почасовке к этой схеме естественным путём приходишь, а вот при фуллтайме в офисе сотрудники частенько ограничиваются имитацией бурной деятельности, так что доп.мотивация им не помешает :-)
К примеру, Иван работает с 9:00 до 18:00, в это время я ожидаю, что он будет на связи.
На связи — это онлайн или на телефоне? Тут есть простор для небольшого смягчения. Нет необходимости требовать присутствие рядом с компьютером на протяжении 9 часов. Достаточно договориться о 3-4 часах, которые гарантировано фиксированы (на это время можно запланировать совещания/консультации/etc.), а в остальное время не отвлекать сотрудника, если нет никакой аварии на production.Source
19.10.2016 22:47-8Я так понимаю, минусуют те самые офисные программисты (склонные к ИБД), которые в месяц не способны наработать 100 часов… и видят в этой статье угрозу собственному раздолбайству. А по существу ничего возразить не могут :-)
Denxc
19.10.2016 20:06+4А кто определяет сколько стоит задача в баллах? В реальности может случиться, что стоимость задачи была недооценена или переоценена. В первом случае сотрудник будет мотивирован сделать абы как, лишь бы быстро, а во втором он просто будет отдыхать.
Как по мне, то такая система не мотивирует делать качественный продукт, но мотивирует делать все быстро «тяп-ляп и готово».Source
19.10.2016 20:19-6А кто определяет сколько стоит задача в баллах?
В статье же указано "объективную оценку, которую отмечает сам разработчик по окончанию задачи, выраженную в потраченных баллах". Т.е. в зачёт идёт фактическое кол-во отработанных часов, вне зависимости от прогнозов.
Denxc
19.10.2016 20:33+5Как мы понимаем, недостаточно подсчитать баллы для определения эффективности разработчика.
Так и не понял, а что вы делаете для определения эффективности, если не баллы считаете?
А кто запрещает сотруднику постоянно переоценивать свои фактически затраченные силы? Как происходит контроль?
время потраченное на написание кода и обмозгование задачи
Не знаю как у других, но в моей работе постоянно приходится сталкиваться с задачами, для решения которых надо думать 80% времени, а кодировать 20%. Если бы на моей работе была бы такая же система, то мне бы просто перестали верить, хотя я честно пару часов могу думать над задачей, что-то изучать, а потом за 30 минут написать 50-100 строчек эффективного кода.Source
19.10.2016 21:10-7Я не имею отношения к автору статьи. Но он пришёл к системе, которая мне близка и понятна. Поэтому могу свой взгляд высказать… Как правило, во главе команды есть тех.лид или технический директор, это человек с огромным опытом программирования, которого невозможно систематически обманывать с оценками задач, потому что он понимает какому уровню сколько реально часов нужно на конкретную задачу. Если задача занимает много времени, то адекватный программист укажет в комментариях к задаче с какими сложностями он столкнулся, а не просто поставит в 3 раза больше времени, чем ожидалось.
в моей работе постоянно приходится сталкиваться с задачами, для решения которых надо думать 80% времени, а кодировать 20%
Вы думаете, что удивите этим фактом хоть одного тех.лида? Это вполне нормальное соотношение для широкого круга задач.
В этом плане описанная в статье методика вполне адекватна, т.к. не привязана ни к кол-ву строк, ни к нажатиям клавиш, ни к времени проведённому неотрывно за клавиатурой.3aicheg
20.10.2016 03:38+8> потому что он понимает какому уровню сколько реально часов нужно на конкретную задачу
А такого, что за пару часов сделал 99% задачи, а потом ещё пару дней бьёшься лбом об монитор, пытаясь домучить оставшийся 1% у вас что, не бывает? И ладно ещё, если сам накосячил — допустим, ваш ведущий технический провидец, зная мой уровень, способен это предсказать. А то проявит себя какой-нибудь малоизвестный, нелогичный и нигде не описанный косяк используемой библиотеки, с которым раньше никогда не сталкивался — тех. лид. знает наизусть все эти косяки, а так же помнит, какие из них знает кто из его разработчиков?
CodeRush
20.10.2016 04:04+11Пара дней — это еще терпимо, и можно пережить. А мы как-то с бывшим начальником над тренировкой набортной DDR3 на новом AMD APU просидели 5 недель подряд, пока она не завелась (в связи с чем хочется передать пламенный привет тому, кто придумал AMD PMU и догадался инициализировать память через PSP).
Получается, за этот месяц нам обоим надо бы ЗП ополовинить? В таком случае в следующий раз подобный проект будет признан неподъемным после трех попыток, а потраченная на него шестизначная сумма в евро пойдет в убыток.
Короче, тут уже говорили несколько раз, что введение метрик, влияющих на зарплату, ведет только и исключительно к оптимизации по ним. Если вас это устраивает — дело ваше. Если же нет, обыкновенного performance review раз в полгода-год вполне достаточно, на мой взгляд.
Source
20.10.2016 13:25-1А такого, что за пару часов сделал 99% задачи, а потом ещё пару дней бьёшься лбом об монитор, пытаясь домучить оставшийся 1% у вас что, не бывает?
Вы невнимательно читаете: "Если задача занимает много времени, то адекватный программист укажет в комментариях к задаче с какими сложностями он столкнулся". В целом, если Вы столкнулись с такими трудностями, что безрезультатно "пару дней бьёшься лбом об монитор", необходимо сообщить об этом начальству, а то так можно целый месяц биться… при этом может оказаться, что добавленная компетенция решит её за пару часов (во всяком случае бывало и такое).
3aicheg
20.10.2016 15:00+4Отнюдь, я вдумчиво несколько раз перечитал ваш комментарий, и временами мне казалось, что вы таки в чём-то правы. Но всё-таки, мне кажется, вы неправы в главном: вся эта система с баллами, учётом времени и выдачей чёрных поясов не будет работать в общем случае. Она будет, возможно, работать в некоторых частных случаях — когда решаются совсем уж шаблонные типовые задачи, и при этом в коллективе царит полное взаимное доверие, никто не питает иллюзий по-поводу собственной компетенции и все работают с полной отдачей на общее благо… но при таких вводных можно вообще не заморачиваться с баллами, а сразу вводить коммунизм. Сложить все деньги в кучу посреди офиса, пусть каждый сам берёт, сколько, по собственному мнению, заслужил.
Вон выше CodeRush пишет, как 5 недель просидели над проблемой. У меня тоже бывали случаи. Как правило, помочь в такой ситуации не может никто. Начальник спрашивает, когда решу проблему — честно отвечаю, что как повезёт. Есть пара томов документации на почитать — возможно, ответ будет на первой странице первого тома, а возможно — на последней странице второго. А возможно, ни там ни там не будет. Есть десяток идей, как заставить всё работать, проверяю их по-очереди — возможно, правильной окажется первая же, возможно — последняя. А возможно, все десять будут мимо. И никакое абстрактное «тимлидство» не поможет начальнику понять, правду я говорю или 2.7бу мозги — ему надо быть либо глубоким экспертом в конкретно этом вопросе, либо отложить все свои дела и плотно вникнуть в мою задачу. Либо и то и другое сразу!
Или вот недавний совсем случай из собственной практики. Понадобился +1 человек на задачу низкоуровневой оптимизации кода под конкретное железо. Меня спрашивают: «Ну что, возьмёшься?» Говорю, никогда раньше такими задачами всерьёз не занимался, взяться могу, но сами понимаете. Понимаем, говорят, у нас все, кто такими задачами всерьёз занимался, уже ими занимаются, а из оставшихся тоже никто не умеет, так что давай. Вот я думаю, стал бы я браться за это нужное дело, если бы мне за него баллы начисляли? Сидят эксперты, типа, они бы за пару часов сделали, над чем я с непривычки буду неделю страдать, и то не факт, что выйдет. Пытаться всеми силами спихнуть задачу на кого другого или торговаться, чтобы мне больше баллов за это начисляли, чем я объективно заслуживаю? А потом опытные люди, в свою очередь, возбухнут, а чего это ему за те же задачи да больше баллов дают?? И погрязнет контора в пучине офисной политики :)Source
20.10.2016 18:33-1ему надо быть либо глубоким экспертом в конкретно этом вопросе, либо отложить все свои дела и плотно вникнуть в мою задачу.
Либо вообще отменить эту задачу… такое тоже бывает. Тут вопрос приоритетов. Но это опять не зона ответственности программиста принимать решение "пилить до победного".
стал бы я браться за это нужное дело, если бы мне за него баллы начисляли?
А кто предлагал баллы начислять? тут же речь только об учёте рабочего времени… Вы заранее предупредили, что опыта с такими задачами нет, начальство согласилось… спокойно отмечайте рабочее время и всё. Откуда тут какие-то претензии могут быть?
На мой взгляд претензии могут быть только такого типа: на задачу стоял эстимейт 2 дня, а Вы её пилите целый месяц и при этом никому не сообщили, что столкнулись с трудностями. Причём претензии такого типа к Вам будут по-любому вне зависимости от наличия какого-либо учёта.
А потом опытные люди, в свою очередь, возбухнут, а чего это ему за те же задачи да больше баллов дают?
Блин, вот я даже не знаю, у меня что-ли какое-то особое восприятие статьи? Я не увидел там идеи давать баллы… А кто в здравом уме будет возбухать на тему "почему это он больше меня работает?" я не знаю.
3aicheg
21.10.2016 03:58Мне показалось, что суть предлагаемой системы в том, что надо наработать задач на определённое количество условных часов. Т. е. за 8 часов рабочего дня в офисе я могу решить одну задачу, оцененную в 2 часа, а могу две задачи, каждая по 7 часов – получив, согласно таблице, за этот день либо 0.4, либо 2.8 балла, соответственно (а не стабильно 1.6 балла за просиженные 8 часов). Выглядит несколько логичнее, чем тупо отсчитывать просиженные часы. Если я, допустим, очень скилловый, я, может, за 2 часа в день буду нарабатывать на вожделенный 1 балл и, в зависимости от собственных амбиций, могу либо расслабиться и получать удовольствие, либо работать ещё и получать в день 2 балла, следовательно, в итоге больше денег. А если я бездарь, мне придётся больше времени просидеть, допустим, 12 часов, чтобы заработать 1 балл – зарабатывать в день 2 балла мне уже времени не хватит, что печально, но как минимум я могу компенсировать собственную тупость собственным упорством, чтобы быть наравне со всеми, и какая-то сермяжная справедливость в этом есть. Всё бы хорошо, вот только задачи не квантуются, о чём я писал выше.
Действительно, невнимательно прочитал статью – в ней этого нет. Прочитав внимательнее, я вообще перестал что-либо понимать. Оценка измеряется в «потраченных баллах» (т. е. во времни, которое я просидел над задачей по факту?). Откуда берётся и что означает коэффициент 1.6? Как с его помощью из 5 часов получают 1 балл? Если оценивается просто затраченное время, почему просто его и не считать – зачем все эти баллы, «кю», пояса?Source
21.10.2016 12:29-1Если оценивается просто затраченное время, почему просто его и не считать – зачем все эти баллы, «кю», пояса?
Это я тоже не очень понял… Пояса видимо для прикола, а вот зачем вместо часов считать баллы непонятно. Достаточно было бы указать, что время, затраченное на задачу отмечается с точностью до 0.25 часа c округлением в большую сторону.
Я вижу эту систему так:
В среднем по региону есть компании, которые предлагают зарплату от нормального уровня до хорошего… например, для стажера можно найти работу с зарплатой 30-34 т.р… Мы создаём компанию, которая предлагает стажеру возможность получить самую высокую зарплату по региону — 40 т.р. Но для этого он должен уделять непосредственно работе более 95 часов за 4 недели. Если он уделяет работе от 70 до 95 часов, то получает зарплату среднюю по региону для своего уровня. Ну а если он совсем лентяй, то нам такие стажеры не интересны, поэтому они получают 20 т.р., чтобы сами ушли балду валять в другое место.
Если фактические затраты времени на задачи начали систематически опережать эстимейт, то мы повышаем сотруднику уровень. Т.е. талантливый стажер уже со второго месяца сможет претендовать на зарплату 50 т.р., в то время как в любой другой компании региона он как минимум первые 3 месяца работал бы в лучшем случае за 34 т.р.
Что в этой системе плохого — хз… но, судя по кол-ву минусов, которые мне тут накидали, очень много людей по факту работают менее 70 часов в месяц, хотя мне раньше казалось, что средние цифры: 90-110 часов/мес.
poxu
21.10.2016 12:48+1судя по кол-ву минусов, которые мне тут накидали, очень много людей по факту работают менее 70 часов в месяц, хотя мне раньше казалось, что средние цифры: 90-110 часов/мес
В месяце 4 недели. В неделе 40 часов. 4*40 = 160. Вот столько работают все, кто работает на полную ставку. Вы, возможно, работаете меньше — видимо из-за того, что у вас не полный рабочий день.
MurzikFreeman
21.10.2016 13:05+1Рискну предположить, что тут идёт речь не о рабочих часах по трудовому кодексу, а о времени фактической работы. Есть мнение что человек из 8 рабочих часов работает реально только 5-6. Не помню для каких отраслей эти расчёты производились, но для программистов это объяснялось примерно так: Разработчик несколько раз в день теряет концентрацию и не выполняет свою непосредственную работу. Т.е. 2 часа в день он тратить на что угодно, только не на написание кода и его обдумывание. Это всё очень спорно, и я очень криво передал эту идею, но возможно именно эти 100 рабочих часов и имеются в виду.
Source
21.10.2016 13:17-1Да, всё верно. Лайф-хак: если Вам реально надо отработать 8 часов за день (ну там сроки горят и т.д.), то разделите рабочее время в течении дня на блоки 3-3-2 или 3-2-3. С большими перерывами (более часа) между блоками.
Впрочем, это работает только на коротких дистанциях… т.е. в таком режиме реально отработать месяц, но не год.
Source
21.10.2016 13:06-1Речь про время, уделённое работе, а не про время, проведённое на работе. Это 2 большие разницы. Так что не надо лукавства, никто из программистов систематически не работает больше 120 часов в месяц, это уже давно понятно (даже исследования есть). А вот то, что средние значения по Хабру не дотягивают до 100 — для меня сюрприз.
P.S. В офисе я тоже работал и успел насмотреться на коллег, которые и 3 часов из 8 не отрабатывали, это вовсе не редкость.MurzikFreeman
21.10.2016 13:44Тогда всё встаёт на свои места. Только теперь добавляется ещё несколько вопросов к описанной методике. Если мы хотим повысить эффективность, почему бы не начать внедрение подобной системы с 4-х часового рабочего дня, по 6 рабочих часов? Ведь проводились опыты по сокращению рабочего времени с положительным результатом. Сам для себя проводил эксперимент. При средней мотивации, я делаю намного больше за 6 часов в день, чем за 8. Мысли «ещё два часа и домой» пропадают, как и желание отвлечься. Хватает обеденного перерыва. Но статья говорит нам
>сотрудник должен быть на связи не меньше 8 часов в день
Вот тебе и мотивация. 8 часов должен отсидеть. Если система рассчитана на 100 часов, зачем воровать у программиста оставшиеся 60? В начале недели программист будет прокрастинировать 30 минут в день, к концу 6 часов. Усталость накопится.Source
21.10.2016 14:49почему бы не начать внедрение подобной системы с 4-х часового рабочего дня, по 6 рабочих часов?
Я бы вообще не нормировал время пребывания в офисе. Отработал 5 часов и можешь уходить из офиса с чистой совестью… Даже если астрономического времени ещё только 6 часов прошло.
Да и вообще, фигня все эти 8-часовые рабочие дни… Не зря же в классической книге есть целая глава "С девяти до пяти здесь совершенно невозможно работать"
сотрудник должен быть на связи не меньше 8 часов в день
Да, к этому пункту статьи у меня такая же претензия, можете в моём первом комментарии посмотреть: "Нет необходимости требовать присутствие рядом с компьютером на протяжении 9 часов. Достаточно договориться о 3-4 часах, которые гарантировано фиксированы"
poxu
21.10.2016 14:08Действительно, не надо лукавства. Если вы считаете, что разработчик работает 100 часов в неделю, то считайте исходя из этой цифры почасовой заработок и исходя из неё же оплачивайте овертаймы по двойному ценнику.
Source
21.10.2016 14:36-1Если вы считаете, что разработчик работает 100 часов в неделю
в месяц
то считайте исходя из этой цифры почасовой заработок
я так и считаю
и исходя из неё же оплачивайте овертаймы по двойному ценнику
А вот это не понял… Вы меня с автором статьи что-ли перепутали? Я сейчас не выступаю в роли работодателя.
Хотя как программист не понимаю почему мне должны овертаймы оплачивать по двойному ценнику, если это моё личное желание сколько часов работать.MurzikFreeman
21.10.2016 14:45> не понимаю почему мне должны овертаймы оплачивать по двойному ценнику
Если Вы договорились с работодателем что работать будете только 6 часов в день, но дополнительно проводите на работе ещё 2 часа в день добровольно, то да, он Вам ничего не должен. Но если Вы договорились об оплате только 6 рабочих часов, то принуждение Вас быть на работе ещё 2 часа в день дополнительно, должно оплачиваться как овертайм.Source
21.10.2016 14:57Ну я лично обычно договариваюсь на почасовку по эффективным часам. Принуждение быть на работе уже даже не представляю как может выглядеть, максимум просьба уделить проекту чуть больше времени.
Может быть это я уже с высоты опыта забыл как бывает, но по-моему вполне нормально когда то, что не оговорено заранее, оговаривается отдельно при необходимости.
Но, честно говоря, мне лично проще отказаться от овертайма, если он в напряг, чем запросить двойную ставку.
poxu
21.10.2016 15:04А вот это не понял… Вы меня с автором статьи что-ли перепутали? Я сейчас не выступаю в роли работодателя.
Это обращение не к вам лично, а к гипотетическому работодателю, который думает, что его программисты работают 100 часов в месяц.
Хотя как программист не понимаю почему мне должны овертаймы оплачивать по двойному ценнику, если это моё личное желание сколько часов работать.
Если бы в статье было написано, что можно отработать 5 часов день и спокойно идти домой, то речь была бы о личном желании. А так о нём речи не идёт.
Source
21.10.2016 16:04+1Если бы в статье было написано, что можно отработать 5 часов день и спокойно идти домой, то речь была бы о личном желании. А так о нём речи не идёт.
Да тут имхо недоработка системы… После отработки 100 часов в месяц, если месяц ещё не закончился, можно было бы пару отгулов давать, как дополнительный бонус. Ну и в рамках одного рабочего дня не должно быть обязанности 8-часового присутствия в офисе.
3aicheg
21.10.2016 14:21Плохого в этой системе то, что она, будучи столь же субъективной, как и любая другая система (включая полное отсутствие какой-либо системы), во-первых, лицемерно претендует на некую объективность и, во-вторых, вводит дополнительные сущности, которые можно использовать, чтобы систему загеймить.
Но вообще-то, мы тут упражняем собственное воображение, интерпретируя мысли автора статьи, а может, лучше сперва у него и спросить, что он имел ввиду? Или он нахватал минусов и ушёл в запой? :)Source
21.10.2016 15:00Хз, автор статьи почему-то очень редко отвечает… Видимо его слишком глубоко в минуса загнали.
Но в целом Вы правы, возможно мне нравится именно моя интерпретация этой системы, а не она сама )))
Okrema
21.10.2016 18:26Роман простите меня за минусы) но Вы абсолютно правильно интерпретирует мои мысли.
Предполагаю, что если Вы поняли и смогли так точно передать, то что я хотел донести, то все люди, которые разводят холивар на мою статью, смогут понять, как эффективно можно использовать данную мотивацию. Ведь это только каркас, где руководитель можете отталкиваться всегда от нормального результата при найме, просто эффективность будет пониже.
На своем примере, могу сказать, когда я стал получать в два раза больше, чем хотел изначально, это дало мне большую мотивацию развиваться и показывать крутые результаты.
Этой методикой я поделился, чтобы помочь кому-то выстроить эффективный it-отдел и не быть привязанным к рабочему месту и постоянному контролю своего сотрудника.
Если бы я в своё время не попробовал, то возможно так бы и не узнал, как бывает просто работать, когда сам программист заинтересован в том, чтобы описывать свою работу, а также её оценивать, хотя бы в часах.
Ставьте адекватные зарплаты, применяйте денежные мотивации, они, на мой взгляд, работают, но, конечно же, подходят не всем организациям.MurzikFreeman
21.10.2016 20:03Вам всё же стоит заменить слово «мотивация» на «стимул». Так честнее будет.
ishevchuk
19.10.2016 20:52+12Данная мотивация может применяться, если сотрудник хочет полностью белую зарплату, но не на столько эффективно.
Мне показалось, или автор статьи говорит о том, что белая зарплата не у всех сотрудников в компании?
Garond
19.10.2016 22:30+8Я сам никогда не работал с «балльными» системами и учётом производительности, но так, чисто умозрительно, предположу, что введение подобных систем приводит к повышению эффективности работника в действиях, которые направлены на получение максимального количества баллов, а не на повышение качества или скорости работы.
senya_z
19.10.2016 22:53+6You get what you measure. Если мерять баллами, сотрудники находят способ максимизировать баллы. Помню, во время работы в Microsoft Dynamics CRM одно время эффективность програмиста пытались считать по количеству закрытых багов в неделю. Это привело к том, что на каждый чих программист открывал баг. Надо поменять ресурс в файле — файлим баг, Нужно поменять стиль в CSS слегка — файлим баг. И еще один side effect — реальные сложные баги, требующие серьезного анализа и приличного времени на починку, никто не трогал — не выгодно же.
Source
19.10.2016 23:07-2Насколько я понял, в данной системе баллы — это количество рабочих часов, делённое на 5, за исключением мелких задач, за которые вы не можете отметить меньше чем 0.5 часа, даже если задача "поменять стиль в CSS слегка". Что в принципе разумно, переключение контекста тоже время занимает. Максимизировать баллы система не призывает, т.к. если у Вас уже есть в среднем 24 рабочих часа в неделю, то за дальнейшее увеличение прибавки не будет.
Я тут уже отхватил кучу минусов, но скажите, Вы действительно считаете, что это жутко несправедливо уделять непосредственно работе 4 часа 50 минут из 8 часов рабочего дня?
И сколько тогда по Вашему программист должен в среднем уделять времени работе в рабочий день?senya_z
19.10.2016 23:15+4На мой взгляд, вообще не стоит нормировать день, поскольку мерять вы исполнение нормы все равно не сможете — как понять, бездельничает ли программист в какой-то отдельно взятый момент или обдумывает решение какой-нибудь задачи (это ведь включается в категорию «работать»)? Можно нормировать office hours — время, когда программист должен быть доступен (на случай митингов, вопросов, помощи какой-нибудь), но это совсем не то же самое и к производительности мало относится. 5-минутный (да даже часовой) work-item, который надо куда-то логировать для меня тоже выглядит слегка дико. Задачи такого уровня гранулярности стоят больше времени на бюрократию чем на выполнение.
Source
19.10.2016 23:28-1как понять, бездельничает ли программист в какой-то отдельно взятый момент или обдумывает решение какой-нибудь задачи
Так а зачем это понимать? Насколько я понимаю описанную систему, она позволяет 3 часа бездельничать, 3 часа обдумывать решение и 2 часа его реализовывать. И никаких вопросов это не вызывает. Нормальный адекватный подход. Программисты же не роботы, чтобы 8 часов писать код, как некоторые думают.
Можно нормировать office hours — время, когда программист должен быть доступен (на случай митингов, вопросов, помощи какой-нибудь)
Можно, но это я как раз посоветовал автору статьи не нормировать жестко… для этих целей достаточно закрепить 3-4 часа, а в остальное время можно даже все IM отключать.
5-минутный (да даже часовой) work-item, который надо куда-то логировать для меня тоже выглядит слегка дико.
А как вы ведёте учёт задач? У вас нет плана на итерацию, где отмечается прогресс по каждой задаче? Вписать в ту же форму одну циферку, обозначающую кол-во часов вообще несложно.
Задачи такого уровня гранулярности стоят больше времени на бюрократию чем на выполнение.
Тут есть 2 варианта:
1) тестировщик нашёл баг и естественно завёл для него задачу
2) вы сами что-то обнаружили в процессе выполнения другой задачи, в таком случае нет смысла открывать задачу на мелкий фикс, просто учтёте это время в текущей задаче.
P.S. Вы уклонились от вопроса… Забудьте про системы учёта и оценки… и озвучьте Ваше мнение: сколько в среднем часов/минут в течении рабочего дня работает хороший программист? (подумать, поискать варианты решения и т.п., это всё учитывается в рабочее время; початиться в соцсетях/форумах, почитать Habr/новости и т.д. не считается, если не связано с текущими рабочими задачами)
senya_z
19.10.2016 23:53+5>> Так а зачем это понимать? Насколько я понимаю описанную систему, она позволяет 3 часа бездельничать, 3 часа обдумывать решение и 2 часа его реализовывать. И никаких вопросов это не вызывает.
Ну а теперь представьте, что человек значительно быстрее может это делать. И обдумывает не 3 часа, а полчаса, и код потом пишет не два, а час. По идее, баллов ему по этой системе надо начислить за полтора часа работы, а не за 5. Но нет, проверить никак нельзя, поэтому будет 5. Еще один вывод отсюда — то, что такой человек мог бы сделать за день, он будет делать три дня. Потому что система позволяет.
>> А как вы ведёте учёт задач? У вас нет плана на итерацию, где отмечается прогресс по каждой задаче?
У нас нет итераций как концепции. Мы не исповедуем Скрам. На больших проектах на моей памяти Скрам ни разу не заработал. Задачи у нас есть — план на квартал. Раз в неделю подбиваем текущий баланс — что успели сделать, что еще осталось. Гранулярность уровня «Написать лоад-балансер для уоркеров, запущенных разными клиентами с учетом приоритетов» — пара-тройка недель. Изредка, бывает, бьем задачи на дни, когда нужно тонко выровнять расписание с какой-то другой командой и надо знать, какие части когда войдут в эксплуатацию.
>> Забудьте про системы учёта и оценки… и озвучьте Ваше мнение: сколько в среднем часов/минут в течении рабочего дня работает хороший программист?
Мне сложно усреднять. Очень по-разному. Зависит и от человека, и от дня. Бывает, что вообще ничего в голову не лезет и не получается. День потерян. Бывает, что все в голове сложилось в картинку и забываешь обо всем вокруг и работаешь часов 12. В среднем, наверное, от 3 до 5 часов продуктивного времени в день.Source
20.10.2016 00:48-1Ну а теперь представьте, что человек значительно быстрее может это делать. И обдумывает не 3 часа, а полчаса, и код потом пишет не два, а час.
Если это системно происходит, то на этот случай в статье указано аж 10 градаций уровня разработчика. Ну а если это так удачно звёзды сложились, то и пусть отдохнёт, порадуется, что справился с задачей гораздо быстрее, чем предполагает его текущий уровень.
Гранулярность уровня пара-тройка недель.
Ну, бывает. Но задачу на 2-3 недели можно спокойно дать только очень хорошему миддлу или сеньору, для среднестатистического мидла придётся разбивать на дни, иначе, к сожалению, есть большой риск, что он 2 недели будет балду гонять, а работать начнёт, когда уже по-любому не успеет в срок.
Бывает, что вообще ничего в голову не лезет и не получается. День потерян. Бывает, что все в голове сложилось в картинку и забываешь обо всем вокруг и работаешь часов 12.
Это понятно, поэтому я и спрашиваю про среднее.
В среднем, наверное, от 3 до 5 часов продуктивного времени в день.
Спасибо за ответ. В принципе, когда я работал в офисе, по моим наблюдениям было примерно так же, но при работе на почасовке пришёл к 4-6 часам продуктивного времени в день. К людям, которые утверждают, что могут работать более 120 часов в месяц на протяжении года, отношусь с недоверием :-)
Garond
20.10.2016 00:21+5И сколько тогда по Вашему программист должен в среднем уделять времени работе в рабочий день?
Видите ли, тут речь скорее не о том, сколько должен и сколько работает «на самом деле». А о порочности самого подхода с баллами, т.к. он провоцирует работников направлять свои усилия не на решение задач, а на эффективное получение баллов. Каким способом будут получены баллы — уже не важно. Отсюда растут всякие неувязки, типа «зачем брать большую сложную задачу, если я возьму 5 мелких, решу их и получу то же количество условных единиц эффективности».
Подобные подходы к стимулированию довольно часто встречаются в играх, если грубо, «регулярно нажимай на кнопку, чтобы получать награды». В играх такой подход работает, потому что там цель — удержание игрока и его возврат в игру, т.е. цель — чтобы игрок нажимал на кнопку.
С точки зрения работодателя же целью является конечный продукт, который можно продать. А у него программисты целыми днями баллы зарабатывают, т.е. «жмут на кнопку» вместо того чтобы работать.
Всё вышесказанное не претензия к конкретной системе, а к непродуманности измерения эффективности умственного труда в целом.
Резюмируя, работодателю что нужно, чтобы программисты баллы зарабатывали или продукт делали? Поверьте, эффективные и неэффективные сотрудники и без всяких баллов довольно неплохо видны, если работаешь непосредственно с ними, а не с табличками в трелло.Source
20.10.2016 01:12-1В целом согласен, что и без баллов всё видно. Но не вижу, где тут провокация набирать больше баллов, в статье же указаны уровни, где для получения премии (отличный результат) не надо пахать как папа Карло… для достижения указанного отличного уровня (95 рабочих часов за 4 недели) достаточно не впадать неделями в прокрастинацию.
Не знаю как у них там с практикой применения, но по описанию реально одна из самых адекватных систем, которые я видел.
Попробуйте со стороны работодателя посмотреть на этот вопрос, вот нанимаете Вы профессионального программиста на 100 т.р. в мес, а он первые пару месяцев отлично работал (по 100ч и вы ему +20 т.р. премии платили), а за 3-й месяц отработал только 50 часов, что делать? Сразу уволить? Или заплатить 60 т.р. и посмотреть что в следующем месяце будет?
По-моему второй вариант одновременно и справедлив для обеих сторон и более гуманен для сотрудника.
Отсюда растут всякие неувязки, типа «зачем брать большую сложную задачу, если я возьму 5 мелких, решу их и получу то же количество условных единиц эффективности».
Как правило, зачачи берут по порядку, т.к. они расставлены по приоритетам. Исключения, конечно, возможно, но не в формате анархии "возьму те задачи, которые мне приглянулись".
MaximChistov
20.10.2016 12:22+3>… вот нанимаете Вы профессионального программиста на 100 т.р. в мес, а он первые пару месяцев отлично работал (по 100ч и вы ему +20 т.р. премии платили), а за 3-й месяц отработал только 50 часов, что делать? Сразу уволить? Или заплатить 60 т.р. и посмотреть что в следующем месяце будет?
Ну во первых, кто вам дал право штрафовать на 40% зп?(да и вообще штрафовать) Еще один фанат черной зарплаты? Во вторых — почему вы эффективность меряете тупо часами? Может он эти 100ч страдал фигней и сознательно писал максимально объемно код, а за те 50 — написал тулзу, которая увеличила прибыль компании на 20%?
Поражаюсь этому менеджерскому мышлениюSource
20.10.2016 13:41-21) Я ни разу не менеджер.
2) Я много лет работаю на почасовке и отмечаю к оплате именно эффективные часы, поэтому снижение "зарплаты" в моём случае — это не штрафы, т.к. никакого фикса в принципе нет. Касаемо статьи, ну рассматривайте 60 т.р. как оклад, а вторые 60 т.р. как максимальную премию. Вам неприятна возможность получить премию в размере оклада?
3) Я, как профессиональный программист, искренне не понимаю, почему работодатель должен платить за то время, когда мне неохота работать. Другими словами, я сам работаю в качестве программиста по схеме похожей на описанную в статье. Причём выбрал я эту схему сам, т.к. считаю её наиболее справедливой.
4) Это не дело программиста считать влияние своих коммитов на прибыль компании.
5) Я часто в обсуждениях про почасовку пишу, что в месяц без перенапряга реально работать только 100-120 часов, но почти всегда налетают комментаторы, которые умножают часовую ставку на 176. Однако, как видно по реакции на комментарии к этой статье, очень много людей работают от силы 80 часов в месяц, а то и меньше. Делайте выводы ;-)AlexPu
20.10.2016 13:48>>ну рассматривайте 60 т.р. как оклад, а вторые 60 т.р. как максимальную премию
Вот вы и рассматривайте… А когда подобная нефиксированная часть ЗАРАБОТНОЙ ПЛАТЫ указывается в трудовом договоре, то это означает, что работодатель может распоряжаться этим по своему усмотрению ибо никаких гарантий обратного просто напросто нет. Найзывайте это премией или штрафом — без разницы. В тех странах, где трудовое законодательство не является пустым звуком подобные вещи наказываются досвольно сурово (причем даже в том случе, есди до практической реализации еще не дошло — каранется сама попытка)Source
20.10.2016 14:30-2А я и рассматриваю. Я ж написал, что работаю на почасовке. Сколько часов наработал, за столько и получил. В договоре указана часовая ставка, впрочем он не трудовой, а подряда (contractor agreement).
AlexPu
20.10.2016 17:22Ну вы не просто рассматривает! Вы предлагаете рассматривать мне!
Source
20.10.2016 18:40-2Ну, не лично Вам… Хотя я не понимаю на что Вы намекаете, на то, что лично Вам интересен исключительно фиксированный оклад в месяц (даже если по другой схеме оплаты Вы могли бы получать условно в 1.5 раза больше), или на то, что 100 рабочих часов в месяц — это нереально много?
AlexPu
21.10.2016 16:20У вас очень бедная фантазия… проистекающая из неспособности прочесть написаное
Source
22.10.2016 02:06-1Скорее это у вас излишне неуёмная фантазия, что вы придумываете то, что не было написано, и начинаете с этим спорить… Почитайте хоть ТК РФ на досуге для развлечения, а то на его тему вы тоже чего только не нафантазировали xD
Merkat0r
20.10.2016 13:46+1В следующем месяце вы с вероятностью 99.9% получите заявление по собственному.
Эффективные менеджеры — хватит уже мерять нормочасами(в большинстве случаев под человекочасами у них все теже нормочасы), оно тут не работает, как бы вы не хотелиOkrema
20.10.2016 13:54-1Поэтому я советую использовать баллы и оценивать коэффициент скорости своей команды. Товарищи, планирование никто не отменял. Оценивать задачи нужно, хоть в яблоках.
По поводу заявления по собственному. Если вы эффективный руководитель, то возможно вам не стоит слепо следовать инструкциям, возможно у сотрудника проблемы в семье или еще какая-то ситуация, поэтому он 4 недели прокрастинировал и не отмечал баллы. Вы это сразу увидите, пообщайтесь с ним, выплатите всю зарплату, дайте ему время прийти в себя. Но если уже 4 месяц не приходит в себя, перестаньте ему платить бонусы, и он сам без ссор уволится.
3aicheg
20.10.2016 09:32+1>эффективные и неэффективные сотрудники и без всяких баллов довольно неплохо видны, если работаешь непосредственно с ними
Вот только восприятие это искажено, особенно если работаешь непосредственно с ними. Допустим, вот Вася — он мудак, но при этом отлично работает. А Петя вообще не работает, но зато человек-то какой хороший!!! Поди их беспристрастно оцени.
janson
19.10.2016 22:31+7В карате наоборот: в ученических ступенях нумерация по убыванию (9-й кю — это белый пояс, а 1-й кю — коричневый), а в ступенях мастера (даны) как раз по нарастающей.
По статье: система удобна тем, что понятна и прозрачна со стороны расчётов. Но также она вполне выступает мотиватором для «побольше наколбасить». Тут уже степень говнокодирования зависит в большой степени от того, насколько часто приходится лазить в свой же код и работать с ним: если часто работаешь с одним и тем же клиентом, то говнять не захочется лишний раз — проще потерять в деньгах сейчас, но быстрее сделать потом.
Ну и по ощущениям: на этапе роста программиста эта система может быть привлекательной. Но когда появляются более интересные и объемные задачи, требующие изучения и продумывания (research), то такая система начинает мешать.
amaksr
20.10.2016 00:31+3IT по своей природе слишком сложно, чтобы можно было вот так вот придумать какие-то баллы, эсэлэи или другие метрики и адекватно по ним что-то оценивать.
Например, можно быстро что-то накодить путем копипаста, и не заморачиваясь особо на архитектуру, сэкономив тем самым на разработке. Баллы и прочие метрики будут высокие. Но потом затраты на саппорт плохо написанной системы могут превысить первоначальную экономию в разы.
В случае саппорта можно тоже работать на закрывание тикетов, чтобы SLA и прочие метрики соблюсти, но метрики не всегда кореллирует с удовлетворением клиента от вашей работы. И если вами недовольны, клиент с вами расстанется несмотря ни на какие баллы.
Оценка трудоемкости задач вообще отдельная тема, так как в ИТ всегда есть фактор неизвестности, обусловленный тем, что в процессе разработки могут выявиться ранее неизвестные ограничения. Например, запросто бывает, что чтобы добавить маленькую фичу в программу приходится переходить на новые версии фреймворков, решать проблемы обратной совместимости, рефакторить и переписывать работающий код.
Поэтому баллы это прикольно, но всей картины они не дают.
Вообще же, хороший тим лид обычно и без баллов знает, кто у него в команде в чем силен или слаб, и соответственно распределяет задачи по сотрудникам. И если кто-то халявит, тим лид про это уж точно будет знать.
TheShock
20.10.2016 07:40+3Например, можно быстро что-то накодить путем копипаста, и не заморачиваясь особо на архитектуру, сэкономив тем самым на разработке. Баллы и прочие метрики будут высокие. Но потом затраты на саппорт плохо написанной системы могут превысить первоначальную экономию в разы.
При чем получать бонус будет плохой разработчик, которому плевать на проект, а хороший разработчик, который думает о будущем — будет получать уменьшение зарплаты, а потом еще и переделывать за плохим. Короче, система поощряющая плохое качество продукта. И зачем она нужна?poxu
20.10.2016 08:09+3Короче, система поощряющая плохое качество продукта. И зачем она нужна?
Ну из статьи же понятно всё. Есть демка, которую проводят менеджеры каждые 2 недели. На этой демке надо показать, как много сделано за эти две недели. Чем больше сделано, тем круче менеджеры. Вот для того, чтобы можно было больше показать — для этого вся система. Что там внутри — неважно. Да, со временем разработка будет идти всё тяжелее, но это неважно, потому что орлы, которые придумают как за 2 недели что-нибудь именно показать, а потом гори оно синим пламенем — обязательно найдутся. А общее замедление темпа всегда можно списать на криворуких дебилов с низким коэффициентом.
Ну и плюс такие системы обычно выстраивают так, чтобы людей с высоким коэффициентом было немного — это ж какая экономия получается. Вон же в статье написано.
Основная идея заключается в том, что сотрудник получает фиксированно только половину зарплаты.
Всё так и есть, только основная идея заключается в том, чтобы всю зарплату целиком никому не платить :). Вот приходите вы на собеседование, договариваетесь о зарплате (которая судя по статье небелая). А на второй рабочей неделе узнаёте, что реально получите только половину. Эффективный менеджмент торжествует!
KoCMoHaBT61
20.10.2016 06:39+3Тут люди раскритиковали систему с практико-технической точки зрения. Добавлю ещё один аспект…
Менеджеры данной конторы вынуждают программистов играть в крысиные бега на свою программистскую зарплату. Очень эффективный подход.
KoCMoHaBT61
20.10.2016 06:43+6Правильнее было-бы — коэффициенты применять, но за снижение производительности по этим коэффициентам штрафовать менеджеров. Это заставит менеджеров заниматься своими обязанностями, а не придумыванием идиотских мотивирующих систем.
TheShock
20.10.2016 07:38+14Рассмотрим на примерах, если сотрудник претендует на зарплату в 80000 рублей, я могу предложить ему пояс: 5кю. При этом после...
То есть, если разработчик претендует на 80000, то вы ему предлагаете 40000 с призрачной возможностью бонусами получить таки его желаемую зарплату? Хуже всего в статье — лицемерие. Правдивая картинка такая:
То есть у вас нету увеличения зарплат. У вас есть только уменьшение.Source
20.10.2016 13:52-1Вот тут соглашусь. Это недостаток практического применения системы в конкретной компании.
Если разработчик претендует на 80 т.р., то это скорее 8кю. При эффективной работе сотрудник должен получать существенно больше, чем люди того же уровня, пинающие балду в другой компании.Okrema
20.10.2016 14:15В точку. Если вы хотите, чтобы эта мотивация круто работала. Вам нужно предлагать зарплаты выше по рынку (в табличке представлена зарплата для регионов России), как эта описывала в своей культуре компания NetFlix. Тогда вы сможете собрать талантливых разработчиков, которые привыкли работать, а не прокрастинировать.
Source
20.10.2016 14:35-1Я думаю, если бы Вы указали числа для Москвы, которые в 2 раза выше, реакция на статью была бы более позитивной… А то люди, работающие на Москву, Питер, заграницу, сравнили со своими зарплатами и испугались )))
AlexPu
20.10.2016 09:29+4Я могу ошибаться (и наверное это так и есть — ведь работает же комманда по описаной технологии?!), но все выглядит как попытка мотивировать разработчика не на работу, а на побочную деятельность по выставлени. каки=-то там баллов… И мухлежа с оными баллами конечно — я например сразу усмотрет два отличных способа не особо напрягаясь иметь некое минимально необходимое для комфортного существования баллов… Чуть напрягаемся и сразу становится хорошо… на бумаге… о кстати — третий способ измыслил…
Чем старше я становлюсь тем более убеждаюсь в том, что все попытки заставить (именно ЗАСТА/ВИТЬ, хотя в статье это именуется «мотивировать») работника заниматься учетом собственной работоспособности проистекают из низкого качества менеджемента… т.е. менеджеры придумывают всякие метрики согласно коиторым они молодцы, а если что идет не так (т.е. всегда), то это не они виноваты, а рядовые сотрудники которые не так пользуются мекой супер-пупер методикой…
boodda
20.10.2016 09:58Люто плюсую!
Вам, кстати правильно указали на то, что вы подменяете понятия.
Можно по разному преподнести вашу методу.
1. Зарплата в нашей организации от 20 до 65. С возможностью получить премию до 100%(не высокая зарплата, хорошие бонусы)
2. Зарплата в нашей организации от 40 до 130. Штрафы за срыв сроков до 50%(большая зарплата, жесткие штрафы)
Но в первом случае человек, который может получить бонус, будет к нему стремиться любым путем.
Во втором же случае человек, который хоть раз получил штрафные санкции, сразу задумывается об уходе, получая мощнейший демотиватор.
Как вы преподносите это программистам?
Мое же личное мнение, что всегда и везде достаточно хорошего начальника, чтобы все работало как надо. Без всех этих сложных танцев с бубном. Если начальник видит, что чел не тянет, надо прощаться. Так как в любую систему можно обойти и подстроиться для получения максимальной выгоды, при минимальных затратах. А усложнение системы, ведет только к более изощренным способам обмана.AlexPu
20.10.2016 10:59-1>>Как вы преподносите это программистам?
Лично мне это преподнести не удастся никак — ни в первом ни во втором случае.
Более того — оба случая противозаконны в той стране, где я проживаю. Нечто похожее (очень-очень отдаленно похожее) практикуют крупные компании типа Нокии — там выплачиваются ежегодные (иногда ежекварталтные) бонусы, размер которых зависит от неких KPI (как они считаются это другой вопрос, ноточно не так как описано в статье) и от прибыли, которую получила компания за отчетный период… Причем последнее первично — компания просто делится прибылью, если она есть со своими работниками. Но если кто-то работал лучше, получает больше… немного… чем другие… которые работали хуже… или не работали совсем… Это ч к чему? К тому, что упомянутый бонус не является тем, ради чего наемные служашие подписывают контракт — это приятное дополнение не более того. Иногда дополнение даже очень приятное но при этом все равно остается дополнением
Durimar123
20.10.2016 11:51+1Проблема в том что все подобные методики, не дают полной привязки сложности работы к баллам, а лишь симулируют наиболее очевидные для менеджеров аспекты.
А учитывая, что большинство программистов еще в детстве наигралось в симуляторы, и хорошо понимают значение слова манчкин, очень быстро система будет использована себе во благо, сначала скромно, а затем оглядываясь на соседей, по полной программе.
В данном случае, себе будут прописываться задачи с наиболее завышенными баллами, а врагам народа коллектив будет занижать.
На качество все будут класть большой болт, так как исправление багов это тоже очень сложная и долгая работа, что хорошо для зарплаты.
Ну а попытки менеджеров наклонить систему в свою пользу упрутся в то, что в большинстве случаев у программистов и интеллект повыше и знание предметной области куда больше. Загрузят так, что лапши на пару лет хватит.
И неважно как будут меняться правила начисления этих бонусов, программисты это эксперты в реализации задач при самых убогих условиях, систему в свою пользу нагнут в любом случае.AlexPu
20.10.2016 13:35+1>>В данном случае, себе будут прописываться задачи с наиболее завышенными баллами, а врагам народа коллектив будет занижать.
А ведь есть еще вариант с управляемым внедрением багов… Я бы лично именно этим в первую очередь бы и занялся — у меня было бы охрененное количество задачь, пускай и дешевых с точки зрения пресловутых багов, но зато с минимально необходимым ФАКТИЧЕСКИМ временем на устранение… Не поймите меня превратно — я в отрасли уже 24 года, и все 24 года я разработчик… я с закрытыми глазами себе таких задач наклепаю, а со стороны все будет выглядеть совершенно естественным образом…
MurzikFreeman
20.10.2016 12:15+4Какой изощрённый демотиватор, однако. Мне всё больше кажется, что некоторые менеджеры просто перестали понимать значение слова «мотивация». Или мотивация, не сама цель, а все эти системы, лишь желание спихнуть как можно больше ответственности на сотрудников? Очередное «Ура! Мы заменили кнут на пряник! Теперь мы лупим их по рожам пряником вместо кнута!». Почему, чтобы сотрудник просто получил за свою работу положенные ему деньги, в полном объёме, ему не достаточно просто хорошо работать? Почему обязательно придерживаться каких-то метрик? Чтобы в любой момент, по желанию левой пятки менеджера, ему могли выплатит меньше, потому что он, якобы, не вписался в какую-то метрику?
Okrema
20.10.2016 12:55-2Менеджер не может выплатить меньше зарплату, если разработчик отмечает 5 часов в день. У руководителя нету такой возможности. А вот если разработчик обманывает, долго выполняет задачи, ведет себя неадекватно и показывает в среднем плохой результат по субъективным метрикам, то может его уволить.
Метрики в нашей стране нужны для эффективного планирования.AlexPu
20.10.2016 13:40+3метрики в вашей стране (и в любой другой впрочем тоже) нужны только для двух вещей:
1) для того, чтобы прикрыть задницу руководителя, если вдруг что-то пойдет не так (это не я виноват, а составители методики или неправильные пчелы, которые делают неправильные метрики)
2) До того, как что-то пойдет не так, демонстрировать вышестоящему начальству рост этих метрик прозрачно
намекая на необходимость материального стимулирования этого самого руковожителя. Самоле лучшее если данный руководитель в результате таких уходит на повышение (иди в другую компанию даже) накануне того, как что-то пойдет не так
Okrema
20.10.2016 14:09-1Мы, к примеру, планируем каждые две недели, составляем план, оцениваем задачки в баллах (фруктах, в чем угодно). На основании этого определяем реально возможную загрузку сотрудника на итерацию. Ставим себе реальные цели, которых пытаемся достичь.
Интересно, как вы планируете, если для вас метрики, это только, чтобы задницу руководителя прикрыть?AlexPu
20.10.2016 14:18+3Как планируем* Да очень просто — у нас попросту принято доверять сотрудникам… И если вдруг случится, что сотрудник теряет доверие (этого нужно довольно упорно добиваться), то такого сотрудника попросту увольняют Странно правда? И даже дико наверное… для вас…
MurzikFreeman
20.10.2016 15:16Месячные итерации. Мы планируем точно так же, только вместо фруктов, часы. И это сразу даёт возможность запланировать без подсчёта метрик в бегемотах. Руководство доверяет нам. Мы доверяем руководству. Если задача выполняется с задержкой, стараемся предупредить руководителя об этом как можно раньше. Границы итерации могут быть сдвинуты или задачу перенесут на следующую итерацию. Если задачи выполняются раньше срока, появляется возможность добрать в итерацию не вошедшие в неё, но уже оценённые задачи или закрыть итерацию раньше. Всё хорошо и без всяких метрик.
Source
20.10.2016 18:42-1А если оставить всё тоже самое, как Вы описали, и сверху выплачивать премию тем, кто 100 часов в месяц отработал, станет сильно хуже?
AlexPu
21.10.2016 16:22-1Безусловно хуже… Причем радикально хуже! Причем и для компании тоже радикально хуже… Но для отдельных менеджеров, профессионализм которых… скажем так не на высоте — вот ля них будет лучне
voopr
20.10.2016 12:15+1Отработал на оценку «хорошо», получи штраф -15%
Заболел, получи штраф -50%
Хорошая система.Okrema
20.10.2016 12:45-2Если сотрудник заболел, мы должны вычесть баллы с учетом количества дней, которые он не работал. В противном случае, как вы уже правильно заметили, это будет демотивация. Это обсуждается на собеседование, после чего вопросов не возникает. При этом я придерживаюсь минимальной бюрократии, так что сотруднику необязательно брать официальный больничный.
Отпуска, как и во всех компаниях должны полностью оплачиваться.
По поводу оценок. Если сотрудник отмечает 5 часов в день, он в априори не может получить получить «хороший» результат. По поводу оценки результатов, существую субъективная оценка, которая представляет из себя пояс, по ней вы можете повышать вашего сотрудника.AlexPu
20.10.2016 13:43+1Вам здорово повезло, что вы не работаете в какой нибудь Финляндии — здешние профсоюзы вас бы уже освежевали :)))
Okrema
20.10.2016 14:26-4Мы работаем в России. Ставьте адекватные зарплаты и проблем не будет.
AlexPu
20.10.2016 17:19+2Вот я и говорю — вам очень повезло… В РФ сама идея соблюдения трудового законодательства кажется несерьезной идеей… Надеюсь что это не всегда так будет…
poxu
21.10.2016 08:32Неплохо всё в РФ с трудовым законодательством. С его соблюдением хуже, но тоже неплохо. В Европе какой-нибудь тебя могут на совершенно законных основаниях уволить с предупреждением за месяц. И пожаловаться даже некому будет.
AlexPu
21.10.2016 16:23Цитирую: В РФ сама идея СОБЛЮДЕНИЯ трудового законодательства кажется несерьезной идеей…
poxu
21.10.2016 16:48Тем не менее его соблюдают.
AlexPu
21.10.2016 16:57+2Серьезно да? А ничего, что данная статья реклапирует прямой и недвусмысленный способ нарушения трудового законодателльства?
poxu
21.10.2016 17:49Плюсанул :). Но вообще-то законодательство будет нарушено, если платить будут меньше, чем написано в договоре. Или если уволят без причины и без выходного пособия.
А тут юридически система премирования. Она законодательство не нарушает.
ultrinfaern
20.10.2016 12:15Расскажите какова текучка кадров?
Ну и насколько комплекс состоит из костылей?Okrema
20.10.2016 12:32-1Добрый день!
Текучка кадров происходит, если вы вводите не с нуля данную мотивацию. Объяснить программистам, которые привыкли получать зарплату и при этом никак не фиксировать свою работу поначалу будет сложно. Поэтому резко вводить данную мотивацию не советую. Даже правильнее будет не вводить данную денежную мотивацию, если программист показывает хорошие результаты итак. Но фиксировать выполненные задачи и оценивать задачи для эффективного планированию, к сожалению, прийдется. Увы, это необходимость.
Из тех программистов, которых мы нанимали с нуля и сожали на данную мотивацию, текучки кадров нет, так как правильно отметил Source (Роман Смирнов), что мы не отмечаем за программиста потраченные баллы и не заставляем работать по 8 часов в день, тем более не стоим над душой, требуя быть постоянно на рабочем месте.
Смотря, что вы имеете в виду под костылями. В этой статье не описан SCRUM, здесь не описаны субъективные метрики, которые у нас выстраиваются на адекватной оценке персонала с учетом культуры it-отдела, интересные задачи, архитектурные особенности проектов.
Также я не описывал нюансы при найме сотрудников. А они определенно есть, прийдется научиться работать с возражениями, но это поможет в дальнейшем избежать недопониманий и текучки.KoCMoHaBT61
20.10.2016 15:01Объяснить программистам, которые привыкли получать зарплату и при этом никак не фиксировать свою работу поначалу будет сложно.
Это попытка переложить ответственность с менеджеров на программистов. Так-же как и
фиксировать выполненные задачи и оценивать задачи для эффективного планированию
В половине комментов, кстати, задан вопрос — кем и как осуществляется эстимейт задачи.
gpixel
20.10.2016 14:28Проблемы начнутся когда такая «система» наткнется на человека, который объективно работает больше чем на ваши условные 130к. В такой ситуации он столкнется только с демотивацией и чем ближе к верхнему порогу, тем призрачней становятся дальнейшие перспективы.
Okrema
20.10.2016 14:34-1В статье описан каркас с практическим применением. Можете уже дальше навешивать и докручивать, как сами хотите. Просто при грамотном внедрении она работает.
Я, к сожалению, редко встречаю в российских компаниях хоть какой-то намек на денежный рост, а тем более отображенный в табличном виде.
Source
20.10.2016 14:47-1Тут есть 2 варианта:
1) поскольку в табличке числа указаны для провинции, то скорее всего у компании просто нет таких ресурсов и/или таких задач, на которые нужны высокооплачиваемые специалисты, т.е. одним словом overqualified.
2) для московских компаний числа в табличке можно удвоить, а саму табличку экстраполировать до мастера международного уровня с диапазоном от 175 до 350 т.р.
Dolbe
20.10.2016 14:52Раз уж статья называется "как перестать беспокоиться о неэффективных сотрудниках?", то чего Вы все от нее хотите? Тут даже в названии сказано, что она для удобства работодателей, а не сотрудников =)
fogone
20.10.2016 17:42+2Рассмотрим на примерах, если сотрудник претендует на зарплату в 80000 рублей, я могу предложить ему пояс: 5кю.
Серьезно? Если человек претендует на 80к, то по вашей табличке вы должны ему предложить хотя бы «мастер», иначе вы не мотивируете человека, а демотивируете потенциальной возможностию сокращения его дохода. Мне кажется, любой уважающий себя человек, если только он не рассчитывает в действительности на 40к на такое не согласиться.AlexPu
20.10.2016 17:49+2>>Мне кажется, любой уважающий себя человек, если только он не рассчитывает в действительности на 40к на такое не согласиться.
Вам не кажется — так оно и есть на самом деле. Любой адекватный человек, имея минимальный опыт работы по найму воспримет это как з/п 40 тыс плюс, если повезет — больше. Причем все разглагольствования про вознаграждение зща то что он будет хорошим такой человек пропустит мимо ушей — он будет понимать это именно так как оно есть на самом деле — некая сумма играющая роль морковки перед мордой осла. А факт получения или неполучения этой необязательной части он будет связывать исключительно с произволом работодателя
Okrema
20.10.2016 18:52У разработчика есть испытательный срок, чтобы это проверить. Предложите ему больше, чем он рассчитывает, и пусть решает сам по результатам первой демки, выполняет ли компания обязательства, на которые подписалась.
По началу сложно решиться предложить работать по такой мотивации, так как нужно быть реально подготовленным отвечать на вопросы. После того, как сотрудник уже начинает работать, вопросы отпадают сами собой.
Товарищи, вы реально думаете, что у нас все разработчики в стране зарабатывают больше 100 000 руб.?
Зачастую у нас в компании зарплаты выше, чем по региону.poxu
21.10.2016 08:20У разработчика есть испытательный срок, чтобы это проверить.
А с какой целью вы упомянули испытательный срок? Что бы изменилось, если бы его не было?
chieftain_yu
21.10.2016 14:42+1Он может оценить только выполняет ли компания свои обязательства сейчас. Ну, может, в прошлом…
Точно так же индюшка может быть уверена на основании своего опыта, что хозяин каждое утро ее кормит. Но потом приходит 4-й четверг ноября…
Если вы даете конкурентный оклад — это еще может работать. Но если вы даете оклад ниже рынка с увещеванием насчет перспектив и всего такого — то более-менее сообразительные смекнут, что в окладе-то они могут быть уверены, а вот во всем остальном — как повезет…
vyatsek
20.10.2016 18:54+1В таком подходе цена идеи или инновации равна нулю и вообще не оценивается. Например есть желание что-то улучшить/понять как работает, расширить знания по коду — это не оценивается и вообще нафиг не надо.
Выгодно пилить свой кусок кода, в котором ты знаешь 100% и сможешь сделать на 30%, чем остальные, у остальных подход точно такой же.
У менеджера с отношение к программисту как в интику, на выходе продукт будет г-но.
deniskreshikhin
Спорная методология.
Можно подумать, что те программисты которые у вас работают за 130к самые мотивированные. Но это ошибка, т.к. если бы они были действительно мотивированные, то могли бы за полгода подтянуть разговорный английский и найти самую обычную удаленку на 400к в месяц (80k$ в год) без всяких там баллов и т.п. фигни.
Поэтому скорее всего у вас две категории работников — джуниоры которым нужна любая работа и бездельники, которым лень учить английский и вообще повышать квалификацию, а проще подстроиться под эту бальную систему.
Source
Хм, и сколько лет Вы работаете на такой самой обычной удалёнке?
deniskreshikhin
Столько что в данный момент могу позволить себе не работать =)
Source
Ну ok, 2-3 месяца в таком режиме отпахали и сдулись, понимаю :-D
llvp
Откуда вы взяли эту информацию вообще? Зачем придумывать, если человек который _точно_ знает — прямо перед вами?
Source
Человек, который пишет, что $80k в год — это обычная удалёнка, по всей видимости не проработал на удалёнке и года, а экстраполировал удачный доход за один или несколько месяцев. Чтоб Вы понимали, $80k в год на удалёнке — это вполне средний показатель для резидентов США уровня Senior, и оутсорсить в Россию при такой зарплате тупо не имеет экономического смысла. У резидентов США и уровень английского по-любому лучше, и разница во времени гораздо меньше, и бумажной волокиты с ними не будет и т.д.
Так что даже если допустить, что Денис прекрасно устроился и выдержал год, то всё равно его комментарий закладывает неадекватные ожидания для тех, кто примет его за чистую монету. Правда в том, что обычная (среднестатистическая) удалёнка — это $30-40k в год. Нравится играть в самообман — пожалуйста. Хотите стать статистическим исключением — пожалуйста, шансы есть.
Xandrmoro
У меня отличный разговорный английский, куда записываться?
(серьёзно)
deniskreshikhin
https://www.linkedin.com/jobs/search?keywords=Remote
https://remoteok.io/
https://goremote.io/
https://weworkremotely.com/
http://jobs.remotive.io/?category=engineering
http://stackoverflow.com/jobs?allowsremote=True
https://jobs.github.com/positions?description=&location=remote
https://angel.co
https://coderwall.com/jobs
https://news.ycombinator.com/jobs
и
Твиттер #remote #job
VioletGiraffe
Спасибо за ссылки!
MaximChistov
Спасибо. А вы про свой опыт нигде не писали?
norlin
Вот, если ещё не пробовали: https://hola.org/jobs