Хабр Курсы для менеджеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Менеджмент доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 81
На деле Performance Review награждает не самых умных или талантливых, а тех, кто работает «овер» […]
Чё? Может у вас на галерах это и так, но обобщать-то не нужно. Я работаю ровно столько, сколько считаю нужным (обычно это меньше 40 часов в неделю), и не было ни единого года за последнее десятилетие, чтобы я не получил максимум и, как следствие, — премию и перерасчет зарплаты на ревью.
Представь, что ты каждый месяц отдаёшь компании 20-30 дополнительных часов
Представить я могу что угодно, но какой в этом смысл, если оно не бьётся с реальностью?
Ты сам решил остаться после работы, сам решил добить задачу. Значит, это не сверхурочные, а твоя личная инициатива.
Не совсем так. Если решил добить задачу, которая важна бизнесу, обосновал необходимость сверхурочки и оформил её, то получил свою х1.5-х2 прибавку. Если этого не сделал, то действительно, это личная инициатива и непонятно с чего это вдруг она должна оплачиваться. Наверное, работодатель должен обладать телепатическими способностями, чтобы догадаться, что вы переработали? Ну, это здорово, конечно, но разве телепатия существует? Так что, да, приходится жить в мире, где переработки необходимо согласовывать.
Легальный обход законадательства.
Всего лишь ваша лень. Конкретно яндексе был/есть косяк с бесплатными дежурствами и это боль, да. Переработки же вне дежурств вполне оплачиваются и в яндексе тоже. Да, после согласования. Ну, а как вы хотели - про телепатию я уже написал. В более других биг- и не-очень-биг- техах, что я работал (и которые опрашивал на собеседованиях), дежурства если встречались, то были платными, а кое где и х2 платными (если выполнялись не штатными девопсами). Переработки везде х(1.5-2) платные. Но только если они действительно нужны бизнесу, а не потому, что вы внезапно решили допинать фичу). Не понимаю о чём вы говорите.
где компания получает беспроцентный кредит за счёт сверхурочного труда сотрудников.
А, вы (не только конкретно вы, а 'вы' в широком смысле - читатели сего) попробуйте согласовывать сверхурочку или, хотя бы, говорить о ней работодателю (посфактум оно вряд ли сработает, но и такие чудеса бывают), а не выдумывать молчком конспирологические теории. Уверен, результат в виде весомой прибавки вам понравится! :)
Да, и на собесах обязательно спрашивайте про дежурства - есть они или нет, и если есть, то как оплачиваются. Бесплатные яндексовые дежурства по моему опыту - ситуация нетипичная, но за всех я не могу ручаться, может ещё где встречаются...
Upd: прочитал в подписи, что вы - тимлид в Х5 и удивился - в Х5 настолько плохо, что аж тимлид (к которому должны идти согласовывать переработку его тиммейты) жалуется о неоплачиваемых сверхурочных? Во, бли-и-ин!
Бывает такое, что получить на ревью оценку "превзошёл ожидания" можно только действительно демонстративно трудясь не покладая рук вечерами и выходными, при этом не требуя ТК-шной компенсации. Это именно что неформальный подход конкретных руководителей к оценке.
Хорошие ли это руководители - вопрос оставлю открытым)
вечерами и выходными, при этом не требуя ТК-шной компенсации
Вот, это, кстати, интересный вопрос. А правда ли, что "не требуя"? Может быть если "требуя", то результат был бы не хуже? ;)
Это именно что неформальный подход конкретных руководителей к оценке.
Что до яндекса, то результат ревью - это не решение одного странного руководителя, а результат каких-то длительных корректировок. По идее, они должны сглаживать эффект. Впрочем, я понятия не имею как происходят корректировки изнутри, поэтому перестаю гадать.
Хорошие ли это руководители
Хорошие руководители защищают своих подчинённых, а не наоборот.
Хорошие руководители защищают своих подчинённых, а не наоборот.
Именно. Золотые слова, Суворов глупость бы не ляпнул.
Может быть если "требуя", то результат был бы не хуже? ;)
Это, кстати, возможно. Но я видел пример и такой: руководитель небольшой команды (не технарь причём) без проблем выбивал компенсацию сверхурочной работы для своих разработчиков, но сам сидел по 10-12 часов. Потому что "тыжменеджер".
Что до яндекса
Я вообще не про него, более того, не про чистую IT компанию в принципе. На всякий случай поясняю, во избежание ложных интерпретаций.
Не очень понятно, как «превзошел ожидания» соотносится с переработками. Эта оценка относится к должностным обязанностям и компетенциям. Например, есть обязанности и компетенции разработчиков мидла и старшего, если мидл выполняет обязанности старшего, или лида, то в этом случае он «превосходит ожидания»
если мидл выполняет обязанности старшего, или лида, то в этом случае он «превосходит ожидания»
Интересно, чем тогда старший с лидом занимались в то время, пока их обязанности выполнял мидл?
Есть матрица компетенции и должностные обязанности, например старший разработчик руководит разработкой фичи и является ментором для новичков, мидл по тем или иным причинам, взял на себя менторство нового сотрудника, или руководство разработкой новой фичи, вот и получается что он вышел за пределы ожидаемых от него компетенций. А старший разработчик или лид могут быть заняты другими проектами или тупо быть в отпуске, всякое бывает. Вот еще пример, лид команды уволился и старший разработчик исполняет его обязанности, в таком случае он должен получать добавку к зарплате или повышение ( с добавкой)
мидл по тем или иным причинам, взял на себя менторство нового сотрудника, или руководство разработкой новой фичи, вот и получается что он вышел за пределы ожидаемых от него компетенций
О чём думает руководство, давая сотруднику задачу, которая по их мнению выходит за рамки его компетенций. Они вообще рассчитывают на успех или же им все равно?
А как тогда сотруднику расти если он не будет брать такие задачи? Просто по выслуги лет? Чтобы стать лидом, нужна брать на себя проекты и показывать лидерские качества
Чтобы стать лидом, нужна брать на себя проекты и показывать лидерские качества
Факторов, которые влияют на карьерный рост, множество. Начиная со скиллов (способности, знания, опыт) и амбиций, заканчивая набором свободных позиций и межличностными отношениями с руководством. Не ясен смысл формулировок «превосходит ожидания» и «выход за пределы ожидаемых от него компетенций».
Руководители ждут, что обязанности будут выполняться подчиненными, у которых изначально для этого нет необходимых компетенций. А подчинённые, в свою очередь, ждут, что их за это повысят или через год заплатят бонусы. Так это работает?
На практике самый простой путь к росту это взятие на себя обязанностей следующей должности или грейда. Деньги придут в рамках года. Все хорошие начальники видят такое и по возможности повышают. Никому из хороших линейных руководителей не нравится когда клевый работник увольняется из-за того что его не повысили на зарплату на которую он уже работает. Нанимать сложно и рискованно. Лучше избегать этого по возможности.
Слова ничто. Код или софтскилы (если рост в сторону управления) все.
взятие на себя обязанностей следующей должности или грейда. Деньги придут в рамках года. Все хорошие начальники видят такое и по возможности повышают.
У руководителя проекта есть бюджет и штатное расписание. Если там появляются какие-то лишние деньги или люди с кучей свободного времени- чтобы помимо своих прямых обязанностей заниматься чем-то ещё, - то в течении года все это анализируется и оптимизируется.
Прошлые годы была ненормальная ситуация, когда проекты и штат надувались как пузыри. Но сейчас какой смысл портить нормального сотрудника за свой же счёт?
Слова ничто. Код или софтскилы (если рост в сторону управления) все.
Софт-скиллы это и есть слова, в основном. Как в паттерне «слова вместо результата» - работы, денег, должностей - где они в практическом смысле становятся на вес золота.
Бывает по разному. Период ковидного надувания не берем. В общем сделать мидла сеньором обычно можно. Сеньору поднять зарплату тоже можно.
Не чем-то еще. А своими обязанностями но больше. Договорится со смежниками, сделать и принести нормальную архитектуру твоей фичи а не ждать пока ее за тебя напишут, уладить вопросики с тестированием крупной фичи, взять на себя все общение с документаторами или самому написать хорошую документацию для фичи и тому подобное. Работы всегда много.
Не. Слова это поговорили и разошлись. Оно никому не надо. А софтскилы это проект требующий более одного человека был сделан. В срок, с нормальным качеством и все такое. Не только тобой, а другими людьми тоже. И другие люди в целом остались довольны проектом. Людей готовых взять на себя ответственность и успешно довести до завершения проект хотя бы на полгода всегда не хватает.
Я тоже так думала и брала на протяжении года все возможные задачи, чтобы апгрейдить скиллы. Вела три проекта вместо одного. В итоге на переоценке мне сказали, что брать задачи не по своей должности - это нормально и вообще это делается исключительно для моего обучения. Премия пришла копеечная в итоге - 20% оклада. А когда попросила заплатить за весь период «переработок» - технический директор разозлился и попросил «уйти по собственному», либо они сами меня уволят по статье… Так что тут не угадаешь, всё зависит от адекватности руководства.
Какая связь между карьерным ростом разработчика и позицией лида? В лиды обычно метят те, кто код писать не умеет, а нас и так неплохо (лучше, чем любого лида) кормят.
Я с вами не соглашусь. Лид != начальник отдела. Многое зависит от компании, по своему опыту скажу, что лид это и сильный разработчик тоже, который больше взаимодействует со стейкхолдерами. Ну и у лида грейд выше, соответственно и ЗП выше
лид это и сильный разработчик тоже, который больше взаимодействует со стейкхолдерами
У слова «Lead» есть словарное значение; сложно быть лидом не тратя огромные ресурсы на собственно людей в команде. Кроме того, общение со стейкхолдерами тоже требует времени, которое отнимается у собственно работы с кодом. А чем меньше человек копает лопатой, тем быстрее теряется навык виртуозного владения лопатой.
у лида грейд выше, соответственно и ЗП выше
Вообще не обязательно. Речь не идет, конечно, про джейсоноукладчиков.
Обычно есть грейды разработчика инженера, у каждого грейда своя вилка, чем выше грейд, тем выше вилка.
А чем меньше человек копает лопатой, тем быстрее теряется навык виртуозного владения лопатой.
Здесь я с Вами соглашусь, поэтому и отказываюсь от должности лида, так как, у этого есть свои недостатки: больше митингов, меньше разработки, вероятный переход в другую команду (два лида не нужны в одной команде)
Обычно есть грейды разработчика инженера, у каждого грейда своя вилка, чем выше грейд, тем выше вилка.
Конечно. Сравните грейды «Principal Engineer» и «Team Lead». А ведь еще в некоторых конторах есть «Distinguished Engineer».
Principal Engineer это дальнейший рост для лида, а не для сеньора. По нашему это руководитель направления или отдела или что-то такое. Руководитель лидов или лидовлидов. Или прямые подчиненные СТО.
Сеньор это конечная точка для технаря без подчиненных. Дальше есть единичные звезды, но это уже прямо исключение. Вырасти в звезду обычно невозможно.
Principal Engineer это дальнейший рост для лида, а не для сеньора.
Да ну? А что делать с людьми, которые не хотят становиться лидами, а хотят писать код, и действительно умеют это делать? Выгонять на мороз?
У меня был случай, чтобы не ссориться с эйчарами, бухгалтерией и прочими бюрократами из-за выплат, у нас была создана «Aleksei’s team», но подчиненных там все равно никаких, конечно, не было.
Они работают сеньорами, получат зарплату, премию. Что не так?
Исключения всегда бывают. Но рассчитывать попасть в исключения это так себе план.
Что не так? — Да буквально всё. Если в конторе нет возможности вырасти по деньгам до приемлемых величин (сравнимых с руководителями крупных отделов, хотя бы), без необходимости иметь подчиненных — шанс нанять крутого разработчика как бы отрицательный (или придется врать на собеседовании).
Так себе план найма, хотя для галер сойдёт.
Руководитель крупного отдела это наверно человек от 100 сотрудников. И гигантская зона ответственности.
Что и как должен писать один разработчик чтобы получать столько же? Чем он должен быть лучше обычного хорошего сеньора с рынка?
Что […]
Библиотеки, фреймворки, алгоритмику, и т. п.
[…] и как
Быстро и пуленепробиваемо.
гигантская зона ответственности
У такого разработчика зона ответственности не меньше, а часто — больше, ибо от его факапов может пострадать весь бизнес.
У такого разработчика зона ответственности не меньше, а часто — больше, ибо от его факапов может пострадать весь бизнес.
Не может.
Если от факапов разработчика может пострадать весь бизнес, значит, неправильно поставлены планирование и тестирование. И, возможно, найм.
Если от факапа разработчика внезапно пострадал весь бизнес, то это факап не разработчика, а его менеджмента (лида, инжиниринг-менеджера или кого бы то ни было)
Факап — это же не «понавыкатывал багов в прод», ну что за детский сад, причем тут вообще тестирование и планирование?
Факап (мой личный, да) — это смог убедить всех в 2014, что Riak — лучшее решение для распределенного KV-store в наших условиях (стек, типы задач, итп). А Basho взяли и разорились, причем, оставив Riak в полуподвешенном состоянии.
"А Basho взяли и разорились" - это не факап, а естественный риск, заложенный в саму природу принятия такого рода решений. Он сыграл, бывает.
Но, допустим, проблема бы была не конкретно в разорении вендора (называть его разорение собственным факапом это кокетство), а произошла бы действителньо ошибка ведущего специалиста, ошибка инженерного плана, выбрали неподходящее 3рд-пати решение, что это означает?
Судя по вашему "смог убедить" - решение принимал не один человек, а некий синклит (и это правильно). А значит, проблема была бы не в одном человеке, а в том, что его предложение неверно рассматривалось. Допустим, вместо полноценного ревью его предложений, с вниканием и собственным исследованием, просто послушали, махнули рукой и согласились. Ну так это опять-таки ошибка не разработчика, а организации процесса. Ч. и т.д.
Если ошибка разработчика становится проблемой для бизнеса - это не ошибка разработчика.
У меня нет привычки оправдывать свои ошибки перекладыванием ответственности на «организацию процесса» и «синклит».
Я тут самый компетентный, я называюсь Principal Engineer, у меня богатая грамотная речь — конечно я смогу убедить окружающих, тоже мне, бином Ньютона. Ни в каком наидеальнейшем мире это не будет ошибкой «всех вокруг». Всегда есть самый компетентный, и если он не боится принимать решения — то ему не до́лжно бояться и признавать ошибки. Иначе грош ему цена.
Всегда есть самый компетентный, и если он не боится принимать решения — то ему не до́лжно бояться и признавать ошибки. Иначе грош ему цена.
Да можно хоть обпризнаваться, можно лоб разбить в монастыре от покаяния, но если в промышленной разработке на любом уровне бас фактор равен единице, то проблема не в самом распрекрасном суперстаре, как бы он ни был готов принимать на себя горы ответственности, а именно в процессе. Т.е. в менеджменте.
При чем тут вообще бас-фактор? При чем тут какие-то суперстары?
Ну снимите свои розовые очки и предложите вариант, при котором менеджмент предотвращает ситуацию «выбран неправильный вендор». В реальном мире, ну, а не в том, в котором феи на понях и единороги.
Ну снимите свои розовые очки и предложите вариант, при котором менеджмент предотвращает ситуацию «выбран неправильный вендор». В реальном мире, ну, а не в том, в котором феи на понях и единороги
В любом нормальном бизнесе.
Хеджирование рисков, второй вендор для всего критичного. Это все изобретено и внедрено больше 100 лет назад.
Концепцию генштаба давно придумали. И вообще не просто так.
Любые серьезные решения принимаются только группой людей вместе. И озвучиваются от имени этой группы людей. Кто именно спикер не важно.
Зачем вы меня тут все хором учите, как вывернуться и убедить себя, что виноваты обстоятельства? Я не кисейная барышня, мне это без нужды. Меня тогда и не распяли на рее, в принципе.
Да, генштаб — это прекрасно. Кто спикер — тоже не важно. Подписываюсь под каждым словом.
Дальше-то что? Напоминаю: разговор начался с «факапа ведущего разработчика». Не каждая команда (да и не каждая страна, даже) может себе позволить содержать генштаб. В любом генштабе всегда есть тот, кто больше знает, и ярче говорит.
Вот только если убрать всю эту смузи-казуистику, это факап ведущего инженера, предложившего и отстоявшего неправильного вендора. В его голове, — и с точки зрения вселенной, энтропии и высшей правды.
Я же не говорю, что его надо наказать за это, ну.
Бизнесу точно нужны такие разработчики в сколь либо значимом количестве? Опенсорс "Библиотеки, фреймворки, алгоритмику, и т. п." достаточно хороши для подавляющего большинства задач. Исключения есть, но это опять исключения которые вообще не массовые и рассчитывать строить карьеру на них странно.
С чего бы это? Ну сделал он фигню, все дружно высказали что фигня и перешли на Постгрю. Тот кто фигню сделал пошел джейсоны перекладывать с удвоенной скоростью чтобы не уволили. Бизнесу вообще плевать какие там библиотеки с фреймворками. Ему надо чтобы работало.
А вот заваленные бизнес проекты на десятки человеколет это больно для бизнеса. А это типичные проекты руководителя сотни человек.
Ну еще есть архитекторские должности. Я вот часто работаю архитектором на проекте вообще формально без подчиненных,
Архитектор обязан писать код 60–80% своего вреени, иначе он полностью оторвётся от корней и начнет придумывать ковры-самолеты для полета на Марс.
Архитектор в принципе может вообще код не писать. На практике это дай бог 20%.
И он сразу становится не нужным. Если не писать код или хотя бы не руководить разработчиками то быстро переходишь к рисованию воздушных замков которые не имеют отношения к реальной разработке. Разработка покивает головой на такие планы и сделает все нормально.
А если половину или больше времени писать код, то получается хороший сеньор.
Это обычно функция сеньоров-лидов, ревью СТО проводит. Выделенная должность это редкий случай.
Не очень понятно, как «превзошел ожидания» соотносится с переработками. Эта оценка относится к должностным обязанностям и компетенциям
Ну, в принципе, у начинающих разработчиков может возникнуть идея экстенсивно подменить недостаток компетентности (одним из проявлений которого может быть недостаточная производительность) переработками. А у начинающего руководителя может возникнуть впечатление, что так и есть.
И наоборот, если проект успешно сделал и внедрил, но пару раз превысил эстимейты, запросто выставят "работал согласно ожиданиям», что в яндексе во многих подразделениях расценивается как провал, а некоторыми младоруководителями и как повод к увольнению.
Дайте IT команду под начало человеку, построившему карьеру, например, на руководстве продажниками (где KPI действительно легко меряется количественно) - увидите.
Яндекс большой. Не припомню оплаты за переработки, а вот код ревью, пройденное в чпс ночи - вполне себе рабочая ситуация. Но и оценку на ревью, привязанную к переработкам тоже не припомню. Работать в любой время и день недели нормальная практика в разных командах.
На счет 1,5-2 за переработки - встречал такой только раз в Luxoft и то далеко не везде и далеко не за регулярные пару часов после работы. И это за 28 лет.
код ревью, пройденное в чпс ночи - вполне себе рабочая ситуация
Но это не означает переработку. Скорее то, ччто в течение дня похалявил и догнался ночью. Регулярно так делаю, когда из дома работаю. Каюсь ;)
Но и оценку на ревью, привязанную к переработкам тоже не припомню.
Теоретически, можно компенсировать собственную низкую производительность переработкой, но для меня это тоже странно, что автор исходной статьи выставляет это за правило.
1,5-2 за переработки - встречал такой только раз в Luxoft и то далеко не везде и далеко не за регулярные пару часов после работы.
Конечно, не регулярка. Регулярная переработка или переработка, инициируемая работником - это большой косяк в процессах и в бигтехе скорее исключение. Но когда бизнесу очень надо, он приходит с просьбой о сверхурочных и оплачивает их соразмерно
В одном бигтехе выше среднего, года 3 назад, сотрудники одной из команд по просьбе работодателя работали по схеме 996 (месяца 2-3), получая по повышенному тарифу всё что выше 40 часов в неделю.
Про переработки из статьи: кто-то копал 40 часов в неделю, а кто-то 60, очевидно, что второй мог выкопать больше, даже если помыслить, что сотрудник менее эффективен, 45 все равно больше 40. И тогда, да работодателю как-то такого сотрудника надо поощрить, ну в вот ревью это для этого подошло. Но получают хорошую оценку на ревью не только хронические «переработчики» (они если можно так выразиться как раз и «портят всю малину», задавая не верный стандарт, но больше сделанной работы за те же деньги в надежде на хорошее ревью, скорее всего работодателю нравится), но и люди, которым реально не пофиг, которые за счет своей экспертизы, могут недели программирования заменить на часы или дни проектирования, которые на столько хорошо проясняют требования и так хорошо их реализуют, что код ревью и тесты проходят без замечаний, а ещё хорошие оценки ставят за надежность и ответственность.
кто-то копал 40 часов в неделю, а кто-то 60, очевидно, что второй мог выкопать больше
Кому очевидно? Создателю теории «Девять женщин могут родить ребенка за месяц»?
И тогда, да работодателю как-то такого сотрудника надо поощрить, ну в вот ревью это для этого подошло.
В моем понимании, результатом таких переработок должен быть 1:1 встреча с руководителем и выяснение причины переработок: ( низкая компентенция, проблемы в планировании или оценки сложности задачи). То есть, для руководителя переработка - это звоночек, а регулярные переработки - это колокол
Переработки везде х(1.5-2) платные
Нигде где я работал они не были платные, а мотивация была простая - не хочешь сниженный кэф премии или уход по соглашению сторон под давлением, будешь делать что говорят)
Встречаются два бывших одноклассника. Один преуспевающий бизнесмен, второй уже практически бомж. Первый говорит:— Привет, сколько лет, сколько зим! Как жизнь?
Второй, угрюмо:
— Плохо все. Жена ушла, с работы уволили, денег нет.
Первый, в знак старой дружбы предлагает:
— Слушай, есть у меня для тебя работа.
— Да я ничего толком делать-то не умею...
— Ерунда! Работа такая: видишь напротив банк? Каждый месяц, десятого числа ты будешь ходить в этот банк и забирать два чемодана денег. Один будешь отдавать мне, а второй себе.
На том и порешили.
Проходит полгода. Второй поднялся, жена вернулась, машину купил, дом. Но ходит все мрачнее и мрачнее.
Первый спрашивает его:
— Ты чего такой хмурый?
— Знаешь я тут долго думал, несправедливость какая-то есть. В банк я через дорогу хожу один, а деньги пополам делим.
Ни кто не платит за уже оказанные услуги. Поэтому оплату овертаймов нужно согласовывать заранее. Это не так уж и сложно - работать бесплатно вас в любом случае ни кто заставить не может.
Годовой бонус это не оплата уже сделанной работы, а мотиватор весь следующий период работать лучше. Не в смысле количества часов, а качества, включая пресловутые extra mile. То есть, это не оплата ваших инвестиций, это инвестиция в вас со стороны бизнеса.
Если менеджмент по каким-то своим причинам его занижает или вообще отказывается платить это в общем-то их решение и их проблемы. Скорее всего ваша работа здесь не сильно нужна и всем будет лучше расстаться с миром.
Представь, что ты каждый месяц отдаёшь компании 20-30 дополнительных часов (если что – это всего лишь 1-1.5 часа каждый день). За год это 240-360 часов — два полноценных рабочих месяца бесплатного труда.
насколько я помню курс экономики - товар, это не только то, что вы готовы продать, но и то, что у вас готовы купить. Если вы предлагаете своей компании своё сверхурочное время и она соглашается, то странно, если она за это не платит и в принципе это уже прямое нарушение ТК.
Если вы добровольно, без запроса со стороны компании и без согласования с руководством работаете сверхурочно - то это можно в лучшем случае рассматривать как собственный маркетинг насчёт бонуса (хотя для нормального менеджера это скорее сигнал, что вы недостаточно компетентны, если не можете закрывать задачи в установленное законом время). И говорить, что вам их обязаны оплатить - это примерно как требовать заплатить от каждого, кто получил рекламную листовку.
А у вас есть другой способ хотя бы относительно справедливо раздавать премии лучшим? С учетом что надо выбрать лучших из тысяч обычных работников.
У Нассима Никласа Талеба в книге "Черный лебедь" есть глава с провокационным названием "Спекулянт и проститутка". Там он разделяет профессии на "масштабируемые" и "немасштабируемые". Последние -- те, где платят за время, проведенное за работой, и для того, чтобы заработать существенно больше, нужно и времени за работой провести сообразно больше. Масштабируемые -- где платят за менее поддающиеся контролю вещи: талант, интуицию, на крайняк, удачу (и тут необязательно проводить больше времени за работой). Время -- ресурс ограниченный, так что и диапазоны зарплат в этих типах профессий разные.
Автор явно считает свою работу немасштабируемой. "Ничто не ценится дешевле уже оказанной услуги" -- этот принцип в таком случае как никогда верен.
Я идеи Талеба развиваю дальше, и считаю, что правильнее говорить о нескольких уровнях масштабируемости профессий (по одному на каждый домен сложности в Cynefin Framework). В этом смысле профессия инженера -- средней масштабируемости. Хотя и это зависит от приложения, компании, уровня самого инженера, и т.д.
В своей компании я работаю скорее меньше тех 40 часов, которые формально учитываются. Хотя что считать работой? Когда я пью кофе, я обычно еще продолжаю размышлять на рабочие темы: это учитывать? Во время езды в транспорте -- тоже. В компании с хорошей инженерной культурой даже сидя на унитазе сотрудник приносит пользу: и тут можно поднять тему связи грязи в туалетах с техническим долгом в коде. А если я по ночам книжки умные читаю, это я для работы или для себя?
Резюме: мне не интересно указывать переработки и выскабливать "чаевые". Зато потратить время на собственную венчурную идею мне не претит, пусть даже она не выстрелит.
В компании с хорошей инженерной культурой даже сидя на унитазе сотрудник приносит пользу
Как-то приехал к нам в командировку сотрудник иностранного офиса, но у него все дни были расписаны встречами на 110%. Мне он не то, чтобы позарез нужен был (так бы я довёл метрику выше до 120%), но парой слов перекинуться было бы полезно.
Ну, что, наткнулся в туалете, задачу решил)
Премии - это не обязанность, а добровольное действие в компании. Устраиваясь - считайте зарплату без премий и вопросов не будет.
Перф-ревью показывает не количество часов переработки, а соответствие ожиданий к сотруднику и реальности.
Перф-ревью показывает не количество часов переработки, а соответствие ожиданий к сотруднику и реальности.
Все верно. При правильной оценке сотрудника, его работа всегда будет соответствовать ожиданиям компании. Соответственно, чтобы получать больше, нужно превосходить ожидания.
Если качество работы сотрудника уже оценивается правильно, то остаётся повышать количество работы, выполненной внеурочно. При этом, логично, что оплаченные переработки будут так же оцениваться как соответствующие ожиданию.
Автор статьи видит выход - получать оценки выше ожидания, путём неофициальной переработки.
Конечно же, это ловушка - рано или поздно компания повысит оклад и автор статьи уже не сможет соответствовать ожиданиям компании без неофициальных переработок.
Премии - это не обязанность, а добровольное действие в компании. Устраиваясь - считайте зарплату без премий и вопросов не будет.
Плюсую. Если без премий деньги не устраивают, значит надо искать работу с зарплатой повыше, ибо премии — это не только приятный бонус для работника, но и потенциально неплохой такой рычаг давления со стороны компании, а потому нечего его компании давать.
А чего, какие варианты-то? "Дайте мне денег, я буду работать, мамой клянус"? А если не будете, отдадите обратно?
А если компания вам платит до того, как вы что-то делаете, означает ли это, что в кредит у компании берете уже вы?
Если говорить про работу в компании, то я руками и ногами за соблюдение четких рамок: вот мои интересы, вот ваши интересы. И здесь материалу однозначный плюс. А вот когда речь заходит о том, чем горишь ты сам, то как по мне "work-life balance" сильно, очень сильно переоценен. И принцип "делай как чувствуешь" будет в этом случае просто в основе работы
Когда компания задерживает выплату на год, она обесценивает твой труд инфляцией. Деньги через год стоят меньше, чем сегодня.
А с чего вы взяли, что при гипотетической оплате "сегодня" вы получили бы столько же в номинальном выражении, сколько и при оплате "через год"?
Если бы речь шла о выплатах, номинал которых закреплен (например о зарплате, размер которой зафиксирован в трудовом договоре), то там задержка выплаты действительно обесценивала бы её. Но годовой бонус не имеет зафиксированного какими-либо соглашениями или нормами закона номинала, поэтому нет никаких причин считать его неизменным. А, следовательно, и ваш тезис про обесценивание не валиден.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Performance Review: почему твоя премия — это беспроцентный кредит компании