Дальше я взялся за задачи блока sre. Самое мне понятное — single producer single consumer queue. Я просто попросил chatGPT написать на C++ на слабых мемори семантиках spsc очередь. Он выдал достаточно лакончиный и рабочий код на кольцевом буфере. Там зачем-то был лишний массив, как член класса, но его было легко удалить. Локально эта реализация проходила тесты, но вот в контрольной системе — нет. Тогда я вкрутил самую попсовую оптимизацию: заменил остаток от деления на логическое И (предварительно захардкодив размер буфера в степень двойки: 2^15). И НЕ ЗАШЛО! АХАХАХАХА. Я поменял размер буфера на 2^16, и тогда зашло. Не ищите здесь логику. Дело в том, что тесты в контрольной системе ОЧЕНЬ шумные. Мог ничего и не менять, короче.

Разделавшись с очередью на раз-два-три, я взялся за задачу retry. Тут мы сталкиваемся с golang. Там есть клиент и сервер. Сервер падает на произвольное количество времени, потом поднимается. Клиент должен:
1. Не просыпать ни одного запроса
2. Поддержать RPS не более, чем x3 от нормы
3. Поддержать тайминги не более, чем х4 от времени недоступности сервера
Я сначала придумывал хитрые алгоритмы отображения отрезков одной длины в отрезки длины х4, но минут через 20 понял, что надо просто написать рейт-лимитер. Я попросил chatGPT написать мне тупейший рейт-лимитер на скользящем окне (никаких вам лики бакетов и подобного), прям с мьютексом, не выдумывая ничего. Настроил рейт-лимитер на параметры условия задачи. И зашло с первой попытки.

Далее я взялся за задачу traces. Я её так и не сдал. Условия там замудренное, но по-сути нужно научиться склеивать спаны в трейсы, находить самые нагруженные участки и репортить их. Извините за мой французский. Условие было довольно нечеткое, много белых пятен и неоднозначностей. Я сразу же, не думая, скормил его chatGPT. Тот выдал довольно понятный, но прям _очевидно_ неоптимальный код на golang. А, да, он еще и не работал. Даже на скормленных примерах. Я надолго откладывал эту задачу в пользу более интересных bpftraces, однако, вернулся к ней после всего. Мне удалось дожать версию нейронки до состояния, когда она падала по таймауту на последнем тесте. Правда, для этого пришлось реверс-инжинирить первый тест на сервере (печатал его данные в выхлоп, чтобы посмотреть в логах CI).
Когда я переделал алгоритм на сильно более оптимальный вариант, я его сломал 🤡 Теперь оно падает где-то на 35-м тесте. СОВРЕМЕННЫЕ ЧУДО-ТЕХНОЛОГИИ МЕНЯ НЕ СПАСЛИ! Ура! Нас не заменят! Хорошо, что я менеджер.

Дальше было самое мясо. Я вообще не знал, как пользоваться bpftrace. Поэтому уже на первой задаче (оттрейсить, какая программа и сколько пишет на диск) я пошел спрашивать chatGPT, чтобы научила меня писать скрипты для bpftrace. Оказалось, что тула очень сырая, некоторые синтаксические конструкции из доки не работают на многих версиях. Но с грехом пополам и one-liner'ами с сайта Брендона Грегга я разобрался. Первая задача залетела минут за 20.

Примерно в этот момент объявили, что для получения сертификата необходимо набрать 1300 баллов. Это означало, что нужно обязательно сдать либо traces, либо bpftrace-3 (самые дорогие задачи). Поэтому, я тут же взялся за bpftrace-3. Это просто мозги в фарш, ребята. golang, функция-член структуры принимает аргументом указатель на структуру из инта и строки (строка в голанге это инт и массив байт, не 0-terminated, как в Си). Нужно собрать все вызовы, для каждой строки из аргументов сложить числа.
Не, ну так-то изян. НО ЭТО ГОЛАНГ! ChatGPT здесь выдает вообще не рабочие варианты. Брожение по документации bpftrace — тоже. Более того, там есть misleading обсуждения, что в голанге calling conventions разные в разных версиях (то на стеке, то в регистрах), но ни одна из этих версий у меня не сработала.
Я уже и таблицу символов всю до дыр просмотрел, уже и научился правильно трейсить такие методы (например, u:main:* не сработает, а вот u:./main:* — да 🤡), если хотите потресить метод, у которого в названии скобочки и звездочки (голанг же), то возьмите его название в двойные кавычки (u:./server:"main.(*Server).Serve"). И on-liner'ы ваше всё. Ничего не работает.
Пришлось расчехлять gdb. Там цепляемся к процессу, ставим брейкпойнт внутрь искомого метода, смотрим, че на стеке, че в регистрах, кастим всё к желаемому типу — находим аргумент в регистре rbx.
Далее в bpftrace скрипте читаем регистр, считаем смещения, собираем строку и вуа ля — нифига не работает, потому что регистра rbx нет. ebx, кстати, тоже. Вот вам знание, которого нет в интернете: надо читать регистр bx. Без префиксов. Тогда работает.

И на десерт я взял трейсинг мьютекса: какой трейс сколько держит лок (никогда так не радовался C++). Там всё просто, даже chatGPT не нужен. Если трейсите мьютекс. Но наивное решение не работает! Я битый час пробовал трейсить и lock (еще пойди научи bpftrace ловить деструктор!) и mutex. Несколько часов пытался понять, почему один из трейсов дублируется, хотя он ключ хеш-таблицы (это баг самой bpftrace). Оказалось, что я трейсил не то! Я считал время от момента входа в функция для лока (то есть вместе с ожиданием, когда лок станет доступен), а надо было трейсить выход! Это делается заменой u на ur.

В общем, сертификат я получил, но одну задачку не сделал. А упражнение весёлое. Мне понравилось.

Прям щас
Стрим Бушвакера
Средневековая Япония
Потом не говорите, что я вас не предупреждал
https://www.twitch.tv/bushhistory?sr=a

Так как планировать

На самом деле здесь есть несколько вопросов в одном. Будем разбирать по одному.
1. Как оценивать срок проекта?
2. Как спланировать проект (в смысле риск менеджмента)
3. Как исполнять сам проект? То есть как двигаться по проекту, вовремя определять риски и понимать с ними.

Я постараюсь напоить поменьше воды, но тема очень абстрактная. Поехали.

1. Сроки. Никто никогда не попадает в сроки. Это на самом деле очевидно, потому что срок это точка во времени (а время мощности континуум), иными словами вероятность попасть точно в срок равна нулю. Но это не возможное событие (вы почти наверное знаете о чем я, в этом то канале).

Но что тогда делать? Подумать! Что мы обычно имеем в виду, когда называем срок? Это какая-то точка, в которой скорее всего будет готово. Но с какой-то вероятностью будет готово раньше, а с какой-то позже. Более того, плотности вероятностей будут не линейны слева и справа от точки. Поэтому гораздо более честно будет называть несколько точек: будет готово через 7 дней с вероятностью 80%, через 8 дней с вероятностью 90%, через 14 дней с вероятностью 99% и т.д.

Да, это гораздо сложнее для других менеджеров (и вообще для людей, вероятности же), но на самом деле это гораздо честнее и позволяет более продуманно подходить к смежным активностям (маркетинг, лигал и т.п.). Кроме того, уже сам факт работы с вероятностями заставляет смежников заниматься управлением рисками. Петя из юр отдела послушает вас и подумает: "хм, если через неделю будет готово только с вероятностью 80%, то стоит поуправлять ожиданиями той стороны и заложиться в контракте на просрочку".

А как оценивать эти вероятности?
Начнём с того, что задачи делятся на две фазы: НИ и ОКР.
Вот НИ оценить очень сложно. Зато его можно задать! Мы можем управлять ползунком между качеством придуманного решения и временем, затраченным на его изобретение. Топорные решения обычно можно выдать за часы. Что-то поумнее требует больше времени. Вот ставьте дедлайн: думаешь не дольше, чем Х времени, потом приносишь, что надумал.

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

Для нас с вами, любителей дата дривен всего (хотя я тут совсем не фанатик), у меня есть бонус-трек. Если вы работаете MOVE'ами, если у вас уже есть какая-то история такой работы, то у вас есть статистика. У меня, например, есть прям графики, где можно посмотреть, за сколько какой персентиль каких эпиков/сторей/move делается.
Вот мы недавно спланировали проект на квартал. Экспертная оценка (целились в 80% вероятности) совпала с оценкой по 85%% из статистики.

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

Отмечу только, что есть ещё один полезный взгляд на риски (и вообще на многие вещи, Брукс так на проблемы разработки ПО смотрит в no silver bullet).
Бывают случайные риски (кто-то заболел), а бывают системные/процессные (не знаю как назвать нормально) риски. Вот вторые бывает сложно заметить, но они самые злые, они жрут ваш фрупут постоянно, очень тихо чавкая. Это могут быть какие-то неэффективные коммуникации, ненужные бутылочные горлышки, размытые договорённости и т.п. Например, нужно всегда получать апрув на фичу от тимлида, который вечно занят на встречах — это вот оно. Или надо ждать викли, чтобы сообщить о проблеме — тоже оно.

Про третий пункт будет позже.

SCRUM это хороший инструмент для слабых менеджеров

Буквально все ритуалы скрама призваны угнетать пролетариат и снимать ответственность с руководителя. Давайте разбираться.

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

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

3. Дейлики. Это на самом деле маленькие демо. Разработчик должен помнить, что завтра утром ему рассказывать, чем он занимался весь день. И если вдруг работа никак не шла: то отвлекут, то окружение не собирается, то соседка пишет, что кота тошнит насквозь семь этажей, — то придётся работать ночью. Или выдумывать, что ты сделал, а в следующий день пытаться уместить в два раза больше работы. В итоге не успеть к демо и выгореть.

4. Груминг. Акт снятия ответственности с лида, переноса её на коллектив. Неверно выбрали приоритеты — МЫ виноваты. Ошиблись в оценке задач — ВЫ виноваты (разработчики). А вот если всё у команды идёт хорошо, то молодец менеджер, это же он всё настроил так хорошо.

5. Ретроспектива. Это либо поиск виноватых в предыдущих проблемах, либо способ заставить работников придумать, как их получше эксплуатировать. Зачем думать менеджеру, если может подумать команда!

А помните, был такой — семавер?
Ну вот он остался в Фетхие. Оказалось, что в Белграде такую штуку не найти! Но мои любимые коллеги в этом году подарили мне новый на день рождения ❤️
Привёз из Москвы в Белград турецкую вундервафлю и счастлив. Такие дела.

Держу в курсе.

Обещанная третья часть про управление проектами

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

Итак, у нас есть на самом деле уже спланированный и оценённый проект. Есть сроки с вероятностями, есть риск реестры. Есть диаграмма Ганта (мы по ней искали критическую цепь).
Начинаем работу!

Всё, наша диаграмма Ганта устарела и поплыла! Но не спешите её чинить, она нам больше не нужна.

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

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

Мы уже давно живём в мире итеративной разработки. Наша итерация — это один сделанный MOVE. Обычно, после итерации предлагается посмотреть:
- как изменились требования
- выбрать, что делаем дальше
- подумать, где было плохо и почему; как сделать лучше

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

Берём нашу оценку срока проекта (там уже есть обычно менеджерский коэффициент). Делим на 2. Очень грубо, здесь проходит 50% вероятности, что мы закончим проект к этому сроку. Про плотности вероятностей у меня был пост с Монте-Карло, я все ещё считаю, что здесь что-то примерно логнормальное.
Теперь, берём половину от этой половины. Это будет где-то 80% (3/4 времени, но распределение скошено влево). Эта четвертина будет нашим сигнальным буфером.

Каждый день мы смотрим:
1. Насколько процентов готов проект
2. Насколько процентов использован буфер
Делим второе на первое. Это наш индикатор проблемности! У него есть лаг длиной с первую половину проекта, но если это долго, то можно брать промежуточные майлстоуны.

Если индикатор сильно меньше 1, то всё хорошо. Если больше 1, то очень плохо, скорее всего уже поздно спасать проект.
Вам нужно выбрать себе диапазоны значений, где
1. Все норм, зелёное
2. Что-то медлим, жёлтое, надо бы посмотреть
3. Отстаём, красное, срочно чинить

Начинать искать причины проблем в проекте нужно уже на жёлтом. На красном нужна уже не профилактика, а лечение.

Бонусом к такому подходу идёт то, что мы видим на индикаторе не только проблемы в конкретной итерации, но и проблемы всего проекта. То есть здесь видны вещи, которые курочка по зёрнышку отъедают пропускную способность вашей команды.

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

PS:
Нигде в тексте не пришлось к месту важное замечание. Чем дальше во времени ваши планы и задачи, тем более они размыты, тем менее специфицированы. С появлением новой информации (в т.ч. требований) может меняться будущее проекта. Его можно вообще остановить. Отсюда сразу можно делать вывод, что детальные планы нужны максимум на одну итерацию вперёд. Остальное больше для оценки и задания направления.
И это ещё один повод вспомнить, что мы не исполняем план, мы решаем задачу.

У меня сегодня контент-бомба!
Вы знаете, что я про Яндекс не пишу вообще ничего. Но вот на каналы и посты коллег ссылаюсь регулярно! Оказалось, что существует огромная папка с каналами
яндексойдов. Там можно найти контент и про компанию, и про разработку, и про менеджмент, и про ML и ещё кучу всякого, в чем я не разбираюсь 😁.
Забирайте папку, выбирайте себе любимчиков, читайте!

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

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

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

Но на общем сборе оказалось, что только две пары из шести или семи вроде смогли о чем-то договориться и заключить сделку. То есть я попал в 15% УСПЕШНЫХ кейсов! Просто вау!

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

Как это сделать?
1. Не показывать нужду. Оно же право на нет. "Если вас не устраивает цена, можете искать другого продавца, ничего страшного"
2. Говорить нет не предложения, которые вам не подходят. Да и вообще на первое предложение. Это создаёт конструктивный лад, так как вторая сторона теперь хочет понять, что нужно, чтобы нет превратилось в да.
3. Снова право на нет. Вы предлагаете Х, но говорите, мол, нет так нет, никаких обид. Если это принципиальный пункт, вы услышите нет.

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

В чате писали, что не могут со мной связаться, поэтому я сделал бота для обратной связи @QuantValerianBot
Инжойтесь

А чтобы пост не был совсем уж бесполезным, вот вам примерно контекст последнего поста (где я писал, что вокруг все внезапно заговорили про переговоры)


Книга Кэмпа "Сначала скажите нет", мы читаем в книжном клубе

Третья глава книги "Путь камикадзе" про переговоры вокруг безнадёжных проектов

Коллега из лавки про переговоры https://t.iss.one/leadsnotes/55

https://youtu.be/1xJVYAVdrUY?si=0rlLFlkd2_G7dqnj подлодка про зарплатные переговоры (я больше рекомендую более старый выпуск с тем же гостем)

https://youtu.be/gs4NoXwXCEE?si=Pocft1aksG9ypN84 Бреслав и Ложечкин про переговоры в корпорациях

https://youtu.be/IwsdeH3SUQ4?si=9WHwJmgumDAvF9fb мультик про переговоры с иностранцами

Плюс подлодка ещё очередную мини конференцию стартовала про переговоры и теперь везде их реклама))

А ещё я машину продаю, кстати

Ключевые принципы успешных переговоров по Кемпу

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

1. Контролировать чувство нужды, скрывать его. Давать визави право сказать "нет". Если вы будете цепляться за сделку или какое-то условие в ней, а та сторона это поймёт, из вас выжмут максимум по все параметрам, угрожая отобрать пункт, в котором вы нуждаетесь.

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

3. Не бояться говорить и слышать "нет". Слово "нет" выводит на конструктив. Вам что-то предлагают, вы отвечаете "нет". Именно в этот момент визави начинает выяснять, почему именно нет, здесь начинаются переговоры по-существу. Если вы скажете "да", то дальше уже проще вам досыпать деталей, вы же уже согласились! Если скажете "может быть", это вообще не дает никакой информации и никуда вас не движет. Говорите "нет".
Быть готовым услышать "нет" это снова про первый пункт. Вы не должны нуждаться. Нет так нет, договоритесь с кем-то другим или в другой раз. Поощряйте собеседника говорить "нет", таким образом вы вынуждаете его принимать решение. Если он не готов сказать вам "нет", то автоматически должен уже сказать вам "да".

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

Продолжаем тему пользы говорения с людьми через рот

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

Многие знают, что и сам в некотором роде чайный мастер. А о чайных мастерах есть стереотипы.

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

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

Время шло. Я скучал. Мастер закончила с гостями и, проходя мимо меня, заметила, что я всё ещё один. У неё был перерыв, в который она surprise собиралась попить чаю. Ну и предложила со мной поделиться. Я с удовольствием согласился!

Она отлила мне из термоса в стакан чай тёмно красного, даже немного коричневатого чая. Это оказалась очень вкусная смесь трав с малиной, а в основе был какой-то красный чай. Офигенно, должен вам сказать!

И понимаете ли, в чем дело? В самой каноничной чайной Москвы, чайный мастер пьет, о ужас!, какие-то травы! Не чистый шен пуэр с больших диких деревьев 1998 года сбора, не из пиалы, без чайников гайваней и чахаев. И всем норм.

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

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

А друг мой тогда довольно скоро пришёл. И мы устроили гун фу ча с каким-то древним тайваньским улуном. Было вкусно и весело.

Давайте знакомиться

Меня зовут Валерий Овчинников, и я квант в нескольких смыслах.

- Во-первых, я закончил на Физтехе факультет ФФКЭ, студентов которого традиционно называют квантами.
- Во-вторых, я проработал больше шести лет quantitative developer / trader в больших немецких и австрийских банках. Людей на этих позициях тоже традиционно называют квантами.
- В-третьих, у меня бакалаврский и магистерская по так называемым "квантам" — я моделировал элементы квантового компьютера и искал оптимальные способы управления кубитами на алмазах.
- В-четвертых, я очень люблю количественное всё. Quantitative подход стараюсь использовать максимально. Начиная от финансов, заканчивая менеджментом.

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

Ещё со мной можно поменториться на getmentor.

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

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

У меня с института много друзей и просто приятелей, один успешнее другого. Самые успешные, кстати, девушки. Некоторые уже даже целые СЕО.

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

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

А вот первые мотивируют бежать быстрее. Потому что они на своём примере демонстрируют, что _реально_ можно добиваться большего. И я, например, бегу быстрее.

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

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

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

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

Не зря же лучшие вузы воспитывают не одно поколение успешных семейств.

Как это мы тут выше называли? Нетворкинг? Кумовство! Кумовство топ.

Об закон необходимого разнообразия

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

О чем речь?
Речь о вполне формальном законе кибернетики. Представим, что есть система (процесс). В системе есть множество состояний X. Мы можем управлять системой, используя некие "управления" u (ну, считайте некоторое управляющее воздействие). Таких управлений у нас тоже целое множество U. Ну и вот некоторое конкретное u из множества U переводит систему из некоторого конкретного состояния x из множества X в некоторое конкретное состояние y из множеcтва X.

Дальше, мы хотим управлять так, чтобы порядочек наводился. Уменьшать энтропию то бишь. Если не хотим, то объясните в комментах почему. Это значит, что энтропия в состоянии y должна быть не больше, чем энтропия в состоянии x. Дальше собственно закон, пикрелейтед. Вот H — это энтропия, а I — это количество информации.

Здесь мы действительно видим, что чем больше энтропия (разнообразие) управления, тем "круче" мы управляем (сильнее уменьшаем энтропию целевого состояния).

Ещё мы видим, что, поскольку энтропия — величина сугубо неотрицательная (логарифм стат веса), то если I(u,x)>=H(x), то неравенство всегда верно.
И вот тут начинаются нюансы.

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

Во-вторых, в функции I кроме энтропии u, есть еще энтропия u при условии x. Что это такое, при условии?
Представьте, что мы вот полностью достоверно знаем текущее состояние x. Теперь представьте, что мы абсолютно точно полностью понимаем, какое u нужно применять к такому состоянию x. Тогда вот эта условная энтропия будет равна нулю. Если же мы, глядя на x, понимаем, что нам нужно применить u из какого-то подмножества U, то есть мы примерно понимаем, что надо делать, но у нас есть несколько вариантов, то вот эта вот H(u|x) как раз будет мерой нашей неопределенности, разнообразия этого подмножества управлений. В пределе, если мы вообще не знаем, что делать в состоянии x, наше управление никак не будет зависеть от текущего состояния. Значит H(u|x) = H(u), а I(u,x) = 0.

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

Давайте собирать всё вместе и делать выводы.
1. Недостаточно просто иметь кучу методик управления. Нужно понимать, когда и какую применять. Чем лучше ты это понимаешь, тем эффективнее управление (спасибо, кэп!). Однако, разнообразие методов здесь всё-таки играет первоочередную роль.
2. Нет необходимости в том, чтобы разнообразие управления было больше, чем разнообразие управляемой системы. Тем не менее, если такое соотношение имеет место, наше управление стабильно эффективно. (Здесь еще можно сразу подумать про закон Седова).