Пол Грэм: Ошибки, которые убивают стартапы (2) - продолжение
27 декабря 2011 в 14:38

Пол Грэм: Ошибки, которые убивают стартапы (2) - продолжение

Пол Грэм: Ошибки, которые убивают стартапы (2) - продолжениеВ некотором смысле, стартапы убивает одна-единственная ошибка: вы делаете не то, чего хочет целевая аудитория. Если вы сможете предложить то, что будет востребовано целевой аудиторией, вероятно, вы добьетесь успеха независимо от того, что вы делаете или чего не делаете помимо этого. А если вы предлагаете не то, чего от вас ждут, то вы обречены на неудачу независимо от всего остального. Далее я привожу 18 причин, по которым стартапы оказываются совсем не тем, чего хочет целевая аудитория.

Неправильно выбранная платформа
С предыдущим пунктом связана другая проблема (поскольку подобные решения принимают плохие программисты) – это неправильный выбор платформы. Например, я считаю, многие стартапы периода краха доткомов оказались неудачными из-за решения заниматься разработкой серверных приложений на Windows. Сервис Hotmail продолжал работать на базе FreeBSD в течение еще нескольких лет после его приобретения компанией Microsoft: сервера на Windows не могли справиться с такой нагрузкой. Если бы основатели Hotmail использовали Windows, почтовик бы обречен.
PayPal также был близок к тому, чтобы прекратить существование. После слияния с X.com новый исполнительный директор хотел перейти на Windows даже несмотря на то, что один из основателей PayPal Макс Левчин утверждал, что на Windows сервис будет масштабироваться лишь на 1% от возможностей Unix. К счастью для PayPal, вместо этого они поменяли исполнительного директора.
Платформа – понятие расплывчатое. Оно может означать операционную систему, язык программирования или фреймворк. Платформа – как фундамент дома, поддерживает строение, но и накладывает ограничения.
С платформами связана следующая опасность: та или иная платформа может показаться подходящей человеку со стороны, но выбор этой платформы погубит весь проект, как было в случае с Windows в 90-х. Java-апплеты – один из ярчайших примеров. Они должны были стать новым способом доставки приложений. Предположительно, они погубило 100% стартапов, основатели которых разделяли веру в технологию.
Как подобрать правильную платформу? Пригласить классных программистов и предоставить им возможность выбирать. Но даже если вы не программист, есть один хороший способ сделать правильный выбор: посетите факультет информатики известного университета и посмотрите, что они используют в исследовательских проектах.

Промедление с запуском
Компании любого уровня переживают нелегкие времена, работая над программным обеспечением. Это отличительная особенность индустрии: программа всегда готова только на 85%. Бывает достаточно тяжело переступить через себя и объявить о релизе. (Стив Джобс пытался мотивировать своих сотрудников словами “настоящие художники выполняют заказ вовремя”. Это отличные слова, но, к сожалению, это неправда. Многие известные произведения искусства так и остались незаконченными. Это утверждение верно для направлений, в которых работа ограничена определенными сроками, например, для архитектуры и кино, но даже там есть тенденция тянуть с представлением готового продукта до последнего).
Основатели ищут любые оправдания, чтобы отложить запуск. Большинство из них совпадает с причинами прокрастинации в повседневной жизни. Сначала должно что-то произойти. Наверное. Но если бы программа была готова на 100% по нажатию кнопки, разве кто-нибудь стал бы ждать?
Одна из причин для скорейшего запуска заключается в том, что в этом случае вы будете вынуждены действительно закончить какую-то часть работы. Ничто не может считаться финальным пока вы не запустились. Об этом свидетельствует огромное количество работы, сопровождающей любой релиз, независимо от того, насколько готовым к релизу казался ваш продукт. Другая причина не медлить с запуском заключается в том, что только по реакции ваших пользователей на идеи, у вас образуется полная картина.
Некоторые стандартные проблемы выливаются как раз в промедление с запуском: слишком медленная работа, непонимание проблемы на самом деле, страх перед реакцией пользователей, боязнь оценки, работа над большим количеством разных задач, чрезмерный перфекционизм. К счастью, есть простое средство справиться с такими проблемами: просто заставьте себя запустить что-нибудь достаточно быстро.

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

Отсутствие представления о пользователе
Нельзя создать продукт, который понравится пользователю, не зная его. Ранее я уже говорил, что большинство удачных стартапов начинались, как попытки разрешить какие-то проблемы, с которыми сталкивались основатели. Можно вывести правило: качество вашего продукта пропорционально пониманию проблемы, которую вы хотите решить, а собственные проблемы вы всегда понимаете лучше, чем проблемы кого-то еще. (Может иметь значение еще один фактор: основатели пытаются пользоваться новейшими технологиями, так что проблемы, которые они пытаются решить, наиболее актуальны).
Но просто теория. Обратное утверждение, впрочем, верно всегда: если вы пытаетесь решить проблему, не понимая ее сути, у вас нет шансов на успех.
На удивление много основателей, похоже, предполагают, что кому-то, причем точно неизвестно, кому, понадобится их продукт. Нужно ли он основателям? Нет, они не целевая аудитория. А кто тогда? Молодежь. Люди, интересующиеся местными событиями (вот это перманентная ловушка). Или бизнесмены. Но какой отрасли? Автозаправки? Киностудии? Оборонные предприятия?
Конечно, можно заниматься проектами, не актуальными для себя, а только для пользователей. Мы так делали. Но нужно понимать, насколько это рискованное предприятие. Фактически, вы летите по приборам, поэтому необходимо (а) осознавать, когда перестраиваться, не полагаясь на интуицию, и (б) следить за приборами.
В данном случае приборы – это ваши пользователи. Работая для других людей, вы не имеете права на ошибку. Вы не можете просто гадать, что сработает, а что нет; вам нужно найти пользователей и наблюдать за их реакцией. Поэтому, если вы собираетесь делать продукт для молодежи, или для бизнесменов, или для любой другой группы, в которую вы сами не входите, вам придется научиться убеждать таких людей в том, что им нужен ваш продукт. Если вы не сможете этого сделать, вы на пути в никуда.

Недостаточные инвестиции
Большинство стартапов привлекают внешнее финансирование на том или ином этапе. Как и присутствие нескольких основателей, это преимущество хотя бы и по статистике. Но сколько денег следует инвестировать в проект?
Финансирование стартапов связано со временем. У каждого не приносящего прибыли стартапа (то есть, изначально, почти у всех) есть определенное количество времени, пока не закончатся деньги и не придется остановить проект. Иногда, по аналогии с авиацией, его называют длиной разбега; часто спрашивают: сколько длины у вас осталось для разбега? Хорошее сравнение, потому что оно напоминает о том, что как только деньги кончатся, вы либо взлетите, либо погибните.
Поэтому, если вы берете деньги у инвесторов, необходимо взять сумму, достаточную для перехода на следующий уровень, каким бы он ни был. (Нужно брать в полтора-два раза больше той суммы, которая, по вашим прогнозам, вам потребуется, потому что на написание программ и на заключение сделок уходит больше времени, чем вы думаете). К счастью, вы можете контролировать свои расходы и думать о следующих шагах. Наш совет – первое время тратьте по минимуму, и просто сконцентрируйтесь на создании надежного прототипа. Это даст вам пространство для маневров.

Слишком большие расходы
Сложно провести грань между слишком большими расходами и слишком маленькими инвестициями. Если у вас кончаются деньги, причиной может быть как первое, так и второе. Единственный способ понять, в чем дело, это провести сравнение с другими стартапами. Если вы получили $5 миллионов инвестиций, и у вас кончились деньги, вероятно, вы тратили слишком много.
Необоснованно большие расходы теперь встречаются крайне редко. Основатели, похоже, выучили урок. Кроме того, основывать стартапы постепенно становится дешевле. На момент написания данной статьи слишком большие расходы имели место всего в нескольких стартапах. Ни в одном из финансируемых нами проектов мы не столкнулись с данной проблемой. (И не только потому, что мы не инвестируем большие суммы; многие стартапы в дальнейшем получили дополнительные инвестиции).
Наиболее распространенный способ потратить больше, чем следует, это набрать большой штат сотрудников. Так вы не только увеличиваете расходы, но и замедляете свою работу – вы не только больше тратите, но и сроки приходится закладывать длиннее. Большинство хакеров понимает, почему так происходит; Фред Брукс объяснил это в книге ”Мифический человеко-месяц“.
У нас есть три предложения по набору персонала: (а) не набирайте людей, если без них можно обойтись, (б) предлагайте сотрудникам долю в компании, а не фиксированный оклад. Не только потому, что это способ сэкономить, но и потому, что вам нужны преданные сотрудники, готовые согласиться с такой формой оплаты; и (в) нанимайте только тех, кто будет или писать код или привлекать пользователей, потому что это единственное, что вам потребуется на первом этапе.

Источник http://rocid.ru/news/1606-graham/

656
Комментарии (0)

Выберите из списка
2019
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008