В предыдущей статье мы рассмотрели полезную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой. POSIWID прекрасно работает для любой социальной системы: команды, продуктовой группы, организации и т.д. Давайте посмотрим на ее применение в командном контексте.
POSIWID на командном уровне
Чтобы взять на вооружение POSIWID («Purpose Of the System Is What It Does»), нужно ответить последовательно на несколько вопросов:
- Какая заявляемая цель системы?
- Как ведет себя система?
- Что говорит поведение системы о цели системы?
- Есть ли соответствие между заявленной и фактической целью?
- Если это не так, как выглядит структура системы?
- Как мы можем изменить структуру системы, чтобы получить новое поведение?
Проиллюстрируем алгоритм на примере команды, с которой мы работали некоторое время назад.
Какая заявляемая цель системы?
Команда, о которой мы рассказываем, использовала фреймворк Скрам. Мы знаем, что цель Скрама — доставка ценности каждыйСпринт. Как минимум раз в Спринт команда имеет потенциально готовый к релизу инкремент, чтобы убедиться в том, что ценность продукта увеличивается и для управления рисками (читайте статью “Скрам начинается с готового к релизу инкремента”).
Как ведет себя система?
Команда, с которой мы работали, не могла поставлять ценность каждый Спринт. Участники команды объясняли это большим размером PBI, которые они хронически не успевали завершить к концу каждого Спринта. Примечательно, что в течение первых нескольких Спринтов команде удавалось это делать. Но со временем средний размер PBI постепенно вырос. Когда мы взглянули на Velocity Chart, то заметили кое что интересное. Как вы видите, нулевая скорость на протяжении нескольких Спринтов чередуется с всплесками в Спринтах, где PBI завершается. Это и неудивительно, учитывая, что фичи переходят из Спринта в Спринт.
Менеджмент компании был недоволен динамикой. Бизнес и стейкхолдеры что не могли своевременно отслеживать прогресс к целям. Владелец Продукта жаловался, что не может получать обратную связь и приоритезировать Бэклог Продукта так часто, как ему бы хотелось.
Что говорит поведение системы о цели системы?
Учитывая все, что ранее мы обнаружили в предыдущем пункте, мы сформулировали фактическую цель системы с помощью POSIWID («Purpose Of the System Is What It Does»):
Команда прекрасно справляется с задачей увеличения среднего размера PBI со временем и избегания поставки ценности каждый Спринт.
Формулировка показалась команде насмешливой, но мы объяснили, что это лишь отражение того, что происходит на самом деле. POSIWID лишь описывает текущую реальность, в которой находится команда.
Есть ли соответствие между заявленной и фактической целью?
Ответ на этот вопрос очевиден. Фактическая цель системы противоречит заявляемой цели Скрама — доставка ценности каждый Спринт. Команда сразу же согласилась с этим и мы перешли на следующий пункт.
Как выглядит структура системы?
Здесь нам пришлось изрядно потрудиться, потому что поиск структуры системы почти всегда непростая задача. Для этого мы предложили команде воспользоваться инструментом Causal-Loop Diagram (CLD).
- На первом шаге мы дали индивидуальное задание выписать все переменные, которые могут быть на системной диаграмме.
- С помощью мульти-голосования выделили самые важные из них.
- Сформировали тройки и дали 20 минут на создание своей версии CLD.
- Использовали освобождающую структуру Shift&Share, чтобы познакомить команду со всеми вариантами.
- Мы задали несколько вопрос: какая диаграмма лучше всего отражает командную динамику? Что нужно добавить, убрать, изменить, чтобы сделать диаграмму еще более полной? В результате обсуждения получили CLD ниже.
Основная структура визуализируется с помощью двух усиливающих петель:
- R1: Чем меньше времени тратится на PBR и декомпозицию, тем больше средний размер PBI и тем меньшее их количество берется в Спринт и шансы достичь Цель Спринта снижаются. Когда Цель Спринта под угрозой, команда уделять меньше времени PBR, что еще больше усугубляет ситуацию.
- R2: Когда PBI становятся все больше, они “переезжают” из Спринта в Спринт, вызывая давление со стороны Владельца Продукта и стейкхолдеров. Срабатывает ментальная модель “Они недостаточно упорно работают” и бизнес начинает обращать внимание на индивидуальную эффективность людей. Это заставляет команду начинать больше работы (WIP). Увеличение WIP предсказуемо увеличивает среднее время, за которое завершается PBI (Cycle Time) и снижает шансы достичь Цели Спринта.
Как мы можем изменить структуру системы, чтобы получить новое поведение?
Когда мы получили финальную CLD, то предложили команде перестроить ее, чтобы получить другие результаты. Мы напомнили, что заявленная цель “доставка ценности каждый Спринт” и попросили придумать улучшения, которые бы выровняли структуру и заявленную цель. Системные улучшения, к которым пришла команда в результате:
- Выделять фиксированное время на PBR два раза в неделю по два часа для тщательной декомпозиции и проработки Бэклога Продукта;
- Начать использовать паттерн Definition of Ready (DoR).
- Команда решила работать не более, чем над двумя PBI одновременно (WIP Limit = 2);
- Владелец Продукта воздерживается от давления и фокуса на индивидуальной продуктивности и защищает Скрам-команду от давлению стейкхолдеров.
Чем закончилась эта история? Команда успешно вернулась к работе с небольшими PBI и через несколько Спринтов научилась поставляла ценность каждый Спринт. Когда справляешься с одними проблемами, то неизбежно появляются другие, и это нормально.
Основные мысли статьи:
- Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой. POSIWID прекрасно работает для любой социальной системы: команды, продуктовой группы, организации и т.д
- Последовательно отвечайте на вопросы: какая заявляемая цель системы? как ведет себя система? что говорит поведение системы о цели системы? есть ли соответствие между заявленной и фактической целью? если это не так, как выглядит структура системы? как мы можем изменить структуру системы, чтобы получить новое поведение?
- Перестройте структуры в соответствие с желаемой целью оптимизации.
