Про демократуру.

Около 5-6 лет назад, когда я решил, что хочу двигаться в сторону CTO, я начал искать литературу, способную приблизить меня к этой цели. Не помню точно, как это произошло, но я нашёл подборку книг - Список книг для тимлидов и CTO. Данный список остается актуальным и по сей день, и я считаю, что многие из упомянутых в нём книг обязательны к прочтению для любого руководителя.

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

Сейчас я читаю (на самом деле слушаю) одну из его следующих книг — Управление изменениями без потрясений и конфликтов. Книга частично повторяет то, что было в "Идеальном руководителе", да и в целом в книгах Адизеса очень много повторений и воды, но это не суть. В данной книге меня зацепил термин "демократура". По Адизесу, демократура — стиль управления, в котором сочетается демократия в принятии решений и диктатура в их осуществлении.

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

О техрадаре

Впервые я столкнулся с термином «техрадар», когда в 2019 году проходил интервью в Lamoda на тимлида. Я хорошо помню тот момент, так как техрадар в Lamoda был распечатан в виде баннера и висел то ли на стене в одной из переговорок, то ли стоял на флипчарте где-то в офисе. Правда, в тот момент я не совсем понял, какую роль он играет и какую ценность несет для компании.

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

К чему я это? У нас в ЗЯ теперь тоже есть свой техрадар!

Про CAPI.

Закончил слушать эту книгу и хочу поделиться одной мыслью. В ней говорится о CAPI. По методологии Адизеса, CAPI (coalesced authority, power and influence) – это объединение полномочий, власти и влияния.

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

Полномочия. Эта функция принадлежит тем, кто имеет право принимать решения и может сказать изменению "да" или "нет". Например, как тимлид, вы принимаете решение о том, как реализовать ту или иную фичу с точки зрения архитектуры, сроков и распределения ресурсов. Вы имеете полномочия сказать: "Да, фича будет сделана так", или "Нет, фича будет сделана не так".

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

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

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

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

Почему стоит чаще катить изменения в PROD.

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

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

Что это значит на практике? Не стоит пытаться оформить фичу одним гигантским MR на 10k строк и выкатить всё разом, так вы упрётесь в кучу блокеров:
- не настроен CI/CD для нового сервиса,
- нужен отдельный инстанс БД, а задачи ещё нет,
- не согласована сетевая связность с ИБ,
- внезапно нет нужного железа в проде,
- зависимость от релизов других команд,
- и так далее.

Надо наоборот: пропустить в прод первый маленький ручей — минимальный, но самостоятельный MR, который открывает путь. Затем наращивайте поток — серией небольших, частых MR’ов. Так вы:
- выявляете инфраструктурные и процессные проблемы заранее,
- снижаете риски и стоимость отката,
- ускоряете обратную связь от PROD-среды,
- упрощаете код-ревью и стабилизацию.

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

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

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

Стань индусом.

Когда-то на меня сильно произвела впечатление книга «45 татуировок менеджера», и вот я наконец-то добрался до в каком-то виде продолжения — «45 татуировок личности».

Я не буду тут приводить список любимых татуировок или составлять какой-то ТОП, пост не об этом. Пост конкретно об одной татуировке, которая называется «Стань индусом». Короткий пересказ, о чем она, вы можете найти тут.

Когда я слушал эту часть главы, я вспомнил коллегу из Островка и его подход о том, как он НЕ отвечает грубостью на грубость. Со его слов, он делал так.

Когда его кто-то или что-то разозлило, он писал куда-то к себе в заметки ответ на данное событие/сообщение его автору, но не отправлял, а давал «отлежаться» час-два или день — в зависимости от потребности в ответе. Спустя это время он возвращался, перечитывал, что он написал, и либо удивлялся тому, как плохо, грубо (неполиткорректно) он написал, и переделывал, либо отправлял, тк все было ок.

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

Вчера посетил конференцию avito.tech.conf for leads & managers.

Мысли в формате тезисов на основе прослушанных докладов и нетворкинга со случайными участниками конфы.
- Все пытаются как-то где-то внедрять AI для автоматизации и ускорения разработки, не у всех получается, не все довольны результатами, но все так или иначе пытаются что-то придумывать и двигаются в этом направлении.
- Многие, с кем я общался, соглашаются с тем, что средний уровень разработчика падает. Моя гипотеза тут — это то, что в IT за последние 10 лет пришло много новых кадров не после профильных вузов, а после курсов. Где — вжух — и через полгода ты уже джун, но базовой базы страданий через пот и кровь какого-либо высшего учебного заведения нет. Плохо это или хорошо — каждый решает для себя сам.
- Тренд работать на двух и более работах, к моему глубокому сожалению, растет. Откуда и почему — лично для меня загадка, но такая проблема есть, и работодатель со стороны ТК тут не защищен.
- Практически у всех компаний, кроме тех, кто занимается каким-либо импортозамещением, проблемы с бюджетами в этом году. Прогноз на 2026 — неутешительный. Иными словами, затягиваем пояса. Эх, видимо, покупку Porsche придется снова отложить =)

Запись трансляции тут.

Про Бурдж-Халифа.

В ЗЯ, кроме заказов и подарочных карт, есть боксы и косметички. Что это такое? Это подборка разного рода товаров, тематически собранных в красивый комплект с определённой тематикой с учётом текущих трендов, времени года, праздников и т. д. и т. п. Анонсы продаж боксов и косметичек публикуются в соответствующих каналах @GoldApple_BOX и @flacon_mag. Подписывайтесь.

К чему я это? Поскольку предложения по данным товарам всегда ограничены и их раскупают в течение 5-ти минут, то это порождает колоссальный рост нагрузки на наши сервисы в момент публикации новости о начале их продаж. Для понимания: RPS на каталог/корзину может подскочить в моменте одной минуты в 2–3 раза, а количество заказов может подскочить до 10 раз.

Причём тут Бурдж-Халифа? Потому что на метрике заказов это выглядит именно так.

Про плагины для Mattermost.

Мы в ЗЯ весной этого года начали переводить наше корп-общение из ТГ в Mattermost среди IT. Это был сложный путь длиною в полгода. Не могу сказать, что всё прошло гладно и что сейчас всё работает идеально, но направление точно было выбрано правильно.

Для Mattermost, кроме банальных плагинов типа gitlab/jira/playbook, есть куча всего. В данном посте хочу поделиться моим ТОПом необычных плагинов. Порядок случайный:
- badges - Значки — они же ачивки, они же лычки. Это способ публично похвалить и/или поблагодарить кого-то за проделанную работу с отображением артефакта в его карточке сотрудника. Добавляет немного геймификации в рабочий процесс.
- jitsi - Интеграция с Jitsi. В идеале — развернуть собственный сервер, тк публичные находятся далеко за океаном. По качеству и функциональности Jitsi уступает Zoom и GMeet, но при этом остаётся одним из лучших и самых открытых решений на рынке.
- wrangler - Переносить треды между каналами, мержить треды в один, форвардить треды из приватных каналов в публичные — это всё об этом. Must Have. Пользуюсь постоянно.
- todo - Быстрые и простые TODO-шки на посты с периодическими напоминаниями, как альтернатива встроенному Remind.
- agents - Возможность использовать как публичных AI-агентов, так и внутренних, развернутых в вашей инфры, внутри Mattermost. Мой основной кейс использования — это когда меня призывают в тред длиной в 100+ сообщений, я прошу агента суммировать всё, что было до этого в обсуждении, короткой выжимкой.

Очень хочется попробовать exchange-calendar плагин, но его установка и конфигурация это какой-то ад.

Про AI.

В четверг был на конференции Yandex: Team Lead Go. В целом это было больше про нетворкинг, но был и один доклад о применении AI в мобильной разработке в Yandex Go. Со слов докладчика, у них уже сейчас используются AI‑агенты, которые парсят макеты в Figma и на их основе генерируют экраны мобильного приложения из коробки. Разработчик все еще нужен, чтобы провести ревью этого кода и самостоятельно добавить анимации. Со стороны это все выглядит невероятно.

Этой осенью на всех конференциях звучали доклады про AI. Автокомплит, рефакторинг, генерация тестов, code review, поиск уязвимостей, обнаружение неоптимального кода вроде n+1 - все это уже воспринимается как норма, а не как фантастика из будущего. При этом утверждается, что это все в помощь разработчику, чтобы быть эффективнее и быстрее перформить. Так ли это? Не знаю. Как будто тут есть доля лукавства. Точно понятно, что страдают джуны, которые сейчас никому не нужны, а senior-инженеры как были, так и остаются востребованы.

Время MVP прошло?

Мой опыт продуктовой разработки в любой роли в любой компании до ЗЯ строился на подходе "собрать быстрое MVP из говна и палок, запуститься, проверить гипотезу, а потом, если взлетит делать нормально". Логика простая, зачем тратить время и ресурсы на качество, если можно кое-как, но зато быстро. Но, кажется, время MVP прошло.

У меня нет на руках исследований или статистики, есть сугубо личное субъективное мнение. Рынок и мы сами, как пользователи цифровых продуктов, сильно изменились. Мы стали гораздо более требовательны к:
- визуальному качеству и целостности дизайна
- скорости и стабильности работы
- отсутствию навязчивой рекламы и "шумных" паттернов
- понятным онбордингам и прозрачной монетизации

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

В ЗЯ мы практически никогда не запускаем на клиентов MVP, в основном это всегда MLP, и это сложно. MLP тянет за собой более долгий discovery, а затем еще более долгий delivery-процесс. Хороший пример - новая программа лояльности.

Про интервью управленческого опыта.

Собрал себе гайд на основе доклада с этой конференции плюс дополнил своими мыслями. Гайд не претендует на истину в последней инстанции. Использовать строго через фильтр собственного здравого смысла и особенностей конкретной компании.

Общая структура интервью
- Формат: 5 секций, 70 минут суммарно, общая продолжительность интервью 90 минут
- Секции:
1) 🧑🏻👩 Управление людьми и командами - примерно 30 минут
2) 🔄 Управление процессами - примерно 10 минут
3) 🎯 Целеполагание - примерно 10 минут
4) 🔀 Внедрение изменений - примерно 10 минут
5) 🤑 Бизнес-экспертиза - примерно 10 минут

🧑🏻👩 Секция 1: Управление людьми и командами
Цель: понять подход к мотивации, развитию, найму/увольнению и дизайну команды.
Вопросы:
- Как ты работаешь с сотрудниками на регулярной основе? Какие практики используешь для поддержания мотивации?
- Как ты развиваешь людей и команду? Как оцениваешь прогресс и сравниваешь результаты между сотрудниками?
- Как принимаешь решения о найме? Кого и в каких ролях нанимал? Как и в каких случаях принимал решения об увольнении?
- Как проектируешь структуру команды и планируешь её рост/изменения?
Кейс-вопрос:
- Приведи конкретный пример: рост сотрудника, найм или увольнение. Какую роль ты в этом играл, как принимал решения, какой был результат?

🔄 Секция 2: Управление процессами
Цель: оценить подход к метрикам процессов, приоритетам качества и скорости, изменениям критичных процессов.
Вопросы:
- Как ты оцениваешь работу своей команды? Какие критерии и метрики используешь?
- Где твой приоритет в типичных дилеммах: качество vs скорость? Как принимаешь компромиссные решения?
- Есть ли у тебя опыт изменений критичных процессов? Как ты это делал?
- Что для тебя важнее — процесс или результат, и почему?
Кейс-вопрос:
- Приведи пример процесса, который тебе нравится или не нравится.

🎯 Секция 3: Целеполагание
Цель: понять горизонты планирования, метод постановки целей и механизм их достижения.
Вопросы:
- На какой горизонт ты планируешь и почему? Как выбираешь уровень детализации?
- Как ты ставишь цели себе и команде? Как обеспечиваешь достижение?
- Ты ожидаешь цели сверху или формируешь их самостоятельно?
- Как выстраиваешь операционный процесс под выбранные цели?
- Как переводишь абстрактные цели в измеримые планы и метрики?
Кейс-вопрос:
- Приведи пример конкретной цели и расскажи, как ты её достигал: план, трекинг, корректировки, результат.

🔀 Секция 4: Внедрение изменений
Цель: оценить подход к “приятным” и “болезненным” изменениям, управлению сопротивлением.
Вопросы:
- Как ты внедряешь изменения, которые команда воспринимает позитивно?
- Как ты внедряешь болезненные, но необходимые изменения? Как снижаешь сопротивление и риски?
Кейс-вопрос:
- Приведи пример неприятных для команды изменений, которые ты внедрял: контекст, план, коммуникации, результат. Если такого опыта не было — как бы ты подошёл к подобной ситуации?

🤑 Секция 5: Бизнес-экспертиза
Цель: понять, как кандидат видит вклад команды в бизнес, работает с метриками и влияет на них.
Вопросы:
- Как ты понимаешь роль и вклад своей команды в контексте бизнеса компании?
- Какие ключевые метрики у твоей команды? Как ты влияешь на них и на бизнес-результат?
Кейс-вопрос:
- Приведи пример конкретной бизнес-метрики и объясни, как твои действия повлияли на неё: гипотеза, действия, измерение эффекта.

По итогам каждой секции ставится 🟢,🟡 или 🔴 флаг. На основе количества флагов по цветам принимается решение о найме.

Лучший кейс по внедрению ИИ

(Взято из интернета)

В прошлом квартале я внедрил Microsoft Copilot для 4 000 сотрудников.

$30 за один аккаунт в месяц.

$1,4 миллиона в год.

Я назвал это «цифровой трансформацией».

Совету директоров понравилась эта формулировка.

Они утвердили всё за одиннадцать минут.

Никто не спросил, что именно он будет делать.

Включая меня.

Я сказал всем, что это даст «рост продуктивности в 10 раз».

Это не реальная цифра.

Но звучит как реальная.

HR спросили, как мы будем измерять эти 10х.

Я ответил, что мы «задействуем аналитические дашборды».

Они перестали задавать вопросы.

Через три месяца я посмотрел отчёты по использованию.

47 человек открывали Copilot.

12 использовали его больше одного раза.

Одним из них был я.

Я использовал его, чтобы пересказать письмо, которое мог прочитать за 30 секунд.

Это заняло 45 секунд.

Плюс время на исправление галлюцинаций.

Но я назвал это «успешным тестом».

Успех означает, что пилот не провалился явно.

Финансовый директор спросил про ROI.

Я показал ему график.

График шёл вверх и вправо.

График измерял «AI-адптацию».

Я выдумал эту метрику.

Он одобрительно кивнул.

Теперь мы «AI-ориентированная компания».

Я не знаю, что это значит.

Но это есть в презентации для инвесторов.

Старший разработчик спросил, почему мы не использовали Claude или ChatGPT.

Я сказал, что нам нужна «корпоративная безопасность».

Он спросил, что это значит.

Я ответил: «комплаенс».

Он спросил — какой именно комплаенс.

Я сказал: «весь».

Он посмотрел скептически.

Я назначил ему «разговор о карьерном развитии».

Он перестал задавать вопросы.

Microsoft прислала команду для анализа кейса.

Они хотели представить нас как историю успеха.

Я сказал им, что мы «сэкономили 40 000 часов».

Я посчитал это, умножив число сотрудников на число, которое выдумал.

Они не стали проверять.

Они никогда не проверяют.

Теперь мы на сайте Microsoft.

«Глобальная корпорация добилась прироста продуктивности на 40 000 часов с Copilot».

CEO выложил это в LinkedIn.

Он получил 3 000 лайков.

Он никогда не пользовался Copilot.

Никто из топ-менеджеров тоже.

У нас есть налоговая льгота.

«Стратегический фокус требует минимального цифрового отвлечения».

Я написал эту политику.

Лицензии продлеваются в следующем месяце.

Я запрашиваю расширение.

Ещё 5 000 лицензий.

Мы не использовали первые 4 000.

Но в этот раз мы «простимулируем внедрение».

Внедрение означает обязательное обучение.

Обучение — это 45-минутный вебинар, который никто не смотрит.

Но прохождение будет отслеживаться.

Прохождение — это метрика.

Метрики идут в дашборды.

Дашборды идут в презентации для совета директоров.

А презентации для совета директоров дают мне повышение.

К третьему кварталу я стану старшим вице-президентом.

Я всё ещё не знаю, что именно делает Copilot.

Но я знаю, зачем он нужен.

Он нужен, чтобы показать, что мы «инвестируем в ИИ».

Инвестиции — это траты.

Траты — это приверженность.

Приверженность означает, что мы серьёзно относимся к будущему.

А будущее — это то, каким я скажу ему быть.

Главное, чтобы график шёл вверх и вправо.

Телеграм канал HR-аналитики

Про планирование бюджета.

Открыл для себя интересный способ планировать бюджет через AI. Суть в том, чтобы через n итераций добиться от AI некого HTML-шаблона, который позволит как-то визуализировать бюджет на команды/отделы/людей с учётом индексации, найма новых ставок, переработок и т. д. и т. п. Всё это, конечно же, можно сделать в Excel, но для этого надо иметь по нему "чёрный пояс".

Само собой, никакие реальные данные в самого AI-агента мы не передаём, т. е. просим от него лишь сгенерировать сам HTML-шаблон (инструмент) на выдуманном примере данных про условных кошечек и собачек. Мой промпт выглядит так, пользуйтесь👇

У меня есть вот такой пример данных. 
;Сотрудник;Команда;Должность;Грейд;Доход net
<сюда вставьте строка за строкой пример выдуманных данных, чтобы AI понимал, что вы будете загружать потом в шаблон>

Ты можешь мне помочь с планированием ФОТ бюджета департамента разработки? Мне надо, чтобы ты дал мне какой-то шаблон в виде HTML‑страницы, куда я могу загрузить данные уже локально у себя на компьютере. 

Мои требования к шаблону:  
- хочу иметь возможность делать разные фильтрации по всем полям, в полях "Сотрудник", "Команда", "Должность", "Грейд" хочу иметь возможность выбрать несколько вариантов, т.е. иметь мультивыбор. При этом можно выбрать как всех, так и не выбрать никого. В фильтрах также должен быть доступ поиск по подстроке. 
- хочу иметь возможность заложить индексацию, чтобы увидеть, как вырастет ФОТ с её учётом  
- хочу иметь возможность заложить какое-то количество новых ставок, чтобы увидеть, как вырастет ФОТ с ними  
- хочу иметь возможность заложить количество дней, которые сотрудники будут перерабатывать, с указанием средней стоимости 1 часа переработки  
- хочу иметь возможность заложить возможность выбрать % налогов, которые компания выплачивает государству от совокупного дохода сотрудника  
- в общей таблице, где будет показываться список сотрудников, я хочу видеть, кроме полей "Сотрудник", "Команда", "Должность", "Грейд", "Доход net", ещё новые поля. Это "Доход gross", "Доход net (с индексацией)", "Доход gross (с индексацией)", "ФОТ сотрудника", "ФОТ сотрудника (с индексацией)"
- видеть общие графики по значениям для выбранных сотрудников в фильтрах: "Доход net", "Доход gross", "ФОТ", "Доход net (с индексацией)", "Доход gross (с индексацией)", "ФОТ (с индексацией)"

Визуально раздели шаблон на части. Визуально части должны идти одна за одной в шаблоне сверху вниз.
- Загрузка файла с данными.  
- Параметры расчёта - налоги. Пусть там будет: "% НДФЛ", "% совокупная налоговая и страховая нагрузка на ФОТ".  
- Параметры расчёта - индексация. Пусть там будет: "% индексации". 
- Параметры расчёта - новые ставки. Пусть там будет: "количество ставок" и "Средний доход net для 1 новой ставки". 
- Параметры расчёта - переработки. Пусть там будет: "общее количество переработок в часах", "средняя стоимость переработки за 1 час (доход net)".  
- Общая сводка ФОТ без индексации. Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Общая сводка ФОТ с переработками. Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Общая сводка ФОТ с новыми ставками. Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Общая сводка ФОТ с индексацией.  Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Общая сводка ФОТ с индексацией, переработками и новыми ставками. Пусть там значения "net", "gross" и "ФОТ на сотрудника". 
- Графики ФОТ. Пусть там будут как общие значения "net", "gross" и "ФОТ на сотрудника". Аналогично по подзразделениями. 
- Таблица сотрудников.

"ФОТ на сотрудника" - это сумма сколько компания тратит всего денег на сотрудника чтобы заплатить ему ЗП и все налоговые и страховые выплаты. 

Сделай данный шаблон HTML в палитре цветов светло‑синей, а не чёрно‑белой. Пусть шаблон будет достаточно компактный, чтобы не приходилось много скролить вверх вниз.

Развивать эту штуку можно бесконечно, все ограничивается лишь вашей фантазией.

Про клиентские метрики.

В рамках backend-разработки клиентские метрики - это метрики запросов из сервиса А в сервис Б, когда со стороны сервиса А измеряются RPS, latency, error rate и тд и тп по всем вашим интеграциям как с внутренними сервисами/системами компании, так и с внешними, с которыми вы, например, взаимодействуете по интернету.

Для внешних интеграций это актуально по множеству причин, начиная с банального, что нельзя слепо доверять тому, что вам говорят ваши партнёры, и заканчивая тем, что между вами могут быть firewall и прочие слои ИБ-инструментов, которые точно будут влиять на скорость ответа между вами, при этом сам партнёр об этом может не знать. Он предоставит вам данные о метриках со своего сервиса «в кубе» или чуть-чуть выше, но о том, что где-то ещё сильно-сильно выше стоит какой-нибудь WAF, он может не подозревать. Актуально для IT-гигантов, где тысячи инженеров, сотни команд, десятки отделов и передача верной информации затруднительна из-за эффекта сломанного телефона.

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

На скрине (latency 99p) я наложил "клиентские метрики", как сервис A видит запросы в сервис B, на "серверные метрики", которые собирает сам сервис B по этим же запросам c самого себя.

Жёваный крот! Щука, брат!

Можно ли ругаться матом на работе? Хочется сразу ответить категорически "нет", но на деле всё не так просто. Почему мы вообще ругаемся матом? В критических ситуациях только мат (к сожалению) может передать всю глубину и сложность проблемы и/или ситуации, с которой мы столкнулись.

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

Вариант 1
Коллеги, кажется, у нас что-то не так. Похоже, мы теряем выручку прямо сейчас. Я вижу проблему уже как минимум 30 минут, и меня это сильно беспокоит. Помогите, пожалуйста.

Вариант 2
Ёлки-палки, уже 30 минут ни черта не работает. Что за ерунда?

Вариант 3 (осторожно мат)
Какого хрена у нас сайт лежит? Где все?

1-й и 3-й варианты крайности, которые неуместны. 2-й вариант наверное, какая-то золотая середина, но он всё равно ни разу не передаёт всю глубину и проблематику ситуации. Что делать?

На эту тему был интересный доклад на крайнем Heisenbug 2025 - Матерюсь — значит, существую. Записи не нашел, видимо ее еще не выложили.

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

P.S.: я так и не понял, как правильно, "жеваный" или "жованый", вроде как "жеваный", но все мемасы через "о".

Как назвать?

В Магнит в 2021 году я разработал (возможно, откуда-то и скопировал, но уже не помню) свой паттерн именования каналов в корпоративном мессенджере. Тогда это был MS Teams, но это не столь важно. Знаю, что этот подход до сих пор используется в Магнит OMNI с некоторыми вариациями. В ЗЯ я его немного доработал, вот что в итоге получилось.

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

Всё базируется на префиксах team, tool, guild, release, support, proj, recruit и постфиксах qna, news.

Итак:
• team-<team_name>-<theme>, например team-main-qna, team-fs-news. qna - в данном случае это "приёмная" команды, куда может обратиться кто угодно с любым вопросом извне. news - это соответственно, канал новостей команды, которые команда может транслировать вовне, например о запуске какой-то крупной и важной фичи. Зачастую хватает только канала qna.
- guild-<guild_name>-<theme>, например guild-ios-qna. Тут всё аналогично team.
- tool-<tool_name>-<theme>, например tool-mattermost-qna, tool-mattermost-news.
- proj-<project_name>, например proj-new-search или proj-tips. proj - префикс, отражающий крупный проект/фичу, которая затрагивает множество команд где им нужно синхронизировать общие вопросы и сроки.
• release-<mobile|web> - каналы релизов МП и веба.
• recruit-<theme> - каналы про найм, например recruit-android или recruit-net.

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