⚡️ Слово «пилот» опасно для организационных изменений?
В прошлом году на встрече с топ-менеджментом, где презентовалась новая модель организационного дизайна, часто звучало слово «пилот». Мы обсуждали первую группу feature-команд, которые перейдут на LeSS.
И один из топ-менеджеров предложил не называть это «пилотом».
Аргументация сильная: если называем изменения «пилотом», мы сигнализируем людям, что они могут не состояться. Пилот может быть успешным — а может не быть.
Такой сигнал подрывает восприятие неизбежности изменений.
Я полностью поддерживаю этот взгляд. Более того, в LeSS есть прямой гайдлайн — Guide: Parallel Organizations:
Иначе неизбежно появляются «ждуны» — люди, которые скептически относятся к изменениям, затаиваются и предпочитают «переждать», надеясь, что эксперимент закончится откатом.
Слово «пилот» создаёт для этого идеальное пространство. Интересно ваше мнение:
Как бы вы поступили? Стали бы называть это «пилотом» или выбрали бы другое название? Почему?
В прошлом году на встрече с топ-менеджментом, где презентовалась новая модель организационного дизайна, часто звучало слово «пилот». Мы обсуждали первую группу feature-команд, которые перейдут на LeSS.
И один из топ-менеджеров предложил не называть это «пилотом».
Аргументация сильная: если называем изменения «пилотом», мы сигнализируем людям, что они могут не состояться. Пилот может быть успешным — а может не быть.
Такой сигнал подрывает восприятие неизбежности изменений.
Я полностью поддерживаю этот взгляд. Более того, в LeSS есть прямой гайдлайн — Guide: Parallel Organizations:
«Сообщайте совершенно ясно, что со временем все будут работать в новой организации. Это важное послание: оно не даёт людям в старой организации сосредоточиться на cопротивлении.»
Иначе неизбежно появляются «ждуны» — люди, которые скептически относятся к изменениям, затаиваются и предпочитают «переждать», надеясь, что эксперимент закончится откатом.
Слово «пилот» создаёт для этого идеальное пространство. Интересно ваше мнение:
Как бы вы поступили? Стали бы называть это «пилотом» или выбрали бы другое название? Почему?
👍15🔥7🤔4
⚡️Как вы провели праздничные дни?
Праздничные дни у меня вышли довольно неоднозначными. Самыми приятными и осмысленными стали несколько дней в Петербурге прямо перед Новым годом: Русский музей с авангардом, Малевич, Кандинский и другие, а затем Главный Штаб Эрмитажа, где мечта наконец сбывается — в зале «Танец» и «Музыка» Матисса вживую оказываются мощнее любых репродукций.
Сильное впечатление оставило и Царское Село: Екатерининский дворец и особенно Александровский, последняя резиденция Николая II, где почти физически ощущается эффект «они только что ушли, а ты пришел чуть позже».
Уже после Нового года было несколько продуктивных рабочих дней и работа над новыми концепциями стратегического менеджмента: типами продуктовых групп и связанностью портфеля — к этому скоро выйдут отдельные тексты.
Финал длинных выходных оказался менее радужным: на пять дней загремел в больницу с инфекцией, но уже вернулся, выбрался из этого вынужденного «ретрита» и потихоньку возвращаюсь к тренировкам и рабочему ритму.
А как прошли ваши праздничные дни?
Праздничные дни у меня вышли довольно неоднозначными. Самыми приятными и осмысленными стали несколько дней в Петербурге прямо перед Новым годом: Русский музей с авангардом, Малевич, Кандинский и другие, а затем Главный Штаб Эрмитажа, где мечта наконец сбывается — в зале «Танец» и «Музыка» Матисса вживую оказываются мощнее любых репродукций.
Сильное впечатление оставило и Царское Село: Екатерининский дворец и особенно Александровский, последняя резиденция Николая II, где почти физически ощущается эффект «они только что ушли, а ты пришел чуть позже».
Уже после Нового года было несколько продуктивных рабочих дней и работа над новыми концепциями стратегического менеджмента: типами продуктовых групп и связанностью портфеля — к этому скоро выйдут отдельные тексты.
Финал длинных выходных оказался менее радужным: на пять дней загремел в больницу с инфекцией, но уже вернулся, выбрался из этого вынужденного «ретрита» и потихоньку возвращаюсь к тренировкам и рабочему ритму.
А как прошли ваши праздничные дни?
❤13🔥5
Иногда кажется, что карьерный путь уже написан заранее.
Аналитик → тимлид → менеджер → руководитель.
И вроде всё логично и понятно, что дальше.
А потом шаг в сторону.
Ещё шаг.
И через несколько лет ты уже CPO не b2b и не b2c, а сложных инструментов для разработки - API, SDK, интеграций, фреймворков. Тех самых продуктов, которые почти никто не видит, но без которых ничего не работает.
Это история Артёма.
После универа рост до Head of PMO в Сбере.
Потом директор по технологическому развитию там же.
Дальше продуктовый офис Яндекса.
Теперь Авито.
(Кстати, вот пост про уход из Яндекса.)
Но на самом деле это история не про должности.
А про момент, когда ты наконец находишь работу, от которой по-настоящему кайфуешь. И то редкое состояние, когда хочется обнять коллег вокруг.
А что у него внутри?
- исследования о том, почему инженер теряет до 3 часов в день на переключении контекста
- разборы того, как Google «заглядывает в голову» инженерам (без магии — только процессы)
- продуктовый подход к разработке, DevEx и внутренним платформам
- карьерные истории без глянца и с юмором
- и авторские обзоры книг и фильмов, которые реально цепляют
Короче, если интересно, как живут и развиваются нестандартные продукты - идем к Артёму 😉
Аналитик → тимлид → менеджер → руководитель.
И вроде всё логично и понятно, что дальше.
А потом шаг в сторону.
Ещё шаг.
И через несколько лет ты уже CPO не b2b и не b2c, а сложных инструментов для разработки - API, SDK, интеграций, фреймворков. Тех самых продуктов, которые почти никто не видит, но без которых ничего не работает.
Это история Артёма.
После универа рост до Head of PMO в Сбере.
Потом директор по технологическому развитию там же.
Дальше продуктовый офис Яндекса.
Теперь Авито.
(Кстати, вот пост про уход из Яндекса.)
Но на самом деле это история не про должности.
А про момент, когда ты наконец находишь работу, от которой по-настоящему кайфуешь. И то редкое состояние, когда хочется обнять коллег вокруг.
А что у него внутри?
- исследования о том, почему инженер теряет до 3 часов в день на переключении контекста
- разборы того, как Google «заглядывает в голову» инженерам (без магии — только процессы)
- продуктовый подход к разработке, DevEx и внутренним платформам
- карьерные истории без глянца и с юмором
- и авторские обзоры книг и фильмов, которые реально цепляют
Короче, если интересно, как живут и развиваются нестандартные продукты - идем к Артёму 😉
❤3🔥2
⚡️Насколько согласован ваш бизнес-портфель?
Мы много говорим про продуктовые команды и продуктовые группы, но почти не задаём более базовый вопрос: а как вообще устроен бизнес-портфель компании и какой ценой достигается текущий уровень централизации или автономии?
В новой статье я разбираю четыре архетипа бизнес-портфеля — от единого интегрированного бизнеса до холдинга — и показываю, как именно выбор архетипа «простреливает» структуру, процессы, систему вознаграждения и культуру. По сути, это разговор о том, где вы на континууме «одна большая интегрированная машина» vs «набор почти независимых бизнесов» и насколько честно операционная модель соответствует этому выбору.
Ключевая мысль: невозможно одновременно быть супергибкими и на уровне всей компании, и на уровне каждого BU / продуктовой группы. Чем выше интеграция, тем больше синергий, масштаба и управляемости портфеля, но тем ниже локальная адаптивность и скорость. Чем больше разделение, тем сильнее локальное предпринимательство и product–market fit, но тем дороже зоопарк процессов, платформ и команд.
Во второй части статьи я прохожусь по плюсам и минусам централизации и децентрализации и предлагаю диагностический инструмент на четыре вопроса: какой тип портфеля логичен вашей стратегии, какой у вас по факту, с какими издержками вы готовы мириться и что нужно поменять в «звезде» Гилбрейта (strategy, structure, processes, rewards, people), чтобы портфель и операционная модель наконец-то совпали.
Русская версия статьи — в блоге Agile Организаций:
Английская версия — в блоге Scrum[.]org
Если вы как раз спорите внутри компании, что централизовать, а что отдавать на уровень бизнес-юнитов, эта оптика и диагностический набор вопросов могут сильно упростить разговор.
Кстати, а какой у вас тип связанности портфеля (Single Integrated Business, Closely Related Portfolio, Loosely Related Portfolio, Holding)?
Мы много говорим про продуктовые команды и продуктовые группы, но почти не задаём более базовый вопрос: а как вообще устроен бизнес-портфель компании и какой ценой достигается текущий уровень централизации или автономии?
В новой статье я разбираю четыре архетипа бизнес-портфеля — от единого интегрированного бизнеса до холдинга — и показываю, как именно выбор архетипа «простреливает» структуру, процессы, систему вознаграждения и культуру. По сути, это разговор о том, где вы на континууме «одна большая интегрированная машина» vs «набор почти независимых бизнесов» и насколько честно операционная модель соответствует этому выбору.
Ключевая мысль: невозможно одновременно быть супергибкими и на уровне всей компании, и на уровне каждого BU / продуктовой группы. Чем выше интеграция, тем больше синергий, масштаба и управляемости портфеля, но тем ниже локальная адаптивность и скорость. Чем больше разделение, тем сильнее локальное предпринимательство и product–market fit, но тем дороже зоопарк процессов, платформ и команд.
Во второй части статьи я прохожусь по плюсам и минусам централизации и децентрализации и предлагаю диагностический инструмент на четыре вопроса: какой тип портфеля логичен вашей стратегии, какой у вас по факту, с какими издержками вы готовы мириться и что нужно поменять в «звезде» Гилбрейта (strategy, structure, processes, rewards, people), чтобы портфель и операционная модель наконец-то совпали.
Русская версия статьи — в блоге Agile Организаций:
Английская версия — в блоге Scrum[.]org
Если вы как раз спорите внутри компании, что централизовать, а что отдавать на уровень бизнес-юнитов, эта оптика и диагностический набор вопросов могут сильно упростить разговор.
Кстати, а какой у вас тип связанности портфеля (Single Integrated Business, Closely Related Portfolio, Loosely Related Portfolio, Holding)?
🔥5❤2✍2👍2
⚡️В командах нет индивидуальной продуктивности
В командах не существует индивидуальной продуктивности. Армин Трост подчёркивает: в динамичной, связанной работе индивидуальные цели становятся токсичными, потому что успех возможен только на уровне всей системы, а не отдельного человека. Производительность создаётся командой, а не индивидуумом.
Его пример с экспедицией на Нанга-Парбат: ни один участник не ставит себе цель «дойти быстрее всех». Такое поведение ставит под угрозу и команду, и самого альпиниста.
Причина проста: внутри команды действуют взаимные (reciprocal) зависимости. Например, дизайн, аналитика, дискавери, архитектура, код и тестирование — не последовательные этапы, а взаимно влияющие друг на друга процессы. В такой системе нет изолированных вкладов, а значит, нет и индивидуальной продуктивности.
То же самое применимо к мультикомандной разработке. Когда две и более команд работают над одним продуктом — как в LeSS — ставить долгосрочные цели на уровне отдельных команд губительно. Команды работают с единым Бэклогом Продукта, создают одну ценность и образуют одну систему.
Если дать им раздельные долгосрочные цели, начнётся локальная оптимизация: борьба за приоритеты, конкуренция, ухудшение интеграции и т.д.
Именно поэтому в LeSS у команд одна продуктовая цель. Потому что ценность создаётся совместно.
Команда — или группа команд — это единственная реальная единица продуктивности.
На каком уровне вы ставите цели?
В командах не существует индивидуальной продуктивности. Армин Трост подчёркивает: в динамичной, связанной работе индивидуальные цели становятся токсичными, потому что успех возможен только на уровне всей системы, а не отдельного человека. Производительность создаётся командой, а не индивидуумом.
Его пример с экспедицией на Нанга-Парбат: ни один участник не ставит себе цель «дойти быстрее всех». Такое поведение ставит под угрозу и команду, и самого альпиниста.
Причина проста: внутри команды действуют взаимные (reciprocal) зависимости. Например, дизайн, аналитика, дискавери, архитектура, код и тестирование — не последовательные этапы, а взаимно влияющие друг на друга процессы. В такой системе нет изолированных вкладов, а значит, нет и индивидуальной продуктивности.
То же самое применимо к мультикомандной разработке. Когда две и более команд работают над одним продуктом — как в LeSS — ставить долгосрочные цели на уровне отдельных команд губительно. Команды работают с единым Бэклогом Продукта, создают одну ценность и образуют одну систему.
Если дать им раздельные долгосрочные цели, начнётся локальная оптимизация: борьба за приоритеты, конкуренция, ухудшение интеграции и т.д.
Именно поэтому в LeSS у команд одна продуктовая цель. Потому что ценность создаётся совместно.
Команда — или группа команд — это единственная реальная единица продуктивности.
На каком уровне вы ставите цели?
❤6👍4💯3😢1
⚡️ Когда нет «классических» KPI
На этой неделе проводил экспресс‑аудит производственной компании в Челябинске. Разбирая их оргдизайн, я не увидел классических KPI и бонусов, привязанных к наградам и наказаниям: во всех подразделениях, включая продажи, у людей стабильная зарплата, которая отражает их роль и набор навыков.
При этом увидел высокий уровень вовлечённости: люди интересуются продуктом, хотят учиться и развиваться внутри компании.
Речь не про бирюзу, а про нормальную практику: KPI и метрики есть, но они нейтральны и используются как язык, чтобы понимать, что происходит с продуктом, процессом и системой, а не как рычаг давления и манипуляции людьми.
За связкой «KPI → бонус/штраф» стоит ментальная модель «люди ленивы, работать не хотят, их надо подталкивать деньгами», и именно она превращает показатели в мишень для игр и манипуляций.
А как у вас устроены KPI и вознаграждение: метрики — это нейтральный компас для разговора о работе или инструмент давления / манипуляции?
На этой неделе проводил экспресс‑аудит производственной компании в Челябинске. Разбирая их оргдизайн, я не увидел классических KPI и бонусов, привязанных к наградам и наказаниям: во всех подразделениях, включая продажи, у людей стабильная зарплата, которая отражает их роль и набор навыков.
При этом увидел высокий уровень вовлечённости: люди интересуются продуктом, хотят учиться и развиваться внутри компании.
Речь не про бирюзу, а про нормальную практику: KPI и метрики есть, но они нейтральны и используются как язык, чтобы понимать, что происходит с продуктом, процессом и системой, а не как рычаг давления и манипуляции людьми.
За связкой «KPI → бонус/штраф» стоит ментальная модель «люди ленивы, работать не хотят, их надо подталкивать деньгами», и именно она превращает показатели в мишень для игр и манипуляций.
А как у вас устроены KPI и вознаграждение: метрики — это нейтральный компас для разговора о работе или инструмент давления / манипуляции?
👍26❤3💘1
⚡️ Agile‑кэмп 20–21 февраля
Последние полгода у меня были плотно забиты, и хотя мы уже привыкли делать по два кэмпа в год — летний и зимний — до зимнего анонса так и не дошли руки. В итоге инициативу перехватил Анатолий Мелентьев: он собрал страницу кэмпа на сайте, а я со своей стороны готов позвать вас в гости.
20–21 февраля устроим двухдневный Agile‑кэмп в Коломне: зимой в беседке не посидишь, поэтому делаем камерный формат — в доме такой группе до 15 человек будет суперкомфортно. Приезжайте, попаримся в бане, разберём ваши кейсы, поговорим про оргдизайн и трансформации — будет много живого общения и возможностей докрутить ваши реальные ситуации.
Хотите приехать на этот камерный зимний кэмп 20–21 февраля? Регистрируйтесь по ссылке: https://scrum.ru/camp
Последние полгода у меня были плотно забиты, и хотя мы уже привыкли делать по два кэмпа в год — летний и зимний — до зимнего анонса так и не дошли руки. В итоге инициативу перехватил Анатолий Мелентьев: он собрал страницу кэмпа на сайте, а я со своей стороны готов позвать вас в гости.
20–21 февраля устроим двухдневный Agile‑кэмп в Коломне: зимой в беседке не посидишь, поэтому делаем камерный формат — в доме такой группе до 15 человек будет суперкомфортно. Приезжайте, попаримся в бане, разберём ваши кейсы, поговорим про оргдизайн и трансформации — будет много живого общения и возможностей докрутить ваши реальные ситуации.
Хотите приехать на этот камерный зимний кэмп 20–21 февраля? Регистрируйтесь по ссылке: https://scrum.ru/camp
❤8🔥7😢1
⚡️ Экспресс-аудит компании за 3 дня
На прошлой неделе я провёл экспресс‑аудит небольшой компании (250+ человек) и по итогам сделал 14‑страничный отчёт. По контракту было всего три дня — при таком масштабе это мало, но при правильном дизайне формата можно успеть достаточно, чтобы увидеть системные вещи.
В первый день я провёл восемь интервью с руководителями ключевых функций, чтобы войти в контекст и увидеть повторяющиеся паттерны в управлении и работе цепочки.
Затем разобрал официальную оргструктуру и выделил узлы, которые требовали более глубокого анализа.
На этой базе мы провели коллаборативный воркшоп по функциональной связанности: выписали все подразделения и их функции и нашли три зоны, где есть дублирование полномочий и связанность между подразделениями. Именно там концентрируются рост сложности изменений, высокие координационные издержки, снижение предсказуемости, задержки и конфликты ответственности.
Следующий воркшоп был про ключевые организационные способности и стратегический фокус. В малых группах сформулировали способности, которые важно сохранить и развивать, и согласились, что основной стратегический фокус компании сейчас — операционный, что даёт ориентир для создания стратегии и организационной структуры.
Отдельно мы посмотрели на операционные зависимости между функциями второго уровня и собрали большую DSM‑матрицу 23×23. После оцифровки и оптимизации стало видно, что возможна более удачная группировка функций, чем текущая, — с меньшей связанностью и более плотными кластерами.
Параллельно запустили работу по стратегии через «Карту гипотез» с горизонтом в месяц: гипотезы мы сознательно привязываем к операционному фокусу и тем организационным способностям, которые компания хочет сохранить и развивать.
Все эти инструменты — работа со связанностью, способностями, операционными зависимостями и стратегией — лежат в основе тренинга Designing Agile Organizations (DAO), который создан по материалам книги «Дизайн Agile‑организаций». Ближайший поток пройдёт 26–27 февраля в онлайн‑формате и ориентирован на агентов изменений, а также топ‑руководителей компаний и крупных подразделений. Присоединяйтесь!
А вы делали экспресс‑аудиты — что удавалось увидеть за несколько дней, а что принципиально не помещается в такой формат?
На прошлой неделе я провёл экспресс‑аудит небольшой компании (250+ человек) и по итогам сделал 14‑страничный отчёт. По контракту было всего три дня — при таком масштабе это мало, но при правильном дизайне формата можно успеть достаточно, чтобы увидеть системные вещи.
В первый день я провёл восемь интервью с руководителями ключевых функций, чтобы войти в контекст и увидеть повторяющиеся паттерны в управлении и работе цепочки.
Затем разобрал официальную оргструктуру и выделил узлы, которые требовали более глубокого анализа.
На этой базе мы провели коллаборативный воркшоп по функциональной связанности: выписали все подразделения и их функции и нашли три зоны, где есть дублирование полномочий и связанность между подразделениями. Именно там концентрируются рост сложности изменений, высокие координационные издержки, снижение предсказуемости, задержки и конфликты ответственности.
Следующий воркшоп был про ключевые организационные способности и стратегический фокус. В малых группах сформулировали способности, которые важно сохранить и развивать, и согласились, что основной стратегический фокус компании сейчас — операционный, что даёт ориентир для создания стратегии и организационной структуры.
Отдельно мы посмотрели на операционные зависимости между функциями второго уровня и собрали большую DSM‑матрицу 23×23. После оцифровки и оптимизации стало видно, что возможна более удачная группировка функций, чем текущая, — с меньшей связанностью и более плотными кластерами.
Параллельно запустили работу по стратегии через «Карту гипотез» с горизонтом в месяц: гипотезы мы сознательно привязываем к операционному фокусу и тем организационным способностям, которые компания хочет сохранить и развивать.
Все эти инструменты — работа со связанностью, способностями, операционными зависимостями и стратегией — лежат в основе тренинга Designing Agile Organizations (DAO), который создан по материалам книги «Дизайн Agile‑организаций». Ближайший поток пройдёт 26–27 февраля в онлайн‑формате и ориентирован на агентов изменений, а также топ‑руководителей компаний и крупных подразделений. Присоединяйтесь!
А вы делали экспресс‑аудиты — что удавалось увидеть за несколько дней, а что принципиально не помещается в такой формат?
🔥7😁2🤔1
⚡️ Как стратегический фокус усиливает Карту Гипотез
Для меня Карта Гипотез — главный рабочий инструмент для стратегии: я использую её с каждым клиентом.
Поэтому перед тем как создавать карту, я всегда делаю один шаг до: помогаю команде стратегов честно ответить на два вопроса:
1. Вокруг чего мы хотим выигрывать — продукта, клиента или операций?
2. Какие организационные способности нам нужно сохранить и развить?
Сначала — коллаборативный воркшоп, где мы определяем стратегический фокус по Treacy–Wiersema и собираем набор ключевых capabilities. Уже потом — Карта Гипотез, где каждая гипотеза проверяется на два фильтра:
– поддерживает ли она выбранный фокус;
– какую способность усиливает: продуктовую, клиентскую или операционную.
Так карта превращается в стратегический компас: вы не просто генерируете гипотезы, а системно прокачиваете ту операционную систему, на которой хотите выигрывать рынок.
Полную версию статьи читаем здесь.
А вы сейчас чётко видите свой стратегический фокус или пытаетесь быть «лучшими во всём» одновременно?
Для меня Карта Гипотез — главный рабочий инструмент для стратегии: я использую её с каждым клиентом.
Поэтому перед тем как создавать карту, я всегда делаю один шаг до: помогаю команде стратегов честно ответить на два вопроса:
1. Вокруг чего мы хотим выигрывать — продукта, клиента или операций?
2. Какие организационные способности нам нужно сохранить и развить?
Сначала — коллаборативный воркшоп, где мы определяем стратегический фокус по Treacy–Wiersema и собираем набор ключевых capabilities. Уже потом — Карта Гипотез, где каждая гипотеза проверяется на два фильтра:
– поддерживает ли она выбранный фокус;
– какую способность усиливает: продуктовую, клиентскую или операционную.
Так карта превращается в стратегический компас: вы не просто генерируете гипотезы, а системно прокачиваете ту операционную систему, на которой хотите выигрывать рынок.
Полную версию статьи читаем здесь.
А вы сейчас чётко видите свой стратегический фокус или пытаетесь быть «лучшими во всём» одновременно?
❤5🔥5👍1👏1
⚡ Фолкнер. Шум и ярость
Прочитал «Шум и ярость». Очень сильная вещь. Модернистский роман, написанный в стиле потока сознания — и это совсем другой опыт чтения.
Первые главы тяжело идут: всё рвётся, время скачет, предложения обрываются. Но потом начинаешь видеть общий рисунок — как будто из отдельных мазков постепенно проступает картина. Такой себе импрессионизм, только в прозе.
История падения семьи Компсонов в Миссисипи в начале XX века. Четыре рассказчика — каждый по‑своему смотрит на одни и те же события.
Необычный прием — курсив: им выделены куски, которые выдёргивают из текущей сцены и переносят в другое время. Сначала роман кажется полной кашей, а потом всё встаёт на свои места.
Роман Фолкнера заслуженно занимает место в топ-100 лучших произведений мировой литературы. Проверено! 😁
А вы читали что‑нибудь такое же странное?
Прочитал «Шум и ярость». Очень сильная вещь. Модернистский роман, написанный в стиле потока сознания — и это совсем другой опыт чтения.
Первые главы тяжело идут: всё рвётся, время скачет, предложения обрываются. Но потом начинаешь видеть общий рисунок — как будто из отдельных мазков постепенно проступает картина. Такой себе импрессионизм, только в прозе.
История падения семьи Компсонов в Миссисипи в начале XX века. Четыре рассказчика — каждый по‑своему смотрит на одни и те же события.
Необычный прием — курсив: им выделены куски, которые выдёргивают из текущей сцены и переносят в другое время. Сначала роман кажется полной кашей, а потом всё встаёт на свои места.
Роман Фолкнера заслуженно занимает место в топ-100 лучших произведений мировой литературы. Проверено! 😁
А вы читали что‑нибудь такое же странное?
❤7👍2🔥2
⚡️ Три типа продуктовых групп: как далеко заходить в автономию?
В книге Creating Agile Organizations мы описывали продуктовую группу как полноценную бизнес‑единицу вокруг продуктового семейства, с собственным лидером, ресурсами и правами на решения. Со временем стало очевидно, что «продуктовая группа» — это прежде всего контейнер для интеграции и координации, а не обязательно отдельный дивизион.
В новой статье я разбираю три типа продуктовых групп, которые на практике оказываются точками на спектре формализации и автономии:
Логическая (виртуальная) продуктовая группа — продуктовый слой поверх функций: выравнивание целей, ролей и программ без выделения отдельной структуры.
Продуктовая группа с частично выделенными функциями — часть ключевых ролей (product, маркетинг, часть инженеров, аналитика) живёт внутри группы, остальные остаются shared.
Полуавтономная продуктовая группа — под одним «контейнером» собираются product, tech, операции, маркетинг, продажи и поддержка; зависимость от shared‑функций минимальна и опциональна.
Через призму связанности портфеля (единый интегрированный бизнес, тесно связанный портфель, слабосвязанный портфель) эти типы помогают трезво выбирать, где уместна централизация, а где — сильная автономия. Собственно, вокруг этих решений мы как раз и работаем на онлайн‑тренинге Designing Agile Organizations (DAO) 26–27 февраля: разбираем, как увязать бизнес‑архитектуру, тип продуктовой группы и оргдизайн.
Полная версия статьи:
- Русская версия
- Английская версия
А у вас сейчас продуктовые группы ближе к логическим, частично выделенным или уже полуавтономным?
В книге Creating Agile Organizations мы описывали продуктовую группу как полноценную бизнес‑единицу вокруг продуктового семейства, с собственным лидером, ресурсами и правами на решения. Со временем стало очевидно, что «продуктовая группа» — это прежде всего контейнер для интеграции и координации, а не обязательно отдельный дивизион.
В новой статье я разбираю три типа продуктовых групп, которые на практике оказываются точками на спектре формализации и автономии:
Логическая (виртуальная) продуктовая группа — продуктовый слой поверх функций: выравнивание целей, ролей и программ без выделения отдельной структуры.
Продуктовая группа с частично выделенными функциями — часть ключевых ролей (product, маркетинг, часть инженеров, аналитика) живёт внутри группы, остальные остаются shared.
Полуавтономная продуктовая группа — под одним «контейнером» собираются product, tech, операции, маркетинг, продажи и поддержка; зависимость от shared‑функций минимальна и опциональна.
Через призму связанности портфеля (единый интегрированный бизнес, тесно связанный портфель, слабосвязанный портфель) эти типы помогают трезво выбирать, где уместна централизация, а где — сильная автономия. Собственно, вокруг этих решений мы как раз и работаем на онлайн‑тренинге Designing Agile Organizations (DAO) 26–27 февраля: разбираем, как увязать бизнес‑архитектуру, тип продуктовой группы и оргдизайн.
Полная версия статьи:
- Русская версия
- Английская версия
А у вас сейчас продуктовые группы ближе к логическим, частично выделенным или уже полуавтономным?
❤4
⚡️Почему бизнес давит на разработку, а техдолг растёт нелинейно
Проводя недавнее исследование (Go See), столкнулся с типичной динамикой.
Бизнес давит на разработку. Команда в ответ на давление снижает качество. На коротком отрезке это действительно ускоряет. Но дальше начинается нелинейный рост технического долга, который в средне- и долгосрочной перспективе резко замедляет разработку.
Параллельно всплывают старые баги, которые «уже вроде фиксили». Они начинают постоянно отвлекать фокус разработчиков, увеличивают переключения и ещё сильнее замедляют поток.
Возникает привычный вопрос: кто виноват?
Плохая новость — обе стороны ведут себя непрофессионально. Бизнес не имеет права давить на разработчиков и требовать снижения качества. Разработчики не имеют права отвечать на давление отказом от тестов и «срезанием углов».
Но ещё важнее другое: это не проблема людей. Это системная проблема.
Посмотрите на системную диаграмму, которую я приложил к посту. Бизнес давит не потому, что он «злой» или «не понимает разработку», а потому что в организационном дизайне награды привязаны к плану работ, скоупу и доставке фич. Давление — рациональное поведение в такой системе.
Это и есть ключевой негативный организационный фактор.
Пока награды завязаны на объём обещанного и отгруженного скоупа, система будет:
— поощрять давление
— толкать к компромиссам с качеством
— производить технический долг
— и сама себя замедлять
Рецепт здесь не сложный, но неприятный.
Уберите награды, привязанные к скоупу. Не идите на компромиссы с качеством как «временное решение».
А вы сталкивались с подобным? Что делали?
Проводя недавнее исследование (Go See), столкнулся с типичной динамикой.
Бизнес давит на разработку. Команда в ответ на давление снижает качество. На коротком отрезке это действительно ускоряет. Но дальше начинается нелинейный рост технического долга, который в средне- и долгосрочной перспективе резко замедляет разработку.
Параллельно всплывают старые баги, которые «уже вроде фиксили». Они начинают постоянно отвлекать фокус разработчиков, увеличивают переключения и ещё сильнее замедляют поток.
Возникает привычный вопрос: кто виноват?
Плохая новость — обе стороны ведут себя непрофессионально. Бизнес не имеет права давить на разработчиков и требовать снижения качества. Разработчики не имеют права отвечать на давление отказом от тестов и «срезанием углов».
Но ещё важнее другое: это не проблема людей. Это системная проблема.
Посмотрите на системную диаграмму, которую я приложил к посту. Бизнес давит не потому, что он «злой» или «не понимает разработку», а потому что в организационном дизайне награды привязаны к плану работ, скоупу и доставке фич. Давление — рациональное поведение в такой системе.
Это и есть ключевой негативный организационный фактор.
Пока награды завязаны на объём обещанного и отгруженного скоупа, система будет:
— поощрять давление
— толкать к компромиссам с качеством
— производить технический долг
— и сама себя замедлять
Рецепт здесь не сложный, но неприятный.
Уберите награды, привязанные к скоупу. Не идите на компромиссы с качеством как «временное решение».
А вы сталкивались с подобным? Что делали?
🔥12👍5❤2👎1