Всем привет! Меня зовут Дмитрий Нозадзе и я - QA-лид агентства по тестированию “Кавычки”. На рынке мы уже 11 лет, поэтому историй и опыта накопилось немало. Поэтому сегодня немного о том, что делать лиду, если приходится объединять тестирование и управление , и вообще, стоит ли это делать?

Ннннеее нннада!

На этом, пожалуй, бы и закончилась моя статья сегодня, если бы я следовал всем советам из интернета. Ведь в 80 (ну может в 90) процентах случаев советуют не раздваиваться и работать только на одну точку - либо тестирование, либо управление. Говорят, что попытка успеть везде и сразу может привести к негативным результатам и прочим бедам (возможно, даже с головой). 

Что ж, в этом есть доля правды, когда ты ведешь не один проект, а несколько или если этот проект - первый твой опыт в роли лида. 

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

Предыстория

Итак, было дано: молодой амбициозный лид в моем лице, жаждущий славы и мирового признания, несколько проектов, ждущих своего “вожака” и несколько команд, чьи "стаи" мне предложено было возглавить. Не ожидая подвоха и лучась готовностью, я согласился взять все, не зная еще, что на одном из проектов придется выполнять роль тестировщика.

Всего было 4 команды, 5 тестеров и я (прямо трое в лодке, не считая собаки). На трех проектах процессы были выстроены, но на одном формировалась полностью новая команда, и поэтому это потребовало больше внимания и сил, чтобы качество тестирования не просело. 

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

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

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

ПОЭТОМУ, СОВЕТ № 1: 

• Не беритесь за несколько проектов ОДНОВРЕМЕННО (ключевое здесь слово), увеличивайте нагрузку постепенно, если проекты для вас новые и вам нужно погрузиться. 

• Оцените ситуацию проектов, на которых будете работать. Если вы понимаете,  что какой-то из них потребует больше времени и концентрации, то:
  

  • выделите с чем столкнетесь и, где могут быть слабые места

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

  • если есть возможность взять проверенного человека, на которого можно положиться и делегировать - возьмите ????
    

При-о-ри-тет! 

Итак, у меня сформировалась новая команда и новый проект, а еще я отвечал за тестирование дополнительного проекта. Ожидаемый итог - времени стало не хватать. От меня постоянно что-то хотели, что приводило к стрессу и выгоранию: на одном проекты ждали срочные задачи, отданные в тестирование, на другом моего внимания требовал релиз. Тестировщики приходили  за помощью или с проблемами, плюс нужен был контроль ( ранее я упоминал, что для людей проект был новый). В общем, дом вверх дном.  Казалось, что рабочего дня не хватает и нужно еще пару часов в сутках, чтобы все успеть. Конечно,  голова была забита нерешенными вопросами на проектах и как всё успеть. 

Тут, наверняка, кто-то скажет: “Ну так выставил бы приоритеты!”. И этот кто-то точно на опыте и абсолютно прав.

Отсюда у нас совет намбер 2 

Выстраивайте приоритет! 

Очевидно, но факт! Очевидно, но не забудьте! Очевидно, ну вы поняли! ПРИ-О-РИ-ТЕТ!

Например: 

• для тестирования  - можно обсудить процесс релизов и взятия задач в работу так, чтобы между ними был зазор. Или учитывать в планировании занятость на другом проекте. 

• для команды создать флоу и выстроить взаимодействие, чтобы большая часть вопросов, не требующая вашего внимания, решалась без вас. А то, что без вас решить/обсудить невозможно - зафиксировать в чёткие созвоны и встречи. Таким образом, вы даже высвободите время для развития своих сотрудников, а задачи не будут перекрывать друг друга. Тем самым из хаоса создаем порядок и исключаем лишнюю занятость, которая может решаться без вас. 

Примечание для особо чувствительных :) : У читателя может возникнуть вопрос: “Какая принцесса попалась,что под ее занятость должны подстраивать флоу?”.

И таки - да, стараемся как можем, корона не давит:) Но проект и заказчик сами озвучивали, какая занятость им нужна и соглашались на формат сотрудничества. 

Дьявол кроется в мелочах

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

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

Другие два проекта были стабильные, но дьявол кроется в мелочах. Чуть загляделся и все, санки, уехавшие по инерции с горки, без контроля и участия, уже валяются в лесу, становятся собственностью волков, а вы грустно наблюдаете за этим и думаете: “Ну что такое-то, нормально же общались”. А тут еще один из тестировщиков заболевает, уходит в отпуск, сбегает от жены на круизном лайнере и оказывается, что вам только казалось, что у вас большие выразительные глаза. Они могут становится еще больше и выразительнее - ведь именно в этот момент оказывается, что этот самый сотрудник - практически духовные скрепы проекта и википедия в одном лице. 

Вся стабильность проекта только что пала, вместе с вами. Как говорится, помянем. 

Так что же делать? 

Принимать совет номер 3.

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

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

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

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

• А также привлекать тех,  на кого вы можете положиться ( я знаю, что вы это где-то видели:) 

Так можно или нельзя?

А что же с тестированием? Мы всё говорим про менеджмент, но как успевать и не просаживаться в тестировании, погружаться в задачи и следить за тестовой документацией? А тут все будет быстро и по делу. Даже не будем называть это советом, так, легкое наставление на путь грядущий: 

• всегда коммуницируйте с командой, особенно когда вы - тестировщик ( а это звучит гордо!), озвучивайте свою нагрузку, старайтесь оценивать ее адекватно,  чтобы лучше определять приоритет и не взваливать всё на себя. И если всё - таки нагрузка растет (зараза такая) доносите, что ваших сил не хватает. 

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

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

ИТОГО, мы имеем: 

• Со временем получилось распределить и декомпозировать нагрузку и не выгорать

• Стабильные проекты не просели, а даже набрали обороты и один из них был продан западному клиенту 

• Новый проект был запущен и были выстроены процессы (но было еще много работы впереди)

• Микро климат в одной из команд был запущен и, к сожалению, один из тестеров ушел

• Развитие и выделение времени на личные вопросы сотрудников происходило в меньшем объеме, чем требовалось

А из того, что мы имеем, еще пара советов сверху:

• Наращивайте нагрузку постепенно, с учетом вашей погруженности в проект

• Старайтесь не брать больше 5 команд в управление

• Выстраивайте команду с учётом погруженности и самостоятельности (это облегчит вам жизнь при любых обстоятельствах)

Все! Всем спасибо!