Статья © 2005 Joel Spolsky, Оригинал называется Hitting the High Notes

В марте 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 для того, чтобы этот клик исходил прямо из-под самого колесика управления. Они могли бы сэкономить много монеток, денег!.. если бы они воспроизводили звук щелчка только через наушники. Но колесико управления дает вам ощущение полного контроля над плеером. Люди счастливы, когда обладают властью. Счастливы. Тот факт, что колесико управления реагирует на ваши команды мгновенно, мягко, да еще и подтверждает команды акустически, — это кайф. А остальным 6,000 продающимся моделям посредственной портативной техники нужно так много времени, чтобы включиться. В течение минуты вам надо поглядывать на этот кусок мусора, только чтобы понять, готов он уже работать или нет... Так у кого власть? У вас? Вспомните, как давно у вас был мобильный телефон, который включался сразу после нажатия кнопки?

Стиль.

Счастье.

Чувства.

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

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

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

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

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

Лучшие условия труда

→

Лучшие программисты

→

Лучший софт

→

Прибыль!