Пятничная рубрика "Пыльный чулан"

На этот раз серия постов про то, как я учился на переводчика. Я хотел пошутить, что мне это пригодилось только, чтобы в интернете в спорах орать, что Я ЛИНГВИСТ. Но на самом деле чуть более глубокое знание лингвистики, чем в среднем по популяции, позволяет легче и интереснее изучать иностранные языки. Я стараюсь подучить (на уровне "как идти больница? еда кушать хотеть") местный язык перед преездом практически в каждую страну, в которой бываю, поэтому неоднократно радовался пройденному обучению.
А та же редактура помогла мне при работе над магистерским. Потому что я попросил его вычитать профессионального редактора. Потом значочки вот эти все смотрел, правил.

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

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

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

Вообще меня спрашивали про тимлидов, но опубликую я истории про себя.

Когда я был тимлидом, часто вечером делал какие-то изменения и тегал дежурного в чатике, чисто FYI. А у меня еще таймзона Мск-2, напомню.
И вот на одном из ретро смотрю: карточка в колонке "перестать делать" — "тегать дежурных вечером в чате". Я сразу понял, что это про меня. Начали разматывать. Оказалось, что один человек думал, что раз я тегаю дежурного в чате, то этот дежурный должен пойти и че-то сделать (посмотреть приборы там, как минимум). А я думал, что я тегаю дежурного, чтобы если к нему придут с вопросами, он знал, что надо слать ко мне. И вот оказалось, что мы как два дурачка смотрели все время в одни и те же графики.
Тут ситуация разрешилась легко и даже смешной анекдот остался.

Но был факап и пожестче, пожалуй, один из самых жестких so far. Опять же, в бытность тимлидом совершено. Вышел ко мне сотрудник. Три месяца испыталки прошли. Не звезда, конечно, ну вроде норм, вкатывается, наверное — _подумал_ я. И ничего ему не сказал о своих ожиданиях.
Прошел еще месяц. А темп тот же. Я пришел с "развивающей" обратной связью. Обсудили что и как. Он чуть прибавил. А еще через месяц наступило полугодовое ревью. На котором я не смог защитить ему хорошую оценку.
После этого разговор с HR, PIP, все дела. Объяснял, что косяк тут мой — недокоммуницировал, не рассказал об ожиданиях, не дал обратную связь СВОЕВРЕМЕННО.
Примерно в этот момент я решил, что надо команду поделить и выделить руководителей на группы поменьше. А человек с PIP'ом справился и получил на следующем ревью хорошую оценку. Вроде даже простил меня.

Я участвую в роли эксперта на курсах для начинющих руководителей у нас в компании. И в этот вторник была практика по мотивации. Принес вам с неё прикольный кейс.

Сотрудник уперся в потолок по зп. Род деятельности менять не хочет. Фрилансить не хочет. Обучаться и уходить в управление не хочет. А денег больше хочет.

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

В комментариях задавали дельные вопросы и писали интересные варианты, рекомендую почитать!
А мы автора кейса могли немножко поспрашивать деталей. Смысл там такой, что человек доп активностей или других активностей не хочет, а денег хочет.
Наша рекомендация такая:
Можем посочувствовать, поддержать, разделить горе несправедливости этой жизни. Но вообще говоря, это не проблема руководителя. Как правильно заметили в комментариях, я тоже хочу вертолет и виллу в Ницце. Но одного желания мало. А мой руководитель не Хоттабыч.
*Касательно тейков про удержать/пойдет писать резюме, раз вы такой жадный/инфляция уменьшает размер сырка — по условию кейса человек уже уперся в потолок, значит, сильно больше он на рынке не получит.

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

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

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

🤝 КОМАНДА vs РАБОЧАЯ ГРУППА
У обоих есть общая цель. Но в команде каждый действительно хочет этой цели достичь. В рабочей группе каждый просто делает свою работу, что должно продвигать группу в сторону цели, но у сотрудников отсутствует персональное стремление к этой общей цели.


⭐️ МОДЕЛЬ ТАКМАНА И ЕЁ ОГРАНИЧЕНИЯ
Модель Такмана описывает динамику развития группы через пять стадий.
В организационной психологии нет единого мнения о развитии группы.

Стадийный подход рассматривает процесс командообразования как последовательность этапов.
Циклический подход предполагает, что развитие группы происходит в виде циклов стабильности и перемен.
Модель прерывистого равновесия Конника и Герчика описывает рабочие группы с дедлайном.

Все модели групповой динамики имеют свои ограничения.
• Модель Такмана подходит для психотерапевтических групп, но не для рабочих.
• Модель прерывистого равновесия Конника и Герчика применима к рабочим группам с дедлайном.

⭐️ ПРОЦЕСС КОМАНДООБРАЗОВАНИЯ В РЕАЛЬНОСТИ
Рабочая группа проходит через этапы формирования, напряжения, кризиса и системных изменений.
Процесс может протекать с разной скоростью и степенью выраженности.
Группа может возвращаться на предыдущие стадии развития.

Процесс командообразования может протекать по-разному в зависимости от обстоятельств.
Группа может избежать стадии шторма.
Влияние на процесс командообразования зависит от этапа развития группы.

🌚 ФОРМИРОВАНИЕ ГРУППЫ (ФОРМИНГ)

• Люди знакомятся, определяют цели и стратегию, распределяют роли.
• На первом этапе люди дружелюбны, послушны, ориентированы на руководителя.
• Однако они безынициативны, не доверяют друг другу и работают разобщенно.

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

Поведение на этапе формирования группы

• Люди пытаются избежать нагрузки, не входящей в их зону ответственности.
• Руководитель активно координирует работу, но это требует много усилий.
• Группа должна собраться, познакомиться и приступить к работе.

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

⭐️ РЕКОМЕНДАЦИИ ФОРМИНГ

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

Регламентация работ

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

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

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

Пятничная рубрика "Пыльный чулан"

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

Но это не повод оставить вас без поста с полезняхами! Вспоминаем всё полезное для подготовки к систем дизайну (архитектуре).

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

- Применение теории для построения реальных систем. Мне нравится курс Олега Бунина в на Физтехе. Там разобрано много стандартных паттернов проектирования высоконагруженных систем. Особенно классно, что в записи есть и разборы кейсов.

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

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

😡 СТАДИЯ КРИЗИСА (ШТОРМИНГ)

Кризис возникает из-за производственных сложностей, тяжелых условий, разного видения целей и несправедливости. Несправедливость и борьба за статус могут привести к конфликтам и разделению группы. Отсутствие возможности сменить контекст и кризис мотивации также способствуют кризису.

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

• Здоровый кризис помогает людям учиться взаимодействовать. Отличается наличием модерации и положительной динамики.
• Нездоровый кризис деструктивен и не способствует командообразованию.

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

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

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

⭐️ ПРОБЛЕМЫ КОМАНДООБРАЗОВАНИЯ

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

⭐️ ТИПОВЫЕ СЦЕНАРИИ КОМАНДООБРАЗОВАНИЯ (ШТОРМИНГА)

Координаты:
• Работа может идти в диапазоне от очень плохо до отлично.
• Отношения могут быть от полного неприятия до полной любви.

Сценарии:
1. Дела идут исключительно хорошо, условия кофмортные + между людьми нет напряжения, есть доверие
2. Дела идут с переменным успехом + подготовленные люди
3. Дела хорошо + обычные люди
4. Переменный успех + обычные люди

Причины кризиса в монтажной бригаде

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

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

⭐️ РЕКОМЕНДАЦИИ ШТОРМИНГ

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

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

Практика стимулирования групповой динамики

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

Высказывания и рефлексия

• Участники должны высказываться прямо и без обиняков.
• Важно не бояться эмоциональных оценок.
• Практика помогает сбрасывать напряжение и проговаривать негативные эмоции.

Работа с конфликтами

• Конфликты должны развиваться, а не оставаться в подвешенном состоянии.
• Практика ускоряет процесс и предотвращает накопление напряжения.
• Важно учитывать чувствительность людей и контекст.

Индивидуальный подход

• Лидер должен подбирать правильные слова и выражения.
• Работать с динамикой нужно на индивидуальном уровне.
• Сначала обсуждать вопросы с непосредственными участниками, а затем выносить на группу.

Работа с агрессией

• Принять нормальность агрессии и токсичности.
• Не отвечать агрессией на агрессию, а переводить в плоскость конкретики.
• Критиковать действия, а не личность.

👌 НОРМАЛИЗАЦИЯ ОТНОШЕНИЙ (НОРМИНГ)

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

Риски и задачи этапа нормализации

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

⭐️ РЕКОМЕНДАЦИИ НОРМИНГ

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

Мотивация и возвращение участников

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

Роль руководителя

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

💪 СТАДИЯ КОМАНДНОЙ РАБОТЫ (ПЕРФОРМИНГ)

• Восстановление производительности и улучшение настроения участников.
• Участники осознают ценность друг друга и становятся настоящей командой.

⭐️ РЕКОМЕНДАЦИИ ПЕРФОРМИНГ

Получать удовольствие от работы, обращать внимание на успехи и благодарить друг друга.

🔚 ФИНАЛЬНАЯ СТАДИЯ (РАСПАД)

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

Изменения в команде

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

Как пройти систем дизайн?

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

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

Мы даём задачку, сформулированную очень размыто. Но там обязательно будет какой-то челлендж от размера: большая нагрузка, много данных, много интерферирующих сценариев и т.п.
Здесь ожидается, что кандидат выяснит, что вообще надо сделать. Поспрашивает, сколько пользователей, продемонстрирует back of the envelope computation skills. Sori za moj ingliš. Это показывает наличие какой-то насмотренности на хай лоад, кроме того, некоторые кандидаты здесь начинают плыть между битами, байтами, мегбитами и мегабайтами, сколько там байтов в инте и флоте... Плохой знак.

Потом моя персональная рекомендация: разработайте API. Его можно потом доделать, но продумывание каких-то основ функционирования системы происходит именно в этот момент. Обычно всем пофиг на rest vs grpc vs graphql, я бы не тратил на это время. Но желательно что-то выбрать, озвучить и оформить API в _едином_ озвученном стиле.
И не забывать про response!

Дальше нужно выдать минимально рабочую схему. Вообще рассказать, как это сделать в гараже на коленке, но чтобы работало на 1 rps.
Это супер важный шаг, потому что если есть рабочее решение, это уже много баллов в копилку результата интервью. Только с такой схемой на руках может начаться _настоящая_проверка_ на сильного инженера.

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

Дальше мы ждём, что кандидат подумает о каких-то крайних случаях. На самом деле есть какие-то стандартные кейсы типа супер популярный ивент, человек и т.п. или супер массовый подписчик. Т.е. объект, который все хотят прочитать и объект, который хочет прочитать всех. Чем больше таких штук кандидат найдет и починит, тем лучше впечатление останется.

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

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

P.S.:
есть отдельный трек таких интервью для технических менеджеров и продактов, про него могу отдельно прокомментировать, если вам интересно будет

🧠 РЕТРОСПЕКТИВА

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

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

⭐️ АЛЬТЕРНАТИВА КОМАНДООБРАЗОВАНИЮ - РЕГЛАМЕНТАЦИЯ

• Регламентация может быть альтернативой командному подходу.
• Регламентация описывает все нюансы работы группы.
• Регламентация может быть необходима в опасных или нестабильных условиях.

⭐️ ПРИМЕРЫ РЕГЛАМЕНТАЦИИ

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

⭐️ ТИМБИЛДИНГ И КОМАНДООБРАЗОВАНИЕ

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

🚨🚨🚨!БУДЕТ СТРИМ!🚨🚨🚨

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

В комментариях к этому посту пишите вопросы!

Как перестать просирать задачи

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

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

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

Потом я прочитал книжку Максима Дорофеева "Джедайские техники". Там очень крутой нарратив, что сложные (компликованные мне самому больно) штуки нам делать тяжело. И подход Максим предлагает очень простой. Но я даже его не смог реализовать. Нужно ЕЩЁ ПРОЩЕ!

Посмотрев на свою рутину и на наивные попытки людей всех рангов и степеней систематизировать и организовать свой телеграм, я обнаружил, что этот мессенджер — главная точка входа. У меня тогда ещё был ноушен с шаренными 1-1 бордами. Начальник мне в телегу написал тему с комментом, что было бы удобно написать "/notion тема на 1-1", а не лезть искать ссылку и заводить задачу. У меня заняло где-то пару часов наклепать бота на make.com, который из текстового сообщения в телеге делал карточку в ноушене и клал на нужную доску. Теперь начальник мог прислать сообщение боту, а не мне — не дергать меня без надобности, но и удобно записать мысль.
А потом ноушен того этого. И скатертью дорожка, если честно.

Поставил я себе todoist, подсмотрев у нескольких коллег. Но в нём все флоу какие-то не для меня. То сложные, то там надо задачам срок проставлять заранее — фу, короче. Нудятина.

Зато ботика переписать на тудуист не составило никакого труда! Поэтому, я начал изучать инструмент и строить что-то более или мене удобное. Кажется, получилось.

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

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

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

Разное
Есть ещё куча заготовок для тудуиста в интернете. Я себе взял Life Admin, чтобы не забывать покупать кофейные зерна и другие жизненно необходимые вещи, но жена справляется без меня.
Кстати, можно дать доступ жене, чтобы она тоже херачила тебе задачи в бэклог. Тоже удобно.

А как этим всем пользоваться-то?
А всё просто.

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

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

- Идешь в фильтр Go Ahead, берешь там первую же задачу из списка must. Делаешь. Потом следующую.

- Когда задачи в этой колонке закончились, берешь задачку из остальных сегодняшних. Если че-то не успел за сегодня — пофиг. Сделаешь завтра. Вообще волноваться вредно. Не надо напрягаться. Надо радоваться.

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

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

Я со своей кучей подпроектов купил себе про подписку. Но в целом схема очень простая и легко повторяется в бесплатной версии. Если хотите помощи с no code ботиком, проще всего попросить ChatGPT, но можно и мне написать, я не кусаюсь.

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

Я хотел сделать лайтовый пятничный "Пыльный чулан" про забавную физику, но посмотрел на пост про распределенные системы и решил дать вам ПОБОЛЬШЕ ХАРДКОРА.
Сегодня достаём разговорчики про перфоманс в основном внутри одной машины.

Не так уж и давно я решал SRE Week от Яндекса. Там были задачки на перфоманс.

- оптимизированный под разного размера массивы бинпоиск. Чуть подробнее о бинпоисках я писал когда-то давно, пригодилось

- потом была spsc queue на C++, rate limiter на golang и задача, которую я не решил из-за лени.
Для лучшего понимания memory ordering'ов в очереди стоит почитать пост с картинкой Serializable vs Linearizable и приправить постом про барьеры памяти.
Про отношения между latency и throughput (пригодится с рейт лимитером) есть (имхо) красивая аналогия в соответствующем посте.

- последний блок задач был на исследование проблем с производительностью с помощью bpftrace — там типичная история из жизни performance инженера, когда ты мерил, мерил, но мерил не то 🤡
Постов про bpftrace у меня нет, поэтому я просто порекомендую постом книгу Дениса Бахвалова про перфоманс и микрооптимизации с массированным использованием perf'а. Заодно разберетесь со всякими там фронтендами и бэкендами процессора. А для подготовки к этой книге, стоит прочитать (если еще не) WEPSKAM (хотя лучше pdf найдите).

Вне категорий ещё неймдроппинг:
- Brendon Gregg, System Performance, которую я украл у Серёги
- Peter Sewell, статьи из раздела Relaxed-memory concurrency, кладезь золота, которую мне открыл Шипилёв

Есть ещё, но мне кажется, что уже этого вполне достаточно, чтобы забить себе башку на месяца вперёд))

Event driven management

Как ни странно, это продолжение темы "как всё успевать". Я этого не планировал, но по сути вкусно так получается.

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

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

Зачем тут, спрашивается руководитель? Развивать сотрудников и решать конфликты? Ну так это коуч какой-то. Оценивать перфоманс и назначать зарплаты? Можно заменить кем-то из HR. Следить за тем, что процессы соблюдаются? Надзиратель.

Мы знаем, что руководитель здесь нужен для этого всего тоже, но в основном для того, чтобы работа в итоге была сделана. Это вообще как бы основная функция начальства — доводить до результата.

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

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

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

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