Вчера я выложил факты, которые получили большой отклик, и решил разобрать один из них… 👇

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

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

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

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

Новому сотруднику давали задачу и отправляли искать ответы в документации (только документация местами была устаревшей, лол 👎). Если он обращался к коллегам, те не всегда могли помочь и часто перенаправляли его к кому-то другому. В итоге значительная часть времени уходила не на тестирование и решение задачи, а на попытки найти актуальную информацию и понять, как вообще здесь всё устроено. В результате, сроки срывались, где-то страдало качество, а команда делала вывод: «Он работает недостаточно эффективно».

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

Если пост был полезен, буду рад реакции!) 👍

QApedia | QApedia в MAX