Agile-сoach Notes – Telegram
Agile-сoach Notes
2.27K subscribers
839 photos
25 videos
60 files
1.04K links
Канал создан в 2018 году. Здесь бывает реклама. Больше интересного контента без рекламы на канале моей компании - 2023 год: @proleaderslab
Download Telegram
В марте 2025 года вышло исследование McKinsey "The State of AI: How Organizations Are Rewiring to Capture Value"

С полным отчётом вы можете ознакомиться по ссылке.
Ниже наш ИИ подготовил для вас краткие выводы по результатам анализа отчёта.

🤩 Использование ИИ растет

🤩78% компаний применяют ИИ хотя бы в одной бизнес-функции (в 2023 году – 55%).

🤩Больше всего ИИ используют в IT, маркетинге и продажах, сервисных операциях и разработке продуктов.

🤩Компании все чаще применяют генеративный ИИ (Gen AI) для создания текста, изображений и кода.

🤩 Перестройка бизнес-процессов под ИИ

🤩21% компаний, использующих Gen AI, уже пересмотрели ключевые рабочие процессы.

🤩Крупные компании (с выручкой более $500 млн) меняются быстрее, чем малые.

🤩Важную роль играет пересмотр рабочих процессов и управление временем сотрудников, освобожденным за счет ИИ.

🤩 Кто управляет внедрением ИИ?

🤩В 28% компаний ответственность за ИИ-управление несет CEO.

🤩В крупных компаниях чаще этим занимается совет директоров (17%).

🤩Оптимальная стратегия — участие нескольких лидеров и четкое управление процессами.

🤩 Генеративный ИИ требует контроля и доверия

🤩27% компаний проверяют все выходные данные Gen AI перед использованием

🤩Главные риски: неточность данных, нарушение авторских прав, вопросы конфиденциальности.

🤩Организации активно развивают механизмы доверия к ИИ среди сотрудников и клиентов.

🤩 Влияние на рабочие места

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

🤩13% уже наняли специалистов по AI-комплаенсу, 6% — по AI-этике.

🤩В ближайшие три года планируется переобучение сотрудников: 48% компаний уже начали этот процесс.

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

🤩 Генеративный ИИ и финансовые результаты

🤩Влияние на EBIT пока ограничено: 80% компаний не видят значительного эффекта.

🤩Однако отдельные подразделения уже фиксируют рост выручки и снижение издержек.

🤩Главный вызов — масштабирование решений и четкое отслеживание ROI.

Ключевые факторы успеха полноценного внедрения ИИ:

🤩Лидерство высшего руководства.

🤩Перестройка рабочих процессов.

🤩Управление рисками и обеспечение доверия.

🤩Развитие компетенций сотрудников.

🤩Четкое измерение эффекта от внедрения.

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

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

По мере того как компании становятся более уверенными в использовании ИИ, он органично встраивается во все бизнес-функции. В результате роль руководства смещается от непосредственного внедрения к более стратегическим задачам — таким как мониторинг влияния технологий и развитие талантов.

- Александр Сухаревский, Старший партнёр и глобальный со-руководитель QuantumBlack, AI от McKinsey.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁1
Please open Telegram to view this post
VIEW IN TELEGRAM
🚀 Мы запускаем новый тренинг

🔥 Относительные оценки в Agile без иллюзий: как делать их правильно и не страдать?🔥


📅 Дата: 17 апреля 2025
🕘 Время: 10:00–18:00 МСК
🌍 Формат: онлайн

🔝Почему мы проводим этот тренинг?

Любая команда сталкивалась с ситуацией, когда:

Оценки в часах не сходятся с реальностью.

Сторипоинты кажутся магией, но не помогают.

Заказчики требуют точности, а команда даёт расплывчатые числа.

🔝 Мы собрали реальные кейсы и практические подходы, которые действительно работают. Без догм и шаблонных решений – только проверенные инструменты и адаптация под вашу команду.

Что будет на тренинге?

✔️ Почему относительные оценки лучше, но не всегда.
✔️ Как работать со сторипоинтами так, чтобы они приносили пользу.
✔️ Когда использовать Planning Poker, а когда другие техники.
✔️ Как оценивать задачи в распределённых командах.
✔️ Как не дать оценкам стать инструментом давления и контроля.

Для кого?

Scrum-мастеров, Agile-коучей и лидеров команд.
Менеджеров, которые хотят понимать оценки без иллюзий.
Разработчиков и аналитиков, которым надоело гадать на кофейной гуще.

Почему этот тренинг особенный?

🔝Тренер – практик с опытом внедрения Agile-оценок в реальных командах.

🛠 Мы не просто объясним теорию, а разберём ошибки и "подводные камни".

💭 Живое общение, дискуссии и реальные кейсы участников.

🎁 Бонус: доступ к закрытому чату для обмена опытом и обсуждения вопросов после тренинга.

💸 Стоимость: 15 000₽

➡️ Регистрация

#Agile #Scrum #Планирование #Сторипоинты #Практика
Please open Telegram to view this post
VIEW IN TELEGRAM
3
💬Разговор с Джеймсом Кранцем: о BART, ролях и настоящих клиентах

Недавно у нас в Магистратуре прошли лекции Джеймса Кранца – настоящей легенды в области организационного психоанализа. Сегодня хочу поделиться темами, которые мы обсуждали, и мыслями, которые возникли после общения с ним.

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

🤩 Что обсуждали на встречах?

🤩Методика BART (Boundary, Authority, Role, Task). Это ключевая модель в психодинамическом подходе, но я не буду углубляться – информацию легко найти в открытых источниках.

🤩Почему именно "Task", а не "Target/Object"?
Я задала этот вопрос Джеймсу, и он объяснил: психодинамическому консультанту важен не просто результат, а весь процесс взаимодействий, изменений и динамики, ведущей к цели. В отличие от "Target/Object" (фиксированной точки), "Task" подразумевает движение, трансформацию.

🤩Роли, полномочия и границы – одна из слабейших точек в организациях, из-за которой возникают конфликты, а иногда – фатальные ошибки. Когда эти элементы размыты, начинается хаос: кто за что отвечает? Где границы влияния? Кто принимает решения?

🤩Настоящий клиент. Кто он?
Один из самых интересных моментов – это тема "истинного клиента". Часто консультант попадает в ловушку: он работает не с тем, кто реально сделал запрос на изменения.

Пример:
👥 HR приглашает консультанта для работы с командой. Кто настоящий клиент? Руководитель этой команды, а не HR! Если консультант не задаёт этот вопрос, он рискует работать не с первопричиной проблемы.

[Из моего опыта] Когда ко мне приходят HR с запросом помочь руководителю сработаться с другим руководителем, я прошу, чтобы мне организовали встречу с руководителем иначе ничего не получится. Есть компании, которые возвращаются, а есть те, кто уходит в небытие.

⚠️ Но ещё более коварная ловушка – когда на проекте есть, назовём его, Senior Consultant (SC), ведущий трансформацию, но не имеющий доступа к настоящему заказчику. Его контакт – только proxy-заказчик (например, руководитель/менеджер проекта).

Что происходит дальше?

😨Proxy-заказчик жалуется на консультантов: "они делают не то, не так".

😨 SC начинает разбираться со своей командой, пытаясь "исправить ситуацию".

😨 В итоге конфликт, смена команды… а проблема остаётся.

🥺В чём ошибка?
SC не понял, что жалобы – это сопротивление изменениям. И они, скорее всего, исходят не от proxy-заказчика, а от настоящего заказчика, который боится трансформации. Но SC до него просто не добрался. Хуже, когда сам proxy-заказчик “пидалирует” изменения из-за собственного регресса.

🔡 Вывод:

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

🔡 Настоящий организационный консультант — этот тот, кто хорошо разбирается в психодинамике, а не только в орг.структуре

#НИУВШЭ #МП_2024
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Всем привет! 👋

🗣️ На связи Анастасия, CEO компании “Лаборатория ПроЛидеров”.

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

↘️ Когда голосование не помогает, а вредит

Сталкивались ли вы с тем, что команда не может принять решение, потому что никто не может договориться? Кажется, идеальный момент для голосования. Но как сделать голосование действительно рабочим, а не причиной конфликта и деструктива?

Реальный кейс*
В команде формально нет лидера, но есть человек, который следит за порядком — модератор.

❗️С чего всё началось:

Один из участников, Коля, задал в чате вопрос. Другой участник, Саша, поделился полезной статьёй, которую когда-то сам написал. Коля поблагодарил — обычное продуктивное взаимодействие.

👻 И тут модератор команды, Кристина, запускает голосование:

“Согласны ли вы, чтобы участники делились своими статьями в чате?”

🐼 Без обозначения сроков, правил подсчёта голосов, принципов принятия решений.

Что пошло не так?

👎 Ошибка 1: Модератор не обсудила с группой принцип голосования.

👎 Ошибка 0 (нулевая): Не объяснила, зачем и почему вообще решила его запустить. Это та самая "игра с нулевой суммой", где личные ощущения важнее интересов команды.

❗️Важно помнить:

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

❗️ Команда ≠ группа

Если у вас 20+ человек, которые не объединены общей целью — это уже не команда, а группа/сообщество. А значит, и правила принятия решений здесь другие:

через консент,
демократию с кворумом,
а не просто «большинство от общего количества участников».
При том, что у вас могут быть пассивные участники, которые даже не читают ваш чат.

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

Когда модератор начинает действовать как руководитель, которым его никто не назначал — начинается сопротивление, обида, пассивная агрессия. Кто-то перестаёт делиться, кто-то уходит в тень. А ведь изначально всё было про ценность и вклад.

💡 Но! Даже такие ситуации могут нести пользу. Если команда готова к открытому диалогу, это может стать точкой роста — именно через сопротивление рождается живая, подлинная среда.

И ещё один важный вывод:

💡 Если модератор уходит, потому что его не поддержали — это значит, что его самоидентификация как «руководителя» не совпала с реальностью. Но это уже тема для отдельного разговора — о границах, ролях и праве влиять.

А теперь к вам:
Как в ваших командах принимаются решения? Через голосование, созданные правила или когда как и не понятно как?

Пишите в комментариях — обсудим.

*все имена и события скорректированы с целью соблюдения конфиденциальности

Полезное по этой теме:

‼️ Тренинг “Стратегии эффективного управления конфликтами”

💬 28-30 мая 2025
💬 24-26 сентября 2025
💬 17-19 декабря 2025

😊 Статья “Доска делегирования и Матрица принятия решений, как вечная дилемма курицы и яйца”

Всем продуктивной недели 👩‍💼
Please open Telegram to view this post
VIEW IN TELEGRAM
👍42🔥2
Не так давно мы публиковали пост о встрече с Джеймсом Кранцем и о методике BART.

По вашим просьбам рассказываем более подробно о BART и показываем как она работает на реальных кейсах.

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

BART = Boundary, Authority, Role, Task
или по-русски: Граница, Полномочия, Роль, Задача


Да именно “полномочия”, а не “власть”, так как “власть” - это уже “Power”

🔡Boundary (Граница) — определяет, где заканчивается одна система и начинается другая. Это может быть временная граница (например, рабочие часы), пространственная (офис — не офис), или социальная (члены группы vs. не-члены). Управление границами важно для эффективности команды.

🔡 Authority (Полномочия) — кто имеет право принимать решения, кто отвечает за что. Это может быть формальная власть (начальник отдела) или неформальная (лидер мнений в группе).

🔡 Role (Роль) — роль, которую человек выполняет в организации или группе. Это не только должностная позиция, но и социальная функция (например, "оппозиционер", "миротворец").

🔡 Task (Задача) — основная цель или работа, которую группа должна выполнить. Четкое определение задачи помогает команде не отвлекаться и правильно распределять усилия

‼️ BART-анализ команды / ситуации

1️⃣ Граница (Boundary)
Какие границы определяют эту систему?
🔘Где проходит физическая граница? (офис/удалёнка, доступ в пространства)
🔘Какие временные границы? (рабочие часы, дедлайны, смены)
🔘Кто "внутри" команды, а кто — "снаружи"? (по статусу, доступу, участию)
🔘Есть ли пересечения или размытые границы?

Примеры: Sales вмешиваются в работу Product;
IT игнорирует бизнес-задачи.

❗️Риск: размытые границы → тревога → микроменеджмент или апатия.

2️⃣ Полномочия (Authority)
Кто принимает решения и на каком основании?
🔘Кто имеет формальные полномочия (менеджеры, кураторы)?
🔘Кто обладает неформальной властью (лидеры мнений)?
🔘Ясно ли, кто за что отвечает?
🔘Есть ли конфликты или пробелы в полномочиях?

‼️ Enterprise-парадокс: многоуровневая иерархия + agile → кто реально принимает решения?

3️⃣ Роль (Role)
Какие роли есть в команде, кто какую занимает?
🔘Какие формальные роли у участников?
🔘Есть ли скрытые/неформальные роли (например, критик, миротворец)?
🔘Ожидания по ролям — проговорены или предполагаются?
🔘Есть ли конфликты ролей или недоразумения?

Пример: Project Manager становится координатором, психологом, фасилитатором и огнетушителем в одном лице.

❗️Важно отслеживать: роли люди "берут на себя" или "навязывают"?

4️⃣ Задача (Task)
Какова основная цель/миссия команды?
🔘Насколько ясно сформулирована задача?
🔘Разделяют ли все участники понимание задачи?
🔘Есть ли конкурирующие задачи или подмены задач?

❗️В корпоративной среде люди часто действуют не в интересах задачи, а для "страховки", "политики", "отчётности".

‼️ Итоговый вывод / точка напряжения
На пересечении этих четырех элементов часто возникают напряжения. Например:
🍄 Расплывчатые полномочия + неясные роли = конфликт.
🍄 Неопределённая задача + размытые границы = дезорганизация.


🤩 Как BART работает в Enterprise:

🤩 Диагностика команд и лидеров: кто реально делает что и зачем.

🤩 Выявление "теневых ролей" — тех, кто формально не руководит, но влияет на процессы.

🤩 Разбор организационных тупиков, где роли и задачи не соответствуют ожиданиям или реальности.

🎙 Пример из Enterprise:

Контекст: команда Digital Transformation в крупном банке.
Проблема: неясность задач, расслоение полномочий между ИТ и бизнесом.

⚡️ BART-анализ выявил: отсутствие ясных границ и размытая роль Product Owner → саботаж изменений.

⬆️ Решение: реструктуризация ролей, уточнение задач, ролевой коучинг.
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Please open Telegram to view this post
VIEW IN TELEGRAM
1
😨 Ваш бэклог продукта: шедевр продакт-искусства… или ящик пандоры?

Знакомо это чувство?

Открываешь бэклог — и не знаешь, то ли планировать спринт, то ли вызвать экзорциста.

Там 👇

👀 Элементы из прошлого года или даже жизни: никто не помнит, зачем они и кто вообще просил.

🚨 “Срочные” хотелки от CEO, “важные” от смежников и “а давайте просто сделаем” от команды.

🫨 3 похожих фичи, но все звучат по-разному.

🤯 какая-то User Story, которая похожа на загадку Сфинкса.

И в голове проносится мысль… а может всё это удалить и заново начать… а потом страх шепчет “А вдруг там что-то важное?”. И твоя рука тянется к кнопке “архивировать”…

Кажется, ты уже не владелец продукта… Ты — архивариус хаоса. 😅

💬Пишите в комментах, какие чудеса вы находили у себя — поделимся болью и посмеёмся вместе.
(И нет, вы не одиноки. Мы тоже через это проходили 🙃)

👍 Кстати!

Если хотите научиться укрощать хаос и превратить бэклог в действительно полезный инструмент — приходите на наш практический тренинг «Управление бэклогом продукта и построение User Story Map».

Будем работать с реальными кейсами: минимум теории, максимум практики.

Ближайший тренинг:

➡️ 20 - 22 мая 2025
Please open Telegram to view this post
VIEW IN TELEGRAM
1
🔥 “Да не конфликт это, просто у нас... ну эмоции!”

Было у вас такое? 👇

Обычная встреча. Вроде даже не пятница. Вроде даже все выспались. А потом — бах! — что-то пошло не так:

😈 Один тяжело вздыхает и уже всем видом “объясняет”, что всё ерунда.

😈 Второй резко выскакивает с “сейчас объясню, как правильно”.

👻 Третий просто выходит с зум-встречи. Без слов.

🍪 А четвёртый нервно ест печеньку, надеясь, что всё рассосётся само.

А вы где-то посередине, в режиме “мама, забери меня с этой планёрки” 🥺

🤩Но знаете что? Это не просто эмоции.
Это — конфликт. Даже если никто не кинулся с ножом. И да, он случается даже у адекватных взрослых людей.

🤩Почему?
Потому что где люди — там всегда разность мнений, ролей, целей и амбиций.

🤩 Вопрос не в том, “как избежать конфликта” — никак.
А в том, что с ним делать. Потому что конфликт может стать катастрофой —
а может стать точкой роста.

И вот об этом как раз будет наш тренинг:

⚠️ “Стратегии эффективного управления конфликтами”

💬 28-30 мая 2025 💬

А пока — давайте немного интерактива 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
2
🤯 Что делать, если бэклог больше напоминает мешок с разной исторической пылью?

Итак, вы открыли бэклог, вдохнули, перекрестились (по продакт-обряду), и в который раз подумали: "Окей… а с чего начать?"

Вот 3 признака, что пора спасать бэклог — и с чего начать этот путь:

🆘1. Задачи есть, смысла — нет

Если вы сами не можете вспомнить, зачем задача — шансы, что она нужна, тают.

🛠 Ревизия. Честная. Без страха и упрёков. Да, удалять страшно, но тянуть весь этот "на всякий случай" багаж — ещё страшнее.

🆘 2. Всё в куче, как на кухне после вечеринки

Когда бизнес фичи лежат в одной стопке —ориентироваться сложно, приоритизировать — невозможно. А если у вас туда забежали ещё и таски разработчиков или вы устроили вакханалию по процессу… Да мы за свой консалтингоывй опыт повидали многое…

🛠 Начните с группировки: по пользователям, по типу задач. Возможно, у вас там окажутся под одним типом и технические стори и технический долг. Уберите то, что вообще не касается вопроса “Что?”, а уже сместилось на вопрос “Как?”

🆘 3. Много задач, но нет ощущения “картины”

🛠 Вот тут приходит время для User Story Map — инструмента, который помогает выстроить всё по логике пользовательского пути, а не в хаотичную ленту стикеров.

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

И да, User Story Map не только про User Story, там и Job Story и Tech Story… Есть место даже тех.долгу и багам. А ещё можно увидеть связи со смежниками.

🦄 Бэклог — это не хаотичное хранилище хотелок (3Х). Это работающий на вас артефакт, который позволяет управлять вниманием и повышать ценность продукта.

Всё это мы разбираем на нашем тренинге “Управление бэклогом продукта и построение User Story Map”

Тренинг, который поможет превратить хаос в управляемую систему. Вы с нами?

➡️ 20 - 22 мая 2025
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🤩 Почему конфликты случаются даже у умных, опытных и «взрослых»?

Иногда кажется: мы же адекватные, мы же все взрослые люди, чего нам делить?

Но потом — раз, и ты уже слушаешь, как в чате "просто уточняют формулировку", но при этом воздух звенит, как перед грозой. 💣

🤔Почему так?

Потому что конфликт — это не про “плохих людей”. Это про разные потребности, роли, границы и ожидания, которые вдруг столкнулись в одной точке.

Вот три самые частые причины, которые запускают скрытый (или очень даже явный) конфликт:

🤩 У всех разная “картина мира”.

Один считает, что “срочно — это сегодня до 12:00”.
Другой — что “срочно” — это до конца недели.
Встреча, два взгляда, три недопонимания.

🔧Что помогает:
проговорённые ожидания и чек с реальностью — совпадает ли то, что мы думаем, с тем, что происходит?

💬 Личный кейс:

Когда я работала в компании Agile-коучем, у меня был напарник, с которым мы часто ездили в командировки. Мы обычно договаривались встретиться через 10 минут после завтрака, чтобы отправиться к командам.
Через 10 минут я уже ожидала напарника в холле гостиницы — но его не было. Проходило ещё минут 15, и только тогда он появлялся.
Поначалу это раздражало меня, потому что я очень пунктуальный человек. Но позже мы превратили это в шутку. Когда напарник говорил: «Встретимся через 10 минут», я уточняла: «Через твои 10 минут?» — потому что уже понимала: это будет +5 или +8 минут. И тогда я могла спокойно выйти позже или просто допить кофе.
И если вы подумали, что мы опаздывали — нет. Каждый из нас был достаточно ответственным. Просто у нас были разные 10 минут.


🤩 Неясные роли.

– Кто принимает решение?
– Кто фасилитирует?
– Кто…?

Если роли размыты, на одном и том же стуле оказываются как минимум двое. И каждый считает, что его не слышат.

⚙️Что помогает:
называть роли и договориться, кто за что отвечает здесь и сейчас. Об этом мы писали в нашем посте про метод BART

🤩 Персональный “багаж”

🔹Кто-то вырос в семье или компании, где за публичный спор будет строго наказан.
🔹Кто-то — где без крика тебя вообще не замечают.

А теперь все они в одной команде. И каждый ведёт себя "нормально", но вот только у каждого — своё “нормально”.

⚙️Что помогает:
навык видеть не только поведение, но и то, что за ним стоит.

🤩 Конфликт — это не ошибка системы. Это её естественная часть. И если с ним правильно работать — он может стать двигателем роста.

🤩 На нашем тренинге “Стратегии эффективного управления конфликтами” мы учим видеть не “кто виноват”, а “что на самом деле происходит”

А пока — делитесь: 💬 Какая из трёх причин ближе вам?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Вот уже несколько лет я учу команды строить Карты пользовательских историй и в 2018 году создала игру "Собирашка", которая помогает по сей день понимать командам как построить свою Карту пользовательских историй. На данный момент уже 5-ая версия игры.

Однако, сегодня мы поговорим с вами не об игре, а о том, какие мифы разрушаются во время построения USM.

Миф 1️⃣:
У нас нет пользователя, поэтому карта пользовательских историй нам не подходит


Огорчу вас у каждого продукта есть пользователь, вы просто до него не добрались, а точнее смотрите не под тем углом на то, что создаёте.

Миф 2️⃣:
В Карте пользовательских историй только клиентские шаги 👣 – активность клиента


Верхушка Карты пользовательских историй - это не верхушка CJM, это соединение CJM и бизнес-процесса, точнее – это поток создания ценности для пользователя, который включает в себя шаги всех причастных.

Миф 3️⃣:
В Карте пользовательских историй только пользовательские истории (user stories) 😱


Это мой самый любимый миф 😁 Вот есть у некоторых консультантов перекосы в одну или другую сторону. Одни "топят" за пользовательские истории, другие – за джоб стори ... Однако, мир не чёрно-белый, а пользовательские истории уже потеряли свой первоначальный вид.

Миф 4️⃣:
В Карте пользовательских историй не может быть технического долга, а багов и подавно 😱


Карта пользовательских историй - это ваша система координат, а команда – это картографы, которые делают на ней разметки, чтобы знать где и что. Если вы не разметите технический долг, то вы просто о нём забудете, а потом будете удивляться откуда столько этого "добра" или почему начинаем замедлять при разработке.

На моём тренинге “Управление бэклогом продукта и построение User Story Map” я детально разбираю все эти Мифы, а также новые.

🔡 Старт 20 мая, присоединяйтесь и делитесь своими мифами 👩‍💼
Please open Telegram to view this post
VIEW IN TELEGRAM
♟️ TKI как шахматная партия: стратегии конфликтов на доске взаимодействия

Конфликт — это не просто “характер не сошёлся”. Это игра. И как в шахматах, важен не только ваш ход, но и ответ партнёра.

Сегодня разбираем модель TKI — через шахматные связки.

🔻Конкуренция — Уступка
Давление (атака) против добровольной сдачи фигуры.

🎯Иногда — разумная стратегия: разница в статусе, кризис, нужно быстро. Но если уступка — по умолчанию, а не по выбору, появляется перекос власти и роль "вечного проигрывающего”, а за ним выгорание и апатия

🔻Конкуренция — Сотрудничество
Один идёт в атаку, второй не поддаётся… но и не отвечает агрессией. Он приглашает к диалогу.

🎯 Это идеальный момент для трансформации конфликта.
Работает, если в команде есть доверие, зрелость и культура диалога.

🔻Конкуренция — Компромисс
Размен фигур. Оба теряют, но никто не уходит с поля.

🎯Иногда — это наилучшее из возможного.
Не победа, но и не поражение. Главное — сохранить игру.

🔻Конкуренция — Избегание
Один давит. Второй уходит.
Проблема "разрешилась"? Нет. Просто ушла в тень.

🧨 Результат: пассивная агрессия, выгорание, молчаливый саботаж. А иногда — тишина перед уходом из команды.

Конкуренция — Конкуренция
Битва королей.

Кажется, что сейчас кто-то выиграет…
Но чаще все проигрывают: цели рушатся, команды ломаются, ресурсы утекают.

🤩Конфликт — это не плохо.
Плохо — не понимать, в какой партии вы оказались и по каким правилам играете.

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

🔡 Старт 28 мая

💬 А вы узнали в этих описаниях свои “партии”?
Напишите, какие связки вам знакомы — и как вы из них выходили.
Please open Telegram to view this post
VIEW IN TELEGRAM
2
Please open Telegram to view this post
VIEW IN TELEGRAM
😑 Декомпозиция — это не про "просто порезать на задачи"

"Порежьте эпик на задачи", — говорили они.

"Сделали!" — ответила команда.

А потом… 🤪
всё равно никто не понимает, что за элементы в бэклоге, что делать дальше и зачем.

🙂 Декомпозиция ради декомпозиции и распухший неуправляемый бэклог продукта…

Вот три типовые ошибки, с которыми сталкиваемся снова и снова:

1️⃣Ошибка 1: Режем по техническому принципу, а не по пользовательской логике

🔻Backend: сделать API
🔻Frontend: отрисовать кнопку
🔻QС: протестировать

В итоге — фичи нет, смысла тоже нет. А в бэклоге продукта уже 14 задач.

2️⃣ Ошибка 2: Привязываемся к исполнителям, а не к шагам ценности

"Эту часть делает Петя", "Эту – Вика", "Эту – подрядчик".

А пользователю неважно, кто, – ему важно, что получится в итоге.

Если строить карту по именам, а не по шагам — легко потеряться.

3️⃣ Ошибка 3: Пытаемся разрезать без цели и контекста

Если вы не знаете, зачем вообще эта фича,
как она встраивается в пользовательский путь и какой эффект ожидается – никакая декомпозиция не спасёт. Только усложнит.

✔️ Хорошая декомпозиция – это не “нарезка”, а встраивание в общую карту смысла:

👌 Что делает пользователь?
👍 Что происходит внутри?
🫡Где пересекаются команды?
👍 Что можно выпустить раньше?
👌 Где тех.долг, а где шанс на быструю победу?

И именно этому мы учим на тренинге:
"Эффективное управление бэклогом и построение User Story Map"

📅 20–22 мая

🔥 Много практики, реальные бэклоги, честная работа с хаосом

💭 А у вас в команде как обычно проходит декомпозиция? Просто “порезали” или с огоньком и болью? Делитесь в комментариях👇
Please open Telegram to view this post
VIEW IN TELEGRAM
3
Please open Telegram to view this post
VIEW IN TELEGRAM
1
🤩 Приоритизация задач: искусство… или игра в “кто громче крикнет”?

Знакомо это чувство?
Вы тщательно распланировали работу, собрали план развития продукта… а потом:

===
👀 CEO проснулся с «гениальной» идеей.

🙂 Маркетинг прибежал со «срочной» хотелкой.

🤡 Техподдержка свалила мешок багов.

🛡 Разработчики: «Без рефакторинга тут никуда».

🆒 И, конечно, личные любимчики команды.
===

Всё важно. Всё срочно. Всё критично. И ваш приоритетный список превращается в битву за внимание. 🥸

☄️Вот три классические ошибки приоритизации, которые мы видим снова и снова:

🤩 Приоритизация по принципу “чьё мнение весомее”
CEO сказал – делаем. Смежный отдел пожаловался – вписали.

🤩 Итог: план отражает не ценность для пользователя, а чью-то настойчивость.

🤩 Приоритизация по принципу “что проще”
О, эта задача лёгкая, давайте возьмём её для разгона
🤩 Результат: много выполненных задач, но с минимальным влиянием на продукт.

🤩 Приоритизация без фокуса на цель
Все задачи ставятся в “высокий приоритет”, потому что “кажется важным”.

🤩 В итоге ваш бэклог превращается в новогоднюю ёлку: всё блестит, но смысла мало.

🤩 Эффективная приоритизация – это не про удобство или громкость.

Это про ценность + влияние + ресурсы.

И да, она всегда требует смелости говорить «нет» – это часть работы продакта.


🤩 На тренинге «Управление бэклогом продукта и построение User Story Map» мы учим не просто сортировать задачи, а приоритизировать их стратегически:

🤩 разбираем реальные кейсы и показываем, как выбирать метод (RICE, MoSCoW, Value vs. Effort и другие);
🤩 связываем приоритеты с целями бизнеса и пользовательским путём;
🤩 отрабатываем аргументацию отказа и защиту решений перед стейкхолдерами;
🤩 учим строить прозрачные карты для эффективного управления даже самыми сложными бэклогами.

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

👉 20–22 мая. Уже скоро!

А как вы приоритезируете? Делитесь в комментариях 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
2👍1