[life] Для красного словца... Или пример того, что в действительности все не так, как на самом деле

Читаю сейчас книгу Александра Прохорова "Русская модель управления". Обнаруживаю интересную цитату:

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

Интересная история, подумал я. Про систему баллотировки офицеров раньше не слышал. Но что-то дернуло меня проверить первоисточник, на который ссылался Прохоров: Архангельская Н. Оборона безопасности // Эксперт. 2000. №44. С.49.

Эта статья легко отыскивается в Интернете, вот она. Оказывается, что это что-то вроде сборника высказываний различных экспертов по теме реформирования армии. И кусочками процитированный Прохоровым текст вырван из мнения Александра Шаравина. Полная цитата должна была бы выглядеть так:

Еще при Петре Первом проводилась баллотировка офицеров, позволявшая выбрать лучших. Если освобождалась должность командира роты или батальона, о том, кто ее займет, шел открытый разговор, и все решалось тайным голосованием. Причем голосованием альтернативным - два-три человека на место, в котором участвовали все офицеры полка. И это при том, что царь Петр у нас единодушно считается диктатором и самодержцем. Он говорил: может быть, этот человек будет мне не очень удобен, но я буду уверен, что ему доверяют сослуживцы. Благодаря этой системе в России появились такие военачальники, как Суворов, Кутузов, Ушаков, Барклай де Толли, Багратион и другие. Затем действовавший в постпетровскую эпоху военный министр фон Миних ввел принцип аттестации офицеров, из-за которого уже в девятнадцатом веке демократичная система отбора высших офицеров начала постепенно размываться: аттестация дала возможность увести дело в бумажное русло и заблокировать продвижение нежелательного человека. Причем петровская система была весьма продуманной. Командир полка мог единолично отменить решение офицерского собрания и назначить свою кандидатуру. Но если его ставленник не справлялся с должностью, то в отставку вместе с ним должен был уйти и выдвинувший его комполка. А потому ни один воинский начальник таким правом ни разу за всю историю существования этой системы не воспользовался.

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

Например, Каменев А.И., История подготовки офицеров в России 1-2:

   До 1712 года в России не существовало никаких правил [18] производства офицеров в следующие чины: оно проходило по усмотрению высшего начальства.
   Петр, естественно, видел все несовершенство этой системы. Он знал, что таким порядком злоупотребляют. Вот почему первый шаг в отношении упорядочения практики производства в чины связан с введением в штат полевой армии некоторых статей относительно офицерского содержания и чинопроизводства.
   14 апреля 1714 года Петр I издал указ, где царь определял пределы компетенции старших воинских начальников при производстве в чины: право присвоения генеральского и полковничьего звания он закрепил за собой, производить в подполковники и майоры было разрешено фельдмаршалам, производство офицеров в чины вплоть до капитана стало правом полных генералов.
   Новый шаг в этом направлении был сделан I января 1719 года. Продвижение по службе было поставлено в зависимость от наличия вакансий и результатов баллотировки 2-3-х претендентов на продвижение.
   Как это происходило на практике, рассказывается в работе И. Пушкарева{17}.
   Штаб и обер-офицеры полка, в котором открывалось производство в офицеры, собирались вместе, читали имена представленных в следующий чин, рассматривали заслуги, отличия их, познания в науках, и клали в общую кружку избирательные и неизбирательные баллы.
   Число баллов отмечалось председателем в особых списках против каждого баллотируемого кандидата. Списки представлялись государю и он обыкновенно награждал чинами получивших больше баллов.
   Но если государь при баллотировке замечал пристрастие, излишнюю благосклонность или строгость товарищей, то приказывал вновь производить баллотирование, сам [19] являлся в собрание и объяснял свое мнение относительно баллотируемого.
   Новые изменения в чинопроизводстве были внесены 7 марта 1721 года. Согласно указу Петра I баллотирование надлежало отправлять только при переходе из ранга в ранг. В связи с этим были установлены 3 ранга:
   -- 1 ранг -- при производстве из унтер-офицеров в обер-офицеры;
   -- 2 ранг -- при производстве из обер-офицеров в штаб-офицеры;
   -- 3 ранг -- при производстве из штаб-офицеров в генералы.
   Производство из чина в чин в рамках одного ранга стало проводиться при наличии вакансии по принципу старшинства. В то же время, генералы должны были баллотироваться при каждом повышении чина, вплоть до фельдмаршала{18}.

Кроме того, выясняется, что баллотировка в своем исходном виде просуществовала совсем недолго. Более подробно это расписано вот здесь (Волков С.В. Русский офицерский корпус. М.:Воениздат, 1993г):

В первой четверти XVIII в. принцип личной заслуги при повышении в чине находил выражение в том, что замещение вакансий при производстве в первые обер-офицерские и штаб-офицерские чины осуществлялось (по указу от 14.4.1714 г.) путем баллотировки, т. е. путем тайного голосования всех офицеров части (не ниже данного чина) или дивизии (для старших офицеров). Однако указом от 11 июня 1726 г. правительство Екатерины I отменило такой порядок, мотивируя это тем, что при выборах бывает много "страсти", т. е. имелось в виду, что мнения могут быть крайне субъективными и пристрастными.

Вместо этого предписано было повышать офицеров в чинах "по старшинству и достоинству". Через пять лет правительство Анны Иоанновны (5 февраля 1731 г.) восстановило выборность при чинопроизводстве офицеров, причем представления о производстве в полковники и выше следовало направлять лично императрице, минуя Сенат. Поскольку при производстве в обер-офицерские чины (кроме первого) и в штаб-офицерские (кроме майора) учитывалась выслуга в предыдущем чине, то во избежание конфликтов при счете служебного старшинства (оно считалось по каждой отдельной части) 7 декабря 1731 г. переводить офицеров из полка в полк без санкции императрицы было запрещено. Однако в 1736 г., констатировав, что "происходят немалые беспорядки и многие достойные по старшинству обойдены бывают", Анна Иоанновна, оставив баллотировку для первого обер-офицерского и первого штаб-офицерского чинов, повелела "в протчие чины производить по удостоинствам, а не по старшинству, смотря только, чтобы достойные в чины были произведены" ⁹⁰.

Так что картинка получается не такая уж идиллическая и однозначная, как это преподносит в своей книге г.Прохоров. Конечно, Интернетам доверять не нужно, но более точную информацию могут раскопать историки, к коим я не принадлежу :(

PS. После прочтения 96 из 488 страниц книги "Русская модель управления" у меня сложилось впечатление, что автор вовсю пользуется антисоветскими штампами перестроичных времен. Насколько после этого можно доверять суждениям автора -- большой вопрос. Тем более, что вот такие ляпсусы с доказательной базой доверия не добавляют.

[life] Пипец: вот кого Google сейчас считает Петром Первым...

[life.photo] Высокие ISO на Sony Alpha 7S против других камер...

На dpreview.com появилось тестовое сравнение поведения Sony Alpha 7S и других современных камер на высоких ISO. Вот, скажем, вариант сравнения A7S с интересующими меня Nikon-овскими камерами -- Df, D4s, D800E.

Имхо, более менее заметно A7S начинает выигрывать у конкурентов только с ISO 25600. Да и то, сравнивать довольно сложно. Поскольку у соперников разрешение выше, поэтому без должного масштабирования, в размере 1-в-1 шумов вроде как и больше. Однако, если привести изображения к одному размеру, например, для печати 40x30см, то будут ли заметны различия по шумам -- вопрос. Итого получается, что если кто-то, как я, плотно сидит на Nikon-е и собрал парк хорошей оптики, то смысла переходить на совершенно другую систему ради высоких ISO нет.

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

Да и беззеркалки пока еще и тормознее обычных зеркалок, и батареи жрут сильнее. Но, если бы это для меня не было проблемой, то я бы все равно смотрел не в сторону Sony, а в сторону Fujifilm. В частности, E-X2. Не полный кадр, конечно, но для большинства бытовых задач будет более чем достаточно. Особенно учитывая тот факт, что тушка E-X2 стоит чуть ли не в три раза дешевле, чем тушка A7S. Да и новая оптика Fuji для X-серии вполне себе доступная по цене. Так, например, если отталкиваться от цен на B&H PhotoVideo, то E-X2 + XF 23mm/1.4 + XF 56mm/1.2 обойдется всего на $250 дороже, чем одна тушка A7S.

Правда, A7S умеет 4K видео выдавать... Но нужно ли это фотографу?

[work.humour] Вакансию в корзину покупок? Это оригинально :)

Обратил внимание на одной из открытых в Oracle вакансий:

Понятно, что пришлось использовать готовый движок, заточенный под Интернет-торговлю, но все-таки...

[prog.c++] SObjectizer-5.3.0 уже почти что...

Похоже, в скоуп работ по версии 5.3.0 больше ничего не пойдет (и так достаточно). Заключительная фича, которая была добавлена за последние дни -- это ad-hoc агенты, для которых не нужно описывать отдельных C++ классов, а все их действия можно задать лямбда функциями (описание этой фичи в Wiki). Теперь пример ping-pong, в котором агенты могут обменивать друг с другом простыми сигналами ping и pong, на SObjectizer может быть записан вот так:

void run_sample(    const cfg_t & cfg )    {       // This variable will be a part of pinger agent's state.       unsigned int pings_left = cfg.m_request_count;       so_5::api::run_so_environment(          [&pings_left, &cfg]( so_5::rt::so_environment_t & env )          {             // Types of signals for the agents.             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",                // Agents will be active or passive.                // It depends on sample arguments.                cfg.m_active_objects ?                   so_5::disp::active_obj::create_disp_binder( "active_obj" ) :                   so_5::rt::create_default_disp_binder() );             // Pinger agent.             coop->define_agent()                .on_start( [mbox]() { mbox->deliver_signal< msg_ping >(); } )                .event( mbox, so_5::signal< msg_pong >,                   [&pings_left, &env, mbox]()                   {                      if( pings_left ) --pings_left;                      if( pings_left )                         mbox->deliver_signal< msg_ping >();                      else                         env.stop();                   } );             // Ponger agent.             coop->define_agent()                .event( mbox, so_5::signal< msg_ping >,                   [mbox]() { mbox->deliver_signal< msg_pong >(); } );             env.register_coop( std::move( coop ) );          },          [&cfg]( so_5::rt::so_environment_params_t & p )          {             if( cfg.m_active_objects )                // Special dispatcher is necessary for agents.                p.add_named_dispatcher( "active_obj",                   so_5::disp::active_obj::create_disp() );          } );    }

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

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

Так что 5.3 вышла на финишную прямую, по которой еще пилить и пилить... Нужно проверять работу на других платформах. Нужно подтягивать все подпроекты. Нужно сделать в Wiki хоть какое-то элементарное введение в SObjectizer "на пальцах"... Так что отдыхать некогда.

[prog.c++] Определение сигнатуры лямбда-функции

С++11 -- это, конечно, мощная штука. Но для некоторых вещей все же, как и в старые добрые времена, нужно использовать трюкачество. Один из подобных трюков я нашел на StackOverflow, когда мне потребовалось определить сигнатуру лямбда-функции (т.е. выделить тип результирующего значения и тип параметра). Решение подсказано Энтони Уильямсом. Продублирую его здесь, дабы никуда ходить не нужно было. Так же следует обратить внимание на предупреждение о применимости этого подхода:

#include <iostream> template<typename F,typename R> void do_stuff(F& f,R (F::*mf)() const) {     (f.*mf)(); } template<typename F,typename R,typename A1> void do_stuff(F& f,R (F::*mf)(A1) const) {     (f.*mf)(99); } template<typename F,typename R,typename A1,typename A2> void do_stuff(F& f,R (F::*mf)(A1,A2) const) {     (f.*mf)(42,123); } template<typename F> void do_stuff(F f) {     do_stuff(f,&F::operator()); } int main() {     do_stuff([]{std::cout<<"no args"<<std::endl;});     do_stuff([](int a1){std::cout<<"1 args="<<a1<<std::endl;});     do_stuff([](int a1,int a2){std::cout<<"2 args="<<a1<<","<<a2<<std::endl;}); }

Предупреждение: данный код не работает с функциональными типами (т.е. с указателями на функции); с классами, в которых более одного operator(); с классами, у которых operator() не константен.

Небольшое пояснение сути этого трюка. Лямбда в C++11 -- это объект какого-то сгенерированного компилятором типа. Компилятор умеет приводить лямбду к std::function, но лямбда -- это не экземпляр std::function. При этом у лямбды есть operator() const, тип которого можно попытаться диагностировать показанным выше способом. Обычно это так. Но, если лямбда определяется с ключевым словом mutable, то у нее будет operator() без const. И показанный выше подход должен быть доработан так, чтобы были варианты do_stuff, принимающие, скажем, не R (F::*mf)(A1,A2) const, а R (F::*mf)(A1,A2):

template<typename F,typename R,typename A1,typename A2> void do_stuff(F& f,R (F::*mf)(A1,A2) const) {     (f.*mf)(42,123); } template<typename F,typename R,typename A1,typename A2> void do_stuff(F& f,R (F::*mf)(A1,A2)) {     (f.*mf)(24,321); } ...     do_stuff([](int a1,int a2){std::cout<<"2 args="<<a1<<","<<a2<<std::endl;});     do_stuff([](int a1,int a2) mutable {std::cout<<"2 args="<<a1<<","<<a2<<std::endl;});

При запуске будет получено:

2 args=42,123
2 args=24,321

[prog.c++] Упрощение создания агентов в SObjectizer?

Если уж идти по пути использования C++ных lambda-функций в SObjectizer на полную катушку, то почему бы не разрешить объявлять в качестве агента лямбду? Без необходимости писать класс агента, писать для него конструктор, переопределять виртуальные методы и пр.

В текущем варианте новой версии 5.3 в примере синхронного взаимодействия агентов parallel_sum есть один агентик, который сейчас определяется вот так:

class a_part_summator_t : public so_5::rt::agent_t    {    public :       a_part_summator_t(          so_5::rt::so_environment_t & env,          const so_5::rt::mbox_ref_t & self_mbox )          :  so_5::rt::agent_t( env )          ,  m_self_mbox( self_mbox )          {}       virtual void       so_define_agent()          {             so_subscribe( m_self_mbox ).event(                   []( const msg_sum_part & part ) {                      return std::accumulate( part.m_begin, part.m_end, 0 );                   } );          }    private :       const so_5::rt::mbox_ref_t m_self_mbox;    };

Хотя можно было бы свести его вот к такому:

coop->define_agent( mbox,     []( const msg_sum_part & part ) {       return std::accumulate( part.m_begin, part.m_end, 0 );     } );

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

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

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

Данный релиз фиксирует текущие стабильные версии подпроектов перед началом подготовки к релизу новой версии 5.3, в которой много нового и вкусного. В сборку 201406 вошли:

• so-5.2.3.5, в которой устранена проблема утечки памяти при работе с отложенными сообщениями;
• so_5_transport-2.2.2;
• so_log-2.2.2, в которой добавлена возможность задавать кодировку solog-файлов при использовании hpp_generator-а;
• mbapi-4.2.3;
• so_sysconf-4.2.2.

 Для загрузки доступно несколько архивов:

• so-201406-00.7z содержит исходные тексты только SObjectizer-а и его подпроектов. Необходимый для SObjectizer-а ACE нужно скачивать и устанавливать вручную;
• so-201406-00+ACE.7z содержит и SObjectizer с подпроектами, и архив с ACE 6.2.6;
• so-201406-00--doc-html.7z содержит сгенерированный Doxygen-ом API Reference Manual;
• so-201406-00--ACE--bin-msvs2012-x86_amd64.7z содержит исходные тексты SObjectizer с подпроектами и ACE 6.2.6 + результаты компиляции в 64-битовом release-режиме с помощью MSVS2012 Express;
• so-201406-00--ACE--bin-msvs2012-x86.7z содержит исходные тексты SObjectizer с подпроектами и ACE 6.2.6 + результаты компиляции в 32-битовом release-режиме с помощью MSVS2012 Express.

 PS. Репосты данной новости всячески приветствуются :)

[prog.management] Потенциально интересная тема про поиск "решателя задач"

На RSDN-е всплыла потенциально интересная тема: [О собеседовании]: Маркеры, выявляющие людей, умеющих решать проблемы. Посыл автора вопрос правильный. Есть люди, которые хорошо выполняют работу. Есть те, кто может придумать, что нужно делать. Не обязательно эти две категории совпадают или даже пересекаются :)

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

Хотя на эту тему нужно смотреть еще шире. Рассматривая, как минимум, четыре типа сотрудников (или в таком варианте).

[prog.humour] Так сколько же swift-ов нужно индустрии?

Не такой уж праздный вопрос. Считаем:

1. Swift is a programming language and system for building web applications.
2. The Swift parallel scripting language. Fast easy parallel scripting - on multicores, clusters, clouds and supercomputers.
3. Swift is an innovative new programming language for Cocoa and Cocoa Touch.

Есть еще Swift PHP и, мне кажется, что я встречал это название еще где-то. Либо как название какого-то фреймворка, либо инструмента. Так шта... :)

PS. Не исключено, что правильный ответ -- 0. Шутка ;)

[prog.management] Механистические бюрократии vs маленькие софтверные компании

Описывая свои впечатления от книги Генри Минцберга “Структура в кулаке” я обещал еще раз вернуться к тому, почему же менеджеры, выходцы из механистических бюрократий, способны убить разработку в маленьких софтверных компаниях. Выполняю свое обещание. (Да, и маленькие -- это до 40-50 разработчиков).
 

Для начала нужно определить некоторые понятия. Минцберг делит персонал организаций на пять категорий:

• операторы или операционное ядро. Это те сотрудники, который выполняют основную работу организации: производят товары, оказывают услуги, несут службу и т.д. Например, рабочие на заводе, почтальоны в отделениях почты, кассиры-операторы в банковских расчетно-кассовых центрах, врачи и медсестры в поликлинниках -- это все операторы;
• стратегический апекс -- это самое высокое руководство организации. Например, совет директоров компании, директор завода со своими заместителями, главный врач больницы и т.д.;
• серединная линия -- это менеджеры всех уровней, расположенные между операционным ядром и стратегическим апексом, отвечающие за непосредственную деятельность организации. Например, на заводе -- это мастера смен, начальники производственных участков, начальники цехов и т.д. Однако, если на заводе есть еще и своя столовая, а так же подсобное хозяйство с небольшой свинофермой, то руководители столовой и свинофермы не входят в серединную линию, т.к. на них не лежит ответственность за выпуск продукции завода;
• техноструктура, состоящая из разного рода аналитиков. Техноструктура отвечает за формирование и контроль над процессом производства или оказания услуг. Например, мастера по ремонту и наладке оборудования являются частями техноструктуры. Нормировщики, методологи, инженеры по качеству, специалисты по технике безопасности и т.д. Техноструктура не производит продукцию, но определяет процесс его производства, либо в общих чертах, либо в мельчайших подробностях;
• вспомогательный персонал. Например, это сотрудники заводской столовой. Или юрисконсульты. Или библиотекари. Т.е. те, кто создают хорошие условия для сотрудников организации, но не занимаются производством продукции, а так же не определяют/регулируют/контролируют процессы производства.

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

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

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

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

1. Насколько хорошо выстроен и отлажен процесс производства. Если не ошибаюсь, Генри Форд на своих заводах с секундомером замерял время выполнения каждой операции и оптимизировал операции так, чтобы свести это время к минимуму. Соответственно, роль техноструктуры и ее аналитиков в механистичеких бюрократиях чрезвычано важна: именно они отвечают за разделение процесса производства на элементарные операции, стандартизацию и формализацию каждой из операций, написание должностных инструкций для операторов, оформление требований к найму новых сотрудников, выработка процедур обучения персонала и т.д., и т.п.;
2. Насколько хорошо конкретные операторы выполняют свою работу. Не филонит ли кто-нибудь из них, не гонит ли брак, не портит ли оборудование, не грубит ли клиентам и т.д. В механистической бюрократии вопросы контроля являются краеугольными, т.к. операторы выполняют однообразную, зачастую скучную, не приносящую никакого интереса и удовлетворения работу. А, поскольку нет заинтересованности в работе, то и качество ее выполнения обеспечивается лишь тотальным, неусыпным контролем и жесткими мерами.

По поводу второго пункта приведу цитату из “Структуры в кулаке”, из главы, посвященной особенностям функционирования механистических бюрократий:

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

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

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

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

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

Почему? По нескольким причинам.

Во-первых, программирование, как занятие, вообще не очень хорошо поддается стандартизации, формализации и разделению на узкоспециализированные задачи. В маленьких компаниях это особенно актуально. Даже если не брать крайние случаи, которые случаются в стартапах, когда один и тот же программист с утра пишет драйвер для железяки на C с вкраплениями ассемблера, а после обеда, уже на PHP, Web-морду для этой железяки, то все равно спектр лежащих на разработчиках задач очень большой. Особенно, если речь идет о ведущих разработчиках.

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

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

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

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

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

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

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

Думаю, что тогда читатели поймут, почему я считаю, что нельзя доверять управление маленькими софтверными компаниями выходцам из банков. ИМХО, Генри Минцберг в своей книги тридцать лет назад писал о том же самом. Поэтому напоследок приведу еще одну цитату оттуда про механистические бюрократии:

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