Ахаххахахзазазазахах

ИИ ускорит работу менеджеров. Но встреч от этого станет только больше! 😁

Короче, есть такая штука - парадокс Джевонса.

В 1865 году экономист Уильям Джевонс заметил странную закономерность.

Паровые двигатели становились эффективнее и потребляли всё меньше угля на единицу работы.

Казалось бы, угля должно требоваться меньше?

А вот и нет!

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

Чем дешевле и проще что-то делать, тем больше мы начинаем это делать.

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

Теперь благодаря ИИ всё это можно сделать за несколько часов.

Казалось бы, решения должны приниматься в 10 раз быстрее?

Но есть нюанс!

Подготовить предложение и принять решение - две совершенно разные задачи.

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

И вот тут ИИ не сильно ускорит процесс.

Зато если раньше мы готовили 3 предложения в месяц, то теперь сможем подготовить 30!

И все их нужно прочитать, обсудить и по каждому принять решение.

Кстати, с интернетом мы уже проходили что-то похожее.

Электронная почта сделала коммуникации почти бесплатными. И что?

Теперь, по данным Microsoft Work Trend Index 2025, средний сотрудник в исследовании получает 117 писем и 153 сообщения в Teams за день.

Мы научились невероятно быстро обмениваться информацией, но не научились так же быстро её обрабатывать.

Кажется, с ИИ будет похожая история.

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

И вот вам моя гипотеза:

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

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

Вы знаете, что хуже бесполезной метрики?

Бесполезная метрика, на основе которой менеджеры начинают принимать решения! 😁

Короче, тут ребята из Google опубликовали интересную статью — What Makes a Good Productivity Metric о том, как правильно мерить продуктивность!

Начнем с метрик.

Мы, менеджеры, очень любим что-нибудь измерять.

Сколько задач закрыли, сколько коммитов сделали, сколько дней провели в офисе (пу-пу-пууууу).

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

Авторы предлагают 4 критерия хорошей метрики:

1. Понятность. Метрику можно объяснить нормальному человеку без защиты кандидатской по математике.
2. Соответствие реальности. Если ситуация объективно ухудшается, метрика должна это замечать.
3. Отсутствие странностей. Метрика не должна показывать ерунду там, где мы точно знаем, как устроен мир.
4. Полезность. По результатам измерений можно принимать решения.

Вот такой вот вам проверочный вопрос для хорошей метрик:

Если метрика изменилась, а вы не понимаете, что теперь делать, то зачем вы вообще её измеряете?

А теперь самое интересное!

В Google решили разобраться, что сильнее связано с продуктивностью инженеров: количество дней в офисе или стабильность рабочего графика.

Для этого рассмотрели 13 вариантов метрик и выбрали довольно хитрую штуку — Weekly Markov Consistency.

Не буду грузить вас математикой, но смысл простой:

👉🏼 Если человек каждую неделю работает по понятному расписанию, то его график предсказуем.

Причём совершенно неважно, ходит он в офис пять дней или два.

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

И что выяснилось?

На данных десятков тысяч инженеров Google обнаружили:

• Разработчики со стабильным гибридным графиком (1–3 дня в офисе) не имели статистически различимой производительности по CL throughput от тех, кто стабильно работал в офисе всю неделю.
• А инженеры, которые появлялись в офисе не чаще одного дня в неделю, но придерживались стабильного графика, по тому же показателю не отличались от тех, кто ходил туда большую часть недели, но нерегулярно.


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

Правда, есть нюанс: это наблюдательное исследование, а CL throughput лишь одна из метрик продуктивности. Причинно-следственную связь авторы тут не доказали.

Но сама мысль отличная!

Какие выводы забрать с собой?

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

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

Проще считать закрытые задачи, чем созданную бизнес-ценность.

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

И, кажется, главный вопрос, который менеджер должен задавать себе при появлении очередного KPI:

«А какое именно решение я буду принимать на основе этой цифры?»

Если ответа нет, возможно, нам просто очень хотелось красивый дашборд. 😁

Можно построить идеальную инженерную платформу, которой никто не хочет пользоваться! 😁

И самое забавное, что с точки зрения инженерных метрик у вас всё будет прекрасно!

Короче, сходил я тут к ребятам из подкаста «В SREду на кухне» поговорить о том, зачем инженерам продуктовое мышление.

И, кажется, это одна из моих любимых тем!

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

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

О чём поболтали:

1. Зачем инженерам продакты? И в какой момент внутренний инструмент вообще становится продуктом?
2. Как измерять успех платформы? Вот у вас 100% adoption. Это успех или просто разработчикам запретили пользоваться альтернативами? 😁
3. Зачем нужны контрметрики? Можно же здорово ускорить разработку, а заодно уронить надёжность. Или сделать супернадёжную платформу, на которой невозможно работать.
4. Алертинг как продукт. Почему даже такую сугубо инженерную штуку можно и нужно проектировать вокруг пользовательского опыта?
5. Кто вообще заказчик надёжности? И почему пользователь, заказчик и тот, кто за всё это платит, — далеко не всегда один человек?
6. Что важнее — надёжность или Developer Experience? И почему вообще приходится выбирать между этими двумя вещами?

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

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

Смотреть и слушать:

📺 YouTube

📱 VK Видео

📺 Rutube

🎧 Mave

Ну и приходите в комментарии спорить!

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

А что дальше?

Автопополнение корзины — идеальный пример такой «фантазии о будущем». Ритейлер или маркетплейс видит твои регулярные покупки, собирает привычный набор и предлагает до того, как ты вспомнил. Удобно? Да.
Но как отличить реальную потребность от навязанного потребления?
И где метрика, которая покажет, что это не просто «продать побольше», а реально польза для клиента?

Вот как раз посмотрел выпуск «ПродАктовой корзины», где эксперты разгоняли про потребление будущего. Для аналитика — прям поле для размышлений про метрики, этику и инкрементальность.

Рекомендую глянуть: YouTube или VK Видео