Привет, Хабр! Меня зовут Ваня, я — QA-лид в компании аутсорс — тестирования «Кавычки».

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

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

У лидов тоже болит, и лечится это по-разному. Кстати, в основном опытом и граблями. Первый вариант — не самый быстрый, а второй — не самый приятный. В общем, либо долго, либо больно. Я хочу попробовать сократить твой путь и поделиться советами, которые помогают мне решать проблемы и боли лидов. Пригодится — супер. Не пригодится — не супер. А если у тебя тоже есть лайфхаки или «советы бывалых», то смелее подсыпь их в комменты.

Боль 1: а что дальше? (спросили они с тревогой в голосе)

«Ну что, гуд лак, парень. Вон та команда, да-да, та что покрасивше и побородатей, теперь твоя. Дай пожму твою мужественную руку!», — сказал руководитель и ушел в закат.

Дышим ровно, не показываем страх (они все чувствуют). Держимся так, будто выиграли Кубок по квиддичу.

• Итак, ты попал на новый проект и в новую команду. Первый и самый важный твой шаг — встретиться с сотрудниками. Лучше всего провести one-to-one встречи, чтобы выяснить компетенции людей: куда они двигаются, что им интересно, в чем они сильны. По итогу встреч нужно составить карточки сотрудников.

• Встретиться с руководством и с заказчиком. Здесь важно на берегу выяснить: какая ответственность на тебе лежит, как заказчик видит работу и конечный результат. Потому что оценка происходящего у каждой стороны может быть разная. Поэтому ее нужно привести к единому пониманию.

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

• Разобраться с техническими вводными: покрытие тестами, есть ли автотесты на проекте, нужны они или нет, какие критерии качества выставлены. И, конечно, нужно поковыряться в процессах: что происходит на проекте, как ставятся задачи, есть ли коммуникация с командой разработки и как она ведется, как сдавать отчеты (вообще есть ли они, эти отчеты, нужны ли они и пр.).

• Проанализировать команду. Важно смотреть на состав команды и сочетание скиллов в ней. Потому что иногда ее приходится усиливать. Если не хватает людей, то нужно нанимать новых, выстраивая процесс найма. При этом не забывай — лучше всего уделять 80% времени сотрудникам, которые приносят 80% результата, развивая их и двигая в нужном направлении.

• Управлять рисками. Есть такая штука как Bus-фактор, и очень важно, чтобы у тебя в команде его не было. Пример Bus-фактора: человек выпал из процесса, и все встало. Поэтому нужно распределять ответственность между людьми — как бы размазать ее планомерно по всем. Плюс давать разные по сложности задачи. Это позволит избежать рутинной и скучной работы для команды, а тебе не придется смотреть им в спины, пока они уходят в закат и светлое будущее от этого вот всего.

Боль 2: найм

Довольно серьезная боль лидов — это найм, потому что не все знают, как нанимать человека и не ошибиться в нем. Что нужно спрашивать на собеседовании и на что смотреть. Это действительно сложно, потому за всего за один-два часа тебе предстоит понять, подойдет ли кандидат в команду, сможет ли работать с другими ребятами, да и вообще, что он за человек такой — адекватный или нет. И кроме этого, тебе еще нужно проверить его хард и софт скилы.

Что делать то:

Сразу скажу, что я не знаю универсального решения. (все, расходимся). Да, и наверное, его просто нет. Я думаю, что здесь у каждого свой подход. Я поделюсь своим рецептом «Альденте найм»:

1. Составь профиль кандидата

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

2. Напиши список вопросов

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

3. Наблюдай за кандидатом

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

(Кстати, про адекватность: как-то наш рекрутер рассказал, что на одном из зум-собеседований кандидат сидел в туалете … Но это, как говорится, уже совсем другая история).

Еще отмечу такой момент: нужно доверять своей чуйке. Если тебе кажется, что человек душный, нелюдимый, странный или еще какая-нибудь диковинка с ним, то скорее всего (прям 90%), тебе не кажется. И он проявит себя в будущем с какой-нибудь стремной ситуацией (оно тебе надо?).

Боль 3: one-to-one встречи 

Очень важно выстраивать доверительные отношения со своей командой, ведь в итоге это влияет на мотивацию, которая в свою очередь отражается на эффективности работы и качестве продукта. Так вот, one-to-one встречи — очень полезная штука, но многие не знают, как их проводить, да и вообще зачем.

Что делать то:

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

Как проводить встречи:

• Большую часть времени  говорит сам сотрудник, а не лид. То есть тебе нужно обсудить вопросы, которые важны сотруднику: его мотивацию, куда он хочется двигаться, что его демотивирует, что не нравится и т.д. Важно общаться не про проект, а про боли и пути их решения (даме — цветы, детям — мороженое, не перепутай). Можно задавать неловкие вопросы, которые вскрывают сложные и важные темы. 

• К встрече определенно нужно готовиться, для этого пропиши некий план и фиксируй то, что вы обсудили — какие-то важные экшен пойнты. Можно также обсуждать карьерный рост, рост зарплаты, перспективы, индивидуальный план развития для сотрудника и др.

 В общем, саммари такое: встречи — очень крутая штука в умелых руках. 

Боль 4: делегирование задач

Девять из десяти случаев человек становится лидом после сеньорства. Например, ты был QA-инженером и все делал ручками аки Золушка, а потом стал лидом. Соответственно, теперь тебе сложно абстрагироваться от того, что нужно распределять задачи и менеджерить, а не выполнять их самому (я сейчас не беру во внимание играющих лидов). 

Многие не умеют отделить себя, считая, что: «как я делегирую эту задачу, ведь я лучше ее знаю и сделаю, я лучше погружен в проект» или еще там чего-нибудь.

Что делать то:

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

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

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

Боль 5: тайм менеджмент

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

Что делать то:

Отталкиваться от текущей ситуации. Например, если у тебя в команде сейчас нет человека, то не надо пытаться вывезти на троих работу, где нужны четверо. Максимально сосредоточься на найме, ходи на собесы и ищи, ищи, ищи человека. Ежели кто-то собрался выгорать, то нужно собрать его обратно — аккумулировать свои ресурсы на его прокачку, сменить задачи и прочее. 

А вот если завал по проектам, и его стало овердофига, то возможно, стоит посмотреть в сторону процессов, — есть ли они вообще:) Подумай, что стоит улучшить, предложи свое видение, например, заказчику — «если вот тут мы отправим флоу к ставке задач или будем сниматься раньше, — вот тогда качество и скорость улучшаться». Главное помните: всегда можно что-то улучшить, придумать или подправить. Достаточно грамотно распределить время и все.

Ну и последняя боль на сегодня (или как пойдет)

Бонус боль: человеческий фактор 

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

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

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

Вот такие вот вам байки от бабайки, лайк, шер, репост и все такое.