Вы могли слышать, что в сеть утекла онбординг инструкция mr beast. Это уже несколько лет топовый производитель роликов на youtube. И вот теперь мне кажется, что это вообще не случайность!

Я её прочёл, когда летел в Алматы. Занимательнейшее чтиво! Офигительно рекомендую.

Первое, на что я обратил внимание — тема про A-player'ов. В моей голове это мем про Револют. Идея здесь примерно та же, что была и у Сторонского. Джимми хочет в компании увлеченных людей, которые быстро учатся, хорошо соображают, готовы брать на себя ответственность и вообще лучшие в мире в своей профессии. Есть ещё B-player'ы — это те, кто хочет стать A-player'ами. Их тоже можно нанять, но при условии их быстрой конвертации в A-player. C-player'ы — это средненькие обычные сотрудники, таки в mr beast production не нужны, как и в свое время в Революте.

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

Dog fooding
С места в карьер сотрудникам предлагается удалить к чертям нетфликсы и хулу, но начать смотреть тонны ютуб видосов, особенно рекомендуется просмотреть бОльшую часть контента самой студии.

ToC
Там прям буквально написано: "настоятельно рекомендую прочитать 'Цель' Элияху, а то как дети малые". И здесь речь про _производство_ контента, не про сам контент. А производство роликов это, оказывается, типичный конвеер. Из документа вижу как минимум: набросок, креатив, сценарий, съемка, монтаж, публикация и постпродакшен (в документе есть немного про анализ данных и эксперименты).
И, блин, чуваки реально понимают, что все сроки подвязаны на ограничение. И работают с этим. Хотя не слишком формально.

Коммуникации
Любопытно, что здесь accountability доведен до абсурда (ну или нет, я не управляю самой успешной студией). Каждый чувак ответственен не только за свой кусок, но и за пуш всех, от кого он зависит. Причём, пушить рекомендуется _каждый_божий_день_. Типа чекай статус, как оно там. А может затягивается? Надо тогда что-то срочно придумывать. Это как бы дейлики, но только не со своей командой. И, да, важно, что тыкать надо не всех, а тех, кто реально сейчас является бутылочным горлышком твоего проекта.

Отдельно меня зацепила тема выбора метода коммуникации. Чем более важная задача, тем более личной должна быть коммуникация. Примерно: email -> messenger -> zoom -> личная встреча. Объясняется это тем, что чем более близкая встреча, тем больше нюансов и деталей передается при коммуникации, тем меньше вероятность понять человека неверно.
Это для меня очень интересная идея.

Accountability
Опять, да. No excuse — снова вайбы успешного британского финтеха. От сотрудников требуется майндсет, что _они_ ответственны за результат. Даже если работу делает аутсорсер.
В качестве совета предлагается _всегда_ держать денёк про запас.

Culture
Поощряется говорить, почему продукт говно. И это, блин, такая жиза! Невозможно понять, куда развиваться, если у тебя везде написано "молодец" (да, я опять прошел тимлида по тем метрикам, что писал полгода назад, кек).
Поощряется челленджить самого Джимми, потому что, сюрприз, он тоже бывает не прав. Это супер важно в команде.
Поощряется креативность. Не нужно ездить по одним и тем же рельсам, колея получится. Здесь пример, что призом можно делать не деньги, а годовой запас доритос! И круто и денег сэкономили!
Поощряется лезть в детали и разбираться до мелочей. Если что-то слишком хорошо, чтобы быть правдой — выясни, в чем дело.
Поощряется признание ошибок, если они потом не повторяются. То самое blameless.
Явно проговорено, что нужно соблюдать приоритеты, если они выданы. Удивительно, что приходится это прописывать на бумаге, но такова жизнь
Честность важнее вежливости (artificial harmony, если вы понимаете о чем я)
Проще — лучше

Про навыки

В чате идёт обсуждение навыков low latency программирования и особенностей позиций в HFT фирмах. Имею кое-что сказать.

Мои специальные навыки начали развиваться в Дойче Банке.
Как сейчас помню, мне пришло письмо от рекрутинга с описанием вакансии, где требованиям были три года опыта и умение в low latency программирование на java. Я тогда сидел в Долгопрудном, в одном из корпусов Физтеха, заваривал в стакане тай пин хоу куй и деплоил на коммунальный веблоджик свои потуги. Я прочитал имейл с вакансией, тяжело вздохнул и закрыл вкладку.

Вообще-то, мне ОЧЕНЬ хотелось в ДБ. Там какие-то крутые штуки делают, low latency, gc-free, какой-то кнокаренси крутой. А у меня тут мрак с ejb 2, в котором я никак не могу толком разобраться. Только и остаётся, что читать статьи про перфоманс и пейперы про лок-фри алгоритмы.

Звонок. Рекрутер из дойче спрашивает, видел ли я вакансию. Конечно, видел, но я не подхожу: у меня даже банально трёх лет опыта нет, не то, что low latency там какие-то... Да это все не важно! Попробуйте, ничего не теряете.

А чо, так можно было?!

Сажусь на электричку с Новодачной до Беговой, подхожу к Nordstar. Эта башня из стекла и бетона вблизи производит впечатление! Я же сейчас в небоскрёб зайду!
В лифте закладывает уши, со временем привыкаешь.

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

Выхожу измотанным. В общагу. Температура 37.5. Рекрутер пишет, что я прошёл.
Потом собесы, собесы, собесы с боссами. Наконец, я выхожу.

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

А вон тот парень сделал проект по маркет дате, лучший в округе сервис по скорости. Будет моим тех лидом.

И мы писали и писали код, читали статьи и книги, собирали метрики с прода, тюнили gc, отдали фид какому-то азиатскому роботу, потом отдали фид дойчевской лучшей торговой машинке.
О, да у нас в пике 2к рпс! А мы держим SLO по латенси! Ещё и ставили четыре копии машинки в разных ДЦ — у нас хай лоад!

Показалось, что на одной машинке я научился делать уже все. Начал читать про распределённые системы. Ох уж этот paxos... Так, что там у нас: gfs, f-1, dynamo, spanner — круто, конечно, технологично, НО НЕ ТО, ЧТО У НАС. Вот, где реальные задачи! Пацаны вон в соседнем отделе на джаве коннектор писали, там 60мкс 99%%, а вы консистент хешинг и crdt мне тут заливаете.

Ушел в Револют. Так, ну сейчас посмотрим на ваш хайлоад, как никак 10 миллионов пользователей отмечаем! Умещаемся в один партиционированный постгрес. Пффф! Вот в трейдинге было! А тут...

Иду писать торговые приложения. Микробенчмарки, микрооптимизации, ipc, udp. Маркет дата обновляется с очень разной частотой, десятки форматов, бэктест система тормозит. Кассандра не вывозит тиковые данные... Какой дурак вообще сюда ее притащил! Кликхаус вроде ничего, другим ещё оперативки из интел оптана. У нас биг дата!

Пришёл в Яндекс. Че у вас тут? Веб сервисы? Пффф, халява! Я ТАКОЕ делал, а тут... Что? Латенси? Сколько сколько? 50 МИЛЛИсекунд? Это разве лоу латенси??
Мдааа, олимпиадники... Щас батя покажет, разойдитесь!

Инцидент. В смысле 40к рпс в одну ручку полилось? Откуда? А че делать? А че рпс-лимитер не режет? Какие бакеты? А почему 40% трафика этого дц на один хост летит? А как переделать? А почему автоматически нельзя это все? Аааа. Аа... АААААААА! Почему постгрес-то не отвечает? В смысле квота на диск кончилась? Чего, какой репак, че за блоат? Ваккум же выключили... А почему коннектов-то не хватает? В смысле ООМ из-за слишком большого документа? Не, подожди, у меня на монге же рид консерн был...

Че-то сложно, короче.

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

Прохавал на инцидентах множество контринтуитивных практик. Начал проводить систем дизайн секции.

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

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

Дочитал книгу Five Dysfunctions of a Team

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

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

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

С тех пор всегда читаю предисловия, ни разу не пожалел.

Так и в пяти пороках команды обязательно нужно прочесть предисловие, чтобы узнать следующие вещи:
1. Книга состоит из двух больших частей
2. История в первой части полностью выдумана, персонажи нарочито архетипизированы; это сделано для лучшего усвоения материала, ведь люди любят истории
3. Во второй части автор написал, что хотел сказать в первой

Как я понял, здесь сделана попытка повторить успех "Цели" Голдратта. Ленсиони тоже нанял профессиональных писателей, тоже в рассказ потихоньку доливается теория неким персонажем экспертом.

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

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

Мне больше понравилась вторая часть книги. Она довольно сильно перекликается с Койловским Культурным Кодом (но пророки на 15+ лет старше). При этом Ленсиони объясняет все гораздо понятнее и проще, а ещё даёт конкретные методики для работы с командой. Все это сухо, сжато, компактно, удобно. Впрочем, там вся книга написана гигантским шрифтом с главами по три страницы.

Я "купил" основные идеи книги. А именно:
1. Доверие. Это база. Люди в команде не должны бояться быть уязвимыми друг перед другом. Это позволяет признавать ошибки, быть открытым к критике, а главное, чувствовать себя в праве критиковать других.
2. Конфликт. Основной инструмент принятия решений. Если есть доверие, то необходимо дискутировать по важным решениям. Нужно услышать мнения всех. Это даёт максимально информированную позицию, оптимальное в конкретной точке времени решение.
3. Commitment. Так как каждый член команды был услышан. На каждое предложение и аргумент были даны ответы. Смотри выше конфликт, конструктивный конфликт, где команда ищет оптимальное решение. То в целом, каждому человеку понятно, почему выбрали именно такое решение. Даже если кто-то не согласен с этим решением — disagree and commit. То есть нужно, чтобы люди в команде "купили" это решение, стремились реализовать именно его.
4. Accountability. Если мы закоммитились на что-то, то должны отвечать за достижение этого результата. Но здесь подразумевается не только отвечать перед начальником. Нужно сделать так, чтобы каждый член команды в любой момент мог почелленджить другого, призвать к ответу, так сказать.
5. Фокус на результатах команды. Это вершина пирамиды, которую строит Ленсиони. Команде нужно прийти к тому, чтобы каждый из ее членов ставил цели команды выше своих собственных. Это сложное место, здесь идёт борьба с эго, с индивидуальными результатами в карьере, а часто и в деньгах. Мне кажется, это самый сложный из пороков команды. Однако, если предыдущие ступени выстроены, то коллеги будут следить друг за другом, требовать результатов, на которые коммитились. Это будет помогать.

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

Ещё у меня есть некая аудиозапись. Чей там второй голос это разрыв вообще!

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

Пока профессионала нанимать не хочу, мне интересно самому потыкаться.

Вчера у нас в Сербии был выходной, а сегодня у меня ощущение продуктивного дня!
Несмотря на 11 встреч с одним перерывом на двадцать минут, я смог получить субъективное ощущение, что я что-то сделал. Тимлиды/руководители в чате, фил ми.

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

То есть, всякого полезного я сделал много за сегодня. Но _ощущение_ какого-то движения, какой-то законченности, какой-то полезности — от банального контроля. Это просто, блин, пара сообщений в телеге.

Я несколько удивлён и доволен. Буду теперь чаще контролировать, а то раньше все сам молча доделывал...

На прошлой неделе ходил на IT-standup от Акустики и Яндекса. Впервые в Белграде и все такое. Билеты на мероприятие разлетелись так быстро, что даже анонса мероприятия сделать нигде не успели. Как тогда закончилось билеты для меня осталось загадкой 😁 Меня позвали, как выпускника нашей внутренней школы спикеров, тем более, что выступал ещё один выпускник. Не знаю, смог ли я его поддержать, но я постарался 😊
А говорили, что все побочные активности бесполезны!

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

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

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

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

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

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

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

Хороших специалистов ОЧЕНЬ мало. У меня конверсия финального интервью в оффер дай бог процентов десять. А выше по воронке конверсия ещё хуже (не только лишь все могут написать алгосики, да).

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

Прокси к деньгам может быть оценка на перфоманс ревью. Здесь стараешься делать так, чтобы у ребят оценки были повыше. Но важно помнить, что оценка это не только деньги, но и сигнал для сотрудника о качестве его работы. Завышать, значит дать сигнал, что можно расслабиться. Занижать — что не ценишь его труд, демотивировать.
И конечно же, зачастую люди рассказывают друг другу что и за какие заслуги они получили. Здесь должно получатся максимально объективно, иначе будет чувство несправедливости.

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

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

А ещё можно предложить культуру и ценности. И если на ESG не поведётся практически никто, то вот атмосфера в компании и команде это очень важно.

Можно вспомнить кейс XSolla или собеседования в LaToken. Там, наверное, задачи были интересные и денег платили. Но многие ли хотели там работать? Когда руководство не уважает, оскорбляет и публично унижает сотрудников, имидж у такого места быстро портится.

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

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

Вот из этих команд повытаскивать бы руководителей, да к себе на тёплые местечки рассадить. Бизнес идея.

Запись макрострима 27.11.24

На сайте ЦБ Сербии написано, что основная его задача это контроль цен. Там же написано, что эта задача решается путём таргетирования инфляции.
В Сербии капитал свободно движется через границу в обе стороны.
EUR RSD держится в достаточно узком коридоре.

Внимание вопрос: где подвох?

Обратное делегирование

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

Большинство тимлидов в разработке сталкиваются с этим в следующем виде. Дают сложную задачку разработчику. Он какое-то время её ковыряет, а потом приходит и просит "немного помочь". По факту выясняется, что в задаче не сделано вообще ничего, а тимлид полностью пошагово показывает сотруднику, как надо. Это даже нормально, когда происходит не часто. Например, тимлид не угадал с задачкой (либо недооценил сложность задачи, либо переоценил человека). Но некоторые разработчики живут в таком режиме годами. Они и пользы-то не приносят, просто сидят и смотрят, как другие работают.
Мы в моих командах во избежание таких ситуаций просим ребят приходить с вариантами решений, а не просто с вопросами. Желательно даже варианты отранжировать.

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

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

Решил несколько задачек из Advent of Code.
Но знакомого чувства кайфа пока так и не возникло. Возможно, потому что я решал на C++ golang. Оказалось совершенно отвратительный язык для таких задач. Даже плюсы кайфовее и лаконичнее, даже с учетом того, что в плюсах вектор не умеет себя печатать по умолчанию.
На самом деле я решил пока что две задачки на плюсах, одну на питоне и одну на golang. Задача, которую я решал на питоне исполнялась 58 секунд, в остальном этот язык приятнее остальных.

Короче, программировать у меня всё ещё получается. Писать красивый код уже не особо. Удовольствие тоже сомнительное. Может быть, надо литкод взять, чтобы был вот этот КАТАРСИС от решенной задачи. А может надо на джаве решить задачку, чтобы было "ещё могу" — посмотрим, я попробую. Но пока диагноз у меня неутешительный: менеджер головного мозга.

BTW я создал приватную борду, можем посоревноваться внутри нашего уютного сообщества (или можете просто самоутвердиться за счет меня), джойн ми:
4688761-9a528736

Как же раздражает псевдоинтеллектуальный мусор типа Маслоу не рисовал пирамиду, выученной беспомощности не существует и окно Овертона не работает.
Прикиньте, а Сократ вопросы никакие не задавал своим собеседникам! А метод Сократа это задавание вопросов.

Делаешь максимально компрометационный заголовок, срываешь покровы! ШАТАЕШЬ УСТОИ!

Конечно же, всем очевидно, что если Маслоу не рисовал пирамиду, а ее нарисовали в последующих работах, развивающих тему мотивации, то никакой пирамиды не существует!
Естественно, что как только ты выяснил причины выученной беспомощности и подобрал более корректный термин, само явление перестало существовать! А то, что Овертон делал свою работу, как наблюдение и подстройку, а не как инструмент влияния, то это бедное окно нельзя использовать в целях влияния! Эй, ты! Положи на место, виагру придумали не для этого!

Че мне не нравится? А у меня классический рецидив баттхерта. Значит, кто-то умный (он же, ВИДИМО, читал оригинал работы Маслоу, Овертона, Платона в конце концов — интеллектуал!) в интернете кидает тезис, что нечто Х не работает/не существует. Для кого он это кидает? Для нас с вами, для серого бездумного хомячья. Два часа видос Тимоновой идёт! Два, Карл! Столько смотреть никто не будет. Просто заголовок запомнят и пойдут дальше всем рассказывать, что УМНЫЕ ЛЮДИ СКАЗАЛИ ТАК. Хотя они либо этого не говорили, либо не умные.
Зачем всем пересказывать умных людей? Чтобы самим себя показать умными: смотри, я вон чо знаю, название ролика на ютубе прочитал! Я интеллектуал!

И вот тебе уже рассказывают, что твои рассуждения фигня, потому что Маслоу пирамиду не рисовал. А обсуждать окно Овертона это моветон и вообще не прилично, все образованные люди знают, что его нет!
Гэповский видос, кстати, стоит досмотреть до конца. У Тимоновой тоже надо либо всё, либо ничего смотреть, сорян.

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

Почти так же омерзительно, как то, что у меня растяжение связки в коленке.

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

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

Хочу прокомментировать, что разные форматы ретроспектив таки нужны. Но они призваны решать разные задачи, а не развлекать. Например, this guy / that guy мы используем, когда есть какая-то невысказанность и напряжение внутри команды (если команда еще не сформирована, люди часто не высказывают друг другу претензии лично). Это помогает проговорить и обсудить какие-то напрягающие моменты, облегчает старт дискуссии.

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

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

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

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

Когда пошли какие-то жалобы на смежников или в компании прошло масштабное изменение, это повод разузнать и пошерить мнения внутри команды. Для команд, где уже построено доверия, лучше подошел бы нытинг (мы так называем встречу, где можно просто поныть друг другу в жилетку, это не ретро в классическом смысле, хотя рукль может забрать себе с него ai), но для менее сформрованных коллективов формат дискуссии, брейншторма, ретро может подойти лучше. И снова здесь есть какие-то события и ретроспектива по ним: Произошло Х, мне не понравилось, что мы можем сделать, чтобы такого больше не было или чтобы я получал меньше дискомфорта? Произошло Y, мне очень понравилось, как сделать так, чтобы оно повторялось?