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

Сразу скажу, что выводы во многом спорные, но многократно подтверждались на личном опыте. Поэтому буду рад обсудить альтернативные точки зрения.

Как только я опишу идею, у меня её украдут, либо реализуют конкуренты

• Одна и та же идея приходит сразу к множеству людей в актуальный момент. Это можно увидеть даже на примере почти одновременных открытий одних и тех же законов физики в разных странах.
• Идея без реализации не стоит ничего. Предыдущий и этот тезис подтверждается комментаторами в предыдущей статье, которые говорят, что схожая идея была, но было как-то не до неё.
• Пока Вы будете пилить понемногу что-то сами, кто-то уже запустит проект на рынок, т.к. он был сфокусирован и рисковал. У меня также был ряд идей, которые я воспринимал, как слишком сложные для самостоятельного запуска, а спустя полгода-год я встречал сырой, но работающий стартап, который успешно её реализовал.

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

Сначала все надо запатентовать, а уж потом..!

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

• Почти любой патент обходится. Apple патентовала slide to unlock. Android разблокируется кружочком.
• Качественный патент должен быть международным. Российский патент — это приятно, но у Вас весь рынок только в России?
• Грамотное оформление патента стоит очень дорого и оформляется долго. Необходимо провести первичный анализ заявки, написать её так, чтобы патент не обходился в два щелчка. Не говоря уже о других подводных камнях.
• Все слышали о долгих патентных судах. Вы реально считаете, что без должных ресурсов, даже если все было оформлено как надо и нарушение действительно присутствует, у Вас получится добиться гипотетического успеха?
• Большинство «патентов» на программы и базы данных у нас делаются для отчетности. Я участвовал в подаче заявок на такие свидетельства регистрации не раз. Заполняется несколько анкет, прикладывается пара листов с произвольными исходниками, платится пошлина и Вы молодцы. Однако это свидетельство на программу или БД «защищает» не идею, а те самые «пару листов» кода. Получить патент на полезную модель, лежащую в основе работы алгоритма программы или сервиса, существенно сложнее и может занять даже больше времени, чем сама разработка программы и вывод её на рынок. О этом уже писали на habrahabr.

Как только я запущу сервис, сразу появятся заинтересованные клиенты

Для всех участников проекта сервис изначально интересен, они им живут, им дышат. Когда Вы выкладываете продукт, будь то сервис или игра, то рассчитываете, что у проекта сразу появятся постоянные пользователи. Множество разных людей, пробовавших запускать свои продукты, уже не раз писали, что работа по первичной раскрутке часто превышает по сложности работу по разработке продукта. Именно поэтому очень важно как можно раньше вывести продукт на рынок, чтобы подтвердить или, как правило, опровергнуть первоначальные теории и искать пути их корректировки. Если на рынке нет общеизвестных аналогов, то вы встретите двойную стену непонимания по отношению к Вашему продукту со стороны потребителей. Интересно, что с этой же проблемой сталкиваются и крупные компании. Если у компании А есть миллионы пользователей в сервисе B и она запускает сервис С, то даже если сервис полезный, актуальный и востребованный, то будет необходимо приложить существенные усилия, чтобы он обрел должную популярность, но этого может и не случиться. При старте с абсолютного нуля задача усложняется многократно. Примеры подобных историй с разной долей успешности: Google Wave, Google Plus, Microsoft Zune, Windows Phone, BB10, Qiwi яйца, Qiwi: билеты в кино, Yandex: сбор денег.

Еще до первого внедрения я знаю своих клиентов, их проблемы и желания

До пилотного запуска, без значительного опыта в конкретной сфере, вы с очень большой вероятностью не знаете почти ничего. Причем, вы можете прекрасно видеть проблему и её решать, но за это могут быть не готовы платить. Есть много провалившихся массовых проектов, когда клиенты есть и играют/используют сервис, но не платят, или стоимость привлечения новых пользователей больше, чем средняя выручка на одного (ARPU). Эту ситуацию далеко не так просто переломить, как кажется. С огромной вероятностью, Вашу стратегию монетизации необходимо будет корректировать после первых продаж. Именно поэтому инвесторы с большей охотой дают деньги в полных «клонов» каких-нибудь начинающих успешных сервисов, т.к. модель монетизации уже подтверждена и бизнес будет окупаться.

Мы сразу сделаем классный сервис, основательно его проработав

Знаю по себе, что многие айтишники перфекционисты. Необходимо выбрать лучшие инструменты, грамотно спроектировать архитектуру, покрыть все тестами — и будет счастье. Стартап же действует в условиях большой неопределенности. Итоговый продукт, который будет окупаться, может быть совсем не похож на первоначальный. Именно поэтому очень важно быстро выходить на рынок, проводить частые итерации релизов и, к сожалению, иногда существенно менять стратегию, отказываясь от части реализованного функционала. При этом это совсем не значит, что «быдлокод» — наше все. Если делать все наспех, без уделения внимания архитектуре и code review, то в какой-то момент проект станет неподдерживаемым, и изменения будут обходиться очень дорого, как по времени, так и по ресурсам. Скорее всего работу придется начинать заново. Тут очень важен баланс.

Кстати, здесь же кроется проблема для крупных компаний, которых часто обвиняют в медлительности по части обновления продуктов и вывода востребованных новых. Существует конвейер разработки, в который включены продуктовые аналитики, которые ставят бизнес-задачи, системные аналитики, которые формируют задачи для проектных групп и координируют взаимодействие. Группы разработки в крупных компаниях, как правило, занимаются поддержкой и развитием существующих продуктов, действуя поступательно, в соответствии с выбранной архитектурой, постепенно её меняя и основательно тестируя, чтобы убедиться, что все не упадет после релиза. Часто есть QA, куда попадает проект, готовящийся к релизу и товарищи, занимающиеся непосредственно размещением на серверах.

При старте нового продукта в условиях неопределенности требуется менеджер проекта, который будет формулировать бизнес-гипотезы, в соответствии с опытом от текущего продукта, преобразовывать их в задачи для разработки, координируя разработку на определенном уровне, чтобы оперативно решать проблемы и нести за все ответственность. Программисты также не должны быть просто исполнителями, а участниками проекта. Часто именно айтишники видят наиболее эффективные решения проблем, связанных с реализацией какой-либо задачи, т.к. именно они постоянно работают с проектом и досконально представляют себе его архитектуру. Разработчики также могут внести ряд очень интересных эффективных предложений, но координировать, приоритезировать и нести ответственность за принятые решения должен менеджер проекта, т.к. он, в частности, должен отвечать за выполнение показателей (KPI) и фокусировку усилий. Однако это требует иных подходов и опыта от всей команды, которого не получить при стандартном подходе к разработке, который применяют в крупных компаниях. Поэтому же я периодически вижу такие статьи. Они появляются, на мой взгляд, когда менеджер оторван от разработки и не понимает процессов, считая, что все сделается само, либо надо просто надавить. При этом команда разработчиков не посвящается в бизнес-предпосылки определенных задач, а ставится перед фактом, в том числе сжатых до минимума сроков. Совсем интересно, когда кардинально меняется подход к разработке и решаемым задачам, к примеру, переводя команду с развития стабильного продукта, когда изменения внедряются поэтапно, на разработку нового, зачастую меняющегося, как минимум, по части бизнес-требований, пилотного проекта.

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

Буду рад ответить на ваши вопросы, а также узнать мнение о высказанном выше личном опыте.

Автор: GEG

Источник