How to become an author
Search
Write a publication
Pull to refresh

Comments 157

Я бы посоветовал инженеру пройти марафон https://hyls.ru/jedi-30
А дальше по результатам.
Если продуктивность вырастет, то оставил бы. Если останется на прежнем уровне, то неспешно поискал бы замену. Но однозначно не стал бы просто увольнять без адекватной замены.

Total votes 15: ↑0 and ↓15-15
Касательно «жертв личного времени» — если они регулярно нужны, то что-то не так с командой и менеджментом. Никто не обязан им жертвовать.

Но в целом, кадровые решения должны приниматься исходя из интересов компании. И если разработчик в целом ничем не лучше остальных, никаких уникальных звёздных фич у него нет, свободно заменяем, при этом создаёт проблемы — то увольнять, конечно. Менеджер ему не отец родной, менеджер работает на компанию, а не на разработчика.
Total votes 22: ↑22 and ↓0+22

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


Вариант с контролем довольно неплох, если он отнимает мало сил или его можно зоть частично автоматизировать(это тоже время, но оно окупиться)


Тут в любом случае стоит смотреть рационально:
время на найм нового+время вливание нового в колектив и прочее должно быть больше сумарного времени контроля над старым сотрудником(ибо без одного разработчика эффективность команды упадёт на 1/7 временно, а это тоже не хорошо)


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


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


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


А лучше всего спросить внезночай других руководителей отделов(и если можно кого-то по-выше) о похожих ситуациях(кажется автор это и сделал, но слегка расширил круг опрашиваемых)

This comment wasn’t rated yet0
Такой сотрудник создает плохой пример остальным. И то что прокатывает у одного, потом будет и у других.
Total votes 1: ↑0 and ↓1-1
мне ближе — дать ему мини-проект. а в идеале — дать ему возможность сменить сферу деятельности. может он выгорел и смена рода деятельности в рамках команды/проекта даст ему новый толчок.
Total votes 3: ↑3 and ↓0+3
Сотрудника все устраивает. «Дать сменить сферу деятельности» — это уволить?
Total votes 2: ↑2 and ↓0+2
Может, ему пора в «бизнес», в PO?
This comment wasn’t rated yet0
У PO навыки тайм-менеджмента и уровень эмоционального интеллекта должны быть еще выше, чем у разработчика.
Если уж парень на позиции разработчика не умеет нормально коммуницировать с другими людьми («при возникновении спорных моментов в реализации фичи «проблемный» инженер спорит до посинения и не слышит аргументов других разработчиков»), какой из его PO?
Total votes 2: ↑2 and ↓0+2
Зато видение свое протащит. Хотя, в исходных данных не указано, есть ли оно у него )
Total votes 1: ↑1 and ↓0+1
Перевести в инфраструктурно-платформенно-библиотечную команду. Судя по всему, человека больше интересует «общественная» работа.
Total votes 5: ↑5 and ↓0+5
Это уход от решения. По сути это означает, что этот выбор будет делегирован другому руководителю.
Total votes 5: ↑2 and ↓3-1
Почему уход? На мой взгляд это вполне один из вариантов решения.
Можно же по договоренности с другим руководителем попробовать это сделать.
Не всегда разработчик попадает сразу в нужную команду, может в пределах компании есть более подходящая для него.
И соглашусь с комментатором выше — не всегда имеет смысл держаться до последнего за человека, если видно, что он не вписывается в команду.
Total votes 4: ↑4 and ↓0+4
В качестве эксперимента. Провалится и там — на выход.
Total votes 3: ↑3 and ↓0+3
Почему уход, может быть ему просто больше нравится решать задачи другого рода, а скучные бизнес круды/интеграции его просто не мотивируют и он над ними работает добросовестно, но в таком темпе, чтобы не сгореть от качества той кодовой базы, в которой он сейчас находится. Короче если у человека есть скиллы, но он не вписывается в команду, то просто поискать команду с более близкой ему культурой. Если таковых нет, то обсудить это с ним напрямую и дать время на поиск новой команды вне компании.
Total votes 4: ↑4 and ↓0+4
Любые вопросы с кадрами легко решаются, если рассматривать трудовые отношения как аналогию с купли-продажей рабочего времени (либо результата) и знаний.
Забудьте о всяких корпоративных мотивациях и прочей шняге. Сотруднику от вас ничего не нужно, кроме денег. Всё всегда переводите в деньги. Сотрудника никак не должна интересовать компания, кроме как источник его персональных финансов.
Поэтому:
1. Переходите на сдельную оплату по результатам труда.
2. О «жертвах личного времени» нужно также заранее. Если для вас это важно, то обозначьте например, что каждый его внерабочий телефонный вызов будет оплачен в размере $100 Конкретная сумма — это вопрос договоренности, но она должна быть такой, чтобы он сам с удовольствием бежал к телефону, чтобы заработать на ответе на ваш вопрос. И боялся его выключить, чтобы не дай бог не пропустить «халтурку».
3. Финансово не договорились — расходимся.
Total votes 8: ↑3 and ↓5-2
Напомню, что по условию этой мысленной задачки — вы руководитель. И как каждый руководитель, стараетесь получить больше пользы за меньшие деньги. Если в команде достигнута такая атмосфера, что сотрудники относятся к продукту как к своему «шедевру» и готовы вкладывать даже личное время в продукт — почему бы это не поддержать? В данном случае один сотрудник к этому не готов, и эта позиция может привести к тому, что и остальные перестанут уделять проекту дополнительное время. Честно ли это? Честно!
Выгоден ли такой вариант Вам как руководителю? Ну не знаю…
Total votes 7: ↑5 and ↓2+3
UFO just landed and posted this here

Место и время действия этой мысленной задачки назовите тогда уж. Одно дело «Россия» и «сейчас» с досадными мелочами типа трудового законодательства, другое дело «Россия» и «17 век» без них. «Руководитель» != «использованный презерватив», не так ли?


Если один гражданин не вписался в имеющийся коллектив, гражданина нужно из коллектива устранить, неважно куда. Даже если этот имеющийся коллектив на самом деле серпентарий. Но «не вписался» тоже понятие интересное: иногда в коллективе удобно иметь одного человека, которого ненавидят все остальные. Или этот человек иным способом командообразует, например, берётся за самые тяжёлые рутинные задачи беспрекословно.

Total votes 3: ↑3 and ↓0+3
Напомню, что всегда нужно ставить себя на место обоих человек. По условию этой мысленной задачи сотрудник также желает поменьше работать за бОльшие деньги.
Ну и за честность: честно то, что равноправно. Договаривайтесь взаимно, забудьте слова «начальник» и «подчиненный». Примите, что руководитель — это координатор проекта и равноправная с наёмником сторона договора. Каждый должен друг другу ровно то, о чем договорились и ни каплей больше. Он вам код, вы ему денгьги.
Договаривайтесь!
This comment wasn’t rated yet0

Про деньги — это спорный вопрос. Когда базовые потребности человека закрыты, даже $100 не будут аргументом для постоянных переработок, которые легко могут привести к перегоранию.
А сознательно ставить человека в ситуацию когда для закрытия базовых потребностей надо ловить каждую халтурку — ну так себе решение.
Соглашусь с комментаторами выше, что регулярные переработки — вопрос к менеджерам. Не стоит этим злоупотреблять, и тем более не стоит подсаживать на это подчиненных. Есть более эффективная схема работы, как мне кажется.

Total votes 2: ↑2 and ↓0+2
А кто говорит про постоянные переработки? Я так понял, что речь идет о каких-то критических случаях вне рабочего времени. То есть те случаи, когда отсутствие срочного реагирования влечет серьезные потери. Во всех остальных случаях можно подождать до утра.
This comment wasn’t rated yet0
Нужно больше подробностей об остальной команде.
Не слишком понятно как они одновременно работают быстрее и при этом часто овертаймят. Может они просто работают больше?
Total votes 8: ↑8 and ↓0+8
> приходит ведущий специалист от Бизнеса, который определяет приоритеты доработок и пользу от новых фич и сообщает, что недоволен продуктивностью одного из инженеров.

И отправляется дальше определять приоритеты разработок и пользу от новых фич.
Total votes 16: ↑16 and ↓0+16
Так и надо. Иначе он каждый раз будет находить самого медленного разработчика и пытаться его выгнать. Такой, очевидно, всегда найдется. Командная работа превратится в элиминатор
Total votes 2: ↑2 and ↓0+2
В майкрософт было подобная система оценки, когда вычисляли в команде сильного и слабенького разараба из-за чего два сильных сеньора не хотели попадать в одну команду, одного из них по-любому пометят слабым.
Total votes 4: ↑4 and ↓0+4
Какая дружественная там, видимо, была атмосфера
Total votes 1: ↑1 and ↓0+1
Ага, лет 10 назад я читал статью какого-то руководителя отдела R&D. У него в отделе все с ученой степенью (у них это доктор каких-то наук, но я не уверен, что это соответствует российскому табелю об ученых рангах).
И вот, в отчетах нужно среди этих докторов наук указать наиболее отстающего…
Total votes 3: ↑3 and ↓0+3
UFO just landed and posted this here
Ну, иностранный «доктор наук» — это, по нынешним временам, не бог весть какое достижение, в среднем по больнице оно означает, что чувак учился в вузе, закорешился с кем-то из профессоров и пошёл к нему аспирантом. Ещё фиг знает, почему пошёл — может, реально имел желание науку двигать, а может, просто работать не хотел. Прозанимался этим года три-четыре, приобрёл некий опыт, ценность какового, с точки зрения практического программирования, довольно сомнительна (хотя с точки зрения R&D, возможно, и нет). Наш «кандидат», как тут верно отметили, примерно соответствует ихнему «доктору» — и формально, и фактически, и попал туда примерно так же, и занимался там примерно тем же самым.

А идея с выявлением и увольнением «слабого звена» описывалась ещё в классике (то ли «Мифический человеко-месяц», то ли «Смертельный марш», что-то подобное). Там же описывалось и то, к чему это приводит на практике: в команду просто нанимается ненужный персонаж, специально под увольнение, вот наступает время — его указывают наиболее отстающим и увольняют, на его место нанимают нового такого же. И начальство довольно, что замотивировало команду на внутреннюю конкуренцию, и работа идёт, как и шла.
Total votes 1: ↑1 and ↓0+1
Кстати, то что ПО узнал о том что кто-то из команды так себе по скорости — говорит о некоторой, кхм, неуверенности автора задачки.
Total votes 2: ↑2 and ↓0+2
человек живёт удобно, размеренно, комфортно, наслаждается жизнью, нашёл свой стиль, уверен в нём
ну рано или поздно его потребности вырастут и он вынужден будет перестать лежать под пальмой по естественной причине, например, женится
нужно ли вам вмешиваться в его жизненную мотивацию — сомневаюсь
если сможете найти сотрудника лучше то зачем вам нужен этот сами решите
Total votes 2: ↑2 and ↓0+2

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

Total votes 4: ↑4 and ↓0+4
1. Берём в команду новичка с похожими скилами и горящими глазами
2. Ставим проблемника наставником новичка
3. Даём новичку и проблемнику смежные или даже одинаковые задачи
4. Новичок учится у проблемника и начинает выполнять его же работу лучше него самого
5. Переводим все задачи на новичка и повышем его до инженера (пряник)
6. Увольняем проблемника так как для него больше нет задач (кнут)
7. Результат — мотивированный и обученый сотрудник в команде, плюс психологическая демонстрация всей группе — за что бывает поощрение, а за что — увольнение.
Total votes 5: ↑3 and ↓2+1

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

Total votes 12: ↑12 and ↓0+12
Можно перевести проблемника на другой участок работ, а его старую работу дать новичку — это будет сигнал что проблемник свою старую работу плохо делал, потому отдали другому. Может поймёт, что на новом участке надо стараться лучше.

А вообще, руководитель обязан заботится о всей команде в целом — команда это такой суперорганизм, который make things done. Организм состоит из клеток, и если одна из них больная — тут либо лечить, либо удалять. В моей практике такие клетки редко поддаются лечению.

Естественно, сначала нужно поговорить, причём подкрепить цифрами любые обвинения в неэффективности. Если сотрудник работал всю жизнь и делал 100 стульев в час (утрирую), а тут вдруг стал делать 50 — возможно заболел, устал, стресс, проблемы в семье и тд. Но если он всё время делает 50 в команде где каждый делает по 100 — возможно, он не в ту команду пришёл.
Total votes 1: ↑1 and ↓0+1
> 2. Ставим проблемника наставником новичка

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

Вам предстоит нанять замену и уже не джуна. И это в кровавом интерпрайзе в условиях переработок и уныния будет не очень хорошей идеей.
Total votes 1: ↑1 and ↓0+1
Обожаю людей которые критикуют чужие идеи, не предлагая ничего взамен!

Можно сделать новичка падаваном всей команды. Но задачи давать смежные/схожие с «проблемным» участком.

Если «прекрасный» инженер уйдёт сам — это может и к лучшему, в РФ тяжело уволить сотрудника если он не косячит по жёсткому. После ухода может и атмосфера в коллективе наладится.

В любом случае, сам по себе он не изменится, ему комфортно.
Это как мой сосед, который любит слушать громко музыку после 23:00 — ему так комфортно, и пока не настучишь по батарее, он не станет ничего менять.
Total votes 1: ↑1 and ↓0+1

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

Total votes 4: ↑4 and ↓0+4
Долго искал подобный комментарий. Наконец-то нашел!

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

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

Увольнение — крайняя мера. Увольняя человека сразу, без разбора, вы лишаете его возможности работать над собой. А это неправильно, потому что он придет на новое место, и ничего не поменяется — человек продолжит портить жизнь, только уже другим людям.
Total votes 2: ↑2 and ↓0+2

Если это скрам-команда, то производительность одного инженера не должна волновать PO. Так ему можно и передать, вот команда, вот велосити, планируй от средней велосити за полгода. Кто там внутри команды как работает — не забота PO. Команда самоорганизоваться должна.
После разговоров с всей командой, обозначены болевые точки — ну так это отличная тема на грамотно проведенную ретроспективу, возможно с привлечением экспертных тренеров или психологов, чтобы устранить зажатость перед начальством.
На ретроспективе команда обозначает проблему, и сообща работает над ее решением. Отсутствие желания решать самим, нежелание озвучить общую проблему на ретре, переход на личности и неумение разговаривать — требует обеспечения обучению Скраму и квалифицированного обучения и подготовки.
Решит команда(включая проблемного) его уволить — обеспечьте увольнение, решит перевести — переводите, решит поговорить по душам за пивом в баре — выделите корп. бюджет на решение социальных разногласий в команде.

Total votes 9: ↑9 and ↓0+9
UFO just landed and posted this here

Я бы для помощи в принятии решения принял дополнительное допущение: допустил бы что он выполняет работу в те же сроки, что и все остальные, или даже быстрее или продуктивнее. Снова опросил остальных инженеров, как бы они в этом случае к нему относились, и было бы ли им комфортно с ним работать. Рискну предположить что они все равно бы отказались бы с ним работать.
Тут возможны два вывода: первый — софт-скиллс проблемника, мешают работать команде и его надо увольнять. Изменить его софт-скиллс вы вряд ли сможете.
Второй неочевидный вывод: проверить гипотезу о том, что коллективное большинство — тайно "подтравливает" или "съедает" по какой-то причине проблемника (внутренний конфликт, с одним(альфа) или несколькими инженерами большинства), и инициатива направленная на его итоговое "увольнение" исходит от них. Попытаться выяснить причину если таковая есть. Если её нет, то, вероятнее всего, это все-таки софт-скиллс проблемника и он действительно отравляет коллектив. Потому что я бы например не отказался от коллеги, который делает работу так же быстро как я, так же качественно как я, и при этом мне с ним работать комфортно.
Вывод: кроме потенциального случая, что это большинство его "подтравливает", нужно просто опеределить насколько соответствуют софт-скиллс проблемника, компании. Если он отравляет работу коллектива и потенциально угрожает стать спусовым крючком для других инженеров, я бы уволил без колебаний.
При этом, при принятии решения, я бы держал в голове, достаточно вероятную и часто встречающуюся, обратную ситуацию: вы нанимаете вместо проблемника "рубаху-парня — душу коллектива и звезду компании", который выполняет таски за двоих, и в сжатые сроки, отвечает на любые звонки, но при этом быть готовым переделывать его веселый код, или тратить объемы времени, соизмеримые с временем, на которое отставал тот самый проблемник.

Total votes 5: ↑5 and ↓0+5
Изменить его софт-скиллс вы вряд ли сможете.
Откуда такая уверенность?
This comment wasn’t rated yet0
Мне показалось вы уверены в том, что «Изменить его софт-скиллс вы вряд ли сможете».
Хорошо, перефразирую: почему вы так считаете?
This comment wasn’t rated yet0

Попробую объяснить мою личную точку зрения и ответить: на мой личный взгляд, софт-скиллс зависят в разной степени от характера, воспитания, жизненных сложившихся обстоятельств (семья, дети, тяжелые ситуации, психологические проблемы или отклонения(аутизм например) и тп).
При всем уважении, я не уверен, что вы как сторонний человек (коллега или руководитель как автор статьи), сможете изменить характер и воспитание, хотя бы в силу времени и социального статуса по отношения к субъекту. У взрослого сформировавшегося человека, мне кажется поздновато менять характер, а базовые ценности, воспитание закладывают все-таки родители/опекуны.
Сложившиеся жизненные обстоятельства (отношения с женой, количество детей и их возраст(грудные дети, недосып и тд), семейные проблемы, и тп) мне тоже видится странным вмешиваться или менять.
Может и сможете, я не знаю ваших способностей, но лично мне это показалось бы странным, и думаю выглядело бы это тоже странным. Условно и теоретически увеличить количество детей в чужой семье вы можете, но боюсь это неизбежно повлияет на другие аспекты софт-скиллс субъекта.
Ну и если отбросить все вышесказанное, с чем вы можете не согласиться, по причине того, что это каким-либо образом связано или влияет на софт-скиллс например, то мне кажется странным менять человека и его софт-скиллс, людям (руководителю и коллегам), которые в представленной статье/ситуации, изначально называют его "проблемником", относятся к нему, не говоря ему все в лицо(?) и прямо(?) (за его спиной?), и относятся к нему с недоверием(?) и непониманием/неприятием/антипатией(?) — вопросы означают что я подвергаю это сомнению и возможно это не так по всем пунктам.
Проще говоря если человек вам не нравится, и если вы уже настроены к нему в неком негативном свете, то выглядит довольно странным пытаться его изменить именно вам. А в данной статье вроде бы отсутствует описание хотя бы одного лица, которое его открыто поддерживает и симпатизирует.

Total votes 1: ↑1 and ↓0+1
Так понравился ответ, что повысил Вам карму :)

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

Меня всегда поражает, почему у нас чуть что — сразу уволить. Ведь во многих случаях достаточно просто по-хорошему поговорить. В конце концов все мы люди, у каждого свои недостатки. А человеку, как известно, свойственно ошибаться.
Кстати, на тему ошибок есть давняя, но поразительно мудрая и поучительная история:
Однажды у руководителя IBM спросили, собирается ли он уволить сотрудника, из-за ошибки которого компания потеряла 500 тысяч долларов? Руководитель ответил: «Нет. Потому что я только что вложил в его обучение полмиллиона долларов».
Total votes 1: ↑1 and ↓0+1

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


Для меня просто странно выглядит ситуация, в которой перевоспитывать человека будут люди, которого в статье описывают эпитетом "проблемник", и за глаза весь коллектив недолюбливает. Поэтому я думаю, что спасать то возможно надо не компанию и руководителя, что в "увольнении"(разрыве ТО) "проблемника", возможно кроется его спасение. То есть потенциально это сохранит, как его здоровье, так и коллектива. Пойдет на пользу обеим сторонам.
Но мы рассуждаем, и не знаем всей ситуации, мнения обеих сторон, знает ли об этом "проблемник", "проблемник" ли он на самом деле или нет, и даже если да, то для "кого" он проблемник? Я упоминал в предыдущем ответе что не исключена ситуация в которой какой-то "Альфа" сотрудник просто настраивает коллектив, умышленно или нет.


Мне понравился выход еще из ситуации довольно простой. Что если он работает медленно, то премировать остальных коллег, а его нет. Рано или поздно "проблемник" либо сам задаст вопрос, почему остальным премия а ему нет, либо руководителю самому придется это объяснить.


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


P.S. получается руководитель IBM вложил в него 1 миллион? ). Ну то есть компания потеряла 500к + он вложил в его обучение еще 500к ).

This comment wasn’t rated yet0
Как всегда все всё усложняют до ужаса.

Вы ведь руководитель? Так?
А сотрудник — это Ваш ресурс. Который достаточно сложно восполняем с текущим качеством кадров на рынке. А Вы должны грамотно распоряжаться своими ресурсами — должность обязывает.

По-этому все очень просто.

У вас должны быть отношения, как в магазине при рыночной экономике — nothing personal.

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

Если сотрудник вам не полезен и вы имеете возможность распределить его задачи по коллективу — расстаетесь, причем — по хорошему. Не имеете — гото п.1 и ищете замену.
Потому что Вы должны понимать, к чему приведет его увольнение здесь и сейчас.

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

Как-то так.

P.S. Поверьте — с современными кадрами ваш «плохой сотрудник» очень даже ничего.
P.P.S. А может быть дело вообще не нем — но там уже психология начинает играть и коллектив — тема сложная и длинная — хотите поговорить — можно в личку, чтобы трэд не захламлять.
Total votes 19: ↑18 and ↓1+17
Другие инженеры избегают совместных задач с «проблемным» разработчиком. Объясняют это тем, что при возникновении спорных моментов в реализации фичи «проблемный» инженер спорит до посинения и не слышит аргументов других разработчиков. В конце концов всё равно делает по-своему, и это (иногда) приходится переделывать на code review. Каждый раз это скандал и трагедия. А если переделывать не приходится (то есть решение верное), это выливается в нетолерантную тираду «а я же говорил».

Ээээ, вот этот пункт совсем странный. Т.е. _приходится переделывать_? Он у вас необучаемый что ли? Ошибка, совершенная дважды — глупость. Или команда не справляется с тем, чтобы объяснить свои решения (и тогда я бы человека просто попробовал в другую команду), или человек просто не умеет объяснить почему он так делает, такие вещи разбирают на ретро обычно.
Total votes 2: ↑2 and ↓0+2

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

Total votes 1: ↑1 and ↓0+1
Ну, «приходится переделывать на code review» я понял как переделывать прям сразу, перед заливкой в общую ветку например.
И это звучит прям адово плохо.
Total votes 1: ↑1 and ↓0+1
На скрам похоже мало, много базовых несостыковок. Разве что заимствование терминологии.
Бонусная проблема: руководитель прошляпил «проблемного разработчика».

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

Варианты:
1. Перевести с понижением зарплаты, возможно в другой команде другой руководитель сможет встроить его лучше.
Риск: разработчик обидится и станет еще токсичнее.
Бонус: уволится сам.
2. Предложить уйти по собственному, разъяснив, что платить текущую зарплату вы больше не будете.
Total votes 3: ↑0 and ↓3-3
Лично я и на 1 и на 2 предложение начну искать новую работу. И уволюсь сразу как такая найдётся, вряд ли это то, что нужно руководителю.
Total votes 1: ↑1 and ↓0+1
Однозначно искать замену. Командная работа — это командная работа. Тем более, что и индивидуальным мастерством «проблемнику» похвастаться не получается. По человечески мне его жаль. Сам такой. Местами. Позиция «работать, чтоб жить, а не жить чтоб работать» в долгосрочной перспективе совершенно правильная. Но… Иногда от нее просто необходимо отступить. Отстаивать свою точку зрения и выдавать гору сарказма — да можно. И даже нужно. Но для этого надо быть (неформальным) лидером команды. Чтоб тебя считали «токсиком», но всегда ждали твоей оценки ситуации (ибо она чаще всего оказывается правильной). Но этого нет. В итоге мы имеем непроизводительную рабочую единицу. И ее просто надо заменить. От этого выиграет проект и команда. Да и сам сотрудник. Иногда, чтоб научить плавать надо выкинуть из комфортной лодки.
Но… Ох уж это но… Есть определенный набор условий при которых именно такое поведение самое правильное. Однако, по факту этот набор условий просто обязан привести к тому, что «проблемник» сам уйдет. Потому все же готовить замену. А дальше… Либо уйдет сам, либо убирать административно.
This comment wasn’t rated yet0
Не очень понял, в чём конкретно проблема. «Не вовлечен в атмосферу команды и не живет ее культурой»? Это где-то в должностных обязанностях прописано, что сотрудник обязан?

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

Код пишет медленнее других — но насколько я понял, в требуемые сроки укладывается (т. к. о какой-то проблеме в этом отношении заговорили только после визита PO, а до этого с точки зрения руководителя команды никаких проблем не было).

Не работает сверхурочно — а это прописано в должностных обязанностях и компенсируется соответственно?

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

На мой взгляд, в этой постановке это выглядит как попытка компании выжать из сотрудников бОльшую производительность, чем от них требовалось «на входе», на этапе найма. Кто-то из разработчиков на личном топливе готов больше времени работе уделять — ну так это его личное решение. Крайне сомнительно, что на том основании, что у некоторых разработчиков, скажем, нет семьи и они могут больше времени уделять работе, можно требовать такого же подхода и у других сотрудников компании.
Total votes 16: ↑16 and ↓0+16
Это ответ программиста, а не руководителя. :)
Total votes 4: ↑1 and ↓3-2
Это ответ программиста руководителю. Что проблема возможно не там и не такая, как ему кажется.
Total votes 8: ↑8 and ↓0+8
Так может рассуждать либо совсем джун, либо сотрудник концентрационной галеры типа CBOSS.

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

Другое дело, если в ней постоянно что-то горит. В таком случае команде надо задавать вопросы капитану. :-)
Total votes 5: ↑0 and ↓5-5
и очень странно отмахиваться «не моя вахта, ебитесь сами», если случился пожар.

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

This comment wasn’t rated yet0
Код пишет медленнее других — но насколько я понял, в требуемые сроки укладывается (т. к. о какой-то проблеме в этом отношении заговорили только после визита PO, а до этого с точки зрения руководителя команды никаких проблем не было).


«Требуемые сроки» — понятие искусственное, под конкретную ситуации и под конкретных людей натянутое.

Всё упирается только в сравнение с другими.
И в возможность замены.

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

Если можно заменить сотрудника на другого, более эффективного — можно говорить, что старый «работал слишком медленно».
This comment wasn’t rated yet0
«Проблемный» инженер активно участвует во всех коллективных мероприятиях и обсуждениях внутри компании, в том числе и в тех, которые не относятся к предметной области команды. Это всевозможные публичные демонстрации других продуктов, обсуждение архитектурных и DevOps-вопросов, активности по созданию единого UI-набора (не задача этой команды) и т. д. По сути, высказывает свое мнение по любому вопросу, даже если вопрос не касается ни стека, ни задач команды. С другой стороны, он помогает развитию коллективных проектов компании.


Этот пункт интересен. Допустим, человек работает на 80% от нормы, но помогает развитию неких других проектов. А как оценить это в процентах?
Интересно получается. В команде он чем-то не устраивает, но в целом компании дает большие плюсы, судя по всему.
Уволить, чтобы улучшить работу команды, но ухудшить работу компании в целом?
Total votes 5: ↑5 and ↓0+5
Я бы сформировал вокруг человека соответствующее командное отношение. Т.е. дал бы понять команде, что перед нами негативный пример (с точки зрения моего видения команды как её руководителя), самому товарищу, естественно, так же — что в нашей команде подобный подход является недопустимым (при этом дав понять, что всё поправимо). Есть много способов сделать вышеозначенное — от стиля общения до материальных поощрений.
Далее бы уже решала личная мотивация сотрудника. Если уволится — значит, уволится. Если качество провалится ниже — значит сами уволим. Исправится или впишется в некий другой круг обязанностей, где его сильные качества проявятся лучше — замечательно.
This comment wasn’t rated yet0

Тоже вставлю 5 копеек. Оговорюсь, я много лет руководил командами, в том числе и большими, человек до 200+. Но это была работа, не связанная с IT. Потом я решил, что мне надоело и обучился на разработчика, и им и работаю, но не руковожу никем. По крайней мере пока. Если консолидировать мой опыт, то могу сказать следующее:
Некоторые моменты из исходных данных не совсем ясны, конечно. Но я бы делал так. В первую очередь, я бы ввел в группу или в группу некие понятные измеримые критерии производительности. Хотя бы примерные. Да, с разрабами это труднее, но вы же как-то определили, что проблемный сотрудник работает с меньшей производительностью. Эти ориентиры должны знать все сотрудники. Далее, если проблемный действительно недорабатывает, то, я бы поговорил с ним по этому поводу, объяснил, что ожидаю от него соответствующей производительности. Возможно, предложил бы некоторую помощь по улучшению скиллов. Если делает, то ок. Если нет, то есть варианты. Если сотрудник не хочет нормально работать, да заменить его не проблема, то уволить. Если хочет действительно, но что-то не получается, то помочь обучиться, если нет, то возможно перевести его на другую должность, где будет полезен, если тоже не вариант, можно сделать сдельную ЗП и платить меньше, раз уж не работает, если тоже не катит, то уволить.
Насчёт переработок и прочих развлечений, не думаю, что надо кого-то принуждать. Считаю, что логично ввести за это понятные вознаграждения и предложить всем такую систему. Желающие будут — значит норм. Не будут, значит мотивация не достаточная. А принуждать это такое.

Total votes 3: ↑3 and ↓0+3
>Да, с разрабами это труднее, но вы же как-то определили, что проблемный сотрудник работает с меньшей производительностью.
Ну, тут есть подводные камни. Мне как-то предъявляли подобные претензии, но при этом полностью забыли, скажем, что пару месяцев назад была задача, которую дали начинающему разработчику, он ее месяц возил туда сюда, и ничего пригодного не сделал. А когда взялся я — то нашел и внедрил готовое решение за пару дней. И на нем все уже пару месяцев сидят. То есть, я сэкономил команде кучу времени, а если бы тут задачу дали мне — то две кучи бы сэкономил. Но вы попробуйте это доказать в случае конфликта в команде.
Total votes 2: ↑2 and ↓0+2
Но вы попробуйте это доказать в случае конфликта в команде.


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

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

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

Исключения конечно бывают.
Но в нормальном коллективе с нормальным руководителем всё равно видно.
А в ненормальном и с ненормальным — зачем работать.
This comment wasn’t rated yet0
>А в результате длительного наблюдения.
Ну, как бы это выразиться. Если в результате длительного наблюдения было замечено что-то (как в моем случае — когда ссылались на проект давностью полгода), и при этом никто ни слова не сказал тогда — вам не кажется, что это болтовня, а не наблюдение?

А так в целом скорее согласен со всем изложенным.
This comment wasn’t rated yet0
Ну, как бы это выразиться. Если в результате длительного наблюдения было замечено что-то (как в моем случае — когда ссылались на проект давностью полгода), и при этом никто ни слова не сказал тогда — вам не кажется, что это болтовня, а не наблюдение?


Руководство — не боги.
Они такие же люди.
У них и занятость есть.
И время нужно им чтобы принять решение.

Более того, при наличие должного объема наблюдений никто вам и не будет говорить те глупости — об этом и был мой пример.
This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
Если вы хотите винтик в команде, кругозор которого ограничен текущим дэшбордом в жире, а из общественного максимум командными дэйли и ретроспективами — расставайтесь, конечно.

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

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

Если его участие действительно конструктивно, а не «в каждой бочке затычка» и не трёп в #random, и при этом просадка по времени выполнения задач не более 20-30% — я бы крепко подумал, стоит ли доставать кнут.

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

Отдельный вопрос о токсичности, из-за чего человека сторонятся — но об этом уже много здесь расписали.
Total votes 4: ↑4 and ↓0+4

Поражаюсь желанию менеджера иметь вместо людей в подчинении сферических разработчиков в вакууме. Прям вася петя валя тратят 3 часа 20 минут на задачу а егор 6 часов 40 минут? Ну что за бред? Люди разные, задачи разные, подходы разные, этож не макдональдс бургер жарить 2 минуты с каждой стороны, хотя если макдональдс то да.

Total votes 3: ↑2 and ↓1+1
Слишком округлое описание, задачка про команду требует наличия полутонов в описании. А у вас только цифры.

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

Основная цель — если команда ответит ДА, значит он уже не нужен, его уже надо выводить из команды.
Второстепенная цель:
если команда ответит НЕТ — до проблемного товарища дойдет информация о серьезности ситуации. Получив такую информацию он примет своё решение, будет он сотрудничать с руководством, или нет. Через некоторое время его нужно об этом прямо спросить. Если будет сотрудничать, то можно дальше решать управленческую задачу о подборе критериев и способов мотивации.
Total votes 1: ↑1 and ↓0+1
Любопытно, что по комментариям сразу видно у кого есть опыт руководства, а кто советует только с позиции исполнителя. Прошу прощения за лёгкий оффтоп.

Total votes 4: ↑2 and ↓20

Хорошо видно тех, кто будучи руководителем, в целях экономии собственных ментальных ресурсов превратил подчиненных в картонные фигурки.

Total votes 4: ↑4 and ↓0+4
Не вижу вашего предложения, как решать проблему. Что предлагаете?
Total votes 3: ↑0 and ↓3-3

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

Total votes 3: ↑3 and ↓0+3
Проблема в том, что — шесть человек говорят что с седьмым некомфортно работать в команде.
Total votes 3: ↑0 and ↓3-3
Если вы считаете это личными проблемами, я считаю что это проблемы команды.
Leeching тоже поощрять плохо.
Total votes 1: ↑1 and ↓0+1
Следует это обсудить непосредственно с сотрудником, для начала. А не выставлять на обсуждение *анонимов* на хабре
This comment wasn’t rated yet0
Топик-стартер указал что уже побеседовал с «прекрасным» инженером, его точка зрения следующая:

-он комфортно себя чувствует в команде
-не замечал, что с ним не хотят делать совместные фичи
-Проблему со своей продуктивностью видит и признаёт
-Не может ее объяснить
This comment wasn’t rated yet0
Следует это обсудить непосредственно с сотрудником, для начала. А не выставлять на обсуждение *анонимов* на хабре


Так ведь и сотрудник анонимен. Так почему нет? Это же такое психологическое упражнение для нас.

Да и, полагаю, сотрудник гипотетический и вся ситуация с ним выдумана только для статьи.
This comment wasn’t rated yet0

Какие метрики для оценки сложности вклада в код вы используете?
Число строк?

Total votes 2: ↑2 and ↓0+2
Не ясно как работает оценка скорости выполнения задач сотрудником. Необходимо проверить корректность измерений.

То что разработчик не может объяснить снижение продуктивности, и более того никто вокруг не знает причин — не круто. Нужно разбираться в деталях.
Total votes 2: ↑2 and ↓0+2
поклонники аджайла потихоньку начинают догадываться про KPI и деньги. ;)
Более продуктивных надо просто больше премировать и оплачивать переработки.
ВСЕ.
Total votes 1: ↑1 and ↓0+1

Расизм называть в этой ситуации инженера проблемным. Это вся команда проблемная) а инженеру надо искать другую работу, раз за спиной его "проблемным" обзывают. Плюс в команде нормально перерабатывать (как я понял по прямым намекам на то, что "проблемный" не перерабатывает и ценит свое личное время) — это не проблема? В общем я за то, чтобы уволить менеджера, ну то есть того, кто в этой статье руководитель разработки.

Total votes 10: ↑7 and ↓3+4
Расизм не зная причины увольнять автора статьи. В общем я за то, чтобы принять вас на работу в эту компанию и сразу уволить за принятие решения без выявления должных симптомов с формулировкой «За скоропалительность»
Total votes 1: ↑1 and ↓0+1
Расизм называть в этой ситуации инженера проблемным.

Проблемный != «Проблемный».

А в статье он назван именно как «проблемный», а не проблемным.

«Проблемный» это просто label, метка, тег — просто чтобы как-то обозначить этого сотрудника. Можно было обозначить его как мистер Х, суть осталась бы та же — это просто обозначение, чтобы как-то можно было на него ссылаться.

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

Total votes 1: ↑1 and ↓0+1

"Негр" — это просто метка, чтобы как-то отличать человека с темной кожей от человека со светлой кожей.


Лучше бы было X, чем "проблемный", ведь там есть слово с заранее негативным контекстом, что меня бы, к примеру, могло оскорбить) да, суть я понял, вы тоже по своему правы, но все ж таки, чтобы статья казалась более объективной, стоило использовать другие метки.

This comment wasn’t rated yet0
Лучше бы было X, чем «проблемный», ведь там есть слово с заранее негативным контекстом

Э…

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

А «негр» — это слово обозначающее «как бы негр по какому-то признаку».

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

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

Total votes 2: ↑1 and ↓10
человек не на своём месте. Надо двигать вбок
This comment wasn’t rated yet0
У нас в компании был очень похожий случай.
Проблемного сотрудника сначала перевели в другую команду, там история повторилась. После этого ему дали отдельный мини-проект, в котором у него были в подчинении outsource… проект затянулся на месяцы и окончательно убедившись что толка не будет, его сократили. 

На принятие правильного решения влияет не только сотрудник, но и сложность его замены. Если компании тяжело и дорого найти новго сотрудника, стоит попробовать все варианты.
Total votes 1: ↑1 and ↓0+1

Он моложе остальных или примерно одного возраста?

This comment wasn’t rated yet0
По-хорошему, возраст сотрудника не должен влиять на решения руководителя.

Но есть подозрение, что этот «прекрасный» инженер немного старше остальной команды.
Total votes 2: ↑2 and ↓0+2
На мой взгляд тут проблема тут всего одна — с сотрудником не хотят работать остальные коллеги. Всё остальное проблемой не является.

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

Про работу вне рабочего времени. Я, если честно, не могу корректно сформулировать свои мысли в обезличенной форме, поэтому скажу про себя лично. Дело тут не в лояльности и не в «все в одной лодке». Как бы сильно мне ни нравилась моя работа, как бы сильно я ни переживал за продукт, как бы сильно я ни любил команду, себя я люблю больше. И я действительно, как и «проблемный» разработчик автора, работаю, чтобы жить, а не живу чтобы работать. Во времена до ограничений и удаленки я тратил на работу половину каждого рабочего дня (8 часов + час на обед + полтора часа на дорогу в одну сторону). ПОЛОВИНУ, КАРЛ! Да, я не работал в дороге или за обедом, но не будь работы, вряд ли я просто так 3 часа катался бы на электричке и метро. И о какой вообще «нелояльности» может идти речь?! И я не хотел работать не просто из принципа, а потому что во внерабочее время я редко находился у компьютера. И давайте начистоту: если простой в 16 часов для бизнеса действительно фатален, то он наймет дежурных на время, когда основная команда не работает. А если бизнес не готов тратить деньги на такой резерв, то значит это не настолько критично и я не понимаю, почему я должен быть готов тратить своё время. При этом я нормально отвечаю коллегам во внерабочее время, и даже пару раз фиксил баги, но только в том случае, если не был занят другими делами.

На этом мой комментарий мог закончится, но у Вас есть пункт, который единственно(на мой скромный взгляд) имеет значение. С «проблемным» не хочет работать команда. Вне зависимости от того, хороший ли «проблемный» разработчик или нет, прав ли он или нет,
Д'Артаньян он или *******, Вы должны сделать одно: решить кто для бизнеса ценнее. Если этот конкретный разработчик, то разогнать команду. Если команда — уволить разработчика.

Я бы на Вашем месте уволил бы разработчика по соглашению сторон с выплатой двух окладов. Считаю, что в ситуации, когда он действительно не нарушает явно никаких правил, но при этом он не устраивает тех людей, с которыми он работает, это самый честный вариант.
Total votes 6: ↑6 and ↓0+6
Честно говоря, я не вижу проблемы. Если человек работает медленнее других — то его зарплата д.б. ниже адекватно скорости.
Например, у меня есть два грузчика. Все таскают по три ящика за раз, а один — по два. Конечно, можно выяснять, почему он так: физически не может или ленится; но проще — платить ему в полтора раза меньше, чем остальным. Так и с программистами.

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

Другой вопрос — не промахнуться бы при этом с оценками. А то может оказаться, что заменить этого проблемного инженера окажется сложно и/или дорого.

Ещё я не понял про «публичные активности». Возможно, это дело следует пресечь.
Total votes 2: ↑1 and ↓10
Другим грузчикам дают премию за внеурочную порчу позвоночников, а этот хочет быть здоровым пенсионером
Total votes 2: ↑1 and ↓10
Вообще, команда — это часовой механизм. Каждый в ней шестеренка разного размера с разным количеством зубьев и каждая шестеренка по разному взаимодействует с соседней. А по описанию, команда похожа на поршни ДВС, все хотят чтобы у них мотор ревел и все неслись в светлое будущее, но если не видно шестеренок, значит что-то упущено.

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

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

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

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

Такое поведение у человека не в один день проявилось, просто все молчали, пока не надоело. А как надоело начали придумывать отмазки типа работает медленнее, не как все и т.п.
Total votes 2: ↑1 and ↓10
1. Переработки. Это не проблема, от него нельзя этого требовать, как бы этого не хотелось менеджеру.
2. Движухи в компании вне команды. Тут похоже наш разработчик молодец.
3. Производительность. Автор и ВП решили, что именно это главная проблема. Либо вводить KPI для всех (ага-ага, как же, KPI для программистов), либо перевести этого одного на сдельную оплату, либо выравнивать ЗП через премирование остальных, либо увольнять.
4. Токсичность. Неприятно. Оценивать величину проблемы сложно по тексту. Если акцент в тексте был на производительности, то видимо все не так плохо и остальные разработчики прокачают стрессоустойчивость. Либо разводить их по разным задачам. Если проблема серьезная — увольнять конечно же.

Мини-проект — сразу нет. Если вам так жаль денег на том, что вы теряете из-за «недоработки» программиста, то проект будет с большими рисками.
Увольнение — отличный вариант. Вы решите проблему, разработчик найдет новую работу с зарплатой побольше и всё у всех будет хорошо. Но есть риски: 1) замена будет стоить денег (всю экономику сами уже поди посчитали); 2) новый разработчик возможно будет не лучше; 3) всегда будет один самый слабый разработчик.
Контроль сроков — сомнительно. Лишние усилия и проблема с этим разработчиком будет висеть и постоянно о себе напоминать и менеджеру, и ВП.
Оставить как есть — нормальный вариант. Может вся эта движуха из пальца высосана и «производительность» меньше на 10%, а разработчик — славный малый и остальные друг с другом тоже срутся.
Также поддерживаю мнение, что ВП тут не при чем, а решение может принять команда.
This comment wasn’t rated yet0
UFO just landed and posted this here

А он-то умеет работать в команде, это другие избегают его )

This comment wasn’t rated yet0
UFO just landed and posted this here
Дать ему отдельный мини-проект.
Чисто из моего опыта, — работал в 2013 году с персонажем не проявлявшем особых трудов и способностей в нашей команде сопровожденцев. В основном тематику вытягивали я и ещё пара товарищей.
со временем руководство перевело его в отдельную группу где все было совсем грустно и печально. Персонаж был привычен к тому что дела всегда делались в срок, и оказался довольно таки внимательным товарищем, усвоил все наиболее эффективные методы используемые в нашей группе. Уже через полгода вытянул свою новую команду из болота ударным трудом, прокачал ответственность и управленческие способности. Пошел на повышение.
This comment wasn’t rated yet0
По описанию проблемы разработчик обладает достаточной квалификацией, но на проекте откровенно заскучал. Проектные задачи неинтересны, пытается сам найти что-то для себя — способ реализации, инфраструктурные задачи, обсуждения других проектов…
Если хочется сохранить (высокая квалификация, много полезного сделал раньше..), надо обсуждать какие задачи ему были бы интересны и попытаться перевести в другую команду. Ну или искать замену.
Total votes 1: ↑1 and ↓0+1
А по факту единственная проблема — скорость решения задач, и даже это не проблема, если дедлайны не срываются (про это ничего не сказано). Все остальное вполне рабочие моменты, плюс несколько противоречивых утверждений. То есть сказать, что работник конкретно косячит в чем-то нельзя. Про свои отношения с командой и опыт руководителя автор при этом скромно умалчивает. Может проблема в том, что автор хочет видеть слишком послушного винтика (с периодическими переработками) в команде, а тот никак не поддается, но увольняться сам при этом не хочет из-за каких-то более позитивных для него самого факторов? Или там не очень с организацией, а человек не хочет выполнять роль «тяни-толкая» при живом руководителе? Или он вообще единственный, кто пытается хоть как-то нетривиально задачи решать? Тема не раскрыта, вопросов к руководителю больше, чем к работнику.
This comment wasn’t rated yet0
Руководитель (или его предшественник) попытался сотворить чудо и собрать плоскую команду в 7 человек, где все должны перформить «одинаково хорошо».
Получив ожидаемый результат он теперь ищет способы пофиксить неудавшееся чудо… и со временем снова получит ожидаемый результат.

Хинт: творить это чудо дано почти никому. Лучший успешный пример наверное Рэй Далио со своим мануалом для сотрудников на 600 страниц.
Только перед принятием на вооружение ознакомьтесь с текучкой IT (и не только) кадров в его Bridgewater Assocs. и решайте потянете вы это или нет.
Все ФААНГ-и уже давно сдались.
This comment wasn’t rated yet0
В случае продуктовой компании мотивируют опционами. На аутсорсе попу рвут только джуны и сектанты. Если производительность всегда была неуд, то тут вряд ли что-то поможет. Разве что выделять мит раз за спринт и при всей команде обсуждать велосити каждого. Если за 2-3 спринта ничего не меняется — предупреждение, если после предупреждения то ж самое — досвидули. Если велосити было норм но упало, возможно стоит сменить команду/проект, или отправить в отпуск
This comment wasn’t rated yet0
В случае продуктовой компании мотивируют опционами.


То есть сотрудник приносит меньше пользы фирме, чем его коллеги за ту же зарплату.
И вы предлагаете этому сотруднику еще и опционов добавить?
Просто потому, что, возможно, он станет работать лучше.
Ну а чё, логично.
А если не станет лучше работать — отобрать опционы?

P.S.:
Цели опционов не те, что вы думаете. Не чтобы получше работали. Цели опционов — подольше удерживать сотрудников. Ценных сотрудников подольше удерживать.
В данном конкретном описанном в статье случае — этого не требуется.
This comment wasn’t rated yet0
Так-то оно так, вот только зачем в таком случае ожидаются «жертвы личным временем ради решения задач команды»? Работа на результат предполагает соответствующую мотивацию.
This comment wasn’t rated yet0
>И вы предлагаете этому сотруднику еще и опционов добавить?
Почему этому? Добавить остальным, если выяснится, что они работают лучше. Если разница реально имеет место — значит кого-то переоценили, а кого-то наоборот. Выровнять зарплату и производительность — как раз самое нормальное решение. Даже если этому человеку пофиг — остальным скорее всего нет.
This comment wasn’t rated yet0
Почему этому? Добавить остальным, если выяснится, что они работают лучше. Если разница реально имеет место — значит кого-то переоценили, а кого-то наоборот. Выровнять зарплату и производительность — как раз самое нормальное решение. Даже если этому человеку пофиг — остальным скорее всего нет.


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

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

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

Не рассчитывайте на сколько-нибудь существенные опционы, если вы работаете в зрелой фирме на рядовых ролях.
This comment wasn’t rated yet0
>Долю вам дают
Не, смотрите, вопрос же можно поставить не так. Если внутри команды есть разница в производительности (измеренная, а не кажущаяся) — значит доходы должны ей соответствовать. А уж как этого добиваться, опционами там, зарплатой, премиями или еще чем-то — это уже вторично. И кого стимулировать — того кто плохо работает, снижая премии, или тех кто хорошо — тоже в общем вопрос отдельный, и да, зависит от того, на какой стадии компания, и от многого другого.
This comment wasn’t rated yet0
Не, смотрите, вопрос же можно поставить не так. Если внутри команды есть разница в производительности (измеренная, а не кажущаяся) — значит доходы должны ей соответствовать. А уж как этого добиваться, опционами там, зарплатой, премиями или еще чем-то — это уже вторично. И кого стимулировать — того кто плохо работает, снижая премии, или тех кто хорошо — тоже в общем вопрос отдельный, и да, зависит от того, на какой стадии компания, и от многого другого.


Проблема заключается только в оценке.
И в её понятности-прозрачности для сотрудников.

Как сделать оценку?

Вот уже когда оценка есть — стимуляция/наказание это чисто арифметический момент сколько там давать шпицрутенов или рублей…
This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
Имхо, вы вкладываете в проблему слишком много эмоциональных посылов. Зря это.
Все же просто: если человек токсичен — нужно коллектив от него ограждать, однозначно.
Если ограждать по-лайтовому — то мини-проект и по результатам принимать решение. Основной критерий, является ли человек для компании прибыльным.
Короче, вывести проблему из психолого-социальной плоскости в плоскость чисто экономическую. И в ней уже спокойно все посчитать.
Total votes 1: ↑1 and ↓0+1
Однажды к вам приходит Владелец продукта и сообщает, что недоволен продуктивностью одного из инженеров. Якобы он делает меньше задач, и аналогичные по сложности доработки другие инженеры выполняют быстрее (в той же кодовой базе).

Разве это компетенция РО — оценивать продуктивность членов команды? Ему какое до этого дело? Он задачи ставит команде а не каждому отдельному инженеру. Такое выражение недовольства — это в первую очередь сомнения в компетенции лида, это сигнал ему что он не справляется со своими обязанностями и является по сути ненужной прокладкой между командой и РО.

И, кстати, то что вы как руководитель проблему с инженером увидели только после пинка РО — это в какой-то мере подтверждает, он заметил ее раньше вас.

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

Все эти оценки скорости — они довольно субъективны, не вникая на все 100% в задачи нельзя точно определить медленно она была сделана или наоборот, быстро, и обычно двух одинаковых задач не бывает, если кончено это не какая-то совсем уж спинномозговая деятельность.

Переработки — он не обязан, ставить человеку минус в карму за то что он не хочет посвящать всего себя проекту — это очень неправильно, на мой взгляд.
Total votes 1: ↑1 and ↓0+1
>> Однажды к вам приходит Владелец продукта и сообщает, что недоволен продуктивностью
>> одного из инженеров. Якобы он делает меньше задач, и аналогичные по сложности
>> доработки другие инженеры выполняют быстрее

По народной легенде, стандартный тест на идиотизм — вопрос: «при авариях на железной дороге по статистке сильнее всего страдают пассажиры последнего вагона. Ваши предложения». Ответ настоящего идиота: «отцепить последний вагон». Правильная реакция руководителя коллектива: порадовать Владельца Продукта этим сообщением и предложить ему Заняться Собственными Делами.
Total votes 2: ↑2 and ↓0+2
У Саймака есть такой рассказ «Дурной пример». Не буду спойлерить, замечательный рассказ. Суть такова — в любой ячейке общества должен быть «дурной пример», тот на кого смотрят и говорят «а мы не такие»
This comment wasn’t rated yet0

Это ведь бизнес, поэтому всё очень просто — посчитать приблизительно убытки от низкой производительности (вы ведь измерение сделали) за год и после взгляда на большую цифру — смело увольняйте. Проще сразу, но можно и мягко — через предложение ему 50% от ставки. Помните, люди не меняются, и даже если он 2-3 месяца будет норм работать, то через полгода всё вернется на то же состояние или даже хуже. Конфликтность сама по себе отравляет команду и служет поводом задуматься об увольнении, а тут ещё и производительность в 2 раза ниже.
P.S. Нелохо бы в конце статьи опрос поставить с вариантами.

This comment wasn’t rated yet0
Помните, люди не меняются
Громкое заявление.
Total votes 1: ↑1 and ↓0+1
ну в какой то части это правда.
Хотя правильнее люди меняются, но не по щелчку пальца. Силы и обстоятельства должны быть очень весомыми для личности меняемого.
This comment wasn’t rated yet0

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


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

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

This comment wasn’t rated yet0
С точки зрения руководителя вы наверное правы.
Я всегда был только со стороны разработчика, для меня всё это звучит дико.

ПС: а ещё «часто» оказывается, что ожидалось «конкретный человек после разговоров и контрольных заданий ведь наверняка знал, что от него хотят», а на деле никто ему ничего не озвучил толком.
This comment wasn’t rated yet0

ИМХО, человек просто левачит на ещё каким-то проектом — ведь в контрольное время с производительностью было всё гуд. Ну, если левачит — то это нечестно к работодателю и однозначно увольнение.

This comment wasn’t rated yet0

Или просто эффективно способен работать только в условиях постоянного контроля.

This comment wasn’t rated yet0
лишь подтверждение общего правила «люди не меняются», ведь конкретный человек после разговоров и контрольных заданий ведь наверняка знал, что от него хотят, но вернулся в режим низкой продуктивности по завершении контроля.


Люди меняются. Но медленно.
И нужен огромный стимул, чтобы изменить себя значительно.

В этом смысле, да, «люди не меняются».

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

Но это все требует усилий.

This comment wasn’t rated yet0
А вообще есть ли проблема? Задачи сдаются в срок? Провалы релизов из-за этого конкретного разработчика были?
Есть страх что другие станут медленнее работать?

Я вижу в этой истории два интересных момента.
1) Нежелание команды особенно взаимодействовать с человеком, в плане его коммитов, и совместной работы.
Может быть звоночком, некоторых проблем внутри команды.
Я бы присмотрелся к взаимоотношениям команды.
Если разработчик занял место парии(отверженного), то особого рвения наверное не стоит ожидать.
2) Деятельность в общественной работе.
Может человек занимается тем, к чему его душа не лежит. И в такой деятельности он получает облегчение.
Попробуйте ради эксперимента, дать задачу что-нибудь организовать. Посмотрите на его поведение, без давления, какая будет производительность.
This comment wasn’t rated yet0
Сам сейчас на новом стеке делаю задачи медленно и чувствую это, но сделать особо ничего не могу работаю больше оговоренного времени что бы задачи сдавались в срок. Я не знаю общей подоплёки но тот фак что команда говорит что не хочет работать с человеком который активно участвует в и ивентах и живо интересуется всем что важно для кампании это весьма плохой звоночек но он скорее про команду а не про человека.

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

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

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

Надеюсь что вы найдёте удачное решение помимо увольнения так как этот инструмент не так часто является взаимовыгодным.
This comment wasn’t rated yet0
Прошу прощения за полуофтопик, но сильно заинтересовало, почему в команде нет тестировщиков:
В состав команды входят:
7 инженеров—разработчиков (допустим, все фуллстеки, чтобы убрать из задачи сложности по непересекающимся стекам);
UI/UX-дизайнер;
системный аналитик;
владелец продукта — ведущий специалист от Бизнеса, который определяет приоритеты доработок и пользу от новых фич.
This comment wasn’t rated yet0

Автотесты + канареечные релизы.

This comment wasn’t rated yet0
Есть решение этой ситуации и оно вполне стандартное и на поверхности:
не давайте «проблемнику» ни одной задачи на протяжении недель трех-четырех. Обязательно скажите команде, что это ваше решение и вы не даете в воспитательных целях, а не потому что он какой-то особенный. Больше ничего не раскрывайте, просто «это мое решение в воспитательных целях» — и загадочно отмалчивайтесь на все вопросы.

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

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

Удачи вам.
Total votes 1: ↑0 and ↓1-1
«Проблемник» первую неделю будет кайфовать, вторую — удивляться, третью либо подойдет к вам сам и начнет разговор что случилось, либо захочет сменить отдел и скажет на какой, или напишет заявление сам.
Если подойдет с желанием остаться — сразу верните всю нагрузку обратно.

Или найдет себе подработки на фриланс и будет спокойно пилить левак в рабочее время — чего париться, з/п и так платят.

ИМХО бред все эти психологические эксперименты. Не нравится как работает сотрудник — прямо и честно ему это сообщите, постарайтесь решить проблему. Проблема не решается — увольняйте.
This comment wasn’t rated yet0
ИМХО бред все эти психологические эксперименты. Не нравится как работает сотрудник — прямо и честно ему это сообщите, постарайтесь решить проблему. Проблема не решается — увольняйте.


Прямо и честно сказать тоже нужно уметь.
Запросто и очень многие впадают в депресняки со снижением производительности труда до 1% от того, что было раньше, если им прямо сказать (безо всякого мата и грубости, а именно прямо-честно).

This comment wasn’t rated yet0
Разумеется нужно уметь, потому руководителями и должны быть по идее люди, которые это умеют делать. А то что описано выше — это похоже на поведение дурной супруги, которая трепет нервы мужу, с помощью всяких намеков и обид, которых тот тупо не понимает, хотя и видит что что-то неладное творится, но добиться прямого ответа от нее не может.
Total votes 1: ↑1 and ↓0+1
Какая-то странная статья, показывающая всю правду о том, что сотрудник почему-то должен переживать за чужой бизнес, в котором он только наемный работник.
  • Оценка личных качеств происходит по продуманному, зафиксированному и подписанному сотрудником процессу в компании или чисто по субъективному мнению «руководителей»?
  • А методика оценки работы сотрудника где-то продумана, зафиксирована и подписана сотрудником, которого оценивают или это «я начальник, я прав»?

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

Прежде чем предъявлять сотруднику претензии их нужно зафиксировать в комании не на уровне «а у нас вот так вот», а на уровне документов, где есть подпись работодателя и сотрудника. Остальное это типичные «я руководитель, я прав».
Всё вышеописанное конечно же ИМХО.
This comment wasn’t rated yet0
Какая-то странная статья, показывающая всю правду о том, что сотрудник почему-то должен переживать за чужой бизнес, в котором он только наемный работник.


Речь вовсе не о переживании.

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

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

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

Если можно купить за 100 единиц денег тех, кто будет работать великолепно, еще и круглые сутки — купят именно таких, а не кого-то ровно такого же по производительности, но за 1000 денег и «с чувством собственного достоинства, которому нужно время на личную жизнь».

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

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

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

А вовсе не о том, что кто-то переживает за бизнес, а кто-то не переживает и кто-то в чем-то виноват.

Бизнес это просто расчет и эффективность.

Эмоции важны в маркетинговой части бизнеса. Но эмоции не нужны для оценки эффективно ли построена работа.

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

Но делается это вовсе не их человеколюбия.
Голый экономический расчет.
И это нормально.

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

Так пойдите навстречу.
This comment wasn’t rated yet0
Лично мне кажется такой человек нужен команде и в чем-то даже полезен. Он не портит общую картину. Отличное от других мнение — это большая польза команде. Это позволяет не только глубже разобраться в вопросе, но и лучше разобраться в своем собственном мнении. Когда все тебе поддакивают, то скорее всего им безразлично твое мнение и в итоге ты не можешь получить реальную оценку своей идеи. Другой вопрос, что над софт скилс надо работать и спорить/общаться доброжелательно и уважительно, независимо от исходов спора.
This comment wasn’t rated yet0
Как бы это больно, дорого и неприятно ни было, нужно распрощаться.

Постоянная напряженность отравляет жизнь всей команде. Скоро с ним откажутся работать или уволятся другие инженеры.


Именно поэтому. Если бы человек хотел меняться, но судя по тому, что изложено в статье, меняться он не хочет и не станет. Он будет гнуть свою линию. В данном случае пусть гнёт её в другом месте. Урон от такого «сотрудника» может быть очень серьезным
This comment wasn’t rated yet0
У меня такой инженер был в этом году, недавно уволился (сам). Просто такому человеку нужна постоянная опека «мамочки», чтобы приносить пользу в длинном проекте, или постоянная дрессировка от «папочки», чтобы быть эффективным в коротком проекте. Можно совмещать по очереди «папочку» и «мамочку».
Другие методы не работают.
Если у руководителя есть время на эти танцы и игра стоит свеч (для проекта), то можно, а если нет, то нет — уволить и забыть.
This comment wasn’t rated yet0
У меня такой инженер был в этом году, недавно уволился (сам). Просто такому человеку нужна постоянная опека «мамочки», чтобы приносить пользу в длинном проекте, или постоянная дрессировка от «папочки», чтобы быть эффективным в коротком проекте. Можно совмещать по очереди «папочку» и «мамочку».
Другие методы не работают.
Если у руководителя есть время на эти танцы и игра стоит свеч (для проекта), то можно, а если нет, то нет — уволить и забыть


Ну строго говоря подобные люди — не редкость.

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

Или не можете это сделать (когда нет на рынке труда достойных альтернатив).

Соответственненно для сотрудника, который понимает что он таков — приходится смиряться или с худшими условиями труда или вытягивать свои скиллы так высоко, чтобы тебя не хотели уволить даже если ты слишком геморойный.
This comment wasn’t rated yet0
Если честно, подобных людей большинство (не только в ИТ), просто обычно (в ИТ) инфантильность проявляется в социализации, а не в профессии. Опыт менеджеров заточен на решение проблем с социализацией — способствование уверенности, вовлеченности и так далее.
Такие ситуации, как в топике, идут в разрез обычной менеджерской практике. И воспринимаются как профессиональный вызов для руководителя, типа «это что то новое, но я разрулю».
Люди редко служают чужие советы, видимо каждый менеджер должен лично пройти по граблям такого опыта.
This comment wasn’t rated yet0
Я правильно понимаю что до обращения Владельца продукта ни о каких конфликтах в команде, ни о каких проседаниях в скорости разработки разработчика автору ничего не было известно?
This comment wasn’t rated yet0
Владелец продукта согласился, что скорость работы «проблемника» в период жесткого контроля выросла. Однако после окончания этого периода продуктивность снова упала.
Это самый интересный пункт. Эксперимент с жёстким контролем показывает что данный работник может работать эффективнее, так почему же не работает?

Либо он халтурит на стороне в рабочее время, либо много времени уделяет посиделкам на кухне/курилке/ютьюбу и тд.

А это уже пахнет дисциплинарными мерами.
This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
Первый вопрос, который я бы задал, как такое может быть чтоб Владелец (С большой буквы!) продукта интересовался производительностью одного конкретного члена вашей команды. Можете объяснить?

И второй вопрос смысл этого опроса? Вы не уверены в своем решении? Хотите его аргументированно подать перед начальством? Разное?
Total votes 1: ↑1 and ↓0+1
Первый вопрос, который я бы задал, как такое может быть чтоб Владелец (С большой буквы!) продукта интересовался производительностью одного конкретного члена вашей команды. Можете объяснить?


В небольших проектах — запросто. Там все люди на виду.

И второй вопрос смысл этого опроса? Вы не уверены в своем решении? Хотите его аргументированно подать перед начальством? Разное?

Он вовсе не советуется с нами.
Имхо, этот «проблемный» из статьи — это гипотетический человек, придуманный конкретно для статьи.
Это такая психологическая задачка нам с вами.
This comment wasn’t rated yet0
Как тут лихо специалистами раскидываются. Для примера, на некоторые позиции в ИТ по статистике нужно провести СОРОК ПЯТЬ phone-screening interviews, чтобы по итогу нанять ОДНОГО человека и выходит на уровень он спустя ПЯТЬ МЕСЯЦЕВ. И подозреваю, что это не самый плохой случай.

Про неурочную работу вообще не понял. Если этого нет в контракте и нет обоюдной договоренности об этом на берегу, то это ваши проблемы — никто не обязан решать их за свой личный счет. Кроме того, у человека могут быть и личные обстоятельства, которые не позволяют этого делать (проблемы в семье, больные родственники и тд).
Total votes 1: ↑1 and ↓0+1
Как тут лихо специалистами раскидываются. Для примера, на некоторые позиции в ИТ по статистике нужно провести СОРОК ПЯТЬ phone-screening interviews, чтобы по итогу нанять ОДНОГО человека и выходит на уровень он спустя ПЯТЬ МЕСЯЦЕВ. И подозреваю, что это не самый плохой случай.


У нас 60.
Личных собеседований на джуна.

Этот джун, то с учетом обучения — окупаться он начинает только спустя полгода. А окупится его обучение еще через полгода (итого год — и вот уже ваш джун приносит чистую прибыль).
This comment wasn’t rated yet0
ИМХО — джуна даже сложнее найти. Если мидла или синьора можно довольно быстро оценить, человек уже реализовался как специалист, то вот понять что получится из «парниши» который мало что умеет и знает — это практически лотерея.
This comment wasn’t rated yet0
Кроме того, у человека могут быть и личные обстоятельства, которые не позволяют этого делать (проблемы в семье, больные родственники и тд).

+ Или он, банально, так удалбывается от работы и дороги туда/обратно, что при мысли о том что нужно еще «немного поработать из дома», ему становится просто фигово.
This comment wasn’t rated yet0

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

This comment wasn’t rated yet0
Сотрудник прежде всего должен выполнять свои прямые рабочие обязанности. Как бы прикольно он не участвовал в коллективных обсуждениях — это просто пыль, если он не может работать в команде. Он же не на должности «прикольный коллективный обсуждатель» у вас работает. На практике, я не раз встречал, что такие прикольные обсуждальщики своим незримым вкладом в коллективные обсуждения, держат впечатлительных руководителей «на крючке», превращая себя в чемодан без ручки. Нельзя дать себя этим отвлечь.

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

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

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

В отдельных случаях можно попытаться перевести человека на другой проект, но, во-первых, в 90% случаях все проблемы, которые есть сейчас, так и останутся (потому что это фундаментальные проблемы психики человека). Во-вторых, если бы это помогло, это решение было бы почти очевидно. Если вопрос встал «увольнять или переводить», скорее всего, ответ вам итак уже известен.
This comment wasn’t rated yet0
Режут глаза пункты про работу в нерабочее время. Почему это считается минусом работника, а не работодателя?

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

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

На текущий момент вывод такой: не вам его нужно увольнять, а ему (как и всем остальным девелоперам) от вас нужно срочно уходить в другую компанию.
This comment wasn’t rated yet0

Это выгодная работодателю (вернее он так считает) деформация, поэтому он с ней не борется. А других девелоперов может всё устраивает и им уходить совсем не хочется — есть плюсы в этой работе, которых в других местах они не найдут, или просто риски не вписаться в новую работу не стоят того, чтобы никогда с 18 до 9 не работать, а если уж работать, то 1,5-2 оплатой.


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

This comment wasn’t rated yet0
Sign up to leave a comment.

Your account

Sections

Information

Services

Support
© 2006–2024, Habr