Пол Грэм, «Хакеры и художники», глава 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] Веб-приложения предлагают прямой путь к тому, чтобы превзойти ваших конкурентов. А&
