Достигая тех высот

From The Joel on Software Translation Project

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

Есть популярное мнение. Мол, при создании софтверной компании ваша задача состоит в поиске клевой идеи, решающей нерешенную доселе проблему, затем в реализации этой идеи и срывании куша. Назовем это мифом-о-лучшей-мышеловке. Но на самом деле задачей софтверной компании должно быть превращение капитала в работающие программы. На входе — деньги, на выходе — софт.

Последние пять лет я проверяю эту теорию на практике. Формула компании, созданной мной с Майклом Прайором (Michael Pryor) в сентябре 2000 года, состоит из четырех элементов:

Лучшие условия труда → Лучшие программисты → Лучший софт → Прибыль!

Это довольно удобная формула. Особенно с учетом того, что нашей истинной целью создания Fog Creek было создание компании, в которой нам хотелось бы работать. Ныне я сделал заявление, что лучшие условия труда (или «создание такой софтверной компании, где программисты сами будут хотеть работать») приведут к прибыли так же естественно, как шоколад приводит к полноте или мультяшный секс в видеоиграх приводит к разгулу бандитизма.

Сегодня я хочу обсудить только один вопрос. Если он поставлен неверно, то и вся моя теория рассыпается. Так вот, вопрос: имеет ли вообще смысл говорить о сотрудничестве с «лучшими программистами»? Неужели разница между программистами настолько велика, что это имеет значение, в наши-то дни?

Для нас с вами ответ, может быть, и очевиден, однако множеству других людей это утверждение должно быть доказано.

Несколько лет назад некая крупная компания рассматривала вопрос приобретения Fog Creek. Я знал, что этому не бывать: я слышал, как директор этой компании заявил, что он не вполне согласен с моей практикой найма самых лучших специалистов. Он привел мне библейскую метафору: мол, нужен лишь единственный Царь Давид, и вместе с ним армия солдат, минимально разумных лишь для того, чтобы точно выполнять его распоряжения. Цена акции его компании спокойно себе упала с 20 до 5 пунктов, так что очень здорово, что мы не приняли его предложение. Правда, я не думаю, что в падении виноват лишь этот фетиш.

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

В некоторых других отраслях низкая стоимость действительно важнее качества. «Уолмарт» (Wal*mart, крупнейшая сеть супермаркетов в США — прим. пер.) выросла в самую большую корпорацию на Земле, продавая дешевые, а не качественные товары. Если бы «Уолмарт» начали продавать высококачественные товары, цена пошла бы вверх и напрочь исчезло бы их конкурентное преимущество дешевизны. Скажем, если бы они попробовали продавать гетры, выдерживающих такие издевательства, как, скажем, стирка в стиральной машине, им бы пришлось использовать всякие дорогие материалы, как, например, хлопок. И тогда поднялась бы цена на каждый носок.

Так почему же в софтверной области нет места дешевому поставщику: кому-то, кто использует самых дешевых программистов? (Напомните мне спросить у Quark, как все-таки работает их концепция уволь-всех-и-найми-самых-дешёвых.)

А вот почему: программное обеспечение можно размножать бесплатно. Это означает, что стоимость программистов распределяется по всем проданным копиям вашей программы. В области программного обеспечения вы можете поднять качество продукта без увеличения затрат на каждую проданную единицу.

По существу, дизайн добавляет стоимость быстрее, чем себестоимость.

Или, грубо говоря, если вы попытаетесь сэкономить на программистах, вы создадите отстойный софт и не сэкономите даже этих денег.

То же самое касается индустрии развлечений. Имеет смысл пригласить Бреда Питта играть в вашем блокбастере, несмотря на то, что он требует высокий гонорар. Потому что его гонорар может быть разделен на миллионы людей, которые посмотрят фильм только потому, что Бред так чертовски крут.

Или же, если поставить вопрос иначе: имеет смысл пригласить Анджелину Джоли играть в вашем блокбастере, несмотря на то, что она требует высокий гонорар. Потому что ее гонорар может быть разделен на миллионы людей, которые посмотрят фильм только потому, что Анджелина так чертовски крута.

Однако я все еще хожу вокруг да около. Итак, что это значит — быть «лучшим программистом», и есть ли действительно такая большая разница между качеством софта, написанного разными программистами?

Начнем со старой доброй продуктивности. Трудновато измерить продуктивность работы программиста. Практически все системы измерения, приходящие вам в голову (строки отлаженного кода, количество методов, число аргументов командной строки), легко надуть. Тяжело получить конкретные данные по большим проектам, потому что редко когда двум программистам нужно делать одно и то же.

Данные, на которых я основываюсь, получены от профессора Стенли Эйзенштадта (Stanley Eisenstat) из Yale. Он ежегодно читает интенсивный курс по программированию CS 323, где большая часть работы состоит примерно из пяти задач по программированию. Задачи достаточно сложны для обычного курса: разработать оболочку для Unix (проще говоря, «command-line shell» — прим. пер.), программу ZLW-сжатия файлов (позже Спольский пояснил, почему он пишет «ZLW» вместо общепринятого «LZW» — прим. пер.) и т.п.

И студенты так интенсивно спорили о том, сколько нужно всего сделать для реализации поставленных задач, что профессор стал просить студентов отсчитывать, сколько времени они потратили на каждую задачу. Он собирал эти показания в течение нескольких лет.

Я потратил некоторое время и поигрался с этими данными. Это единственные известные мне статистические показания по работе множества студентов над одинаковыми заданиями, использующими одинаковые технологии и одно и то же время. Эти данные, к тому же, грамотно собраны.

Первое, что я сделал с этими данными, — я высчитал среднее, минимальное и максимальное количество часов, затраченных на каждую из двенадцати задач. Вот результаты:

Проект	Ср. часов	Мин. часов	Макс. часов	Ст. откл. часов
CMDLINE99	14.84	4.67	29.25	5.82
COMPRESS00	33.83	11.58	77.00	14.51
COMPRESS01	25.78	10.00	48.00	9.96
COMPRESS99	27.47	6.67	69.50	13.62
LEXHIST01	17.39	5.50	39.25	7.39
MAKE01	22.03	8.25	51.50	8.91
MAKE99	22.12	6.77	52.75	10.72
SHELL00	22.98	10.00	38.68	7.17
SHELL01	17.95	6.00	45.00	7.66
SHELL99	20.38	4.50	41.77	7.03
TAR00	12.39	4.00	69.00	10.57
TEX00	21.22	6.00	75.00	12.11
ВСЕ ПРОЕКТЫ	21.44	4.00	77.00	11.16

Первое, что бросается в глаза, — это огромная разница в показаниях. Самые шустрые студенты заканчивают эти задачи в три или четыре раза быстрее, чем средние студенты, и — ни много ни мало — в десять раз быстрее самых медленных. Стандартное отклонение просто невероятно. Тогда я подумал: хмм, наверное, некоторые из этих студентов сделали просто-таки отвратительные реализации. Я решил исключить студентов, затративших 4 часа на решение задачи и не сделавших работающей программы. Так что я уменьшил выборку и взял данные только по тем студентам, которые были среди лучших: по 25% студентов, показавших лучшее качество кода. Я должен заметить, что оценки в классе профессора Эйзенштата практически полностью объективны: они вычисляются на основе ряда формальных критериев — количество автоматизированных тестов, которые проходит код, — а также на основе нескольких очень простых стилевых правил, вроде аккуратных комментариев и табуляции.

Так о чем это я. Вот результаты лучшей четверти студентов:

Проект	Ср. часов	Мин. часов	Макс. часов	Ст. откл. часов
CMDLINE99	13.89	8.68	29.25	6.55
COMPRESS00	37.40	23.25	77.00	16.14
COMPRESS01	23.76	15.00	48.00	11.14
COMPRESS99	20.95	6.67	39.17	9.70
LEXHIST01	14.32	7.75	22.00	4.39
MAKE01	22.02	14.50	36.00	6.87
MAKE99	22.54	8.00	50.75	14.80
SHELL00	23.13	18.00	30.50	4.27
SHELL01	16.20	6.00	34.00	8.67
SHELL99	20.98	13.15	32.00	5.77
TAR00	11.96	6.35	18.00	4.09
TEX00	16.58	6.92	30.50	7.32
Все проекты	20.49	6.00	77.00	10.93

Невелика разница! Стандартное отклонение практически такое же для четверти лучших студентов. Более того, если вы внимательно посмотрите на эти данные, то станет ясно, что видимой зависимости между временем и оценкой нет. Вот типичный график одной из задач... Я выбрал задание COMPRESS01, реализацию алгоритма сжатия Зива-Лемпеля-Уелша, которое задали студентам в 2001 году. Выбрал его, потому что стандартное отклонение здесь очень близко к общему стандартному отклонению.

Нечего здесь искать, в этом-то и вся суть. Качество работы и время, на нее затраченное, — эти параметры попросту не кореллируют.

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

Эти данные нельзя назвать строго научными. Наверняка здесь не все достоверно. Некоторые студенты могли завышать время в надежде заработать некоторую симпатию и получить более легкие задачи в следующий раз. (Удачи! Задания CS 323 не менялись с 1980-х годов, когда я там учился.) Другие студенты могли занижать затраты, потому что они теряли ощущение времени. Тем не менее, я не считаю большим допущением поверить в то, что эти данные показывают пятикратную или десятикратную разницу в продуктивности разных программистов.

Подождите, это еще не все!

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

И еще!

Истинная проблема использования толпы посредственных программистов вместо парочки профессионалов в том, что сколько бы они ни работали над задачей, они никогда не создадут такого продукта, какой могут создать профессионалы.

Пять Сальери не напишут «Реквием» Моцарта. Никак. Даже если они будут работать над ним сто лет.

Пять Василиев Пупкиных, создателей всяческих несмешных мультяшных сериалов, в которых 20% шуток — про сисадминов, а остальные якобы смешны лишь за счет ужасного новорусского сленга... Так вот, пять Василиев Пупкиных могут потратить весь остаток своих жизней, но даже близко не создать что-то столь же хитовое, как Масяня.

Команда разработчиков плеера Creative Zen может потратить годы, улучшая свое жалкое подобие iPod, и все же никогда не выпустить что-то столь прекрасное и элегантное, как Apple iPod. И они не сомкнут свои челюсти на рыночном пироге Apple по той лишь причине, что феерический дизайнерский талант у них в команде отсутствует. Просто нет его там, и все.

Посредственность никогда не достигает тех высот, на которых спокойно парит профессионал. Количество оперных див, способных взять высокую ноту f6 в моцартовской «Королеве Ночи», исчезающе мало, но «Королеву Ночи» просто невозможно исполнить без этой знаменитой f6.

Разве софт — это рассказ о тех высотах? «Может, в чем-то и так, — скажете вы, — но я работаю над софтом учета товарных накладных в индустрии утилизации медицинских отходов». Логично. Наша беседа — о софтверных компаниях, о коробочном продукте, о том случае, когда успех или провал бизнеса напрямую зависит от качества кода.

Да и мы в последнее время видели массу великолепного софта, созданного действительно на тех высотах: софта, воплотить который посредственность просто не смогла бы.

В 2003 году Nullsoft выпустили новую версию плеера Winamp, сопроводив выпуск вот такими комментариями на веб-сайте:

• Клевый новый дизайн!
• Навороченные фичи!
• Большинство функций таки работают!

Я о последнем... «Большинство функций таки работают!» — это забавно. И все счастливы, довольны плеером, используют его, говорят всем своим знакомым и друзьям. И они полагают, что Winamp — это хороший продукт, потому что они таки взяли и написали на своем сайте: «Большинство функций таки работают». Круто, да?

Если бы вы подключили еще людей в команду разработчиков Windows Media Player, смогли бы они достичь тех высот? Никогда в жизни.. Потому что, чем больше людей работает в команде, тем больше шансов, что в ней найдутся натуральные снобы, полагающие, что это непрофессионально и по-детски — писать на веб-сайте «Большинство функций-таки работают».

Не говоря уже об этом комментарии: «Winamp 3: Почти такой же новый, как и Winamp 2!».

Вот такие вещи и заставили нас влюбиться в Winamp.

А с тех пор, как корпоративные слизняки из AOL Time Warner наложили свои лапы на эту штуку, весь юмор с сайта исчез. Вы теперь просто-таки явно можете представить их себе, этих сальери, убийственно подавляющих малейшие признаки творческого подхода, который может отпугнуть какую-нибудь немолодую даму из Минессоты. Ценой уничтожения всего того, что могло бы заставить людей полюбить этот продукт.

Или посмотрите на iPod. Вы не можете сменить батарею. Когда аккумулятор умирает — все очень грустно. Покупайте новый iPod. Ну, или Apple готова заменить вам аккумулятор, если вы отошлете ваш iPod обратно на завод, и стоит это $65.95. Вот так вот.

Почему у вас нет возможности поменять аккумулятор?

Мое предположение: дизайнеры Apple решили оставить нетронутой превосходно-гладкую поверхность своего прекрасного, сексуального плеера. Не портить ее одной из этих крышек для аккумулятора, которые можно увидеть на любой дешевой бытовой аппаратуре, с этими плохо прилегающими, цепляющимися за одежду и ломающимися крышечками для аккумуляторов. iPod — это самое цельное устройство из всех, когда-либо виденных мною. Он прекрасен. Он прекрасен на ощупь, как гладкий речной камушек. Одна только крышка аккумулятора могла бы полностью уничтожить это ощущение.

Apple приняла решение в пользу стиля. На самом деле в iPod полно таких «стилевых» решений. И чувство стиля — это вовсе не то, чем обладают 100 программистов в Microsoft или 200 промышленных дизайнеров в ошибочно названной компании Creative (Сreative — творчество — прим. пер.) Потому что у них нет Джонатана Айва (Jonathan Ive), и Джонатаны Айвы на дороге не валяются.

Простите, но я всё не перестаю восхвалять iPod. А это прекрасное колесико управления с щелкающим звуком! Apple вложила дополнительные деньги, встроив динамик в сам iPod для того, чтобы этот клик исходил прямо из-под самого колесика управления. Они могли бы сэкономить копейки... копейки!, если бы они воспроизводили звук щелчка через наушники. Но колесико управления дает вам ощущение полного контроля над плеером. Люди счастливы, когда чувствуют, что всё под контролем. Счастливы. Тот факт, что колесико управления реагирует на ваши команды мгновенно, мягко и с звуком, — это счастье. Не то, что остальные 6000 продающихся моделей карманного электронного барахла, которые включаются так долго, что после нажатия кнопки надо ждать минуту, пока что-нибудь произойдет. У вас есть ощущение контроля? Кто знает? Когда в последний раз у вас был мобильный телефон, который включался сразу после нажатия кнопки?

Стиль.

Счастье.

Чувства.

Это то, на чем создаются хиты в программном обеспечении, кино и бытовой электронике. И если вы этого не понимаете, вы можете успешно решать технологические задачи, но ваш продукт не станет хитом номер один. Таким хитом, который сделает всех сотрудников компании богатыми, так что вы все сможете водить стильные, счастливые, кричащие машины типа Ferrari Spider F-1 и при этом иметь еще достаточно денег, чтобы построить ашрам на заднем дворе.

Это не вопрос десятикратной разницы в продуктивности. Это о том, что «среднепродуктивный» разработчик никогда не взлетит на те высоты, на которых создается великолепный софт.

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

Рынок ПО сегодня представляет собой игру, в которой «победитель забирает все». Кроме Apple, никто не зарабатывает на MP3-плеерах. Никто не зарабатывает на электронных таблицах и текстовых процессорах, кроме Microsoft. Да, я знаю, что они предприняли определенные шаги, чтобы избавиться от конкурентов, но это ничего не меняет: рынок ПО — система, где победитель забирает все.

Вы не можете себе позволить быть продуктом «номер два» или поставлять «достаточно хорошего уровня» программу. Программа должна быть заметно хороша, где «заметно» означает, что покупатели именно видят ее качество. Преимущество, которое вы получите от команды действительно — действительно талантливых программистов, — это единственный шанс стать заметным. Вот и вся формула:

Лучшие условия труда → Лучшие программисты → Лучший софт → Прибыль!

---