Коллега продолжает ошибаться, как ему помочь? [закрыто]

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

Я пытался помочь ему следующим образом:

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

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

Каков наилучший способ справиться с этим?

При обсуждении того, почему он изменил функцию, было ли у него объяснение? Возможно, он чувствует, что «улучшил» его, но не понял, что это должно быть сделано именно так, как обсуждалось. Он может даже не знать, что поступает неправильно, и может думать, что ваши предложения только таковы.
Подождите, почему его работы представляются непосредственно клиенту, чтобы они разозлились? Нет ли какой-либо проверки или внутренних «ворот», прежде чем они попадут к клиенту?
Добро пожаловать на планету Земля. Если бы он был идеальным, он был бы твоим боссом. Частью бизнеса является эффективное использование дефективных людей.
Это удаленный работник? Потому что, если бы он сидел рядом с дизайнером или рядом с QA, вместо того, чтобы дать ему прямой доступ к клиенту (что на самом деле является вашей работой), у вас, вероятно, не было бы этой проблемы. Работать удаленно сложно, именно потому, что цикл обратной связи намного длиннее, поэтому вместо того, чтобы потратить 10 секунд, чтобы исправить что-то, бросив быстрый взгляд рядом с вами, вам, вероятно, нужно запустить код самостоятельно, а затем отправить официальное электронное письмо с изложением проблему целиком, а затем нужно ждать ответа, который может прийти только на следующий рабочий день.
Итак, если то, что я говорю, верно, пока он не выполнит качественную работу, вы должны попросить его сделать скриншот своей работы и поместить его рядом с фактическим макетом, а затем попросить его объяснить, какую оставшуюся работу он должен выполнить в его ежедневные отчеты для вас. В качестве еще одного возможного решения вы можете попробовать нанять стажера в том же месте, что и этот разработчик, и пусть он будет для него QA. QA на самом деле очень важен, но не похоже, что у вас есть кто-то, посвященный этой роли.

Ответы (1)

Убедитесь, что он знает, что это серьезная проблема.

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

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

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

Формально проверяйте его работу на соответствие четким требованиям.

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

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

Не убирайте за ним.

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

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

Регулярно встречайтесь с ним, чтобы оценивать эффективность работы с течением времени и ставить четкие измеримые цели.

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

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

Важно никогда не убирать за некомпетентным. Отправьте ему обратно с комментариями о том, как исправить. Заставьте его почувствовать боль исправления. При необходимости сядьте рядом с ним и направьте его, но никогда не прикасайтесь к клавиатуре. Вы включаете некомпетентного, если убираете за ним. Люди удивляются, как эти люди остаются на работе, потому что другие убирают их работу. Важно, чтобы он знал, что его работа поставлена ​​на карту, если он не сможет исправить это, и работа никогда не улучшится.
@HLGEM - именно такие комментарии заставляют меня лоббировать StackExchange для кнопки «+100». Хотел бы я заставить нескольких человек, с которыми я работал, читать это вслух в начале каждого рабочего дня.
@WesleyLong Верно!