стоимость генерации бизнес-идей и бизнес-планов

1. чтобы сгенерировать качественную бизнес-идею нужно отправить в путешествие по первому миру на период от 2х недель до 6ти месяцев,
все остальное сделанное без путешествия — будет клоном уже имеющегося (из ничего не выйдет ничего — это не я придумал эту фразу)
2. такое путешествие стоит от 2К$ до 20K$
3. процесс кристаллизации идеи в голове занимает от 2х недель до 2х месяцев растянутых на неизвестный период
4. затем идет процесс написания бизнес-плана в процессе чего идея трансформируется и обрастает под-идеями, написание первой версии бизнес-плана на несколько десятков страниц занимает от 2х до 4х недель
5. итого, если исходит из месячной зарплаты опытного российского программера в 4К$, то расходы на процесс оформления идеи с момента ее рождения стоят от 4K$ до 12K$

итоги:
стоимость создания оригинальной идеи и бизнес-плана по ней равна от 6K$ до 32K$

вывод:
треп во всяких статьях о стартапах о том, что идеи и бизнес-план ничего не стоят — это чушь собачья
они стоят именно ту сумму, которую я указал выше

забыл заметить
статистика основа на личном опыте написания документов для 3 бизнес-идей

Здравствуйте, 3dbiz, Вы писали:

Максим, это вы?

Здравствуйте, 3dbiz, Вы писали:

3>треп во всяких статьях о стартапах о том, что идеи и бизнес-план ничего не стоят — это чушь собачья
3>они стоят именно ту сумму, которую я указал выше

у барина творческий кризис?

закон номер 1:
от идеи до модели (прототипа) лежит путь в 100500 км;

закон номер 2:
от модели до продукта лежит путь в 100500 км;

закон номер 3:
от продукта до рынка лежит путь в 100500 км;


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

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, 3dbiz, Вы писали:

3>>треп во всяких статьях о стартапах о том, что идеи и бизнес-план ничего не стоят — это чушь собачья
3>>они стоят именно ту сумму, которую я указал выше

М>идея образно говоря это как кинуть палку в женщину. это несложно. и если долго мучаться, то на выходе что-нибудь получиться. а вот что именно полуится -- бомж или космонавт это зависит от можества обстоятельств, в том числе и тех, которые вам неподвластны.

я не говорил, что реализация идеи ничего не значит! :)
не перевирайте мои слова, пожалуйста
я лишь заметил, что генерация идеи и бизнес-плана основанного на ней — это отнюдь не "ничего не стоящие задачи", как многократно упоминается в разных блогах и статьях

собственно соотношение затрат 1 к 100 для бизнес-плана и первой версии продукта вполне действует, как могу сказать основываясь на моем опыте
все написанные мною документы описывают задачи для реализации которых необходимо от нескольких сот тысяч до нескольких миллионов $$$

дополнение

естественно никто специально такие деньги за идеи платить не станет по одной простой причине

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

и цель создания этого топика на форуме была лишь в том, чтобы показать цену того, что массово считается "условно бесплатным"
ибо все стоит денег

Здравствуйте, 3dbiz, Вы писали:

3> я лишь заметил, что генерация идеи и бизнес-плана основанного на ней
3> это отнюдь не "ничего не стоящие задачи", как многократно упоминается в разных блогах и статьях
затраты на генерацию идеи зависят от творческих способностей. у меня идеи рождаются, что называется on demand. это самая простая и наименее затратная часть. за ней следует продвижение идей в массы, которые нужно увлечь за собой, т.к. первая реакция "это не нужно, неработоспособно и т.д. и т.п.", вторая реакция "в этом что-то есть. давайте работать". при этом в ходе обсуждений (в процессе которых чуть до драки не доходит) идея претерпевает радикальные изменения и полностью перерождается. типа хотели стоить экономичный пассажирский самолет, а решили на этих движках лететь к марсу, хотя всем понятно, что до марса оно не долетит и в качестве компромисса выбирается трактор, работающий на авиационном керосине.

3>собственно соотношение затрат 1 к 100 для бизнес-плана и первой версии продукта вполне действует,
строго говоря, работающий бизнес-юнит (слаженная команда опытных девов) практически гарантированно выдаст на выходе предсказуемый результат, если на вход подать идею. истории успеха на 99% зависят от входа. бизнес-юнит это как усилитель с колонками и эквалайзером. во-первых, нужно чтобы входной сигнал соотносился с возможностями той аппаратуры, что у нас есть. во-вторых, сам сигнал должен быть таким, чтобы зацепило.

лично мне за идею, которую я изложил партнерам, пообещали 20% акций при условии, что она взлетит. а она взлетит. это покруче пляжа с банкоматом. я сплю, а денежки бегут. потому что предложил такую идею, которую реально реализовать небольшими силами и в которой уже заинтересованы заказчики, которые готовы дать предоплату. т.е. деньги уже потекли. впрочем, реализация идеи нетривиальна. с другой стороны, я был поставлен в жесткие рамки. знакомый спец по базам данных разработал базу данных нового типа и спросил меня -- а что с ней делать?! вы же понимаете, что продать саму базу это ни разу не вариант и вообще не рассматривается. потому мне пришлось два дня медитировать и думать какую именно задачу из числа нерешенных может решить его база. никакой свободы творчества. была поставлена задача -- разработать концепцию под существущую базу с учетом ее ТТХ. цена? цена 20% от прибыли.

3>все написанные мною документы описывают задачи для реализации
3>которых необходимо от нескольких сот тысяч до нескольких миллионов $$$
давайте так. себистоимость генерации идеи посчитать невозможно, т.к. в нее входит весь ваш жизненный опыт, начиная с момента рождения и обучения, а не только время медитации. "рыночную" стоимость идеи считать смысла нет, т.к. в этом смысле идеи конкурируют со сценариями для кинофильмов. почему одним за какое-то фуфло платят миллионы, а другимм всего несколько тысяч за шедевр? до начала кинопроката очень сложно делать какие-либо прогнозы в отношении кассовости фильма, а потому сценаристам платят по договоренности.

что такое "цена идеи" вообще?

М>что такое "цена идеи" вообще?

понятие "цена идеи + бизнес плана" в контексте моего топика означает следующее:
это то, сколько наличных денег и моего личного времени я потратил с момента
а) "у меня нет ни идеи ни бизнес плана, но есть желание иметь их"
до момента
б) "у меня в руках бизнес-план по идее, которая кажется мне стоящей и которая, насколько я вижу, еще не реализована никем"

пройдя расстояние между этими двумя моментами приблизительно 3 раза я определил цифры указанные выше

а определив цифры поделился ими с вами
(ну и заодно зарекся больше писать и рассылать кому попало бизнес-планы просто так — жизнь слишком коротка, чтобы тратить ее на это — а процесс личного психологического удовлетворения от написания первых нескольких документов уже был получен)

Здравствуйте, 3dbiz, Вы писали:
3>понятие "цена идеи + бизнес плана" в контексте моего топика означает следующее:
3>это то, сколько наличных денег и моего личного времени я потратил с момента
Это себестоимость при производстве конкретно Вашим методом. А цена — это столько, сколько за нее согласен заплатить тот, кому продаете.

Здравствуйте, Кольцехвостый Кускус, Вы писали:

КК>Здравствуйте, 3dbiz, Вы писали:
3>>понятие "цена идеи + бизнес плана" в контексте моего топика означает следующее:
3>>это то, сколько наличных денег и моего личного времени я потратил с момента
КК>Это себестоимость при производстве конкретно Вашим методом. А цена — это столько, сколько за нее согласен заплатить тот, кому продаете.

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

Здравствуйте, мыщъх, Вы писали:

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

Это сильно

Здравствуйте, edton, Вы писали:

E>Здравствуйте, мыщъх, Вы писали:

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

E>Это сильно

а раньше он нейропроцессоры разрабатывал. и что? он ученый с Ph.D. и обширными наработками.

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

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, edton, Вы писали:

E>>Здравствуйте, мыщъх, Вы писали:

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

E>>Это сильно

М>а раньше он нейропроцессоры разрабатывал. и что? он ученый с Ph.D. и обширными наработками.

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

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

Здравствуйте, edton, Вы писали:

М>>разработать базу данных нового типа не так уж сложнее. сложнее найти ей применение.
E>Возможно не найти применение, а внедрить.
внедрить бд -- ужасно сложно, ибо потребуется раскачать лодку. легче создать решение на базе данной бд которое порвет по своим ТТХ всех остальных и будет решать теже задачи существенно дешевле в пересчете на железо и упростит обслуживание, ибо там где раньше был кластер теперь стоит один сервер и не гудит.

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

> Если же первое, то возможно не такая уж это стоящая идея, которая
> не вписывается органично в реальный мир как реляционные и иерархические БД.
новая бд поддерживает SQL синтаксис, но раз в десять по скорости обходит существущие бд на добавлении новых записей имя которым легион. то есть она идеально подходит для задач типа логгирования телеметрии (ведь не в сыром же виде писать телеметрические данные, верно?), т.к. если бд не будет успевать, то данные начнут теряться. а при этом нужно еще и обрабатывать запросы, т.к. софт следит за ситуацией и время отклика бд на выполнение запроса так же критично. оборудование для таких задач стоит от сотен тысяч долларов до миллионов и постановка задачи не нова. а вот что изменилось за последние годы так это соотношение цен на память/диск. к тому же размер памяти стал чуть ли не безграничным (мы не про писюки говорим). за счет чего теперь можно класть все в память, там же делать препроцессорную обработку, компилируя SQL запросы (при условии, что они известны наперед) и ложить данные на диск в том виде в каком они будут удобны для выборки для заданных откомпилированных запросов.

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

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

> она идеально подходит для задач типа логгирования телеметрии

так никто в здравом уме данные телеметрии не пишет в базу напрямую.
Нужно кэширование.
т.е.
не приемник — база
а приемник — кэширование — база

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

А потом еще умные люди придумали OLTP и OLAP.
Т.е. заливаем то в OLTP базу, но для серьезной аналитики данные
переносим уже в OLTP

хотя чего это я вам объясняю

Здравствуйте, qwertyop, Вы писали:

>> она идеально подходит для задач типа логгирования телеметрии

Q>так никто в здравом уме данные телеметрии не пишет в базу напрямую.
Q>Нужно кэширование.
Q>не приемник — база
Q>а приемник — кэширование — база
у вас есть 100500 сенсоров и over 9000 метрик. куда их кэшировать? какую структуру данных использовать? ну не массив же, верно. найдите мне в массиве все значения от M до K. долго же вы их искать будете. а все, что сложнее массива уже в каком-то смысле база данных.

Q>тогда если база отвалится или будет тормозить, то данные будут просто
Q>копиться в кэше.
с телеметрического оборудования идут данные. есть предельное время, отпущенное на их обработку. как их обрабатывать в кэше? даже на примере того же поиска значений от M до K? допустим это массив. тогда добавление новых записей ничего не стоит, но запрос будет обрабатываться дооооолго. а если это не массив, а дерево? тогда добавление новых записей будет тормозить, да и извлечение тоже. следовательно из кэща все дерево нужно выгружать целиком, блокируя на это время выполнение запросов, ибо тут происходит нарушение когенентности

Q>А потом еще умные люди придумали OLTP и OLAP.
я не спец в таких умных словах. я даже не знаю, что они значат.

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

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

Здравствуйте, мыщъх, Вы писали:

Q>>А потом еще умные люди придумали OLTP и OLAP.
М>я не спец в таких умных словах. я даже не знаю, что они значат.

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

Здравствуйте, edton, Вы писали:

E>Здравствуйте, мыщъх, Вы писали:

E>Да, кстати тоже про OLTP подумалось когда про телеметрию речь пошла.
E>Возможно все-таки стоит говорить не о новом типе БД, а о новой архитектуре или реализации.
это уже терминологические тонкости. новизна в том, что "движок" базы генерируется на этапе написания программы, на основании характера запросов, известных заранее. то есть программист говорит -- вот я буду делать такие-то и такие-то запросы. оглашаю полный список. база его проглатывает и генерирует код и подбирает структуры данных, оптимизированные специально под эти конкретные запросы. если характер запросов заранее неизвестен, то никакого выигрыша мы не получим, но это крайний случай.

E>Тут я себя вспомнил, когда еще до вуза придумал новый способ хранения данных,
E>а оказалось изобрел велосипед вариацию на тему иерархических БД.
давайте возьмем близкую мне область, ибо в бд я не силен. возьмем антиврусы. еще с 6х годов ученому миру было известно о возможности трансляции определенного класса регулярных выражений в DFA-деревья. вопрос -- какого хрена в XXI веке на рынке полно решений, которые способны затормозить даже самый быстрый пень, потому что они... сосут. когда они входят в стандартную библиотеку питона -- это ладно. бесплатная кобыла сойдет и за жену. но когда вместо того, чтобы нанять нормальных программистов отваливают несколько лямов за кластер... я теряюсь. возьмите Snort для примера. довольно популярная система. где там трансляция в DFA? а там 500 человек в компании работает. а упомняный товарищ написал движок, поддерживающий Snort синтаксис с трансляцией в DFA и кроющий его по скорости в результате чего мы переплюнули даже аппартные решения. без всякой специальной оптимизации под конкретное железо, без GPU -- просто за счет алгоритмов. причем алгоритмы известны еще с ветхозаветных времен и препадаются в каждом институте.

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

E> Позже уже в вузе появилась идея нового типа бизнес приложений, хотя оказалось
E> что и для этого типа приложений уже давно есть соответствующая трехбуквенная аббревиатура
в моем случае с точки зрения пользователя различия носят колличественный, а не качественный характер. но на этих различиях можно неплохо заработать, т.к. стоимость содержания железа растет быстрее чем O(N). подозреваю (но не уверен), что стоимость содержания/обслуживания это как O(N^2) или даже еще хуже.

3>стоимость генерации бизнес-идей и бизнес-планов

3>1. чтобы сгенерировать качественную бизнес-идею нужно отправить в путешествие по первому миру...

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

On 20.10.2012 22:08, 3dbiz wrote:
> From: *3dbiz* </Users/102080.aspx>
> стоимость генерации бизнес-идей и бизнес-планов
>
> 1. чтобы сгенерировать качественную бизнес-идею нужно отправить в
> путешествие по первому миру на период от 2х недель до 6ти месяцев,

Не отправить, а отправитьСЯ — всего 2 буквы и пост обретает смысл )

--
WBR,
Serge.

Здравствуйте, мыщъх, Вы писали:

М>с телеметрического оборудования идут данные. есть предельное время, отпущенное на их обработку. как их обрабатывать в кэше? даже на примере того же поиска значений от M до K?

Это не что-то наподобие вот этого:
http://www.microsoft.com/sqlserver/en/us/solutions-technologies/business-intelligence/streaming-data.aspx
?

Здравствуйте, 3dbiz, Вы писали:

3>вывод:
3>треп во всяких статьях о стартапах о том, что идеи и бизнес-план ничего не стоят — это чушь собачья
3>они стоят именно ту сумму, которую я указал выше
Люблю такие темы. Идеи эт конечно хорошо. Скажи, сколько твоих идей дощли до продакшена и дали прибыль? В какой срок? Сколько денег затрачено было от момента составления бизнес плана до получения стабильной прибыли? Надеюсь твои "идеи" это не очередной сервис на похапе?

Здравствуйте, 3dbiz, Вы писали:

3>стоимость генерации бизнес-идей и бизнес-планов

3>вывод:
3>треп во всяких статьях о стартапах о том, что идеи и бизнес-план ничего не стоят — это чушь собачья
3>они стоят именно ту сумму, которую я указал выше

У меня идея ещё проще — поступи в Гарвард или в Колумбийский университет и идей будет сколько хочешь.

Здравствуйте, мыщъх, Вы писали:


>>> она идеально подходит для задач типа логгирования телеметрии
Q>>так никто в здравом уме данные телеметрии не пишет в базу напрямую.
Q>>Нужно кэширование.
Q>>не приемник — база
Q>>а приемник — кэширование — база
М>у вас есть 100500 сенсоров и over 9000 метрик. куда их кэшировать? какую структуру данных использовать? ну не массив же, верно. найдите мне в массиве все значения от M до K. долго же вы их искать будете. а все, что сложнее массива уже в каком-то смысле база данных.

Я не qwertyop, но попытаюсь ответить.
Сейчас вся телеметрия приходит на контроллеры, которые эти данные обрабатывают и реагирую.
На выходе я не встречал данных быстрее 100MS для SCADA или логирования. 90% что я встечал 1000MS на передачу данных.
Все эти 100500 сенсоров находятся не на одном контроллере, но если на одном, то отправляются данные одним пакетом, именно массивом (можно и самому их читать). Каждой метрике соответствует какая то область определенного размера и вот тут qwertyop абсолютно прав, если для SCADA системы нужно сразу отражать изменения сигналов (их довольно мало), то для логов время не критично, и гораздо разумнее их потихоньку разбирать, не нагружая ни сеть, ни комп, беря только разницу, или только измененные значения. А писать сразу в БД, без предварительной обработки, это имхо изврат и то, только на малом количестве сигналов и на отдельно стоящей железяке. И для очень больших данных подходит обыкновенный типиризированный файл, который скачивается на сервак и там парсится.
И даже для 100500 сенсоров не все так сложно. 80% параметров нафиг никому не нужны, берут данные влияющие или на работу оборудования или на технологический процесс и их очень мало, из нескольких сотен метрик, хорошо если десяток наберется тех которые нужны.
Полный анализ (и то не тысячи, а десятки метрик) включается только на проблемные узлы, но никак не на все.
Данные же специалисты должны анализировать, а они не вечны и в сутках у них не 1000 часов.

Здравствуйте, AWSVladimir, Вы писали:

AWS>Здравствуйте, мыщъх, Вы писали:


AWS> Я не qwertyop, но попытаюсь ответить.
...
AWS> А писать сразу в БД, без предварительной обработки, это имхо изврат

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

"писать сразу в БД без предварительной обработки..." -- в данном случае БД и является частью процесса обработки данных.

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