А между тем, под Новый Год мы записали новую серию ПрожекторСэмаАальтмана - про то, что ИИ делает с миром, и как люди реагируют на эти изменения

В этом выпуске мы решили не привязываться к конкретным цифрам и новостям, а просто подвести некоторые ИИ-итоги 2025 года.

В этом выпуске:
➡️ Почему разработчики теперь кодят быстрее, чем продакты успевают думать и приносить новые идеи в бэклог?
➡️ Как продакты с помощью вайб-кода создают работающие прототипы вместо ТЗ
➡️ Зачем рынку нужны «реаниматоры» кривого вайб-кода?
➡️ Лайфхаки для защиты от прохождения собеседований с помощью ИИ
➡️ Смерть Agile? Станут ли команды микроскопическими и почему стабильность больше не в моде.
➡️ Кибер-саботаж: зачем пользователи кормят ИИ «отвратительной датой» и портят модели.
➡️ Узнайте, как не превратиться в простого «оператора черного ящика» в 2026 году

Говорим свободно, с юмором, в меру собственного понимания происходящего.

https://youtu.be/sguUHwmCHNQ?si=wXdJ2D6-3UG0dAVN

Последний пост был 23 января, куда делся автор? (Спойлер: цифровая археология, вайб-кодинг и HR)

Я не ушел в монастырь, я ушел в глубокий R&D.
Проверял, на что способен эксперт в 2026 году, вооружившись ИИ, здравым смыслом и прошлым опытом.

Итоги месяца (выбирайте тему для лонгрида 👇)

1. Process Mining в помощь канбанисту 🕵️‍♂️
Дано: 10+ команд, 12 тысяч строк логов и полный разнобой в workflow
Задача: Найти реальный Commitment Point и построить аналитику (Upstream/Downstream Lead Time).
Выход: С помощью Gemini реализовал алгоритм Transition Analysis. Он вычислил реальные Commitment Point, игнорируя хаос в Jira. Дальше — дело техники.

2. Импортозамещение Канбан-игры 🎮
Дано: Любимая Канбан-игра для тренингов попала под VPN. Заменить нечем.
Выход: Психанул, открыл Cursor и сел писать свою версию (с блэкджеком и 💃)
Итог: За 2 часа «вайб-кодинга» создал рабочий прототип. За 4 часа — 90% механик. Скоро релиз! Хотите попробовать? 😁

3. Вероятностный Анализ на R 🎲
Задача: Обработать огромный, пятилетний массив данных клиента по 10+ проектам. LLMки захлебываются, вручную делать - годы.
Выход: Делегировал нейросети написание кода на R для подготовки и анализа данных. Код был написан и отлажен за 4 часа. Итоговый анализ всех данных занял 2 дня. Клиент в восторге от точности попадания и инсайтов.

4. Практикум в BigTech 🏢
Дано: Крупная IT-компания, 10+ зубастых менеджеров.
Задача: Научить анализу метрик.
Что сделал: Сперва играли на чужих данных — было весело. Когда загрузили свои — случился ледяной душ. Видеть реальный Lead Time страшно, как прием у стоматолога, но лечить надо.

5. Инсайт: Смерть обучения как поощрения 💼
Задача: Понять через интервью с HR, что творится с обучением.
Инсайт: Бюджеты на «счастье сотрудников» закрыты. Теперь обучение — только под жесткий бизнес-заказ и фин. обоснование.

О чем написать подробнее? Жмите реакцию 👇 или пишите в комментарии:
🗿 — Археология Commitment Point в JIRA
🆒 — Моя игра и как я ее делал
🦄 — Прогнозы на R
🙊 — Инсайты в HR
👍 — просто порадоваться за автора 😊

🗿 JIRA-археология с помощью Process Mining ⛏️ Часть 1.

Кратко: 27 000 строк логов 📜, 5 лет хаотичных процессов 🌪, конец года ❄️ и Process Mining⛏️

Сеттинг:
Огромное подразделение разработки Data-продуктов в одной огромной компании 🏢
20+ внутренних заказчиков, 10 направлений разработки.

😤 Бизнес жалуется: «Мы не понимаем, когда Data-подразделения сделают задачи! Их обещания по срокам не сбываются! Мы не знаем как нам выполнять обещания, которые мы даем нашему руководству».

🛡 Департамент Data-продуктов оправдывается: «У нас все сложно, контекст меняется часто, а бизнес постоянно меняет приоритеты! Проектов больше чем людей!»

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

На дворе декабрь ❄️, конец года, у всех горят дедлайны 🔥. Доступ к людям ограничен, «посидеть и поговорить» с представителем каждого из 10 проектов нереально! 🚫

У меня на руках — выгрузка из трекера: 27 000 задач за 5 лет 💾

🕵️‍♂️ Проблема: Вавилонская башня в Excel

Открываю файл лога статусов и вижу:
1️⃣ 30 разных статусов, из который часть используется в одних проектах, часть в других. Часть вообще не используется.

2️⃣ 4 статуса, означающих закрытие задач 🏁

3️⃣ 5 статусов означающих на открытие задачи 🚦

4️⃣ 7 статусов-буферов 🛋

🤯🤯🤯🤯🤯

Но главная проблема: десяток промежуточных Work-статусов, среди которых спрятана точка принятия обязательств (ТПО)📍!

А без знания точки принятия обязательств не возможно понять границу между ⬆️Upstream (выбор и подготовка задач) и ⬇️Downstream (разработка).

Анализировать вручную 27 тысяч строк — это месяца два работы 🐢
Напомню - декабрь, все в мыле 🧼, времени поговорить ни у кого нет. А тем более разобрать 10 разных проектов.

🤖 Решение: эвристики Process Mining
Я решил не гадать, а использовать два алгоритма Process Mining, адаптированные под Kanban. С помощью ИИ-шки написал код на языке R и прогнал данные.

🎰 Алгоритм 1. Trace Variant Analysis (Анализ вариантов процесса)
Для начала я взял каждую задачу и по последовательности дат в логе, восстановил её реальный путь по статусам.

Получилась таблица из двух полей:

🆔 ID задачи,
🔀 Workflow ( последовательность статусов )

Посчитал частоту повторения одних и тех же workflow - получил список частотности workflow 📊

1) 1234 раза:
"Open -> Ready To Develop -> In Progress -> Done"

2) 976 раз:
"Open -> In Progress -> Done "

3) 540 раз:
"Open -> Analysis -> In Progress -> Close "

И тд

Очевидно самый частый workflow, который включает в себя статус открытия, промежуточные статусы и статус закрытия - скорее всего и есть основной 🏆

😱 Сюрприз: Оказалось, что примерно 20-30% задач в каждом проекте имеют путь "Open -> Closed".
Это «шум», мусорные задачи или массовые чистки бэклога. Они искажали статистику, поэтому пришлось их отфильтровать.

[продолжение в следующем посте] 👇

[Продолжение предыдущего поста. Часть 3] 🍿

💡 Развязка: свежесть ≠ количество
Я вспомнил золотое правило классиков Канбан-метода ( Трой Мадженнис, Даниэль Ваканти) при анализе метрик рабочего процесса:

«Свежесть данных важнее их количества»
(c) умные люди

Если у нас на руках «простыня» данных за 5 лет, не стоит радоваться. В IT-разработке 5 лет — это целая эпоха.

За это время могло измениться всё:
🎭 Состав команды (кто-то выгорел, кто-то пришел);
👔 Менеджмент (новые метлы по-новому метут);
🌍 Предметная область;
🏗 Стек технологий;
...и еще вагон нюансов.

Любое из этих изменений меняет «физику» процесса. 🌪

А значит, статистика за 5 лет показывает не то, что происходит сейчас, а «среднюю температуру по больнице» с учетом всех кризисов и реформ прошлого.

Я уточнил у заказчика хронологию событий. И бинго! 🎯 Выяснилось, что в этом проекте за 5 лет сменилось три состава команд и два менеджера. Каждый «оптимизировал» процесс под себя.

Когда я запустил алгоритм Probabilistic Activity Tagging отдельно по годам, хаос превратился в стройную историю:

📜 Эпоха 2020-2022
Точкой Принятия Обязателств явно был статус «Analysis» (вероятность 65%)

⚡️ Эпоха 2023 – н.в.
ТПО сдвинулась на "In progress" ( вероятность 73% )

Даты смены ТПО четко совпадали приходом новых менеджеров 🤷‍♂️

🏁 Итог
Мы договорились с заказчиком убрать «хвост» старых данных и анализировать только последние 2 года (период стабильности). Это дало чистые метрики, четкое разделение Upstream/Downstream и адекватные данные для аудита.

💼 В чем профит для вас?

Если вы рулите армадой из 10–50 команд, вы наверняка смотрите в дашборды с метриками CLT, ULT, DLT.

Но чтобы эти буквы имели смысл, нужно знать три координаты:
🐣 Точка создания (Open)
💀 Точка закрытия (Done)
💍 Точка принятия обязательств (ТПО)

А дальше — чистая математика:
🧮Customer LT=Done-Open
🧮Upstream LT=ТПО-Open
🧮Downstream LT=Done-ТПО

В каждой команде «своя атмосфера», и эти точки могут гулять по разным статусам.

И тут на сцену выходят эвристики, о которых я писал выше 🚀

С их помощью можно автоматически отследить, когда ТПО (или другая точка) вдруг «поехала» в сторону.

📡 Это сигнал - процесс изменился, метрики врут, пора идти к команде с вопросами.

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

P.S. Весь код для анализа (R + эвристики) я писал с помощью LLM 🤖🤝🧔

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