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

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

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

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

Одна из ключевых причин, почему Google успешен даже с маленьким количеством тестировщиков, в том, что мы редко пытаемся сразу поставить большой набор фич. Как раз наоборот. Мы строим минимально жизнеспособный продукт и выпускаем его в тот момент, когда он может стать полезным как можно большему количеству людей, получаем обратную связь и дальше развиваем продукт итеративно. Так мы действовали с Gmail, у которого ярлык «бета-версии» сохранялся четыре года. Мы предупреждали пользователей, что продукт все еще дорабатывается. Ярлык «бета-версии» мы убрали, только когда достигли поставленной цели в 99,99 % нормальной работоспособности почты. По той же схеме мы работали с Android при выпуске G1 – продукта, получившего хорошие отзывы. Он был улучшен и обогащен новыми фичами, когда выходил для линейки телефонов Nexus. Важно помнить, что ранняя версия, за которую платят пользователи, должна быть достаточно функциональной и полезной для них. То, что версия является ранней, еще не означает, что она должна быть слабым продуктом.