⚡️ Координация через структуру: кейс Salesforce
Раньше у Salesforce была классика: Sales, Customer Success и Professional Services под COO, а Engineering — отдельно, как в типовой IBM‑логике «продаём и кастомизируем здесь, строим там».
В 2025 всё перевернули: появился President & Chief Engineering and Customer Success Officer, под которым теперь Engineering + Customer Success Group + Global Professional Services — один центр власти за коробку, кастомизацию и эксплуатацию.
Николай Уоррен в Organization Design очень точно описывает, почему это работает:
А вы в своих компаниях сталкивались с похожими ходами — когда для устранения стыков функции их «сшивали» под одного руководителя?
Раньше у Salesforce была классика: Sales, Customer Success и Professional Services под COO, а Engineering — отдельно, как в типовой IBM‑логике «продаём и кастомизируем здесь, строим там».
В 2025 всё перевернули: появился President & Chief Engineering and Customer Success Officer, под которым теперь Engineering + Customer Success Group + Global Professional Services — один центр власти за коробку, кастомизацию и эксплуатацию.
Николай Уоррен в Organization Design очень точно описывает, почему это работает:
«Затраты на координацию внутри подразделения ниже, чем между подразделениями. В большинстве случаев люди, принадлежащие к одному и тому же юниту, эффективно координируют свои действия, потому что они подчиняются одному и тому же менеджеру, преследуют одни и те же цели и приоритеты, совместно используют одни и те же ресурсы и обычно работают в одних и тех же физических помещениях».Salesforce делает именно это: вместо того чтобы согласовывать решения между продуктом, кастомизацией и поддержкой, он просто сшивает их в одну вертикаль, снижая стоимость координации и минимизируя конфликты за счёт структуры, а не процессов.
А вы в своих компаниях сталкивались с похожими ходами — когда для устранения стыков функции их «сшивали» под одного руководителя?
👍5❤4🔥1💋1
⚡️Go See и аудит Скрам-команды — давно не испытывал такого кайфа
Я редко работаю на уровне отдельных команд — чаще это продуктовые группы и крупные бизнесы. Но каждый раз, когда иду в go see к конкретной команде, ловлю один и тот же эффект: очень чистый профессиональный кайф.
В этот раз аудит занял два дня (неделя календарно) и был именно исследованием: индивидуальные интервью с участниками команды, наблюдения за событиями и интервью с руководителями.
Команда сильная и вовлечённая, но на этом фоне хорошо видны паттерны, которые замедляют поток: высокая специализация, техдолг, большой WIP, фокус на индивидуальной работе и фактический мини-водопад.
По итогам я предложил цепочку Скрам-паттернов:
- жёсткий Definition of Done
- объём спринта по Yesterday Weather
- приоритеты по High Value First
- планирование задач на команду, не на людей
- используемая Цель Спринта
- Daily в потоковом режиме — фокус на завершении задач
- сворминг с WIP=1
- регулярный Обзор Спринта
В связке это даст ускорение в 2–3 раза за счёт снижения WIP и неизбежного выпрямления потока.
Если вы хотите ускорить свои команды, я могу провести такое же исследование для вас и показать, где потенциал для кратного ускорения.
Поделитесь фишками того, как вы проводите Go See?
Я редко работаю на уровне отдельных команд — чаще это продуктовые группы и крупные бизнесы. Но каждый раз, когда иду в go see к конкретной команде, ловлю один и тот же эффект: очень чистый профессиональный кайф.
В этот раз аудит занял два дня (неделя календарно) и был именно исследованием: индивидуальные интервью с участниками команды, наблюдения за событиями и интервью с руководителями.
Команда сильная и вовлечённая, но на этом фоне хорошо видны паттерны, которые замедляют поток: высокая специализация, техдолг, большой WIP, фокус на индивидуальной работе и фактический мини-водопад.
По итогам я предложил цепочку Скрам-паттернов:
- жёсткий Definition of Done
- объём спринта по Yesterday Weather
- приоритеты по High Value First
- планирование задач на команду, не на людей
- используемая Цель Спринта
- Daily в потоковом режиме — фокус на завершении задач
- сворминг с WIP=1
- регулярный Обзор Спринта
В связке это даст ускорение в 2–3 раза за счёт снижения WIP и неизбежного выпрямления потока.
Если вы хотите ускорить свои команды, я могу провести такое же исследование для вас и показать, где потенциал для кратного ускорения.
Поделитесь фишками того, как вы проводите Go See?
🔥23❤3
⚡️ Скрам-мастер ≠ ведущий Ежедневного Скрама
Этот пост навеян недавним аудитом одной Скрам‑команды.
Частый анти‑паттерн: Ежедневный Скрам ведёт Скрам‑мастер, по очереди задавая вопросы участникам.
Что получается:
- падает вовлечённость — остальные превращаются в слушателей;
- снижается внутренняя мотивация — встреча воспринимается как отчёт;
- проседает самоорганизация — команда ждёт, что её «проведут» через событие.
Скрам‑мастер не обязан вести Ежедневный Скрам. Его задача — научить команду, как проводить это событие так, чтобы оно помогало планировать день и управлять работой, а дальше отойти в сторону и дать команде вести Ежедневный Скрам самим.
Паттерн, который хорошо описывает такой переход: Scrum Master Incognito
А вы сталкивались с таким? Как лечите?
Этот пост навеян недавним аудитом одной Скрам‑команды.
Частый анти‑паттерн: Ежедневный Скрам ведёт Скрам‑мастер, по очереди задавая вопросы участникам.
Что получается:
- падает вовлечённость — остальные превращаются в слушателей;
- снижается внутренняя мотивация — встреча воспринимается как отчёт;
- проседает самоорганизация — команда ждёт, что её «проведут» через событие.
Скрам‑мастер не обязан вести Ежедневный Скрам. Его задача — научить команду, как проводить это событие так, чтобы оно помогало планировать день и управлять работой, а дальше отойти в сторону и дать команде вести Ежедневный Скрам самим.
Паттерн, который хорошо описывает такой переход: Scrum Master Incognito
А вы сталкивались с таким? Как лечите?
❤7💯2
⚡️ Продвинутая Heat Map: частота и специфичность
Разбирая по частям большой кейс структурирования продуктовой группы Daily Banking, начнём с создания продвинутой Heat Map. Добавим к частотности ещё и специфичность функций.
Специфичность в логике TCE — это то, насколько функция «привязана» к вашему контексту и продукто-специфична:
- низкая — универсальная, стандартная, можно централизовать (Commodity Platform);
- высокая — завязана на продукт, домен и архитектуру, выносить дорого из‑за координации, согласований и переделок.
В статье вы найдёте:
- четырёхуровневую шкалу частотности и специфичности;
- матрицу решений: что включать в продуктовую группу, что оставлять централизованным, а что отправлять в «consider»;
как за счёт этого очертить экономические границы юнита и не убиться в зависимостях.
Статья:
- https://agile-organizations.ru/tpost/2y4gikssf1-prodvinutaya-heat-map-chastota-i-spetsif (рус)
- https://www.scrum.org/resources/blog/advanced-heat-map-frequency-and-specificity (англ.)
Разбирая по частям большой кейс структурирования продуктовой группы Daily Banking, начнём с создания продвинутой Heat Map. Добавим к частотности ещё и специфичность функций.
Специфичность в логике TCE — это то, насколько функция «привязана» к вашему контексту и продукто-специфична:
- низкая — универсальная, стандартная, можно централизовать (Commodity Platform);
- высокая — завязана на продукт, домен и архитектуру, выносить дорого из‑за координации, согласований и переделок.
В статье вы найдёте:
- четырёхуровневую шкалу частотности и специфичности;
- матрицу решений: что включать в продуктовую группу, что оставлять централизованным, а что отправлять в «consider»;
как за счёт этого очертить экономические границы юнита и не убиться в зависимостях.
Статья:
- https://agile-organizations.ru/tpost/2y4gikssf1-prodvinutaya-heat-map-chastota-i-spetsif (рус)
- https://www.scrum.org/resources/blog/advanced-heat-map-frequency-and-specificity (англ.)
👍4🔥2
⚡️ Отличное завершение года
В этом году у меня было два крупных проекта по организационному дизайну. Оба начались весной, оба стартовали с Go See и тянулись до поздней осени. Но развивались по-разному.
Первый проект завершился не так, как я рассчитывал. Мы прошли Go See, обсуждали внедрение LeSS в одной из бизнес-единиц. Но на уровне борда поддержки не получили. Это напомнило простую вещь: без поддержки сверху даже лучшие решения остаются “в стол”.
Второй проект.
Это крупный банк. Всё также началось с Go See. Затем — обучение топ-менеджмента. А потом мы неожиданно застряли: пилот не мог стартовать. Причина оказалась почти драматичной: CEO, который должен был присутствовать на тренинге, был вызван в Центробанк, и ключевая часть знаний прошла мимо него.
Поэтому следующие месяцы мы посвятили тому, чтобы заново “продать” ему концепцию организационного дизайна. И получилась довольно зрелой — она создавалась по всем канонам подхода “Дизайн Agile-организаций”: от стратегии → к организационным способностям → к оргдизайну:
— Широкое определение продукта (“кредитные” и “некредитные” продукты)
— LeSS и фиче-команды
— HR-политики под развитие T-shape
— Кросс-функциональные линейные менеджеры у команд
С вдохновением заканчиваю год.
Впереди столько интересного!
В этом году у меня было два крупных проекта по организационному дизайну. Оба начались весной, оба стартовали с Go See и тянулись до поздней осени. Но развивались по-разному.
Первый проект завершился не так, как я рассчитывал. Мы прошли Go See, обсуждали внедрение LeSS в одной из бизнес-единиц. Но на уровне борда поддержки не получили. Это напомнило простую вещь: без поддержки сверху даже лучшие решения остаются “в стол”.
Второй проект.
Это крупный банк. Всё также началось с Go See. Затем — обучение топ-менеджмента. А потом мы неожиданно застряли: пилот не мог стартовать. Причина оказалась почти драматичной: CEO, который должен был присутствовать на тренинге, был вызван в Центробанк, и ключевая часть знаний прошла мимо него.
Поэтому следующие месяцы мы посвятили тому, чтобы заново “продать” ему концепцию организационного дизайна. И получилась довольно зрелой — она создавалась по всем канонам подхода “Дизайн Agile-организаций”: от стратегии → к организационным способностям → к оргдизайну:
— Широкое определение продукта (“кредитные” и “некредитные” продукты)
— LeSS и фиче-команды
— HR-политики под развитие T-shape
— Кросс-функциональные линейные менеджеры у команд
С вдохновением заканчиваю год.
Впереди столько интересного!
🎄20🔥9❤6
⚡️ Эффект Санта-Клауса и почему Agile-организации отказываются от формальных оценок
Накануне performance review все внезапно становятся примерными: ускоряются, демонстрируют инициативу, подчёркивают нужные достижения.
Это эффект Санта-Клауса: сотрудник старается выглядеть «хорошим ребёнком», который заслужил подарок. После оценки всё возвращается в нормальный ритм.
Когда один человек оценивает другого, возникает страх быть осуждённым.
К этому добавляется ещё одна токсичная практика — forced distribution. Она превращает коллег не в партнёров по работе, а в соперников за место в «верхней корзине».
Армин Трост сравнивает это с университетом: если бы профессор выставлял оценки по квотам, студентам пришлось бы прекратить учиться вместе — любая учебная группа просто распалась бы.
Так же распадаются и команды. Нельзя требовать сотрудничества и одновременно создавать систему, где успех одного зависит от неуспеха другого.
Именно поэтому Agile-организации отказываются от формальных оценок и квот. Их цель — не заставлять людей “хорошо выглядеть” раз в год, а создать среду, где они развиваются, учатся и усиливают друг друга каждый день.
А вы замечали эффект Санта Клауса? Если да, то к каким последствиям это приводило?
Накануне performance review все внезапно становятся примерными: ускоряются, демонстрируют инициативу, подчёркивают нужные достижения.
Это эффект Санта-Клауса: сотрудник старается выглядеть «хорошим ребёнком», который заслужил подарок. После оценки всё возвращается в нормальный ритм.
Когда один человек оценивает другого, возникает страх быть осуждённым.
К этому добавляется ещё одна токсичная практика — forced distribution. Она превращает коллег не в партнёров по работе, а в соперников за место в «верхней корзине».
Армин Трост сравнивает это с университетом: если бы профессор выставлял оценки по квотам, студентам пришлось бы прекратить учиться вместе — любая учебная группа просто распалась бы.
Так же распадаются и команды. Нельзя требовать сотрудничества и одновременно создавать систему, где успех одного зависит от неуспеха другого.
Именно поэтому Agile-организации отказываются от формальных оценок и квот. Их цель — не заставлять людей “хорошо выглядеть” раз в год, а создать среду, где они развиваются, учатся и усиливают друг друга каждый день.
А вы замечали эффект Санта Клауса? Если да, то к каким последствиям это приводило?
🔥11❤5
⚡ Три метрики адаптивности: сравниваем LeSS и SAFe
Выбор фреймворка — это не декоративное решение, а ответ на вопрос, какие организационные способности вы хотите развивать.
В статье я разбираю три метрики адаптивности и через эту призму сравниваю LeSS и SAFe:
- WIP продукта на конец итерации.
- Lead Time от идеи до потенциальной ценности.
- % задач продукта, доступных ≥80% команд (практическая цена переключения и взаимозаменяемость).
Если вы работаете на низкоконкурентных рынках, в условиях медленного регулирования и предсказуемого спроса, вам может быть достаточно SAFe с пересмотром курса раз в 8–12 недель на уровне PI.
Если же вы живёте в турбулентной среде — финтех, e‑commerce, онлайн‑сервисы, B2C с сильной конкуренцией — и хотите менять направление развития продукта каждые 1–4 недели при низком WIP и switching costs на уровне продукта, ваш выбор — LeSS.
Статья: https://agile-organizations.ru/tpost/o45kv8m951-tri-metriki-adaptivnosti-sravnivaem-less
Выбор фреймворка — это не декоративное решение, а ответ на вопрос, какие организационные способности вы хотите развивать.
В статье я разбираю три метрики адаптивности и через эту призму сравниваю LeSS и SAFe:
- WIP продукта на конец итерации.
- Lead Time от идеи до потенциальной ценности.
- % задач продукта, доступных ≥80% команд (практическая цена переключения и взаимозаменяемость).
Если вы работаете на низкоконкурентных рынках, в условиях медленного регулирования и предсказуемого спроса, вам может быть достаточно SAFe с пересмотром курса раз в 8–12 недель на уровне PI.
Если же вы живёте в турбулентной среде — финтех, e‑commerce, онлайн‑сервисы, B2C с сильной конкуренцией — и хотите менять направление развития продукта каждые 1–4 недели при низком WIP и switching costs на уровне продукта, ваш выбор — LeSS.
Статья: https://agile-organizations.ru/tpost/o45kv8m951-tri-metriki-adaptivnosti-sravnivaem-less
🔥11❤3
⚡️ Когда спайки превращают Скрам в мини-водопад
Столкнулся с командой, где каждый Спринт — это «спайк», и цикл превращается в мини‑водопад: один Спринт на PBR, второй на «spike», третий–четвёртый на реализацию, вместо нормального двухнедельного цикла поставки. При этом степень неопределённости вовсе не запредельная: под «спайками» скрывается обычная системная аналитика — разбор смежных систем, интерфейсов, архитектурных стыков, то есть нормальная работа Спринта, а не отдельный вид активности.
В XP настоящий spike — это короткий эксперимент для снятия конкретной технической неизвестности, а не удобный способ растянуть анализ. Это может быть микро‑прототип для проверки производительности БД, маленький клиент для реальной проверки внешнего API или страница с двумя вариантами UI‑библиотек, чтобы выбрать стек. У спайка есть жёсткие критерии: он создаётся только когда историю нельзя оценить, имеет одну исследовательскую цель, строгий таймбокс и даёт знание (решение, оценку, выбор подхода). Всё остальное честнее называть реализацией, а не spike.
А вы сталкивались с командами, которые под видом спайков по сути растягивают анализ и откладывают реальную поставку ценности?
Столкнулся с командой, где каждый Спринт — это «спайк», и цикл превращается в мини‑водопад: один Спринт на PBR, второй на «spike», третий–четвёртый на реализацию, вместо нормального двухнедельного цикла поставки. При этом степень неопределённости вовсе не запредельная: под «спайками» скрывается обычная системная аналитика — разбор смежных систем, интерфейсов, архитектурных стыков, то есть нормальная работа Спринта, а не отдельный вид активности.
В XP настоящий spike — это короткий эксперимент для снятия конкретной технической неизвестности, а не удобный способ растянуть анализ. Это может быть микро‑прототип для проверки производительности БД, маленький клиент для реальной проверки внешнего API или страница с двумя вариантами UI‑библиотек, чтобы выбрать стек. У спайка есть жёсткие критерии: он создаётся только когда историю нельзя оценить, имеет одну исследовательскую цель, строгий таймбокс и даёт знание (решение, оценку, выбор подхода). Всё остальное честнее называть реализацией, а не spike.
А вы сталкивались с командами, которые под видом спайков по сути растягивают анализ и откладывают реальную поставку ценности?
👍18❤3💯2
⚡️ Слово «пилот» опасно для организационных изменений?
В прошлом году на встрече с топ-менеджментом, где презентовалась новая модель организационного дизайна, часто звучало слово «пилот». Мы обсуждали первую группу 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