Marat @ Predictable.Team

🤯 Фасилитация: Как избежать ступора на сложной теме (на примере воркшопа по Context Engineering)

Это последний пост про Context Engineering. Зачем он нам | Техники работы с контекстом | шпаргалка: когда что применять / План фасилитации воркшопа по теме

Сами видите — тема непростая. Context Engineering может легко превратиться в абстрактную лекцию. Вот и мы хотели, чтобы 50 человек не застопорились, а вместе проработали "агентизацию" бизнес-процессов.

Условия: небольшая аудитория, кондиционер не справлялся. Чтобы никто не помер:

- один из нас (нас было трое: я как фасилитатор и два технических руководителя) придерживал дверь.
- Убедились, что у всех есть вода.

На подготовку ушло ~5 часов.

📚 План фасилитации

0. Знакомство (5 минут)

Попросили ребят представиться: кто ты, отдел, любимое место для отпуска. Не просто Ice Breaker — Чеховское ружьё. Позже участники объединились по смежным процессам благодаря этому знакомству.

1. Галопом по теории (45 минут)

Лекция про: Context Engineering, инструменты, техники.
Чтоб было чуть легче аудитории слушали микро-активность: в середине доклада участники выписали на стикерах источники контекста из их работы (кодовая база, API, CRM). Это перевело теорию в их рабочий контекст.

2. Демо от CTO (10 минут)

Один из технических руководителей (CTO) показал чатбот, который отвечал на вопросы о сервисах, забирая данные из репозитория, справочника процессов и орг-структуры.Это отлично помогло показать практический Профит.

3. Выбор кейса (10 минут)

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

Дали ребятам 10 минут обсудить, какой кейс хотят обогатить контекстом для автоматизации.

4. Практика "Франкенштейн" (45 минут)

Главная фишка — физическое взаимодействие:

1. Декомпозиция процесса на 3-5 шагов на флипчарте
2. Раздали А4 с распечатанными стикерами для вырезания: "RAG", "Vector DB", "Sandbox" и т.д.
3. Задача — наклеить стикер на нужный шаг

🎨 Вырезание и наклейка превратили архитектуру в детскую аппликацию. Участники спорили, двигали стикеры, визуализировали руками. Никто не мог "отсидеться". Даже в жаре это держало энергию на высоте.

5. Презентация с экономикой (30 минут)

Обязательное условие: "Какой экономический эффект? 2-3 метрики". Это сдвинуло фокус с технологий на бизнес-ценность и потенциально показало сколько мы как организация можем сэкономить, обогатив контекст для AI-агента при автоматизации.

🏆 Итог: участники ушли с конкретными наработками про автоматизацию с обращением контекста, защищёнными через призму бизнес-выгоды.

🤝 Формат со стикерами - тема (и весело).

Наш NPS: 93.

⁉️А вы делали какую-нибудь фасилитацию, где надо было задействовать мелкую моторику и аппликацию? Как народ это воспринял?

✍️Шпаргалка по Context Engineering (3/3)

Предыдущий пост был сложный. Давайте коротко и просто пройдемся по рецептам - что и когда применять.

По дефолту подключайте контекст к агенту напрямую. Большинство задач по-прежнему эффективно решаются связкой RAG + качественная очистка данных.

Если у вас ...

Объём данных:

- Огромный или постоянно обновляемый? → RAG. Даже с окнами в миллионы токенов, RAG экономичнее и точнее для работы с внешними знаниями.​
- До 100K-200K токенов? → Прямое включение в контекст, если данные не требуют постоянных обновлений.

Динамичность данных:

- Нужны данные в реальном времени? → Function Calling.
- Данные статичны? → Vector DB (RAG).

Сложность задачи:

- Многоэтапный, нелинейный процесс? → Multi-Agent Systems.
- Простой, линейный процесс? → Function Calling или RAG.

Требования к качеству:

- Критична точность и важны скрытые связи? → GraphRAG.
- Есть противоречивые или устаревшие данные? → Compression с фильтрацией.

Продолжительность сессии:

- Долгая, многочасовая работа? → State Checkpoints + Summarization.
- Короткая сессия (минуты)? → Semantic Caching.

Что потыкать из тулинга:

Для векторного поиска: Milvus (мощный и open-source) или Pinecone (заводится с полпинка).​

Для графов и связей: Neo4j GraphRAG.​

Для построения агентов: LangGraph (погибче) или CrewAI (попроще).​

Для управления памятью: Zep (enterprise-ready).​

Context Engineering (2/3): Выжимка техник для работы с контекстом в LLM-системах 🛠

Итак, мы с вами натыкали бизнес процесс и поняли какой у нас есть разные источники информации, которые можно кормить агенту и что-то полезное от него в ответ получать. Для этого надо уложиться примерно в 170к токенов - чтобы агент мог нормально работать с контекстом.

В этом нам помогут 4 ключевые техники работы с контекстом для агента- и инструменты на вооружении этих техник (их десятки, тут только топ) - чтобы правильно готовить этот контекст:

📝 ЗАПИСЬ (Write)
Сохранение и управление состоянием для долгих и сложных задач.

- Scratchpad: Временная зона для промежуточных рассуждений, заметок и шагов chain-of-thought, чтобы структурировать мышление агента без перегрузки основного контекста. (Инструменты: Встроенные в LangGraph/LangChain, кастомные промпты в LLM, Redis для персистентных заметок).

- Semantic Caching: Кэширование ответов на семантически близкие запросы для ускорения и удешевления. (Инструменты: Redis, кастомные решения на файлах).

- State Checkpoints: Снимки состояния для возобновляемых, отказоустойчивых сессий. (Инструменты: PostgreSQL, Zep, встроенная персистентность в LangGraph).

- Long-term Memory: Долгосрочное хранение фактов и предпочтений для персонализации. (Инструменты: Pinecone, Neo4j).

📖 ЧТЕНИЕ (Select)
Точное извлечение релевантной информации — основа качественных ответов.

- RAG (Retrieval-Augmented Generation): Тут надо смотреть на схему, но в самом простом варианте это Векторный поиск по большим базам знаний (предварительно chunking + embedding). Остается стандартом де-факто, несмотря на рост контекстных окон, из-за экономичности и точности. (Инструменты: Milvus, Weaviate, Pinecone).​
@AigizK - большой специалист (колонка Homai + MLOps) тут ещё прояснил про RAG в комменте.

- Hybrid RAG: Комбинация векторного (семантического) и лексического (по ключевым словам) поиска для максимальной релевантности. (Инструменты: Elasticsearch, Weaviate).

- Function Calling: Динамическое получение данных из внешних API в реальном времени. (Инструменты: OpenAI Function Calling, аналоги в других моделях).​

- GraphRAG: Поиск по связям в графовых базах данных. Ключевой тренд 2025 года для задач, где важны сложные взаимосвязи, а не только семантическая близость. (Инструменты: Neo4j + embeddings).​

🗜 СЖАТИЕ (Compress)
Оптимизация контекста для экономии токенов и ускорения работы.

- Summarization: Суммаризация диалогов или документов через LLM для передачи ключевой сути.

- Contextual Compression: Автоматическая фильтрация нерелевантных частей извлеченных документов перед отправкой в LLM.​

- Entity-Centric: Сжатие контекста до ключевых сущностей и их связей, часто с использованием NER (Named Entity Recognition).​

🔒 ИЗОЛЯЦИЯ (Isolate)
Разделение задач между специализированными компонентами — главный вектор развития сложных систем.

- Multi-Agent Systems: Декомпозиция сложной задачи на роли (агенты), где каждый выполняет свою часть работы. Это позволяет решать нелинейные и комплексные проблемы. (Фреймворки: LangGraph, CrewAI).​

- Sandbox: Изолированная среда для безопасного выполнения кода или работы с чувствительными данными. (Инструменты: Docker, E2B).

- State Management: Управление состоянием и переходами в сложных, многошаговых сценариях. (Инструменты: XState).

#ContextEngineering #AITools #RAG #AIAgents #LangGraph #GraphRAG #LLM

🤖 Хотите чтоб ваш AI-агент отвечал на вопросы по требованиям из Confluence / коду из репозитория?
Без Context Engineering каши не сваришь? (1 пост из 4)

В прошлый четверг коллегами провели воркшоп на 50 IT-руководителей по Context Engineering и разобрали почему промпт-инжениринга не хватает от слова совсем. Дальше ещё напишу про сам воркшоп и техники работы с информацией.

🤌🏽 Суть проблемы:

Сегодня дело не в том, КАК спросить у AI, а в том, ЧТО (какие источники информации и данные) дать ему как контекст. Потому что всю вашу предметную область, документацию и тонну чувствительных данных вы в промпт не впихнете).

💻 Представьте контекстное окно как оперативки (RAM) — ограниченную рабочую память.

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

🍄Все это выливается в галлюцинации LLM / агента по следующей классификации:
- Context Rot — "испортившиеся" (устаревшие, подпорченные) данные
- Context Poisoning — одна или несколько ошибок портит весь остальной контекст
- Context Clash — противоречия в контексте из-за противоречий в источниках
- Context Overflow — слишком много информации

🍳 Чтоб такого не было, надо уметь "готовить" - информацию с помощью техник Записи, Чтения, Сжатия и Изоляции контекста. У каждой техники есть свои инструменты. И паттерны того, когда что использовать надо знать.

⁉️ Почему это критично:

Еще в Metamap мы силами нашего отдела (Technical Program Management) запускали квартальный цикл совместного планирования > пристрелки в середине квартала по > обзора результатов и метрик выпущенных фич и статуса по целям. Это был один из самых сильных инструментов выстраивания совместной работы на наши 500 членов команды, раскиданых по земному шару.

Работа на уровне отдельных команд не даёт системной картины. Квартальное выравнивание руководителей позволяет предвосхитить проблемы и действовать на опережение.

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

Анализ состояния целей в подобном событии это всего лишь пререквизит.
Он погружает коллег в контекст текущего состояния (as is) и задает тон тому, как нам надо адаптироваться к новой реальности (to be). А мы, как оркестраторы события, добавляем активности которые помогут выработать единый вектор движения к целевому состоянию (how).

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

🤘Задротская аналогия: у группы Meshuggah (это такой шведский экстрим метал) в композициях часто каждый инструмент играет свою партию в своём размере. Но в определенных точках музыканты сходятся и размер на коротком периоде совпадает. Вот квартальное планирование, это как раз такой период где все выравниваются и вновь начинают новый раунд.

Очень плотные две недели перед отпуском. Поздние рейсы, ночные посиделки с презентациями, last minute changes.

📣 Во вторник проводил с коллегами «Квартальную встречу» для руководителей 20 команд (60 человек) в нашем периметре.

TL;DR в один абзац:

Квартальные встречи менеджмента для подведения промежуточных итогов - это один из наиболее эффективных форматов запуска изменений и оптимизации работы. При условии что мы фасилитируем это правильно: подсвечиваем взаимозависимости, запускаем правильные диалоги. И это точно лучший способ внедрения культуры непрерывных улучшений.

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

🚦 Что делаем на ивенте:

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

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

Мы с автором плагина ещё в 2012-2015 работали в месте в небезызвестной конторе в Уфе - Frumatic. Сейчас я в Райфе а Анвар в HH.ru, и вновь сошлись на почве работы с метриками.

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

Если вы пользуетесь плагином, то вот пара полезных ссылок:
- @JiraMetricsPro - канал плагина на русском языке
- @akhakimov - канал Анвара про работу Lead Project Manager’а, метрики и вызовы
- @JiraMetrics - чат и поддержка плагина

Встречайте Марата Киньябулатова — нового члена команды JiraMetrics.Pro.

Марат — эксперт по flow-метрикам и предсказуемости, автор практических гайдов по метрикам и активный участник agile-сообщества. За его плечами — руководство PMO в MetaMap (InCode), развитие сообщества Agile Ufa, работа с ядром банковских сервисов в системно-значимом финтехе на периметре 45 команд.

Что особенно важно — он давно сам пользуется JiraMetrics.Pro и знает плагин изнутри. На недавнем демо для канбан-тренеров Марат показал все возможности инструмента, поделился лучшими практиками использования и примерами, как метрики помогают командам работать предсказуемее и понятнее.

И это только начало. Мы планируем регулярно проводить демо и воркшопы, чтобы превращать данные в понятные шаги и реальный результат.

👉 Подписывайтесь, чтобы быть в курсе следующих встреч.

🔥 Motivation30.com - Выбери тип мотивации сотрудника -> получи персональный план с готовыми инструкциями

или как из идеи сделать интерактивную лекцию родился прототип "Motivation 3.0 - конструктора мотивации".

Не люблю читать лекции. Люблю, когда ребята сами осваивают и рефлексируют над материалом. На прошлой неделе готовился читать небольшой докладик по нематериальной мотивации и подумал: «А что если дополнить презентацию интерактивом?»

🗿 Презентация была основана на "Теории Самодетерминации":
- 3 основных кита мотивации: Автономность, Компетентность, Связанность.
- 2 фактора нематериальной мотивации: внутренние или внешние.
- Факторы также можно делить по скорости эффекта: быстрые, отложенные, долгосрочные.

🧑‍💻 За полчаса накидал прототип в Loveable (мой фаворит среди вайб-кодинг инструментов) — простой конструктор мотивационных практик. Для пилотирования пообстукивал об ребят в Ufa IT Coworking.

На практической части поделил руководителей на мини-группы и оставил на полчаса обсуждать практики и делать планы повышения мотивации исходя из заданных кейсов. По итогу ребятам очень зашла практика, на дебрифе попросили: «Дай ссылку, будем пользоваться!».

✅ Ссылку-preview давать негоже, посему на выходных допилил:
- Добавил полноценные практики ко всем 9 факторам мотивации,
- Прикрутил ссылки на курсы и статьи,
- Купил домен с SSL (шоб солидно и секурно).
- Добавил экспорт планов в md / txt.

⌛ Сделано за пару часов:
30 минут на прототип (буквально с телефона перед сном) + 2,5 часа на продукт + 1,5 часа на изучение литературы = работающий инструмент, который просят сохранить.

Короче лень и интерактив - двигатель прогресса

*Тут есть приписка, что все таки я работаю с мотивацией персонала с 2015 года, поэтому нельзя говорить что я с нуля изучил тему.

Мы провели демо JiraMetrics.Pro для сообщества Канбан Стандарт — экспертов, которые делают канбан-метод понятнее и доступнее для индустрии.

Это была не просто демонстрация. Мы получили ценный фидбэк и поддержку от людей, чья экспертиза формирует практику канбан-метода в России и СНГ. Такая обратная связь помогает нам делать продукт ещё понятнее, полезнее и ближе к задачам команд.

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

Отдельная благодарность Алексею Пименову за организацию этого созвона 🤝

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

😎 Похвастаюсь: мы тут с Анваром (автором Jira Metrics) на прошлой неделе провели демо с элементами воркшопа для тренеров Канбан-Стандарта (neogenda / Лёша Пименов) по возможностям плагина и анализу команд 💪

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

Очень круто видеть живой интерес в глазах людей, желание вместе "вваливать" своё время чтобы дополнить документацию и гайды по оптимизации. В ближайшее время я проведу подобное еще и в @AgileUfa и аудитории канала. Даешь data-driven подход в работе с командами!

💎WIP Aging — самая важная метрика потока

🪦 Посмотрите реальный пример на скриншоте выше - там состарилась целая свора задач, какие-то явно протухли.

WIP (work in progress) Aging — это количество времени, которое задача уже провела в работе, но еще не завершена. Помогает понять, где работа "застревает" в процессе и сигнализирует о рисках для потока.
Мы считаем начало "в работе" как точку, когда вы втягиваете в свою систему работу (у разных команд она может разная).

📈 Где посмотреть:

- Jira Metrics Plugin - бесплатное расширение для хрома, которое показывает Aging Chart (скрин оттуда)
- Predictable.Team - анализатор выгрузок из Youtrack / Jira, есть визуализация Aging

👆 Почему это важно?

- Чем дольше задача "стареет" в потоке, тем выше риск, что она устареет для бизнеса, попадёт в зависимости, или просто потеряется ценность работы.
- Следить за Aging надо до завершения задачи - ваш шанс оперативно реагировать на проблемы в процессе, а не ждать, когда цикл завершится и станет "слишком поздно" для улучшений.
- Всё в Kanban — визуализация, блокировки, Pull-политики — заточено на то, чтобы не позволять задачам стареть без необходимости.

🕸 Какие основные паттерны Aging встречаются в практике?

- Стабильный рост: WIP Aging растёт равномерно — признак стабильного процесса и правильных WIP-лимитов.
- Плато или затор: Aging резко увеличивается на каком-то этапе — вероятен bottleneck или проблемы формата слишком крупных задач.
- Волнообразные скачки: Aging периодически ускоряется — возможны внешние зависимости/нестабильность команды.
- Разделение на мелкие задачи: Когда Aging сигнализирует о "застрявшей" задаче, best practice — разделить её на более мелкие части.
- Экспоненциальный рост: Очевидная перегрузка WIP — новые задачи начинают быстрее, чем завершаются старые.

Tips & Tricks:

- WIP Aging — один из лучших ранних индикаторов проблем (если выбирать одну метрику, то Aging — самая полезная для начала).
- Комбинируйте её с Lead Time и Throughput, чтобы видеть общую картину. Lead Time = ваш исторический SLA, а Aging - возможность увидеть в realtime что сейчас пробьёт SLA.
- При превышении допустимого возраста задачи — обсуждайте и разбивайте крупные работы. Например, начинайте разбирать все, что выше 85-перцентили.
- Правильно используйте WIP-лимиты: лимит не спасёт, если не анализировать aging, а просто "сжимать поток".

📝 Хотите большую большущую детальную статью про Aging?
- На VC недавно вышла статья про опережающий индикатор: WIP Aging от Васи Савунова.

📈 Где посмотреть:
- Jira Metrics Plugin - бесплатное расширение для хрома, которое показывает Aging Chart (скрин оттуда)
- Predictable.Team - анализатор выгрузок из Youtrack / Jira, есть визуализация Aging

#aging #flowmetrics

Вот вам мемчик в тему 👆

Если на прошлой неделе я ресерчил - какие китайские альтернативы Nvidia скоро появятся. То на этой - а сколько ведущие страны-производители полупроводников вкладывают (государственных и частных денег) в ИИ-железки. И сравнил с Россией.

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

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

Как правильно прогнозировать, когда команда закончит следующие X задач и причем тут прогнозирование через симуляцию Монте-Карло?

❌ Точную дату говорить не надо "Эпик будет готов ровно через 42 дня" — это неправда.
✅ Правильный прогноз: 10 задач за 35-45 календарных дней, где:
- 35 дней = 50% вероятности
- 45 дней = 85% вероятности

У любого прогноза есть
- Разброс,
- Вероятность,
- Мы предполагаем что работа в будущем будет похожа на работу в прошлом.

Работает следующим образом:

- 1️⃣ Собираем историю throughput команды
- 2️⃣ Запускаем 1000+ симуляций со случайной выборкой
- 3️⃣ Получаем распределение вероятностей

Главное условие: нужны WIP-лимиты!
"Нет WIP-лимита = нет потока = нет предсказуемости" — Daniel Vacanti

👩‍🔬 Исследования и материалы:

- 🖥 На прикрепленной картинке пример прогноза из приложения: Predictable.team (я когда-нибудь переведу его на русский) — загружаете CSV из Jira (или demo data) и тыкаете во вкладку Монте-Карло.

- ActionableAgile доказали: простая случайная выборка работает лучше сложных алгоритмов.
- Российские кейсы (Тинькофф, SportMaster) подтверждают точность 80-90%.
- Daniel Vacanti "Actionable Agile Metrics".
- Моя статья на Хабре
- Материалы на Scrum.ru, Neogenda.

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