Либо встречу…либо нет (продолжение эффекта зонтика).

Март 5th, 2008

Вчера выложил статью «Эффект забытого зонтика» не совсем доведя ее до ума. Основную идею которую я хотел сказать то, что лезть в сильно занятую нишу в виде подражателя – опасно и вероятнее всего денег не принесет. Достаточно много людей возразили, что есть большое количество удачных подражателей. Так что, по ходу чтения комментариев, обнаружил другой эффект.

Знаете этот анекдот, когда у кого-то спрашивают, какова вероятность, встретить динозавра на улице. И человек отвечает, что вероятность 50% — либо встречу, либо нет.

Так вот, как мне кажется, приведение контрпримеров, не всегда является доказательством, что теория не верна. Теория не бинарная (либо встречу либо нет), а скорее вероятностная.

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

Нельзя же взять несколько примеров (Google, Microsoft, Facebook) и сделать на этой выборке вывод, что обязательно нужно лезть в конкурентный рынок и биться против большущей компании, чтобы заработать. Да, на выборке из этих трех компаний такой вывод можно сделать. Но вот, если взять выборку из всех компаний которые пытались это сделать, потом отбросить из выборки выбросы (не уверен, что так оно называется, так как давно статистику учил) то уверен, картина будет совсем другой, чем, если мы смотрим только на три успешные компании.

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

Повысить это самое мат. ожидание можно тем, что в уже имеющемся рынке/нише найти какую-то поднишу и быть в ней первым/вторым.

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

P.S. Кстати, слегка дырявое мат. обоснование, но если кто-то недавно проходил математику и не лень может его доработать до ума.

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

Вероятнее всего если нарисовать график зависимости мат. ожидания прибыли от порядкового номера входа игрока на рынок то кривая окажется гауссианой (обрубленной слева) с мат ожиданием где-нибудь в области от 1.5 до 2.

 P.S. Хорошее замечание вышло из переписке с jaguar. Более точный метод считать порядковый номер, является считание номера «волны», вместо абсолютного порядкового номера. «Волна» — это набор фирм которые стартовали примерно в одно время. Обычно на рынке очень хороши видны эти самые волны — когда фирм то густо (гребень волны), то пусто — между гребнями.

В остально, все вышеописанные рассуждения актуальны.

Эффект забытого зонтика.

Март 4th, 2008

Увидел забавный эффект. Когда на сцену вышел Google, все начали писать новые поисковые системы, когда человек сделал Million Dollar Home Page, все начали делать свои такие же страницы. Когда появился Facebook, все начали клепать социальные сети.

О чем это я… Ах да. Так вот, фактически никто из подражателей не получил и 1 цента прибыли.

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

Это я к тому, что когда вы читаете как гарантировано заработать денег (пиша plugin’ы по Facebook или разрабатывая web 2.0 магазины), то на самом деле — это значит, что на этом заработать уже нельзя.

P.S. Добавление и разъяснение. Все бросились штурмовать то, что есть удачные подражатели. Я с этим не спорю — таки есть удачные подражатели, однако вероятность выживания в не слишком занятой нише 5%, вероятность выживания в занятой нише скажем 1%. Один из методов, повысить свою вероятность выживания, копировать, но позиционировать для другого рынка (например русскоговорящий vs. англоговорящий).

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

P.P.S. Пожалуйста прочитайте мое пояснение к этой статье тут: «Либо встречу, либо нет«.

Стоимость бага.

Март 4th, 2008

Берем количество выпущенных машин — А,

умножаем на вероятную долю машин с неисправностями — B,

и умножаем произведение на стоимость урегулирования вопроса без суда — С.

A на B на C равно X

Если X меньше затрат на доработку, возврата не будет.

И часто случаются такие аварии?

Вы и представить не можете.

Бойцовский Клуб

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

Фактически все, раз в некоторое время жалуются – почему <вставить название программы> работает так глючно. Вспомним, тот же Windows 95, благодаря которому Microsoft получила такую плохую репутацию.

А ведь, если вдуматься, то формула приведенная в эпиграфе верна. Если цена предполагаемо проданных программ (количество программ * цена программы) – A, вероятность того, что заказчик увидит баг – B и вероятность того, что заказчик не купит из-за бага программу, то A*B*C = X равно недополученной прибыли из-за бага. И соответственно, цена исправления бага Y. Как вы понимаете до тех пор пока X < Y, то никому не интересно будет исправлять этот баг.

Просто для того, чтобы показать порядок цифр. Предположим, что цена предполагаемо проданных программ $1M. Вероятность того, что заказчик увидит какой-то конкретный баг 1% и вероятность того, что заказчик не захочет покупать программу из-за этого бага 1%. Итого мы имеем 1M*0.01*0.01 = $100. Ну, что можно сказать… Сто баксов – это сто баксов. Есть баги, которые можно будет решить дешевле, есть которые дороже.

Несколько производных из этой формулы:

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

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

Пару вещей, которые находятся вне формулы:

— часто во время исправление вносятся новые баги (и это тяжело внести в формулу)

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

— чем дольше исправляются баги, тем дольше время до выхода версии.

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

Как научиться учиться?

Февраль 29th, 2008

Продолжая тематику образования и эффективности.

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

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

Кстати, описанная проблема это классическое проблема целевика (детальнее о то, что такое целевик можно почитать в статье «Цель vs Путь»)

Таким образом, я по молодости не подготавливал «базу» для решения следующих задач.

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

А) Сбор информации.

Б) Первичный анализ информации.

В) Сбор вопросов и контроль понимания.

Во время сбора информации, я просто ищу, все, до чего могу добраться на интересующую тему. Например, сегодня я разбирался с Bluetooth на WinMobile и соответственно добрался до общего описания, описания security, описания как бороться с этим security, Widcomm SDK для BT WinCE, Microsoft примеры в Platform Builder’е, ну и еще некоторого количества документов. Все это я просто пробегаю взглядом, чтобы оценить, интересующая меня это информация или нет. Дальше, я аккуратно складываю все в папочку (не читая) и продолжаю поиск. В тот момент, когда я вижу, что документов достаточно  где-то на день чтения, то я перехожу к второй стадии.

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

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

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