вторник, 23 марта 2010 г.

Наброски мыслей о стартапах

Эта статья написана для начинающих программистов, кто, начав карьеру, уже задумывается о собственном бизнесе. Нового в статье нет- аккумулированы только основные мысли по данной теме, давно уже высказанные многими успешными предпринимателями.
Начиная карьеру в ИТ, многие молодые специалисты обращают внимание на блоги, где люди деляться своими успехами, продвигают (внешне успешно) свои программы/сайты/услуги. В голове мелькают мысли типа "если у многих получается, то почему бы и мне не попробовать". Очень заманчиво- в 20 лет стать миллионером, и, далее, наслаждаться беззаботной жизнью счастливого рантье. Такие мысли посещают не только ИТ'шников: менеджеры-продажники мечтают открыть свой бизнес, строители- склолотить свою бригаду, бухгалтеры- набрать клиентов и организовать свою аудиторскую фирмочку. В какой-то области это сделать сложнее, в какой-то проще. Но, если в других областях придумать нечто прорывное и сорвать куш практически нереально, то в ИТ, в силу молодости этой области промышленности, такое еще возможно. С одной стороны- это дополнительная степень свободы, с другой стороны- более высокие риски. Зачем я об этом заговорил? Я не собираюсь вас агитировать или отговаривать, если вы задумали начать свой собственный проект. У меня есть некоторые свои соображения и наблюдения по этому поводу, которые я и хочу изложить в этой статье.

  1. Многие пробуют, но только у небольшой доли процента начинающих предпринимателей вообще что-либо получается. Вероятность успеха мизерна. Если один раз не получилось, то и в другой раз вероятность успеха будет такой же, мизерной. Фраза "В этот раз не получилось, значит в следующий раз получится" тут не работает. Может вообще никогда не повезти. А может два раза подряд повезти. Тогда вас назовут гуру, и будут внимательно слушать историю вашего успеха, мечтая также преуспеть.

  2. Когда человек "обрастает" обязательствами (семья, кредиты) риск неуспеха в попытке "самостоятельного плавания" недопустим. Все же, пытаться затеять свое дело лучше смолоду или поставив детей "на крыло" и рассчитавшись с кредитами. Не так давно видел статистику, что в США наибольшая доля стартапов основана людьми в возрасте около 50 лет. Т.е. детей вырастили, в жизни устроились- можно и рискнуть теперь.

  3. Решайте новые задачи или по-новому старые задачи. В 99% случаев я наблюдаю, что пытаются заработать на далеко не новой идее или идее, которую легко скопировать. Посмотрите на мой сайт: www.alvosoft.com/. Моя программа- пример того же неправильного подхода. Я сделал программу, у которой есть аналоги. И сделал ее не принципиально как-то по-новому- она никак среди остальных программ не выделяется. Ну, я никогда и не делал ставку на нее- "проба пера". Не надо делать очередной мессенджер, почтовый сервер. Если некуда девать энергию, то подумайте лучше о том, чтобы присоединиться к разработке существующего ПО интересующей вас тематики.
Третий пункт очень важен. Можно взяться за разработку продукта у которого уже есть куча аналогов. Но это надо сделать блестяще. Чтобы всем стало сразу понятно, что все, что до этого было- ерунда. Например, интерфейс- вспомните пример с GMail. Кардинально улучшить "юзабельность"- как пример, айфон.
Другой путь- сделать инновационный продукт. Такой, о котором только мечтали до этого или даже мечтать боялись. Я помню как начинался skype. У меня был модем, аж на 56кб. Какое там видео/голос передавать, когда и просто загрузка страниц с постоянным перебоями связи была просто мучением! Когда я услышал о skype, я недоуменно пожал плечами: "Что за ерунда?! При зачем надо по интернету голосом говорить?" Интернет в то время был дорог, учитывая низкое качество связи, постоянные перебои- это казалось бредом. Теперь скайпом уже никого не удивишь. Даже бабушки вовсю общаются с внучатами по нему. В любом случае- идея и реализация не должна быть тривиальной.

  1. Надо решать реальную задачу. Покрывать реальные потребности людей. Регулярно на эту тему пишет Петр Диденко: http://www.kip.ru/. Вот не моя задача- вычитал откуда-то, во что инвестор бы вложился: как избавится от очередей в супермаркетах. Актуально? Да. И не вызывает сомнений, что хорошее решение принесет хорошие деньги изобретателю. Решение проблем пробок на дорогах. Динамические карты пробок- это информирование о пробках, но не решение проблемы. Решите проблему, а не лечите ее симптомы!
Лично мне еще нравятся идеи ТРИЗ. Например, доведенное до абсолюта определение идеального изобретения: никакого устройства нет, а функции его выполняются. В более приближенной к реалиям интерпретации: стремится к тому, что изобретение не требовало от пользователя совершения дополнительных действий при пользовании им. Желательно, чтобы количество действий для выполнения той же работы с помощью нового инструмента, наоборот, снизилось. На ум приходит замечательный пример, иллюстрирующий эту мысль. Из года в год в домах отключают горячую воду и промывают систему. Трубы ржавеют, прорываются. Поставлена была задача уменьшить количество аварий. Изобретателем было найдено, на мой взгляд, гениальное решение. При промывке труб с них удаляется налет. Однако налет защищает трубы от ржавления. Было предложено при промывке оставлять небольшой налет для защиты труб. Т.е. изобретение не только не потребовало дополнительных мер, а упростило существующую процедуру промывки- промывать, но не до конца или с меньшей концентрацией чистящих веществ.
Этой же идеей можно руководствовать и в ИТ. Например, возьмем модную ныне тему облачных вычислений. Для нужны датаценты. Можно обойтись без датацентов? А если попробовать, например, сформировать распределенную сеть из компьютеров пользователей? Пользователь, который хочет распределить свои документы по сети для их резервирования и доступности по всему миру, подключается в облачную сеть. Устанавливает на свой компьютер ПО для организации песочницы. В этой песочнице в зашифрованном виде хранятся отдельные кусочки информации от разных пользователей облака. Таким образом, информация мелко-мелко распределяется по другим компьютерам пользователей по всему миру. Знающему пароль, она становится доступна круглосуточно, обеспечивается резервное ее сохранение в сети, да и классические "маски-шоу" с изъятием серверов (см. историю с Агавой) станут невозможны. Таким образом, для создания облака, в данном примере, датацентры не понадобились.
Итоговая мысль такова: "выстрелит" идея или нет- трудно предугадать, но если пробовать, то делать надо что-то принципиально новое или старое, но принципиально по-новому. Пользователю при использовании изобретения должно быть легче, чем без использования его.
PS: лично для меня ненапряжность нового сервиса в интернете стало играть весомую роль, например, если меня просят зарегистрироваться, то я не буду пользоваться таким сервисом. Мне лень это делать, ведь есть же OpenID- вот пусть его и используют. Это к вопросу о том, что требование лишних движений со стороны пользователя может привести к отказу от использования вашего изобретения.