Original text of Paul Graham

Перейти к начальной статье "18 роковых ошибок..."

Выбор неправильной платформы

Эта проблема связана с предыдущей – именно плохие программисты выбирают неверную платформу. К примеру, в девяностые годы многие стартапы обрекли себя на гибель, решив строить серверные приложения на базе Windows. Hotmail ещё годы после того, как его купила Microsoft, стоял на операционной системе FreeBSD – вероятно, потому, что Windows не могла справиться с аналогичной загрузкой. Если бы основатели Hotmail изначально решили использовать Windows, их бы буквально завалило.

А вот PayPal повезло и они удачно увернулись от пули. После их объединения с X.com, новый исполнительный директор хотел перейти на Windows – и после того, как один из основателей PayPal Макс Левчин продемонстрировал что на Windows их программное обеспечение достигало только 1% от производительности на Unix. К счастью, вместо смены платформы PayPal сменил исполнительного директора.

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

Всегда есть такие платформы, которые аутсайдеры сочтут прекрасным выбором для себя, но если они его сделают, то он подобно выбору Windows в 90-е погубит их. Самый эффектный пример – Java апплеты, которые убили почти 100 % стартапов, которые поверили в них как в новый путь поставки приложений.

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

Слишком медленный выпуск

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

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

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

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

Слишком быстрый выпуск

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

Советую разработать план работ, определить ядро продукта, которое будет а) полезно само по себе и б) может быть постепенно расширено до целого продукта.

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

Первые пользователи, которых вам нужно впечатлить, обычно терпимы и не ждут от только что запущенного продукта универсальных возможностей; продукт просто должен что-то делать.

скачать Valon.Doc - программу для ускорения работы с документами