Творческий отбор

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

Более того, Ричард за два рабочих человеко-дня сделал для нашего проекта больше, чем мы с Доном сделали за предыдущие двенадцать человеко-недель. Это ускорение более чем в тридцать раз.

Чем можно объяснить такое отличие? Поначалу может сложиться впечатление, что многое держится на ловкости Ричарда как программиста, на его созданной программными средствами оболочке. Тем не менее его усилия по работе с Konqueror очень напоминают мои попытки обуздать Mozilla. Возможно, он просто был куда лучшим программистом, чем я, и без его таланта в разработке кода не было бы и этой истории.

Это слишком простое объяснение. Ричард сделал свою оболочку только после того, как осознал, что ему нужно еще что-то, кроме вдохновения, расчетов и рассуждений, какое-то последнее звено. Его оболочка соответствовала его плану. Чтобы показать, что я имею в виду, я привожу список всего, что Ричард сделал за свои первые два дня в Apple.

Он начал с того, что расспросил нас о том, какой анализ браузеров мы провели до его прихода в компанию, и, услышав об этом, быстро сбросил со счетов нашу идею с Mozilla, поскольку этот браузер едва ли нам подходил. Так он показал, что уверен в себе, и не стал заискивать перед руководителем с многолетним опытом в технической области, где Уильямсон был новичком. Далее Ричард сумел добиться результата в самые короткие возможные сроки. Он загрузил проект с открытым исходным кодом, который выглядел многообещающим, — исходник Konqueror из KDE, браузер, который мог стать основой для нашей долговременной работы. Пытаясь заставить этот код работать на Macintosh, Уильямсон решил сделать наиболее близкую к реальности версию браузера, которую только возможно было создать за короткий срок. Он выделил три функции: загрузка страниц, переход по ссылкам и возвращение на предыдущую страницу. Он посчитал, что уже это может стать достаточно веским подтверждением концепции. Затем Ричард применил свои хитрости для упрощения задачи, и после стало понятно, чего у нас пока не будет: на время пришлось отказаться от идеального отображения шрифтов, а также от полной интеграции с оригинальной графической системой Macintosh, равно как и от использования минимального количества исходного кода KDE. Уильямсон рассудил, что все эти недоделки хотя и имеют значение, но не могут существенно преуменьшить значение от появления браузера, отображающего веб-страницы. Он решил свести воедино все эти составные части в одну демоверсию, которая показала бы потенциал Konqueror. Наконец, затем он проработал технические детали и таким образом разработал оболочку, поскольку оставалось только одно препятствие, мешающее реализации его плана. Его мышление дополнило техническую смекалку.

А вот мы с Доном вцепились в то, что Mozilla каким-то образом оправдает ожидания. Я пытался заставить эту громадину с открытым исходным кодом скомпилироваться на Macintosh, нисколько не думая, что же будет после этого. У меня не было никаких достойных планов, целей, списка того, чем можно пренебречь, жесткого графика или технических задумок.

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

Если бы мы с Доном продолжили работать в Apple так же, как было принято в Eazel, кто знает, когда мы смогли бы показать демоверсию? В тот момент нашей карьеры мы просто не знали, как раскрутить крупный проект и вывести его к успеху.