В первые годы существования Menlo мы занимались информационной системой учета больных для отделения трансплантационной хирургии одной из местных больниц. Через несколько месяцев работы над проектом куратор со стороны больницы узнала, что мы работаем в парах. Мы никогда не скрывали этого аспекта, она просто поначалу не обратила внимания. Меня вызвали в ее офис в больнице. «Насколько я понимаю, – сказала она мне, – ваши сотрудники работают по два человека за одним компьютером».
«Да, так и есть. Этот метод называется парным программированием…» Она резко прервала меня и потребовала ответить, платят ли они таким образом обоим программистам. «Да, – заверил я ее, – усилия каждого человека, задействованного в проекте, учитываются в счете на оплату». «Перестаньте так работать», – потребовала у меня заказчица, а потом поинтересовалась, почему мы так делаем.
«Мы работаем так, в парах, по той же самой причине, по которой в вашей больнице врачи работают по двое», – ответил я ей. Моя дочь только что пережила серьезную операцию из-за тяжелого перелома, случившегося во время футбольного матча. Перед операцией к нам зашла пара хирургов, чтобы познакомиться. И анестезиологов оказалось двое, и медсестер тоже. Об этом всём я рассказал моей собеседнице.
«Но здесь на карту поставлена жизнь вашей дочери, потому мы работаем таким образом», – ответила она, пытаясь осадить меня.
«Если в системе, которую мы разрабатываем для вашей организации, – объяснил я, – мы допустим какую-то серьезную ошибку, например неправильно укажем тип ткани для трансплантации, мы можем убить пациента. Качество работы в нашей отрасли настолько же важный фактор, как и в вашей».
Вопрос о парной работе программистов больше никогда не поднимался.
В 2012 году я прочитал рассказ о том, как один из самых талантливых технических специалистов Knight Capital сделал ошибку, модернизируя программное обеспечение сервера, который контролировал автоматизированную торговую систему компании. В течение следующих сорока пяти минут эта техническая ошибка привела к случайной продаже акций на сумму в 7 миллиардов долларов, что стоило Knight Capital более 400 миллионов. Я не могу утверждать, что пара программистов не допустила бы возникновения этой ошибки, но вероятность ее была бы намного ниже. Сейчас программное обеспечение – повсюду. Оно контролирует вашу машину, пассажирские авиалайнеры, ядерные реакторы, банковские и биржевые системы, кофейные магазины… Ошибки в программном обеспечении способны вылиться в серьезные риски для людей, компаний и экономики. Такие же серьезные последствия могут быть у ошибки в любой индустрии, например в вашей. Неправильная патентная заявка иногда стоит компании огромных сумм. Молниеносное решение офицера полиции может привести к смерти его самого или невинного свидетеля.
Работа в парах повышает качество и внимание к деталям, особенно в трудных случаях, при напряжении или усталости. В следующий раз, когда вы подниметесь на борт пассажирского самолета, задайте себе вопрос, как бы вы себя чувствовали, если бы увидели в кабине одного-единственного пилота. Представьте, что капитан самолета обращается по внутренней связи и говорит, что его напарник сегодня позвонил, сказал, что не выйдет на работу из-за болезни, так что он будет управлять самолетом в одиночку. Дальше капитан объяснит, что, несмотря на сложные погодные условия в пункте назначения и тот факт, что он не спал всю ночь из-за заболевшего ребенка, он уверен, что никаких проблем не будет. Я готов поспорить, что пассажиры сразу же начнут думать, как открыть аварийные двери.
Мойте руки
Одна из самых печальных историй о неудачных попытках внедрения новых методов строгого обеспечения качества произошла в середине XIX века в многопрофильной больнице в Вене. В рамках своего исследования Игнац Филипп Земмельвайс обнаружил важную связь между мытьем рук и выживаемостью рожавших в больнице матерей. Интерны и их учителя часто приходили помогать принимать роды сразу же после вскрытия трупов, не помыв при этом руки. Земмельвайс попытался ввести порядок регулярного мытья рук, чтобы не допустить смерти матерей от инфекции. Однако он не преуспел в своей инициативе, доктора говорили, что проблема заключается не в этом и вообще они слишком заняты и серьезны и не будут тратить свое время на глупости.
Жестокая критика, с которой столкнулся Земмельвайс, сломила его дух. К 1865 году он не выходил из депрессии и страдал от множества нервных заболеваний. В итоге его отправили в сумасшедший дом, где он вскоре умер в возрасте сорока семи лет. Конечно, сейчас мы знаем, что, к большому сожалению, Земмельвайс был прав. Строгость и дисциплина в данной сфере могли бы спасти множество жизней. Его внимание к качеству в свое время было проигнорировано, но сегодня это стандарт для наших систем здравоохранения.
Вы должны найти аналог мытья рук для вашей отрасли и строго придерживаться этого принципа. Какие методы обеспечения качества вы можете ввести, чтобы отстаивать свои ценности и поддерживать безопасность и организацию в вашей команде? Для пилотов это карта контрольных проверок, для ресторанов – мытье рук и шапочки, закрывающие волосы, для банков крови – всеобъемлющие опросники и систематический скрининг, для аптечных сетей – автоматические предупреждения о взаимодействии лекарств, а для пищевой промышленности – сроки годности.
Какие методы, какие практики, какие дисциплины потребуются, чтобы дать нам лучший шанс работать с гордостью? Иными словами, как именно мы будем делать нашу работу?
Многие их тех, кто приходит в гости в Menlo, видят веселье и легкомыслие нашей причудливо дерзкой компании. Это может создать впечатление, что у нас попустительское отношение к квалификации сотрудников или качеству работы. На самом деле ничего подобного. Строгость и дисциплина, которые лежат буквально на сантиметр глубже видимой поверхности Menlo, дают в результате беспрецедентное качество наших продуктов.
Независимо от того, управляете ли вы магазином, больницей, авиакомпанией, пожарной частью, автомобильным производством, цирком, патентным делом или IT-компанией, эффект, оказываемый строгостью и дисциплиной на качество, имеет первостепенное значение. Что мы можем сделать, чтобы убедиться, что получили шанс работать с гордостью, сознавая вместе с тем, что приложен максимум усилий для выполнения работы?
Герои полагаются на опасные авантюры, великие команды – на дисциплину
Наряду со всеми методами, позволяющими поддерживать высокое качество продукции, в Menlo есть мораль. Она исходит от знания, что вы работаете в среде, которая безопасна для вас и где уважается хорошая работа.
Строгость и дисциплина – это трудно, всегда проще сказать: «Завтра я сделаю лучше». Но завтра никогда не наступит – сегодняшние действия решают исход дела. Если вы сможете привить своей команде дисциплину применять тот строгий подход, в который все вы верите, скоро вы увидите результат: мораль воспарит, даже если строгость – это сложно. Именно в такие моменты проявления строгости и сеются семена радости. Когда ваша команда наслаждается плодами своей работы, возникает удовлетворение, которое поднимает моральный дух и вдохновляет каждого сделать это еще раз.
Одним из таких строгих правил для нас является обязанность программистов писать автоматизированные тесты для модулей, прежде чем они создадут код, который потом предстоит протестировать. Большинство программистов просто хотят сесть и написать код; будучи уверенными, что они проделали хорошую работу, они убеждают себя, что написание автоматизированного теста совсем не обязательно. Отказаться от этой привычки было бы очень просто, но она критически важна для поддержания уровня качества, к которому мы стремимся. Тем не менее наша дисциплина требует, чтобы мы писали тесты прежде кода, и она гарантирует, что мы будем делать так каждый раз.
В 1980 году я устроился на работу программистом в компанию Manufacturing Data Systems (MDSI) – одну из самых успешных технологических компаний в истории Анн-Арбора. Я все еще учился в колледже Мичигана, так что, пока не закончил учебу, работал неполный день. В MDSI я попал в окружение отличных людей, включая маму Ларри Пейджа, Глорию, которая работала там программистом, а также Томаса Нолла, который продолжал создавать свой Photoshop.
Это были бурные времена для нашей отрасли, и компания MDSI запустила замечательную программу привлечения стажеров в тот год, когда я сам туда устроился. В MDSI нас обучили кое-каким дисциплинарным стандартам кодирования, которые я помню по сей день. Одним из самых необычных, но впечатляющих был стандарт, который сегодня назвали бы разработкой через тестирование. Говоря простым языком, это означает, что программисты пишут автоматизированные тесты для будущего кода, затем – сам код, а в конце запускают тесты, чтобы убедиться, что с кодом все в порядке.
Влияние такого подхода на качество неоспоримо. Эта строгость гарантирует автоматическое отлавливание глупых человеческих ошибок без необходимости помнить все мелочи, которые могут пойти не так. Думайте о нем как об автомеханике, который живет в вашем домашнем гараже. Каждую ночь, пока вы спите, этот неутомимый труженик проверяет давление в шинах, рулевые тяги, тормозные колодки, качество масла, топливный бак, состояние воздушного фильтра, обзор через окна, электрические системы, а также убеждается, что каждый болт и гайка надежно закреплены и находятся в отличном состоянии. Наверное, при таком внимании ваш автомобиль сможет проехать миллион миль. Давайте предположим, что до работы вам ехать 80 километров через замерзшую тундру, в которой не работают мобильные телефоны и любая механическая поломка, скорее всего, приведет к тому, что вы замерзнете насмерть, прежде чем к вам поспеет помощь. В общем, вы понимаете, о чем я.
После завершения той летней стажировки молодых программистов в MDSI я получил назначение в другой отдел, а также четкие указания моего нового босса забыть о принципе разработки через тестирование, потому что у нас есть реальная работа. Я бы больше так и не встретился с этим методом, если бы Кент Бек и Мартин Фаулер не представили вновь данную концепцию миру программирования в 2000 году в своей книге «Рефакторинг».
Строгое применение автоматизированной среды тестирования моделей в Menlo является одной из самых сильных технических дисциплин нашей общей системы убеждений. Новые программисты, приходящие в нашу команду, узнают об этом подходе от своего партнера по паре. Растет качество, мораль и продуктивность, потому что мы можем двигаться вперед быстрее, будучи уверены, что не разрушаем вещи, которые работали в прошлом. И тесты нам помогают выловить возможные ошибки.
Гастроном Zingerman’s имеет собственную версию систематической проверки качества. Там диспетчер магазина каждый заказ повторяет клиенту. Когда вы размещаете заказ, его зачитывают вам для подтверждения. Когда вы оплачиваете его, кассир делает это еще раз. Когда заказ привозят к вашей двери, его состав зачитывают вам в третий раз, чтобы подтвердить, что вы получили правильный набор продуктов. Каждый сотрудник Zingerman’s поступает так всегда. Вы можете себе представить, какое хорошее мнение о компании создает такой подход у клиентов? Он не улучшает качество самих продуктов (для этого есть другие процессы), но он поддерживает уровень удовлетворенности покупателей на самом высоком уровне. Очень просто упустить очевидные ответы на серьезные вопросы, касающиеся качества.
Уверенность в отдельных фрагментах не гарантирует, что вся система будет работать
Еще одной классической проблемой, особенно для команд разработчиков ПО, является то, что система собирается вместе из маленьких несвязанных кусочков, представляющих собой результат работы многих сотрудников. Где-то ближе к концу проекта начинают летать искры, когда все кусочки наконец-то собираются вместе. Такая интеграция обычно становится катастрофой последнего этапа работы и никогда не бывает предусмотренной в плане проекта. Руководители, не являющиеся «технарями», не могут даже понять, что вдруг произошло в их многомиллионном, чрезвычайно важном проекте.
Во избежание этого кризиса последней стадии сборки системы все наши сотрудники в Menlo делают проверки, постоянно соединяя части, над которыми они работают. Благодаря этому мы никогда не сталкиваемся с неприятными сюрпризами на последнем этапе. Если при соединении фрагментов возникают проблемы, мы находим их, пока у нас есть на это время и бюджет. Если же подобная попытка собрать все вместе происходит впервые в самом конце проекта – как это бывает у большинства разработчиков ПО, – команда не может справиться с неизбежной катастрофой последнего этапа. Руководители отменяют проект и распускают сотрудников. Я не знаю всю подноготную проекта Ford Everest, стоившего 400 миллионов долларов, но легко могу допустить, что причиной его сворачивания была именно проблема сборки частей системы в одно целое. Каждый год десятки миллиардов долларов в нашей отрасли тратятся впустую на проекты, которые никогда не выйдут в свет.
Живое представление мюзикла имеет аналогичные проблемы совмещения. За несколько недель до премьеры оркестр сидит над музыкальными партитурами, а актеры репетируют свои песни и роли. Танцевальные группы работают над хореографией, осветители и другой технический персонал разбираются с важными закулисными вопросами. Уверен, вы легко можете вообразить, какая будет катастрофа, если первое совместное выступление состоится, когда поднимется занавес вечерней премьеры. Каждый участник безупречно исполнит свою роль, но зрители увидят хаос. Опытные режиссеры отлично знают это. Они постоянно проводят небольшие совместные репетиции, чтобы преодолеть проблемы, которые даже представить невозможно, пока все участники не окажутся на одной сцене.
Работа в команде и доверие, необходимые для завершения совместных усилий, требуют дисциплины и систематической координации. Пока не будет установлен необходимый уровень дисциплины и строгости, единственным способом довести до конца хоть что-нибудь будут героические усилия нескольких человек – а мы уже видели, что происходит с культурой, которая делает все свои ставки на героев и «башни знаний».
Чаще достигайте значимых результатов
Лучший известный нам способ постоянного испытания нашей системы на прочность – поделиться своей работой с клиентами. Мы посвящаем их в подробности наших процессов тестирования и объединения, мы позволяем им проводить эксперименты на многих этапах, так что по завершении работы они знают о ее качестве не понаслышке.
Каждую неделю после «Покажи и расскажи» мы отправляем клиенту пакет с CD или DVD, на котором записана полностью интегрированная система, чтобы у него была возможность более тщательно исследовать ту часть работы, которую мы на данный момент завершили. Смыслом этой еженедельной рассылки является желание в практическом плане укрепить наше мнение, что презентации в PowerPoint, отчеты о состоянии, рассмотрения группой закрытия каждого этапа и т. п. неспособны заменить готовое программное обеспечение. Отправка материалов после каждого «Покажи и расскажи» также является частью нашей дисциплины.
Каждый, кто хоть раз строил себе дом, может подтвердить вам, что периодически приходится заглядывать на строительную площадку, чтобы проверить прогресс, – некоторые заказчики наведываются туда каждый день. Разве они эксперты в строительстве, плотничестве, укладке блоков или сантехнике? Конечно, нет. Они приходят посмотреть на работу, потому что не существует устной или письменной замены возможности по-настоящему пройти через дом, постоять в почти законченной кухне, где в конечном итоге будет собираться семья, посмотреть, какой вид из окна открывается на прудик на заднем дворе. Людям нравится видеть реальные вещи, в которых они заинтересованы, прикасаться к ним. Чтение отчета о текущем состоянии дел, просмотр слайдов презентации в PowerPoint или ленточных диаграмм не заменит чувств, возникающих во время прогулки по строящемуся дому или тестирования частей вполне работающей компьютерной программы.
У спортсменов есть процедуры, через которые они проходят, чтобы установить строгость и дисциплину. Лучшие команды свято придерживаются этих принципов не только телом, но и душой. Посредственности же только разглагольствуют о строгости, на самом деле они выполняют действия, в которые не верят. Разницу можно увидеть в турнирной таблице, ее можно ощутить на поле и на трибуне.
Строгость, дисциплина и качество, получаемое в результате, усиливают понимание сотрудниками вашей компании того, зачем вы существуете, – концепции, так изящно исследованной Саймоном Синеком в его книге Start with Why («Начните с “почему”»). Как объясняет Синек, все компании знают, что они делают, некоторые даже знают, как они это делают, но удивительно, что совсем немногие отдают себе отчет, почему они делают то, что делают. Это самое «почему» вашей компании может привести к такому уровню качества, о котором большинство только мечтает.