В Японии на сборку фешенебельного автомобиля компании Toyota, Honda и Nissan тратили в среднем 16,8 часа. На завод поступали запчасти, и спустя 17 часов появлялся, например, Lexus. На 100 автомобилей приходилось всего 34 дефекта. Недурно.

В Европе наблюдалась совсем другая традиция. На производство автомобиля высшего класса компании Mercedes-Benz, Audi и BMW тратили 57 часов. На 100 автомобилей приходилось 78,7 дефекта.

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

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

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

Да, вы все верно поняли. Немцы чинили только что собранную машину дольше, чем японцы производили новую. Японские компании скрупулезно проводили сборку с самого начала производственного процесса. Вот почему Toyota стала лучшим в мире производителем автомобилей.

Мы не всегда умеем сразу делать все правильно. Мы люди и мы совершаем ошибки. Однако то, как мы дальше поступаем с этими ошибками, исключительно отражается и на скорости нашей работы, и на ее результатах. В Toyota, как мы уже знаем, каждый сотрудник завода, если заметил погрешность, мог остановить конвейер. Мысль нехитрая: поскольку линия движется безостановочно, а сборка должна проходить безукоризненно, то самый правильный момент для исправления брака – та минута, когда вы его заметили, а не после того, как перед вами будет стоять готовое изделие.

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

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

Тогда в компании внимательно присмотрелись ко всем своим Мэттам – а в ней работали сотни разработчиков – и решили проанализировать, сколько времени понадобится на то, чтобы исправить ошибку сразу, а сколько – если вернуться к ней через несколько недель. Все мы в состоянии понять, какой сложной и запутанной может быть программа, поэтому я вас спрашиваю: во сколько раз больше будет потрачено времени во втором случае?

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

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

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

Когда основатель OpenView Venture Partners Скотт Максвелл сотрудничал в начале 1990-х годов с McKinsey & Company, он получил от Джона Катценбаха одно напутствие, показавшееся ему тогда довольно странным. В те годы Джон Катценбах возглавлял McKinsey, в настоящее время он руководит Центром Катценбаха, действующим в рамках компании Booz Allen Hamilton; он известный автор множества статей и бестселлеров. Именно этот опытный эксперт в области управления дал Максвеллу совет, который тот запомнил на всю жизнь.