Волчков
точка ру



Домен или IP:

Мой IP
  Обмен валют
  WHOIS
 
  Доменные
новости
  Новости Сети
  Самые дорогие доменные имена
  Самое длинное доменное имя Рунета
  Список регистраторов домена RU
  АКЦИЯ
  Энциклопедия контента
 
 
 
  В закладки
  Стартовой
 




Самые трудные уроки для стартапов, часть I
11.06.2006 00:51:46

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

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

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

1. Выпускайте рабочую версию как можно раньше

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

Быстрый выпуск первой версии оправдан по ряду причин. Во-первых, просто потому, что это оптимальный метод программирования, и не только для стартапов. Я утверждаю это с 1993 года и до сих пор не встречал особых тому опровержений. Множество стартапов погибло из-за того, что они слишком затягивали релизы, и ни один - благодаря тому, что выпускал продукт слишком быстро. [1]

Одно из неожиданных открытий, которое вас ждет, если вам удастся создать нечто популярное - это то, что вы не будете знать своих пользователей. У Reddit сейчас почти полмиллиона уникальных посетителей в месяц. Кто эти люди? Команда Reddit понятия об этом не имеет. И ни один web-стартап этого не знает. А поскольку вы не знаете своих пользователей, то очень рискованно пытаться угадать,что им понравится. Гораздо лучше выпустить нечто и прислушаться к их мнению.

Wufoo восприняли этот мой совет близко к сердцу и выпустили генератор форм еще до создания базы данных. Машина еще не ездит, а уже 83 тысячи человек пришли посидеть в водительском кресле и подержаться за руль. Подобный подход дал Wufoo ценную обратную связь: пользователи Linux жаловались на излишнее использование Flash, поэтому разработчики избавились от Flash, переписав программу. А вот если бы они решили выпустить все сразу, то к моменту обнаружения проблемы она была бы внедрена уже гораздо глубже.

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

И, пожалуй, самый главный аргумент за быстрый выпуск состоит в том, что он заставляет вас больше работать. Когда вы работаете над еще не выпущенным продуктом, появление проблем вызывает любопытство. Но их появление в уже выпущенном продукте вызывает сильную тревогу. Как только вы выпустите продукт, у вас появится намного больше безотлагательных задач. Мне кажется, что именно поэтому разработчики затягивают выпуск, они знают: как только он состоится - им придется работать гораздо больше. [2]

2. Продолжайте наращивать возможности

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

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

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

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

И это не только хорошая методика разработки, но и маркетинговый ход. Пользователи любят постоянно улучшающиеся сайты. Ведь на самом деле они ждут от сайта улучшений. Представьте: вы посетили очень хороший сайт, затем вернулись через два месяца, а он ни на йоту не изменился. Разве он не покажется вам никудышным? [3]

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

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

Как только продукт избавлен от вопиющих недостатков, вы начинаете к нему привыкать и постепенно отождествляете его с набором уже реализованных в нем возможностей. Например, я сомневаюсь, что кто-нибудь в Yahoo! (или Google) осознавал, насколько лучшей может быть web-почта, пока Paul Buchheit им это не продемонстрировал.

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

Сноски


     

  • [1] Стартап может погибнуть из-за выпуска продукта, полного ошибок, к тому же недостаточно быстро исправляемых. Но мне неизвестен ни один стартап, погибший из-за очень раннего выпуска минимального стабильного продукта и быстрой его доработки.
  • [2]Я знаю, что именно поэтому я так и не выпустил Arc. Как только я это сделаю, меня начнут донимать запросами новых функциональностей.
  • [3] Web-сайт в этом отношении отличается от книг, фильмов и десктоп-приложений. Пользователи расценивают сайт не как отдельный снимок, а как фильм с множеством кадров. Сравнивая два фактора между собой, я бы сказал, что скорость изменений для пользователей важнее, чем текущее состояние. / Интернет.ру


<<Назад

Материалы по теме:
15.06.2006 01:57:13 Самые трудные уроки для стартапов, часть IV
15.06.2006 01:55:58 Самые трудные уроки для стартапов, часть III
15.06.2006 01:40:42 Самые трудные уроки для стартапов, часть II
30.03.2006 09:59:46 Самые дорогие слова в AdWords, «Директе» и «Бегуне»
19.12.2005 14:59:14 Лучшие программы Web 2.0 этого года
Все новости по теме

Отзывы (0)

Добавить отзыв






Новости Сети
« июнь 2006 »
пн   5 12 19 26
вт   6 13 20 27
ср   7 14 21 28
чт 1 8 15 22 29
пт 2 9 16 23 30
сб 3 10 17 24  
вс 4 11 18 25
Заголовки всех новостей

© 2000 Volchkov.ru