Home

Оригинальная публикация

Меня зовут Антон Морозов, я инженер по тестированию в Яндекс 360. Я работаю над мобильным Яндекс Диском — это проект с тысячами тест-кейсов, который развивается уже тринадцатый год. 

Погружение в продукт и новую команду — непростая задача для новичка, но нам удалось выстроить безболезненную адаптацию (отток за 4 года составил 0%). В статье поделюсь практиками в команде QA, которые помогли нам за последние четыре года успешно адаптировать новичков.

Небольшие дисклеймеры перед прочтением статьи

1. Статья — наш личный опыт, который сработал конкретно в нашей команде. Эти практики не волшебная таблетка, а то, что работает конкретно у нас.

2. У нас есть общекорпоративный процесс адаптации, погружение в культуру компании, отдельные курсы для новичков. Команда Яндекс 360 делает собственные мероприятия для знакомства новичков, а руководитель готовит план адаптации. В статье речь пойдёт о более прикладных советах, которые помогут быстрее погрузиться в продукт.

Специфика работы тестировщиков в мобильном Диске

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

Сложность продукта. Со стороны может показаться, что в проекте всё просто: есть клиент, сервер и база, которые взаимодействуют между собой. Но на деле всё устроено сложнее.

Пример: пользователь хочет поделиться фотографией. Это можно сделать из раздела «Файлы» или «Фото», блока ленты или фотоподборок, просмотрщика фото или альбома, по публичной ссылке, из папки с общим или read-only-доступом, из раздела «Офлайн» и из семейного фотоальбома, где фотография может принадлежать аккаунту члена семьи. При этом фото может быть облачным, облачно-локальным или полностью локальным — в каждом случае будут свои особенности.

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

Наследие. Если проекту больше пары лет (например, мобильному Диску уже 12 лет), скорее всего, в нём есть особенности, с которыми никто из команды не может разобраться. Такие элементы обычно объясняются фразой: «Так исторически сложилось». Самое плохое в наследии — это либо очень важная, либо очень сложная штука. Всё понятное и простое уже много раз меняли, а сложное так и остаётся нетронутым.

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

1. Понять, проблема в приложении или библиотеке.

2. Решить, как приоритизировать проблему.

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

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

Разноплановые задачи. В QA-команде Яндекс Диска у нас нет жёсткого разделения по зонам ответственности. У нас не скучно, и работа не ограничивается только написанием автотестов и выкаткой релизов. 

Тестировщик может делать следующие вещи:

• Прорабатывать и тестировать фичи.

• Проводить регрессионное тестирование, разбирать и актуализировать бэклог.

• Писать кейсы на новую фичу или актуализировать кейсы старых фич.

• Писать документацию.

• Писать код для автоматизации: будь то оптимизация процессов или инструменты для тестирования — мы уделяем этому много времени. Если не умеете — научим.

• Выстраивать процессы — например, проведения ретро или планирования.

• Готовить доклад на конференцию или писать статью.

В нашей команде работают T-shaped-специалисты, которые умеют подхватывать любую часть процесса. Это снижает вероятность, что всё будет завязано на одном сотруднике: система не ляжет из-за отсутствия конкретного человека, потому что его легко заменит другой специалист. 

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

Далее расскажу, что помогает нам эффективно онбордить новых тестировщиков — за последние четыре года отток в команде составил 0%. 

Почему онбординг — это важно

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

Продуктивность команды тоже чуть снизится вначале, потому что ресурсы будут уходить на вовлечение человека. И это нормально. Состояние и команды, и новичка будет похоже на эту модель развития по Такману: 

1. Выбираем бадди для новичка и планируем ежедневные встречи 

С адаптацией нового сотрудника поможет бадди — это опытный сотрудник, который погрузит в процессы и ответит на все вопросы. Хорошего бадди можно найти по нескольким параметрам:

1. Он сам хочет стать наставником и помогать новичкам.

2. Будущий бадди достаточно опытен, он самостоятельно делает задачи. Важно, что наставник не самый опытный сотрудник, потому что иначе у него может просто не быть времени, а достаточно опытный.

3. У бадди есть время на помощь в адаптации новичка без ущерба для своих задач.

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

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

Для ответа на эти вопросы у нас есть подготовленная документация. Как и у всех, из-за постоянных изменений не вся будет актуальной — но мы стараемся поддерживать её в таком виде. 

Вот почему нужен бадди: 

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

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

• Ежедневные вопросы из разряда «Есть ли трудности?» убирают барьер, когда страшно показаться глупым. У специалистов бывает такое заблуждение: раз нанят на синьорскую позицию, значит, должен знать всё. Если его проработать, новый сотрудник будет задавать больше вопросов, что полезно для всех.

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

2. Погружаем в продукт через кейсы бизнес-логики

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

Наши тест-кейсы разделены на три большие группы:

1. Аксептанс — расширенные смоки, самые базовые проверки крупных фич.

2. Регресс — широкий перечень проверок всего и вся, вплоть до самых мелких.

3. Бизнес-логика находится примерно посередине как по покрытию проверок, так и по количеству кейсов на проекте.

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

Вот несколько примеров кейсов бизнес-логики для новичков: 

• Просмотр видео в режиме офлайн

• Очистка места, когда удаляемые фото находятся на SD-карте и в памяти телефона

• Формирование блока в ленте, если кто-то предоставил пользователю доступ к папке

3. Предлагаем новичку решать разные задачи 

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

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

Вот какой у этого эффект:

• Ускоряем темп погружения, выдавая весь объём информации. А ежедневные встречи и поддержка команды помогают контролировать моральное состояние специалиста: можно быстро отреагировать и скорректировать нагрузку, чтобы не допустить выгорания.

• Получаем универсального сотрудника. Да, не всегда новые знания усваиваются достаточно хорошо с первого раза. Но лучше сразу познакомить человека с задачей, чем ждать подходящего случая и откладывать это на неопределённый срок.

Конечно, важно на этом этапе следить за загрузкой специалиста и вовремя подать ему руку, если это потребуется.

4. Вовлекаем в адаптацию всю команду

Каждый новичок регулярно встречается с руководителем и ежедневно — с наставником. Однако все остальные участники команды тоже не стоят в стороне.

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

Период «притирки» мы сокращаем за счёт 1–1 встреч нового специалиста с каждым участником команды.

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

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

Общий объём информации, которую мы передаём во время адаптации, делится на всех сотрудников. Каждый рассказывает об инструменте или той области профессиональной деятельности, в которой он более экспертен. 

5. Настраиваем отношения со смежниками

Тестировщику из мобильного Диска нужно уметь общаться со специалистами из соседних команд. Для понимания приведу пример:

Часть функционала мобильного приложения реализована в WebView — этим занимается команда фронтенда. Мы обнаруживаем, что поведение отличается от ожидаемого, при этом с нашей стороны разработчики говорят, что ошибок нет. Для решения проблемы нужно вместе с разработчиком из команды фронтенда локализовать баг и пофиксить его на стороне фронтенда.

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

В идеальной картине мира весь период адаптации выглядит как-то так: 

Короткий чек-лист по адаптации новых сотрудников 

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

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

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

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

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

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

• Ведите документацию и фиксируйте процессы, чтобы уменьшить затраты ресурсов команды.

Расскажите, а каких практик придерживаетесь вы в командах при онбординге новичков? Что работает, а что нет?

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

Обсудить в форуме