Рост команд тестирования - мифы и реальность. Часть 2. Инструмент для оценки риска роста.

Продолжаю публикацию моего выступления на SQA Days 13. Напомню, что это не построчный перевод моего доклада, а его переработанная версия. Одни моменты я просто не успел рассмотреть за 20 минут блиц-доклада, другие - прозвучали в вопросах слушателей, за что вам большое спасибо!

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

Инструмент для оценки риска роста.

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

• Любой рост - это хорошо.
• Больше - значит, лучше.
• Или расти, или умри.

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

1. Зачем мы должны расти?
2. Как мы должны расти?
3. Как сильно мы должны расти?
4. Как много роста мы можем себе позволить?
5. Достаточно ли у нас людей?
6. Есть ли у нас правильные люди?
7. Есть ли у нас процессы найма и обучения?
8. Есть ли у нас адекватные способы оценки и мотивации сотрудников?
9. Есть ли у нас поставленные процессы контроля качества?

Рассмотрим каждый пункт подробнее.

1. Зачем мы должны расти?

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

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

2. Как мы должны расти?

Рост - процесс нелинейный и сложно прогнозируемый. Многое зависит от успеха проекта на начальной стадии: пойдет успешно - будут новые запросы от заказчиков, много новых фич, развитие и новые задачи по тестированию.

Очень многое зависит не только от первого, но и второго тестировщика на проекте:

• когда вы работаете один на проекте, вы упомянутый "тестировщик-снежинка": должны уметь делать многое: в зависимости от проекта, от сбора требований, до написания (хотя бы) простейшей автоматизации и скриптов для нагрузочного тестирования. Рассматривайте второго человека как кандидата на ту область тестирования, в которой необходимы либо дополнительные ресурсы, либо на ту, которая будет развиваться. Банально, но факт: хотите развивать автоматизацию - ищите автоматизатора, нужно еще больше ручного тестирования - берите мануальщика, проблемы с требованиями - воспользуйтесь помощью бизнес-аналитика.
• расссматривайте таких кандидатов, которые могут и вас чему-то научить. Например, если вы сильны в тест-дизайне, то берите автоматизатора. Даже если вы в данный момент занимаетесь только ручным тестированием и вам нужен еще один мануальщик - обратите внимание на то, как ваш потенциальный коллега ищет баги, какие баги он находит (для оценки его навыков можете использовать старую версию вашего продукта как полигон, на котором все баги вам хорошо известны).
• второй тестировщик не должен быть копией вас. Подсознательно, мы стремимся взять похожего на нас. Но для проекта будет полезен взгляд и с другой стороны, помните "идеального руководителя, почему им нельзя стать и что из этого следует" Адизеса: все уметь невозможно, развивайте свои сильные стороны и используйте сотрудничество с другими.
• высока вероятность, что в будущем со вторым тестировщиком вы будете проводить больше всего времени, решая поставленные задачи по тестированию, он станет либо вашим заместителем, либо возглавит, например, отдел "автоматизированного тестирования", и очень важно, чтобы вам было комфортно с ним общаться. Комфортно - не в смысле приятно, а продуктивно и с пользой для проекта.

3. Как сильно мы должны расти?

и

4. Как много роста мы можем себе позволить?

Жил-был замечательный тестировщик Коля. Тестировал он хорошо, даже отлично: заказчик был доволен, разработчики тоже. И вот однажды менеджер проекта Миша предложил: "Коля, ты отлично работаешь, но функционал приложения у нас расширяется, тестировать вручную надо еще больше, а ты у нас один. Давай мы тебе возьмем помощника, а еще лучше, не одного, а сразу трех (что-то подозрительно напоминает). Благо, мы работаем в ста метрах от университета. Наймем трех джуниоров-студентов, замотивируем их стартовой зарплатой, которую им даже после окончания университета по специальности никто не сможет предложить, они будут тестировать, а ты будешь за ними следить ими управлять, да и уму-разуму их обучать."

Коля, недолго думая, согласился. Да вот только вышло все не так, как в сказке менеджера: всему пришлось учить с самых азов, студенты-то Майерса не читали, про задачу о треугольнике, граничные проверки слыхом не слыхивали. Да и повторять каждому приходилось по несколько раз: слишком много нового для них было, а записывать они не научились. А начальство, обижено на Колю: мы-то ему вон сколько помощников выделили, а он совсем плохо работает, багов много пропускает, за весь день даже компьютер не включил, только что-то все рассказывает студентам, травит байки из своей тяжелой работы-жизни. И стал Коля из толкового специалиста унылым менеджером обезьянок, как в слайде презентации или в части первой статьи.

Мораль, выводы? Их несколько. Первое: хоть и мог Коля расти, но сразу трех джуниоров он не потянул. Взял бы одного, обучил, поработал бы с ним несколько итераций в проекте - можно было бы еще одного взять, а потом, как научил второго, можно и третьего. При этом, постепенно, а не сразу, передавая тестируемый функционал джуниорам, по мере изучения ими продукта.

Второе: а был ли смысл брать джуниоров? Проект-то только развивается, растет, и времени растить новичков на перспективу нет: заказчик требует результат прямо сейчас. Вот потом, когда проект разовьется, можно будет и "на перспективу" взять кого-нибудь.

5. Достаточно ли у нас людей?

Рост - это не обязательно привлечение новых людей. Есть "разовые задачи" по тестированию (см. вопрос 1 - делегируем), есть и "внутренние задачи", над которыми нужно работать всем вместе: повышение качества - это задача не только тестировщика, но и всей команды. Например, проведение инспекций кода, ретроспективных митингов, тест-сессии в паре с программистом (см. статью Джеймса Баха). Эти и другие способы позволят вам привлечь на сторону улучшения качества вашего продукта и ваших коллег. Еще возможные варианты - работа с отделом поддержки (если он есть на вашем проекте) и привлечение бета-тестировщиков (например, при тестировании игр).

6. Есть ли у нас правильные люди?

По поводу "правильности", на докладе прозвучало два интересных вопроса, которые мне очень понравились, и я хочу поделиться ими с вами.
Первый - "А если у вас нет правильных людей?" Не может быть абсолютно отрицательного ответа: есть хотя бы один - и это вы :) (Леша Федоров, спасибо за краткую формулировку)
Второй - "Как быть с новичками?". Если у вас есть процессы найма и обучения - вы уже знаете что делать :) Если нету - тогда не берите новичков больше, чем сможете себе позволить, как в примере с тестировщиком Колей.

7. Есть ли у нас процессы найма или обучения?

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

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

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

Но и тут, с технической частью, не все бывает просто. Возможно, вам придется набирать сотрудников на ту область тестирования, в которой требования выше, чем ваши знания в данной области. Как вы можете проверить, что перед вами действительно классный специалист, а не красиво говорящий болтун, прочитавший одну хорошую статью с хабра, или утверждающий, что он в ТОП-100 рейтинга stackoverflow? Обратимся ко второй части курса Grow to Greatness, а именно к Part 4: Hiring Senior Management Team, см. карту памяти.

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

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

8. Есть ли у нас адекватные способы оценки и мотивации сотрудников?

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

9. Есть ли у нас поставленные процессы контроля качества?

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

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