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

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

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

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

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

Является ли это справедливым, чтобы быть сварливым в этом сценарии? Конечно. Справедливо ли требовать повышения зарплаты? Может быть, а может и нет - возможно, сотруднику даже платят слишком много. Так как работодатель и работник, очевидно, имеют разные ожидания от работника, нельзя сказать, что

Культура тоже имеет значение - я в Швеции FWIW (как правило, относительно плоской иерархии и уполномоченных сотрудников / слабых менеджеров).

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

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

Если еще есть место для разработчика, который отказался от возможности, то задайте ему эту задачу.

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

Позвольте мне поиграть в адвоката дьявола:

• Ваша компания взялась за работу, в которой у нее нет абсолютно никаких компетенций.
• Эта работа в области, которая очень сильно отличается от большинства других областей в разработке программного обеспечения. Это не ваш обычный “выучить новый язык программирования”, это тяжелая математика, которой боятся даже большинство математиков.
• Ваша компания отказывается нанимать нового руководителя, вместо этого она считает, что теоретические тренинги и курсы могут компенсировать отсутствие опыта.
• Они поставили безнадежный оптимист и энтузиаст у руля (вы)
• Лидер (вы) даже не может признать, что другие люди могут иметь другие цели, чем он.

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

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

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

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

Давайте вернемся к последнему пункту моего пулевого списка, который является единственной вещью, которую вы лично сделали неправильно. Вы приняли решение о том, чего хотят другие дьяволы в ваших руках. Вы, кажется, не понимаете, что то, что вы видите как захватывающее, другие люди могут видеть как пугающее или просто скучное. Вы видите в этом повышение, отказываясь принять то, что другие могут видеть в этом понижение. Или просто не подходит для их баланса между работой и жизнью. Другой угол зрения заключается в том, что вы видите это в рамках позиции “разработчик”. Проблема в том, что это всего лишь мнение. Противоположное мнение, что это совершенно новая работа, так же верно, как и ваше. Вы должны ожидать, что другие люди не разделят вашего мнения. Было нормально случайно спросить, хочет ли кто-нибудь новую работу. Но вы должны были ожидать “нет” столько же, сколько “да”.

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

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

ИМХО его вопрос не был настоящим, он просто не хочет новую работу. И перевернул все на тебя, так что это ты должен сказать “нет”. Здесь тебе не с чем справиться, кроме как изменить свое отношение к команде, разделяющей твои убеждения и жизненные цели.

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

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

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

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

Ворчун с этим справился очень плохо. Однако…

Как человек, который был разработчиком в течение десятилетий, а сейчас является исследователем математики, делающим много predictive analytics, я вроде как вижу точку зрения Ворчунья. В то время как разработчики программного обеспечения должны быть готовы к изучению битов и кусочков из самых разных дисциплин, чтобы выполнять свою работу, существует существенная разница между разработчиком и исследователем, так же, как и между менеджером и разработчиком. Это не похоже на то, что он отказывается изучать новый язык программирования или придумывать, как взаимодействовать с каким-то странным оборудованием; это больше похоже на то, что он отказывается заниматься графическим дизайном, управлять командой или летать на самолете.

Grumpy может быть математически фобичным. Но также возможно, что он знает достаточно о статистике и добыче данных, чтобы подозревать, что это будет трудный, мутный слог. В этой конкретной области математики очень легко выучить некоторые техники, но также легко применять их в неправильных ситуациях! Старшеклассник мог бы научиться делать ARIMA, но знать, когда она действительна и как выбрать правильные параметры, больше на уровне аспиранта. Многие математики не любят статистику не потому, что она сложнее других полей, а потому что она более… кропотлива.

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

Говоря как математик-разработчик программного обеспечения, я симпатизирую Grumpy: т.е. сейчас я предпочитаю разработку программного обеспечения (и я думаю, что сейчас я лучше разбираюсь в разработке программного обеспечения, чем в математике).

С другой стороны, если бы я был на месте Grumpy и хотел сказать это вам, я бы сказал - и я бы не путал вопрос с упоминанием зарплаты.

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

Поэтому моим советом было бы попробовать разделить вопросы, даже если Ворчун не разделял их. Спросите: “Ворчун счастлив ли Ворчун со своей нынешней зарплатой? Просит ли он прибавки независимо от этого нового проекта?” Учитывая, что он один из двух самых старых и опытных разработчиков, стоит ли сначала предложить ему безусловную прибавку, а затем спросить, готов ли он сделать это новое дело?

И/или вы можете его успокоить о характере новых обязанностей? На его месте я мог бы беспокоиться о провале. Повышенная зарплата может быть “деньгами за риск”, чтобы компенсировать мне повышенный риск или стресс, или неоплаченную сверхурочную работу. Например, будет ли компания оказывать достаточно помощи (например, эксперт в области, т.е. наставник по математике), чтобы гарантировать его успех?

Вы говорите, что это “исследование на академическом уровне”, но также и “в основном исследование программного обеспечения”, которое может быть взаимоисключающим/контрадирующим. Очевидно, что вы более продвинуты в академических исследованиях, чем он?

Возможно ли, что разработчик чувствует, что ему недостаточно платят за работу, которую он сейчас выполняет? Обычно, когда люди говорят “мне за это не платят достаточно”, это означает, что они чувствуют, что их недооценивают в целом, и это может быть риском побега.

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

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

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

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

Так что я бы сказал, чтобы сделать здесь, это взять этого парня, как если бы он говорит вам эту вещь, а не “заплатить мне больше”, потому что в каком-то смысле это это то, что он делает. Проблема здесь на самом деле не в том, что разработчики программ получают X, а математика должна дать вам X + 10%, а в том, что разработка некоторых программ на самом деле не требует математики, и поэтому просить людей делать много, значит, что вы получите нечто меньшее, чем звездные результаты. В зависимости от ситуации, я могу порекомендовать:

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

• Привлечение аналитика для вычисления уравнений, а затем приказание вашим существующим разработчикам внедрить уравнения в код, точно так же, как они сделали бы это с любой другой частью бизнес-логики. Недостатком этого является то, что человек, знающий математику, в конце концов не записывает математику в вашу систему, но это можно довольно легко решить, сделав упор на разработку, основанную на тестировании (что вы уже делаете, верно? Верно?). Этот метод также имеет то преимущество, что, если вы работаете, например, в области финансов, вы можете взять один из номеров людей из их отдела: есть шанс, что они будут знать этот материал лучше, чем практически любой s-dev, который вы можете принести с улицы, потому что это их работа.

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

Как я уже сказал, я не очень большой поклонник этой фразы, и, возможно, это само по себе означает, что вам нужно поговорить с человеком, который говорит это (я бы, в отступление, остерегался, чтобы он не придерживался Bus Factor и, возможно, пришло время пройтись по кодексу этого парня, не в наказание, а потому что люди из IME, которые думают с точки зрения оплаты труда в этой индустрии, также думают с точки зрения того, как сделать что-то, чтобы сделать себя незаменимым). Я не думаю, что он обязательно неправильно.

Вы упомянули, что Ворчун - один из старейших разработчиков. Интересно, сколько лет? Много лет назад у меня работал человек, которому было за 50, он был компетентным разработчиком, он был счастлив в своей работе, но он отказывался брать на себя какую-либо дополнительную ответственность. Оказалось, что была история, в прошлом ему приходилось делать перерывы в карьере из-за стресса, он знал свои пределы, и он не хотел их переборщить. Уважайте его суждения и используйте его для того, что он делает хорошо.

Я бы сказал, что ответ зависит от того, насколько точна оценка разработчика.

Если его описание работы на самом деле включает в себя выполнение такого рода работы, и его ставка оплаты для этого подходит, то его утверждение является неточным.

С другой стороны, описание его работы и/или ставка оплаты труда не соответствуют новому типу работы, тогда они должны быть скорректированы, чтобы точно отразить это.

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

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

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

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

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

Я думаю, что пара второстепенных пунктов, связанных с вопросом, не были заданы/отвечены другими плакатами (на момент написания статьи):

• Как называется старая позиция?
• Какую сумму получает эта позиция? (Рыночные курсы)
• Каково название новой позиции?
• Что за название платят? (Рыночные ставки)
• Какова разница в зарплате между “Старшим разработчиком” и “Это название”

• Стоит ли ему время/усилия, чтобы получить разницу в зарплате?

• Каково название текущей позиции? Различные титулы получают разную заработную плату… есть разница между разработчиком и инженером… старшим разработчиком и старшим инженером. Как называется новый титул? Математический разработчик? Разработчик-исследователь? Старший инженер-исследователь?

Как кто-то из сотрудников этого звания получает оплату по рыночным расценкам? Есть должности, которые “труднее”, но за которые платят меньше…. Подумайте, исследователь в университетах… многие люди пытаются получить эти должности, поэтому спрос снижает рыночные ставки.

Какая разница между текущим “Положением” и “Новым Положением” на рынке? Если это 1000 долларов в год… это другой разговор, чем 75000 долларов в год…

Что означает… стоит ли “Ворчун Дев” учиться “Математическим исследованиям”? Да, это правда, что часть Жизни Разработчиков - это изучение новых вещей… это также изучение новых вещей, которые являются ценными. Либо в денежном выражении (повышение зарплаты), либо в другом (карьерный рост, новые возможности, новые технологии)…

Сэр Ворчун, для меня, дал понять, что его главный приоритет - деньги. Если он хочет стать Front End Developer, а вы пытаетесь сделать его разработчиком прикладных наук… то, возможно, ему не стоит переключаться - при той же шкале оплаты. Единственный способ считать, что это того стоит - $$$. Либо так, либо он не заинтересован и перекладывает ответственность на вас. Соответствуют ли рыночные ставки его ожиданиям? Ваши ожидания?

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

Но чтобы ответить на ваш вопрос - “это справедливая просьба? Это справедливо по отношению к нему, но совсем не обязательно, чтобы вы взялись за это.

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

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

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

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

Что ваш товарищ по команде просит, это нечестно - вообще.

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

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

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

Реакция вашего товарища по команде является откровенно непослушной и токсичной. Вам не нужен такой человек в вашей команде.

Этот вопрос должен быть поднят до менеджера или кого-то, кто отвечает за оценку работы вашего товарища по команде.