Управление «пиратским кораблем» для чайников Джеймс Арбон

Управление «пиратским кораблем» для чайников

Джеймс Арбон

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

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

Руководить инженерами означает самому быть пиратом, но знать чуть больше о том, что лежит за горизонтом, какие корабли проплывают поблизости и какие сокровища томятся в их трюмах. Другими словами, это означает управлять с помощью своего технического видения, обещать волнующие технические приключения и интересные порты для стоянок. Технические руководители в Google всегда должны держать нос по ветру.

В Google есть несколько типов руководителей и менеджеров.

— Ведущий инженер (Tech Lead). Эти ребята появляются в больших командах, где много разработчиков в тестировании и тестировщиков работают над большим проектом с общими техническими проблемами и инфраструктурой. Они встречаются в командах, которые занимаются инфраструктурами, не зависящими от продукта. Обычно ведущие инженеры не управляют людьми. К ним инженеры обращаются с техническими проблемами или вопросами по тестированию. Часто это неформальная роль, которая выделилась естественным образом в процессе работы. Ведущий инженер всегда сосредоточен только на одном проекте.

— Технический менеджер (TLM, Tech Lead Manager). Это удивительное создание рождается, когда человек, к которому обращаются по техническим вопросам, еще и официально руководит командой инженеров проекта. Технические менеджеры очень уважаемы и влиятельны. Обычно они тоже работают только над одним важным проектом.

— Тест-менеджер (Test Engineering Manager). Те, кто координирует инженерную работу нескольких команд, называются тест-менеджерами. Почти все они выросли из рядовых сотрудников. Можно сказать, что эта роль в Google — аналог принятой в индустрии роли тест-менеджера, но с более широким полем действий, типичным для директоров в других компаниях. В их полномочиях выделять и забирать ресурсы тестирования на проектах. Обычно у них в подчинении от 12 до 35 человек. Тест-менеджеры распределяют людей между командами, регулируют совместное использование инструментов и процессов и рулят процессом поиска, собеседований и найма людей.

— Директор по тестированию (Test Director). У нас несколько таких директоров. Они немного координируют работу нескольких тест-менеджеров, а по большей части работают над общей перспективой тестирования, стратегическим управлением и иногда — преобразованиями в технической инфраструктуре и методологиях тестирования. Все-таки основное направление их работы — следить, как влияет качество тестирования на бизнес: анализ затрат, анализ эффективности и т.д. Их работа развернута наружу — показывать результаты другим. У директоров по тестированию обычно от 40 до 70 подчиненных. Каждый из них закреплен за отдельным направлением: Client, Apps, Ads и т.д.

— Старший директор по тестированию (Senior Test Director). Такой человек у нас один — Патрик Коупленд. Он отвечает перед высшим руководством компании за единообразие должностных инструкций, найм, внешние взаимодействия и общую стратегию тестирования в Google. Это его работа — распространять передовые практики, создавать и продвигать новые начинания, например инфраструктуру глобальной сборки или тестирования. Статический анализ и задачи по тестированию, которые касаются всех продуктов Google, пользовательские проблемы и база тестового кода — все это лежит в ответственности старшего директора по тестированию.

Большинство тех, кто работает в тестировании в Google, особенно директора и даже сам Патрик Коупленд, участвуют в поиске и наборе людей. Есть несколько подводных камней, на которые мы натыкаемся во время собеседований. Например, большинство кандидатов отлично знают компанию, ее основные технологии и то, что это отличное место для работы. Инженеры очень осторожны на собеседовании: они опасаются показать свое волнение и не пройти отбор. Хорошие кандидаты и так работают в хороших условиях, и их беспокоит сильная конкуренция внутри Google. Часто можно развеять все опасения, если интервьюер представится и расскажет немного о себе. Инженеры в Google, безусловно, профессиональные и воодушевленные. И все же большая часть того, что заставляет их работу выглядеть такой интересной и даже героической, ­— это просто грамотное использование коллективного разума сообщества инженеров-единомышленников и технических мощностей Google.

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

Давайте отметим основные аспекты работы руководителей тестирования.

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

— Переговоры. Невозможно постоянно заниматься только тестированием. Руководители разработки постоянно требуют ресурсов и внимания тестирования, поэтому тест-менеджеры должны уметь вежливо и обоснованно отказывать.

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

— Стратегические инициативы. Менеджмент тестирования часто спрашивают, что еще такого можно сделать в Google, чего нельзя сделать нигде больше? Как мы можем расширить свою тестовую инфраструктуру и поделиться ею, чтобы улучшить интернет в целом, а не только наш продукт или компанию? Что будет, если мы объединим наши ресурсы и возьмемся за долгосрочные проекты? Поддержка таких инициатив идеями, финансами и защитой от натиска команд, желающих срочно заполучить тестировщика, — это работа, требующая огромной отдачи.

— Аттестация и оценка персонала. Чтобы оценивать своих сотрудников, менеджеры в Google опрашивают всех участников команд. Результаты сравнивают между командами, чтобы выровнять их. Всех сотрудников Google оценивают раз в квартал. Мы делаем упор на то, что человек сделал за последнее время и как он повлиял на качество продукта, что он сделал для команды и для пользователей.

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

Оценивая людей таким способом, мы выявляем и поддерживаем ребят, которым пора сменить специализацию на более подходящую. Перемещения происходят постоянно и во всех направлениях. Чаще всего инженеры по тестированию переходят в разработчики в тестировании, а разработчики в тестировании — в разработчики. Ребята прокачиваются технически и специализируются на своих новых интересах. На втором месте — перемещения из роли разработчика в тестировании на роль инженера по тестированию и из роли инженера по тестированию на роль руководителя проекта. Это легко объяснить тем, что людям надоедает целыми днями программировать и хочется расширить поле деятельности.

Руководители помогают людям устанавливать ежеквартальные и годовые OKR.[46] Они следят за тем, чтобы цели ставились высокие и амбициозные, поощряют людей метить высоко даже при краткосрочном планировании. Менеджеры следят, чтобы цели отвечали способностям и интересам инженеров и не конфликтовали с требованиями проекта и бизнеса.

Управлять тестированием — значит находить компромиссы и прислушиваться к каждому человеку. Управлять в Google — значит направлять и опекать своих людей, а не командовать ими. Возвращаясь к аналогии с пиратами: хороший руководитель обеспечивает семь футов под килем и попутный ветер.