Принцип «черного ящика». Как превратить неудачи в успех и снизить риск непоправимых ошибок

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

У Слеммера была другая точка зрения. Он уже создал две компании в области высоких технологий и понял кое-что очень важное: разработать идеальное программное обеспечение с первого раза практически невозможно. Только когда сервисом начинают пользоваться, испытывая его возможности, можно заметить ошибки и изъяны, которые до того не выявишь, сколько ни пытайся. Тестируя программу и действуя методом проб и ошибок, ты получаешь информацию, которая в итоге обеспечивает развитие. Слеммер спросил Ванье: с какой стати тот пытается ответить на все вопросы, когда программой еще никто не пользуется?

Спор Слеммера и Ванье отражает разницу между биологами и математиками компании Unilever (а на более абстрактном уровне – разницу между идеей прогресса по Кили и представлениями, что прогресс возникает из-за новых теорий): концепция «сверху вниз» против концепции «снизу вверх». Ванье хотел делать все по плану, а Слеммер хотел сразу начать испытания продукта и впоследствии совершенствовать программу, оперативно получая обратную связь от клиентов. Он желал проверить свои предположения.

Победили доводы Слеммера. Уже на ранней стадии разработки компания предложила клиентам испытать программу – и смогла быстро устранить недостатки благодаря отзывам тестеров. По мере того как росло количество отзывов, Ванье и Слеммер переписывали всё большие куски исходного кода. В конце концов они создали, по всей вероятности, самый сложный продукт в своей области.

«Несмотря на то что Слеммер и Ванье конкурировали с куда более крупными фирмами, у которых было больше финансовых ресурсов… они всякий раз первыми открывали новые приложения и сервисы, такие как направления дорожного движения и веб-телефон с интегрированными рекламными предложениями, – пишет Питер Симс, следивший за развитием компании. – По словам Ванье, если у него есть возможность запустить десять приложений, пока конкуренты запускают одно, он получит в десять раз больше опыта за счет обратной связи, помогающей понять, что именно с точки зрения покупателей удалось, а что нет» [161].

Эта история намекает на опасность перфекционизма – желания добиться идеального результата с первого раза. Судьба Рика, компьютерного гения из Кремниевой долины, подтверждает это.

Рик хотел создать веб-сервис, позволяющий пользователям размещать в интернете простые текстовые статьи. Эта идея осенила Рика задолго до революции блогов. Он чувствовал возможности этой идеи и работал по 15 часов в день. Вскоре у него появилась рабочая версия сервиса. Однако вместо того чтобы дать пользователям шанс испытать этот сервис, Рик решил, что программное обеспечение будет работать еще лучше, если создать более совершенный язык программирования. Рик проектировал этот новый язык четыре года. Результат был ужасен. Психологи Райан Бабино и Джон Крамбольц писали:

Следующие четыре года Рик все больше увязал в технических деталях и отдалялся от первоначальной идеи. В это время другие бизнесмены создавали блог-платформы, которые не были ни совершенны, ни технологически продвинуты. Разница была в том, что они быстро выпускали свои ущербные сервисы на рынок. При этом они получали обратную связь, благодаря которой совершенствовали сервисы и зарабатывали миллионы долларов [162].

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