суббота, 5 июля 2014 г.

[management] Perfomance for Pay?

По ссылкам на LinkedIn вышел на статью под названием "Performance for Pay? The Relation Between CEO Incentive Compensation and Future Stock Price Performance". Это отчет на 46 страниц об исследовании положения дел в порядка 1500 фирмах в период с 1994 по 2011 год. Смысл полученных результатов изложен в кратком резюме:
We find evidence that CEO pay is negatively related to future stock returns for periods up to three years after sorting on pay. For example, firms that pay their CEOs in the top ten percent of excess pay earn negative abnormal returns over the next three years of approximately -8%. The effect is stronger for CEOs who receive higher incentive pay relative to their peers. Our results appear to be driven by high-pay induced CEO overconfidence that leads to shareholder wealth losses from activities such as overinvestment and value-destroying mergers and acquisitions.
Или, в моем переводе:
Мы нашли свидетельства того, что на период до трех лет после повышения размер оплаты генеральных директоров находится в отрицательной связи с будущей доходностью акций. Например, фирмы, размеры зарплат директоров которых входят в верхние 10%, в течении последующих трех лет имеют отрицательную доходность приблизительно в -8%. Этот эффект еще сильнее для директоров, кто получает более высокий компенсационный пакет по отношению к своим коллегам. Представляется, что наши результаты обусловлены тем, что высокий уровень оплаты ведет к излишней самоуверенности директоров результатом чего являются потери акционеров от таких действий, как чрезмерные инвестиции и разрушающие бизнес слияния и поглощения.
 PS. Саму статью пока еще не прочел, там довольно сложный для меня английский. Но жаль, что я не знал этого раньше, до своего краткосрочного возвращения в Интервэйл в начале 2014-го.

пятница, 4 июля 2014 г.

[life] Про Юго-Восток Украины

Таки не удержался...

Думаю, что Россия не окажет никакой официальной помощи Юго-Востоку Украины. РФ еще не настолько вышла из поражения в Холодной войне, чтобы ставить на карту свое существование прямо здесь и сейчас (если она вообще выбирается из этого поражения).

Только вот что. РФ упрекают в том, что она заливает последствия Чеченских войн деньгами, щедро спонсируя Кавказ. Хорошо это или нет -- не мне судить. Важно то, что у РФ есть такая возможность.

Но что Украина будет делать с последствиями того, что сейчас происходит в Донецке и Луганске?

PS. Мне все больше и больше кажется, что Обама и Путин сейчас в такой же ситуации, как Кеннеди и Хрущев во время Карибского кризиса. А может и еще в более худшей.

[prog.c++] Еще на тему libcppa

Продолжаю озвучивать впечатления от libcppa (предыдущие части: #1, #2).

libcppa -- это фреймворк, реализующий actor model а-ля Erlang в C++. И вот эта попытка максимально близко скопировать Erlang в C++ приводит к коду, который лично мне представляется странным и избыточным. Видимо, все дело в том, что туплы в Erlang -- это основной механизм структурирования данных. А pattern-matching -- это главный механизм декомпозиции туплов на составляющие. Поэтому сочетание конструкций receive с паттерн-матчингом в Erlang-е выглядит лаконично и естественно.

Кроме того, туплы -- это структурная эквивалентность. Т.е. если у меня есть {0,1} и {3,5}, то я не могу судить -- относятся ли эти значения к экземплярам разных типов или нет. Может быть первый обозначает IP-адрес и порт, а второй секунды и микросекунды? Для решения этой проблемы в Erlang-е ввели дискриминанты под названием атомы. Что стало позволять записывать туплы с указанием "типовой принадлежности": {address, 0, 1} и {timeval, 3, 5}. Однако, в императивных языках, вышедших из Algol/Simula, нет необходимости в таком отдельном дискриминанте таковым там является само имя типа. Т.е. то, что в Erlang-е из-за отсутствия в языке struct записывается как {address, 0, 1}, в C++ записывается как address(0, 1). Поэтому очень странным для C++ выглядит попытка перенести в C++ из Erlang-а понятие атома, да еще в виде строки (размер которой ограничен 10 символами, а содержимое -- только определенным набором символов).

Если же попробовать объединить в C++ попытку притащить из Erlang-а паттерн-матчинг вместе с имитацией атомов, то результат получается слишком многословным. Вот, например, фрагмент кода из примера dining_philosophers.cpp:

// either taken by a philosopher or available
void chopstick(event_based_actor* self) {
    self->become(
        on(atom("take"), arg_match) >> [=](const actor& philos) {
            // tell philosopher it took this chopstick
            self->send(philos, atom("taken"), self);
            // await 'put' message and reject other 'take' messages
            self->become(
                // allows us to return to the previous behavior
                keep_behavior,
                on(atom("take"), arg_match) >> [=](const actor& other) {
                    self->send(other, atom("busy"), self);
                },
                on(atom("put"), philos) >> [=] {
                    // return to previous behaivor, i.e., await next 'take'
                    self->unbecome();
                }
            );
        }
    );
}

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

        on(atom("take"), arg_match) >> [=](const actor& philos) {

излишне избыточна. Более того, она требует дополнительного внимания, т.к. глядя на arg_match я затем должен еще и посмотреть на параметр лямбды для того, чтобы понять, что же такое этот аргумент на самом деле. Отказавшись от атомов и попытки эмулировать паттерн-матчинг в стиле Erlang-а тот же самый пример можно было бы переписать вот так (Upd. Т.к. такая запись несовместима с системой guard-ов, то и от методов on можно совсем отказаться):

// Atoms in C++ style.
struct take {};
struct taken {};
struct busy {};
struct put {};

// either taken by a philosopher or available
void chopstick(event_based_actor* self) {
    self->become(
        [=](take, const actor& philos) {
            // tell philosopher it took this chopstick
            self->send(philos, taken(), self);
            // await 'put' message and reject other 'take' messages
            self->become(
                // allows us to return to the previous behavior
                keep_behavior,
                [=](take, const actor& other) {
                    self->send(other, busy(), self);
                },
                [=](put, const actor&) {
                    // return to previous behaivor, i.e., await next 'take'
                    self->unbecome();
                }
            );
        }
    );
}

Код актора chopstick стал лаконичнее, меньше отвлекающих внимания факторов, быстрее вникаешь в код. Плюс, компилятор сам бьет по рукам, если вместо take по ошибке напишешь taike.

Следующий момент, который напрягает при изучении кода акторов в libcppa, это тот факт, что код внутри конструкций become -- это определение реакции на какое-то событие в будущем. Т.е. то, что написано внутри become -- это то, что будет исполнено не прямо сейчас, а когда-то в будущем, когда актор получит соответствующее сообщение. Это несколько запутывает, когда ты видишь become, вложенный в другой become. Как в примере выше. Вложенный become исполнится не тогда, когда агент выполняет обработку запроса take, т.е. не сразу после self->send(philos,atom("taken"),self). Поэтому, если после вложенного become написать еще какие-то действия, то время выполнения этих действий может стать сюрпризом для новичка:

void chopstick(event_based_actor* self) {
    self->become(
        on(atom("take"), arg_match) >> [=](const actor& philos) {
            // tell philosopher it took this chopstick
            self->send(philos, atom("taken"), self);
            // await 'put' message and reject other 'take' messages
            self->become(
               /* SOME CODE SKIPPED */
            );
            std::cout << "after nested become" << std::endl;
        }
    );
}

Отладочная печать будет выполнена сразу при обработке запроса take, а не после всех действий, которые определены во вложенном become. Конечно, к этой особенности привыкаешь. Но, поначалу, пониманию кода это не способствует.

Еще одна штука, которая напрягает в libcppa -- это получение и обработка ответа на синхронный запрос. Выглядит это так (причем это еще лаконичный вариант для статически типизированных акторов, для динамически типизированных еще многословнее):

self->sync_send(testee, minus_request{21}).then(
    [=](int r2) {
        assert(r2 == 1);
    }
);

ИМХО, здесь опять мы наступаем на грабли того, что статически типизированный C++ с необходимостью явной декларации типов -- это нифига не динамически типизированный Erlang. В котором запись:

Testee !{minus21}
receive
   Result -> ?assertResult =:= 1 )
end

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

int r2 = self->expect<int>()->sync_send(testee, minus_request{21});
assert(r2 == 1);
...

Я, конечно, понимаю, что вариант libcppa более универсален, и в then можно передать не один функциональный объект, а несколько для разных вариантов ответа (afaik, это так лишь для динамически типизированных агентов, у статически типизированных ответ всего один). Но, что-то мне подсказывает, что в большинстве случаев синхронные запросы делают для того, чтобы получить один вполне конкретный ответ. И именно этот сценарий должен быть предоставлен пользователю в наиболее удобном виде.

Как-то вот так. Общее впечатление, что изучая libcppa, ты изучаешь, по крайней мере, две вещи. Во-первых, библиотеку диспетчеризации событий и обмена сообщениями. Со своими тараканами особенностями и ограничениями. Во-вторых, отдельный хитрый DSL, накрученный вокруг этой библиотеки. Или даже несколько диалектов этого DSL, т.к. есть особенности записи guard-ов. Хотя хотелось бы изучать всего одну целостную вещь :(

Чуть-чуть больше слов на тему различий в подходах C++ и Erlang касательно туплов, паттерн-матчинга и динамической типизации я написал на sources.ru (disclaimer для Erlang-еров: про инструкцию -record я не знал, поэтому написал, что в Erlang-е структур нет).

четверг, 3 июля 2014 г.

[prog.c++] О принципиальных различиях между SObjectizer и libcppa

В продолжение вчерашней темы про libcppa. Борис Сивко подсказал ссылку на хороший PDF-документик, посвященный основам libcppa и сравнению производительности этой библиотеки с Erlang, Scala Actors и Akka. Так что если у кого-то есть желание узнать, что такое libcppa, то можно начинать с этой PDF-ки, там всего 10 страниц и общее впечатление она дает не хуже, чем полноценный большой мануал.

Что же до сравнения SObjectizer-5 и libcppa, то его, собственно говоря, можно начинать и заканчивать на одной простой теме. libcppa заточен на то, что в приложении будет работать всего один экземпляр рантайма libcppa. Посему все выглядит так, как выглядит -- вся эта похожесть на Erlang и простое использование spawn, await_all_actors_done, shutdown, self -- все это из-за того, что любой агент, созданный в приложении будет принадлежать единственному запущенному в приложении рантайму libcppa. Второго параллельно запущенного здесь же рантайма не может быть в принципе.

Это те же самые грабли, которые я сделал создавая SObjectizer-4. И на которые наступил, когда для заказчиков пришлось написать парочку библиотек, выставляющих наружу простой API, а внутри использующих SObjectizer и запускающих SObjectizer RunTime. Все это было хорошо ровно до тех пор, пока одну из библиотек нам самим не пришлось использовать в собственном SObjectizer-приложении. Получилась коллизия: приложение стартует и запускает свой SObjectizer RunTime, затем подгружает DLL с кодом, использующим библиотеку, библиотека пытается запустить SObjectizer RunTime еще раз. Пришлось делать костыльное решение. Костыльное потому, что для нормального решения требовалось, чтобы можно было параллельно и независимо друг от друга запускать несколько SObjectizer-4 RunTime. А это было невозможно из-за прибитого гвоздями к единственной копии RunTime прикладному API SObjectizer-4.

Эта проблема была в числе тех, которые мы старались разрешить в SObjectizer-5. Поэтому у нас появилось понятие SObjectizer Environment (это контейнер, в котором находится отдельный экземпляр SObjectizer RunTime) и интерфейс so_environment_t. А так же необходимость связывать агентов с данным интерфейсом и проводить ряд операций (например, создание и регистрация коопераций, создание mbox-ов, останов RunTime) через so_environment_t. Что не могло не сказаться на многословности определения агентов в SObjectizer и особенностями внешнего вида использующего SObjectizer-5 кода.

Зато SObjectizer-5 позволяет, например, написать библиотеку для вставки водяных знаков в видео. В этой библиотеке SObjectizer может использоваться для распараллеливания работы на несколько ядер. И, скажем, библиотеку, которая внутри себя задействует SObjectizer для работы с аппаратно реализованной криптографией (HSM). А затем задействовать обе эти библиотеки в одном приложении, где с помощью второй библиотеки формируются криптографически стойкие подписи, а затем средствами второй библиотеки эти подписи вставляются в виде водяных знаков в видеофайл. И ни одна из библиотек не будет подозревать, что рядом запущен еще один SObjectizer RunTime.

С libcppa так не получится.

Но есть и еще одно различие, менее формальное, но не менее важное. Хоть и чисто субъективное (ну вот так мне кажется и ничего с этим не поделать).

На мой взгляд, SObjectizer -- это фреймворк для coarse-grained actors, тогда как libcppa -- это фреймворк для fine-grained actors (для прояснения различий между coarse- и fine-grained прошу в Wikipedia). Т.е. SObjectizer разрабатывался с прицелом на работу с "тяжеловесными" агентами, такими, например, как агент для обслуживания SMPP канала. Такой агент может иметь несколько десятков обработчиков сообщений, получать десяток-другой разных типов сообщений, требовать работы на контексте выделенной нити и т.д. Тогда как libcppa в большей степени ориентирован на очень эффективное обслуживание совсем мелких агентов, подавляющее большинство из которых вполне могут работать на одной общей нити. Отсюда в документации по libcppa и соответствующие примеры. Скажем, пример fixed_stack, в котором агент реализует стек целых чисел фиксированного размера. Я себе даже представить не могу реализацию такого агента на SObjectizer -- это чистой воды overkill, слишком тяжеловесной выйдет реализация (если не по объему кода, то по затрате ресурсов при работе). С другой стороны, я вспоминаю некоторые объемные агенты, написанный мной за время работы в Интервэйле, и слабо себе представляю, как мелко их пришлось бы "нарезать", чтобы реализовать в libcppa...

Вот такие пока предварительные выводы. Двигаюсь дальше. Если еще что-то придет в голову, вернусь к данной теме.

Под катом сравнение реализации примера fixed_stack из документации к libcppa и его аналога на SObjectizer (предупреждение: ни один из примеров не проверялся компилятором/линкером).

[prog.thoughts] Первые более-менее серьезные впечатления от libcppa

После анонса релиза SObjectizer 5.3.0 на forum.sources.ru завязалась интересная дискуссия по поводу сравнения SObjectizer и еще одной библиотеки с реализацией акторов для C++ -- libcppa. Про эту библиотеку я был наслышан раньше, поскольку если судить по списку реализаций модели актеров для C++ в Wikipedia, с 2012 года более-менее развивалось только два проекта: SObjectizer и libcppa. Но пристально смотреть было некогда. А вот сейчас довелось глянуть внимательнее...

Ну что тут сказать. Очень умные люди делают libcppa. Сделано столько, что это реально внушаить. На C++ных лямбдах и шаблонах сделан DSL для своеобразного аналога pattern-matching-а, да еще и с guard-ами. Вот, например:

on<int, anything>() >> [](int i) {
   // tuple with int as first element
},
on(any_vals, arg_match) >> [](int i) {
   // tuple with int as last element
   // "on(any_vals, arg_match)" is equal to "on(anything{}, arg_match)"
},
others() >> [] {
   // everything else (default handler)
   // "others()" is equal to "on<anything>()" and "on(any_vals)"
}
/**********************************************************************/
on<int>().when(_x1 % 2 == 0) >> [] {
   // int is even
},
on<int>() >> [] {
   // int is odd
}
/**********************************************************************/
int val = 42;
on<int>().when(_x1 == val) // (1) matches if _x1 == 42
on<int>().when(_x1 == gref(val)) // (2) matches if _x1 == val
on<int>().when(_x1 == std::ref(val)) // (3) ok, because of placeholder
others().when(gref(val) == 42// (4) matches everything
                               // as long as val == 42

Смотришь на такое и не можешь не восхищаться изобретательности авторов библиотеки. Они умудрились максимально похоже отобразить Erlang в C++. Вот честно, не уверен, что можно было бы сделать лучше.

Но, с другой стороны, постоянно задаешься вопросом: а зачем это все? Зачем переносить в C++ Erlang-овские приемы? Ведь языки совершенно разные. Да, новые фичи C++ позволяют писать лаконично. Но я постоянно ловлю себя на мысли, что когда я изучал диссертацию Джо Армстронга про Erlang, примеры кода на Erlang-а до меня доходили гораздо быстрее, чем примеры из документации по libcppa. Может я уже просто постарел и много чего позабыл, да и программировать разучился. Но вот этот пример я вкуривал долго. И не уверен, что до меня дошло. Поэтому объяснить на пальцах я его не возьмусь:

behavior server(event_based_actor* self) {
  auto die = [=] { self->quit(exit_reason::user_defined); };
  return {
    on(atom("idle")) >> [=]() { 
      auto worker = last_sender();
      self->become (
        keep_behavior,
        on(atom("request")) >> [=] {
          // forward request to idle worker
          self->forward_to(worker);
          // await next idle message
          self->unbecome();
        },
        on(atom("idle")) >> skip_message,
        others() >> die );
    },
    on(atom("request")) >> skip_message,
    others() >> die
  };
}

В общем, первое впечатление -- ну очень навороченная штука. Но вот нужна ли она такая навороченная -- фиг знает. Может и не нужна. Хотя тем разработчикам, которые тащатся от Modern C++ Style, наверняка придется по вкусу.

Свое же знакомство с libcppa я продолжу. Надеюсь, получиться затем оформить свои мысли во что-то вроде сравнения SObjectizer и libcppa.

Ну а под катом пример того, до чего доходит сейчас использование лямбд в C++. Это фрагмент примера curl_fuse.cpp из штатных примеров libcppa. Понятно, что это демонстрация возможностей libcppa, а не промышленный код. Но все же... Когда-то был очень суровый overuse плюсовых шаблонов. Сейчас, же будет overuse лямбда-функций :(

Наброс-задачка для внимательных: сколько лямбда функций создается в этом фрагменте ;)

А так же вопрос: а вы сами готовы писать на C++ в таком стиле?

вторник, 1 июля 2014 г.

[prog.c++] Состоялся релиз SObjectizer 5.3.0

SObjectizer -- это реализация модели акторов для C++, позволяющая программировать на C++ с использованием работающих на разных нитях агентов, общающихся между собой посредством сообщений. SObjectizer существенно упрощает разработку событийно-ориентированных приложений, для параллельной и независимой обработки событий в которых требуется многопоточность и/или распределенность. SObjectizer использовался для создания как для мелких утилит, так и серьезных распределенных приложений, работающих под большой нагрузкой в режиме 24x7.

Последние несколько лет SObjectizer развивается на SourceForge как OpenSource проект под BSD-лицензией. Версия 5.3.0 является очередным существенным шагом по наращиванию возможностей SObjectizer при одновременном упрощении его использования.

В версии 5.3.0 произведены значительные улучшения:

  • добавлена возможность организации синхронного взаимодействия агентов: инициатор запроса может синхронно ожидать результата на объекте std::future, в то время как обработчик запроса работает обычным образом на своей рабочей нити;
  • более активно используются лямбда-функции, введенные в C++11. Например, теперь обработчики событий могут быть заданы посредством лямбда-функций, что позволяет уменьшить объем кода агентов;
  • добавлена возможность создавать ad-hoc агентов, формируя агента из лямбда-функций, а не описывая отдельный, унаследованный от so_5::rt::agent_t, класс;
  • доработана модель реагирования на выпущенные из обработчиков событий исключения.

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

Традиционный пример “Hello, World” теперь может быть записан вот так:

so_5::api::run_so_environment(
  []( so_5::rt::so_environment_t & env ) {
    auto coop = env.create_coop( "hello" );
    coop->define_agent().on_start( [&env]() {
      std::cout << "Hello, World" << std::endl;
      env.stop();
    } );
    env.register_coop( std::move( coop ) );
  } );

А более интересный пример ping_pong, где каждый агент работает на контексте своей собственной нити, вот так:

int pings_left = 10000;
so_5::api::run_so_environment(
  [&pings_left]( so_5::rt::so_environment_t & env )
  {
    struct msg_ping : public so_5::rt::signal_t {};
    struct msg_pong : public so_5::rt::signal_t {};

    auto mbox = env.create_local_mbox();
    auto coop = env.create_coop( "ping_pong",
       so_5::disp::active_obj::create_disp_binder( "active_obj" ) );
    coop->define_agent()
      .on_start( [mbox]() { mbox->deliver_signal< msg_ping >(); } )
      .on_event( mbox, so_5::signal< msg_pong >,
        [&pings_left, &env, mbox]() {
          if( --pings_left > 0 )
            mbox->deliver_signal< msg_ping >();
          else
            env.stop();
        } );
    coop->define_agent()
      .on_event( mbox, so_5::signal< msg_ping >,
        [mbox]() { mbox->deliver_signal< msg_pong >(); } );
    env.register_coop( std::move( coop ) );
  },
  []( so_5::rt::so_environment_params_t & params )
  {
    params.add_named_dispatcher( "active_obj", so_5::disp::active_obj::create_disp() );
  } );

Версия распространяется в виде сборки so-201407-00, в которую кроме SObjectzer 5.3.0 входит еще несколько SObjectizer-библиотек, предназначенных для разработки больших, распределенных приложений на основе SObjectizer, а именно:

  • so_log, служащая оберткой над ACE Logging и упрощающая логирование для агентов;
  • so_sysconf, позволяющая собирать большое приложение из маленьких кусочков, оформленных в виде dll/so-библиотек;
  • so_5_transport, оформляющая работу с TCP/IP соединениями в виде транспортных SObjectizer-агентов;
  • mbapi, являющаяся высокоуровневой библиотекой для обмена сообщениями между агентами или между компонентами распределенного приложения.

Релизная сборка может быть загружена с SourceForge в виде архива или же взята из svn-репозитория.

Wiki-раздел SObjectizer-а на SourceForge содержит более подробную информацию как об особенностях версии 5.3.0, так и о самом SObjectizer и его основах.

понедельник, 30 июня 2014 г.

[management] Г.Минцберг: различия между знаниями эксперта и менеджера

Из книги "Действуй эффективно! Лучшая практика менеджмента" Генри Минцберга:
Говорят, эксперт -- это тот, кто знает все больше и больше во все более узкой области и в итоге знает все ни о чем. Проблемы менеджера прямо противоположны: он знает все меньше и меньше во все более широкой области и в итоге не знает ничего обо всем.

[life.cinema] Очередной кинообзор (2014/06)

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


Грань будущего. Здорово.

Букашки. Приключение в Долине муравьев. Посмотрел с большим удовольствием.

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

Этот демон внутри. Очень даже неплохо. А если бы и спецэффекты были подороже, было бы вообще здорово.

Кухня в Париже. Мне понравилось. И хотя фильм совсем не выдающийся, было приятно посмотреть и впечатления остались хорошие.

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

Вулкан страстей. Проходная французская комедия. Если есть возможность не смотреть, то можно не смотреть.

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

13-й район 3. Кирпичные особняки. Насколько я помню первую часть -- этот фильм ее точная копия. Поэтому тем, кто не смотрел фильмы “13-й район” я бы посоветовал начать именно с первой, оригинальной части. А тем кто смотрел, вообще бы не советовал.

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

Отель “Гранд Будапешт”. Не понял, что это было. Может, конечно, фильм и гениальный, и это просто я туплю и не догоняю… Но лучше бы не смотрел. Жаль потерянного времени.

Скорый “Москва-Россия”. Отзыв удален из-за полного отсутствия цензурных слов.

воскресенье, 29 июня 2014 г.

[management] Шикарные тезисы, которые отлично проецируются и на коммерческие компании

Читая архивы одного интереснейшего ЖЖ нашел вот эту запись: Население против террора. Государство против населения.

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

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