Казнить нельзя помиловать

    Spoiler

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

    Привет! 

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

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

    Условия эксперимента следующие:

    Вы руководите несколькими командами разработки. Одна из команд (не единственная) состоит из 10 человек, делает классный и востребованный продукт для конечных клиентов. В состав команды входят:

    • 7 инженеров—разработчиков (допустим, все фуллстеки, чтобы убрать из задачи сложности по непересекающимся стекам);

    • UI/UX-дизайнер;

    • системный аналитик;

    • владелец продукта — ведущий специалист от Бизнеса, который определяет приоритеты доработок и пользу от новых фич.

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

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

    Погрузившись в историю коммитов и побеседовав со всеми инженерами команды (в том числе и с тем, по которому «есть вопросы») вы получаете следующую картину:

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

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

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

    4. Другие инженеры избегают совместных задач с «проблемным» разработчиком. Объясняют это тем, что при возникновении спорных моментов в реализации фичи «проблемный» инженер спорит до посинения и не слышит аргументов других разработчиков. В конце концов всё равно делает по-своему, и это (иногда) приходится переделывать на code review. Каждый раз это скандал и трагедия. А если переделывать не приходится (то есть решение верное), это выливается в нетолерантную тираду «а я же говорил».

    5. «Проблемный» инженер активно участвует во всех коллективных мероприятиях и обсуждениях внутри компании, в том числе и в тех, которые не относятся к предметной области команды. Это всевозможные публичные демонстрации других продуктов, обсуждение архитектурных и DevOps-вопросов, активности по созданию единого UI-набора (не задача этой команды) и т. д. По сути, высказывает свое мнение по любому вопросу, даже если вопрос не касается ни стека, ни задач команды. С другой стороны, он помогает развитию коллективных проектов компании.

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

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

    Вы также побеседовали с самим «проблемным» инженером, его точка зрения следующая:

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

    2. Проблему со своей продуктивностью видит и признаёт, но не может ее объяснить.

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

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

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

    Итак, дамы и господа, что бы вы сделали? Учитывайте и моральную, и практическую сторону вопроса.

    Уволить проблемного инженера

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

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

    • Самому «проблемному» инженеру не видать повышения. Он тратит свою время попусту и не растет в профессиональном плане.

    Оставить всё как есть

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

    • Может, ему и не нужно повышение. Он сам же выразился, «работает, чтобы жить».

    Дать ему отдельный мини-проект (даже с вакансиями, чтобы набирал команду под себя)

    • Возможность вырасти в плане менеджмента и архитектурного проектирования. Может, начнет по-другому относится к задачам?

    • А как ему доверить проект? Он задачки-то не вовремя делает: чувства ответственности практически нет. Хотя, может, ответственность перед другими разработчиками (которых он же и набирал) заставит его по-другому относиться к работе?

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

    Организовать постоянный контроль за сроками для этого разработчика

    • Отвлечение ваших ресурсов на одного разработчика. Будете проседать по другим задачам.

    • И с чего бы это такое особое отношение? Другие инженеры сразу заметят такой жестокий микроконтроль, и как отреагируют — неизвестно.

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

    Ваше мнение?

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

    Если возникнут еще какие-то варианты, напишите их в комментарии.

    ДомКлик
    Место силы

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

      –15

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

        +22
        Касательно «жертв личного времени» — если они регулярно нужны, то что-то не так с командой и менеджментом. Никто не обязан им жертвовать.

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

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


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


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


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


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


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


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

              –1
              Такой сотрудник создает плохой пример остальным. И то что прокатывает у одного, потом будет и у других.
            +3
            мне ближе — дать ему мини-проект. а в идеале — дать ему возможность сменить сферу деятельности. может он выгорел и смена рода деятельности в рамках команды/проекта даст ему новый толчок.
              +2
              Сотрудника все устраивает. «Дать сменить сферу деятельности» — это уволить?
                0
                Может, ему пора в «бизнес», в PO?
                  +2
                  У PO навыки тайм-менеджмента и уровень эмоционального интеллекта должны быть еще выше, чем у разработчика.
                  Если уж парень на позиции разработчика не умеет нормально коммуницировать с другими людьми («при возникновении спорных моментов в реализации фичи «проблемный» инженер спорит до посинения и не слышит аргументов других разработчиков»), какой из его PO?
                    +1
                    Зато видение свое протащит. Хотя, в исходных данных не указано, есть ли оно у него )
              +5
              Перевести в инфраструктурно-платформенно-библиотечную команду. Судя по всему, человека больше интересует «общественная» работа.
                –1
                Это уход от решения. По сути это означает, что этот выбор будет делегирован другому руководителю.
                  +4
                  Почему уход? На мой взгляд это вполне один из вариантов решения.
                  Можно же по договоренности с другим руководителем попробовать это сделать.
                  Не всегда разработчик попадает сразу в нужную команду, может в пределах компании есть более подходящая для него.
                  И соглашусь с комментатором выше — не всегда имеет смысл держаться до последнего за человека, если видно, что он не вписывается в команду.
                    +3
                    В качестве эксперимента. Провалится и там — на выход.
                      +4
                      Почему уход, может быть ему просто больше нравится решать задачи другого рода, а скучные бизнес круды/интеграции его просто не мотивируют и он над ними работает добросовестно, но в таком темпе, чтобы не сгореть от качества той кодовой базы, в которой он сейчас находится. Короче если у человека есть скиллы, но он не вписывается в команду, то просто поискать команду с более близкой ему культурой. Если таковых нет, то обсудить это с ним напрямую и дать время на поиск новой команды вне компании.
                    –2
                    Любые вопросы с кадрами легко решаются, если рассматривать трудовые отношения как аналогию с купли-продажей рабочего времени (либо результата) и знаний.
                    Забудьте о всяких корпоративных мотивациях и прочей шняге. Сотруднику от вас ничего не нужно, кроме денег. Всё всегда переводите в деньги. Сотрудника никак не должна интересовать компания, кроме как источник его персональных финансов.
                    Поэтому:
                    1. Переходите на сдельную оплату по результатам труда.
                    2. О «жертвах личного времени» нужно также заранее. Если для вас это важно, то обозначьте например, что каждый его внерабочий телефонный вызов будет оплачен в размере $100 Конкретная сумма — это вопрос договоренности, но она должна быть такой, чтобы он сам с удовольствием бежал к телефону, чтобы заработать на ответе на ваш вопрос. И боялся его выключить, чтобы не дай бог не пропустить «халтурку».
                    3. Финансово не договорились — расходимся.
                      +3
                      Напомню, что по условию этой мысленной задачки — вы руководитель. И как каждый руководитель, стараетесь получить больше пользы за меньшие деньги. Если в команде достигнута такая атмосфера, что сотрудники относятся к продукту как к своему «шедевру» и готовы вкладывать даже личное время в продукт — почему бы это не поддержать? В данном случае один сотрудник к этому не готов, и эта позиция может привести к тому, что и остальные перестанут уделять проекту дополнительное время. Честно ли это? Честно!
                      Выгоден ли такой вариант Вам как руководителю? Ну не знаю…
                        +10

                        Все вам правильно сказали: "заткнись и пиши код считай".
                        Надо прояснять условия. В реальности руководитель выбирает из альтернатив.
                        В США можно просто сказать "ты уволен". А в РФ очень трудно уволить сотрудника, если он не хочет увольняться. Что реально может сделать руководитель — предложить уволиться. И это совсем другие пироги.
                        Считаем цену увольнения (3 оклада и может даже больше), цену поиска нового сотрудника, онбоардинг. Считаем сколько денег "теряется" на недостаточной(?) продуктивности текущего. Учитываем различные риски ("позиция может привести").
                        Сравниваем, получаем срок окупаемости. И на основе этого принимаем решение.

                          +3

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


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

                            0
                            Напомню, что всегда нужно ставить себя на место обоих человек. По условию этой мысленной задачи сотрудник также желает поменьше работать за бОльшие деньги.
                            Ну и за честность: честно то, что равноправно. Договаривайтесь взаимно, забудьте слова «начальник» и «подчиненный». Примите, что руководитель — это координатор проекта и равноправная с наёмником сторона договора. Каждый должен друг другу ровно то, о чем договорились и ни каплей больше. Он вам код, вы ему денгьги.
                            Договаривайтесь!
                            +2

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

                              0
                              А кто говорит про постоянные переработки? Я так понял, что речь идет о каких-то критических случаях вне рабочего времени. То есть те случаи, когда отсутствие срочного реагирования влечет серьезные потери. Во всех остальных случаях можно подождать до утра.
                            +8
                            Нужно больше подробностей об остальной команде.
                            Не слишком понятно как они одновременно работают быстрее и при этом часто овертаймят. Может они просто работают больше?
                              +16
                              > приходит ведущий специалист от Бизнеса, который определяет приоритеты доработок и пользу от новых фич и сообщает, что недоволен продуктивностью одного из инженеров.

                              И отправляется дальше определять приоритеты разработок и пользу от новых фич.
                                +2
                                Так и надо. Иначе он каждый раз будет находить самого медленного разработчика и пытаться его выгнать. Такой, очевидно, всегда найдется. Командная работа превратится в элиминатор
                                  +4
                                  В майкрософт было подобная система оценки, когда вычисляли в команде сильного и слабенького разараба из-за чего два сильных сеньора не хотели попадать в одну команду, одного из них по-любому пометят слабым.
                                    +1
                                    Какая дружественная там, видимо, была атмосфера
                                      +3
                                      Ага, лет 10 назад я читал статью какого-то руководителя отдела R&D. У него в отделе все с ученой степенью (у них это доктор каких-то наук, но я не уверен, что это соответствует российскому табелю об ученых рангах).
                                      И вот, в отчетах нужно среди этих докторов наук указать наиболее отстающего…
                                        +1

                                        PhD — это плюс-минус наш кандидат.

                                          +1
                                          Ну, иностранный «доктор наук» — это, по нынешним временам, не бог весть какое достижение, в среднем по больнице оно означает, что чувак учился в вузе, закорешился с кем-то из профессоров и пошёл к нему аспирантом. Ещё фиг знает, почему пошёл — может, реально имел желание науку двигать, а может, просто работать не хотел. Прозанимался этим года три-четыре, приобрёл некий опыт, ценность какового, с точки зрения практического программирования, довольно сомнительна (хотя с точки зрения R&D, возможно, и нет). Наш «кандидат», как тут верно отметили, примерно соответствует ихнему «доктору» — и формально, и фактически, и попал туда примерно так же, и занимался там примерно тем же самым.

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

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

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

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

                                              +1
                                              Можно перевести проблемника на другой участок работ, а его старую работу дать новичку — это будет сигнал что проблемник свою старую работу плохо делал, потому отдали другому. Может поймёт, что на новом участке надо стараться лучше.

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

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

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

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

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

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

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

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

                                                +2
                                                Долго искал подобный комментарий. Наконец-то нашел!

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

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

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

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

                                                  +8
                                                  Как и в семейной жизни, основная часть проблем от несоответствия (незаявленных) ожиданий реальному поведению.
                                                  И решение, имхо, стоит начать искать с того, что огласить ожидания работнику.
                                                  Я от лица команды ожидаю, что:
                                                  ты будешь на связи после работы, хотя бы с… по…
                                                  что при обсуждении задач ты не будешь использовать (список выражений), а будешь (список выражений), а последнее слово (право вето) — за имярек / простым большинством / 2/3…
                                                  И т.д. и т.п.

                                                  Возможно, работник скажет: «Вы там совсем обалдели?! Я на такое не нанимался и не подписывался!!» и уйдет сам.
                                                  Если сам не уйдет — сначала найдите на его место кандидата лучше (понятно, что сразу не оценить, но разницу в подходах между «жить, чтобы работать» и «работать, чтобы жить», думаю, можно отловить на собеседовании), и только потом решайте — стоит ли менять синицу на журавля.
                                                    +5

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

                                                      0
                                                      Изменить его софт-скиллс вы вряд ли сможете.
                                                      Откуда такая уверенность?
                                                        0

                                                        Где в этом высказывании уверенность? В любом случае вы можете быть несогласны с этим высказыванием. Ваше право.
                                                        https://ru.wiktionary.org/wiki/вряд_ли

                                                          0
                                                          Мне показалось вы уверены в том, что «Изменить его софт-скиллс вы вряд ли сможете».
                                                          Хорошо, перефразирую: почему вы так считаете?
                                                            +1

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

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

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

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

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


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


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


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


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

                                                      +17
                                                      Как всегда все всё усложняют до ужаса.

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

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

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

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

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

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

                                                      Как-то так.

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

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

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

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

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

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

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

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

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

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

                                                              На мой взгляд, в этой постановке это выглядит как попытка компании выжать из сотрудников бОльшую производительность, чем от них требовалось «на входе», на этапе найма. Кто-то из разработчиков на личном топливе готов больше времени работе уделять — ну так это его личное решение. Крайне сомнительно, что на том основании, что у некоторых разработчиков, скажем, нет семьи и они могут больше времени уделять работе, можно требовать такого же подхода и у других сотрудников компании.
                                                                –2
                                                                Это ответ программиста, а не руководителя. :)
                                                                  +8
                                                                  Это ответ программиста руководителю. Что проблема возможно не там и не такая, как ему кажется.
                                                                  –5
                                                                  Так может рассуждать либо совсем джун, либо сотрудник концентрационной галеры типа CBOSS.

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

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

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

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


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

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

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

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


                                                                    Этот пункт интересен. Допустим, человек работает на 80% от нормы, но помогает развитию неких других проектов. А как оценить это в процентах?
                                                                    Интересно получается. В команде он чем-то не устраивает, но в целом компании дает большие плюсы, судя по всему.
                                                                    Уволить, чтобы улучшить работу команды, но ухудшить работу компании в целом?
                                                                      0
                                                                      Я бы сформировал вокруг человека соответствующее командное отношение. Т.е. дал бы понять команде, что перед нами негативный пример (с точки зрения моего видения команды как её руководителя), самому товарищу, естественно, так же — что в нашей команде подобный подход является недопустимым (при этом дав понять, что всё поправимо). Есть много способов сделать вышеозначенное — от стиля общения до материальных поощрений.
                                                                      Далее бы уже решала личная мотивация сотрудника. Если уволится — значит, уволится. Если качество провалится ниже — значит сами уволим. Исправится или впишется в некий другой круг обязанностей, где его сильные качества проявятся лучше — замечательно.
                                                                        +3

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

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


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

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

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

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

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


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

                                                                                Более того, при наличие должного объема наблюдений никто вам и не будет говорить те глупости — об этом и был мой пример.
                                                                              0

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

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

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

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

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

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

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

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

                                                                                +1
                                                                                Слишком округлое описание, задачка про команду требует наличия полутонов в описании. А у вас только цифры.

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

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

                                                                                    +4

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

                                                                                      –3
                                                                                      Не вижу вашего предложения, как решать проблему. Что предлагаете?
                                                                                        +3

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

                                                                                          –3
                                                                                          Проблема в том, что — шесть человек говорят что с седьмым некомфортно работать в команде.
                                                                                            +4

                                                                                            Это их личные проблемы. Буллинг поощерять это вообще дно.

                                                                                              +1
                                                                                              Если вы считаете это личными проблемами, я считаю что это проблемы команды.
                                                                                              Leeching тоже поощрять плохо.
                                                                                              0
                                                                                              Следует это обсудить непосредственно с сотрудником, для начала. А не выставлять на обсуждение *анонимов* на хабре
                                                                                                0
                                                                                                Топик-стартер указал что уже побеседовал с «прекрасным» инженером, его точка зрения следующая:

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


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

                                                                                                  Да и, полагаю, сотрудник гипотетический и вся ситуация с ним выдумана только для статьи.
                                                                                        +2

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

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

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

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

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

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

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

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

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

                                                                                                    0

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


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

                                                                                                      0
                                                                                                      Лучше бы было X, чем «проблемный», ведь там есть слово с заранее негативным контекстом

                                                                                                      Э…

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

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

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

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

                                                                                                  0
                                                                                                  человек не на своём месте. Надо двигать вбок
                                                                                                    +1
                                                                                                    У нас в компании был очень похожий случай.
                                                                                                    Проблемного сотрудника сначала перевели в другую команду, там история повторилась. После этого ему дали отдельный мини-проект, в котором у него были в подчинении outsource… проект затянулся на месяцы и окончательно убедившись что толка не будет, его сократили. 

                                                                                                    На принятие правильного решения влияет не только сотрудник, но и сложность его замены. Если компании тяжело и дорого найти новго сотрудника, стоит попробовать все варианты.
                                                                                                      +1
                                                                                                      Отличный пример!
                                                                                                      0

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

                                                                                                        +2
                                                                                                        По-хорошему, возраст сотрудника не должен влиять на решения руководителя.

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

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

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

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

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

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

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

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

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

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

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

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

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

                                                                                                              Мини-проект — сразу нет. Если вам так жаль денег на том, что вы теряете из-за «недоработки» программиста, то проект будет с большими рисками.
                                                                                                              Увольнение — отличный вариант. Вы решите проблему, разработчик найдет новую работу с зарплатой побольше и всё у всех будет хорошо. Но есть риски: 1) замена будет стоить денег (всю экономику сами уже поди посчитали); 2) новый разработчик возможно будет не лучше; 3) всегда будет один самый слабый разработчик.
                                                                                                              Контроль сроков — сомнительно. Лишние усилия и проблема с этим разработчиком будет висеть и постоянно о себе напоминать и менеджеру, и ВП.
                                                                                                              Оставить как есть — нормальный вариант. Может вся эта движуха из пальца высосана и «производительность» меньше на 10%, а разработчик — славный малый и остальные друг с другом тоже срутся.
                                                                                                              Также поддерживаю мнение, что ВП тут не при чем, а решение может принять команда.
                                                                                                                0
                                                                                                                3. Профессиональные навыки «проблемного» инженера также соответствуют ожидаемому уровню, и где-то даже превосходят средний уровень команды. Свою профессиональную область он знает хорошо, перфекционизмом страдает в меру, соблюдает принятые стандарты и паттерны разработки.

                                                                                                                4. Другие инженеры избегают совместных задач с «проблемным» разработчиком. Объясняют это тем, что при возникновении спорных моментов в реализации фичи «проблемный» инженер спорит до посинения и не слышит аргументов других разработчиков. В конце концов всё равно делает по-своему, и это (иногда) приходится переделывать на code review. Каждый раз это скандал и трагедия. А если переделывать не приходится (то есть решение верное), это выливается в нетолерантную тираду «а я же говорил».


                                                                                                                Во-первых, пункт 4 противоречит пункту 3. Кому как, а по мне умение работать в команде, если работаешь в команде — неотъёмлемая часть обязанностей инженера. Даже если этого не прописано в трудовом договоре. Там ещё много чего не прописано, это просто common sense.

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

                                                                                                                По поводу остального:

                                                                                                                Скорость работы — ну Вам виднее, насколько это критично. Если он предсказуемо небыстр, то с этим можно жить (менять что-то ли нет — опционально).

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

                                                                                                                Если в вашей местности нет проблем с трудоустройством, то переживать вообще не о чем.

                                                                                                                  0

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

                                                                                                                  0
                                                                                                                  Хороший вопрос. Ну что, давайте думать по пунктам.

                                                                                                                  1. Что если уволить?
                                                                                                                  — Его нагрузка равномерно распределится на других инженеров.
                                                                                                                  — Придется потратить некоторое время на поиск нового человека.
                                                                                                                  — Придется потратить некоторое время на внедрение его в коллектив.
                                                                                                                  Вывод: потрачено некоторое личное время, потрачено некоторое количество труда, но результат скорее всего будет достигнут (если вы берете расчет на будущее).

                                                                                                                  2. Оставить все как есть.
                                                                                                                  По личному опыту могу сказать что в долгосрочной перспективе это аппендикс, который будет расти все больше.

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

                                                                                                                  4. Постоянный контроль.
                                                                                                                  Свое время я ценю. Я не могу его контролировать все время. Нанимать другого человека для этого? Звучит как первый пункт. Почему бы мне не нанять другого человека для работы вместо него, а не брать человека для работы с ним.

                                                                                                                  По ходу написания этого комментария я сделал свой вывод. По моему пункт первый самый оптимальный. Главный аргумент — этот человек мешает работе других людей, снижая их продуктивность. Уволив его мы повысим продуктивность остальных ребят. Скорее всего, конечно. Ситуация теоретическая, конечно. А нужно ли нанимать на его место другого человека — покажет месяц работы без него.
                                                                                                                    0
                                                                                                                    Дать ему отдельный мини-проект.
                                                                                                                    Чисто из моего опыта, — работал в 2013 году с персонажем не проявлявшем особых трудов и способностей в нашей команде сопровожденцев. В основном тематику вытягивали я и ещё пара товарищей.
                                                                                                                    со временем руководство перевело его в отдельную группу где все было совсем грустно и печально. Персонаж был привычен к тому что дела всегда делались в срок, и оказался довольно таки внимательным товарищем, усвоил все наиболее эффективные методы используемые в нашей группе. Уже через полгода вытянул свою новую команду из болота ударным трудом, прокачал ответственность и управленческие способности. Пошел на повышение.
                                                                                                                      +1
                                                                                                                      По описанию проблемы разработчик обладает достаточной квалификацией, но на проекте откровенно заскучал. Проектные задачи неинтересны, пытается сам найти что-то для себя — способ реализации, инфраструктурные задачи, обсуждения других проектов…
                                                                                                                      Если хочется сохранить (высокая квалификация, много полезного сделал раньше..), надо обсуждать какие задачи ему были бы интересны и попытаться перевести в другую команду. Ну или искать замену.
                                                                                                                        0
                                                                                                                        А по факту единственная проблема — скорость решения задач, и даже это не проблема, если дедлайны не срываются (про это ничего не сказано). Все остальное вполне рабочие моменты, плюс несколько противоречивых утверждений. То есть сказать, что работник конкретно косячит в чем-то нельзя. Про свои отношения с командой и опыт руководителя автор при этом скромно умалчивает. Может проблема в том, что автор хочет видеть слишком послушного винтика (с периодическими переработками) в команде, а тот никак не поддается, но увольняться сам при этом не хочет из-за каких-то более позитивных для него самого факторов? Или там не очень с организацией, а человек не хочет выполнять роль «тяни-толкая» при живом руководителе? Или он вообще единственный, кто пытается хоть как-то нетривиально задачи решать? Тема не раскрыта, вопросов к руководителю больше, чем к работнику.
                                                                                                                          0
                                                                                                                          Руководитель (или его предшественник) попытался сотворить чудо и собрать плоскую команду в 7 человек, где все должны перформить «одинаково хорошо».
                                                                                                                          Получив ожидаемый результат он теперь ищет способы пофиксить неудавшееся чудо… и со временем снова получит ожидаемый результат.

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


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

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


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

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

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

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


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

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

                                                                                                                                        Вот уже когда оценка есть — стимуляция/наказание это чисто арифметический момент сколько там давать шпицрутенов или рублей…
                                                                                                                                          0

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

                                                                                                                                +1
                                                                                                                                Имхо, вы вкладываете в проблему слишком много эмоциональных посылов. Зря это.
                                                                                                                                Все же просто: если человек токсичен — нужно коллектив от него ограждать, однозначно.
                                                                                                                                Если ограждать по-лайтовому — то мини-проект и по результатам принимать решение. Основной критерий, является ли человек для компании прибыльным.
                                                                                                                                Короче, вывести проблему из психолого-социальной плоскости в плоскость чисто экономическую. И в ней уже спокойно все посчитать.
                                                                                                                                  +1
                                                                                                                                  Однажды к вам приходит Владелец продукта и сообщает, что недоволен продуктивностью одного из инженеров. Якобы он делает меньше задач, и аналогичные по сложности доработки другие инженеры выполняют быстрее (в той же кодовой базе).

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

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

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

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

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

                                                                                                                                    По народной легенде, стандартный тест на идиотизм — вопрос: «при авариях на железной дороге по статистке сильнее всего страдают пассажиры последнего вагона. Ваши предложения». Ответ настоящего идиота: «отцепить последний вагон». Правильная реакция руководителя коллектива: порадовать Владельца Продукта этим сообщением и предложить ему Заняться Собственными Делами.
                                                                                                                                      0
                                                                                                                                      У Саймака есть такой рассказ «Дурной пример». Не буду спойлерить, замечательный рассказ. Суть такова — в любой ячейке общества должен быть «дурной пример», тот на кого смотрят и говорят «а мы не такие»
                                                                                                                                        0

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

                                                                                                                                          +1
                                                                                                                                          Помните, люди не меняются
                                                                                                                                          Громкое заявление.
                                                                                                                                            0
                                                                                                                                            ну в какой то части это правда.
                                                                                                                                            Хотя правильнее люди меняются, но не по щелчку пальца. Силы и обстоятельства должны быть очень весомыми для личности меняемого.
                                                                                                                                              0

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


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

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

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

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

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

                                                                                                                                                    0

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

                                                                                                                                                          +1
                                                                                                                                                          Разумеется нужно уметь, потому руководителями и должны быть по идее люди, которые это умеют делать. А то что описано выше — это похоже на поведение дурной супруги, которая трепет нервы мужу, с помощью всяких намеков и обид, которых тот тупо не понимает, хотя и видит что что-то неладное творится, но добиться прямого ответа от нее не может.
                                                                                                                                                      0
                                                                                                                                                      Какая-то странная статья, показывающая всю правду о том, что сотрудник почему-то должен переживать за чужой бизнес, в котором он только наемный работник.
                                                                                                                                                      • Оценка личных качеств происходит по продуманному, зафиксированному и подписанному сотрудником процессу в компании или чисто по субъективному мнению «руководителей»?
                                                                                                                                                      • А методика оценки работы сотрудника где-то продумана, зафиксирована и подписана сотрудником, которого оценивают или это «я начальник, я прав»?

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

                                                                                                                                                                А это уже пахнет дисциплинарными мерами.
                                                                                                                                                                  0

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

                                                                                                                                                                        В отдельных случаях можно попытаться перевести человека на другой проект, но, во-первых, в 90% случаях все проблемы, которые есть сейчас, так и останутся (потому что это фундаментальные проблемы психики человека). Во-вторых, если бы это помогло, это решение было бы почти очевидно. Если вопрос встал «увольнять или переводить», скорее всего, ответ вам итак уже известен.
                                                                                                                                                                          0
                                                                                                                                                                          Для автора прям "постарался ответить" один «сеньёр» постарался ответить!
                                                                                                                                                                          Перевод тоже уже готов!
                                                                                                                                                                          Вот и дожили, что не может не радовать:
                                                                                                                                                                          — Ответы сеть генерирует ещё раньше чем вопросы задаются!
                                                                                                                                                                            0
                                                                                                                                                                            Режут глаза пункты про работу в нерабочее время. Почему это считается минусом работника, а не работодателя?

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

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

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

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


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

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

                                                                                                                                                                            Самое читаемое