Как быть с относительно технически некомпетентным коллегой?

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

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

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

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

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

Знает ли ваш коллега о своем относительном недостатке знаний? Судя по тому, что вы провели с ними, доказали ли они, что хотят узнать больше, полезное для их работы?
Я не понимаю, что ты думаешь, что можешь сделать. Вы не можете просто внезапно заставить кого-то понять тестирование, и если это не является частью их работы (до сих пор они справлялись), то им не нужно его изучать.
Почему вы влезаете в темы об алгоритмах, в первую очередь с QA-специалистом? И зачем отлаживать и запускать ручные тесты «вместе»? У задачи должны быть четкие требования и «критерии приемки», соответствуете вы ей или нет. QA несет ответственность за сообщение об отсутствии совпадений или наличии ошибок с побочными эффектами.
Здесь возникает серьезный вопрос процесса — кто несет ответственность за разработку, проверку, выполнение и отчетность по тестовым случаям? Я должен разработать свои собственные тестовые примеры, проверить их у другого разработчика, а затем они выполняются и о них сообщается нетехническим персоналом, после чего все идет/не идет.
«Моя работа проверена и работает, но в других местах есть другие проблемы, и чтобы убедиться, что моя работа не содержит ошибок, мне нужно понять ошибки и в других частях» — если ваша работа проверена и работает, это должно доказать, что ваша работа не работает. не глючит. Если нет, то, возможно, потребуется перепроектировать тестирование или продукт, чтобы обеспечить лучшую изоляцию между компонентами.

Ответы (3)

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

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

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

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

  • Изучите знания/качества, необходимые для работы/должности
  • Уступите место тому, кто имеет квалификацию.

Предложение ( в указанном порядке )

  1. ПРЕКРАТИТЕ помогать им во всех задачах. Пусть они работают и продлевают или терпят неудачу.
  2. Попытайтесь визуализировать общее узкое место, не указывая пальцем на своего менеджера / начальника. Кроме того, составьте список случаев, когда вы помогли им достичь результата сверх ожидаемого графика/юрисдикции.
  3. Сообщите о решениях, которые вы можете предложить (например, о любом обучении/ориентационном занятии, которое может быть проведено для их ознакомления).
  4. Наконец, еще раз подтвердите тот факт, что из-за узкого места общая производительность команды снижается.

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

Вы не определили роль этого человека, как и первоначальный задавший этот вопрос. В небольшой организации это несоответствие часто может происходить из-за несогласованных ожиданий в отношении ролей и обязанностей, а также из-за того, как это может повлиять на процесс, который не был четко определен с самого начала. Это не делает его дефицитом QA Hardware Engineers, это проблема процесса. Разработчик нередко помогает QA воспроизвести/диагностировать проблему — это может быть допустимым процессом, кому-то просто нужно дать понять, что это часть процесса, если это так.
ОП также может захотеть сообщить своему руководителю / начальнику о ситуации. Не для того, чтобы призывать их к дисциплине, а для того, чтобы дать им дополнительную подготовку. В хорошей рабочей обстановке вы можете собрать их, их начальника и начальника ОП на встречу, чтобы обсудить стратегии обучения, чтобы помочь человеку, о котором идет речь, а не создавать ему проблемы.
Ответчик не упомянул одну вещь: если вы им помогаете, это может усугубить проблему. Либо они не подходят для работы, как написано, либо они подходят , и их работа должна быть адаптирована в соответствии с QA со всеми необходимыми инструментами. Одно дело, если они инженеры-испытатели; другое дело, если у них просто есть опыт QA старой школы, когда они привыкли ломать вещи и писать ошибки.

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

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

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

ЛОЖЬ. Инженер-железо, который не может писать код, устарел уже несколько десятилетий. Даже если программное обеспечение никогда не является чьим-то рабочим продуктом , слишком много моментов в рабочем процессе аппаратного обеспечения, когда возможность написать некоторый код для моделирования чего-либо, проверить свой проект или внести тривиальные исправления в то, что написал кто-то другой, абсолютно необходима . Тот, кто не может этого сделать, пытается работать со связанными за спиной обеими руками . Кроме того, такая неспособность указывала бы на огромный пробел в способности мыслить как Инженер .
Но в этом случае вы полностью ошибаетесь в названии должности — «инженер по обеспечению качества и анализа оборудования» не проектирует оборудование, а тестирует его. И программное обеспечение — это бьющееся сердце таких тестов.
@ChrisStratton Тестирование программного обеспечения, чтобы убедиться, что оно работает на оборудовании, требует, чтобы вы знали, как именно это сделать, и больше ничего на данный момент. Еще одна вещь, которую следует учитывать, это то, что если этот человек только что закончил школу или не знаком с языком, он, по сути, младший.
Вы интерпретируете «инженера по обеспечению качества оборудования» как человека, который тестирует программное обеспечение на разных процессорах. Это будет роль «QA портативности». Я согласен с интерпретацией Криса: кто-то, кто тестирует новые конструкции оборудования, чтобы проверить аппаратное обеспечение . OP дает несколько подсказок о том, что в компании работают люди с навыками проектирования оборудования, поэтому они, вероятно, не просто создают + тестируют программное обеспечение. Аппаратное обеспечение качества означает, что им, возможно, придется написать программное обеспечение для проверки любых аппаратных крайних случаев, которые они придумают.
Я предполагаю, что «инженер по обеспечению качества оборудования» вовсе не инженер.

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

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

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

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

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

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

Как быть с относительно технически некомпетентным коллегой?
СпросиСетьПолитика конфиденциальности1y, 0v