Как помочь команде решить любую проблему

В предыдущей статье мы рассмотрели полезную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой. POSIWID прекрасно работает для любой социальной системы: команды, продуктовой группы, организации и т.д. Давайте посмотрим на ее применение в командном контексте.

POSIWID на командном уровне

Чтобы взять на вооружение POSIWID («Purpose Of the System Is What It Does»), нужно ответить последовательно на несколько вопросов: 

  1. Какая заявляемая цель системы?  
  2. Как ведет себя система?  
  3. Что говорит поведение системы о цели системы?
  4. Есть ли соответствие между заявленной и фактической целью?  
  5. Если это не так, как выглядит структура системы?  
  6. Как мы можем изменить структуру системы, чтобы получить новое поведение?

Проиллюстрируем алгоритм на примере команды, с которой мы работали некоторое время назад. 

Читать далее «Как помочь команде решить любую проблему»

Определение продукта в LeSS. Часть 1.

Перевод оригинальной статьи Сезарио Рамоса.

Это первая часть серии блог-постов об определении продукта в LeSS.

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

Узкое определение продукта создает различного рода проблемы для продуктовой группы. Узкое определение продукта локально оптимизирует производительность команд за счет производительности группы. Системная диаграмма (CLD) ниже объясняет эту динамику. 

(См. Этот блог-пост для краткого обзора обозначения CLD.)

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

Устраните локальную оптимизацию узкого определения продукта

Часто используемое определение продукта – «что-то, что сделано для продажи». Продукт обеспечивает способ извлечения прибыли.

  • У продукта есть пользователи, люди;
  • Продукт предоставляет базовую функциональность, которая закрывает проблемы и отвечает потребностям пользователей;
  • Продукт имеет бизнес-модель, источники доходов, независимую прибыль и убыток (P&L) или возврат инвестиций (ROI).
  • Продукт разрабатывается и поддерживается системой людей, компонентов и процессов.

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

Как определить продукт?

Определение продукта включает в себя несколько компонентов, действий и предоставляет решения для потребностей и проблем конечных пользователей. Вы можете определить свой продукт, используя следующие два шага:

Шаг 1 — Определите необходимые организационные элементы для разработки и поддержки продукта.

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

Типичные шаги для достижения этой цели:

  • Определите типичных внешних конечных пользователей для вашей группы.
  • Определите постоянные потребности, которые эти конечные пользователи хотят решить, или задачи, которые они должны выполнить.
  • Определите фичи для каждого из пользователей, которые они используют для удовлетворения потребностей или выполнения своей работы.
  • Определите каналы, через которые пользователи используют функции для удовлетворения своих потребностей/проблем и т. д. (Например, Браузер, Приложение, API, Connector или Helpdesk)
  • Затем, определите организационные элементы, которые вам необходимы для разработки фичи и удовлетворения пользователя. Сделайте это, изучая путь, как каждый элемент функциональности проходит через вашу организацию в руки клиента. Начните с каналов, проработайте компоненты, системы, людей и процессы до конца пользовательского пути.

Шаг 2 – Проясните источники доходов

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

На этом шаге задайте вопросы вопросы: “Производят ли идентифицированные организационные элементы продукт, который генерирует доход для организации? Или есть недостающие части для этого?”. Также неплохо найти ответы на следующие вопросы:

  • Как элементы вместе генерируют деньги? Например, может ли определение продукта иметь плату за использование? Продажа активов? Абонентская плата? Лицензирование? Если нет, что нужно добавить к определению продукта?
  • Имеет ли определение продукта независимый P&L? Если нет, то какие организационные элементы отсутствуют? 
  • Какие KPI можно назначить определению продукта? Например, можете ли вы назначить увеличение валового дохода? Увеличение новых клиентов? Удовлетворенность клиентов?

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

Определение продукта завершено?

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

С такой большой группой вы можете спросить себя: «Как я могу создать эффективные кросс-функциональные команды, которые включают все эти компетенции? В случае более чем десяти групп, мы рекомендуем организовать команды среди Области Ценностей  и содержать зависимости для каждой области.

Это тема моего следующего блога.

Скрам-мастер как организационный коуч

Скрам-мастер оказывает сервисы по трем направлениям: Команде Разработке, Владельцу Продукта и организации. Чтобы быть успешным лидером-слугой, он должен уделять значительное время коучингу организации. Это важно, потому что Скрам-команды сталкиваются с множеством препятствий, которые ни они сами, ни Скрам-мастера не могут преодолеть самостоятельно. Даже самому стойкому Скрам-мастеру необходима помощь.

Эта статья будет полезна Скрам-мастерам, которые ищут конкретные примеры организационного коучинга. Я поделюсь с вами эпизодом, в котором была вовлечена команда топ-менеджеров (CxO). Результатом интервенции стал эксперимент, сильно влияющий на организационною гибкость (Business Agility).

Читать далее «Скрам-мастер как организационный коуч»

Трансформационный долг и пределы роста

В этой статье мы расскажем вам об эпизоде организационного коучинга, в котором скорость трансформации была слишком велика. Аджайл-коучи не успевали качественно стартовать пилоты и одновременно поддерживать ранее запущенные команды. Делимся выученными уроками.

Успех первых пилотов

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

Читать далее «Трансформационный долг и пределы роста»

Организационный коучинг: целое не может быть разделено на части

О чем эта статья

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

Низкое качество, снижение продаж

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

Целое не может быть разделено на части

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

“Более 90% проблем, которые возникают в корпорациях, должны решаться не там, где они возникли” (R. Ackoff)

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

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

Производительность системы зависит от взаимодействия частей, а не от того, насколько эффективно они работают по отдельности. (R. Ackoff)

Читать далее «Организационный коучинг: целое не может быть разделено на части»

Системное мышление и организационный коучинг

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

Системное мышление для организационного коучинга

Большие организации — комплексные социальные системы. Причины и следствия не очевидны, а точки приложения решения проблем находятся в самых неожиданных местах.

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

В одной большой организации

Недавно мы работали с группой Скрам-мастеров в большой организации. Во время интервью мы спрашивали, сколько времени они уделяют организационному коучингу. Скрам-мастера отвечали уклончиво, соглашаясь, что это важная часть обязанностей. Они жаловались на катастрофическую нехватку времени. По их словам, командные активности поглощали все время. 

В компании было понимание важности полного выделения человека на роль Скрам-мастера. Каждый Скрам-мастер работал только с одной командой. Нам стало интересно разобраться в этой истории. Мы провели системное расследование и делимся его результатами.

Читать далее «Системное мышление и организационный коучинг»

Меняйте систему, а не людей

Система определяет результаты

Часто я демонстрирую картинку, где изображен организационный дизайн одной из продуктовых групп. Посмотрите на схему. Что вы замечаете?

  • Работа организована вокруг компонентных команд: аналитика, бэкенд, Android, Windows и т.д. 
  • Команды из-за многочисленных зависимостей передают из Спринта в Спринт проделанную работу. 
  • Цепочку замыкает “релиз менеджер”, который большой пачкой выводит новую функциональность на продакшн конечным пользователям. 
  • Легко заметить, что время цикла lead time или time-2-market равно нескольким Спринтам (2-3 месяца).

Мы называем это Copy Paste Scrum — использование Скрама в текущей организационной структуре без ее изменения. Какие факторы влияют на производительность всей системы? Обычно я задаю этот вопрос студентам, а затем даю несколько минут на генерацию факторов. Прошу разместить их в две колонки: система и люди. Типичный результат который получается в итоге:

Я проводил этот эксперимент с топ-менеджерами, разработчиками, менеджерами среднего звена, сотрудниками отдела продаж, маркетологами, но результат предсказуемый. Большинство стикеров оказываются в колонке “система”. Почему?

95% производительности зависит от системы (Эдвард Деминг 1982). 

Читать далее «Меняйте систему, а не людей»

Традиционное и системное мышление

Перевод статьи Сезарио Рамоса Systems and traditional thinkers

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

Системный мыслитель признает, что большинство проблем в разработке программного обеспечения возникает в системе, в которой работают люди. Проблемы по своей сути системны!

«95 % проблем в бизнесе возникают на уровне систем и только 5 % на уровне людей».

Э. У. Деминг

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

Но что представляет собой система? Р. Л. Акофф предложил лучшее, на мой взгляд, определение:

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

Читать далее «Традиционное и системное мышление»