OnAgile Learning Hub 💎

Выложили пять промптов для чат-ботов, которые помогают найти, где команда теряет время, конкретные цифры: сколько часов уходит на context switching, где застревают задачи, когда реально закончатся задачи спринта.Взяли типовые боли тимлидов и для каждой сделали готовый промпт. Можно скопировать, подставить свои данные о задачах за последние спринты, и получить таблицы и графики с рекомендациями.Например, первый промпт считает Lead Time и Cycle Time по задачам, показывает где bottleneck. Команда видит: в Code Review задачи висят по 3 дня, а в разработке проходят за день. Сразу понятно, что делать.Второй промпт переводит прерывания в деньги. Сколько story points команда теряет, когда разработчиков дёргают с вопросами. Получается презентация для стейкхолдеров с обоснованием "тихих часов".Третий считает ROI от устранения узких мест. Четвёртый прогнозирует сроки по методу Монте-Карло, чтобы не обещать продакт-оунеру невозможное. Пятый помогает управлять зависимостями между командами.(Запросы основаны на Value Stream Mapping, Cost of Delay, Critical Path Method, но это уже детали)Все промпты на странице: onagile.ru/trends/ai/prompty-produktivnost-komandyБерите, пробуйте на своих данных.

Спросил у давних клиентов о результатах использования AI для написания кода. У них кстати полностью локальные модель и coding agents.Интересно было узнать, как они оценивают экономию времени и справляется ли архитектура с быстрым ростом объема кода.Ответ оказался неожиданным:)Первые недели ощущаются как взлёт. За пару вечеров получается рабочий прототип вместо недели. Но потом наступает "ИИ-похмелье".Когда один разработчик начинает генерировать 10-20 PR за вечер, в системе начинают одновременно трогать разные слои. Код расползается, дублируются решения, размывается ownership компонентов. Поток изменений в команде из 5+ человек становится трудно отследить.Интересно, что здесь не столько проблема AI, сколько переход на другой подход к разработке. Нужны договоренности внутри команды, например: • Каждый разработчик по-прежнему отвечает головой за каждую строку кода• Мы никогда не делаем auto-accept генерированного кода• Мы всегда проверяем написанный код с учетом изменений (не только новые фичи, но и архитектура, рефакторинг) в общей ветке.• и тп.И конечно, инфраструктура разработки должна эволюционировать. Нужны агенты, которые будут в realtime делать код-ревью, анализировать влияние изменений и необходимость архитектурных изменений, анализировать влияние изменений в контексте всей кодовой базы (то, что приносит основную боль в классический энтерпрайз разработке).Главное всегда помнить, что лучше меньше кода, но более качественно спроектированного и написанного чисто.

Недавно видели в одной компании чудесное: руководитель попросил разработчика оценить задачу, тот молча спросил у ChatGPT и ответил ровно то, что бот написал. Слово в слово.С одной стороны, ну что это вообще такое. С другой, давайте честно, кто из нас когда-либо давал точные оценки? Оценки в разработке это такой коллективный ритуал, где все понимают, что цифры условные, но продолжают их запрашивать.Так что, может, бот даже честнее. Он хотя бы не притворяется, что знает.А если серьёзно, лучшая замена оценкам это ежедневная поставка в прод. Когда задачи маленькие и летят каждый день, вопрос «сколько займёт» просто теряет смысл.У вас оценки ещё живы или уже перешли на что-то другое?​​​​​​​​​​​​​​​​

Сертифицированный Agile-практик: Scrum, Kanban, продуктовые команды и AI28-30 января проводим трёхдневный интенсив, где разбираем, как организовать работу команды, чтобы она выдавала результат, а не буксовала в хаосе.Что будем делать:🎯 Учиться управлять потоком задач — разбирем Kanban-метод, поработаем с метриками Lead Time и Cycle Time, научимся находить узкие места в процессах. И не забудем про Scrum.📊 Освоим принятие решений на данных — используем фреймворк Cynefin для анализа ситуаций и выбора правильного подхода. Плюс AI-инструменты для анализа и прогнозирования.⚙️ Настроим командную работу — от постановки целей (OKR) и проверки гипотез до техник оценки задач и эффективных ретроспектив. Разберем, что делает группу людей командой, а не просто набором исполнителей.🔧 Поработаем с бэклогом и приоритетами — методы декомпозиции, приоритизации, актуализации задач. Как сделать так, чтобы команда всегда знала, что делать дальше.🤖 Интегрируем AI в процессы — разберем конкретные варианты автоматизации процессной рутины и использования AI для поддержки принятия решений.По итогам вы получите международный сертификат ICAgile Certified Professional (ICP) — подтверждающий ваши управленческие компетенции.Тренинг для тех, кто руководит командами, проектами или просто устал от того, что процессы не работают так, как должны.Программа и регистрация, не пропустите!

Один из наших самых насыщенных тренингов для руководителей проектов. Проводим сегодня для финтех компании, очень активные обсуждения, десятки вопросов, а день только начался! 🧑‍🎓👩‍🎓

⚡️Вебинар: Ошибки, которые снижают вашу продуктивность в ScrumСколько раз вы замечали, что спринт идет не по плану, бизнес недоволен сроками, а команда выгорает? Чаще всего проблема — в скрытых ошибках процесса.🗓 22 сентября в 17:00 (Мск) приглашаем на разбор системных ошибкок, из-за которых команды, работающие по Scrum, не достигают целевой эффективности.Обсудим:• Прогнозирование: как повысить точность оценки сроков.• Фокус: как работать с задачами, которые постоянно добавляют в спринт.• Поддержка: как меняется работа Скрам-мастера на разных этапах жизни команды.• Метрики: какие ключевые метрики важны для стейкхолдера, Владельца продукта и Скрам-мастера.➡️ Регистрация

Шаблон для GTM стратегии.Привет! Если вы запускаете новые продукты, будет полезно - мы подготовили интерактивный шаблон формирования go-to-market стратегии.Он кастомизирован под конкретную продуктовую задачу (подсказки заточены под b2b маркетплейс), однако в целом структура шаблона универсальна и подойдет любому продукту.Будем рады обратной связи!https://onagile.ru/tools/gtm-strategy-canvas

Пока мы обсуждаем, стоит ли доверять ChatGPT корпоративные данные, ребята из Alibaba тихо выложили в открытый доступ модель Qwen3, которая по многим параметрам превосходит GPT-4o.И самое крутое - её можно совершенно бесплатно развернуть у себя в компании.Никаких утечек данных, никаких переживаний за конфиденциальность.Qwen3 умеет работать с документами объемом до 256 тысяч токенов (это примерно 500-600 страниц обычного текста). Представьте, что вы можете загрузить в неё целый договор со всеми приложениями, техническое задание на проект или отчет - и получить любой анализ за секунды.А еще модель отлично работает с инструментами и может строить AI-агентов. То есть, можно научить её работать с вашими внутренними системами - CRM, ERP, базами данных.Знаю компанию, которая за выходные подключила такую модель к своей системе управления проектами. Теперь любой сотрудник может спросить "Какие задачи просрочены в проекте А?" или "Сколько часов потратил Иванов на разработку в этом месяце?" - и получить точный ответ.Единственный нюанс - для полноценной работы нужны серверы с хорошими видеокартами. Но если у компании есть своя IT-инфраструктура, то настроить можно довольно быстро.Такие технологии дают возможность любой компании получить собственного "ChatGPT", который знает ваши процессы и работает только с вашими данными.Если интересно обсудить, как это работает на практике и какие задачи можно закрыть в вашей компании - пишите в direct.

Почему спринты и дейли не делают команду настоящей Scrum-командой.Многие команды проводят спринты и стендапы, но так и не получают результат от применения Scrum. Разбираемся, почему поверхностное внедрение гибких методик не работает и как правильное обучение Scrum меняет всё.https://onagile.ru/trends/agile/obuchenie-scrum-komand-vnedrenie

«Если ты хочешь построить корабль, не надо созывать людей, планировать, делить работу, доставать инструменты. Надо заразить людей стремлением к бесконечному морю. Тогда они сами построят корабль…»— Антуан де Сент-Экзюпери.

Пытаться всё распланировать — не всегда эффективно🗓Иногда хочется собрать в один список все проекты, просьбы и операционные процессы, которые никогда не заканчиваются — и навести порядок. Но если так сделать, то получится громоздкий список, в котором сложно даже сориентироваться, не то что работать.• Уточнить бюджет по проекту• Подготовить презентацию• Согласовать KPI новой команды• Обновить отчётность за квартал• Провести собеседование на вакансию аналитика• ...А уже завтра появятся новые вводные, и старый план станет неактуален. То же самое касается и проектной работы — при первых же изменениях приходится корректировать план.На старте проекта не обязательно знать всё, важно понимать ближайшие шаги. Остальное — будет видно по ходу.📒 29-31 июля на тренинге Профессиональный сертификационный тренинг по Agile и Scrum мы поговорим о том, как эффективно управлять проектами и командами в условиях постоянных изменений.

Спасибо за ваши ответы 🍂Вот как можно поступить в такой ситуации:🗣Признать, что задача важная, но без обещаний. 🗣Уточнить, что если взяться за неё прямо сейчас, можно не успеть к текущему релизу.🗣Предложить компромисс и зафиксировать суть задачи, собрать минимальные требования и подготовить её к следующему спринту. В идеале такое решение должен принимать Product Owner — он определяет приоритеты и решает, что можно успеть в рамках спринта.

🗣 Как мягко отстаивать свою точку зренияСередина спринта, команда внедряет новый внутренний сервис. И вдруг в чат приходит сообщение от Product Owner’а:Коллеги, директор продуктового направления срочно просит добавить интеграцию с голосовым ассистентом — фича нужна к презентации на совете директоров. Не можем отложить. Понимаю, что это неожиданно, но он настаивает. Что думаете?Такой задачи нет в бэклоге, даже собрать требования до конца недели вряд ли получится. Если сейчас согласиться взять её в работу, есть риск не успеть даже то, что уже запланировано. А если отказаться — может начаться конфликт.PO явно ждёт согласия — ему самому не хочется говорить «нет», особенно публично.❤️Как бы вы поступили, если бы пришлось мягко отказать, чтобы при этом не испортить отношения с руководством?

📼 Продолжаем делиться короткими видео о масштабируемых фреймворкахСегодня, опираясь на таблицу из нашего руководства, расскажем о неочевидных вариантах, как можно организовать работу нескольких Agile-команд — Kanban на масштабе и Модели, адаптированные под компанию.⏱ 23-25 июля разберём, как организовать совместную работу нескольких команд над одним проектом, синхронизироваться и отслеживать эффективность с помощью SAFe, LeSS и Flight Levels.Присоединиться к тренингу Фреймворки масштабирования Agile и скачать руководство по выбору и запуску масштабируемого Agile-фреймворка можно на сайте тренинга.

Что если просто раздать всем Scrum-гайд?И ждать, что команды сами как-то начнут двигаться к общей цели? Если бы всё было так просто.Допустим, одна команда смогла взять на себя ответственность, научилась находить решения, и понимает, зачем делает ту или иную задачу, — но это не значит, что у другой получится так же.Можно скопировать ритуалы, завести те же доски, даже говорить те же фразы на встречах. Но если внутри команды нет доверия, прозрачности и самоорганизации, то и результата не будет.Как выстраивать взаимодействие между командами с разным уровнем зрелости?📹 Рассказываем том, как масштабировать Agile на несколько команд с помощью Flight Levels и Nexus.