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

🤝 КОМАНДА 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. Следить за тем, что процессы соблюдаются? Надзиратель.

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

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

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

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

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

Расскажу, что есть у меня, а что я бы хотел, чтобы было ещё.

1. Я стараюсь коммуницировать, что при затыках, проволочках и потере темпа _нужно_ идти и эскалировать в меня. Это вообще первый и главный сигнал к включению
2. Колонка "запланировано" всегда должна содержать не менее X задач (X, очевидно, разнится). Здесь мы хотим не менее пяти задач, а если их становится меньше трёх, то это повод прямо сейчас разобраться, что ещё нужно докинуть. Иначе следующий освободившийся сотрудник не будет знать, за что взяться и случится бесполезный простой в лучшем случае. В худшем сотрудник будет делать задачу, которая важна _по_его_мнению_. С другой стороны, если в колонке слишком много задач, то это тоже какой-то нездоровый признак — явно что-то сломалось с приоритетами и планированием (если ты планируешься в среднем раз в неделю на команду из пяти человек, а задач в запланированном больше 20-ти штук, то скорее всего вы их не сделаете)
3. Колонка "готово к работе" тоже должна всегда содержать некоторый буфер задач. Если задач в ней становится меньше Y, нужно озаботиться тем, чтобы кто-то уже взялся за запланированное и начал готовить задачу к взятию в работу (у нас это значит выполнить DoR: по чек-листу проверить, что в задаче есть вся нужная инфа, DoD, проведена декомпозиция, учтены и обработаны все внешние зависимости и т.д.). В противном случае мы рискуем оказаться в ситуации, когда код никто не пишет, а все заняты высокими материями типа общения со смежниками или декомпозиции задач. Я уже молчу о том, что не каждый сотрудник одинаково хорошо может с такими задачами справляться, тут нужно всё-таки давать что-то посильное (пусть и с челленджем).
4. Диаграммы DORA. Беглого взгляда на них обычно достаточно, чтобы увидеть какие-то аномалии: слишком быстро или слишком медленно стали делать задачи (на новогодние отлично видно, как релизы откладываются, например). Здесь у нас в трекере есть вьюшка, отображающая цикл тайм по статусам. По ней можно попробовать понять, в какой именно части процесса произошла проблема (релизы, ревью ПРов, декомпозиция или сама разработка и т.п.) — тут либо будет ожидаемо, либо надо копать дальше, но уже ясно направление.
5. Диаграмма потока задач. Здесь просто следим за тем, что решается задач не меньше, чем заводится новых — рост бэклога это не хорошо, это "запасы".
6. Длина очереди обращений в поддержку. Ну тут всё ясно, кажется. Если очередь выросла, надо бы разобраться, что к этому привело и разгрести хвост.
7. Доска с задачами в разбивке по людям. Здесь следим за тем, что у каждого есть задача и в работе только одна в один момент времени.

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

Для операционного менеджмента ещё не хватает одной диаграммы:

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

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

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

После долгих раздумий и метаний в нерешительности я решил покинуть найм и основать свою компанию. Детали скоро узнаете, но в общих словах это стартап, который позволяет верифицировать все изменения в исходниках и весах больших языковых моделей. Все изменения будут храниться в публичной блокчейн цепи. Чтобы сгенерировать очередной блок и применить изменения к модели, необходимо будет специальным образом намайнить ревью от AI Alignment комитета и публичных ревьюеров.
Для частных компаний есть возможность настроить требования участия в майнинге независимых аудиторов.
Это поможет избежать ситуаций, когда в модели нарочно вносятся искажения, цензура, а также мы получаем встроенную защиту от скайнета, который не сможет сам менять свой код без ревью людей.
За подробностями, бизнес и фин моделями, а так же если вы хотите стать инвестором — пишите в бота канала.

Это первоапрельская шутка была, если что ^^^^^

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

Завтра будет плановый пыльный чулан с публицистикой, ничего сложного! Отдыхаем, друзья!

Отправляю без нотификаций ❤️

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

В этот раз пост ленивца, извините, на работе прям завал.
Принёс вам рассказ про то, как я чуть не умер. Вообще в детстве всякое бывало, мальчишки же, но здесь, во-первых, взрослый человек, во-вторых ДРАМА, в-третьих, шанс один на миллион (так прям в инструкции к лекарствам написано).

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

Так что же должен делать руководитель?

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

Я уже пару раз писал, что по моему мнению должен делать руководитель. Но мысли со временем становятся понятнее и четче. Поэтому ещё разок!

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

Например, проблема с процессами. Найми, попроси взаймы, откопай из под земли, привлеки опытного процессного/проектного менеджера. Если не можешь найти — сделай сам.
Если проект не сходится — найди причину и почини. Не хватает людей? Найди! Нет вакансии? Попроси у соседа. Сосед жадничает? Сходи к общему руководителю. И там не получается? Отдай часть обязанностей кому-то. Всё равно не помогло? Ну пора садиться за клавиатуру, дружище. Или освоить какие-то методы повышения продуктивности сотрудников (процессные, инструментальные, мотивационные). Я вот ознакомился с курсором и подобными нейро решениями — это вау!

Или вот у меня ребята программируют на go и c++, а я прям плохо знаю эти языки. Или, например, ты фронтендер, а у тебя QA в команде. И хотят мои/твои ребята развития. Надо бы что-то посоветовать,, ИПР там составить. А как? Найти опытных гошников и спросить их! Например, я сходил в облако, где много пишут на go и попросил их роадмап для развития — они мне всё дали, рассказали.

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

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

Потом можно на конференцию такое сносить рассказать. Если это кому-то будет интересно, конечно 😁 Короче, снова. Надо делать так, чтобы всё работало. Это включает создание условий, устранение препятствий и постоянный мониторинг.