Marat @ Predictable.Team

📚 Книжка "Неслучайная случайность: как управлять удачей и что такое серендипность." (en: The Serendipity Mindset: The Art and Science of Creating)

🦋 Долго и нудно, на протяжении 300 страниц автор предлагает видеть необычное в обычном, быть “открытым к неожиданностям” и прокачивать тот самый serendipity – “искусство счастливых случайностей”. Не рекомендую.

🔍 Короткий обзор и духота от меня

В 2020 году профессор Кристиан Буш решил легализовать удачу (мол, это не просто "удача", это целый процесс) и описал новый “майндсет” поиска возможностей в хаосе.

🎱 Основа - принципы “серендипного” мышления:

- Будь внимательнее: замечай детали, на которые обычно бы не обратил взор (развивай внимание, периферийное зрение и вот это всё). Тут про насмотренность и осознанность.

- Мысли с разных сторон: рассматривай привычные ситуации с других сторон (в идеале — не только своих). Тут как бы просто про критическое/латеральное/ дивергентное мышление.

- Расширяй связи: общайся шире, спрашивай про “что-то еще” в Small Talk — вдруг подвернется “касание удачи”. Я переведу - просто будь экстравертом и делай нетворкинг.

- Порождай триггеры: вместо “Я маркетолог” во время знакомста удиви (вау) всех словами — “Я изучаю поведение людей, делаю подкасты, люблю сканди-детективы” — и смотри, к чему это приведет. Именно так люди запоминают тебя лучше и образовываются связи.

- Не жди чуда, а сам создавай предпосылки: чем больше действий, тем выше шанс “случайного” открытия (но это не точно). Ну чем не проактивность.

☦️ К чему скепсис (мой)

Неплохо, что тут есть практики self-reflection и упражнений в конце каждой главы. Но если коротко — почти всё, о чем пишет Буш можно найти в любой self-help литературе.

Много историй уровня “один парень что-то сделал -> случайно повезло -> теперь миллионер”. Сама идея, что “сознательно можно тренировать удачу”, не нова. Но в этой книге глубокое знание и эрудиция как фундамент серендипности — отодвинули на второй план. Зато техник, сторителлинга который бесконечно повторяется — с лихвой.

"Видеть возможности в случайностях”, как говорит автор, всегда полезно — особенно если крутишься в стартапах или креативных продуктах. Но никакой “серендипный майндсет” без системного подхода, осознанности, привычки критично смотреть на вещи и работы с культурой не жизнеспособен

Ozon / Альпина / Амазон

PS: Лучше прочитайте эту "Неслучайную случайность"

Воскресное чтиво: Какое есть ии-железо в Китае на замену Nvidia (и насколько они мощные).

https://habr.com/ru/articles/944548/

Я на работе занимаюсь внедрением AI в разработку. И интересуюсь ИИ-темой во всех ее проявлениях. И ROI, и adoption, и в целом насколько это реально помогает командам разработки.

На выхожных читал статью, на которую наткнулся в канале The Edinorog - какие в Китае есть производители ИИ чипов. Перевел статью и добавил мяса (ато как-то неинтересно без деталей) - какие по техническим характеристикам есть чипы в сравнении с Nvidia A100/H100 , AMD Ryzen.

🚀 Вы только посмотрите до чего дошли технологии.

Из статьи можно делать видео-презу с аудио и графиками, причем качественно и автоматически!

Вчера, интереса ради закинул свою статью про Прогнозирование с помощью симуляции Монте-Карло с Хабра и попросил сделать NotebookLM видео-обзор (я уже писал для чего использую NotebookLM).

📹 Так он сделал целую презу с хорошим визуалом, нарративом (пусть и излишне оптимистичным). Такое можно хоть на youtube запихивать! Воистину, как пела SuperAlisa, "Безнен жирда жана технологиялар" (на нашей земле горят технологии) в своем шлягере "Су Анасы".

🙄 Если кому-то было лень читать и вы не в числе 2,4к прочитавших -> ролик-преза на английском (на русском он пока не могёт).

У меня тут вышел большой практический гайд на Хабре про Throughput (динамику и паттерны) и прогнозирование симуляцией 🎲 Монте-Карло.

🔍 Разбор Throughput со стороны
- Значимых периодов и частоты замеров
- Вариативности
- Кластеризации по типам работ

🤖 Алгоритм составления прогнозов через симуляцию Monte-Carlo на основе Throughput - Когда будут готовы следующие 50 элементов

+ Обзор инструментов визуализации и прогнозирования
+ Почему Throughput уже учитывают вариативность в работе команде
+ Почему Story Points менее эффективны для прогнозирования

https://habr.com/ru/articles/940882/

#mcs #montecarlo #throughput #forecasting

🎓 Про Notebook LM. Back to school (как в песне Deftones), так сказать.
Общаемся с книжками, слушаем ИИ-подкасты, провоцируем шизофрению.

Где-то год назад я открыл для себя NotebookLM*, это инструмент от гугла который достаточно сильно поменял мой подход к изучению информации.

Фактически это, да простят меня технари, RAG-модель от Google. Она превращает ваши документы в умного собеседника. Теперь не надо листать книгу или PDF, в поисках цитаты.

🥸 Как это работает:

1. Загружаешь до 50 источников — Книги, статьи, видео YouTube, Google Docs.
2. Спрашиваешь что угодно — он отвечает ТОЛЬКО на основе загруженных документов.
3. Получаешь точные ответы со ссылками на источники!

💡Мои сценарии использования:

- Изучаю как разные источники рассматривают одну и ту же проблему — закидываю, к примеру, книги по платформенным командам: Team Topologies, Platform Engineering, Scaling Teams (изучаю тему платформ).

- Product research — собираю пользовательский фидбек на разные инструменты, нахожу паттерны

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

🍰 В итоге:

Экономия времени, никакого муторного поиска. И всегда супер-явно можно сослаться на данные из конкретных источников.

🎧 ИИ-подкасты

А еще там есть генерация подкастов из ваших материалов! Это уже совсем космос и шизофрения, но я этим пользуюсь. Закинул три книги по теме, попросил сделать подкаст - и там два ИИ-хоста обсуждают твой материал


* чтобы пользоваться из России, надо зайти "не-из-России"

Маленький пост, важная и очень простая тема.

🦾 Закон Литтла - универсальная взаимосвязь метрик потока

Мы с вами прошлись по Throughput, Lead Time - а как они взаимосвязаны, есть ли формула? Да, закон Джона Литтла! В следующий раз, когда ваш менеджмент/команда будет говорить "да давайте напихаем побольше в спринт" - покажете что это приведет к определенным последствиям.

📜 Чем больше у вас элементов в работе (Work In Progress, WIP) - тем дольше вы делаете каждый элемент (Lead Time) и тем меньше элементов выпускаете (Throughput).

🍣 Что такое WIP на примере суши‑ресторана

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

💻 А в IT?

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

👌 Простота и универсальность

Логика закона Литтла тривиальна в использовании и не требует спецподготовки. В практике она превращается в один вывод: чтобы lead time был меньше, а throughput — выше, нужно не раздувать параллельную работу. Слишком много начатого — значит, мало законченного и долгое ожидание.

🛣 С чего начать с WIP‑лимитов

- Базовая настройка: стартовать с WIP примерно «размер команды + 1».
- Наблюдать пару итераций: если throughput растёт и lead time сокращается — можно пробовать аккуратно снижать WIP дальше.
- Если при снижении WIP throughput падает — лимит задушили, верните на шаг назад.

👨‍🦰Так что наматываем на ус правило: ограничивая параллельную работу, мы управляем и временем поставки (lead time), и пропускной способностью (throughput).

Marat @ Predictable.Team pinned «🤟️️ Всем хаумы ("привет" на башкирском) Меня зовут Марат. Я занимаюсь оптимизацией процессов и data-driven изменениями в АйТи и всех смежных с ним областях. Я работаю в крупном финтехе Agile-коучем (linkedin), отвечаю за эффективную работу и взаимодействие…»

Пятничный лайтовый-пост.

Самые нестандартные (и местами трешовые) метрики. Из коллекции “2 Dozen Weird Agile Metrics Ideas” — это подборка странных и забавных способов замерять "эффективность" команд, которой поделились PM-ы, agile-практики и коучи на projecttimes.com.

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

Вот топ-10 из подборки “2 Dozen Weird Agile Metrics Ideas”:

🗑 Количество фич, удалённых (не отмененных) из бэклога (а может, и из прода) — иногда главное не сделать, а вовремя удалить
❌ Количество остановок продакшна (stop the line events)?
❓ Сколько пунктов из ретро реализуют реально? (Легенда гласит, что кто-то доводил до 3 из 10)
🤟 “Коэффициент user stories с нулём багов” — чем ближе к 100%, тем веселее обсуждение!
🤣 Время до первой шутки на дейли — автоматизация для души.
☕️ “Индекс кофеина” — сколько кофе на команду за спринт vs сколько багов в релизе?
🐞 Число багов, найденных после релиза vs до — здесь всегда есть над чем посмеяться и задуматься.
✍️ Дедлайны, на которые подписались абсолютно все… Если такое было — команда получает +10 к карме! А если еще и смежным командам было ок, это какие-то единороги.
🔥 Количество историй, переписанных после демо PO — "индекс выгорания продакта".
✋ Число креативных ICE-breakers подряд на ретро (иногда с этим очень перебарщивают).

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

Они отлично подходят для ретро, помогают снять напряжение и поднять важные темы, но не должны становиться самоцелью или поводом для токсичности. Главное не вести по ним отчетность :)

❓ У вас был опыт с какой-нибудь упоротой метрикой?)

Часть третья про Lead Time (база тут, про связь cycle time+lead time+time to market тут). Обсудим кластеризацию типов работы, динамику, гистограммы и диаграммы рассеивания, end 2 end.

Дорогой друг, давай прям на практике пройдёмся по показателям:
- Открываем в хроме https://predictable.team, нажимаем на Try with Demo Data, и кликаем на вкладку Lead Time. На графике Scatteplot показывается, за какое время завершается 50% задач (median), а за какое 85%.

🏄‍♂️ В Lead Time динамика всегда важнее текущего состояния

Один раз замерить lead/cycle time полезно. Но если хочешь реально улучшать показатели надо смотреть в динамике на типы работы (прямо как в throughput).

🎳 Кластеризуй Lead Time по типам работы (потому что они все разные)

На практике, чаще показывают гистограмму Lead Time. Но мне субъективно кажется что в ней не хватает временной динамики, поэтому я люблю диаграмму рассеивания (scatterplot, control chart в Jira).

- Баги — обычно устраняются быстрее (у них часто самые короткие lead time).
- Полноценные end-2-end стори — куда длиннее, иногда с кучей согласований.
- Инциденты — вообще особый поток, SLA, жёсткое реагирование.

Посему смотрим на динамику в два шага:

1. Общая динамика (вкладка Lead Time)
2. Динамика по классам задач. Для этого в верхнем меню можно менять набор "Issue Types".

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

🧩 Цикл твоей команды ≠ end-to-end всего потока ценности.

Оптимизировал поток своей команды вместе с ребятами, далаете свои задачи быстрее? Молодцы, но зачастую на всем end-2-end потоке работы ваша оптимизация будет локальной (то есть расширить самые медленные бутылочные горлышки и простои в сквозной системе всегда будет эффективнее, чем оптимизировать какую-то только подконтрольную вам часть).

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

#leadtime #cycletime #timetomarket #метрики #metrics #flowmetrics

👀️️️️️️ Друзья, делюсь планом контента с отпускными фото из Приэльбрусья ❤️🏔

- Посты про метрики были подготовкой к нашему митапу @agileufa в воскресенье. Уже 70 человек зарегистрировалось! Планирую завершить темы Lead Time, Aging и закон Литтла к концу недели.

- Хочу реже публиковать посты (раз в неделю) и больше обсуждать оргизменения, исследования и прогнозирования. Проголосуем?
- 👍 за посты реже
- 🔥 и так норм частота

- Метрики важны как база, в том числе чтоб делать разбор в моем инструменте прогнозирования: https://predictable.team

- Есть темы (кейсы / советы / обзоры), которые интересно было бы обсудить?

🚦Time to Market, Lead Time, Cycle Time и почему они про одно и то же?

Расставим точки над "i" после вчерашних дискуссий в @agileufa с Сережей (организатором @UfaJS)

🏗 Базовый термин времени производства: Cycle Time. Это супер-простая идея: выбери любую пару точек на процессе (начало и конец) и посчитай, сколько времени проходит между ними. Главное, после слов Cycle Time указать начало и конец цикла.

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

🧱 Как это работает на практике:

В IT и продуктовых командах часто под термином Cycle Time подразумевают время от момента, когда задача переходит в состояние “В работе”, до момента “Готово”. Это отражает длительность всех активных действий по задаче, исключая время, когда она находилась в бэклоге.

✅ Чтобы быть более точным, стоит обозначать этот показатель как Cycle Time (In Progress -> Closed), а не просто Cycle Time.

Какие еще циклы бывают?
- От “Идея!” до “Go Live” — Time to Market (общая скорость реакции компании на рыночные изменения).
- От “Будет сделано” до “В проде!” — Lead Time (качество планирования и уровень доверия клиентов).

❓ Зачем нам все это?

Если Time to Market, Lead Time не соответствуют нашим ожиданиям, то конкретные циклы внутри них (In Progress -> Closed, а может еще глубже: отдельно цикл Code Review / Ready for Testing / Testing) подсвечивают узкие места. Это наш базовый инструмент диагностики для понимания затыков в работе.

Что для нас по-настоящему важно: скорость вывода фичи на рынок, ведь это наша конкурентоспособность (будь мы внутренним продуктом/платформой или публичной компанией).

А еще большинство времени фича вообще ждет реализации в беклоге. Принимая решения на основе данных (время в беклоге или цикл Created -> Committed) мы можем существенно оптимизировать и балансировать наш поток работы.

🍰 TLDR

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

⚠️ Очень важно, что Time to Market (а зачастую и Lead Time, и Cycle Time (In Progress -> Done) и мы все таки считаем у фичей (новый функционал приносящий ценность), а не у рядовых задач, которые делает кусочек нового функционала.

#timetomarket #cycletime #leadtime #metrics

Всем привет! Сегодня продолжим покрывать основные метрики потока.

⏰ Lead Time (1/2): погружающий в базу пост.

Опять возьмем суши-бар в качестве примера. Опять приходим в пятницу и заказываем хенд-ролл с тунцом. Точкой отсчета мы считаем Commitment Point (когда ресторан берет на себя обязательство сделать нам хендролл - то есть время приёма заказа).

🍣 Так вот, Lead Time — в классическом понимании это время с момента заказа до момента, когда тебе подали заслуженную пищу богов после лютой рабочей недели. Всё, что тебе важно как клиенту, — когда эта еда окажется во рту и ты закроешь глаза от удовольствия.

👨‍💻В разработке то же самое: коммитмент сделан (пообещали что возьмете в работу) → взята в работу → разработана → протестирована → выкачена в продакшен → пользователь получает ценность. Иногда можно упростить до времени создания тикета, но тут надо быть осторожным и понимать где действительно начинаются ваши обязательства, и где вы ведете Discovery backlog.

💎Почему Lead Time одна из главных метрик потока?

- Это главный ориентир и для клиента ("когда будет готово?"), и для бизнеса (можно ли обещать релиз/фичу).
- По Lead Time видно, насколько реально наша команда быстрая (а не “про субъективную скорость”).

❓ А что и как считать-то?

Вот набралась у тебя статистика по времени завершения роллов / задач / чего угодно.
Когда задают вопрос про Lead Time, многие просто отвечают про “среднее время”.

❌Так вот, среднее в целом очень плохой показатель для анализа (например книжка Flaw of Averages). Среднее очень сильно подвержено выбросам данных, и не отражает реалий.

✅ Настоящие котаны и котанессы смотрят на перцентили вместо среднего. Нам для наглядности надо 50p, 85p, 95p.

- Для простоты - за какое время завершается 50% работы (50p или медиана), 85% работы (85p), 95% работы:
- 50p (медиана) показывает типичную работу. Например, мы можем стараться планировать на основе данных медианы.
- А вот 85p, 95p показывают не только “обычные” случаи, но и экстремальные ожидания.

💼 Примеры:

- "Среднее" время ожидания в суши-баре — 20 минут, но половина получает заказ за 10 минут, а часть ждёт по 40-50.
- Медиана (50p) покажет типичное время (10 минут), а 85p — насколько быстро обслуживают почти всех (40 минут). Это честнее и точнее — клиент меньше разочарован и команда видит, где реальные задержки.)

🏆 Самое главное для нас:

- Чем ближе 50p и 85p - тем вы предсказуемее.
- 85p не должен превышать 50p (медиану) в 3 раза. Но.. везде есть свои приколы и специфика домена.

🧩 Паттерны

- Если 85p намного больше медианы (пример во второй картинке присобаченной)— у вас есть “зависшие” задачи или бутылочные горлышки.
- Если 95p намного больше / выше чем 85p - есть какие-то супер специфические зависшие или зависимые от других команд задачи.

#leadtime #metrics