Пол Грэм, «Хакеры и художники», глава 5: «The Other Road Ahead», продолжение

«Инвесторы и аналитики спрашивали нас о том, что мы запланировали на будущее. Нашим настоящим ответом было бы: «У нас вообще нет планов».»
— Пол Грэм, разработчик, инвестор, эссеист.

Мне было любопытно познакомиться с прогнозом основателя самого влиятельного бизнес-инкубатора кремниевой долины (Y combinator). Спустя 15 лет с момента публикации эссе Пола Грэма, благодаря компании Edison и отличным людям с Хабра, руки дошли до перевода. Для тех, кому интересно, как происходило зарождение нового продукта и как три программиста бодались с гигантами индустрии, добро пожаловать под кат.

Сентябрь 2001
Оригинал — The Other Road Ahead
(За перевод спасибо Щекотовой Яне)

Читать первую часть главы.

Подход к делу

Иметь возможность выпускать программу незамедлительно — существенный мотиватор. Часто по пути на работу я думал об изменениях, которые мне хотелось внести в приложение, и вносил их в тот же день. Это также работало и для более крупных фич. Даже если на написание чего-то требовалось две недели (а на некоторых проектах и того больше), я знал, что смогу увидеть результат как только все будет реализовано.

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

Крупные компании вместо реализации фич планируют их. По этой причине мы в Viaweb иногда сталкивались с трудностями. Инвесторы и аналитики спрашивали нас о том, что мы запланировали на будущее. Нашим настоящим ответом было бы: «У нас вообще нет планов». У нас были общие представления о том, что бы мы хотели улучшить, но если бы мы знали как, то уже давно бы это сделали. Что мы собираемся делать с течении следующих шести месяцев? Все, что могло бы привести нас к максимально выигрышному положению. Не знаю, осмелился бы я когда-нибудь так ответить, но такова была правда. Планы — это всего лишь синоним к слову «идеи». Когда нас посещали хорошие идеи, мы реализовывали их.

В Viaweb, так же как и во многих других компаниях по разработке программного обеспечения, большинство кода имеет одного определенного владельца. Но если вам что-то принадлежит, то вы реально этим обладали: никто, за исключением владельца части программы, не может дать разрешение на ее релиз (или даже знать об этом). Как таковой защиты от поломок, кроме как страха выглядеть идиотом перед своими коллегами, не было, но и этого было более чем достаточно. Я, возможно, создал ложное представление о том, что мы просто безмятежно двигались вперед создавая код. Мы и правда быстро продвигались, но мы тщательно все продумывали перед тем, как выложить приложение на серверы. В плане надежности внимание важнее медленного продвижения. Именно благодаря повышенному вниманию к процессу военный летчик может ночью посадить 40 000 фунтовый самолет на скорости 140 миль в час на раскачивающуюся палубу авианосца, и при этом риска будет меньше, чем при разрезании хлеба среднестатистическим подростком.

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

Теория Брукса наоборот

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

Viaweb был написан всего тремя людьми. [7] Я очень старался нанять еще, потому что нам хотелось, чтобы нас купили, а мы знали, что было бы нелегко убедить покупателей заплатить высокую цену за фирму с тремя программистами. (Решение: мы наняли еще людей, но создали для них новые проекты.)

Когда вы пишете программы, имея в штате меньшее количество программистов, то вы экономите больше, чем только деньги. Как заметил Фред Брукс в своей книге «Мистический человеко-месяц», увеличение числа людей в проекте ведет к его замедлению. Количество возможных связей между разработчиками растет экспоненциально с увеличением размера группы: чем она крупнее, тем больше времени будет потрачено на обсуждение того, как приложения будут совместно работать, и тем больше ошибок проявится из-за непредвиденных зависимостей. К счастью, этот процесс также работает и в обратном направлении: чем меньше группа, тем выше по экспоненте растет эффективность процесса разработки приложений. Я не могу припомнить, чтобы программисты в Viaweb организовывали настоящие собрания. Мы никогда за раз не говорили больше, чем могли сказать по пути на обед.

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

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

Наблюдение за пользователями

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

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

Когда на вашем сервере есть пользователи, вам не нужно полагаться, например, на бенчмарки, которые являются эмуляцией пользователей. С серверными приложениями вы можете наблюдать за реальными пользователями. Чтобы решить, что оптимизировать, просто залогиньтесь на сервере и посмотрите, что потребляет все процессорное время. И вам также известно, когда завершить оптимизацию. Мы в итоге довели редактор Viaweb до такой точки, когда он стал больше зависеть от объема памяти, а не от быстродействия процессора, и, поскольку мы ничего не могли сделать для уменьшения размеров пользовательских данных (ну, ничего того, что считалось простым), мы знали, что надо бы на этом остановиться.

Для серверных приложений производительность имеет значение, потому что вы платите за оборудование. Число пользователей, которое вы можете поддерживать на одном сервере, является делителем ваших капитальных затрат, поэтому, если вы можете создать довольно производительное приложение, то вы сможете предоставлять его по цене ниже, чем у конкурентов, и получить прибыль. В Viaweb наши капитальные затраты в расчете на одного пользователя снизились до 5$. А сейчас они бы могли бы быть и еще меньше. Возможно, меньше, чем отправка счета за первый месяц. Сейчас оборудование вам ничего не стоит, если ваши приложения достаточно производительны.

Наблюдение за пользователями может привести вас к вопросам как проектирования, так и оптимизации. В Viaweb используется скриптовый язык RTML, который позволил продвинутым пользователям определять стиль их личных страниц. Мы выяснили, что RTML стал своего рода журналом отзывов и предложений, т.к. пользователи использовали его только тогда, когда готовые стили страниц не могли реализовать то, что им хотелось. Например, изначально редактор размещал панель с кнопками поперек страницы, но после того, как некоторое число пользователей воспользовались RTML для размещения кнопок внизу слева, мы реализовали такую опцию (по умолчанию) в готовых стилях страницы.

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

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

Я изучал историю переходов по ссылкам людей, участвующих в тестовом запуске и выяснил, что на определенном шаге они запутывались и кликали мышью на кнопку браузера «Назад». (Если вы попробуете написать веб-приложение, то обнаружите, что кнопка «Назад» переходит в разряд одной из самых интересных философских проблем.) Поэтому я добавил в этом месте сообщение, разъясняющее пользователям, что они практически закончили, и чтобы они не нажимали на кнопку «Назад». Еще одна замечательная вещь в веб-приложениях это то, что вы получаете мгновенную реакцию на изменения: число людей, завершивших тестовый запуск, тут же возросло с 60% до 90%. А поскольку число новых пользователей зависит от числа завершивших тестдрайв, наш доход вырос на 50% только из-за этих изменений.

Оплата

В начале 90-х годов я прочел статью, в которой кто-то сказал, что программное обеспечение — это бизнес на основе подписки. Поначалу это утверждение показалось очень циничным. Но потом я осознал, что это отражает реальность: разработка программного обеспечения — это непрерывный процесс. Полагаю, что будет честнее, если вы открыто обозначите стоимость подписки вместо того, чтобы вынуждать людей покупать и устанавливать новые версии, чтобы они продолжали вам платить. И, к счастью, подписка — это естественный способ оплаты веб-приложений.

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

Для компаний веб-приложения — это идеальный источник дохода. Вместо того, чтобы начинать каждый квартал с чистого листа, у вас будет периодический доход. Поскольку ваше приложение раскручивается постепенно, вам не нужно беспокоиться, что новая модель потерпит крах; новая модель, как таковая, и не будет нужна, и если вы внесете в приложение нечто, что пользователи воспримут в штыки, то вы тут же узнаете об этом. У вас нет проблем со счетами, неподлежащих оплате: если кто-то не будет платить, вы просто отключаете сервис. Тут также отсутствует возможность для пиратства.

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

Компании по возможности любят проводить ценовую дискриминацию, что означает назначить каждому клиенту как можно более высокую цену, какую только можно позволить. [8] Программное обеспечение особенно подходит для ценовой дискриминации, т. к. предельные затраты близки к нулю. Вот почему некоторые приложения для запуска на компьютерах Suns стоят больше аналогов для Intel: фирма, использующая Suns, не заинтересована в экономии денег и может заплатить больше. Пиратство, в сущности, является низшим уровнем ценовой дискриминации. Думаю, что компании по разработке ПО это понимают и намеренно не замечают некоторые виды пиратства. [9] Что касается серверных приложений, то для них придумают другое решение.

Веб-приложения хорошо продаются, особенно в сравнении с десктопным ПО, потому что его легко купить. Вы могли бы подумать, что решение людей что-то купить, и последующая покупка — это два отдельных шага. Так я думал раньше в Viaweb, по мере того, как размышлял на эту тему в принципе. На самом деле, второй шаг может перейти обратно в первый: если что-то сложно купить, люди начнут сомневаться, а надо ли им это. И наоборот: вы больше продадите, если это легко купить. Я покупаю больше книг, потому что существует Amazon. Веб-приложение просто самая простая в мире вещь, которую можно купить, особенно если вы только что сделали онлайн демо-версию. Пользователи не должны совершать много действий, а только вводить номер кредитной карты. (Вынуждайте совершать их больше действий на свой страх и риск.)

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

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

Клиенты

Кем будут ваши клиенты? Для Viaweb это изначально были частные лица и небольшие фирмы, и, как мне кажется, в веб-приложениях это станет устоявшимся правилом. Такие пользователи готовы попробовать что-то новое частично потому, что они более гибкие, и отчасти потому, что они хотят меньше тратиться на новые технологии.

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

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

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

Крупные компании, которые используют веб-приложения, в некоторой степени передают часть IT-функций в аутсорс. Как бы резко это ни звучало, я считаю, что, в целом, это хорошая идея. Так у фирм больше шансов получить лучшее обслуживание, чем если бы они организовывали собственный штат системных администраторов, которые могут стать своенравными и невосприимчивыми, потому что они не подвергаются напрямую конкурентному давлению: продавец работает с клиентами, разработчик – с приложениями конкурентов, а у системного администратора, как у старого холостяка, в распоряжении всего несколько внешних факторов, удерживающих его на плаву. [10] В Viaweb внешних факторов для удержания себя на плаву было в изобилии. Люди, звонящие нам, были клиентами, а не просто коллегами. Если сервер заклинивало, мы тут же подрывались; уже сама мысль об этом заставляет почувствовать всплеск адреналина, даже спустя годы.

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

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

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

Сын сервера

Ничего нового в запуске приложение на сервере нет. В действительности, это устаревшая модель: все приложения для суперЭВМ являются серверными. Если серверные приложения — это такая хорошая идея, то почему она проиграла другим? Почему настольные компьютеры затмили суперЭВМ?

Поначалу настольные компьютеры не рассматривались как прямая угроза. Все первые пользователи были поголовно компьютерными специалистами или людьми увлеченными. Им нравились микроЭВМ, т. к. они были дешевле. Впервые у вас был свой собственный компьютер. Фраза «персональный компьютер» сейчас прочно вошла в обиход, но когда ее впервые использовали, она обладала намеренно ярким звучанием, как сегодня фраза «персональный спутник».

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

Не думаю, что многие люди осознают, как хрупки и неуверены стартапы на ранней стадии. Многие стартапы начинаются почти случайно: пара молодых людей, либо с постоянной работой, либо школьники, пишут прототип чего-то, что могло, если это выглядело многообещающим, перерасти в фирму. В таком зачаточном состоянии любое значительное препятствие намертво заморозит стартап. Написание ПО для суперЭВМ требовало слишком много обязательств. Компьютеры для разработки ПО были дороги, и, т. к. клиентами были крупные фирмы, вам понадобился бы впечатляющий торговый персонал, чтобы им это продать. Начинать стартап по созданию ПО для суперЭВМ было бы гораздо более серьезным делом, чем просто совместное ковыряние программ на своем Apple II по вечерам. Поэтому и не было большого числа стартапов по созданию такого ПО.

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

Приложение, которое перевело настольные компьютеры в господствующую тенденцию, называлось VisiCalc, первый редактор таблиц. Его написали на чердаке два парня, и оно творило такие вещи, которые ни одно приложение для суперЭВМ осуществить не могло. [11] VisiCalc был в то время таким прорывом, что люди покупали Apple II только для того, чтобы запускать его. И это было началом нового тренда: настольные компьютеры победили потому, что стартапы создавали под них приложения.

Кажется, что серверные приложения были бы как нельзя кстати, т. к. стартапы их напишут. Сейчас компьютеры такие дешевые, что вы можете начать с того же, что и мы, т.е. использовать настольный компьютер в качестве сервера. Недорогие процессоры поглотили рынок рабочих станций (вы сейчас едва ли услышите это словосочетание) и по большей части через рынок серверов; серверы Yahoo, которые справляются с нагрузками, как и все прочие серверы в Интернет, все они оснащены недорогими процессорами Intel, что установлены в вашем настольном компьютере. И, когда вы написали приложение, все, что вам нужно продать, это веб-сайт. Почти все наши пользователи пришли напрямую на наш сайт посредством сарафанного радио и отсылками в прессе. [12]

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

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

Если фирма хочет создать платформу, на основе которой будут реализовываться стартапы, то она должна быть такой, чтобы программисты сами захотели бы ее использовать. Что означает, что она должна быть недорогой и хорошо спроектированной. Когда Mac впервые появился, он был популярен среди компьютерных профессионалов, и многие из них писали под него приложения. [13] В случае с Windows это было менее заметно, т. к. программисты ей не пользовались. Сейчас люди, которые хороши в разработке приложений, склонны к использованию Linux или FreeBSD.

Не думаю, что мы бы организовали стартап для создания ПО для настольных компьютеров, потому что такое ПО должно запускаться на Windows, а перед тем, как писать ПО под Windows, нам пришлось бы ей пользоваться. Веб позволяет обойти Windows, и предоставлять ПО, работающее на Unix, напрямую пользователям через браузер. Это отличный шанс, чтобы освободиться от зависимостей, что очень напоминает появление ПК 25 лет назад.

Microsoft

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

Я как-то упоминал ранее, что, например, моей матери вообще не нужен настольный компьютер. И, вероятно, большинству пользователей это тоже не надо. Вот в чем проблема Microsoft, и они это знают. Если приложения запускаются на удаленных серверах, никому не нужна Windows. Что же будет делать Microsoft? Смогут ли они воспользоваться своим контролем над ПК, чтобы предотвратить появление или ограничить это новое поколение приложений?

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

Я считаю, что Microsoft будет сложно удерживать технологии в жестких рамках. Будет слишком много различных типов клиентов, чтобы обеспечивать контроль над ними всеми. А если приложения Microsoft работают только с некоторыми клиентами, конкурентам удастся их обскакать, предлагая приложения, работающие на любом клиенте. [14]

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

Дело не только в том, что их обставят конкуренты, но и в том, что они сами себе роют яму. По мере развития веб-приложений они столкнутся не только с техническими проблемами, но и со своим принятием желаемого за действительное. Им нужно поглотить свой текущий бизнес, и я представить не могу, что они пойдут на это. Та самая целеустремленность, которая их так далеко завела, теперь будет работать против них. IBM была в точно таком же положении, и ей не удалось с этим справиться. IBM сделала запоздалый и нерешительный выход на рынок микроЭВМ, потому что они испытывали двойственное чувство, ставя под угрозу свою дойную корову – использование суперЭВМ. Аналогично Microsoft будет стеснен в своих действиях, желая сохранить настольные решения. Надежный источник денег может превратиться в довольно тяжелую ношу.

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

Больше, чем просто стартап

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

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

Со временем команды стали меньше, быстрее, и более непринужденными. В 1960 под разработкой ПО подразумевалась комната, полная людей в очках с роговой оправой в узких черных галстуках, усердно пишущих по 10 строк кода в день в бланках для кодирования IBM. В 1980 это была команда из 8-10 человек, приходящих в офис в джинсах и печатающих в терминалах vt100. Теперь это пара парней, сидящих в гостиной с ноутбуками. (А джинсы оказались не самым последним пунктом в обеспечении атмосферы непринужденности и свободы.)

В стартапах много стресса, и, к сожалению, это также доводится до крайности в сфере веб-приложений. У многих компаний по разработке ПО, особенно в начале, были моменты, когда разработчики спали под столами и т.п. Тревожным сигналом может стать тот факт, что ничто не может препятствовать переходу этого явления в постоянную практику. Истории про то, как кто-то спит под столом, обычно заканчиваются так: и вот, наконец, мы сохранили все изменения и пошли домой, и отсыпались всю неделю. В веб-приложениях нельзя взять и внести все изменения. Вы можете работать по 16 часов в день так долго, как того захотите. А т.к. можете вы, и ваши конкуренты тоже, вы уже вынуждены это делать. Вы можете, поэтому вы должны. Закон Паркинсона наоборот.

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

В Viaweb мы провели первые 6 месяцев просто за написанием программы. Мы работали типичный удлиненный рабочий день стартапа на ранних стадиях развития. Будь мы в компании по разработке десктопных приложений, мы бы рассказывали, как усердно мы трудимся, но по ощущениям это сопоставимо с отпуском, если брать в сравнении со следующим этапом, где мы пустили пользователей на свой сервер. Вторым большим преимуществом (после денег) от продажи Viaweb компании Yahoo была возможность переложить всю ответственность за все это на плечи крупной фирмы.

Десктопные приложения вынуждают пользователей становиться системными администраторами. Веб-приложения вынуждают таковыми становиться программистов. В общей сумме стресса получается меньше, но его доля на программистов больше. Это не всегда плохо. Если вы затеяли стартап и конкурируете с крупной фирмой, то это хорошо. [15] Веб-приложения предлагают прямой путь к тому, чтобы превзойти ваших конкурентов. А стартапы большего и не требуют.

И так хорошо

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

Здесь прослеживается аналогия с первыми микроЭВМ. Процессоры в этих машинах на самом деле не были предназначены для использования в качестве центральных процессоров. Они были предназначены для использования в светофорах и т.п. Но люди вроде Эда Робертса, создателя Altair, поняли, что они хорошо подходили и для этих целей тоже. Можно было совмещать один из этих чипов с какой-нибудь памятью (в первом Altair было 256 байт памяти), добавить переднюю панель переключателей, и вот перед вами работающий компьютер. Возможность собрать свой собственный компьютер была такой захватывающей идеей, что появилась куча людей, которые хотели их купить, хотя их число и было ограничено.

Веб-страницы создавались не для того, чтобы служить интерфейсом веб-приложениям, но они и так хороши. А для значительного числа пользователей приложений, которыми можно воспользоваться из любого браузера, будет достаточно, чтобы действительно пересилить неприятие некоторой неповоротливости в UI. Может, у вас и не получается создать с помощью HTML самую красивую электронную таблицу, но вы можете создать такую таблицу, которой несколько людей могут пользоваться одновременно из различных мест без специального клиентского ПО, или которая может объединять реальные данные, или которая может присылать вам уведомление, когда срабатывают определенные условия. Что более важно, можно создавать новые виды приложений, у которых еще нет названий. VisiCalc был не просто приложением для суперЭВМ с версией для микроЭВМ, в конце концов, это был новый тип приложений.

Конечно, серверные приложения не обязаны быть веб-приложениями. У вас мог бы быть и какой-нибудь другой клиент. Но я уверен, что это плохая идея. Было бы очень удобно, если бы можно было допустить, что все установят ваш клиент. Так удобно, что вы могли бы легко себя убедить, что они все так и поступят, но если они не захотят, то вы будете повязаны по рукам и ногам. Поскольку веб-приложения не делают никаких предположений о клиентской стороне, она будут работать везде, где работает веб. А это уже большое преимущество, и оно будет только увеличиваться по мере распространения новых веб-устройств. Вы понравитесь пользователям, потому что ваше приложение просто работает, а ваша жизнь станет проще, потому что вам не придется настраивать его под каждого нового клиента. [16]

У меня такое чувство, что я просмотрел эволюцию сферы веб также подробно, как и любой из нас, но я не могу предсказать, что произойдет с клиентским наполнением. Вероятно, грядет конвергенция, но в какой точке? Я не могу определить лидера. Единственное, что я могу предсказать, это разногласие между AOL и Microsoft. Чем бы в итоге ни оказалась технология Microsoft .NET, она, вероятнее всего, будет включать соединение ПК с сервером. Пока AOL не начнет качать права, их либо отодвинут в сторону, либо превратят в прослойку между клиентом Microsoft и серверным ПО. Если Microsoft и AOL затеют войну за клиента, единственное, что точно сработает для обоих, это просмотр веб-страниц, т.е. веб-приложения будут единственным ПО, которое работает везде.

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

Почему бы и нет?

Э. Б. Уайта позабавил тот факт, что, как рассказал ему друг-фермер, многие изгороди с электрическим током на самом деле не находятся под напряжением. Когда коровы научились держаться от них подальше, уже не было необходимости пропускать ток через изгородь. «Вставайте, коровы! – писал он, – Идите на свободу, пока ваши тираны храпят!»

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

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

Возможно, поначалу вы не сможете зарабатывать больше, чем тратите, но как только этот разрыв начнет достаточно быстро сокращаться, у вас все наладится. Если вы начнете с меньшим количеством денежных средств, то это, по крайней мере, поспособствует выработке привычки к бережливости. Чем меньше вы тратите, тем легче заработать больше своих трат. К счастью, запуск веб-приложения может очень дешево обойтись. Мы запустились с бюджетом меньше $10,000, а сегодня это еще дешевле. Нам пришлось потратить тысячи на сервер, и еще несколько тысяч на SSL. (Единственной фирмой, продающей SSL ПО в то время, была Netscape.) Сейчас вы можете арендовать гораздо более мощные серверы, уже с SSL, и заплатить за это меньше, чем пришлось заплатить нам только за полосу пропускания. Вы могли бы сейчас запустить веб-приложение за стоимость, меньшую стоимости хорошего офисного кресла.

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

А теперь давайте обсудим конкуренцию. То, чего вы боитесь, это не предполагаемые группы программистов как вы, а реальные фирмы, с офисами и бизнес-планами, продавцами и т.д., так ведь? Ну, они больше боятся вас, чем вы их, и правильно делают. Гораздо проще паре хакеров разобраться в том, как арендовать офисное помещение или нанять людей для ведения продаж, чем для фирмы любого размера написать приложение. Я побывал по обе стороны баррикад, и знаю, о чем говорю. Когда Viaweb был куплен фирмой Yahoo, я внезапно обнаружил, что я работаю на крупную компанию, и это было равносильно бегу по пояс в воде.

Я не хочу принижать Yahoo. У них было несколько хороших специалистов, менеджеры высшего звена были настоящими монстрами. Для крупной компании это редкость. Но все же, они продуктивны всего лишь на десятую долю маленького стартапа. И ни одна крупная фирма не сможет сделать лучше. Что в Microsoft пугает, так это то, что такая крупная компания вообще может разрабатывать приложения. Они как гора, которая может передвигаться.

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

Вы, может, и не поверите, но я гарантирую, что Microsoft боится вас. Самодовольные менеджеры среднего звена, может, и нет, но Билл точно, потому что он когда-то был на вашем месте, в далеком 1975 году, когда последний раз появился новый способ распространения ПО.

Примечания

[7] Роберт Моррис написал систему заказов, которую покупатели использовали для размещения заказов. Тревор Блэквелл написал генератор изображений и менеджер, который продавцы использовали для просмотра заказов, статистики, настройки доменных имен, и т.д… Я написал редактор, которым пользовались продавцы для создания своих сайтов. Система заказов и генератор изображений были написаны на C и C++, менеджер — в основном на Perl, а редактор — на Lisp.

[8] Ценовая дискриминация так распространена (как часто вы слышали, чтобы розничный продавец заявлял, что их покупательская способность означала бы более низкие цены для вас?), что я был сильно удивлен, когда узнал, что в США законом Робинсона-Патмана 1936 года она объявлена незаконной деятельностью. К принятию такого закона, кажется, не особо-то и принуждали.

[9] Наоми Кляйн из No Logo говорит, что бренды одежды, пользующиеся популярностью у «городской молодежи», не особо-то и стараются предотвращать магазинные кражи, потому что в их целевом рынке магазинные воры также являются ведущими игроками в моде.

[10] Фирмы часто задаются вопросом, что отдать в аутсорс, а что нет. Один возможный ответ: отдавать в аутсорс любую работу, которая напрямую не подвергается конкурнтному давлению, потому что, таким образом, ее аутсорс подставит ее под это самое давление.

[11] Этими двумя парнями были Дэн Бриклин и Боб Фракстон. Дэн написал прототип на Basic за пару дней, затем в течении следующего года они работали вместе (в основном по ночам) над созданием более мощной версии, написанной на языке компьютера 6502. Дэн в то время учился в Гарвардской школе бизнеса, а Боб официально имел постоянную работу, где писал приложения. «В ведении своего бизнеса не было крупных рисков, – писал Боб, – Если не получится, то не получится. Ничего особенного».

[12] Это не совсем так просто, как я это озвучил. Потребуется много мучительного времени, чтобы сарафанное радио заработало, и у нас не было частых освещений в прессе, пока мы не наняли PR фирму (и правда лучшая в своем деле) за $16,000 в месяц. Однако, правда в том, что единственным значимым каналом был наш собственный сайт.

[13] Если Mac был такой крутой, почему он проиграл? Опять же, дело в цене. Microsoft сконцентрировался на создании ПО, и выпустила толпу поставщиков дешевых компонентов для оборудования Apple. Но это также не помогло, that suits took over during a critical period.

[14] Единственное, что помогло бы веб-приложениям, и удержало бы следующее поколение приложений от being overshadowed by Microsoft, это хороший open-source браузер. Mozilla является open-source браузером, но, кажется, пострадало от слишком длительного пребывания в амплуа корпоративного приложения. Маленький быстрый браузер, который активно бы поддерживали, уже само по себе было бы здорово, а также, возможно, вдохновило бы фирмы на реализацию небольших веб-устройств.

Кроме того, подходящий open-source браузер стал бы причиной дальнейшего развития HTTP и HTML (как, например, это было Perl). Это очень помогло бы веб-приложениям распознавать выделение ссылки и проход по ней; все, что для этого понадобится, будет банальным расширением HTTP, что позволит содержать несколько URL в запросе. Каскадное меню также было бы хорошо реализовать.

Если вы хотите изменить мир, напишите новую Mosaic. Думаете, слишком поздно? В 1998 многие люди думали, что слишком поздно запускать новый поисковый движок, но Google доказал обратное. Всегда есть место для чего-то нового, если текущие решения довольно убоги. Сначала убедитесь, что оно работает на всех бесплатных операционных системах, т.к. новое начинается с их пользователей.

[15] Тревор Блэквелл, который, возможно, из своего личного опыта знает об этом больше, чем кто-либо, пишет: «Я бы добавил, что, т.к. серверные приложения слишком суровы с программистами, это вызывает существенный экономический отток из крупных фирм. От программистов требуется некоторая энергия и преданность делу, которое они смогут проявить только тогда, когда это их собственная фирма. Фирмы по разработке ПО могут нанять опытных людей для работы в не особо требовательной среде, а могут нанять неопытных людей, чтобы они испытывали трудности, но они не могут нанять высококвалифицированных людей, чтобы те надрывались на работе. С тех пор как капитальные вложения перестали быть обязательным элементом, крупные фирмы мало чем могут заинтересовать.»

[16] В первоначальной версии этого эссе я советовал избегать Javascript. Такой план был хорош для 2001 года, но Javascript сейчас и правда работает.

---

Хакеры и художники

Автор: Edison

Источник