Сотрудник не слушает моих требований

Здесь возможны 2 вещи:

1. Этот разработчик очень некомпетентен. У вас есть конфигурация докера для разработки, поэтому достаточно просто добавить все, что нужно сделать для производства. Теоретически у вас уже есть настроенная производственная инфраструктура и документация (или эксперт в предметной области) о том, как запустить приложение в производство, так что это не должно быть слишком сложно. При этом «жесткий» и «долгий» — не одно и то же; только потому, что это не «сложно», не означает, что это не может занять много времени. Если разработчик некомпетентен, то вы должны уволить его и найти некомпетентного. Вы менеджер, вот как вы управляете.

2. Этот разработчик очень хорош в своей работе. Хорошие разработчики говорят что-то вроде «Я не собираюсь продвигать неработающий код». Вот как вы узнаете, что у вас действительно хороший человек в вашей команде, когда они так отталкивают вас, потому что это означает, что они гордятся своей работой и следят за тем, чтобы она была сделана правильно. Вот как вы знаете, когда этот человек что-то доставляет, это может занять немного больше времени, но вашему дежурному не придется вскакивать с постели в 2 часа ночи из-за полного сбоя сервера серьезности 1. Если этот человек — очень хороший разработчик, а вы не привыкли иметь дело с хорошими разработчиками (а кажется, что это не так), это означает, что остальная часть вашей команды не является хорошим разработчиком или, по крайней мере, не так хороша, как этот человек. Это означает, что если этот человек не создавал это приложение, а только развертывал его, тогда, вероятно, развертываемое приложение было написано плохо, и могут быть внешние факторы, препятствующие его правильному развертыванию, такие как несовместимые конфигурации, которые увеличили ожидаемое время, необходимое для развертывания. Если это так, то вы должны уделять этому человеку все время, необходимое ему для надлежащего выполнения своей работы. Вы должны поощрять их проверять свою работу в Git, «чтобы убедиться, что они не потеряют свой прогресс» (используйте это как оправдание, не связывайте эти коммиты Git конкретно с производительностью, и действительно тогда вы должны дать этому человеку все время, необходимое ему для надлежащего выполнения своей работы. Вы должны поощрять их проверять свою работу в Git, «чтобы убедиться, что они не потеряют свой прогресс» (используйте это как оправдание, не связывайте эти коммиты Git конкретно с производительностью, и действительно тогда вы должны дать этому человеку все время, необходимое ему для надлежащего выполнения своей работы. Вы должны поощрять их проверять свою работу в Git, «чтобы убедиться, что они не потеряют свой прогресс» (используйте это как оправдание, не связывайте эти коммиты Git конкретно с производительностью, и действительноНЕ ИСПОЛЬЗУЙТЕ их в качестве критерия производительности; если вы не просите отточенный, работающий код в этих коммитах, то не кричите на этого разработчика, когда его коммиты Git не отполированы или не работают), и вы можете использовать эти контрольные точки для оценки производительности, но не давите сильнее. чем это.

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

Я предлагаю позволить вашему разработчику объяснить вам, что происходит. Возможно, пригласите его на совещание по статусу просто для того, чтобы он объяснил вам, что он сделал, что он делает и что еще нужно сделать, и посмотрите, можете ли вы сократить для него объем работ, чтобы он сделал это быстрее, или добавить больше. люди, чтобы помочь ему, или что-то. Или просто, неформально, задайте несколько вопросов и будьте готовы выслушать его ответы, а не просто отметать его работу как «вещи, которые не нужны». Затем, как только вы его выслушаете, вы сможете принять решение; если вы считаете, что он хорошо работает и делает то, что ему нужно, то позвольте ему продолжать, если нет, то вы можете его уволить.

Это простая петля ответственности:

1. Установить ожидания
2. Отслеживание производительности, поддержка, обучение
3. Оцените производительность
4. Последствия: корректирующие действия или подкрепление
5. вернуться к 1

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

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

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

1. Честно говорите о своих технических навыках:

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

2. Все должны обеспечить видимость своим руководителям:

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

3. Есть место для черновика кода

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

Но менеджеры и коллеги, оказывающие помощь, должны иметь доступ к этим репозиториям, чтобы они могли предоставить информацию и советы на концептуальном уровне, например: «Эй, вы используете инструмент X, вы не рассматривали возможность использования инструмента Y?», «Нет, потому что он платный». ", "Ну, а у нас уже есть лицензия на это!".

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

4. Будьте очень осторожны, обвиняя других

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

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

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

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

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

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

Позвольте мне добавить: что бы вы сделали, если бы вы хотели, чтобы ВАШ босс пришел и уволил его? Вместо этого они, вероятно, уволят вас за то, что вы были неэффективным лидером.

Убедитесь, что есть способ скрыть его или посадить с ним кого-то еще. Он будет производить или не будет. Если он этого не сделает, выгода от того, что кто-то будет работать с ним, окупится за выяснение того, где он остановился и что он сделал.