Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Всем привет! 👋
🗣️ На связи Анастасия, CEO компании “Лаборатория ПроЛидеров”.
Сегодня я хочу поделиться с вами одной историей про командную работу и голосование — ситуацией, которая, возможно, откликнется многим.
↘️ Когда голосование не помогает, а вредит
Сталкивались ли вы с тем, что команда не может принять решение, потому что никто не может договориться? Кажется, идеальный момент для голосования. Но как сделать голосование действительно рабочим, а не причиной конфликта и деструктива?
Реальный кейс*
В команде формально нет лидера, но есть человек, который следит за порядком — модератор.
❗️ С чего всё началось:
Один из участников, Коля, задал в чате вопрос. Другой участник, Саша, поделился полезной статьёй, которую когда-то сам написал. Коля поблагодарил — обычное продуктивное взаимодействие.
👻 И тут модератор команды, Кристина, запускает голосование:
“Согласны ли вы, чтобы участники делились своими статьями в чате?”
🐼 Без обозначения сроков, правил подсчёта голосов, принципов принятия решений.
❌ Что пошло не так?
👎 Ошибка 1: Модератор не обсудила с группой принцип голосования.
👎 Ошибка 0 (нулевая): Не объяснила, зачем и почему вообще решила его запустить. Это та самая "игра с нулевой суммой", где личные ощущения важнее интересов команды.
❗️ Важно помнить:
В команде равных любое новое правило появляется тогда, когда команда сама сигнализирует, что назревает хаос, который нужно структурировать.
Если этого сигнала не было, преждевременное «наведение порядка» воспринимается как нарушение границ.
❗️ Команда ≠ группа
Если у вас 20+ человек, которые не объединены общей целью — это уже не команда, а группа/сообщество. А значит, и правила принятия решений здесь другие:
✅ через консент,
✅ демократию с кворумом,
а не просто «большинство от общего количества участников».
При том, что у вас могут быть пассивные участники, которые даже не читают ваш чат.
❗️ Почему это важно?
Когда модератор начинает действовать как руководитель, которым его никто не назначал — начинается сопротивление, обида, пассивная агрессия. Кто-то перестаёт делиться, кто-то уходит в тень. А ведь изначально всё было про ценность и вклад.
💡 Но! Даже такие ситуации могут нести пользу. Если команда готова к открытому диалогу, это может стать точкой роста — именно через сопротивление рождается живая, подлинная среда.
И ещё один важный вывод:
💡 Если модератор уходит, потому что его не поддержали — это значит, что его самоидентификация как «руководителя» не совпала с реальностью. Но это уже тема для отдельного разговора — о границах, ролях и праве влиять.
❓ А теперь к вам:
Как в ваших командах принимаются решения? Через голосование, созданные правила или когда как и не понятно как?
Пишите в комментариях — обсудим.
*все имена и события скорректированы с целью соблюдения конфиденциальности
—
Полезное по этой теме:
‼️ Тренинг “Стратегии эффективного управления конфликтами”
💬 28-30 мая 2025
💬 24-26 сентября 2025
💬 17-19 декабря 2025
😊 Статья “Доска делегирования и Матрица принятия решений, как вечная дилемма курицы и яйца”
Всем продуктивной недели👩💼
Сегодня я хочу поделиться с вами одной историей про командную работу и голосование — ситуацией, которая, возможно, откликнется многим.
Сталкивались ли вы с тем, что команда не может принять решение, потому что никто не может договориться? Кажется, идеальный момент для голосования. Но как сделать голосование действительно рабочим, а не причиной конфликта и деструктива?
Реальный кейс*
В команде формально нет лидера, но есть человек, который следит за порядком — модератор.
Один из участников, Коля, задал в чате вопрос. Другой участник, Саша, поделился полезной статьёй, которую когда-то сам написал. Коля поблагодарил — обычное продуктивное взаимодействие.
“Согласны ли вы, чтобы участники делились своими статьями в чате?”
В команде равных любое новое правило появляется тогда, когда команда сама сигнализирует, что назревает хаос, который нужно структурировать.
Если этого сигнала не было, преждевременное «наведение порядка» воспринимается как нарушение границ.
Если у вас 20+ человек, которые не объединены общей целью — это уже не команда, а группа/сообщество. А значит, и правила принятия решений здесь другие:
а не просто «большинство от общего количества участников».
При том, что у вас могут быть пассивные участники, которые даже не читают ваш чат.
Когда модератор начинает действовать как руководитель, которым его никто не назначал — начинается сопротивление, обида, пассивная агрессия. Кто-то перестаёт делиться, кто-то уходит в тень. А ведь изначально всё было про ценность и вклад.
И ещё один важный вывод:
Как в ваших командах принимаются решения? Через голосование, созданные правила или когда как и не понятно как?
Пишите в комментариях — обсудим.
*все имена и события скорректированы с целью соблюдения конфиденциальности
—
Полезное по этой теме:
Всем продуктивной недели
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2🔥2
Forwarded from Лаборатория ПроЛидеров | ProLeadersLab®
Не так давно мы публиковали пост о встрече с Джеймсом Кранцем и о методике BART.
По вашим просьбам рассказываем более подробно о BART и показываем как она работает на реальных кейсах.
Модель BART в контексте организационного консалтинга и групповой динамики — это не то же самое, что модель BART в машинном обучении (которая используется для обработки текста).
В консалтинге BART — это аббревиатура, описывающая четыре ключевые роли и функции в группах и организациях:
BART = Boundary, Authority, Role, Task
или по-русски: Граница, Полномочия, Роль, Задача
Да именно “полномочия”, а не “власть”, так как “власть” - это уже “Power”
🔡 Boundary (Граница) — определяет, где заканчивается одна система и начинается другая. Это может быть временная граница (например, рабочие часы), пространственная (офис — не офис), или социальная (члены группы vs. не-члены). Управление границами важно для эффективности команды.
🔡 Authority (Полномочия) — кто имеет право принимать решения, кто отвечает за что. Это может быть формальная власть (начальник отдела) или неформальная (лидер мнений в группе).
🔡 Role (Роль) — роль, которую человек выполняет в организации или группе. Это не только должностная позиция, но и социальная функция (например, "оппозиционер", "миротворец").
🔡 Task (Задача) — основная цель или работа, которую группа должна выполнить. Четкое определение задачи помогает команде не отвлекаться и правильно распределять усилия
‼️
1️⃣ Граница (Boundary)
Какие границы определяют эту систему?
🔘 Где проходит физическая граница? (офис/удалёнка, доступ в пространства)
🔘 Какие временные границы? (рабочие часы, дедлайны, смены)
🔘 Кто "внутри" команды, а кто — "снаружи"? (по статусу, доступу, участию)
🔘 Есть ли пересечения или размытые границы?
✨ Примеры: Sales вмешиваются в работу Product;
IT игнорирует бизнес-задачи.
❗️ Риск: размытые границы → тревога → микроменеджмент или апатия.
2️⃣ Полномочия (Authority)
Кто принимает решения и на каком основании?
🔘 Кто имеет формальные полномочия (менеджеры, кураторы)?
🔘 Кто обладает неформальной властью (лидеры мнений)?
🔘 Ясно ли, кто за что отвечает?
🔘 Есть ли конфликты или пробелы в полномочиях?
‼️ Enterprise-парадокс: многоуровневая иерархия + agile → кто реально принимает решения?
3️⃣ Роль (Role)
Какие роли есть в команде, кто какую занимает?
🔘 Какие формальные роли у участников?
🔘 Есть ли скрытые/неформальные роли (например, критик, миротворец)?
🔘 Ожидания по ролям — проговорены или предполагаются?
🔘 Есть ли конфликты ролей или недоразумения?
✨ Пример: Project Manager становится координатором, психологом, фасилитатором и огнетушителем в одном лице.
❗️ Важно отслеживать: роли люди "берут на себя" или "навязывают"?
4️⃣ Задача (Task)
Какова основная цель/миссия команды?
🔘 Насколько ясно сформулирована задача?
🔘 Разделяют ли все участники понимание задачи?
🔘 Есть ли конкурирующие задачи или подмены задач?
❗️ В корпоративной среде люди часто действуют не в интересах задачи, а для "страховки", "политики", "отчётности".
‼️ Итоговый вывод / точка напряжения
На пересечении этих четырех элементов часто возникают напряжения. Например:
🍄 Расплывчатые полномочия + неясные роли = конфликт.
🍄 Неопределённая задача + размытые границы = дезорганизация.
🤩 Как BART работает в Enterprise:
🤩 Диагностика команд и лидеров: кто реально делает что и зачем.
🤩 Выявление "теневых ролей" — тех, кто формально не руководит, но влияет на процессы.
🤩 Разбор организационных тупиков, где роли и задачи не соответствуют ожиданиям или реальности.
🎙 Пример из Enterprise:
Контекст: команда Digital Transformation в крупном банке.
Проблема: неясность задач, расслоение полномочий между ИТ и бизнесом.
⚡️ BART-анализ выявил: отсутствие ясных границ и размытая роль Product Owner → саботаж изменений.
⬆️ Решение: реструктуризация ролей, уточнение задач, ролевой коучинг.
По вашим просьбам рассказываем более подробно о BART и показываем как она работает на реальных кейсах.
Модель BART в контексте организационного консалтинга и групповой динамики — это не то же самое, что модель BART в машинном обучении (которая используется для обработки текста).
В консалтинге BART — это аббревиатура, описывающая четыре ключевые роли и функции в группах и организациях:
BART = Boundary, Authority, Role, Task
или по-русски: Граница, Полномочия, Роль, Задача
Да именно “полномочия”, а не “власть”, так как “власть” - это уже “Power”
BART-анализ команды / ситуацииКакие границы определяют эту систему?
IT игнорирует бизнес-задачи.
Кто принимает решения и на каком основании?
Какие роли есть в команде, кто какую занимает?
Какова основная цель/миссия команды?
На пересечении этих четырех элементов часто возникают напряжения. Например:
Контекст: команда Digital Transformation в крупном банке.
Проблема: неясность задач, расслоение полномочий между ИТ и бизнесом.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Forwarded from Лаборатория ПроЛидеров | ProLeadersLab®
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
Знакомо это чувство?
Открываешь бэклог — и не знаешь, то ли планировать спринт, то ли вызвать экзорциста.
Там
🫨 3 похожих фичи, но все звучат по-разному.
🤯 какая-то User Story, которая похожа на загадку Сфинкса.
И в голове проносится мысль… а может всё это удалить и заново начать… а потом страх шепчет “А вдруг там что-то важное?”. И твоя рука тянется к кнопке “архивировать”…
Кажется, ты уже не владелец продукта… Ты — архивариус хаоса. 😅
(И нет, вы не одиноки. Мы тоже через это проходили 🙃)
Если хотите научиться укрощать хаос и превратить бэклог в действительно полезный инструмент — приходите на наш практический тренинг «Управление бэклогом продукта и построение User Story Map».
Будем работать с реальными кейсами: минимум теории, максимум практики.
Ближайший тренинг:
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
Anonymous Poll
2%
Молча грызёте ручку
32%
Стреляете фактами
56%
Становитесь миротворцем с флагом “давайте просто работать”
10%
У вас свой стиль — делитесь в комментах!
Итак, вы открыли бэклог, вдохнули, перекрестились (по продакт-обряду), и в который раз подумали: "Окей… а с чего начать?"
Вот 3 признака, что пора спасать бэклог — и с чего начать этот путь:
Если вы сами не можете вспомнить, зачем задача — шансы, что она нужна, тают.
Когда бизнес фичи лежат в одной стопке —ориентироваться сложно, приоритизировать — невозможно. А если у вас туда забежали ещё и таски разработчиков или вы устроили вакханалию по процессу…
Вы не просто расставляете “что”, вы начинаете видеть “зачем” и “в каком порядке”. А при правильном составлении и шаги, которые пропустили и опции, которые не учли.
И да, User Story Map не только про User Story, там и Job Story и Tech Story… Есть место даже тех.долгу и багам. А ещё можно увидеть связи со смежниками.
Всё это мы разбираем на нашем тренинге “Управление бэклогом продукта и построение User Story Map”
Тренинг, который поможет превратить хаос в управляемую систему. Вы с нами?
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️⃣ :
Это мой самый любимый миф 😁 Вот есть у некоторых консультантов перекосы в одну или другую сторону. Одни "топят" за пользовательские истории, другие – за джоб стори ... Однако, мир не чёрно-белый, а пользовательские истории уже потеряли свой первоначальный вид.
Миф4️⃣ :
Карта пользовательских историй - это ваша система координат, а команда – это картографы, которые делают на ней разметки, чтобы знать где и что. Если вы не разметите технический долг, то вы просто о нём забудете, а потом будете удивляться откуда столько этого "добра" или почему начинаем замедлять при разработке.
На моём тренинге “Управление бэклогом продукта и построение User Story Map” я детально разбираю все эти Мифы, а также новые.
🔡 Старт 20 мая, присоединяйтесь и делитесь своими мифами 👩💼
Однако, сегодня мы поговорим с вами не об игре, а о том, какие мифы разрушаются во время построения USM.
Миф
У нас нет пользователя, поэтому карта пользовательских историй нам не подходит
Огорчу вас у каждого продукта есть пользователь, вы просто до него не добрались, а точнее смотрите не под тем углом на то, что создаёте.
Миф
В Карте пользовательских историй только клиентские шаги 👣 – активность клиента
Верхушка Карты пользовательских историй - это не верхушка CJM, это соединение CJM и бизнес-процесса, точнее – это поток создания ценности для пользователя, который включает в себя шаги всех причастных.
Миф
В Карте пользовательских историй только пользовательские истории (user stories) 😱
Это мой самый любимый миф 😁 Вот есть у некоторых консультантов перекосы в одну или другую сторону. Одни "топят" за пользовательские истории, другие – за джоб стори ... Однако, мир не чёрно-белый, а пользовательские истории уже потеряли свой первоначальный вид.
Миф
В Карте пользовательских историй не может быть технического долга, а багов и подавно 😱
Карта пользовательских историй - это ваша система координат, а команда – это картографы, которые делают на ней разметки, чтобы знать где и что. Если вы не разметите технический долг, то вы просто о нём забудете, а потом будете удивляться откуда столько этого "добра" или почему начинаем замедлять при разработке.
На моём тренинге “Управление бэклогом продукта и построение User Story Map” я детально разбираю все эти Мифы, а также новые.
Please open Telegram to view this post
VIEW IN TELEGRAM
Конфликт — это не просто “характер не сошёлся”. Это игра. И как в шахматах, важен не только ваш ход, но и ответ партнёра.
Сегодня разбираем модель TKI — через шахматные связки.Давление (атака) против добровольной сдачи фигуры.
Один идёт в атаку, второй не поддаётся… но и не отвечает агрессией. Он приглашает к диалогу.
Работает, если в команде есть доверие, зрелость и культура диалога.
Размен фигур. Оба теряют, но никто не уходит с поля.
Не победа, но и не поражение. Главное — сохранить игру.
Один давит. Второй уходит.
Проблема "разрешилась"? Нет. Просто ушла в тень.
🧨 Результат: пассивная агрессия, выгорание, молчаливый саботаж. А иногда — тишина перед уходом из команды.
Битва королей.
Кажется, что сейчас кто-то выиграет…
Но чаще все проигрывают: цели рушатся, команды ломаются, ресурсы утекают.
Плохо — не понимать, в какой партии вы оказались и по каким правилам играете.
На тренинге “Стратегии эффективного управления конфликтами” вы научитесь видеть динамику, выбирать стратегию осознанно и управлять не только собой, но и процессом конфликта.
💬 А вы узнали в этих описаниях свои “партии”?
Напишите, какие связки вам знакомы — и как вы из них выходили.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Please open Telegram to view this post
VIEW IN TELEGRAM
"Порежьте эпик на задачи", — говорили они.
"Сделали!" — ответила команда.
А потом…
всё равно никто не понимает, что за элементы в бэклоге, что делать дальше и зачем.
Вот три типовые ошибки, с которыми сталкиваемся снова и снова:
"Эту часть делает Петя", "Эту – Вика", "Эту – подрядчик".
А пользователю неважно, кто, – ему важно, что получится в итоге.
Если вы не знаете, зачем вообще эта фича,
как она встраивается в пользовательский путь и какой эффект ожидается – никакая декомпозиция не спасёт. Только усложнит.
И именно этому мы учим на тренинге:
"Эффективное управление бэклогом и построение 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 сказал – делаем. Смежный отдел пожаловался – вписали.
О, эта задача лёгкая, давайте возьмём её для разгона
Все задачи ставятся в “высокий приоритет”, потому что “кажется важным”.
Это про ценность + влияние + ресурсы.
И да, она всегда требует смелости говорить «нет» – это часть работы продакта.
Фокус — на практических инструментах, которые работают в условиях высокой динамики и ограниченных ресурсов.
А как вы приоритезируете? Делитесь в комментариях
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
Бывает, что в команде вроде тихо – но как-то… не так.
Напряжение в воздухе. Переписки сухие. В зуме – согласие, а потом всё идёт мимо.
Это не “люди испортились”. Это может быть обычный конфликт – просто не очень очевидный.
Вот три мифа, которые часто мешают с ним справиться – и что помогает на самом деле.
💡 На деле:
Конфликт – это не “неудача”, а естественное следствие того, что вы разные. Разные взгляды. Разные скорости. Разное понимание “срочно” и “важно”.
Если договориться — можно выйти слаженнее, чем были.
💡Иногда – наоборот:
Важно научиться это считывать – и открыто обсуждать, пока не поздно.
💡А по факту:
В командных конфликтах дело редко в логике.
Обычно – в ощущении: “меня не слышат”, “я здесь один”, “меня обесценили”.
Потому что “понятно” не случается без “безопасно”.
Но не у всех есть инструменты, как проходить их честно, бережно и с пользой.
“Стратегии эффективного управления конфликтами”
А вы узнаёте себя или свою команду?
Поделитесь — какой из мифов встречался чаще всего?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6
Forwarded from Лаборатория ПроЛидеров | ProLeadersLab®
Длинные выходные позади, настраиваемся на работу 🤓
#ВдохновениеНедели #ЦитатыНедели
🗂 Цитаты 2024
📂 Вдохновения 2025
#ВдохновениеНедели #ЦитатыНедели
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1
– Так, берём вот эту задачу.
– А зачем она?
– Ну… это было в пожеланиях от клиента. Кажется… Год назад…
– А как это повлияет на пользователя?
– Ну, как-то повлияет. Должно… Наверное…
– А что идёт перед этим?
– 🤷♀️
– А что идёт после?
– 🤷♂️
– А кто вообще это просил?
– Не знаю, но в бэклоге лежит. Значит, надо делать.
Когда нет карты пользовательских историй, обсуждение фич превращается в археологические раскопки:
🪦 пытаемся вспомнить откуда взялась задача;
🧩 сочиняем, как она встроится в остальное;
💥 спорим, потому что у всех в голове разная картина.
А если в голове – каша, то и в разработке получится примерно то же самое.
Это:
Когда тренинг?
А у вас были “задачи-призраки” в бэклоге? Пишите – соберём коллекцию и сделаем арт-объект
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
«А вдруг это не подойдёт мне?»
💭 «У нас всё не по учебнику...»
💭 «User Story Map – я уже знаю про это»
💭 «Мне сейчас не до обучения»
💭 «Команды нет, с кем внедрять?»
Звучит знакомо? Эти фразы мы слышим каждый раз перед стартом тренинга.
И да – они нормальные. Но часто за ними прячется главное:
❗️ Нам неловко разбираться в хаосе.
❗️ Страшно признать, что не всё под контролем.
❗️ И обидно, когда вроде бы знаешь, но не применяешь.
Вот4️⃣ частых “внутренних аргумента” – и что на самом деле за ними:
1️⃣ «У нас бэклог не как в книжках – там мешанина»
💡 Именно поэтому вам и стоит прийти.
У нас не “академия идеального продукта” – мы работаем с реальностью:
с багами, внезапными хотелками от CEO и задачами из «прошлой жизни».
2️⃣ «Я уже это знаю, у меня есть книга/слайды/статья»
💡 Но практика ≠ чтение.
На тренинге вы не слушаете лекции – вы работаете со своим продуктом.
И вдруг видите, как “картинка из статьи” начинает оживать.
3️⃣ «У меня нет команды, всё равно не с кем делать карту»
🐤 Зато у вас есть голова и понимание продукта.
Вы можете собрать карту сами – и принести её в команду как новый инструмент.
(Кстати, так чаще всего и начинается системная работа.)
4️⃣ «Сейчас не время»
❓ Тогда когда?
Если вы живёте в огне задач и зоопарке приоритетов –
это и есть сигнал, что пора остановиться и выстроить систему. Потому что “потом” = “никогда”.
⚡️ На тренинге «Управление бэклогом продукта и построение User Story Map»
мы не раздаём шаблоны. Мы учим смотреть на продукт по-другому:
✅ видеть связи;
✅ убирать шум из бэклога;
✅ строить карту, которая помогает принимать решения;
✅ аргументировать перед командой и стейкхолдерами
➡️ Старт – уже 20 мая.
Это шанс запрыгнуть в последний вагон
💭 Что говорят участники:
— Андрей Клят
— Алексей Кочемиров
💬 А вы себе что чаще всего говорите, чтобы отложить обучение?
Напишите в комментариях — может, пора это переформулировать👇
Звучит знакомо? Эти фразы мы слышим каждый раз перед стартом тренинга.
И да – они нормальные. Но часто за ними прячется главное:
Вот
У нас не “академия идеального продукта” – мы работаем с реальностью:
с багами, внезапными хотелками от CEO и задачами из «прошлой жизни».
На тренинге вы не слушаете лекции – вы работаете со своим продуктом.
И вдруг видите, как “картинка из статьи” начинает оживать.
Вы можете собрать карту сами – и принести её в команду как новый инструмент.
Если вы живёте в огне задач и зоопарке приоритетов –
это и есть сигнал, что пора остановиться и выстроить систему. Потому что “потом” = “никогда”.
мы не раздаём шаблоны. Мы учим смотреть на продукт по-другому:
Это шанс запрыгнуть в последний вагон
Тренинг был организован на высоком уровне и содержал только полезную информацию, которая была представлена без "воды" (как я люблю :)). Особенно хочется отметить, что на тренинге были разобраны все нюансы и детали, которые невозможно найти в книгах и статьях. Только практики с опытом могут поделиться такой информацией
— Андрей Клят
Очень рекомендую пройти данный тренинг всем, кто участвует в доставке и управляет изменениями в IT. Курс подойдёт как начинающим, так и опытным специалистам и лидерам изменений. Поднимете базу, узнаете много нового и залатаете свои ухабы в знаниях.
— Алексей Кочемиров
Напишите в комментариях — может, пора это переформулировать
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Иногда конфликт начинается не с громкого спора. А с тихого внутреннего: “Ну вот, опять…”
Это не “ты слишком чувствительный”.
Это – триггеры
Что такое триггер?
Это внутренний сигнал, на который включается автоматическая реакция.
Часто – не на саму ситуацию, а на что-то из прошлого опыта:
Несколько типичных триггеров:
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3❤1😁1