Как стать автором
Обновить

Мотивация каратистов: как перестать беспокоиться о неэффективных сотрудниках?

Управление проектами *Agile *Управление e-commerce *Развитие стартапа Управление персоналом *
Recovery mode
Tutorial
Всего голосов 38: ↑15 и ↓23 -8
Просмотры 8.9K
Комментарии 124

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

НЛО прилетело и опубликовало эту надпись здесь
могли бы за полгода подтянуть разговорный английский и найти самую обычную удаленку на 400к в месяц (80k$ в год) без всяких там баллов и т.п. фигни.

Хм, и сколько лет Вы работаете на такой самой обычной удалёнке?

НЛО прилетело и опубликовало эту надпись здесь

Ну ok, 2-3 месяца в таком режиме отпахали и сдулись, понимаю :-D

Откуда вы взяли эту информацию вообще? Зачем придумывать, если человек который _точно_ знает — прямо перед вами?

Человек, который пишет, что $80k в год — это обычная удалёнка, по всей видимости не проработал на удалёнке и года, а экстраполировал удачный доход за один или несколько месяцев. Чтоб Вы понимали, $80k в год на удалёнке — это вполне средний показатель для резидентов США уровня Senior, и оутсорсить в Россию при такой зарплате тупо не имеет экономического смысла. У резидентов США и уровень английского по-любому лучше, и разница во времени гораздо меньше, и бумажной волокиты с ними не будет и т.д.
Так что даже если допустить, что Денис прекрасно устроился и выдержал год, то всё равно его комментарий закладывает неадекватные ожидания для тех, кто примет его за чистую монету. Правда в том, что обычная (среднестатистическая) удалёнка — это $30-40k в год. Нравится играть в самообман — пожалуйста. Хотите стать статистическим исключением — пожалуйста, шансы есть.

У меня отличный разговорный английский, куда записываться?

(серьёзно)
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за ссылки!
Спасибо. А вы про свой опыт нигде не писали?

Вот, если ещё не пробовали: https://hola.org/jobs

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

В результате компания теряет настоящих программистов, приобретая игроков в крысиные бега.

Вот, например, кем проводится оценка трудоёмкости задачи?

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


И исследования уже есть, демонстрирующие, что привязка зарплаты к эффективности программиста ухудшает результаты и опыт крупных контор — всё пофигу в общем.

Непонятно, что такое эта «эффективность программиста». Эффективных менеджеров мы знаем — подгрызть, понадкусать всё, что надкусывается, а потом быстренько свалить, когда конструкция начнёт падать.

Что такое «эффективный программист»? Программист выигрывающий в менеджерские игры? Программист-математик? Программист-архитектор? Программист-художник? Программист-оптимизатор? Программист-конвеерщик?
Кто из них «эффективный»?

В экспериментах просто замеряли скорость выполнения задач с неочевидными решениями. У тех, кого премировали за время и у тех, кого не премировали.

Отличная система! С адекватными параметрами.
Максимум эффективности находится в районе 100-110 эффективных рабочих часов в месяц. Что как раз соответствует 20 баллам по вашей системе. При почасовке к этой схеме естественным путём приходишь, а вот при фуллтайме в офисе сотрудники частенько ограничиваются имитацией бурной деятельности, так что доп.мотивация им не помешает :-)

К примеру, Иван работает с 9:00 до 18:00, в это время я ожидаю, что он будет на связи.
На связи — это онлайн или на телефоне? Тут есть простор для небольшого смягчения. Нет необходимости требовать присутствие рядом с компьютером на протяжении 9 часов. Достаточно договориться о 3-4 часах, которые гарантировано фиксированы (на это время можно запланировать совещания/консультации/etc.), а в остальное время не отвлекать сотрудника, если нет никакой аварии на production.

Я так понимаю, минусуют те самые офисные программисты (склонные к ИБД), которые в месяц не способны наработать 100 часов… и видят в этой статье угрозу собственному раздолбайству. А по существу ничего возразить не могут :-)

Черт, как же вы раскусили-то?

А кто определяет сколько стоит задача в баллах? В реальности может случиться, что стоимость задачи была недооценена или переоценена. В первом случае сотрудник будет мотивирован сделать абы как, лишь бы быстро, а во втором он просто будет отдыхать.

Как по мне, то такая система не мотивирует делать качественный продукт, но мотивирует делать все быстро «тяп-ляп и готово».
А кто определяет сколько стоит задача в баллах?

В статье же указано "объективную оценку, которую отмечает сам разработчик по окончанию задачи, выраженную в потраченных баллах". Т.е. в зачёт идёт фактическое кол-во отработанных часов, вне зависимости от прогнозов.

Как мы понимаем, недостаточно подсчитать баллы для определения эффективности разработчика.

Так и не понял, а что вы делаете для определения эффективности, если не баллы считаете?
А кто запрещает сотруднику постоянно переоценивать свои фактически затраченные силы? Как происходит контроль?
время потраченное на написание кода и обмозгование задачи

Не знаю как у других, но в моей работе постоянно приходится сталкиваться с задачами, для решения которых надо думать 80% времени, а кодировать 20%. Если бы на моей работе была бы такая же система, то мне бы просто перестали верить, хотя я честно пару часов могу думать над задачей, что-то изучать, а потом за 30 минут написать 50-100 строчек эффективного кода.

Я не имею отношения к автору статьи. Но он пришёл к системе, которая мне близка и понятна. Поэтому могу свой взгляд высказать… Как правило, во главе команды есть тех.лид или технический директор, это человек с огромным опытом программирования, которого невозможно систематически обманывать с оценками задач, потому что он понимает какому уровню сколько реально часов нужно на конкретную задачу. Если задача занимает много времени, то адекватный программист укажет в комментариях к задаче с какими сложностями он столкнулся, а не просто поставит в 3 раза больше времени, чем ожидалось.


в моей работе постоянно приходится сталкиваться с задачами, для решения которых надо думать 80% времени, а кодировать 20%

Вы думаете, что удивите этим фактом хоть одного тех.лида? Это вполне нормальное соотношение для широкого круга задач.
В этом плане описанная в статье методика вполне адекватна, т.к. не привязана ни к кол-ву строк, ни к нажатиям клавиш, ни к времени проведённому неотрывно за клавиатурой.

> потому что он понимает какому уровню сколько реально часов нужно на конкретную задачу

А такого, что за пару часов сделал 99% задачи, а потом ещё пару дней бьёшься лбом об монитор, пытаясь домучить оставшийся 1% у вас что, не бывает? И ладно ещё, если сам накосячил — допустим, ваш ведущий технический провидец, зная мой уровень, способен это предсказать. А то проявит себя какой-нибудь малоизвестный, нелогичный и нигде не описанный косяк используемой библиотеки, с которым раньше никогда не сталкивался — тех. лид. знает наизусть все эти косяки, а так же помнит, какие из них знает кто из его разработчиков?
Пара дней — это еще терпимо, и можно пережить. А мы как-то с бывшим начальником над тренировкой набортной DDR3 на новом AMD APU просидели 5 недель подряд, пока она не завелась (в связи с чем хочется передать пламенный привет тому, кто придумал AMD PMU и догадался инициализировать память через PSP).
Получается, за этот месяц нам обоим надо бы ЗП ополовинить? В таком случае в следующий раз подобный проект будет признан неподъемным после трех попыток, а потраченная на него шестизначная сумма в евро пойдет в убыток.
Короче, тут уже говорили несколько раз, что введение метрик, влияющих на зарплату, ведет только и исключительно к оптимизации по ним. Если вас это устраивает — дело ваше. Если же нет, обыкновенного performance review раз в полгода-год вполне достаточно, на мой взгляд.
А такого, что за пару часов сделал 99% задачи, а потом ещё пару дней бьёшься лбом об монитор, пытаясь домучить оставшийся 1% у вас что, не бывает?

Вы невнимательно читаете: "Если задача занимает много времени, то адекватный программист укажет в комментариях к задаче с какими сложностями он столкнулся". В целом, если Вы столкнулись с такими трудностями, что безрезультатно "пару дней бьёшься лбом об монитор", необходимо сообщить об этом начальству, а то так можно целый месяц биться… при этом может оказаться, что добавленная компетенция решит её за пару часов (во всяком случае бывало и такое).

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

Вон выше CodeRush пишет, как 5 недель просидели над проблемой. У меня тоже бывали случаи. Как правило, помочь в такой ситуации не может никто. Начальник спрашивает, когда решу проблему — честно отвечаю, что как повезёт. Есть пара томов документации на почитать — возможно, ответ будет на первой странице первого тома, а возможно — на последней странице второго. А возможно, ни там ни там не будет. Есть десяток идей, как заставить всё работать, проверяю их по-очереди — возможно, правильной окажется первая же, возможно — последняя. А возможно, все десять будут мимо. И никакое абстрактное «тимлидство» не поможет начальнику понять, правду я говорю или 2.7бу мозги — ему надо быть либо глубоким экспертом в конкретно этом вопросе, либо отложить все свои дела и плотно вникнуть в мою задачу. Либо и то и другое сразу!

Или вот недавний совсем случай из собственной практики. Понадобился +1 человек на задачу низкоуровневой оптимизации кода под конкретное железо. Меня спрашивают: «Ну что, возьмёшься?» Говорю, никогда раньше такими задачами всерьёз не занимался, взяться могу, но сами понимаете. Понимаем, говорят, у нас все, кто такими задачами всерьёз занимался, уже ими занимаются, а из оставшихся тоже никто не умеет, так что давай. Вот я думаю, стал бы я браться за это нужное дело, если бы мне за него баллы начисляли? Сидят эксперты, типа, они бы за пару часов сделали, над чем я с непривычки буду неделю страдать, и то не факт, что выйдет. Пытаться всеми силами спихнуть задачу на кого другого или торговаться, чтобы мне больше баллов за это начисляли, чем я объективно заслуживаю? А потом опытные люди, в свою очередь, возбухнут, а чего это ему за те же задачи да больше баллов дают?? И погрязнет контора в пучине офисной политики :)
ему надо быть либо глубоким экспертом в конкретно этом вопросе, либо отложить все свои дела и плотно вникнуть в мою задачу.

Либо вообще отменить эту задачу… такое тоже бывает. Тут вопрос приоритетов. Но это опять не зона ответственности программиста принимать решение "пилить до победного".


стал бы я браться за это нужное дело, если бы мне за него баллы начисляли?

А кто предлагал баллы начислять? тут же речь только об учёте рабочего времени… Вы заранее предупредили, что опыта с такими задачами нет, начальство согласилось… спокойно отмечайте рабочее время и всё. Откуда тут какие-то претензии могут быть?
На мой взгляд претензии могут быть только такого типа: на задачу стоял эстимейт 2 дня, а Вы её пилите целый месяц и при этом никому не сообщили, что столкнулись с трудностями. Причём претензии такого типа к Вам будут по-любому вне зависимости от наличия какого-либо учёта.


А потом опытные люди, в свою очередь, возбухнут, а чего это ему за те же задачи да больше баллов дают?

Блин, вот я даже не знаю, у меня что-ли какое-то особое восприятие статьи? Я не увидел там идеи давать баллы… А кто в здравом уме будет возбухать на тему "почему это он больше меня работает?" я не знаю.

Мне показалось, что суть предлагаемой системы в том, что надо наработать задач на определённое количество условных часов. Т. е. за 8 часов рабочего дня в офисе я могу решить одну задачу, оцененную в 2 часа, а могу две задачи, каждая по 7 часов – получив, согласно таблице, за этот день либо 0.4, либо 2.8 балла, соответственно (а не стабильно 1.6 балла за просиженные 8 часов). Выглядит несколько логичнее, чем тупо отсчитывать просиженные часы. Если я, допустим, очень скилловый, я, может, за 2 часа в день буду нарабатывать на вожделенный 1 балл и, в зависимости от собственных амбиций, могу либо расслабиться и получать удовольствие, либо работать ещё и получать в день 2 балла, следовательно, в итоге больше денег. А если я бездарь, мне придётся больше времени просидеть, допустим, 12 часов, чтобы заработать 1 балл – зарабатывать в день 2 балла мне уже времени не хватит, что печально, но как минимум я могу компенсировать собственную тупость собственным упорством, чтобы быть наравне со всеми, и какая-то сермяжная справедливость в этом есть. Всё бы хорошо, вот только задачи не квантуются, о чём я писал выше.

Действительно, невнимательно прочитал статью – в ней этого нет. Прочитав внимательнее, я вообще перестал что-либо понимать. Оценка измеряется в «потраченных баллах» (т. е. во времни, которое я просидел над задачей по факту?). Откуда берётся и что означает коэффициент 1.6? Как с его помощью из 5 часов получают 1 балл? Если оценивается просто затраченное время, почему просто его и не считать – зачем все эти баллы, «кю», пояса?
Если оценивается просто затраченное время, почему просто его и не считать – зачем все эти баллы, «кю», пояса?

Это я тоже не очень понял… Пояса видимо для прикола, а вот зачем вместо часов считать баллы непонятно. Достаточно было бы указать, что время, затраченное на задачу отмечается с точностью до 0.25 часа c округлением в большую сторону.


Я вижу эту систему так:
В среднем по региону есть компании, которые предлагают зарплату от нормального уровня до хорошего… например, для стажера можно найти работу с зарплатой 30-34 т.р… Мы создаём компанию, которая предлагает стажеру возможность получить самую высокую зарплату по региону — 40 т.р. Но для этого он должен уделять непосредственно работе более 95 часов за 4 недели. Если он уделяет работе от 70 до 95 часов, то получает зарплату среднюю по региону для своего уровня. Ну а если он совсем лентяй, то нам такие стажеры не интересны, поэтому они получают 20 т.р., чтобы сами ушли балду валять в другое место.
Если фактические затраты времени на задачи начали систематически опережать эстимейт, то мы повышаем сотруднику уровень. Т.е. талантливый стажер уже со второго месяца сможет претендовать на зарплату 50 т.р., в то время как в любой другой компании региона он как минимум первые 3 месяца работал бы в лучшем случае за 34 т.р.


Что в этой системе плохого — хз… но, судя по кол-ву минусов, которые мне тут накидали, очень много людей по факту работают менее 70 часов в месяц, хотя мне раньше казалось, что средние цифры: 90-110 часов/мес.

судя по кол-ву минусов, которые мне тут накидали, очень много людей по факту работают менее 70 часов в месяц, хотя мне раньше казалось, что средние цифры: 90-110 часов/мес

В месяце 4 недели. В неделе 40 часов. 4*40 = 160. Вот столько работают все, кто работает на полную ставку. Вы, возможно, работаете меньше — видимо из-за того, что у вас не полный рабочий день.

Рискну предположить, что тут идёт речь не о рабочих часах по трудовому кодексу, а о времени фактической работы. Есть мнение что человек из 8 рабочих часов работает реально только 5-6. Не помню для каких отраслей эти расчёты производились, но для программистов это объяснялось примерно так: Разработчик несколько раз в день теряет концентрацию и не выполняет свою непосредственную работу. Т.е. 2 часа в день он тратить на что угодно, только не на написание кода и его обдумывание. Это всё очень спорно, и я очень криво передал эту идею, но возможно именно эти 100 рабочих часов и имеются в виду.

Да, всё верно. Лайф-хак: если Вам реально надо отработать 8 часов за день (ну там сроки горят и т.д.), то разделите рабочее время в течении дня на блоки 3-3-2 или 3-2-3. С большими перерывами (более часа) между блоками.
Впрочем, это работает только на коротких дистанциях… т.е. в таком режиме реально отработать месяц, но не год.

Речь про время, уделённое работе, а не про время, проведённое на работе. Это 2 большие разницы. Так что не надо лукавства, никто из программистов систематически не работает больше 120 часов в месяц, это уже давно понятно (даже исследования есть). А вот то, что средние значения по Хабру не дотягивают до 100 — для меня сюрприз.
P.S. В офисе я тоже работал и успел насмотреться на коллег, которые и 3 часов из 8 не отрабатывали, это вовсе не редкость.

Тогда всё встаёт на свои места. Только теперь добавляется ещё несколько вопросов к описанной методике. Если мы хотим повысить эффективность, почему бы не начать внедрение подобной системы с 4-х часового рабочего дня, по 6 рабочих часов? Ведь проводились опыты по сокращению рабочего времени с положительным результатом. Сам для себя проводил эксперимент. При средней мотивации, я делаю намного больше за 6 часов в день, чем за 8. Мысли «ещё два часа и домой» пропадают, как и желание отвлечься. Хватает обеденного перерыва. Но статья говорит нам
>сотрудник должен быть на связи не меньше 8 часов в день
Вот тебе и мотивация. 8 часов должен отсидеть. Если система рассчитана на 100 часов, зачем воровать у программиста оставшиеся 60? В начале недели программист будет прокрастинировать 30 минут в день, к концу 6 часов. Усталость накопится.
почему бы не начать внедрение подобной системы с 4-х часового рабочего дня, по 6 рабочих часов?

Я бы вообще не нормировал время пребывания в офисе. Отработал 5 часов и можешь уходить из офиса с чистой совестью… Даже если астрономического времени ещё только 6 часов прошло.
Да и вообще, фигня все эти 8-часовые рабочие дни… Не зря же в классической книге есть целая глава "С девяти до пяти здесь совершенно невозможно работать"


сотрудник должен быть на связи не меньше 8 часов в день

Да, к этому пункту статьи у меня такая же претензия, можете в моём первом комментарии посмотреть: "Нет необходимости требовать присутствие рядом с компьютером на протяжении 9 часов. Достаточно договориться о 3-4 часах, которые гарантировано фиксированы"

Действительно, не надо лукавства. Если вы считаете, что разработчик работает 100 часов в неделю, то считайте исходя из этой цифры почасовой заработок и исходя из неё же оплачивайте овертаймы по двойному ценнику.

Если вы считаете, что разработчик работает 100 часов в неделю

в месяц


то считайте исходя из этой цифры почасовой заработок

я так и считаю


и исходя из неё же оплачивайте овертаймы по двойному ценнику

А вот это не понял… Вы меня с автором статьи что-ли перепутали? Я сейчас не выступаю в роли работодателя.
Хотя как программист не понимаю почему мне должны овертаймы оплачивать по двойному ценнику, если это моё личное желание сколько часов работать.

> не понимаю почему мне должны овертаймы оплачивать по двойному ценнику
Если Вы договорились с работодателем что работать будете только 6 часов в день, но дополнительно проводите на работе ещё 2 часа в день добровольно, то да, он Вам ничего не должен. Но если Вы договорились об оплате только 6 рабочих часов, то принуждение Вас быть на работе ещё 2 часа в день дополнительно, должно оплачиваться как овертайм.

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

А вот это не понял… Вы меня с автором статьи что-ли перепутали? Я сейчас не выступаю в роли работодателя.

Это обращение не к вам лично, а к гипотетическому работодателю, который думает, что его программисты работают 100 часов в месяц.


Хотя как программист не понимаю почему мне должны овертаймы оплачивать по двойному ценнику, если это моё личное желание сколько часов работать.

Если бы в статье было написано, что можно отработать 5 часов день и спокойно идти домой, то речь была бы о личном желании. А так о нём речи не идёт.

Если бы в статье было написано, что можно отработать 5 часов день и спокойно идти домой, то речь была бы о личном желании. А так о нём речи не идёт.

Да тут имхо недоработка системы… После отработки 100 часов в месяц, если месяц ещё не закончился, можно было бы пару отгулов давать, как дополнительный бонус. Ну и в рамках одного рабочего дня не должно быть обязанности 8-часового присутствия в офисе.

Плохого в этой системе то, что она, будучи столь же субъективной, как и любая другая система (включая полное отсутствие какой-либо системы), во-первых, лицемерно претендует на некую объективность и, во-вторых, вводит дополнительные сущности, которые можно использовать, чтобы систему загеймить.

Но вообще-то, мы тут упражняем собственное воображение, интерпретируя мысли автора статьи, а может, лучше сперва у него и спросить, что он имел ввиду? Или он нахватал минусов и ушёл в запой? :)

Хз, автор статьи почему-то очень редко отвечает… Видимо его слишком глубоко в минуса загнали.
Но в целом Вы правы, возможно мне нравится именно моя интерпретация этой системы, а не она сама )))

Роман простите меня за минусы) но Вы абсолютно правильно интерпретирует мои мысли.
Предполагаю, что если Вы поняли и смогли так точно передать, то что я хотел донести, то все люди, которые разводят холивар на мою статью, смогут понять, как эффективно можно использовать данную мотивацию. Ведь это только каркас, где руководитель можете отталкиваться всегда от нормального результата при найме, просто эффективность будет пониже.
На своем примере, могу сказать, когда я стал получать в два раза больше, чем хотел изначально, это дало мне большую мотивацию развиваться и показывать крутые результаты.
Этой методикой я поделился, чтобы помочь кому-то выстроить эффективный it-отдел и не быть привязанным к рабочему месту и постоянному контролю своего сотрудника.
Если бы я в своё время не попробовал, то возможно так бы и не узнал, как бывает просто работать, когда сам программист заинтересован в том, чтобы описывать свою работу, а также её оценивать, хотя бы в часах.
Ставьте адекватные зарплаты, применяйте денежные мотивации, они, на мой взгляд, работают, но, конечно же, подходят не всем организациям.
Вам всё же стоит заменить слово «мотивация» на «стимул». Так честнее будет.
Спасибо большое, что внимательно прочли статью. Рад буду, если данная мотивация вам поможет.
Кто и как делает эстимейт задачам?
Может быть, не «человек/час», а «человек⋅час»?

Если это расход, а не трудоёмкость, то всё верно, человек в час ,)

Ну да, или эффективность размножения.

При описанном в статье подходе размножаться скорее будет говнокод, а там логичная метрика — wtf/s^2

Данная мотивация может применяться, если сотрудник хочет полностью белую зарплату, но не на столько эффективно.

Мне показалось, или автор статьи говорит о том, что белая зарплата не у всех сотрудников в компании?
Я сам никогда не работал с «балльными» системами и учётом производительности, но так, чисто умозрительно, предположу, что введение подобных систем приводит к повышению эффективности работника в действиях, которые направлены на получение максимального количества баллов, а не на повышение качества или скорости работы.
You get what you measure. Если мерять баллами, сотрудники находят способ максимизировать баллы. Помню, во время работы в Microsoft Dynamics CRM одно время эффективность програмиста пытались считать по количеству закрытых багов в неделю. Это привело к том, что на каждый чих программист открывал баг. Надо поменять ресурс в файле — файлим баг, Нужно поменять стиль в CSS слегка — файлим баг. И еще один side effect — реальные сложные баги, требующие серьезного анализа и приличного времени на починку, никто не трогал — не выгодно же.

Насколько я понял, в данной системе баллы — это количество рабочих часов, делённое на 5, за исключением мелких задач, за которые вы не можете отметить меньше чем 0.5 часа, даже если задача "поменять стиль в CSS слегка". Что в принципе разумно, переключение контекста тоже время занимает. Максимизировать баллы система не призывает, т.к. если у Вас уже есть в среднем 24 рабочих часа в неделю, то за дальнейшее увеличение прибавки не будет.
Я тут уже отхватил кучу минусов, но скажите, Вы действительно считаете, что это жутко несправедливо уделять непосредственно работе 4 часа 50 минут из 8 часов рабочего дня?
И сколько тогда по Вашему программист должен в среднем уделять времени работе в рабочий день?

На мой взгляд, вообще не стоит нормировать день, поскольку мерять вы исполнение нормы все равно не сможете — как понять, бездельничает ли программист в какой-то отдельно взятый момент или обдумывает решение какой-нибудь задачи (это ведь включается в категорию «работать»)? Можно нормировать office hours — время, когда программист должен быть доступен (на случай митингов, вопросов, помощи какой-нибудь), но это совсем не то же самое и к производительности мало относится. 5-минутный (да даже часовой) work-item, который надо куда-то логировать для меня тоже выглядит слегка дико. Задачи такого уровня гранулярности стоят больше времени на бюрократию чем на выполнение.
как понять, бездельничает ли программист в какой-то отдельно взятый момент или обдумывает решение какой-нибудь задачи

Так а зачем это понимать? Насколько я понимаю описанную систему, она позволяет 3 часа бездельничать, 3 часа обдумывать решение и 2 часа его реализовывать. И никаких вопросов это не вызывает. Нормальный адекватный подход. Программисты же не роботы, чтобы 8 часов писать код, как некоторые думают.


Можно нормировать office hours — время, когда программист должен быть доступен (на случай митингов, вопросов, помощи какой-нибудь)

Можно, но это я как раз посоветовал автору статьи не нормировать жестко… для этих целей достаточно закрепить 3-4 часа, а в остальное время можно даже все IM отключать.


5-минутный (да даже часовой) work-item, который надо куда-то логировать для меня тоже выглядит слегка дико.

А как вы ведёте учёт задач? У вас нет плана на итерацию, где отмечается прогресс по каждой задаче? Вписать в ту же форму одну циферку, обозначающую кол-во часов вообще несложно.


Задачи такого уровня гранулярности стоят больше времени на бюрократию чем на выполнение.

Тут есть 2 варианта:
1) тестировщик нашёл баг и естественно завёл для него задачу
2) вы сами что-то обнаружили в процессе выполнения другой задачи, в таком случае нет смысла открывать задачу на мелкий фикс, просто учтёте это время в текущей задаче.


P.S. Вы уклонились от вопроса… Забудьте про системы учёта и оценки… и озвучьте Ваше мнение: сколько в среднем часов/минут в течении рабочего дня работает хороший программист? (подумать, поискать варианты решения и т.п., это всё учитывается в рабочее время; початиться в соцсетях/форумах, почитать Habr/новости и т.д. не считается, если не связано с текущими рабочими задачами)

>> Так а зачем это понимать? Насколько я понимаю описанную систему, она позволяет 3 часа бездельничать, 3 часа обдумывать решение и 2 часа его реализовывать. И никаких вопросов это не вызывает.
Ну а теперь представьте, что человек значительно быстрее может это делать. И обдумывает не 3 часа, а полчаса, и код потом пишет не два, а час. По идее, баллов ему по этой системе надо начислить за полтора часа работы, а не за 5. Но нет, проверить никак нельзя, поэтому будет 5. Еще один вывод отсюда — то, что такой человек мог бы сделать за день, он будет делать три дня. Потому что система позволяет.

>> А как вы ведёте учёт задач? У вас нет плана на итерацию, где отмечается прогресс по каждой задаче?
У нас нет итераций как концепции. Мы не исповедуем Скрам. На больших проектах на моей памяти Скрам ни разу не заработал. Задачи у нас есть — план на квартал. Раз в неделю подбиваем текущий баланс — что успели сделать, что еще осталось. Гранулярность уровня «Написать лоад-балансер для уоркеров, запущенных разными клиентами с учетом приоритетов» — пара-тройка недель. Изредка, бывает, бьем задачи на дни, когда нужно тонко выровнять расписание с какой-то другой командой и надо знать, какие части когда войдут в эксплуатацию.

>> Забудьте про системы учёта и оценки… и озвучьте Ваше мнение: сколько в среднем часов/минут в течении рабочего дня работает хороший программист?
Мне сложно усреднять. Очень по-разному. Зависит и от человека, и от дня. Бывает, что вообще ничего в голову не лезет и не получается. День потерян. Бывает, что все в голове сложилось в картинку и забываешь обо всем вокруг и работаешь часов 12. В среднем, наверное, от 3 до 5 часов продуктивного времени в день.
Ну а теперь представьте, что человек значительно быстрее может это делать. И обдумывает не 3 часа, а полчаса, и код потом пишет не два, а час.

Если это системно происходит, то на этот случай в статье указано аж 10 градаций уровня разработчика. Ну а если это так удачно звёзды сложились, то и пусть отдохнёт, порадуется, что справился с задачей гораздо быстрее, чем предполагает его текущий уровень.


Гранулярность уровня пара-тройка недель.

Ну, бывает. Но задачу на 2-3 недели можно спокойно дать только очень хорошему миддлу или сеньору, для среднестатистического мидла придётся разбивать на дни, иначе, к сожалению, есть большой риск, что он 2 недели будет балду гонять, а работать начнёт, когда уже по-любому не успеет в срок.


Бывает, что вообще ничего в голову не лезет и не получается. День потерян. Бывает, что все в голове сложилось в картинку и забываешь обо всем вокруг и работаешь часов 12.

Это понятно, поэтому я и спрашиваю про среднее.


В среднем, наверное, от 3 до 5 часов продуктивного времени в день.

Спасибо за ответ. В принципе, когда я работал в офисе, по моим наблюдениям было примерно так же, но при работе на почасовке пришёл к 4-6 часам продуктивного времени в день. К людям, которые утверждают, что могут работать более 120 часов в месяц на протяжении года, отношусь с недоверием :-)

И сколько тогда по Вашему программист должен в среднем уделять времени работе в рабочий день?

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

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

С точки зрения работодателя же целью является конечный продукт, который можно продать. А у него программисты целыми днями баллы зарабатывают, т.е. «жмут на кнопку» вместо того чтобы работать.
Всё вышесказанное не претензия к конкретной системе, а к непродуманности измерения эффективности умственного труда в целом.

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

В целом согласен, что и без баллов всё видно. Но не вижу, где тут провокация набирать больше баллов, в статье же указаны уровни, где для получения премии (отличный результат) не надо пахать как папа Карло… для достижения указанного отличного уровня (95 рабочих часов за 4 недели) достаточно не впадать неделями в прокрастинацию.
Не знаю как у них там с практикой применения, но по описанию реально одна из самых адекватных систем, которые я видел.
Попробуйте со стороны работодателя посмотреть на этот вопрос, вот нанимаете Вы профессионального программиста на 100 т.р. в мес, а он первые пару месяцев отлично работал (по 100ч и вы ему +20 т.р. премии платили), а за 3-й месяц отработал только 50 часов, что делать? Сразу уволить? Или заплатить 60 т.р. и посмотреть что в следующем месяце будет?
По-моему второй вариант одновременно и справедлив для обеих сторон и более гуманен для сотрудника.


Отсюда растут всякие неувязки, типа «зачем брать большую сложную задачу, если я возьму 5 мелких, решу их и получу то же количество условных единиц эффективности».

Как правило, зачачи берут по порядку, т.к. они расставлены по приоритетам. Исключения, конечно, возможно, но не в формате анархии "возьму те задачи, которые мне приглянулись".

>… вот нанимаете Вы профессионального программиста на 100 т.р. в мес, а он первые пару месяцев отлично работал (по 100ч и вы ему +20 т.р. премии платили), а за 3-й месяц отработал только 50 часов, что делать? Сразу уволить? Или заплатить 60 т.р. и посмотреть что в следующем месяце будет?

Ну во первых, кто вам дал право штрафовать на 40% зп?(да и вообще штрафовать) Еще один фанат черной зарплаты? Во вторых — почему вы эффективность меряете тупо часами? Может он эти 100ч страдал фигней и сознательно писал максимально объемно код, а за те 50 — написал тулзу, которая увеличила прибыль компании на 20%?

Поражаюсь этому менеджерскому мышлению

1) Я ни разу не менеджер.
2) Я много лет работаю на почасовке и отмечаю к оплате именно эффективные часы, поэтому снижение "зарплаты" в моём случае — это не штрафы, т.к. никакого фикса в принципе нет. Касаемо статьи, ну рассматривайте 60 т.р. как оклад, а вторые 60 т.р. как максимальную премию. Вам неприятна возможность получить премию в размере оклада?
3) Я, как профессиональный программист, искренне не понимаю, почему работодатель должен платить за то время, когда мне неохота работать. Другими словами, я сам работаю в качестве программиста по схеме похожей на описанную в статье. Причём выбрал я эту схему сам, т.к. считаю её наиболее справедливой.
4) Это не дело программиста считать влияние своих коммитов на прибыль компании.
5) Я часто в обсуждениях про почасовку пишу, что в месяц без перенапряга реально работать только 100-120 часов, но почти всегда налетают комментаторы, которые умножают часовую ставку на 176. Однако, как видно по реакции на комментарии к этой статье, очень много людей работают от силы 80 часов в месяц, а то и меньше. Делайте выводы ;-)

НЛО прилетело и опубликовало эту надпись здесь

А я и рассматриваю. Я ж написал, что работаю на почасовке. Сколько часов наработал, за столько и получил. В договоре указана часовая ставка, впрочем он не трудовой, а подряда (contractor agreement).

НЛО прилетело и опубликовало эту надпись здесь

Ну, не лично Вам… Хотя я не понимаю на что Вы намекаете, на то, что лично Вам интересен исключительно фиксированный оклад в месяц (даже если по другой схеме оплаты Вы могли бы получать условно в 1.5 раза больше), или на то, что 100 рабочих часов в месяц — это нереально много?

НЛО прилетело и опубликовало эту надпись здесь

Скорее это у вас излишне неуёмная фантазия, что вы придумываете то, что не было написано, и начинаете с этим спорить… Почитайте хоть ТК РФ на досуге для развлечения, а то на его тему вы тоже чего только не нафантазировали xD

В следующем месяце вы с вероятностью 99.9% получите заявление по собственному.
Эффективные менеджеры — хватит уже мерять нормочасами(в большинстве случаев под человекочасами у них все теже нормочасы), оно тут не работает, как бы вы не хотели
Поэтому я советую использовать баллы и оценивать коэффициент скорости своей команды. Товарищи, планирование никто не отменял. Оценивать задачи нужно, хоть в яблоках.

По поводу заявления по собственному. Если вы эффективный руководитель, то возможно вам не стоит слепо следовать инструкциям, возможно у сотрудника проблемы в семье или еще какая-то ситуация, поэтому он 4 недели прокрастинировал и не отмечал баллы. Вы это сразу увидите, пообщайтесь с ним, выплатите всю зарплату, дайте ему время прийти в себя. Но если уже 4 месяц не приходит в себя, перестаньте ему платить бонусы, и он сам без ссор уволится.
>эффективные и неэффективные сотрудники и без всяких баллов довольно неплохо видны, если работаешь непосредственно с ними

Вот только восприятие это искажено, особенно если работаешь непосредственно с ними. Допустим, вот Вася — он мудак, но при этом отлично работает. А Петя вообще не работает, но зато человек-то какой хороший!!! Поди их беспристрастно оцени.
В карате наоборот: в ученических ступенях нумерация по убыванию (9-й кю — это белый пояс, а 1-й кю — коричневый), а в ступенях мастера (даны) как раз по нарастающей.

По статье: система удобна тем, что понятна и прозрачна со стороны расчётов. Но также она вполне выступает мотиватором для «побольше наколбасить». Тут уже степень говнокодирования зависит в большой степени от того, насколько часто приходится лазить в свой же код и работать с ним: если часто работаешь с одним и тем же клиентом, то говнять не захочется лишний раз — проще потерять в деньгах сейчас, но быстрее сделать потом.

Ну и по ощущениям: на этапе роста программиста эта система может быть привлекательной. Но когда появляются более интересные и объемные задачи, требующие изучения и продумывания (research), то такая система начинает мешать.
IT по своей природе слишком сложно, чтобы можно было вот так вот придумать какие-то баллы, эсэлэи или другие метрики и адекватно по ним что-то оценивать.
Например, можно быстро что-то накодить путем копипаста, и не заморачиваясь особо на архитектуру, сэкономив тем самым на разработке. Баллы и прочие метрики будут высокие. Но потом затраты на саппорт плохо написанной системы могут превысить первоначальную экономию в разы.
В случае саппорта можно тоже работать на закрывание тикетов, чтобы SLA и прочие метрики соблюсти, но метрики не всегда кореллирует с удовлетворением клиента от вашей работы. И если вами недовольны, клиент с вами расстанется несмотря ни на какие баллы.
Оценка трудоемкости задач вообще отдельная тема, так как в ИТ всегда есть фактор неизвестности, обусловленный тем, что в процессе разработки могут выявиться ранее неизвестные ограничения. Например, запросто бывает, что чтобы добавить маленькую фичу в программу приходится переходить на новые версии фреймворков, решать проблемы обратной совместимости, рефакторить и переписывать работающий код.
Поэтому баллы это прикольно, но всей картины они не дают.
Вообще же, хороший тим лид обычно и без баллов знает, кто у него в команде в чем силен или слаб, и соответственно распределяет задачи по сотрудникам. И если кто-то халявит, тим лид про это уж точно будет знать.
Например, можно быстро что-то накодить путем копипаста, и не заморачиваясь особо на архитектуру, сэкономив тем самым на разработке. Баллы и прочие метрики будут высокие. Но потом затраты на саппорт плохо написанной системы могут превысить первоначальную экономию в разы.

При чем получать бонус будет плохой разработчик, которому плевать на проект, а хороший разработчик, который думает о будущем — будет получать уменьшение зарплаты, а потом еще и переделывать за плохим. Короче, система поощряющая плохое качество продукта. И зачем она нужна?
Короче, система поощряющая плохое качество продукта. И зачем она нужна?

Ну из статьи же понятно всё. Есть демка, которую проводят менеджеры каждые 2 недели. На этой демке надо показать, как много сделано за эти две недели. Чем больше сделано, тем круче менеджеры. Вот для того, чтобы можно было больше показать — для этого вся система. Что там внутри — неважно. Да, со временем разработка будет идти всё тяжелее, но это неважно, потому что орлы, которые придумают как за 2 недели что-нибудь именно показать, а потом гори оно синим пламенем — обязательно найдутся. А общее замедление темпа всегда можно списать на криворуких дебилов с низким коэффициентом.


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


Основная идея заключается в том, что сотрудник получает фиксированно только половину зарплаты.

Всё так и есть, только основная идея заключается в том, чтобы всю зарплату целиком никому не платить :). Вот приходите вы на собеседование, договариваетесь о зарплате (которая судя по статье небелая). А на второй рабочей неделе узнаёте, что реально получите только половину. Эффективный менеджмент торжествует!

Идите нахер со своими коэффициентами
Тут люди раскритиковали систему с практико-технической точки зрения. Добавлю ещё один аспект…

Менеджеры данной конторы вынуждают программистов играть в крысиные бега на свою программистскую зарплату. Очень эффективный подход.
Правильнее было-бы — коэффициенты применять, но за снижение производительности по этим коэффициентам штрафовать менеджеров. Это заставит менеджеров заниматься своими обязанностями, а не придумыванием идиотских мотивирующих систем.
Рассмотрим на примерах, если сотрудник претендует на зарплату в 80000 рублей, я могу предложить ему пояс: 5кю. При этом после...

То есть, если разработчик претендует на 80000, то вы ему предлагаете 40000 с призрачной возможностью бонусами получить таки его желаемую зарплату? Хуже всего в статье — лицемерие. Правдивая картинка такая:


То есть у вас нету увеличения зарплат. У вас есть только уменьшение.

Вот тут соглашусь. Это недостаток практического применения системы в конкретной компании.
Если разработчик претендует на 80 т.р., то это скорее 8кю. При эффективной работе сотрудник должен получать существенно больше, чем люди того же уровня, пинающие балду в другой компании.

В точку. Если вы хотите, чтобы эта мотивация круто работала. Вам нужно предлагать зарплаты выше по рынку (в табличке представлена зарплата для регионов России), как эта описывала в своей культуре компания NetFlix. Тогда вы сможете собрать талантливых разработчиков, которые привыкли работать, а не прокрастинировать.

Я думаю, если бы Вы указали числа для Москвы, которые в 2 раза выше, реакция на статью была бы более позитивной… А то люди, работающие на Москву, Питер, заграницу, сравнили со своими зарплатами и испугались )))

НЛО прилетело и опубликовало эту надпись здесь
Люто плюсую!

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

Можно по разному преподнести вашу методу.
1. Зарплата в нашей организации от 20 до 65. С возможностью получить премию до 100%(не высокая зарплата, хорошие бонусы)
2. Зарплата в нашей организации от 40 до 130. Штрафы за срыв сроков до 50%(большая зарплата, жесткие штрафы)

Но в первом случае человек, который может получить бонус, будет к нему стремиться любым путем.
Во втором же случае человек, который хоть раз получил штрафные санкции, сразу задумывается об уходе, получая мощнейший демотиватор.

Как вы преподносите это программистам?

Мое же личное мнение, что всегда и везде достаточно хорошего начальника, чтобы все работало как надо. Без всех этих сложных танцев с бубном. Если начальник видит, что чел не тянет, надо прощаться. Так как в любую систему можно обойти и подстроиться для получения максимальной выгоды, при минимальных затратах. А усложнение системы, ведет только к более изощренным способам обмана.
НЛО прилетело и опубликовало эту надпись здесь
Я прошу прощения, в данном случае вам я ответил «Люто плюсую», а все остальное относится к автору статьи.
Блин, не уклюже как то получилось)
НЛО прилетело и опубликовало эту надпись здесь
Проблема в том что все подобные методики, не дают полной привязки сложности работы к баллам, а лишь симулируют наиболее очевидные для менеджеров аспекты.

А учитывая, что большинство программистов еще в детстве наигралось в симуляторы, и хорошо понимают значение слова манчкин, очень быстро система будет использована себе во благо, сначала скромно, а затем оглядываясь на соседей, по полной программе.

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

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

И неважно как будут меняться правила начисления этих бонусов, программисты это эксперты в реализации задач при самых убогих условиях, систему в свою пользу нагнут в любом случае.
НЛО прилетело и опубликовало эту надпись здесь
Какой изощрённый демотиватор, однако. Мне всё больше кажется, что некоторые менеджеры просто перестали понимать значение слова «мотивация». Или мотивация, не сама цель, а все эти системы, лишь желание спихнуть как можно больше ответственности на сотрудников? Очередное «Ура! Мы заменили кнут на пряник! Теперь мы лупим их по рожам пряником вместо кнута!». Почему, чтобы сотрудник просто получил за свою работу положенные ему деньги, в полном объёме, ему не достаточно просто хорошо работать? Почему обязательно придерживаться каких-то метрик? Чтобы в любой момент, по желанию левой пятки менеджера, ему могли выплатит меньше, потому что он, якобы, не вписался в какую-то метрику?
Менеджер не может выплатить меньше зарплату, если разработчик отмечает 5 часов в день. У руководителя нету такой возможности. А вот если разработчик обманывает, долго выполняет задачи, ведет себя неадекватно и показывает в среднем плохой результат по субъективным метрикам, то может его уволить.
Метрики в нашей стране нужны для эффективного планирования.
НЛО прилетело и опубликовало эту надпись здесь
Мы, к примеру, планируем каждые две недели, составляем план, оцениваем задачки в баллах (фруктах, в чем угодно). На основании этого определяем реально возможную загрузку сотрудника на итерацию. Ставим себе реальные цели, которых пытаемся достичь.
Интересно, как вы планируете, если для вас метрики, это только, чтобы задницу руководителя прикрыть?
НЛО прилетело и опубликовало эту надпись здесь
Месячные итерации. Мы планируем точно так же, только вместо фруктов, часы. И это сразу даёт возможность запланировать без подсчёта метрик в бегемотах. Руководство доверяет нам. Мы доверяем руководству. Если задача выполняется с задержкой, стараемся предупредить руководителя об этом как можно раньше. Границы итерации могут быть сдвинуты или задачу перенесут на следующую итерацию. Если задачи выполняются раньше срока, появляется возможность добрать в итерацию не вошедшие в неё, но уже оценённые задачи или закрыть итерацию раньше. Всё хорошо и без всяких метрик.

А если оставить всё тоже самое, как Вы описали, и сверху выплачивать премию тем, кто 100 часов в месяц отработал, станет сильно хуже?

НЛО прилетело и опубликовало эту надпись здесь
Отработал на оценку «хорошо», получи штраф -15%
Заболел, получи штраф -50%
Хорошая система.
Если сотрудник заболел, мы должны вычесть баллы с учетом количества дней, которые он не работал. В противном случае, как вы уже правильно заметили, это будет демотивация. Это обсуждается на собеседование, после чего вопросов не возникает. При этом я придерживаюсь минимальной бюрократии, так что сотруднику необязательно брать официальный больничный.
Отпуска, как и во всех компаниях должны полностью оплачиваться.
По поводу оценок. Если сотрудник отмечает 5 часов в день, он в априори не может получить получить «хороший» результат. По поводу оценки результатов, существую субъективная оценка, которая представляет из себя пояс, по ней вы можете повышать вашего сотрудника.
НЛО прилетело и опубликовало эту надпись здесь
Мы работаем в России. Ставьте адекватные зарплаты и проблем не будет.
НЛО прилетело и опубликовало эту надпись здесь

Неплохо всё в РФ с трудовым законодательством. С его соблюдением хуже, но тоже неплохо. В Европе какой-нибудь тебя могут на совершенно законных основаниях уволить с предупреждением за месяц. И пожаловаться даже некому будет.

НЛО прилетело и опубликовало эту надпись здесь

Тем не менее его соблюдают.

НЛО прилетело и опубликовало эту надпись здесь

Плюсанул :). Но вообще-то законодательство будет нарушено, если платить будут меньше, чем написано в договоре. Или если уволят без причины и без выходного пособия.


А тут юридически система премирования. Она законодательство не нарушает.

Расскажите какова текучка кадров?
Ну и насколько комплекс состоит из костылей?
Добрый день!

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

Из тех программистов, которых мы нанимали с нуля и сожали на данную мотивацию, текучки кадров нет, так как правильно отметил Source (Роман Смирнов), что мы не отмечаем за программиста потраченные баллы и не заставляем работать по 8 часов в день, тем более не стоим над душой, требуя быть постоянно на рабочем месте.

Смотря, что вы имеете в виду под костылями. В этой статье не описан SCRUM, здесь не описаны субъективные метрики, которые у нас выстраиваются на адекватной оценке персонала с учетом культуры it-отдела, интересные задачи, архитектурные особенности проектов.

Также я не описывал нюансы при найме сотрудников. А они определенно есть, прийдется научиться работать с возражениями, но это поможет в дальнейшем избежать недопониманий и текучки.
Объяснить программистам, которые привыкли получать зарплату и при этом никак не фиксировать свою работу поначалу будет сложно.

Это попытка переложить ответственность с менеджеров на программистов. Так-же как и
фиксировать выполненные задачи и оценивать задачи для эффективного планированию

В половине комментов, кстати, задан вопрос — кем и как осуществляется эстимейт задачи.
Проблемы начнутся когда такая «система» наткнется на человека, который объективно работает больше чем на ваши условные 130к. В такой ситуации он столкнется только с демотивацией и чем ближе к верхнему порогу, тем призрачней становятся дальнейшие перспективы.
В статье описан каркас с практическим применением. Можете уже дальше навешивать и докручивать, как сами хотите. Просто при грамотном внедрении она работает.
Я, к сожалению, редко встречаю в российских компаниях хоть какой-то намек на денежный рост, а тем более отображенный в табличном виде.
«Денежный рост» — это получить целую зарплату вместо половины?
Заманчивое предложение.

Это Вы с московских позиций оцениваете… В провинции зарплаты от 30 до 97.5 т.р. — это очень конкурентное предложение, а это строка "нормально", а не "отлично"..

Тут есть 2 варианта:
1) поскольку в табличке числа указаны для провинции, то скорее всего у компании просто нет таких ресурсов и/или таких задач, на которые нужны высокооплачиваемые специалисты, т.е. одним словом overqualified.
2) для московских компаний числа в табличке можно удвоить, а саму табличку экстраполировать до мастера международного уровня с диапазоном от 175 до 350 т.р.

Раз уж статья называется "как перестать беспокоиться о неэффективных сотрудниках?", то чего Вы все от нее хотите? Тут даже в названии сказано, что она для удобства работодателей, а не сотрудников =)

Рассмотрим на примерах, если сотрудник претендует на зарплату в 80000 рублей, я могу предложить ему пояс: 5кю.

Серьезно? Если человек претендует на 80к, то по вашей табличке вы должны ему предложить хотя бы «мастер», иначе вы не мотивируете человека, а демотивируете потенциальной возможностию сокращения его дохода. Мне кажется, любой уважающий себя человек, если только он не рассчитывает в действительности на 40к на такое не согласиться.
НЛО прилетело и опубликовало эту надпись здесь
У разработчика есть испытательный срок, чтобы это проверить. Предложите ему больше, чем он рассчитывает, и пусть решает сам по результатам первой демки, выполняет ли компания обязательства, на которые подписалась.

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

Товарищи, вы реально думаете, что у нас все разработчики в стране зарабатывают больше 100 000 руб.?
Зачастую у нас в компании зарплаты выше, чем по региону.
У разработчика есть испытательный срок, чтобы это проверить.

А с какой целью вы упомянули испытательный срок? Что бы изменилось, если бы его не было?

Он может оценить только выполняет ли компания свои обязательства сейчас. Ну, может, в прошлом…

Точно так же индюшка может быть уверена на основании своего опыта, что хозяин каждое утро ее кормит. Но потом приходит 4-й четверг ноября…

Если вы даете конкурентный оклад — это еще может работать. Но если вы даете оклад ниже рынка с увещеванием насчет перспектив и всего такого — то более-менее сообразительные смекнут, что в окладе-то они могут быть уверены, а вот во всем остальном — как повезет…
Причем тут абсолютные цифры оклада, если мы говорим о подходе вцелом?
В таком подходе цена идеи или инновации равна нулю и вообще не оценивается. Например есть желание что-то улучшить/понять как работает, расширить знания по коду — это не оценивается и вообще нафиг не надо.
Выгодно пилить свой кусок кода, в котором ты знаешь 100% и сможешь сделать на 30%, чем остальные, у остальных подход точно такой же.
У менеджера с отношение к программисту как в интику, на выходе продукт будет г-но.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.