Справедливости ради, стоит отметить, что отсутствие жесткой конкуренции и «гона» может несколько отодвигать сроки открытий в исследовательских консорциумах. Что можно, в какой-то мере, компенсировать увеличением ресурсов (капитальных и людских).
Вы правы в том, что ваш пример не верен, поскольку в нем не учитывается, во-первых, риск (а большинство корпораций относятся к «избегателям риска»), а во-вторых, возможности, которые открывают исследовательские консорциумы для извлечения дополнительной прибыли. Утрируя, 200 млн. без риска поделятся на 10 участников, требуя с них по 4 млн. инвестиций. То есть каждая корпорация без риска (sic!) получит 16 млн. у.е. прибыли. Те же 16 млн. у.е., которые, в среднем, каждая корпорация сэкономила, не начиная исследования в одиночку, она может отправить на другие столь же прибыльные проекты.
Что касается участия мелких инвесторов, то им никто не мешает приобретать/продавать акции соответствующих компаний на фондовом рынке. Более того, исследовательские консорциумы и сами могут выходить на фондовый рынок, размещая свои ценные бумаги.
Я не вижу противоречия (даже в очках).
Заключение двумя сторонами (к примеру, работником и корпорацией) Договора о неразглашении не является публикацией. Договор затрагивает только подписантов. Права третьих лиц не затрагиваются.
Публикация произведения с намерением защиты прав на него ущемляет права третьих лиц без их согласия на то.
Сейчас действет принцип «победитель забирает все». Десять исследовательских лабораторий работают над, допустим, препаратом «Панацеиум». В каждой лаборатории работает 20 ученых и лаборантов. Затраты всех лабораторий в среднем составили 20 млн. у.е. (уж простите...). Лабратория, которая в конечном итоге запатентовала формулу «Панацеиум» потратила 30 млн. у.е. Общий бюджет открытия составил 200 млн. у.е. Если бы заинтересованные стороны объединились в исследовательский консорциум, то общий бюджет открытия сократился бы до, предположим, 40 млн. у.е. (из-за трансакционных издержек). Высвободившиеся средства (в нашем примере — 160 млн. у.е.) можно было бы направить на исследование «Гармония», и еще на «Халявий» хватило бы. Согласитесь, это эффективнее.
Выход всегда есть.
1. Берегите открытие как зеницу ока (NDA, коммерческая тайна, служба безопасности, суд). 2. Извлекайте выгоду из открытия как можно быстрее (гибкие производственные линии, отлаженные каналы сбыта). 3. Уменьшайте расходы на открытие (исследовательские консорциумы, энтузиасты).
Следование этим рецептам не только оздоровит экономику (изгнав с ее тела патентных троллей и ускорив экономический рост), но и избавит очень многих людей от совершенно лишних в данном случае мук совести.
Что значит — «борись с рисками»? Бороться можно с противником, проблемами, урожаем. Риски можно учитывать, оценивать, минимизировать.
Публикация произведения с намерением защиты прав на него — это нарушение прав других людей на создание такого же произведения. Если вы первым поняли, что 2х2=4, ваше имя впишут в анналы истории, и это правильно. Но если вы при этом начинаете требовать лицензионных отчислений со всех, кто использует ваше открытие, то этим вы имплицитно предполагаете, что они не смогут в силу слабости ума дойти до этого открытия сами, и, что еще хуже, облагаете налогом тех, кто все-таки, вопреки вашим предположением, это сделал.
Почему так получается, что инженеры пользуются спросом, а «эффективные менеджеры» которые ими руководят – совсем никому не интересны?
В первую очередь потому, что программист — это станок с ЧПУ. Его можно поставить в офисе, подключить питание, задать какую-то программу действий, и он будет работать, выдавая с определенными интервалами готовую продукцию — код. От места дислокации производительность и качество продукта программиста зависят слабо. Если культурные различия здесь и имеются, то весьма слабые. Китайские и индийские программисты в Америке пишут совсем не китайский или индусский код.
В случае же с менеджерами культурные различия оказываются исключительно большими. Менеджер — это ведь не только начальник. Это и подчиненный (для топов), и коллега (для других менеджеров), и продавец (для клиентов). Как человек здоровается, как улыбается, как отдыхает, насколько уважает субординацию, как назначает встречи, насколько вовремя все делает, насколько прямо выражает свои эмоции, и даже насколько близко при разговоре подходит к собеседнику. Это не проблема только наших «эффективных менеджеров». Вспомните, какие проблемы у западных менеджеров бывают в азиатских компаниях, в частности — в японских (недавний пример с Olympus'ом хотя бы).
Очень часто «некомпетентность» менеджеров оказывается следствием другой корпоративной культуры. Общее «разгильдяйство» российских менеджеров может быть реакцией на исключительную долю неопределенности (как противоположности риска) в бизнес-среде. А «железная дисциплина» японских менеджеров — просто следствием традиций самурайского служения. Иногда модель может работать, иногда — сбоить. Как исключительно эффективный канбан в случае маленького сбоя может закончится катастрофой, так и исключительно эффективные западные управленцы в случае тотального кризиса неплатежей, инфляции под 1000% и наезда рэкетиров запросто могут наложить в штаны.
Вот пример кода. Обратите внимание, как объекты назваются в консоли.
Словами — если в приложении предполагается создавать много объектов, то разумно использовать для этого специальный инструмент. Обычно используют функцию create Крокфорда. Но если ее использовать так, как есть, то в консоли объекты будут называться «Object». Нам же хотелось бы, чтобы они назывались — «Man», «Woman», «Point» и т.д. С помощью eval этого легко можно достичь. При этом нет ни проблем производительности (так как количество вызовов равно количеству типов), ни проблем безопасности (так как мы контролируем передающийся код).
Если Вы знаете для этого более подходящую методику, я с радостью ее перениму.
Что касается участия мелких инвесторов, то им никто не мешает приобретать/продавать акции соответствующих компаний на фондовом рынке. Более того, исследовательские консорциумы и сами могут выходить на фондовый рынок, размещая свои ценные бумаги.
Заключение двумя сторонами (к примеру, работником и корпорацией) Договора о неразглашении не является публикацией. Договор затрагивает только подписантов. Права третьих лиц не затрагиваются.
Публикация произведения с намерением защиты прав на него ущемляет права третьих лиц без их согласия на то.
Сейчас действет принцип «победитель забирает все». Десять исследовательских лабораторий работают над, допустим, препаратом «Панацеиум». В каждой лаборатории работает 20 ученых и лаборантов. Затраты всех лабораторий в среднем составили 20 млн. у.е. (уж простите...). Лабратория, которая в конечном итоге запатентовала формулу «Панацеиум» потратила 30 млн. у.е. Общий бюджет открытия составил 200 млн. у.е. Если бы заинтересованные стороны объединились в исследовательский консорциум, то общий бюджет открытия сократился бы до, предположим, 40 млн. у.е. (из-за трансакционных издержек). Высвободившиеся средства (в нашем примере — 160 млн. у.е.) можно было бы направить на исследование «Гармония», и еще на «Халявий» хватило бы. Согласитесь, это эффективнее.
1. Берегите открытие как зеницу ока (NDA, коммерческая тайна, служба безопасности, суд). 2. Извлекайте выгоду из открытия как можно быстрее (гибкие производственные линии, отлаженные каналы сбыта). 3. Уменьшайте расходы на открытие (исследовательские консорциумы, энтузиасты).
Следование этим рецептам не только оздоровит экономику (изгнав с ее тела патентных троллей и ускорив экономический рост), но и избавит очень многих людей от совершенно лишних в данном случае мук совести.
Публикация произведения с намерением защиты прав на него — это нарушение прав других людей на создание такого же произведения. Если вы первым поняли, что 2х2=4, ваше имя впишут в анналы истории, и это правильно. Но если вы при этом начинаете требовать лицензионных отчислений со всех, кто использует ваше открытие, то этим вы имплицитно предполагаете, что они не смогут в силу слабости ума дойти до этого открытия сами, и, что еще хуже, облагаете налогом тех, кто все-таки, вопреки вашим предположением, это сделал.
В первую очередь потому, что программист — это станок с ЧПУ. Его можно поставить в офисе, подключить питание, задать какую-то программу действий, и он будет работать, выдавая с определенными интервалами готовую продукцию — код. От места дислокации производительность и качество продукта программиста зависят слабо. Если культурные различия здесь и имеются, то весьма слабые. Китайские и индийские программисты в Америке пишут совсем не китайский или индусский код.
В случае же с менеджерами культурные различия оказываются исключительно большими. Менеджер — это ведь не только начальник. Это и подчиненный (для топов), и коллега (для других менеджеров), и продавец (для клиентов). Как человек здоровается, как улыбается, как отдыхает, насколько уважает субординацию, как назначает встречи, насколько вовремя все делает, насколько прямо выражает свои эмоции, и даже насколько близко при разговоре подходит к собеседнику. Это не проблема только наших «эффективных менеджеров». Вспомните, какие проблемы у западных менеджеров бывают в азиатских компаниях, в частности — в японских (недавний пример с Olympus'ом хотя бы).
Очень часто «некомпетентность» менеджеров оказывается следствием другой корпоративной культуры. Общее «разгильдяйство» российских менеджеров может быть реакцией на исключительную долю неопределенности (как противоположности риска) в бизнес-среде. А «железная дисциплина» японских менеджеров — просто следствием традиций самурайского служения. Иногда модель может работать, иногда — сбоить. Как исключительно эффективный канбан в случае маленького сбоя может закончится катастрофой, так и исключительно эффективные западные управленцы в случае тотального кризиса неплатежей, инфляции под 1000% и наезда рэкетиров запросто могут наложить в штаны.
А какие-то проблемы встречали с таким решением?
instanceofи для метода Крокфорда действует, если передавать нужный прототип.var Fговорило в коде. Нет?instanceofэто большое подспорье.Словами — если в приложении предполагается создавать много объектов, то разумно использовать для этого специальный инструмент. Обычно используют функцию
createКрокфорда. Но если ее использовать так, как есть, то в консоли объекты будут называться «Object». Нам же хотелось бы, чтобы они назывались — «Man», «Woman», «Point» и т.д. С помощьюevalэтого легко можно достичь. При этом нет ни проблем производительности (так как количество вызовов равно количеству типов), ни проблем безопасности (так как мы контролируем передающийся код).Если Вы знаете для этого более подходящую методику, я с радостью ее перениму.