Вы просили - мы сделали.

После выхода первой серии видеопроекта ПрожекторСэмаАльтмана, выяснилось , что есть множество людей, которые не любят смотреть видео ❌, но любят слушать аудиоподкасты 🎧 в машине или в метро по дороге на работу 🤷‍♂️

Мы раньше такого не делали, так что это эксперимент 🧪
Давайте вместе попробуем, надеюсь, он будет удачным 👇

Слушаем по ссылкам:
🎵 Яндекс.Музыка: ссылка
🍎 Apple Podcasts: ссылка
📱 Mave.Stream (слушать в Телеграм): ссылка

Данные в действии

Как менеджерам победить ИИ? «Прожектор СэмаАльтмана» 2я серия

Что во 2й серии:
- 🧠 Какие навыки потребуется развивать менеджерам, чтобы ИИ их не заменил?
- 💪 Какие проблемы мотивации людей возникнут в ИИ-эпоху?
- 🤖 Может ли ИИ осуществлять лидерство?
- ✨ И много чего еще..

Видео:
📱 Смотреть на Youtube

Аудиоверсии:
📱 Телеграм (mave)
🎵 Яндекс.Музыка
🍎 Apple Podcasts

В выпуске:
• 01:15 — Отчет PMI: три компетенции менеджера будущего. ИИ уже в списке.
• 02:45 — ИИ сам записывает совещание, сам составляет и согласует ТЗ...
• 05:35 — От идеи → до новой версии продукта за ОДИН ДЕНЬ. И это не фантазия
• 06:17 — Мёртвый интернет: в онлайне больше нет людей
• 08:57 — PM будущего — это не "координатор задач", а стратегический бизнес-партнер
• 11:20 — Останутся только самые умные и незаменимые сотрудники. С ними манипуляции PMов не работают
• 13:17 — А что если сотрудников просто привяжут к компании через опционы или нейролинк?
• 15:51 — HR после пандемии осознали: с людьми нельзя вести себя как с роботами
• 18:58 — Если AI станeт менеджером — будет ли человек подчиняться машине?
• 20:54 — Реальная история: кандидата собеседовала ИИ — он почувствовал ужас
• 31:02 — Дарт Вейдер входит в кадр :)
• 37:04 — ИИ и производство чапельников
• 39:04 — Итоговый список компетенций менеджера будущего
• 43:01 — Молитва ИИ-автоматизатора

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

#ИИ

📊 Раскрываем дело: сопоставление ТТХ и гипотез

Если я когда-нибудь соберусь написать "Методичку по анализу процессных метрик", то после главы о сборе ТТХ рабочего процессе, следующей будет глава про сопоставление гипотез и ТТХ.

К этому моменту у нас уже есть:
— 🎯 цели анализа,
—💡 гипотезы,
—📐 декомпозиция гипотез до метрик,
—📁 и собранные данные о ТТХ процесса

Теперь нужно сопоставить одно с другим. Звучит просто, но “в лоб” редко работает.

---

🧩 Разберем на примере гипотезы

«Аналитиков заваливают идеями без приоритезации, заказчики недоступны, сроки сжаты — итог: пишем “как поняли”, а потом программисты делают не то»

Разберём первый кусок гипотезы: «заваливают идеями»

Что здесь непонятно с точки зрения анализа рабочего процесса:
1️⃣ Где искать “идеи” на доске?
2️⃣ Какие метрики покажут “завал”?

---

1️⃣ Где искать "идеи" на доске

С точки зрения рабочего процесса (value stream), “идеи” — это работа на ранней стадии, обычно где-то в начальной колонке - Backlog (ToDo).

2️⃣ Какие метрики покажут “завал”?
Если в этом столбце копятся десятки карточек идей, и новых приходит больше, чем успевают обработать — то процесс явно не справляется с нагрузкой - что и есть "завал" ⚠️

⚠️ “Заваливают” — это когда частота поступления > частоты обработки.
Например, в месяц приходит 100 новых идей, а берут в работу только 10 — очередь растёт. Завал.

---

🔍 Что смотрим в ТТХ для проверки "завала идеями"

*📊 CFD (Cumulative Flow Diagram): видно, как растет “толщина” слоя с идеями

*📥 Inflow / Throughput: сколько идей приходит и сколько уходит из колонки за период.

Если Inflow стабильно превышает Throughput — гипотеза подтверждается ✅
Если нет — гипотеза не подтверждена ❌

Для уверенности, дополнительно можно посмотреть:
*⏳ Backlog Cycle Time Distribution — сколько времени идеи “маринуются” в колонке Backlog (ToDo)

*📆 Aging Chart — возраст идей в колонке Backlog (ToDo)

---

🛫Upstream: где всё начинается

Читаем гипотезу дальше — “...без приоритезации, ... заказчики недоступны... делаем как поняли....”

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

Если на доске только три колонки (ToDo / In Progress / Done) и нет какой-то отдельной Upstream-доски — значит, Upstream отсутствует как таковой 🤷‍♂️

А если Upstream отсутствует, то значит, разработка требований, фильтрация и приоритезация происходит уже во время разработки (Downstream). Что доставляет массу проблем всем 👎

Если же Upstream есть, то он может быть "плохим" и не работать как надо

🚧 Признаки "плохого" Upstream:
* ⚙️ нет Definition of Ready / Definition of Done в колонках Upstream-процесса;

* 🔁 есть возвраты задач с Downstream назад в Upstream;

* 🧩 большое количество “переделок” или "доработок" по просьбам бизнеса после релиза

---

🧠 Анализ аномалий как источник знаний об Upstream

Отдельный источник инсайтов — анализ задач с аномально длинным Lead Time 🐢

Берём самые “долгоиграющие” карточки и обсуждаем их с командой:
почему именно эти где-то застряли в ходе работы над ними?

Часто вскрываются типовые паттерны плохого Upstream:
- ❗️ непроработанные требования,
- 🔄 хаотичные приоритеты,
- ⌛ долгая обратная связь от заказчика,
- 🔧 переделки после релиза

Всё это - следы проблем на Upstream.

Аномалии — зеркало системных проблем в котором очень многое можно увидеть.

---

📍Что получаем в результате

После такого сопоставления гипотез и ТТХ становится ясно, какие гипотезы подтверждаются, а какие нет - и дело раскрыто

Причем у нас появляются данные на которые можно опираться 💪

Следующий шаг — переход к рекомендациям.
Но это — уже тема следующей главы 😉

#методичка
#data_driven_management

Данные в действии