как разнородные задачи было в корне неверно, и мы не могли решить ни одну из проблем. Улучшение команды тестирования стало бы всего лишь временным успехом.
Но все-таки положительные сдвиги начались. Полезно нанимать умных людей – они могут сами исправить ситуацию. К 2007 году позиции дисциплины тестирования укрепились. Мы неплохо справлялись с завершающей фазой цикла выпуска. Команды разработки знали, что могут рассчитывать на нас как на партнеров в производстве. Правда, наше существование как команды поддержки позднего цикла ограничивало нас рамками традиционной модели контроля качества. Несмотря на неплохие результаты, мы все еще не достигли состояния, в котором я хотел бы оказаться. Я разобрался с проблемой найма, тестирование двигалось в нужном направлении, но мы все еще слишком поздно включались в процесс.
Наша концепция «Тест-сертификации» делала успехи (вы прочитаете про нее дальше в книге). Мы общались с командами разработчиков и помогали улучшить чистоту кода и внедрить юнит-тестирование на ранней стадии. Мы разрабатывали инструменты и обучали команды основам непрерывной интеграции, чтобы наши продукты всегда были готовы к тестированию. Бесчисленные мелкие усовершенствования и приемы, многие из которых описаны в книге, развеяли скептицизм. Тем не менее чего-то не хватало. Разработка все еще была разработкой, а тестирование так и оставалось тестированием. Все ингредиенты для изменения культуры присутствовали, но нам был нужен катализатор, который смог бы запустить объединение дисциплин.
Глядя на организацию, которая выросла из моей идеи о привлечении разработчиков на позиции тестирования, я понял, что тестирование было лишь частью нашей работы. У нас были команды, которые создавали все инструменты – от репозиториев исходного кода до инфраструктуры для багтрекинговой системы. Среди нас были инженеры по тестированию, инженеры по выпуску продуктов, разработчики инструментов и консультанты. Меня поражало, как сильно тот аспект нашей работы, который не являлся непосредственно тестированием, влиял на производительность. Возможно, наша команда называлась «службой тестирования», но наши обязанности были намного шире.
Поэтому я решил оформить все официально и сменил название команды на «направление продуктивности разработки». Смена названия привела к культурному сдвигу. Люди начали говорить не о контроле качества и тестировании, а о производительности. Повышение производительности – наша работа, а тестирование и контроль качества – работа всех, кто пишет код. Это означает, что и тестирование, и контроль качества входят в обязанности разработчика. Команда продуктивности разработки должна заботиться о том, чтобы разработчик мог заниматься этими двумя вещами.
На первых порах идея была абстрактной, а наш девиз «Ускоряем Google» поначалу звучал наигранно. Со временем мы выполнили обещание. Наши инструменты ускорили темпы разработки, мы переходили от одного бутылочного горлышка к другому, расчищали