В биографии Эдуарда Лимонова — писателя, диссидента и политика — есть неожиданный эпизод: в конце 1970-х годов, во время жизни в США, он подрабатывал в IT-сфере и, по некоторым данным, участвовал в разработке ранних версий языка C.

Почти 80 лет назад человечество узнало о методе мозгового штурма.

С тех пор про него писали даже в журнале "Трамвай" и назвали в его честь него один из стандартных шаблонов презентаций в Microsoft Powerpoint. Многие из читателей этой статьи, возможно, успели в нём поучаствовать. А организаторы напридумывали огромное количество причудливых вариантов, которые постоянно пытаются продать под видом бизнес-консультации.

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

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

Я внимательно изучил эту тему и добрался даже до первоисточников. И теперь я могу говорить, уверенно: не правы ни те, ни эти.

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

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

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

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

Допустим отдел аналитики подготовил нам Swagger YAML с описанием API доступа к какому-то сервису: xyz-swagger-v1.0.0.yaml.

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

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

Особенность китайских чаев — они допускают многократный пролив. То есть их можно заваривать быстро и несколько раз

Разумеется, наш стандартный заварочный чайник делался под индийские чаи, которые завариваются одним проливом и по многу. Чтобы пить чай китайский, его надо завариватаь прямо в чашке, но ещё лучше запастись стандартным набором:

1. Гайван или заварочный чайник. По сути, пиала-переросток, куда кладут чай и заливают водой.  В принципе, можно пить прямо из чахай.

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

3. Чашки или пиалки.

Чайный поднос и чайные инструменты пока оставим.

Причём, само собой, всё это должно соответствовать друг другу. Объём гайвана и чахана должны быть примерно одинаковыми, и равняться суммарному объёму пиалок. Чтобы чай и не застоялся и не успел остыть.

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

Давайте посмотрим, кто же готов получить мои деньги?

— …Вот, например, ты пишешь: «коллективное бессознательное». А ты знаешь, что это такое?

Татарский пошевелил в воздухе пальцами, подбирая слова.

— На уровне коллективного бессознательного, — ответил он.

— А ты не боишься, что найдется кто-то, кто знает отчетливо?

Татарский шмыгнул носом.

— Господин Азадовский, — сказал он, — я этого не боюсь. Потому не боюсь, что все, кто отчетливо знает, что такое «коллективное бессознательное», давно торгуют сигаретами у метро.

Виктор Пелевин, «Generation П»

У меня нет психологического образования. Я просто экспериментировал с индустрией и смотрит на неё глазами клиента.

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

И дело тут не в корпоративной солидарности. Психолог смотрит с другой стороны и видит саму ситуацию под другим углом.

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

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

И все они оказались поразительно некомпетентны. Они не просто не смогли взяться за терапию тех проблем, с которыми якобы работают — они не смогли даже толком меня одурачить!

Очень хотелось изучить Ruby получше, а рабочего проекта не было. И я попробовал написать gem для работы с Yandex Direct API.

Причин было несколько. Среди них: Yandex Direct API очень типичен для Яндекса и современных REST-сервисов вообще. Если разобраться и преодолеть типичные ошибки, то можно легко и быстро написать аналоги для прочих API Яндекса (и не только). И ещё: у всех аналогов, которые мне удалось найти, были проблемы с поддержкой версий Директа: одни были заточены под 4, другие под новую 5, и поддержке units я нигде не нашёл.

Метапрограммирование — великая вещь

Основная идея gem-а — раз в языке вроде Ruby или Python можно создавать новые методы и JSON-подобные объекты на лету, то методы интерфейс для доступа к REST-сервису могут повторять функции самого Rest-сервиса. Чтобы можно было писать так:

request = {
    "SelectionCriteria" => {
      "Types" => ["TEXT_CAMPAIGN"]
    },
    "FieldNames" => ["Id", "Name"],
    "TextCampaignFieldNames" => ["BiddingStrategy"]
}

options = { token: Token }
@direct = Ya::API::Direct::Client.new(options)
json = direct.campaigns.get(request)

А вместо того, чтобы писать справку, отсылать пользователей к мануалам по указанному API.

Забытое искусство подсказки

Что у нас есть?

var source1 = '[{"vConfig":{"vType":"objectview","serverItemType":"TrackerObject"}}]';

var source2 = '[{"vConfig":{"serverItemType":"TrackerObject","vType":"objectview"}}]';