Как корпоративный менеджмент порождает монстров истории или почему IQ в корпоративных системах коррелирует с атмосферным давлением?

Ты – начальник, я – ...?

Вас когда-нибудь мучал вопрос, почему вы – такой умный – подчиняетесь таким... как бы это сказать... Причем, ваш прямой начальник может быть еще и неплох, но чем выше вы глядите вверх по корпоративной или государственной лестнице, тем более идеал начальника приближается к чему-то вроде Горбачева-Черномырдина, а иногда даже (GM, Chrysler, Enron…) и Ельцина. А оказывается тому есть хорошие технические причины.

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

И правда, проецируя на социальные системы народная мудрость обычно вполне согласна с данным утверждением. Умный должен быть способен переиграть глупого. Система всегда бьет одиночек. А переросший мозг Homo самоуверенно называющего себя Sapiens однозначно побил все остальные виды в борьбе за ресурсы планеты. Более того, могу подтвердить это на собственном опыте. Когда я считал, что что-то надо сделать для фирмы, я вполне справлялся с контролем поведения групп более ста человек, включающих три прямых уровня начальников наверх и добивался принятия правильного плана действий. Вот только советское воспитание подвело – как всегда раньше думал о корпоративной родине, а потом о себе, а надо было наоборот. Если и когда я покину Майкрософт, моей первой задачей будет сделать для себя 10% того, что я заработал для Майкрософта, после чего моей второй задачей будет провести остаток моей жизни с максимальным удовольствием, благо, деньги позволят. Ну, может начну в 1-2%, чтобы не думать о деньгах до конца моей жизни, а уж потом займусь оставшимися 8-9% уже для удовольствия. Впрочем, мы отвлеклись на несущественное.

Недавно я вспомнил это утверждение и понял в чем оно неверно. Более правильная формулировка состоит в том, что "Подсистема с наивысшей сложностью, посвященной контролю системы в целом, определяет поведение системы в целом."

Непонятно? Поясню на примере. Допустим мы научились мерять сложность систем, или даже частного случая – людей. Представьте себе менеджера со сложностью 3 единицы. И его подчиненного со сложностью 10 единиц. Кто должен контролировать систему? Подчиненный, верно? И таки да, когда речь идет о том, что же будет делать продукт, подчиненный скорее всего сделает все так, как считает нужным. И это будет хорошо для фирмы и ее доходов. А вот в плане карьеры и продвижения по службе это скорее всего будет не так, поскольку из 10 единиц сложности подчиненного, 9 посвященно тому чтобы перебрасывать лопатой навоз, асфальт или, там,  С++ код, так что на контроль системы в целом (в том числе своей карьеры) у него остается только одна единица сложности, а у менеджера на это используются все три! Чувствуете разницу?

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

 

Грех корпоративной эволюции

Вот тут мы и подходим к моей любимой теме – корпоративной эволюции и чем она плоха. Для тех, кто не читал моих предыдущих статей, напомню.

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

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

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

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

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

Не могу не пнуть очередной раз Джека Велча – знаменитого главу General Electric введшего теорию альфа-персон, которых надо ставить в начальники (термин, взятый из наблюдений зоопсихологов над крысами) и годовых ревью с увольнением нижних 10%. Этакий селекционер, знатный Мичуринец, блин...

Так вот, как только подобные меры, даже в более мягкой форме, вводятся в фирме, она превращается в эволюционную среду. Результат? Выживают лучшие не для фирмы, а лучшие по определению эволюции. А для эволюции лучшие – это наиболее приспособленные. Это вовсе не самые умные. Это вовсе не самые сильные. Это вовсе не самые производительные или полезные. Это те, кто выжили. "Мальчик, который выжил!" в буквальном смысле этого слова. Ничто другое эволюцию не заботит. С чего сторонники Джека Велча и свободного рынка решили, что выжившие Гарри Поттеры – это автоматически лучшие для фирмы или общества для меня непостижимо, впрочем, это – отдельная тема.

Так вот, как только корпорация превращается в эволюционную среду, у каждого работника появляется две четко разных цели – первая, сделать деньги фирме, вторая, выжить. Отгадайте, какая занимает его внимание больше? Конечно, если вам надо за смену перебросить определенное количество навоза или С++ кода, то от этого никуда не деться, но отгадайте как это влияет на ваше выживание? В идеале, разумеется, именно количество навоза и должно определять ваше выживание, но идеал – вещь труднодостижимая. Вы часто видели идеальные корпоративные структуры? Вон, в СССР мы такой идеал в рамках государства 70 лет строили, коммунизм называется, а корпоративный коммунизм ничем не легче построить.

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

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

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

Продвижение талантов и порождение монстров

А теперь, представьте себе, что нашелся работник с 14 единицами сложности. Он честно потратил 9 на благо фирмы, и у него еще осталось 5 на себя и свою карьеру. Продвинется такой? Да, продвинется. Но, только если он нашел это магический баланс сразу, если он сознательно выбрал карьеру паразита, по крайней мере на 5 единиц своей производительнсти. Если он сознательно решил, что эти 5 (или более) единиц он тратит не на благо фирмы, а на себя и только себя, что бы там ни говорил его контракт.

А если он начал с траты всех 14 единиц на благо фирмы, то он успел поесть корпоративного новояза вместо продвижения. Его "трехзвездочный" менеджер обьяснил ему, почему он – недостоин, почему он – плохой, почему он недовыполняет свою работу, почему... В общем, прежде чем наш минигений найдет баланс, когда он сможет отчитаться о работе и при этом затратить достаточные ресурсы на карьеру, его успеют оскорбить, унизить, смешать с дерьмом... И вот, когда он с размаху был брошен лицом в навоз и начал думать что же происходит, он начинает понимать, что надо делать. А 14 единиц при среднем уровне менеджеров 3 единицы – это не хухры-мухры. И прорывается наверх уже не наивный идеалист с чистыми глазами, а законченный мизантроп, который, увы, знает цену людям, и который сознательно выбрал карьеру паразита.

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

Не буду приводить навязшие в зубах примеры Гитлера или Хуссейна, у нас есть другие примеры. Ленин, Троцкий, Черчиль. Из  более близких примеров, Горбачев, Ельцин, Шеварднадзе, Ющенко, Сакашвили. Дополните или поправьте список по вкусу, суть от этого не изменится.

Так что может и не так плохо, что IQ в корпоративных системах коррелирует с атмосферным давлением – чем выше, тем ниже? По крайней мере способность целенаправленно делать зло ослабевает.

Как обычно, кросс-пост с персонального блога.

Метрики при разработке софта

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

Долгое время мир делился на теоретиков-апологетов метрик и практиков. Апологеты гордо и самоуверенно вещали: "Ну, мы же инженеры или не инженеры? Инженеры должны мерять! И ваще, процесс!" В качестве положительных примеров приводились случаи, когда тот или иной процесс применялся и продукт таки удавалось создать и шипнуть!

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

Инженеры меряют, но что?

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

Дело в том, что разработка софта бывает очень разной. Сравните это с автомобилестроением. Одно дело завинчивать гайки на потогонной линии, другое дело создать новую модель. Первое меряется, второе – разве что по результату и продажам новой модели. А заметьте, и то, и другое – это "создание автомобиля".

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

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

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

Много ли толку от метрик?

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

Допустим, у вас есть два проекта, которые по смете каждый стоит миллион. Проект А, после реализации, принесет фирме 100 миллионов, а проект Б только 2 миллиона.

Теперь скажите сами, для какого проекта важнее контролировать его стоимость? Проект Б, верно? Если вы ошибетесь с оценкой стоимости проекта в два раза, то проект А принесет 98 миллионов вместо 99, разница около одного процента, а вот проект Б окажется полностью бесприбыльным и безполезным.

Видите что получается? Чем более бесполезен проект, тем более важны метрики.

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

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

Баланс между риском и шампанским, или любовь – зла...

Я уже приводил этот пример в статье про экономику открытий, но рискну повторить его. Очень уж хорошо он описывает суть дела.

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

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

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

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

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

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

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

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

Этап 1. Добраться до избушки Бабы-Яги.

Этап 2. Добраться до животного, на которое укажет Баба-Яга (убедить Бабу-Ягу указывать на зверя не далее одного дня пути, либо предварительно найти такого самостоятельно) и сразить его.

Этап 3. Жениться на особе женского пола, которую охраняло сраженное животное и привезти ее обратно в королевство.

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

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

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

Что я пытаюсь сказать в этой статье, это то, что используя мудреные процессы для снижения риска (предсказуемое время) вы всего-навсего частично переводите процесс отрезания функциональности в начало проекта, и когда функциональности оказыватся так мало, что ее действительно можно запланировать – менеджмент рапортует о победе. Вот и получаются проекты, где "сразили животное и женились на особе женского пола, которую оно охраняло." И хорошо, если это – внучка Бабы-Яги, а не она сама, или там, коза, которая паслась рядом. Кстати, не оттуда ли взялась сказка о царевне-лягушке?

Послесловие к метрикам при разработке софта и опять об экономика открытий

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

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

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

• Автомобильная индустрия – конкуренция и постоянно меняющиеся требования покупателей. Гонка за экономичностью, безопасностью, маневренностью, комфортом. Три крупнейшие группы производителей – японские, европейские и американские, готовы друг друг глотку перерезать, не говоря уж о конкуренции внутри групп, Тойота проти Хонды и Ниссана, Даймлер против БМВ, Форд против GM и Крайслера... Неудивительно, что производители, оставшиеся в индустриальной эпохе, вроде Лады или Фиата большинству даже в голову не приходят, несмотря на то, что и те, и другие имеют свои наработки – Фиат, например, вроде бы лидер в экономичности, к сожалению, с непримлемой для многих мощностью двигателей.
• Авиастроение – все слыхали историю с Dreamliner от Боинга? Вот, кажется, ярчайший пример компании, застрявшей в экономике знаний, а то и индустриальной. Люди у них грамотные, образованные, а вот методы управления... Это ж насколько надо было плевать на людей, чтобы перевести штаб-квартиру компании из Сиэттла в Чикаго, просто потому что новый CEO с Восточного побережья!
• Тяжелое машиностроение – опять же гонка между японскими, европейскими и американскими производителями. Знаете разницу между экскаватором за полмиллиона и три миллиона? Бортовое ПО, которое знает как его выкрутить в стабильное положение, когда он стоит на крае котлована и его покачнуло к краю.
• Военная техника – вот уж индустрия, где победа в конкурентной борьбе буквально вопрос выживания.

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

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

Хотите два примера? Пример номер один: Россия начала 20-го века. Вся страна была еще по сути феодальной с какой-то степенью капитализма. Социализм нарос только в столицах и нескольких крупных городах, так что конфликт производительных сил и производственных отношений был весьма локализован географически. И все равно жахнуло так, что мало не показалось. Кстати, в феврале, а не октябре. Вся эта кодла Временного правтельства была по сути разношерстной смесью социалистов представляющих уже не капитализм или феодализм, а социализм – индустриальное общество.

Пример номер два? Ага, Россия конца 20-го века. Опять же, экономика знаний нарасла в столицах плюс нескольких крупных центрах. Вся глубинка была индустриальной, с отдельными вкраплениями микрокапитализма, специфического феодализма и даже местами первобытнообщинного строя. Конфликт производства и управления из-за прогресса производства опять весьма локализованный. И тем не менее, опять жахнуло.

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

Как обычно, кросс-пост с персонального блога.

Экономика Открытий

Недавно я усомнился в своих убеждениях... Ага... бывает. Обычно проходит, но тут было уж очень убедительно.

Если вы читаете мои статьи, то должны были заметить, что я – апологет "экономики знаний", и не пропускаю шанса провозгласить порцию проклятий исчезновшему в небытие индустриальному обществу a.k.a. социализму, поскольку оно устарело и не только развалило СССР, которому я честно присягал, но и угрожает США, которые Бог мне дал взамен спертого у меня Союза, и за которые я готов... Ладно, неважно. Так вот, теперь я понял, что я был неправ. Спасибо еще одному хреновому менеджеру. И тем, кто оных поставляет, не будем называть имена и трейдмарки... Итак, к делу.

Напомним азбуку. Капитализм – Социализм – Экономика Знания. В чем разница? Так сказать, на пальцах, поскольку многомудренно п...ь на эту тему добровольцев хватает, а что нужно, это – чтоб было понятно.

Капитализм – "я – начальник, ты – ничто!": капиталист имеет деньги, и за них имеет фабрику со станками и прочим. Поэтому он может гулять по фабрике в свободное время и раздавать пинки по зад ленивым рабочим, а те должны работать из последних сил за гроши, чтобы он мог обогащаться. Капиталист имеет деньги и фабрику. Это – его способ заставить рабочих работать на него на почти халяву, поскольку у них денег на фабрику нет, а без фабрики они заработать на жизнь не могут.

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

Экономика знания – "Ты – начальник, ты – дурак.": которую общество пока что до сих пор не усвоило – это социализм, при котором раздающие пинки под зад мендежеры, еще и понятия не имеют что же надо делать. Поскольку производство стало таким сложным, что в одну голову даже маленькие кусочки больше не лезут. То есть, их функция полностью редуцировалась до пинков под зад, которые, понятное дело, сами по себе ничему не помогают, а только всех путают и мешают.

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

Долгие годы я верил, что все проблемы СССР и США растут как раз отсюда. Из того, что системы управления у них социалистичекие, а экономика уже – экономика знаний. Ага, как же... В том-то и дело, что уже не экономика знаний...

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

Увы, это больше не так. Можно создать iPhone или Гугл используя лишь то, чему научился и в предсказумые сроки? Ага. Ну, да, конечно. Так и представляю "личный комплексный план пионера капиталистического труда" с обязательством вроде "в следующий ревью период создать продукт, которые потрясет рынок"...

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

Сказочный пример

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

Пошел принц к казначею, а тот в ответ: "Извините, принц, но не могли бы вы составить смету расходов и детальный план освобождения принцессы? На каждый день пункт отправления и пункт прибытия, время в пути, сколько это будет стоит, где вы собираетесь сразить драконов, сколько и конкретно каких, где будете убеждать волшебников вам помогать, и какие вспомогательные задачи для этого придется выполнить..." А если ты не можешь указать третьего дракона, которого придется сразить, поскольку на него пальцем должен указать второй волшебник, которого ты должен уговорить, то ты – плохой девелопер, пардон, принц...

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

Кстати, вы уже поняли, что это я под методологии разработки софта подкапываюсь. Да, эти архитекурные ублюдины, которые чванливо вам говорят "А мы используем XY# методологию, и у нас замечательно получается...", все что они делают – это выгружают всю творческую и сложную работу в "планирование", оставляя на "реализацию" откровенную халяву, вроде написания кода для уже полностью понятного и организованного процесса. А потом говорят "Видите, как у нас хорошо получается?" А ни хрена у них не получается. Они просто аморально, беззаконно и бесчестно изнасиловали своих людей и заставили их выполнить всю работу вначале забесплатно, после чего и правда остались "семечки". В общем, им и правда "хорошо", но сколько можно людей забесплатно использовать.

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

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

Программирование и фреймворки

Я не слишком сложно обьясняю? Давайте на примере попроще...

Помните, MFC и первые библиотеки Жабы? Как люди гордились, что знают их наизусть. До сих пор помню телефонное интервью в 1998-м с одним козлом из Чикаго... К разработке софта таких на пушечный выстрел подпускать нельзя, но как он был горд своим знанием ныне полностью устаревшей библиотеки... Его главная подколка была: "Что вы сделаете, если нужно 10,000 элементов засунуть в один combo box?" Все, что он хотел, было вставить обработчики события на смену индекса, которые динамически подгружали бы новые элементы и убирали лишни, когда пользватель достигал бы начала или конца списка. Потом я рассказал это как анекдот на интервью в IBM в 1999-м, и мы дружно посмеялись над идиотом. Суть-то проста. Машина – железная, она может такое издевательство и выдержит, а пользователь перед ней – нет. И ему сильно помешает, что список дергается у концов как сумасшедший.

Но шутки – шутками, а суть в том, что плюсом считалось знание библиотеки. Вот это и была ОНА, экономика ЗНАНИЯ. Знаешь эту вонючую библиотеку до последней запятой – молодец. Конечно, если она хоть кому-то еще зачем-то нужна. А не знаешь – бяка, плохой девелопер. Кака. Все просто, правда?

Вот только с JDK 2.0, и еще больше с .Net ситуация изменилась. Библиотеки разрослись настолько, что даже идиоты с очень хорошей памятью не могли их запомнить полностью... И что пришло взамен? Ага...

Еще в 1980-м нам на мат-мехе обьясняли, что хороший математик не тот, кто знает все, а тот – кто знает, где прочитать. Ну, дак, то – математика, Царица Наук. А всякая дребедень вроде программирования ее догоняет только со временем, когда развивается до какого-то хоть сколько-нибудь приличного уровня. Вот и доросла... блин...

Начиная с .Net, хороший программист – это не тот, кто помнит наизусть все интерфейсы, а тот кто знаком с кнопкой F1 и знает как ее использвать... Знание сменилось открытием. Ты уже не знаешь как что-то сделать, но ты знаешь как найти знание, как это сделать. В просторечье, "найти знание" называется "открыть".

Экономика Открытий

Почуствовали разницу? Вот она – экономика открытий. Перед носом. И дразнится, зараза. А как и не дразниться, перед такими тупыми, что ее в упор не видят. Самому стыдно, сколько ее не замечал...

И вот она разница. Экономика знаний состояла в том, что работник, а не менеджер обладал знаниями. Менеджер уже не знал, что надо делать на благо компании. А работник наоборот знал. Что и ставило прежнюю социалистическую систему "ты – начальник, я – дурак" с ног на голову.

А теперь, в экономике открытий, и работник не знает. Да, он обладает знаниями, но нужную фирме фиговину он должен открыть, придумать, создать из нуля. Чтоб был iPhone, а не следующая реплика того, что и так у каждого второго в кармане. Причем не у первого, поскольку тому и этого не нужно. И так везде. В программировании. В автомобилестроении. В авиаиндустрии. В военном деле. Везде, чтобы выжить в бизнесе нужно придумать то, чего НЕ БЫЛО. И это – ключ. Этого не сделать, если ты безмоглый исполнитель, как при социализме. Этого не сделать, если ты обученный и сертифицированный "специалист", как в экономике знаний.

Заключение...

Мда-м... опять никто не услышит, а если услышит, то сопрет, и никто так и не узнает, что я первый об этом рассказал... Нет, человечество определенно отвратительно, впрочем, это – не новость. Да, ладно, какая разница... Суть простая. Экономика знаний уже тоже умирает. Не в России еще, но в мире, в Америке. Но еще не умерла. И еще довлеет над нами куда хуже чем социализм.

А вообще-то больно, просто больно. Представьте себе Креза, которому говорят, "ты – парень, просто страдаешь манией величия. Это все золото и так тут было. Видишь – оно есть, значит и было! Ты что, действительно хочешь чтоб мы поверили, что твое прикосновение превращает все в золото? Ты, давай, того, не выпендривайся. Мы тебя так и быть потерпим, но ты вокруг ничего не трогай. А если найдешь еще золото, не притворяйся, что сам его создал, а позови нас! Не твое, отдай начальству! И не мудри, ты тут – совершенно ни причем."

Как обычно, кросс-пост с персонального блога...

10 лет с правом переписки...

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

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

Cross-post from the personal blog.