В 1980 году я устроился на работу программистом в компанию Manufacturing Data Systems (MDSI) – одну из самых успешных технологических компаний в истории Анн-Арбора. Я все еще учился в колледже Мичигана, так что, пока не закончил учебу, работал неполный день. В MDSI я попал в окружение отличных людей, включая маму Ларри Пейджа[38], Глорию, которая работала там программистом, а также Томаса Нолла[39], который продолжал создавать свой Photoshop.

Это были бурные времена для нашей отрасли, и компания MDSI запустила замечательную программу привлечения стажеров в тот год, когда я сам туда устроился. В MDSI нас обучили кое-каким дисциплинарным стандартам кодирования, которые я помню по сей день. Одним из самых необычных, но впечатляющих был стандарт, который сегодня назвали бы разработкой через тестирование. Говоря простым языком, это означает, что программисты пишут автоматизированные тесты для будущего кода, затем – сам код, а в конце запускают тесты, чтобы убедиться, что с кодом все в порядке.

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

После завершения той летней стажировки молодых программистов в MDSI я получил назначение в другой отдел, а также четкие указания моего нового босса забыть о принципе разработки через тестирование, потому что у нас есть реальная работа. Я бы больше так и не встретился с этим методом, если бы Кент Бек и Мартин Фаулер не представили вновь данную концепцию миру программирования в 2000 году в своей книге «Рефакторинг»[40].

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

Гастроном Zingerman’s[41] имеет собственную версию систематической проверки качества. Там диспетчер магазина каждый заказ повторяет клиенту. Когда вы размещаете заказ, его зачитывают вам для подтверждения. Когда вы оплачиваете его, кассир делает это еще раз. Когда заказ привозят к вашей двери, его состав зачитывают вам в третий раз, чтобы подтвердить, что вы получили правильный набор продуктов. Каждый сотрудник Zingerman’s поступает так всегда. Вы можете себе представить, какое хорошее мнение о компании создает такой подход у клиентов? Он не улучшает качество самих продуктов (для этого есть другие процессы), но он поддерживает уровень удовлетворенности покупателей на самом высоком уровне. Очень просто упустить очевидные ответы на серьезные вопросы, касающиеся качества.

Еще одной классической проблемой, особенно для команд разработчиков ПО, является то, что система собирается вместе из маленьких несвязанных кусочков, представляющих собой результат работы многих сотрудников. Где-то ближе к концу проекта начинают летать искры, когда все кусочки наконец-то собираются вместе. Такая интеграция обычно становится катастрофой последнего этапа работы и никогда не бывает предусмотренной в плане проекта. Руководители, не являющиеся «технарями», не могут даже понять, что вдруг произошло в их многомиллионном, чрезвычайно важном проекте.

Во избежание этого кризиса последней стадии сборки системы все наши сотрудники в Menlo делают проверки, постоянно соединяя части, над которыми они работают. Благодаря этому мы никогда не сталкиваемся с неприятными сюрпризами на последнем этапе. Если при соединении фрагментов возникают проблемы, мы находим их, пока у нас есть на это время и бюджет. Если же подобная попытка собрать все вместе происходит впервые в самом конце проекта – как это бывает у большинства разработчиков ПО, – команда не может справиться с неизбежной катастрофой последнего этапа. Руководители отменяют проект и распускают сотрудников. Я не знаю всю подноготную проекта Ford Everest, стоившего 400 миллионов долларов, но легко могу допустить, что причиной его сворачивания была именно проблема сборки частей системы в одно целое. Каждый год десятки миллиардов долларов в нашей отрасли тратятся впустую на проекты, которые никогда не выйдут в свет.

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

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

Лучший известный нам способ постоянного испытания нашей системы на прочность – поделиться своей работой с клиентами. Мы посвящаем их в подробности наших процессов тестирования и объединения, мы позволяем им проводить эксперименты на многих этапах, так что по завершении работы они знают о ее качестве не понаслышке.