August 14th, 2005

2019

Воскресные заметки

Несколько лет я пытался делать содержательные заголовки к своим постингам. А сейчас -- после появления внешних поисков (а также ALJ) можно и отказаться от этой привычки. К тому же я обнаружил, что найти какую-нибудь ссылку для упоминания в частных письмах мне легче уже через нахождение постинга с этой ссылкой, а не через список favorites браузера (и уж точно не через тяжелый механизм закладок).
* * *
Поглядите, как долго и сложно двигался человек от "общей теории" (Theory of constrains в данном случае, Thinking Process, метод CCRT) к положениям, которые давно и подробно описаны в экстремальном программировании: http://clarkeching.blogs.com/tocsoftware/ (вкратце: главное найденное противоречие выглядит как невозможность работать над неизбежными изменениями в спецификациях и одновременно выдерживать планы и бюджеты). Неудивительно, что пройдя в помянутый на этой страничке список рассылки http://finance.groups.yahoo.com/group/TOCSoftware/ мы обнаруживаем много постингов Ron Jeffries (да, один из соавторов Extreme Programming Istalled -- http://www.xprogramming.com/). Было очень поучительно заглянуть к нему на страничку и убедиться в том, что XP вполне себе живет и развивается.

В XP (и очень большом количестве других методологий) де-факто работают принципы из "общих теорий", или как их сейчас называют "философий управления". Более того, все они дополняют друг друга. Так, critical chain из TOC может сильно ускорить продвижение проекта через итерации XP стандартным предложением "уполовинь размер партии" и "планируй оптимистично" (пример: http://finance.groups.yahoo.com/group/TOCSoftware/message/306).
* * *
А еще мне кажется продуктивной аналогия между реформированием и производством софта -- ибо производство софта отличается и от manufacturing и от проектной работы. Нужно будет подумать над этим: очень богатая аналогия. Я давно вводил разницу между работой в режиме функционирования, проектной работой и программной работой (а реформы -- это именно программы, как говаривают наши методологи "пошаговое движение в воронке возможностей"). Но все руки у меня не доходили проработать эту тему. И что же: современные "общие философии менеджмента" предоставляют отличный способ описывать такое программное движение в виде неких "циклов улучшений". Но реформирование -- это все-таки не "налаживание производства", это другое. В частности, во всех "философиях менеджмента" не забывается говорить о том, что главная цель -- это "рост скорости зарабатывания денег сейчас и в будущем". Ну, и как пришить это к госреформам -- даже если согласиться, что "рост скорости зарабатывания денег" в "общих философиях управления" достигается именно что институциональными реформами? А вот в софтверных проектах (гм... ну не проекты это, а программы -- не сочтите за каламбур!) совсем другое, и методы организации работы поэтому другие -- более похожие на тот бардак, который обычно творится в реформах.

А не проводить ли нам при организации реформ планирующую игру и не раздавать ли карточки? ;) С соответствующими доработками, понятно.

У меня, кстати, были наработки по обобщению XP на несофтовые задачи с невозможностью up-front design (я поминал это "экстремальное выполнение работ" еще в постинге Школа-2 (http://www.livejournal.com/users/ailev/44904.html, но почему-то пропустил в постинге "частный государственный университет" http://www.livejournal.com/users/ailev/192607.html и не помянул явно в недавнем "симултрек и реформы" http://www.livejournal.com/users/ailev/329646.html, по идее это должно там войти в "10. Налаживание работы институтов"). Вот презентация по "экстремальному выполнению заказных работ": http://www.techinvestlab.com/47987, речь идет о варианте организации работ при стремительно меняющихся ожиданиях и требованиях.
* * *
Интересно, как потихоньку разные методологические инструменты слипаются в одну Большую Картину. Так, продажи по методу SPIN уже не только мной рассматриваются как вполне себе интегральная часть в рамках той же Теории ограничений (http://www.dbrmfg.co.nz/Strategy%20Sales.htm). Вообще, разных компиляций
* * *
Общее ощущение, остающееся от всех этих "Больших Теорий" -- невозможность размышлений в предлагаемых этими теориями моделях. Формальные методы, предлагаемые для эффективного размышления не работают. Или дают тривиальный результат. Более того, чем более обща теория, тем более тривиальный это будет результат. Научиться можно только в диалогах с носителями этих теорий, только моделируя их актуальное поведение, только решая собственные задачи и получая обратную связь. Иначе все эти абстрактные "деревья целей" быстро становятся совершенно неуправляемыми и будут только предлогом к получению набора плохих идей. Голдратт правильно написал свои первые книжки в форме производственных романов: так его тривиальные заключительные выводы и вопросы кажутся не такими уж тривиальными. Но ведь они тривиальны!

Что не тривиально -- так это предложения по конретизации этих выводов. Так, "показатели важны" является тривиальным рассуждением. А вот предложение конкретных показателей для Constraints Accounting уже не так тривиально и может помочь. Но тут же автор воспаряет крыльями и говорит, что в каждом конкретном случае требуется создать свою систему показателей -- исходя из общих его принципов! Так и хочется поправить: исходя не из общих принципов, а из вполне частных мозгов этого автора.

Это очень трудно -- держать золотую середину в уровне моделирования: между общими принципами и методиками конкретной предметной области. Вот я пытался что-то писать про общие принципы реформирования, но получил обратную связь, что взял слишком абстрактную ноту, оторвался от предметной реальности -- нужны конкретные примеры. Думаю, речь должна идти не только о конкретных примерах, но и более конкретных методиках тоже. Нужна связь абстракции с реальностью, нужно простроить достаточно мелкие ступеньки, чтобы было передано какое-то знание.
* * *
Дитенка сутками не выходит из игры Adiboo Energy Thieves. Мы уже вторую неделю ждем, что ему надоест. Увы, никак. Или не увы, а к счастью -- он таки научился нажимать разные кнопки на клавиатуре по одной, а не парой пальцев три клавиши сразу, да еще и нажимать вовремя, а не в случайное время...
* * *
Нужно заняться дисковым хозяйством. Жена умудрилась забить 80Гбайт винт в видеотюнере, и конца этому ее увлечению не предвидится. Нужно сходить на Савелу и купить нормальный внешний винт на 1Тбайт. А бэкап -- на дивиди делать...
* * *
Понял, как обходить мяту (уж больно ее гомеопаты не любят) -- чистить зубы детской зубной пастой. Мяты в детской пасте нет.
2019

Разработка презентаций как метод принятия решений и синхронизации группового понимания

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

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

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

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

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

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

На что уходит все это огромное дорогое время с кучей топов?

1. На выработку решений. Ибо в момент фиксации давно проговоренного в виде текста/картинок вдруг выясняется, что а) решения таки еще нет, б) не все с ним согласны, в) не все его понимают.

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

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

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

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

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

Новый technorati: ему и замки не страшны

Заглянул в http://www.technorati.com (впервые за последние полгода -- по слухам он обновился чуть ли не на днях), тестово поискал ailev -- и нашел на первой же странице результатов поиска закрытый пост в закрытом комьюнити, где упоминался мой ник. Интересно, как Technorati выкачивает и индексирует закрытые посты в ЖЖ?

Я бы не обратил внимания, но vvagr 161 день назад написал в нем "Постинг виден только..." -- и это как раз и высветилось на странице результатов поиска. Ну, я сходил по приведенной ссылке и проверил, на месте ли замок в том постинге. Замок пока на месте...

А сам поиск technorati приводит на порядок меньше результатов, нежели blogs.yandex.ru. Русскоязычным туда ходить неинтересно -- разве что за закрытыми записями.