Про 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.

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

Про 360 и оценку сотрудников.

В школе я был далеко не отличником, а в вузе тем более. Но именно тогда у меня закрепилась установка, всё нужно делать «на отлично», то есть на 5. В школьной системе 5ка воспринимается скорее как норма, а не как выдающийся результат. Таким образом нам с детства задают планку "учись на 5".

При оценке сотрудников в формате 360 "школьный подход" часто приводит к конфликту восприятия, тк в нашей работе невозможно постоянно быть отличником. Задачи разные, контекст меняется, а результат зависит не только от усилий конкретного человека. Поэтому 3 - это нормальный, те ожидаемый результат. И это НОРМАЛЬНО!

Мое воспринятие:
1 - значительно ниже ожиданий. Провал, требуется срочного исправление.
2 - ниже ожиданий. Немного не дотянул до нормы.
3 - соответствует ожиданиям. Уверенная норма, те все ОК.
4 - выше ожиданий. Заметно лучше требуемого уровня.
5 - выдающийся, редкий результат. Уровень Rockstar.

Про офис для руководителя.

Пока вокруг все говорят про внедрение ИИ, про удалёнку, про распределённые команды, про метрики и т. д. и т. п., хочется вернуться во времена, когда мы просто приходили в офис, завтракали на кухне, потом садились за общий стол на 3–4 человека и вместе работали. Без созвонов, встреч и календаря.

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

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

Было же время!

P.S.: картинка отсюда.

Пост про бардак.

Я глубоко уверен, что первопричиной большого количества проблем в современном IT (и не только) является простой бардак. Попробую, попытаюсь объяснить.

Начнём издалека, с некоторой аллегории. Представьте, что к вам подходит ваш ребёнок и просит помочь собрать пазл из LEGO. Вы, конечно же, готовы помочь. Идёте в комнату, а там бардак. Игрушки разбросаны, кровать не убрана, одежда валяется на полу и тд и тп. Можно ли в такой комнате собрать LEGO на фоне бардака? Наверное, да, но хочется сначала навести порядок, а уже потом собирать LEGO.

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

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

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

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

Про оценку настроения/cчастья команды.

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

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

Я не знаю, как правильно, я лишь помню, как это было на одном из мест моей работы. Бот стучался к тебе в личку каждый день ближе к концу рабочего дня и просил оценить твой день по шкале bad/hard/neutral/good/excellent и, опционально, оставить комментарий. В итоге ты как менеджер видел анонимную среднюю оценку настроения своей команды каждый день в динамике, с историческими данными, и мог понять, как и какие события тем или иным образом на нее влияют.

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

"Письмо" в редакцию.

Ниже текст не обиженного луддита, настальгирующего по good old days - а скорее анализ происходящего и попытка трезво принять будущее.

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

В Software Engineering всегда было разделение на «художников» и «маляров». Художники творят Linux, Redis, Python. Маляры решают прикладные задачи перематывая всё это изолентой. Спрос на вторых рос десятилетиями, но сейчас приходит смерть профессии в ее привычном виде, ака демократизация малярного дела.

Все мои знания аргументов grep, параметров gunicorn или трюков оптимизации Docker-образов больше не нужны (даже мне так то!). Даже хитровыебанные знания, вроде паттернов проектирования или систем дизайна. LLM в них компетентнее. Когда я получаю от нейронки снисходительное «You are absolutely right», мы оба знаем: это просто вежливая лесть за уплоченны токены.

Мы поднимаемся на новый уровень абстракции, где становится неважно, *как это сделано*. Нам же плевать на регистры и сдвиги в ассемблере? Теперь этот подход добрался до нашего “высокоуровневого” кода,

Я вижу это на ревью: прилетает PR на 1000 строк нового кода в репозиторий, где всего их 3000. Там всё ок: тесты, документация, структура.
• Да, можно это сделать проще через стороннюю библиотеку - так уж вышло что я это знаю.
• Да, это стоило бы разбить на пять мелких PR, чтобы я не сошел с ума это всё ревьюить.

Но реальность такова: этот код больше не предназначен для чтения человеком. Индустрия переходит в write-only режим. Если нейронка написала тысячу строк, которые работают, и она же сможет их потом поправить — «красота», «переиспользуемость» и «поддерживаемость» кода в человеческом понимании становятся атавизмом.

Так уж вышло что последние 10 или сколько там лет я практиковался именно в “как”. Как сделать код поддерживаемы, безопасным. Как побить на зависимости и сделать общие части переиспользуемыми. Как сделать красиво - ну это самый кайф в нашем достаточно скучном корпаротивном болоте. Теперь этот навык превращается в избыточную нагрузку для бизнеса – хотя wait a second, it always been.

Про настоящий gamechanger от AI.

Что действительно может быть сделано на основе AI, что драматически перевернёт весь мир? Создание полнометражного фильма уровня Голливуда одним человеком? Создание новой игры типа GTA7 одним человеком? Нет. Это, конечно, сильно поломает текущие индустрии развлечений, но всё же нет.

Если вы читали или смотрели экранизацию книги «Автостопом по галактике», то там была рыбка, которая позволяла главному герою понимать любую речь в галактике. Вот оно. Уже сейчас есть Neuralink. Если его как-то скрестить с AI и позволить работать как эта рыбка, то вот он геймченджер. Не надо больше учить никакие языки. Вы понимаете всё, что слышите, и вас также понимает любой слушатель. Мир радикально изменится, так как обмен любой информацией с любым человеком на Земле больше не будет иметь никаких преград.

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