Я присоединился к этой компании в качестве инженера по тестированию, чтобы создать CI, автоматическое тестирование и т. д. Моя проблема в том, что когда я выявляю проблемы и говорю разработчикам, как их исправить, они игнорируют меня и довольно враждебно относятся ко мне. Как я могу заставить их слушать мой вклад? Я хочу, чтобы мы могли лучше работать в команде. Прямо сейчас я чувствую себя в ловушке как QA-парень, которого никто не уважает.
Некоторые подробности произошедшего:
Сразу же начальник №1 (все еще работающий удаленно еще несколько месяцев) позвонил мне по видеосвязи и сказал, что он не знает, что произошло, и на самом деле не хочет знать — сказал мне, что что бы ни случилось, это моя вина. и, цитата: "кто бы ни был прав, дружба важнее компетентности".
С тех пор прошло около месяца — все эти ребята до сих пор меня не слушают, пишут дерьмовый код, ничему не учатся и нечему меня учить. Снова и снова они борются с проблемами, которых не было бы, если бы они слушали меня, когда я их предупреждаю. Но даже если у меня больше лет опыта программирования и я знаю больше языков программирования, чем они в сумме, поскольку я работаю здесь всего несколько месяцев и на должности инженера по тестированию, это означает, что они не должны меня слушать. .
Моя проблема в том, что когда я выявляю проблемы и говорю разработчикам, как их исправить
Я думаю, что вы выходите за рамки своей позиции, и я не удивлен вашей реакцией. Ваша работа не в том, чтобы указывать разработчикам, как что-то исправить. Я давно в этом бизнесе, и никогда не слышал, чтобы специалист по контролю качества говорил мне, как писать код. Но с другой стороны, я никогда не работал с QA людьми, которые смотрят на код. Это выходит за рамки QA.
Когда вы приходите к разработчику, говорящему о том, как ему следует использовать функции сокращения высокого порядка и тому подобное, я могу точно сказать вам, что крутится у него в голове: «Если вы так хорошо программируете, то почему вы не пишете код? ?" Весь ваш пост имеет такое отношение. Если ты такой хороший, а они такие плохие, то почему ты до сих пор там работаешь?
Как вы сказали, основная роль отдела контроля качества заключается в выявлении проблем. Вы делаете это посредством тестирования и анализа. Любая информация, которую вы можете добавить, которая поможет в решении проблемы, всегда хороша. Но будьте осторожны, предлагая решения. Помните, что ваша работа заключается в выявлении проблем, а не решений. Все разработчики ожидают от QA как можно больше информации для решения проблемы. Если вы знаете, как это исправить, то обязательно сообщите подробности. Но если все, что у вас есть, это мнение, то дайте понять, что это мнение, а не директива. Напишите «Я думаю, это потому, что XYZ нуждается в токене при каждом запросе» или «Я подозреваю, что мы опускаем токен».
Устранение сопротивления команды разработчиков решениям, предложенным QA-инженером?
Как «инженер в тестировании», у вас, вероятно, больше навыков кодирования, чем у большинства QA, особенно в вашей текущей рабочей среде, основанной на вашем вопросе. Вам нужны навыки программирования для автоматического тестирования, и это создает ложное впечатление, что эти навыки принимаются и уважаются теми, кто занимается разработкой.
Однако, внося предложения о том, как решить проблемы, вы выходите за свои профессиональные границы. У вас ограниченная информация и понимание всего процесса разработки. Ребята, пишущие код, должны отвечать за решения, так что пусть они делают свою работу.
Нетехническая аналогия, которую я люблю использовать, заключается в следующем: если вы нанимаете кровельщика, чтобы заменить вашу крышу, вы будете задавать вопросы и наблюдать за ним, чтобы чувствовать себя комфортно, что он делает хорошую работу. Но если вы заберетесь на крышу и начнете рассказывать кровельщику, как он мог бы «делать вещи лучше» или что-то в этом роде, вы зашли слишком далеко и, вероятно, разозлите своего кровельщика. Слезь с крыши и перестань указывать парню, что делать.
Сосредоточьтесь на построении своих систем и выявлении ошибок разработчиков. Позвольте им определить и выбрать решения выявленных вами проблем.
Я думаю, вам нужно разделить ваше общение с разработкой на две части:
Вы должны попытаться построить хорошие рабочие отношения с разработчиками. Возможно, это усложнилось из-за того, как вы начали, поэтому отложите на несколько месяцев. Начните с того, что попросите их совета: «Я думаю, нам следует проводить больше стресс-тестирования компонента X. Какая рабочая нагрузка может вызвать его перегрузку? Есть ли сложные области, требующие дополнительного тестирования?» Прислушиваться к советам становится нормальным и неважным.
Как только у вас сложится такая связь, попробуйте небрежно упомянуть, что, по вашему мнению, конкретный кластер неудачных тестов можно исправить как группу путем некоторого изменения дизайна.
Я хочу начать с того, что я работаю в очень похожей области с почти такими же целями: ИТ-аудит. Если я вас правильно понимаю, вы расстроены, потому что чувствуете, что другие не прислушиваются к вашим советам, а ваш начальник не поддерживает вас, настаивая на отношениях, а не на компетентности.
Если вы хотите, чтобы люди слушали вас и серьезно относились к вашим отзывам, вы должны сначала рассказать им, какую пользу они принесут в своей работе, слушая вас. В вашем случае преимущество будет заключаться в меньшем количестве ошибок и улучшенном функционировании кода, который с большей вероятностью будет соответствовать бизнес-целям. Постоянное написание плохого кода и отказ от улучшения, когда предоставляется возможность, демонстрирует презрение, агрессию и почти высокомерие в некотором смысле, поскольку они лучше знают. Если такое поведение будет продолжаться, это почти гарантирует увольнение из-за некомпетентности и неспособности хорошо работать с другими.
Я предлагаю вам предположить положительное - что эти разработчики не пытаются быть враждебными назло. Скорее всего, они не понимают , почему вы хотите, чтобы они изменились . Предположим, что люди рациональны, что, хотя они могут не хотеть сотрудничать, они не будут подвергать опасности свою работу из-за этого конфликта. Обсудите с этими разработчиками, когда все стороны будут спокойны, и объясните ход ваших мыслей. Почему вы хотите, чтобы они менялись так же, как и вы, и какую пользу они от этого выиграют.
Ваш босс здесь также ведет себя неразумно, настаивая на отношениях, а не на компетентности. Я полностью не согласен. Ваша работа отражается на вашем начальнике — либо плохо, либо хорошо. Когда ваш начальник заламывает руки, отказываясь от какой-либо ответственности, он подвергает риску свою работу. Не признавая компетентность и добавленную стоимость за счет улучшения процессов, он и члены его команды (и вы среди них) в конечном итоге будут оцениваться, он демонстрирует удивительно недальновидное суждение. Ситуация неприятная, но зарывание головы в песок не избавляет от проблемы.
Ваша работа служит контролем над работой других, и вы должны признать, что из-за этого факта всегда найдутся люди, которым вы не нравитесь. Идите по прямому пути и не рассматривайте обратную связь как личное нападение, каким бы неприятным оно ни было. Станьте толще кожи и научитесь не реагировать на враждебность/непрофессионализм других — в долгосрочной перспективе эта практика сослужит вам хорошую службу.
Я согласен с этим ответом о четком разделении между сообщениями о проблемах (ваша работа) и неформальными предложениями по их решению . К этому я добавлю еще один подход: задавайте вопросы .
Я технический писатель и часто отвечаю за определение угловых случаев в интерфейсе перед документированием, потому что, как мы все знаем, ни одна спецификация не может быть завершена на 100%. Иногда я обнаруживаю поведение, которое, скажем так, не совсем желательно — оно нелогичное, непоследовательное или дорогое. Я неплохо преуспел в своей карьере, объясняя, что, как я думал, должно произойти, и что вместо этого я видел, говоря, почему меня это волнует (если это не очевидно из контекста), делясь любыми предположениями, которые у меня есть о причине, и прося совета или помощи . В конце концов, вы можете сделать предложение или посеять семена, не говоря никому, что делать.
Вот пример того, что я имею в виду:
Я проводил некоторые тесты безопасности. Я думал, что клиентский запрос данных из службы будет отклонен, если пользователь не авторизован, но я все равно смог прочитать данные. В частности, я запустил клиент, прочитал некоторые данные, отозвал авторизацию этого пользователя на сервере, а затем прочитал еще некоторые данные, и это сработало. Разве мы не проверяем каждый звонок? Если мы кэшируем его, указываем, как долго между повторными проверками, или это не указано? Я хочу убедиться, что я ясно объясняю это в административной документации.
Предположим, что ответ заключается в том, что состояние авторизации кэшируется на сервере, и разработчик не хочет давать никаких дополнительных гарантий. Чтобы продолжить разговор:
Спасибо; Я понимаю. Итак, если администратор сервера хочет убедиться, что отзыв вступает в силу немедленно, потому что, возможно, это ситуация с высоким риском, есть ли способ очистить кеш? Или ему нужно сбросить сеанс и заставить клиента переподключиться?
Что мы сделали здесь, так это описали проблему пользователя и вслух подумали о том, как с помощью программного обеспечения, как оно есть, он может ее решить. Разработчик, который думал, что небольшая задержка в обновлении авторизации не имеет большого значения, может подумать еще раз, если ответом является перезапуск клиентского сеанса - возможно, это слишком тяжело. Или, может быть, это совершенно нормально, и вы узнаете, что клиентские сеансы должны быть короткими, эфемерными и часто возобновляться, и в этом случае вы узнали кое-что о дизайне.
Вы и разработчик — коллеги с разными специальностями. Ни один из вас не должен диктовать другому, как выполнять его работу, но вы оба должны быть открыты для обмена информацией, обучения и совместной работы над решением проблем ваших клиентов.
Как было предложено, лучшей стратегией может быть отступление назад и сдерживание вашего стремления рассказать всем, как исправить проблемы, вместо этого сосредоточение внимания на выявлении, документировании и тестировании исправлений проблем.
Кроме того, в этом конкретном случае культура рабочего места может отдавать предпочтение старшинству и разделению труда, а не компетентности. Заслужить уважение в такой обстановке может быть длительным процессом и тяжелой битвой, требующей больше времени и усилий, чем потребовалось бы на рабочем месте другого типа. Похоже, что руководство замешано в этом, ценя статус-кво, а не адаптацию и изменения.
Мне интересно, изменилась бы эта модель, если бы потребности бизнеса определяли скорость исправления ошибок, т. е. если бы ошибки вызывали очевидные и измеримые задержки и жалобы клиентов. Это будет трудно решить до тех пор, пока не изменятся стимулы, но, скорее всего, это находится вне вашего контроля. Если вы считаете, что это сигнализирует о дисфункции на текущем рабочем месте и продолжает демотивировать вас без надежды на изменение тенденции вплоть до увольнения, возможно, пришло время рассмотреть другие варианты трудоустройства.
Тем не менее, есть ряд изменений в вашем поведении, которые стоит попробовать, прежде чем отбрасывать текущую ситуацию как неисправимую. Я бы посоветовал вам сначала сделать шаг назад и пересмотреть свой собственный подход к этому процессу, а также прислушаться к совету о том, чтобы не давать слишком много советов относительно исправлений, если этого не требует команда разработчиков.
комар
Джейн С
Моника Челлио