Я была С++ разработчиком, когда мне предложили стать тимлидом. В моей новой команде были и разработчики, и QA-инженеры. В тестировании я имела поверхностные знания, поэтому долгое время не понимала, как подступиться к задаче по развитию QA-специалистов. Поиск решения занял несколько лет, и в этой статье я поделюсь своим опытом. Надеюсь, она будет полезна для тех тимлидов, которые в тестировании не так хороши, как в программировании.
Отправная точка
Менеджерская функция добавляет много задач, и одна из них — развитие сотрудников. Хороший лид растит специалистов: даёт им возможность профессионально развиваться, работать более эффективно и приносить пользу команде. Развитие сотрудников — это взаимовыгодный процесс для них и компании.
Я начала руководить командой и взялась за индивидуальные планы развития. И если с С++ программистами мне многое было понятно, то с тестировщиками было сложнее.
Моя практика. Первым делом я подумала, что раз я тимлид в команде с тестировщиками, то должна не просто знать об основах тестирования и организации процессов, но и знать, видимо, всё.
Я собрала у умудрённых опытом коллег список литературы и полезных видео. По вечерам после работы включала доклады с конференций, чтобы знать обо всех новинках в мире тестирования. На изучения я потратила месяц, но это привело только к жуткой усталости от количества информации. Большинство идей, которые я услышала и вычитала, не подходили под мою ситуацию, а возможности попробовать что-то на практике просто не было.
Опыт, который я вынесла. Ты должен быть хорошим руководителем, это основная задача. Хороший тимлид — не обязательно топовый специалист во всех областях: эта роль не только про технологии, но и про менеджмент и лидерство. Замечательно, когда сотрудники команды разбираются в технологиях лучше тебя, именно таких и стоит нанимать.
Задача
У меня — тимлида — назначена встреча один на один с тестировщиком. На ней надо обсудить его индивидуальный план развития (ИПР). В условиях оговоримся, что сотрудник сам хочет расти.
Первый шаг: оценка скиллов
Чтобы понять, какие скиллы сотруднику стоит развивать, нужно сперва оценить текущие по каким-то критериям.
Существует много инструментов для оценки. Но чтобы процесс не превратился в формализм, а действительно помог, нужно найти баланс между этими инструментами. Выбрать один или несколько и адаптировать их под команду.
Расскажу про инструменты, которые я нашла, и про то, что из них использовала на практике.
1. Оценка по уровню: Junior/Middle/Senior
Такая оценка не даёт полноценного представления о реальных навыках специалиста, очень поверхностно определяет уровень знаний и опыта, а также является субъективной у каждого руководителя и компании.
Моя практика. Я пообщалась на эту тему с руководителями из разных компаний, джедаями тестирования и собрала свои определения «уровней». Они помогли мне базово понять, от чего я могу отталкиваться в своей оценке.
Абсолютно всем сотрудникам необходимы:
представление о тайм-менеджменте;
коммуникационные навыки, в том числе уважение и вежливость.
Это минимум для работы в команде.
Junior-специалист:
имеет базовые знания и мало опыта;
ревью задач для него обязательно;
обязательно нужен ментор. Ментор должен не только ставить задачи и контролировать их выполнение, а также обучать.
От Junior-специалистов требуется умение задавать вопросы. Часто случается так, что они просто стесняются спросить. Задача тимлида — создать такую атмосферу в команде, чтобы начинающий специалист мог спокойно спрашивать обо всём.
Middle-специалист:
умеет писать нормальные тест-кейсы и отчёты;
может делать ревью других Middle- и Junior-специалистов;
обладает знаниями и опытом, чтобы анализировать фичу и требования;
обладает знаниями о процессах и методологиях тестирования;
имеет навыки работы с логами и спецсофтом в зависимости от сферы;
может взять на себя тестирование целой фичи;
может самостоятельно выполнять задачи без постоянного контроля.
Senior-специалист согласует с тимлидом только задачи, а дальше самостоятельно делает всё:
прогнозирование рисков;
оценку сроков;
анализ;
общение с заказчиком;
делегирование задач и так далее.
Помимо экспертных знаний в теории тестирования и предметной области, ключевое отличие Senior-специалиста от Middle — это самостоятельность. Senior делает задачу от начала и до конца. Это помощник тимлида в налаживании процессов в команде.
2. Грейды
Если они есть в компании, то часть с оценкой уже решена. Вопрос о том, вводить или не вводить такую систему — очень сложный.
Моя практика. В моей ситуации грейды не подошли. Мы попробовали разработать систему грейдов с несколькими командами, но успехом это не увенчалось. Введение грейдов — задача скорее для всей компании, а не нескольких команд. Это длительный и сложный процесс, который требует много времени и сил.
В молодой компании, которой мы были в то время, договориться о единой оценке между, например, командами бэка и фронта, было очень сложно. Плюс, на мой взгляд, грейды привязывают сотрудников к каким-то конкретным точкам: знаниям, стажу, навыкам, тем самым ограничивая и вписывая в рамки. Тем не менее, многим этот инструмент помогает централизованно оценить уровни сотрудников и сделать критерии роста прозрачнее. Подходят ли грейды для вашей компании на её этапе развития — выбирать вам.
3. Внутреннее QA-сообщество
Если есть сообщество QA-специалистов для обмена опытом внутри компании, и сотрудник в нём участвует, то можно собрать обратную связь у его коллег из «виртуальной» команды.
Моя практика несколько интересней: на тот момент в компании была отдельная QA-команда. Мы попробовали этот подход, поскольку у нас был один релизный цикл на три команды — все занимались разработкой фронта. Для синхронизации тестирования и релизов мы решили, что выделим отдельную команду тестирования.
Это дало массу существенных плюсов: ребята ускорили выпуск релиза в три раза, подняли огромный пласт работы по тест-кейсам, автоматизации, проработке фич на разных уровнях тестирования. Вообще удивительно, насколько совместная работа способна создавать благоприятную атмосферу для роста команды, генерации и воплощения идей.
Тимлидом команды стал QA Manual. Как специалист в своей сфере он занялся ИПР каждого из тестировщиков, потому что имел колоссальную экспертность и необходимые хард-скиллы.
Но все течёт и меняется, и через несколько лет под процессы компании такая оргструктура уже не подходила. Мы объединили команду с разработкой. Тимлидом новой команды стал лид тестирования, это тоже один из вариантов развития.
4. QA Lead
Идея такая — если в компании есть старший QA-друид, то стоит прямиком идти к нему с запросом об оценке и помощи в составлении ИПР.
Моя практика. Я обращалась к QA-лиду с запросом об оценке. Это очень помогало в специфических отраслях, где нужны были глубокие знания в теории тестирования.
Из плюсов моего взаимодействия:
профессиональная оценка;
советы по развитию;
рекомендации по конференциям, курсам и литературе;
рекомендации по новым практикам в команде и помощь с процессами тестирования.
Из нюансов — важно проверять, насколько рекомендации соотносятся с целями вашей команды и компании. У меня был случай, когда моя коллега делала задачу «формулирование критериев достаточности тестирования». И это была работа в стол: команда критериями не пользовалась, и никто не понимал, зачем мы это делаем. Но в целом, QA-лид для меня был большим помощником в оценке и развитии тестировщиков.
5. Обратная связь от коллег
У каждого члена своей команды я спрашивала:
Что у сотрудника получается хорошо?
Что стоит улучшить?
Какой опыт взаимодействия с вашим QA?
Перед тем, как задавать вопросы, важно сказать коллегам о цели — составить план развития для человека. Тогда рекомендациями поделятся охотнее.
Моя практика показывает, что зачастую мнения коллег сходятся, и можно легко выявить сильные стороны сотрудника и точки роста. Считаю этот способ одним из самых эффективных: ребятам из команды оценить ежедневную работу проще всего, ведь они трудятся бок о бок. Например, разработчики легко оценят коммуникацию с конкретным тестировщиком: насколько быстро реагирует на вопросы, хорошо ли описывает шаги воспроизведения бага и т. д.
Думаю, что если вы услышите диаметрально противоположные мнения, то возможно, в команде есть конфликт или напряжённость. На это стоит обратить внимание.
6. Опрос методом 360
Это отличный инструмент оценки и не только оценки.
Моя практика. Мы проводим такой опрос по запросу. Он даёт полноценную картину по компетенциям, которыми должен обладать сотрудник. По нему составить ИПР будет намного проще. Вероятность ошибки про такой оценке минимизируется.
Из нюансов: метод достаточно дорогой и длительный. В среднем организация опроса, сбор данных, их обработка и интерпретация занимает около месяца. Мне кажется, что нет необходимости проводить опрос методом 360 для каждого сотрудника. Я использовала бы его только для перехода на какую-то новую позицию, например из QA в тимлиды.
7. Личная оценка
Здесь я анализировала работу сотрудника как минимум последний квартал. Обращала внимание на:
Количество дефектов, которые остаются после проверки фичи.
Скорость выполнения задач в зависимости от их сложности.
Выполнение нетипичных задач: достаточно ли у сотрудника навыков и знаний, чтобы взяться за задачу, которую он ещё ни разу не делал.
Написание чек-листов на фичи и их покрытие тест-кейсами.
Коммуникацию с сотрудником.
Если вы хорошо ведёте таск-трекер, то можно оценить работу с помощью графиков и диаграмм. Но не все любят, когда им приносят графики, поэтому тут лучше ориентироваться на сотрудника. Можно просто посмотреть часть задач подробно, в том числе почитать комментарии к ним.
8. Внешний аудит
Существуют компании, которые проводят оценку сотрудников.
Моя практика. Лично я в тематике данной статьи отношусь к ним скептически, потому что оценку нужно будет проводить с завидной регулярностью, а это долго и дорого. Этот инструмент скорее подходит для повсеместной оценки каждого сотрудника, а не для подготовки ИПР и работы с ним. Поэтому у меня опыта работы с такими компаниями нет. Но такой вариант оценки тоже существует, вдруг он подойдёт кому-то из вас.
Второй шаг: оценка ресурсов
На этом шаге я оценивала, что у нас есть для составления ИПР и его дальнейшего выполнения. Здесь всё очень зависит от возможностей компании, но вот что прикидывала я:
Время сотрудника на выполнение дополнительных задач.
Бюджет на обучение.
Есть ли ментор для сотрудника.
Время сотрудника на выполнение дополнительных задач. Важна не только личная заинтересованность тестировщика в развитии, а ещё и то, какую часть его рабочего времени вы можете выделить на обучение. Если в команде случается асап за асапом, то, конечно, выкроить часы на длительное регулярное обучение не выйдет. Поэтому важно точно определить максимум времени в неделю на дополнительные задачи, чтобы основная работа не просела.
Моя практика. С одним сотрудником мы договорились, что среда — это день, в который я его не трогаю, и он может спокойно заниматься задачами по автоматизации. С другим — что он забьёт себе в календарь слот с 10:00 до 11:00, чтобы заниматься задачами из ИПР. Вариантов может быть много.
Бюджет на обучение. У нас есть отдельный бюджет на обучение каждого сотрудника. Поэтому я оценивала, сколько средств мы можем дать на полезные курсы, мастер-классы или конференции.
Есть ли ментор, который может поработать с сотрудником, кроме меня. Это позволяло сэкономить моё время, а заодно давало сотруднику возможность поработать с профи именно в среде тестирования. Я ходила к потенциальному ментору и спрашивала, есть ли у него возможность, силы и желание.
Третий шаг: задачи для развития
Здесь я уже примерно представляла свои карты на руках: уровень специалиста, рекомендации для него от коллег и имеющиеся ресурсы. Пришло время подумать, какие задачи я могу дать сотруднику для развития.
Следует понимать, что развитие ради развития полезно только для вашего коллеги. Его знания, развитие и опыт должны приносить профит компании. Поэтому хорошо, если человек сможет применить новые практики в работе, чтобы принести результат команде.
Чтобы выбрать задачи для развития тестировщиков, я анализировала:
Долгосрочный план развития команды.
Бизнес-задачи, которые стояли перед компанией и командой.
Как мы оцениваем качество продукта.
Как обстоят дела с написанием тест-кейсов и их автоматизацией.
Насколько у нас прозрачный и понятный процесс тестирования, на каких этапах есть проблемы. Что бы мне хотелось от тестировщиков в идеальной картине мира.
Как быстро мы готовим релиз, и устраивает ли нас это время.
В каждом пункте оценивала, сможет ли тестировщик сделать что-то для выполнения одной из задач или повлиять на показатели в лучшую сторону. Итоговые задачи должны помочь прокачать уровень сотрудника. Не стоит заваливать его очередной рутиной из серии «дописать ещё 1000 новых тест-кейсов к существующим», если человек и до этого прекрасно справлялся с написанием тест-кейсов.
Как только появляется список задач, план развития приобретает осязаемый вид.
Моя практика. У нас в команде был успешный кейс, когда QA Manual взяла на себя роль скрам-мастера, помогла наладить процессы в команде, установить требования к задачам и т. д. В конечном итоге скрам захватил её полностью, и она продолжила развитие в этом направлении. Конечно, как команда мы потеряли тестировщика, но я рада, что человек нашёл себя. К этому надо быть просто готовым, и вовремя искать замену, если понимаете, что время подходит.
Но что делать, если задач для роста нет? Если в вашей команде расти некуда, стоит подумать о переводе сотрудника в другую команду. Моя команда занимается разработкой десктопных продуктов. За 6 лет было несколько случаев, когда тестировщики вырастали из наших задач: их уровень был уже значительно выше, чем задачи, которые я могла им предложить. Мы по возможности предлагали таким ребятам вакансии в бэкенд-командах. Например, один из тестировщиков с позиции QA Automation стал Scala-разработчиком.
Для ребят это были новые знания и новые задачи. Для компании — возможность сохранить отличных сотрудников и закрыть вакансии в других командах внутренним переводом.
Четвёртый шаг: подготовка сотрудника
Развитие — это в первую очередь инициатива со стороны сотрудника. Очень важно, чтобы со своей стороны коллега тоже проделал работу. Я просила тестировщиков записать к нашей встрече ответы на следующие вопросы:
Что бы ты сам хотел прокачать?
Чего тебе не хватает, чтобы быть эффективнее в нашей команде?
Какие задачи тебе наиболее интересны?
Какие профильные конференции/курсы/книги тебе могут понадобиться?
Моя практика. Достаточно частый кейс, что QA Manual интересуются позицией QA Automation. QA Automation — это больше разработчик. QA Manual, особенно на фронте, — это в первую очередь человек, который знает принципы работы продукта, умеет аналитически прорабатывать каждую фичу, думать о механике её работы и бизнес-логике.
Между этими специалистами огромная разница. Когда ко мне как к тимлиду приходят с таким желанием, я разбираюсь вместе с сотрудником в этой разнице, и ищу реальную причину желания стать автоматизатором. У меня был случай, что за таким желанием была просто неясность, куда расти дальше. И был успешный кейс перехода на позицию QA Automation.
Пятый шаг: встреча один на один
Подошёл момент согласования ИПР. Эта встреча обязательно должна быть подготовленной. К этому моменту у меня уже был примерный план развития для сотрудника, а саму встречу я поделила на следующие этапы:
Обозначить цель встречи — обсудить и согласовать ИПР.
Узнать, что хочет сам сотрудник. Ведь игра в одни ворота бесполезна.
Спросить об идеях для команды, что сотрудник хотел бы поменять. Обязательно слушайте, записывайте.
Дать обратную связь по работе сотрудника. Вы делали оценку, можете смело рассказать как о сильных сторонах, так и о точках роста.
Показать свой вариант ИПР и аргументировать каждый пункт.
Момент творчества: сопоставить свой подготовленный план с желаниями и планом сотрудника.
Вместе заполнить ИПР. Зафиксировать цель, план, задачи и сроки. Я составляла с каждым тестировщиком таблицу. Она помогает подтвердить, что мы правильно друг друга поняли. Сроки я предлагала выбрать самому сотруднику, чтобы он сам их оценил. Это не строгие дедлайны, а точки контроля для ориентира.
Назначить следующую встречу для трекинга результата. На ней вы обменяетесь мнениями и сможете скорректировать ИПР.
Результат всех шагов
В результате у меня был ИПР для сотрудника и возможность отслеживать результат. И мне и сотруднику становилось понятно: что, в каком порядке, зачем делать, и какой результат мы ожидаем. И тимлид, и сотрудник заинтересованы в реализации такого плана, потому что согласовали его вместе.
По ссылке на Google Docs вы найдёте пример того, как может выглядеть ИПР. Возможно, эта структура будет полезна вам и вашим сотрудникам.
Итог
Задача с развитием тестировщиков решена. Надеюсь, я сэкономила время на поиск этой информации, и у вас уже есть идеи, как подступиться к аналогичной задаче в вашей команде.
Это решение в любом случае должно адаптироваться под вашу ситуацию, а также дополняться своими способами оценки, задачами, и возможно, новыми шагами.