6 Мая 2013 / Статьи

Станислав Протасов о том, как инженеру стать предпринимателем 

Станислав Протасов о том, как инженеру стать предпринимателем

Сооснователь и глава разработки Parallels Станислав Протасов объясняет, о чем стоит знать техническому человеку, который запускает стартап.

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

Как инженеру стать предпринимателем? Для начала надо развивать в себе self awareness, самосознание. Мы всегда чуть более хорошего мнения о себе, чем нужно. Надо уметь видеть собственные слабости. У инженеров, как правило, нет опыта в бизнесе, и это их слабая черта. Поймите это и начните нивелировать пробелы. Сделайте, например, план. Пусть он даже будет наивным: встретиться с состоявшимся предпринимателем и обсудить свою идею или пойти поучиться. Выглядит смешно? Нестрашно. Зато это позволит адекватно посмотреть на себя и развиваться. Слишком часто я вижу ситуации, когда два инженера делают стартап и каждый думает «ну да, я не очень силен в бизнесе, но у меня есть партнер, он закроет эту часть». А тот ровно такой же технарь и думает так же.

Люди начитаются статей в СМИ, наслушаются этих популярных тезисов современности – «не работай на дядю» и прочее – и думают, что бизнес для молодых и дерзких. Но в создании бизнеса важен инсайт. Идея стартапа действует на инженеров, как удав на кролика, логика просто пропадает. Это удивительно: у технического человека развита та часть мозга, которая отвечает за рациональное мышление. Занимаясь привычной работой, его инсайт – понимание, как, имея на руках факты, обработать их и найти решение. Но начиная бизнес, он почему-то эту логику игнорирует. Где мы возьмем деньги? Кто и почему будет покупать наш продукт? Почему-то он предпочитает закрыть глаза и, вместо того, чтобы, как и обычно, проанализировать ситуацию, двигается наощупь.

Многие умные, хорошие программисты проваливают стартапы потому что забывают про план, хотя как минимум цикл релиза должны знать, как планировать. А надо работать, как привык: составил план и двигаешься по нему. Осознали, что план не работает, меняем – продолжаем двигаться к цели. Закрывать глаза нельзя.

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

Техническое образование имеет свою специфику – инженеру ужиться с корпоративным человеком сложно. Просто они видят мир по-разному. Естественные науки развивают, с одной стороны, способность логически мыслить, а с другой – гордость за свое дело, честность – это очень важно, когда разрабатываешь продукт. У хорошего инженера нетерпимость к подтасовке фактов. У корпоративного человека все иначе: если СЕО скажет, что черное это белое – значит, так и есть. Я не говорю здесь о том, хорошо это или плохо – просто некая данность, которая тоже может привести к конфликтам в команде. Каждая команда такие проблемы решает по-своему. Готового рецепта нет.

Несколько лет назад я был на одном стартаперском мероприятии. Там был довольно неплохой проект из Сибири. С инженерной точки зрения ребята были светлые – технология имела право на жизнь и они могли это обосновать. Кто-то из инвесторов спросил их, сколько денег они ищут. Лидер ответил, что полмиллиона долларов. На что потратите? Половину – на разработку, остальное на наем профессионального СЕО из Америки. Очень типичная ситуация. Инженеры, когда дело доходит до бизнеса, ищут «волшебную палочку». Надо ли говорить, что ее нет. А давайте наймем задорого человека, который много продавал – он отстроит нам продажи. Ошибочная гипотеза – опыт показывает, что прошлые заслуги не гарантируют будущие успехи. Поэтому шансы, что человек оправдает возложенные на него ожидания, не очень велики. Это все о том же – не надо надеяться на волшебство и волшебников.

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

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

Инженеры часто преувеличивают роль технологии. Ничего удивительного. Вряд ли обычный человек будет говорить о том, что ядро «Линукса» красивое – во-первых, он не знает, как оно вообще выглядит, а во-вторых, ему все равно. А инженер всегда оценивает красоту технического решения. Но правда в том, что в бизнесе технология вторична. Это не значит, что ей можно пренебрегать, но конечный успех зависит в большей степени от других вещей – от того, правильно ли выбрана цель и путь к ней, например.

В 2000 году мы начали делать продукт, который потом получил название Parallels Virtuozzo Containers. Его частью должна была стать менеджмент-консоль, через которую можно было менять параметры услуги. Согласно первоначальному плану, под ней должна была лежать база данных. В инженерной команде возник принципиальный спор: что использовать – MySQL или Postgress. Это была эпическая битва, поверьте. Люди едва не плакали. Я получил кучу заявлений в духе «раз так, то я ухожу». В какой-то момент спор пришлось решить волевым путем. Ну и что вы думаете – в финальной версии базы данных вообще не было. Это о роли и месте технологий в бизнесе.