Жонглирование людьми и дирижирование проектами

Жонглирование людьми и дирижирование проектами

Фирменная особенность инженерной работы в Google — возможность поменять проект. Как правило, у сотрудника появляется такая возможность примерно раз в 18 месяцев. Конечно, мы не заставляем людей это делать. Если инженеру нравятся мобильные операционные системы, никто не будет кидать его бороздить просторы YouTube. Такая мобильность позволяет попробовать разные проекты. Многие хотят оставаться на одном проекте годами или в течение всей своей карьеры, другие предпочитают узнать обо всем, что делает Google. Мы просто хотим, чтобы у сотрудников был выбор.

Такая особенность работы на руку тест-менеджеру. Фактически получается, что можно в любое время нанять к себе сотрудника с опытом в разных областях. Представьте, что ваш проект — Google Maps, и вы привлекаете к работе ребят, которые работали с Chrome и Google Docs! То есть вы всегда можете пополнить свою команду инженерами с необходимым опытом и свежим взглядом на ситуацию.

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

Тест-менеджер управляет процессом распределения. Он может размещать вакансии в специальном веб-приложении, которое просматривают инженеры. Переход не требует формального разрешения от текущего или будущего менеджера, и любой инженер после полутора лет работы в Google может свободно сменить проект. Конечно, скорость такого перехода согласовывается, так как она не должна создавать помех дате выпуска или ключевым точкам плана проекта, но с разногласиями по поводу подобных переходов мы еще не сталкивались.[66]

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

Основные приоритеты распределения:

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

— Пожелания нового сотрудника. Обретение работы мечты может сделать его счастливым, а значит, и производительным инженером.

— Потребности проекта. Стратегически или экономически важные проекты иногда получают более высокий приоритет.

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

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

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

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

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

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

Данный текст является ознакомительным фрагментом.