👀 невербалики пост

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

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

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

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

Модерация сообществ

https://vas3k.blog/notes/moderation/
vas3k сделал отличный лонгрид про подводные камни модерации сообществ и влияния оной модерации на жизнь онлайн-коммьюнити. Многое говорит о проблемах формулировки командных правил вообще.
Особенно рекомендовано читать людям от мира управления знаниями, мечтающим сделать платформу, и чтобы оно дальше как-то само происходило и люди сами делились знаниями.

Почему не пишется лог?

Подумайте над этим пару минут, какие могут быть варианты. Ну или напишите в комментарии — порассуждаем вместе!
А потом посмотрите увлекательный ответ под спойлером ниже ⬇️

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

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

Ну… Как работало… )

Первые полгода-год меня поносили всеми немыслимыми словами и менеджеры, и разработчики. Добавил работы на пустом месте.
А потом люди начали понимать плюсы, особенно когда проект зарелизили и полезли баги в production. Когда благодаря зафиксированным знаниям разработчикам удавалось быстро влезать в незнакомые сервисы, а менеджеры сами могли диагностировать проблемы с помощью Postman и хорошего описания API.


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

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

Счастливой отладки :)

Давайте будем документировать архитектурные решения!

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

Я часто видел, как в результате команды приходили к идее сделать какой-то вид ADR (Architecture Decision Record) — фиксировать каждое архитектурное решение в виде этакой блогозаметки.
На мой взгляд это хорошее решение и это ужасное решение.

Хорошее — потому что это лучше чем ничего, и даже внедрение подобного подхода требует мощного волевого усилия. Вот, кстати хорошая статья с самым простым шаблоном: https://infraeng.dev/decision-log/

Плохое — потому что начиная записей с 30 разобраться в этом становится невозможно. Мне кажется, что тут лучше подход wiki: выделить абстрактные сущности (например, такие: https://youtu.be/NGiN3df_YGc?t=571) и с каждым решением — обновлять описания каждой из сущностей, затрагиваемых изменением (методы API, компоненты, фунциональные/не функциональные требования, бизнес-возможности пользователей и т.п.) и аккуратно пролинковывать зависимости.
Это сложнее, требует сурового онбординга для новичков, но гораздо прозрачнее в использовании. Причём изучение можно начать с того места, которое тебя волнует здесь и сейчас — меняя сущность ты от неё можешь размотать все взаимосвязи.

😌 Управление ожиданиями, кейс №1

У тебя есть две задачи А (30 часов) от Васи и Б (10 часов) от Екатерины на ближайший недельный спринт. К тебе приходит менеджер Виссарион и просит сделать задачу Д (20 часов). При этом ты точно знаешь, что Д — супер-срочная. Что будешь делать с задачами?

Условно считаем, что у нас реально есть 40 часов в неделю, встречи-оффтопики для простоты как бы включены в оценку времени.
Вы сами решаете кем быть — формалистом, карьеристом или полезным человеком, насколько зрелая ваша компания и т.п. Ответ формулируем с позиции исполнителя, а не руководителя команды.

Мой ответ с объяснением позиции — через несколько дней.

Счастье — есть, скоро в obsidian

Obsidian 1.4 будет позволять оперировать frontmatter-полями через удобный формо-подобный интерфейс.

Frontmatter — это такая шапка в виде yaml-а, которую можно (согласно спецификации) вставлять в любой markdown файл наверху. Долгое время obsidian позволял работать с этой шапкой сугубо как с текстом, что начисто отсекало неопытных пользователей не умеющих в эти ваши ямлы, и в целом было мерзко.
Особенно мерзко было работать с выбором из списка, датами и тому подобным.
Ситуация меняется и в версии 1.4 завозят удобные интерфейсы из коробки.

Вот видос: https://www.youtube.com/watch?v=RrxqkIhh9L8&t=108s

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

Игнорировать задачу Д, мол, спринт утверждён — путь отдельных самураев, внедривших бескомпромиссный скрам. Встречал такие команды, но ИМХО, так далеко не уедешь. У команды должно быть capacity на срочные задачи: либо через возможность менять скоуп задач, либо через "дежурного по срочным задачам".

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

Кто должен разруливать ситуацию с изменившимися договорённостями — исполнитель или менеджер?
А фиг его знает 🙂 Я видел самые разные конфигурации: "мой непосредственный руководитель", "рандомный менеджер проекта", "исполнитель сам" и даже "жира автоматически".
Мне больше нравится вариант, где исполнитель сам занимается оповещением. Это защищает нас от менеджеров-врунишек-"я-согласовал-давай-делай" (а на самом деле — ничерта не согласовал), и в целом способствует карьерному росту самого исполнителя. Это хороший выбор для адекватных команд, где всё нормально с доверием исполнителям.

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

Трудно решить инцидент тогда, когда инцидента нет

Один из топовых способов въебать кучу времени в расследование инцидента, поднять кучу людей, несколько раз прийти в тупик и бессистемно потыкаться в поисках проблем — забыть сформулировать в чём проблема.

Когда я говорю “в чём проблема”, я не имею ввиду такие вещи, как:
- рост потребления памяти
- троттлинг цпу
- потери пакетов
- высокий уровнь ошибок
Это — симптомы, наблюдения, факты. Они помогают нам подтвердить, опровергнуть или придумать гипотезы о происходящем. Но они не являются проблемой сами по себе.

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

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

Условный высокий уровень 502-ых может продолжаться столько угодно, если он не мешает пользователя делать заказы (потому что есть retry или fallback-механизм).

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

😌 Управление ожиданиями, кейс №2

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

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

Мой ответ с объяснением позиции — через несколько дней.

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

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

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


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

Капать на мозги тем, кто делает нужные вам задачи — путь дятла. В некоторых компаниях только он и работает, но это как минимум не гуманно.

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

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

Инструментов для расследования сложных инцидентов пост

Значительная часть моей работы сейчас — расследование сложных инцидентов, на стыке многих команд. Инструмент, который я использую чаще всего — это схемы. Они позволяют быстро ориентироваться, наглядно объяснять и понимать друг друга.
Если вы сталкиваетесь с подобными задачами, думаю, вам помогут следующие схемы:

1. Карта зон ответственности и контактов
- Кто из вашей команды за какую часть отвечает, какие у них контакты
- Кто из соседних команд, от которых вы зависите, за что отвечает, какие у них контакты и пути эскалации

2. Карту того, как идут запросы на уровне инфраструктуры — верхнеуровнево, без фанатизма, на уровне компонентов. Со ссылками на инструменты диагностики каждого из компонентов.

3. Sequence диаграммы, на которых фиксируем ход идущего расследования со всеми ключевыми показателями, скриншотами и выводами

Для удобства понимания — визуализировал для вас примеры:
https://miro.com/app/board/o9J_l5D3LgE=/?share_link_id=594302631362

Нежно люблю инженерный подход. Сегодня - не про айтишечку, но про него.

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

https://youtube.com/watch?v=BYVZh5kqaFg

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

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

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

Поверхностности пост

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

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

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

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

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

Начинающий использует много слов не по делу. Эксперт умеет сказать ровно то, что нужно, тому кому нужно.

Интересно смотреть, как компьютер учится решать те или иные задачи.
Отличный видос для пятничного вечера, как обучали AI проходить старый добрый Pokemon Red:

https://youtube.com/watch?v=DcYLT37ImBY

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