Комментарии 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.
Как по мне, то такая система не мотивирует делать качественный продукт, но мотивирует делать все быстро «тяп-ляп и готово».
А кто определяет сколько стоит задача в баллах?
В статье же указано "объективную оценку, которую отмечает сам разработчик по окончанию задачи, выраженную в потраченных баллах". Т.е. в зачёт идёт фактическое кол-во отработанных часов, вне зависимости от прогнозов.
Как мы понимаем, недостаточно подсчитать баллы для определения эффективности разработчика.
Так и не понял, а что вы делаете для определения эффективности, если не баллы считаете?
А кто запрещает сотруднику постоянно переоценивать свои фактически затраченные силы? Как происходит контроль?
время потраченное на написание кода и обмозгование задачи
Не знаю как у других, но в моей работе постоянно приходится сталкиваться с задачами, для решения которых надо думать 80% времени, а кодировать 20%. Если бы на моей работе была бы такая же система, то мне бы просто перестали верить, хотя я честно пару часов могу думать над задачей, что-то изучать, а потом за 30 минут написать 50-100 строчек эффективного кода.
Я не имею отношения к автору статьи. Но он пришёл к системе, которая мне близка и понятна. Поэтому могу свой взгляд высказать… Как правило, во главе команды есть тех.лид или технический директор, это человек с огромным опытом программирования, которого невозможно систематически обманывать с оценками задач, потому что он понимает какому уровню сколько реально часов нужно на конкретную задачу. Если задача занимает много времени, то адекватный программист укажет в комментариях к задаче с какими сложностями он столкнулся, а не просто поставит в 3 раза больше времени, чем ожидалось.
в моей работе постоянно приходится сталкиваться с задачами, для решения которых надо думать 80% времени, а кодировать 20%
Вы думаете, что удивите этим фактом хоть одного тех.лида? Это вполне нормальное соотношение для широкого круга задач.
В этом плане описанная в статье методика вполне адекватна, т.к. не привязана ни к кол-ву строк, ни к нажатиям клавиш, ни к времени проведённому неотрывно за клавиатурой.
А такого, что за пару часов сделал 99% задачи, а потом ещё пару дней бьёшься лбом об монитор, пытаясь домучить оставшийся 1% у вас что, не бывает? И ладно ещё, если сам накосячил — допустим, ваш ведущий технический провидец, зная мой уровень, способен это предсказать. А то проявит себя какой-нибудь малоизвестный, нелогичный и нигде не описанный косяк используемой библиотеки, с которым раньше никогда не сталкивался — тех. лид. знает наизусть все эти косяки, а так же помнит, какие из них знает кто из его разработчиков?
Получается, за этот месяц нам обоим надо бы ЗП ополовинить? В таком случае в следующий раз подобный проект будет признан неподъемным после трех попыток, а потраченная на него шестизначная сумма в евро пойдет в убыток.
Короче, тут уже говорили несколько раз, что введение метрик, влияющих на зарплату, ведет только и исключительно к оптимизации по ним. Если вас это устраивает — дело ваше. Если же нет, обыкновенного performance review раз в полгода-год вполне достаточно, на мой взгляд.
А такого, что за пару часов сделал 99% задачи, а потом ещё пару дней бьёшься лбом об монитор, пытаясь домучить оставшийся 1% у вас что, не бывает?
Вы невнимательно читаете: "Если задача занимает много времени, то адекватный программист укажет в комментариях к задаче с какими сложностями он столкнулся". В целом, если Вы столкнулись с такими трудностями, что безрезультатно "пару дней бьёшься лбом об монитор", необходимо сообщить об этом начальству, а то так можно целый месяц биться… при этом может оказаться, что добавленная компетенция решит её за пару часов (во всяком случае бывало и такое).
Вон выше CodeRush пишет, как 5 недель просидели над проблемой. У меня тоже бывали случаи. Как правило, помочь в такой ситуации не может никто. Начальник спрашивает, когда решу проблему — честно отвечаю, что как повезёт. Есть пара томов документации на почитать — возможно, ответ будет на первой странице первого тома, а возможно — на последней странице второго. А возможно, ни там ни там не будет. Есть десяток идей, как заставить всё работать, проверяю их по-очереди — возможно, правильной окажется первая же, возможно — последняя. А возможно, все десять будут мимо. И никакое абстрактное «тимлидство» не поможет начальнику понять, правду я говорю или 2.7бу мозги — ему надо быть либо глубоким экспертом в конкретно этом вопросе, либо отложить все свои дела и плотно вникнуть в мою задачу. Либо и то и другое сразу!
Или вот недавний совсем случай из собственной практики. Понадобился +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 часов за день (ну там сроки горят и т.д.), то разделите рабочее время в течении дня на блоки 3-3-2 или 3-2-3. С большими перерывами (более часа) между блоками.
Впрочем, это работает только на коротких дистанциях… т.е. в таком режиме реально отработать месяц, но не год.
Речь про время, уделённое работе, а не про время, проведённое на работе. Это 2 большие разницы. Так что не надо лукавства, никто из программистов систематически не работает больше 120 часов в месяц, это уже давно понятно (даже исследования есть). А вот то, что средние значения по Хабру не дотягивают до 100 — для меня сюрприз.
P.S. В офисе я тоже работал и успел насмотреться на коллег, которые и 3 часов из 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-отдел и не быть привязанным к рабочему месту и постоянному контролю своего сотрудника.
Если бы я в своё время не попробовал, то возможно так бы и не узнал, как бывает просто работать, когда сам программист заинтересован в том, чтобы описывать свою работу, а также её оценивать, хотя бы в часах.
Ставьте адекватные зарплаты, применяйте денежные мотивации, они, на мой взгляд, работают, но, конечно же, подходят не всем организациям.
Данная мотивация может применяться, если сотрудник хочет полностью белую зарплату, но не на столько эффективно.
Мне показалось, или автор статьи говорит о том, что белая зарплата не у всех сотрудников в компании?
Насколько я понял, в данной системе баллы — это количество рабочих часов, делённое на 5, за исключением мелких задач, за которые вы не можете отметить меньше чем 0.5 часа, даже если задача "поменять стиль в CSS слегка". Что в принципе разумно, переключение контекста тоже время занимает. Максимизировать баллы система не призывает, т.к. если у Вас уже есть в среднем 24 рабочих часа в неделю, то за дальнейшее увеличение прибавки не будет.
Я тут уже отхватил кучу минусов, но скажите, Вы действительно считаете, что это жутко несправедливо уделять непосредственно работе 4 часа 50 минут из 8 часов рабочего дня?
И сколько тогда по Вашему программист должен в среднем уделять времени работе в рабочий день?
как понять, бездельничает ли программист в какой-то отдельно взятый момент или обдумывает решение какой-нибудь задачи
Так а зачем это понимать? Насколько я понимаю описанную систему, она позволяет 3 часа бездельничать, 3 часа обдумывать решение и 2 часа его реализовывать. И никаких вопросов это не вызывает. Нормальный адекватный подход. Программисты же не роботы, чтобы 8 часов писать код, как некоторые думают.
Можно нормировать office hours — время, когда программист должен быть доступен (на случай митингов, вопросов, помощи какой-нибудь)
Можно, но это я как раз посоветовал автору статьи не нормировать жестко… для этих целей достаточно закрепить 3-4 часа, а в остальное время можно даже все IM отключать.
5-минутный (да даже часовой) work-item, который надо куда-то логировать для меня тоже выглядит слегка дико.
А как вы ведёте учёт задач? У вас нет плана на итерацию, где отмечается прогресс по каждой задаче? Вписать в ту же форму одну циферку, обозначающую кол-во часов вообще несложно.
Задачи такого уровня гранулярности стоят больше времени на бюрократию чем на выполнение.
Тут есть 2 варианта:
1) тестировщик нашёл баг и естественно завёл для него задачу
2) вы сами что-то обнаружили в процессе выполнения другой задачи, в таком случае нет смысла открывать задачу на мелкий фикс, просто учтёте это время в текущей задаче.
P.S. Вы уклонились от вопроса… Забудьте про системы учёта и оценки… и озвучьте Ваше мнение: сколько в среднем часов/минут в течении рабочего дня работает хороший программист? (подумать, поискать варианты решения и т.п., это всё учитывается в рабочее время; початиться в соцсетях/форумах, почитать Habr/новости и т.д. не считается, если не связано с текущими рабочими задачами)
Ну а теперь представьте, что человек значительно быстрее может это делать. И обдумывает не 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 мелких, решу их и получу то же количество условных единиц эффективности».
Как правило, зачачи берут по порядку, т.к. они расставлены по приоритетам. Исключения, конечно, возможно, но не в формате анархии "возьму те задачи, которые мне приглянулись".
Ну во первых, кто вам дал право штрафовать на 40% зп?(да и вообще штрафовать) Еще один фанат черной зарплаты? Во вторых — почему вы эффективность меряете тупо часами? Может он эти 100ч страдал фигней и сознательно писал максимально объемно код, а за те 50 — написал тулзу, которая увеличила прибыль компании на 20%?
Поражаюсь этому менеджерскому мышлению
1) Я ни разу не менеджер.
2) Я много лет работаю на почасовке и отмечаю к оплате именно эффективные часы, поэтому снижение "зарплаты" в моём случае — это не штрафы, т.к. никакого фикса в принципе нет. Касаемо статьи, ну рассматривайте 60 т.р. как оклад, а вторые 60 т.р. как максимальную премию. Вам неприятна возможность получить премию в размере оклада?
3) Я, как профессиональный программист, искренне не понимаю, почему работодатель должен платить за то время, когда мне неохота работать. Другими словами, я сам работаю в качестве программиста по схеме похожей на описанную в статье. Причём выбрал я эту схему сам, т.к. считаю её наиболее справедливой.
4) Это не дело программиста считать влияние своих коммитов на прибыль компании.
5) Я часто в обсуждениях про почасовку пишу, что в месяц без перенапряга реально работать только 100-120 часов, но почти всегда налетают комментаторы, которые умножают часовую ставку на 176. Однако, как видно по реакции на комментарии к этой статье, очень много людей работают от силы 80 часов в месяц, а то и меньше. Делайте выводы ;-)
А я и рассматриваю. Я ж написал, что работаю на почасовке. Сколько часов наработал, за столько и получил. В договоре указана часовая ставка, впрочем он не трудовой, а подряда (contractor agreement).
Эффективные менеджеры — хватит уже мерять нормочасами(в большинстве случаев под человекочасами у них все теже нормочасы), оно тут не работает, как бы вы не хотели
По поводу заявления по собственному. Если вы эффективный руководитель, то возможно вам не стоит слепо следовать инструкциям, возможно у сотрудника проблемы в семье или еще какая-то ситуация, поэтому он 4 недели прокрастинировал и не отмечал баллы. Вы это сразу увидите, пообщайтесь с ним, выплатите всю зарплату, дайте ему время прийти в себя. Но если уже 4 месяц не приходит в себя, перестаньте ему платить бонусы, и он сам без ссор уволится.
Вот только восприятие это искажено, особенно если работаешь непосредственно с ними. Допустим, вот Вася — он мудак, но при этом отлично работает. А Петя вообще не работает, но зато человек-то какой хороший!!! Поди их беспристрастно оцени.
По статье: система удобна тем, что понятна и прозрачна со стороны расчётов. Но также она вполне выступает мотиватором для «побольше наколбасить». Тут уже степень говнокодирования зависит в большой степени от того, насколько часто приходится лазить в свой же код и работать с ним: если часто работаешь с одним и тем же клиентом, то говнять не захочется лишний раз — проще потерять в деньгах сейчас, но быстрее сделать потом.
Ну и по ощущениям: на этапе роста программиста эта система может быть привлекательной. Но когда появляются более интересные и объемные задачи, требующие изучения и продумывания (research), то такая система начинает мешать.
Например, можно быстро что-то накодить путем копипаста, и не заморачиваясь особо на архитектуру, сэкономив тем самым на разработке. Баллы и прочие метрики будут высокие. Но потом затраты на саппорт плохо написанной системы могут превысить первоначальную экономию в разы.
В случае саппорта можно тоже работать на закрывание тикетов, чтобы SLA и прочие метрики соблюсти, но метрики не всегда кореллирует с удовлетворением клиента от вашей работы. И если вами недовольны, клиент с вами расстанется несмотря ни на какие баллы.
Оценка трудоемкости задач вообще отдельная тема, так как в ИТ всегда есть фактор неизвестности, обусловленный тем, что в процессе разработки могут выявиться ранее неизвестные ограничения. Например, запросто бывает, что чтобы добавить маленькую фичу в программу приходится переходить на новые версии фреймворков, решать проблемы обратной совместимости, рефакторить и переписывать работающий код.
Поэтому баллы это прикольно, но всей картины они не дают.
Вообще же, хороший тим лид обычно и без баллов знает, кто у него в команде в чем силен или слаб, и соответственно распределяет задачи по сотрудникам. И если кто-то халявит, тим лид про это уж точно будет знать.
Например, можно быстро что-то накодить путем копипаста, и не заморачиваясь особо на архитектуру, сэкономив тем самым на разработке. Баллы и прочие метрики будут высокие. Но потом затраты на саппорт плохо написанной системы могут превысить первоначальную экономию в разы.
При чем получать бонус будет плохой разработчик, которому плевать на проект, а хороший разработчик, который думает о будущем — будет получать уменьшение зарплаты, а потом еще и переделывать за плохим. Короче, система поощряющая плохое качество продукта. И зачем она нужна?
Короче, система поощряющая плохое качество продукта. И зачем она нужна?
Ну из статьи же понятно всё. Есть демка, которую проводят менеджеры каждые 2 недели. На этой демке надо показать, как много сделано за эти две недели. Чем больше сделано, тем круче менеджеры. Вот для того, чтобы можно было больше показать — для этого вся система. Что там внутри — неважно. Да, со временем разработка будет идти всё тяжелее, но это неважно, потому что орлы, которые придумают как за 2 недели что-нибудь именно показать, а потом гори оно синим пламенем — обязательно найдутся. А общее замедление темпа всегда можно списать на криворуких дебилов с низким коэффициентом.
Ну и плюс такие системы обычно выстраивают так, чтобы людей с высоким коэффициентом было немного — это ж какая экономия получается. Вон же в статье написано.
Основная идея заключается в том, что сотрудник получает фиксированно только половину зарплаты.
Всё так и есть, только основная идея заключается в том, чтобы всю зарплату целиком никому не платить :). Вот приходите вы на собеседование, договариваетесь о зарплате (которая судя по статье небелая). А на второй рабочей неделе узнаёте, что реально получите только половину. Эффективный менеджмент торжествует!
Менеджеры данной конторы вынуждают программистов играть в крысиные бега на свою программистскую зарплату. Очень эффективный подход.
Рассмотрим на примерах, если сотрудник претендует на зарплату в 80000 рублей, я могу предложить ему пояс: 5кю. При этом после...
То есть, если разработчик претендует на 80000, то вы ему предлагаете 40000 с призрачной возможностью бонусами получить таки его желаемую зарплату? Хуже всего в статье — лицемерие. Правдивая картинка такая:
То есть у вас нету увеличения зарплат. У вас есть только уменьшение.
Вот тут соглашусь. Это недостаток практического применения системы в конкретной компании.
Если разработчик претендует на 80 т.р., то это скорее 8кю. При эффективной работе сотрудник должен получать существенно больше, чем люди того же уровня, пинающие балду в другой компании.
Вам, кстати правильно указали на то, что вы подменяете понятия.
Можно по разному преподнести вашу методу.
1. Зарплата в нашей организации от 20 до 65. С возможностью получить премию до 100%(не высокая зарплата, хорошие бонусы)
2. Зарплата в нашей организации от 40 до 130. Штрафы за срыв сроков до 50%(большая зарплата, жесткие штрафы)
Но в первом случае человек, который может получить бонус, будет к нему стремиться любым путем.
Во втором же случае человек, который хоть раз получил штрафные санкции, сразу задумывается об уходе, получая мощнейший демотиватор.
Как вы преподносите это программистам?
Мое же личное мнение, что всегда и везде достаточно хорошего начальника, чтобы все работало как надо. Без всех этих сложных танцев с бубном. Если начальник видит, что чел не тянет, надо прощаться. Так как в любую систему можно обойти и подстроиться для получения максимальной выгоды, при минимальных затратах. А усложнение системы, ведет только к более изощренным способам обмана.
А учитывая, что большинство программистов еще в детстве наигралось в симуляторы, и хорошо понимают значение слова манчкин, очень быстро система будет использована себе во благо, сначала скромно, а затем оглядываясь на соседей, по полной программе.
В данном случае, себе будут прописываться задачи с наиболее завышенными баллами, а врагам народа коллектив будет занижать.
На качество все будут класть большой болт, так как исправление багов это тоже очень сложная и долгая работа, что хорошо для зарплаты.
Ну а попытки менеджеров наклонить систему в свою пользу упрутся в то, что в большинстве случаев у программистов и интеллект повыше и знание предметной области куда больше. Загрузят так, что лапши на пару лет хватит.
И неважно как будут меняться правила начисления этих бонусов, программисты это эксперты в реализации задач при самых убогих условиях, систему в свою пользу нагнут в любом случае.
Метрики в нашей стране нужны для эффективного планирования.
Интересно, как вы планируете, если для вас метрики, это только, чтобы задницу руководителя прикрыть?
Заболел, получи штраф -50%
Хорошая система.
Отпуска, как и во всех компаниях должны полностью оплачиваться.
По поводу оценок. Если сотрудник отмечает 5 часов в день, он в априори не может получить получить «хороший» результат. По поводу оценки результатов, существую субъективная оценка, которая представляет из себя пояс, по ней вы можете повышать вашего сотрудника.
Ну и насколько комплекс состоит из костылей?
Текучка кадров происходит, если вы вводите не с нуля данную мотивацию. Объяснить программистам, которые привыкли получать зарплату и при этом никак не фиксировать свою работу поначалу будет сложно. Поэтому резко вводить данную мотивацию не советую. Даже правильнее будет не вводить данную денежную мотивацию, если программист показывает хорошие результаты итак. Но фиксировать выполненные задачи и оценивать задачи для эффективного планированию, к сожалению, прийдется. Увы, это необходимость.
Из тех программистов, которых мы нанимали с нуля и сожали на данную мотивацию, текучки кадров нет, так как правильно отметил Source (Роман Смирнов), что мы не отмечаем за программиста потраченные баллы и не заставляем работать по 8 часов в день, тем более не стоим над душой, требуя быть постоянно на рабочем месте.
Смотря, что вы имеете в виду под костылями. В этой статье не описан SCRUM, здесь не описаны субъективные метрики, которые у нас выстраиваются на адекватной оценке персонала с учетом культуры it-отдела, интересные задачи, архитектурные особенности проектов.
Также я не описывал нюансы при найме сотрудников. А они определенно есть, прийдется научиться работать с возражениями, но это поможет в дальнейшем избежать недопониманий и текучки.
Объяснить программистам, которые привыкли получать зарплату и при этом никак не фиксировать свою работу поначалу будет сложно.
Это попытка переложить ответственность с менеджеров на программистов. Так-же как и
фиксировать выполненные задачи и оценивать задачи для эффективного планированию
В половине комментов, кстати, задан вопрос — кем и как осуществляется эстимейт задачи.
Я, к сожалению, редко встречаю в российских компаниях хоть какой-то намек на денежный рост, а тем более отображенный в табличном виде.
Тут есть 2 варианта:
1) поскольку в табличке числа указаны для провинции, то скорее всего у компании просто нет таких ресурсов и/или таких задач, на которые нужны высокооплачиваемые специалисты, т.е. одним словом overqualified.
2) для московских компаний числа в табличке можно удвоить, а саму табличку экстраполировать до мастера международного уровня с диапазоном от 175 до 350 т.р.
Раз уж статья называется "как перестать беспокоиться о неэффективных сотрудниках?", то чего Вы все от нее хотите? Тут даже в названии сказано, что она для удобства работодателей, а не сотрудников =)
Рассмотрим на примерах, если сотрудник претендует на зарплату в 80000 рублей, я могу предложить ему пояс: 5кю.
Серьезно? Если человек претендует на 80к, то по вашей табличке вы должны ему предложить хотя бы «мастер», иначе вы не мотивируете человека, а демотивируете потенциальной возможностию сокращения его дохода. Мне кажется, любой уважающий себя человек, если только он не рассчитывает в действительности на 40к на такое не согласиться.
По началу сложно решиться предложить работать по такой мотивации, так как нужно быть реально подготовленным отвечать на вопросы. После того, как сотрудник уже начинает работать, вопросы отпадают сами собой.
Товарищи, вы реально думаете, что у нас все разработчики в стране зарабатывают больше 100 000 руб.?
Зачастую у нас в компании зарплаты выше, чем по региону.
У разработчика есть испытательный срок, чтобы это проверить.
А с какой целью вы упомянули испытательный срок? Что бы изменилось, если бы его не было?
Точно так же индюшка может быть уверена на основании своего опыта, что хозяин каждое утро ее кормит. Но потом приходит 4-й четверг ноября…
Если вы даете конкурентный оклад — это еще может работать. Но если вы даете оклад ниже рынка с увещеванием насчет перспектив и всего такого — то более-менее сообразительные смекнут, что в окладе-то они могут быть уверены, а вот во всем остальном — как повезет…
Выгодно пилить свой кусок кода, в котором ты знаешь 100% и сможешь сделать на 30%, чем остальные, у остальных подход точно такой же.
У менеджера с отношение к программисту как в интику, на выходе продукт будет г-но.
Мотивация каратистов: как перестать беспокоиться о неэффективных сотрудниках?