Railorz - Блог Алексея Дмитриева

Кастомизация кода под клиентов

2012-02-13T11:20:00Z

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

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

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

Модульная структура проекта

Если у вас есть хотя бы мало-мальский опыт программирования, то вам не надо объяснять что такое разбивка проекта на модули. Часть функционала системы выносится за пределы основного проекта – вот собственно и все. В языке Ruby такими модулями могут быть gem-ы, в PHP это PEAR-пакеты, ну и так далее. Суть одна – кусок функционала системы, который опционально устанавливается и настраивается для клиента.

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

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

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

Клонирование кода

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

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

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

Допустим, наш основной код хранится в репозитории git@myserver:myrepo.git и мы хотим создать копию кода для клиента, которая будет лежать в отдельном репозитории git@myselver:client_1.git. Для начала, мы создаем локальную копию кода для клиента:

1	$ git clone git@myserver:myrepo client_1

Отлично, копия есть. Однако, эта копия привязана к нашему исходному репозиторию:

$ cd client_1
$ git remote show origin

  * remote origin
  Fetch URL: git@myserver:myrepo.git
  Push  URL: git@myserver:myrepo.git
  ...

Нам нужно отвязать нашу копию от исходного репозитория и привязать к новому:

1
2
3

$ git remote rm origin
$ git remote add origin git@myselver:client_1.git
$ git push -u origin master

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

1 2	$ cd client_1 $ git pull git@myserver:myrepo.git master

Так как большинство коммитов в клиентском репозитории идентичны коммитам в исходном репозитории, то Git импортирует исключительно те коммиты, которых нет в клиентском репозитории. Все конфликты между коммитами (если таковые возникнут) можно будет разрешить используя стандартные механизмы Git. Останется только залить изменения в репозиторий:

1	$ git push

Для упрощения импорта коммитов можно прописать основной репозиторий в remote-ссылки клиентского репозитория:

1	$ git remote add main_repo git@myserver:myrepo.git

И использовать ссылку вместо адреса для импорта:

1	$ git pull main_repo master

Кроме того, импортировать можно и из различных веток или тегов:

1 2	$ git pull main_repo tags/stable $ git pull main_repo experimental_feature

Вполне вероятно, что этот же подход можно использовать и с другими распределенными системами контроля версий, такими как Mercurial. Если я не прав – поправьте меня.

Итого

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

Используйте модули тогда, когда функционал повторяется от клиента к клиенту, но его нельзя включить в основной код
Используйте клонирование кода тогда, когда изменения разумнее сделать напрямую в коде проекта, нежели писать для этого отдельный модуль

Событийный игровой сервер

2012-01-13T09:00:00Z

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

Наш основной проект на момент написания этой заметки – игра Witchcraft – написан на Ruby on Rails. Начать разработку онлайн-игры именно на Rails не было каким-то сознательным решением, скорее так исторически сложилось, что мне очень нравилось программировать на Rails и я готов был все что угодно делать с помощью этой технологии, не взирая на уместность. У текущей реализации проекта есть один несомненный плюс – она работает. Но есть и ряд существенных минусов, от которых я сильно хочу избавиться и которые мы стараемся исключить при разработке нового продукта.

Минусы текущей реализации

Игровая механика жестко ограничена соглашениями Rails. Каждое действие игрока может генерировать только один результат, только один ответ от сервера. Например, при клике по кнопке миссии можно только вернуть результат выполнения миссии, но не событие о получении нового уровня или об открытии новой миссии. Конечно, все можно сделать, однако код для такой логике абсолютно противоречит структуре традиционного rails-приложения.
Возможности общения сервера с клиентом ограничены ответами на HTTP-запросы. Любая попытка реализовать отправку сообщения с сервера на клиент вне контекста конкретного запроса выглядит совершенно ортогонально концепции Rails.
Использование базы данных для хранения игрового контента и данных игрока жесточайше и главное совершенно бесполезно растрачивает серверные ресурсы на загрузку/сохранение данных при выполнении мелких действий, из которых собственно и строится интерактивный игровой процесс.
Завязанность визуализации игрового процесса на сервер. В Witchcraft подавляющая часть всего визуального представления игры генерируется сервером. Все страницы, результаты действий, сообщения пользователю, диалоги – все это в виде HTML поступает с сервера. На клиенте происходит самый минимум – навешивание событий на кнопки и ссылки, которые опять же вызывают сервер для генерации результатов событий. В отличие от бизнес-приложений, где один клиент генерирует 10-15 запросов за сессию, игрок выполняет 50-1000 действий за игровую сессию, потребляя ощутимое количество ресурсов.

Эти проблемы натолкнули меня на мысль разработать игровой сервер, более соответствующий природе игр, где весь процесс строится на базе событий.

Событийный игровой сервер

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

В процессе работы над прототипом игрового сервера у меня выкристаллизовалась система, состоящая из клиента, транспорта, очереди событий и игрового демона.

Игровой клиент

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

Транспорт

Для доставки событий от клиента на сервер и обратно я решил испробовать WebSocket – эта технология оказалась наиболее подходящей для асинхронного обмена данными. На стороне сервера я поставил Rack middleware прямо на Rails-приложение, обработку websocket-ов реализовал с помощью гема faye-websocket. Клиент подключается к серверу и отправляет сообщения о событиях, сервер сваливает полученные сообщения в очередь событий для обработки игровым демоном, выгребает из очереди события, сгенерированные игровым демоном для данного игрока, и отправляет их на клиент. Обмен данными происходит асинхронно.

Очередь событий

Хранение очередей входящих и исходящих игровых событий я пока решил реализовать через Redis, так как с ним я более-менее знаком и в нем хорошо реализована возможность создания списков объектов. События пишутся в ключи, соответствующие игровой сессии – ‘game_123_incoming’ для всех входящих от всех игроков, ‘game_123_ougoing_player_*’ – для исходящих, адресованных конкретным игрокам.

Игровой демон

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

Предолагаемые проблемы

На данный момент это экспериментальная схема, но она весьма неплохо работает, по крайней мере на девелоперской машине :) Однако я заранее предвижу несколько проблем, которые могут возникнуть:

JS-клиент может достаточно сильно тормозить при активном рендере. Это частично можно скомпенсировать пре-рендером части шаблонов, а так же переходом на какие-либо более быстрые средства рендеринга – Flash, Unity, нативный клиент.
Websocket – новая технология, поддерживается не всеми браузерами. Эту проблему можно обойти, используя Flash-сокеты, уже даже есть готовые решения. На крайний случай доставку событий от клиента можно реализовать обычными HTTP-запросами, а от сервера клиенту – через long-polling.
Redis – не самый подходящий инструмент для хранения очередей. При необходимости его можно заменить на что-то более подходящее для организации очередей. Например, RabbitMQ.
Игровой демон на ruby может оказаться достаточно медленным при большом количестве игровых сессий. Это решается распределением сессий между несколькими демонами и/или переписыванием игровой логики на более быстрые языки – Java, Erlang, C++.

Преимущества

У данной схемы помимо недостатков есть и определенные преимущества:

Слабая связность компонентов позволяет менять технологии и инструменты одного компонента без особого влияния на все остальные. При желании JS-клиента можно отдавать не рельсами, а голым nginx-ом, websocket-ы обрабатывать сервером на C++, игровой демон переписать на Java, а очередь хранить RabbitMQ.
Относительная универсальность системы позволяет разрабатывать игры совершенно разных жанров – стратегии, rpg, тетрисы и кроссворды – используя одну и ту же инфраструктуру. Все отличия заключаются в двух компонентах – логика игровой сессии и клиент. Все остальное остается неизменным.

В целом, эксперимент сам по себе оказался весьма интересен и позволил немного отстраниться от привычной схемы разработки приложений.

Идея есть. Как на ней заработать?

2011-09-12T08:00:00Z

Вопрос, вынесенный в заголовок, наверное самый интересный вопрос бизнеса как такового. А ответ на него – самый важный для того, чтобы простое увлечение превратилось в источник прибыли.

Вообще, практически каждую идею можно монетизировать несколькими способами. Мы сейчас рассматриваем разработку ПО, поэтому давайте подумаем над тем, каким образом можно монетизировать разработанный программный продукт.

Продажа самого продукта

Самый простой и логичный подход – вы делаете продукт, за использование которого люди платят вам деньги. Таким способом зарабатывают все без исключения разработчики софта, которые выставляют ценник на свой продукт.

Продажа расширений и дополнительных модулей

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

Платная поддержка

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

Доработки и дополнительные услуги

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

Реклама в продукте

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

Пожертвования и поддержка спонсоров

Пожалуй, этот способ монетизации я бы назвал наименее перспективным в плане финансов. На мой взгляд, люди с гораздо большей вероятностью заплатят $100 за платный продукт, чем пожертвуют $100 на бесплатный. Единственный продукт, собиравший неплохие суммы пожертвований, который я знаю – это Phusion Passenger. Но я абсолютно уверен, что и для команды Phusion этот способ монетизации их продукта далеко не самый приоритетный :)

Ищем Ruby-программиста в Челябинске

2011-09-08T14:00:00Z

Мы ищем новых Ruby-программистов в команду. Подробности вакансии можно посмотреть на сайте RubyJobs

Если у вас есть знакомые веб-программисты в Челябинске – не постесняйтесь скинуть им ссылку :)

В поисках идеи

2011-08-29T08:00:00Z

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

Кристаллизация идей

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

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

Чтобы вытащить на свет мало-мальски стоящую идею, нужно на время приостановить поток поступающей информации и дать зернам идеи прорасти. Я это делаю так:

Отключаю все входящие потоки информации – отрываюсь от компьютера, вырубаю телефон, ухожу куда-нибудь, где я могу побыть один (тихая комната, кафе, парк) или просто прошу близких меня какое-то время не беспокоить.
Беру ручку и чистый блокнот. Я не единожды пробовал записывать мысли сразу в компьютер, но чаще всего это заканчивалось тем, что паузу в размышлениях сама собой заполнялась какой-нибудь активностью (типа чтения почты или твиттера) и все идеи куда-то выветривались. Записывать в разного рода гаджеты мне тоже не очень удобно, потому как сам по себе процесс набирания текста на телефоне или планшете требует немалых мозговых усилий. Так что ручка и бумага для меня – идеальный вариант.
Выбираю какую-то из крупных идей, которые плавают на поверхности. У меня в голове идеи чаще всего выглядят так: “Было бы прикольно сделать доску объявлений о продаже авто, в которой будет такая штучка, делающая то-то и вот так-то”. Из этой мысли я беру идею “сделать доску объявлений о продаже авто” или даже просто “сделать доску объявлений”.
Выписываю на бумагу все возможные детали реализации идеи, которые могут прийти в голову. Не важно, относятся ли они к дизайну, разработке, развертыванию, маркетингу, организации работы или тому, как будет выглядеть мой офис если я займусь этой идеей. Все подряд, без всякого порядка, очередности, приоритетов, ограничений по длине предложений и качеству написания, без оглядки на возможность или невозможность воплощения. Короче, вываливаю все подряд. Этот список не увидит никто, кроме меня. Это, можно сказать, дамп, резервная копия идеи как таковой, в том виде, в котором ее выдает мозг. Просто пишу все подряд как приходит в голову.
Как только идеи закончились и ничего больше не пишется – откладываю ручку и делаю паузу 5-10 минут. В это время важно сохранять всю ту же информационную тишину. Закрываю глаза, смотрю в окно, принимаю душ – не важно. Главное – минимум входящей информации.
Если в течение перерыва не пришло больше никаких мыслей – перечитываю то, что написал. Если в мозгу еще остались какие-то остатки, не изложенные в списке – они скорее всего всплывут при перечитывании или в течение следующих нескольких минут. Если ничего нового не всплыло – можно считать идею готовой для систематизации.
Через несколько часов, максимум – пара дней, я эту идею высказываю вслух кому-то из друзей или близких людей, подглядывая в конспект. При этом не так важно, разбирается ли человек в том, что я ему говорю (хоть это и желательно), важно чтобы он внимательно выслушал до конца. По ходу высказывания мозг заново переваривает идею, облекая ее в понятные другому человеку термины, и чаще всего при этом рождаются какие-то новые мысли, детали и мелочи, упущенные при первом изложении или на тот момент просто не существовавшие. Эти идеи тоже обязательно записываю в тот же список. Наиболее интересные свои идеи я рассказываю поочередно нескольким людям – сначала тем, кто не разбирается в деталях реализации совсем (жена, теща), потом тем, кто более-менее в теме (друзья из смежных областей работы – дизайнеры, верстальщики, маркетологи, сеошники), и в самом конце – коллегам по цеху (программистам, админам).

Систематизация идеи

Для того, чтобы начать работу над идеей, нужно ее хотя бы немного систематизировать. Я использую всего два критерия систематизации – категории задач и приоритеты.

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

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

Отбор идей

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

Для оценки идей я использую следующие критерии в порядке приоритета:

Финансовая привлекательность, объем потенциальной прибыли, критерии и срок выхода на самоокупаемость. Тут важно оперировать конкретными цифрами. Если ориентируемся на продажу рекламы – берем минимальную рыночную стоимость рекламы в нашем сегменте. Если планируем продавать продукт – считаем объемы продаж исходя из минимального процента конверсии (не более 1-3% от общего числа пользователей). Если продаем услугу – считаем прибыль для наиболее дешевого пакета. Лучше строить бизнес на минимальных цифрах, в этом случае все что сверх минимума – чистая прибыль.
Полезность. Нет никакого смысла делать вещи, которыми никто не будет пользоваться. Кто наши потенциальные покупатели? Чем наш продукт им поможет? Буду ли я сам пользоваться нашим продуктом? Идеальный вариант – это делать продукт, который решает мою собственную проблему. В этом случае клиентами наверняка станут те, у кого есть та же самая проблема.
Временные и финансовые затраты. Могу ли я себе это позволить? Смогу ли я воплотить идею в течение 2-3 месяцев при текущей загруженности? Где я возьму финансы на первоначальные затраты (домен, хостинг, покупка ПО, зарплата сотрудников, офис)? Любой бизнес требует затрат – это норма. Нужно лишь понимать, где взять денег и сколько. Продавать квартиру и бросать работу ради мифической идеи очень романтично, но может и оказаться просто-напросто гибельно.
Интересность с точки зрения реализации. Делать что-то полезное и выгодное, но банальное – скучно. Мы программисты, на важно делать что-то новое и интересное. Какие новые технологии можно использовать в новом проекте? Чем он будет отличаться от того, что мы делали раньше? Важно понять, какой опыт можно получить при работе над этим проектом, даже если он не принесет денег напрямую.
Наличие готовых альтернатив. Если уже есть готовые продукты, в которых ваша идея реализована как минимум на половину – имеет ли смысл делать новый продукт? Я не имею в виду что это бессмысленно, я говорю о том, что стоит ответить на вопрос: чем ваш продукт будет отличаться от существующих? Какие проблемы новый продукт будет решать лучше? Можно ли эти проблемы решить комбинацией из двух уже существующих продуктов? Насколько легко существующие продукты смогут повторить инновацию?

Резюмируя, можно сказать следующее: не бойтесь идей и не бросайтесь ими. Переносите идеи на бумагу как только они приходят в голову, рассказывайте о них своим друзьям и знакомым, выбирайте наиболее интересные и перспективные идеи – и действуйте!