В предыдущей статье мы рассмотрели полезную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой. POSIWID прекрасно работает для любой социальной системы: команды, продуктовой группы, организации и т.д. Давайте посмотрим на ее применение в командном контексте.
POSIWID на командном уровне
Чтобы взять на вооружение POSIWID («Purpose Of the System Is What It Does»), нужно ответить последовательно на несколько вопросов:
Какая заявляемая цель системы?
Как ведет себя система?
Что говорит поведение системы о цели системы?
Есть ли соответствие между заявленной и фактической целью?
Если это не так, как выглядит структура системы?
Как мы можем изменить структуру системы, чтобы получить новое поведение?
Проиллюстрируем алгоритм на примере команды, с которой мы работали некоторое время назад.
…Скрам-команда преодолела некоторые препятствия и работает более эффективно, чем раньше.
✥ ✥ ✥
Команды могут войти в состояние чрезвычайной удовлетворенности улучшениями, которые они сделали. И это сохраняет дисфункцию. Как будто пузырь счастья окружает их и изолирует от неприятной, но правдивой информации.
Многие организации начинают применять Скрам в условиях кризиса, когда время, необходимое для разработки новой версии продукта, намного больше, чем рынок готов ждать. После первоначальных настроек Скрама, команда поставляет Инкремент Продукта. Переход от отсутствия продукта к хоть какому-то продукту является настолько значительным успехом, что он препятствует устранению любых других препятствий, так как ни одно из них не такое значительное, как предыдущее. Команда считает, что не стоит прилагать усилия для решения таких сравнительно небольших проблем.
В средах, где есть поддержка для постоянного улучшения, успешная команда часто не может понять, как улучшаться. Со временем становится все труднее и труднее совершенствоваться. Команда собрала все низко висящие фрукты. Возможно, команда достигла предела своих знаний или опыта и не может понять, есть ли альтернатива тому, как она работает.
Ретроспектива Спринта в таком случае проводится для самоуспокоения. Она приводит к небольшим (если таковые имеются) изменениям процесса или к поверхностным изменениям, не оказывающим реального влияния на команду. В конце концов, команда перестает проводить Ретроспективы, потому что не видит пути к улучшению – кроме остановки, чтобы сохранить навсегда общий миф о великолепной производительности.
Некоторые команды могут не видеть пути улучшения, потому что все препятствия, которые у них есть, находятся «вне команды». Когда команда не достигает Цели Спринта, она всегда приписывает это разовым, исключительным событиям. И всегда есть какое-то одноразовое событие. Они чувствуют, что если бы только некоторые «они» могли что-то с этим сделать, команда бы улучшилась.
Столкновение с проблемами неприятно, и устранение препятствий может заставить команды вести неудобные разговоры или принимать трудные решения. Для людей естественно избегать таких неприятных переживаний. Такое может быть в очень сплоченной команде, где все любят работать и просто ладить друг с другом. Это затрудняет признание проблем. В культуре, где людей учат не раскачивать лодку, становится все труднее признавать проблемы. Там, где нет смелости и решимости принять проблемы и измениться, не может быть никаких улучшений.
Команда может жить в “Пузыре Счастья”. Одна из самых больших проблем состоит в том, что пузыри прозрачны – команде очень трудно его увидеть. Почти всегда требуется взгляд со стороны, чтобы осознать такое поведение. Команде нужно получить обратную связь от нейтральных наблюдателей. Это то, что команды, возможно, не хотят замечать. Наблюдатели должны иметь смелость быть честными с участниками команды и чтобы справиться с неприятием результатов их обратной связи.
С другой стороны, все команды могут улучшаться. Они просто не видят этого.
Поэтому:
Привлеките команду к осознанию своей ситуации (Лопните Пузырь Счастья): вынудите команду противостоять своему удовлетворению, подсветив им важные недостатки. Затем вместе с командой планируйте действия по улучшению. Создайте в команде культуру постоянного самоанализа и совершенствования.
Это паттерн для исправления. Лучшая ситуация – не попадать в «Пузырь Счастья». Когда кто-то (например, Скрам-мастер) поднимает проблему, которую все игнорируют, бросьте вызов команде и спросите их, как они планируют ее решить. Главное, в первую очередь, заставить команду признать, что у нее есть проблема.
Лучший человек, который может вывести команду за пределы Пузыря Счастья, – это тот, кто входит в Скрам-команду и хочет и может поднимать сложные вопросы. Этот человек должен иметь возможность видеть проблемы, поднимать проблемы и пробуждать изменения. Этот человек должен пользоваться уважением и доверием Скрам-команды и поддерживать ее самостоятельность и самоорганизацию.
У Скрам-мастера есть уникальная возможность лопнуть пузырь счастья из-за его или ее взгляда на всю команду, а также из-за объективности, связанной с практикой по удалению себя от проработки решений. Однако, когда Скрам-мастер противостоит команде, сообщение должно быть таким, что мы (а не вы) работаем недостаточно хорошо, и что мы будем с этим делать.
Что если Скрам-мастер часть проблемы? Если это только Скрам-мастер, команда может позаботиться об этом внутри. Однако, поскольку Скрам-мастер имеет более широкое видение процесса, если Скрам-мастер находится в «Пузыре Счастья», вполне вероятно, что вся команда также находится в «Пузыре Счастья». В этом случае, Владельцу Продукта возможно, придется принять решительные меры, такие как привнесение внешней перспективы, неформально или формально. Это крайнее средство для тех случаев, когда «Пузырь счастья» вызывает серьезные сбои, а другие меры не дают результатов.
Внешний человек, который “лопает пузырь”, уступает по важности кому-то из Скрам-команды, но может быть необходим, если вся команда не знает о «Пузыре Счастья». Любой, кто находится в лидерской позиции, может инициировать вовлечение этого внешнего “лопателя пузыря”. Крайне важно, чтобы были достоверные данные для подтверждения заявлений о производительности команды и о существовании «Пузыря Счастья». Тот факт, что команда находится в пузыре, означает, что они могут скептически относиться к наличию проблемы. Предоставьте членам команды данные, чтобы они не могли их оспорить. Лучшая роль для этого вне команды — это, вероятно, Скрам-мастер из другой команды, особенно если Скрам-мастер также не замечает этой дисфункции. Эта роль уникальна тем, что она объективна и нейтральна и может видеть всю картину. Команда видит свое отражение и поэтому может понимать последствия своего постоянного поведения. Скрам-мастер играет вопрошающую роль. Если Скрам-мастер слишком настойчив и пытается продвинуть определенное решение, такое поведение может быть разрушительно для командной самоорганизации. Где это возможно, используйте вопросный метод Сократа.
✥ ✥ ✥
Ожидаемый результат – команда осознает свои недостатки, вновь привержена улучшениям и предпринимает для них шаги. Основным результатом является осознание, и это может быть самым важным. “Лопание Пузыря Счастья” повышает осведомленность о проблемах, которые команда может решить с помощью Scrumming the Scrum. И наоборот, модели Scrumming the Scrum, Ретроспективы и Norms of Conduct помогают в первую очередь предотвратить появление “Пузырей Счастья”.
Идеальный результат заключается в том, что команда понимает, почему она попала в “Пузырь счастья”, и предпринимает шаги по предотвращению образования будущих пузырей. Некоторым людям может не понравиться отсутствие “Пузыря Счастья”. Они могут воспринять это как необоснованное давление для достижения неоправданного уровня производительности. В крайнем случае, люди могут покинуть команду. Эффект такого давления может быть внезапным и сокрушительным, снижающим эйфорию, в которой находилась команда, что выражается в отсутствии мотивации и потенциально вредит командной динамике из-за людей, покидающих организацию в результате.
Наиболее вероятным положительным долгосрочным следствием многократного появления “Пузыря Счастья” является то, что команда получает признание за способность рефлексировать и совершенствоваться. Это полноправный источник Team Pride (см. Team Pride).
Рекомендуемые тренинги
Продвинутый курс Professional Scrum Master II (PSMII) + Scrum Patterns для Скрам-мастеров с опытом больше года. Решаем кейсы, изучаем интересные техники фасилитации, применяем системное мышление, Скрам-паттерны и готовим вас к сертификации Professional Scrum Master (PSMII).
Уникальный тренинг Scrum Patterns для Аджайл-коучей и Скрам-мастеров. Освойте десятки Скрам-паттернов и закройте большинство проблем, с которыми сталкиваются ваши Скрам-команды. Научитесь используйте комбинацию Скрам-паттернов и системного мышления.
Знаете ли вы компании, которые используют Аджайл-практики и внедрили Скрам, но так и не получили ощутимых результатов после нескольких лет трансформации? Чаще всего дело в том, что цели оптимизации адаптивность и скорость противоречат организационному дизайну компании, который поддерживает другие цели. В этой статье мы научимся находить несоответствия между целями оптимизации и текущей структурой.
POSIWID (“Purpose Of The System Is What It Does”)
Специалист по системам и управлению Стаффорд Беер разработал важную и популярную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Другими словами, цель оптимизации определяет результаты системы. Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой.
Когда люди понимают, как цель системы и ее структура определяют результаты, они могут взять на себя ответственность за изменению структуры.
Давайте приведем примеры, где ЗАЯВЛЯЕМАЯ и ФАКТИЧЕСКИЕ цели систем не совпадают.
Система
Наблюдаемая проблема
Заявляемая цель
Цель, сформированная с помощью POSIWID
Школа
Много не вовлеченных детей
Воспитание полноценных и самостоятельных людей
Школа хорошо достигает цели в том, чтобы сделать обучение для детей как можно более скучным
Программное обеспечение XYZ
Большой отток клиентов
Помощь малому бизнесу
Продукт прекрасно достигает цели в том, чтобы заинтересовывать клиента, а затем сделать все возможное, чтобы он ушел.
Парламент
Коррупция, слияние власти с крупным бизнесом
Представлять интересы граждан и защищать их интересы
Парламент замечательно выполняет цель, которая заключается в обогащении и лоббировании интересов крупного бизнеса.
Обратите внимание на формулировки в последней колонке. Вместо того, чтобы говорить о “плохо спроектированной системе” или “побочных эффектах”, мы считаем, что текущая система уже сейчас блестяще справляется с достижением плохих результатов.
Каждая система идеально разработана для достижения результатов, которые она получает. (Дон Бервик)
Хороший пример, когда поставленная цель не работает — Copy-Paste масштабирование. Это самый распространенный способ использования Скрама в больших организациях по всему миру.
Когда Скрам ошибочно воспринимается как “командный” фреймворк, то за каждой командой закрепляется локальный “Владелец Продукта”, а команды формируются вокруг функций, компонентов и внутренних бизнес-процессов.
Такая структура порождает зависимости и длинные релизные циклы. Кроме того, команды работают не над самой важной функциональностью из-за наличия многочисленных Бэклогов Продукта. Copy-Paste масштабирование имеет мало общего с заявленными оптимизационными целями. Чаще всего фактические цели оптимизации: сохранение статуса-кво и структур власти, индивидуальная эффективность, создание видимости изменений для того, чтобы отрапортовать руководству о том, что “трансформация завершена”. Поэтому фактическая цель, определенная с помощью POSIWID, может звучать так:
продуктовая организация блестяще справляется со своей целью занять людей работой, обеспечить длинные циклы и создать видимость изменений
Итак, можно до посинения доказывать, что целью системы является [XYZ], но если это не подтверждается результатами и поведением системы, то это ЗАЯВЛЕННАЯ цель, а не ФАКТИЧЕСКАЯ. Давайте дальше разбираться в том, как привести к соответствию цели оптимизации и организационный дизайн.
В первой части блог-поста, я объяснил, как идентифицировать организационные элементы для включения их в ваше определение продукта. В этом блоге я объясню, как вы можете уточнить определение продукта для организации эффективных кросс-функциональных команд.
Некоторые элементы равнее, чем другие.
Ниже представлен упрощенный вид организационных элементов одного из моих клиентов.
Мы обнаружили, что некоторые организационные элементы требуются чаще, чем другие для разработки функциональности. Чем чаще требуется конкретный элемент, тем сильнее зависимость. Мы визуализировали силу зависимостей с помощью тепловой карты (heat map) – см. рисунок анонимного упрощенного примера ниже.
По шкале y находятся элементы функциональности. По шкале x – организационные элементы. Зеленый цвет показывает, какой элемент нужен, чтобы доставить этот элемент.
Элементы, которые “нагреваются” больше всего, указывают на силу зависимости – это горячие точки. Обратите внимание, что элемент WEB необходим в 28% времени для разработки функциональности продукта, APP– в 20% времени, в то время как для LEGAL требуется всего 7%.
ПРИМЕЧАНИЕ. Старайтесь не уделять слишком много внимания процентам, это не точная наука, а скорее руководство, которое поможет вам двигаться вперед. Помимо процентов, я также успешно использовал различные шкалы для оценки силы зависимостей, таких как: Редко, Сейчас и Затем, Частота.
Когда все команды могут взять любую работу, которая приходит, и полностью выполнить ее, вы получаете максимальную адаптивность. Это будет означать, что у каждой команды есть навыки, чтобы покрыть всю тепловую карту. К сожалению, это был не наш случай. Количество технологий оказалось слишком велико для освоения командами. Кроме того, мы увидели ценность в специализации команды. Решение заключалось в том, чтобы команды, в первую очередь, специализировались на домене клиента, а затем при необходимости изучали другие домены продукта.
Обучение может занять много месяцев или даже лет, а между тем нам нужно было определить, с чего начать. Какие организационные элементы должны охватывать команды в первую очередь, а какие мы добавим позже? Это решение зависит от силы и типа зависимостей.
Найдите баланс между адаптивностью и скоростью
Когда команда может работать во всех компонентах, но только с одной функцией, команда охватывает всю строку, как показано на рисунке ниже. У такой команды нет внешних зависимостей; следовательно, они, вероятно, поставляют быстро. С другой стороны, когда команда охватывает все функции, но только один компонент, команда покрывает полный столбец в тепловой карте. Такая команда может работать над всеми частями; следовательно, они могут адаптироваться ко всей работе, которая поступает, но не может выполнять работу от начала до конца.
Следовательно, размер области тепловой карты, которую охватывает команда, сильно определяет ее
скорость поставки фич
гибкость в выборе работы из Бэклога Продукта.
Наша задача состояла в том, чтобы найти оптимальный баланс между скоростью и адаптивностью в контексте нашей команды, и это зависело от нескольких переменных:
Когнитивные способности команд. Когда команды специализируются на клиентском домене, они могут по-прежнему работать с клиентскими фичами (end-2-end), не разбираясь в других клиентских доменах продукта.
Тип зависимостей между элементами. Это помогает командам определить какой организационный элемент охватить в первую очередь, а какой потом.
Специализируйтесь на домене клиента
Наш продукт был большой системой страхования. Мы использовали интервью и анкеты, чтобы определить, где пользователи проводят большую часть своего времени при использовании продукта. Оказалось, что было несколько основных групп пользователей (для этого блога я просто использую 2 группы «Заявки и оценка» и называю их красным и желтым). Некоторые пользователи в основном использовали фичи красного цвета – красную область, в то время как другая группа в основном использовала фичи желтого цвета – желтую область. Оранжевые фичи используются обеими группами пользователей: они перекрывают или пересекают как красные, так и желтые области.
Красные и желтые области позволяют командам специализироваться на домене клиента — см. Области требований в LeSS (less.works) и паттерн Области Ценностей. Это снижает когнитивную нагрузку на команды.
Следующим шагом нужно было найти наиболее значимую область тепловой карты, которую команды могли бы охватить.
Тип зависимостей между элементами
Мы использовали следующие правила, чтобы решить, какие элементы включить с самого начала, а какие добавить позже.
Правило 1 Pooled Dependencies – содержание взаимных зависимостей внутри одной Области Ценности: Работа одной команды является входом для другой команды, и наоборот, и существует неопределенность в том, как выполнить задачу, что делает необходимым частое выравнивание.
Правило 2 Sequential Dependencies – обеспечение последовательных зависимостей между Областями Ценностей с помощью итеративного планирования: команда зависит от работы, которая должна быть выполнена другой командой. Применимо для работы с низкой неопределенностью и предсказуемой работой.
Правило 3 Reciprocal dependencies – управление зависимостями между командами и Областями Ценностей с помощью простых правил координации: например, совместное использование единой тестовой среды или зависимость от человека с дефицитным навыком.
Ниже вы можете увидеть пример результата для красной Области Ценностей.
WEB, APP, SIEBEL, PORTAL компоненты часто используются вместе и их взаимозависимости двусторонние. Команды в красной области Команды красной области решили, что им нужно будет охватить хотя бы эти элементы.
Кроме того, вы можете увидеть, что область имеет объединенную взаимозависимость с LEGAL и что это относительно сильная зависимость. Самая слабая взаимозависимость – 14% с SALES FORCE. Мы решили не включать SALES FORCE изначально, а добавлять его только тогда, когда команды освоят другие элементы. LEGAL также не был включен, потому что это была общая зависимость.
Желтая Область Ценности ниже имела другой состав зависимостей.
Команды решили что им нужно охватить как минимум APP, SALES FORCE, SIEBEL и WEB компоненты.
Для этой области LEGAl был не нужен совсем. И слабая последовательная зависимость от PORTAl. Мы решили не включать PORTAl на первом этапе. В исключительном случае, когда какая-либо фича нуждалась в изменении PORTAl, команды могли координировать свою работу с красной областью, чтобы выполнить это. Мы также использовали это, как возможность, чтобы узнать больше о PORTAL.
Что делать с элементами функциональности в пересекающейся оранжевой области? Решение состоит в том, чтобы решать, на основе самой фичи.
Например, F10 может быть выбрана как красной так и желтой областью. F18 задействует только APP и может быть выбрана желтой областью. Единственная сложная фича – F11. Она задействует SALES FORCE и PORTAL, которых нет ни у красной ни у желтой области. Итак, как быть с ней? Хорошо…., вспоминаем золотое правило Скрам-мастерства: “Всегда спрашивай команду.”
Итоговый результат
Определение продукта включает все элементы, но мы выбрали не включать LEGAL-компетенции ни в одну из команд на старте. Почему? Потому что это общая и слабая зависимость. Кроме того, команды чувствовали, что еще не готовы охватить больше навыков с самого начала. Вместо этого, LEGAL стал следующей активностью для включения в Definition of Done.
Изредка, когда фича, требующая LEGAL-компетенций, возникала в топе Бэклога Продукта, мы создавали план работы вместе с LEGAL на встречах по Актуализации Бэклога Продукта и на протяжении всего Спринта.
На Планировании Спринта, команда, которая выбирает эту фичу будет координировать свою работу с кем-то из LEGAL для ее завершения. Предпочтительно, чтобы члены LEGAL также использовали эту возможность, чтобы обучать команду, чтобы они немного больше узнали о LEGAL к концу Спринта. Когда команда продолжает выбирать фичи LEGAl-компонентом, в конечном итоге они обучатся достаточно, чтобы добавить LEGAL в Definition of Done. Бас Водди называет это случайной специализацией.
ПРИМЕЧАНИЕ. Не всем командам необходимо знать все обо всех элементах определения продукта с самого начала. Команды могут иметь свою специализацию до тех пор, пока все команды в группе смогут выбирать все элементы из верхней части Бэклога Продукта.
Кайзен или kai-zen (カイゼン) японская бизнес-философия постоянного совершенствования методов работы, личной эффективности и т. д. В переводе с японского ‘улучшение’.
Посмотрите также Toyota Kata.
✥ ✥ ✥
Лишь небольшая часть Скрам-команд сдвигает парадигму к радикально новому уровню производительности и способности создавать ценность. Так происходит из-за того, что большинству команд не удается выявить и устранить препятствия.
Их работа не Done (смотри Definition of Done), их Бэклог не Ready (see Definition of Ready), команда не самоорганизуется для повышения производительности.
Сложные препятствия могут потребовать чрезвычайно целенаправленных усилий для устранения. Работа над многими препятствиями одновременно часто приводит к большому объему работ с небольшим выхлопом и может деморализовать команду.
Поэтому:
Определите самое важное препятствие на Ретроспективе Спринта и устраните его до конца следующего Спринта. Чтобы устранить самое важное по приоритету препятствие, поместите его в Бэклог Спринта как задачу с приемочными тестами (смотри Testable Improvements) которые будут определять, когда задача Готова. Затем оцените статус задачи, как и любой другой, на Обзоре Спринта.
Фокус внимания на препятствии высшего приоритета будет иметь побочный эффект самоорганизации команды для устранения других препятствий высокого приоритета, не теряя при этом внимание на препятствии самого высокого приоритета.
Работая с большим количеством продуктовых групп и компаний, мы замечаем паттерн — команды не умеют создавать готовый к релизу инкремент каждый Спринт. Команды опираются не на свои возможности, а на опыт других команд/компаний: начинают работать двухнедельными Спринтами.
Мы называем такие Спринты фейковыми, потому что они не завершаются полными циклами обратной связи. Несмотря на то, что команды формально проводят Обзор Спринта и Ретроспективу Спринта, отсутствует готовый к релизу инкремент. Значит, эмпирический контроль не работает, стейкхолдеры не могут инспектировать прозрачный инкремент на Обзоре Спринта и своевременно работать с возникающими рисками.
Сердцем Скрама является Спринт, период времени не более одного месяца, в течение которого создается потенциально готовый к релизу инкремент продукта (Руководство по Скраму, 2017).
Это первая часть серии блог-постов об определении продукта в LeSS.
При разработке крупных продуктов команды, как правило, работают только над частью реального продукта. Эта часть – узкое определение продукта – часто является компонентом или конкретной активностью в процессе разработки. Это не продукт.
Узкое определение продукта создает различного рода проблемы для продуктовой группы. Узкое определение продукта локально оптимизирует производительность команд за счет производительности группы. Системная диаграмма (CLD) ниже объясняет эту динамику.
(См. Этот блог-пост для краткого обзора обозначения CLD.)
При узком определении продукта повышается вероятность того, что будут появляться специализированные группы, которые работают только в своем функциональном колодце, что, в свою очередь, снижает адаптивность и скорость обучения на общем уровне продукта. Более широкое определение продукта приводит к группам, которые охватывают несколько компонентов и видов деятельности, которые в совокупности отвечают потребностям конечных пользователей.
Устраните локальную оптимизацию узкого определения продукта
Часто используемое определение продукта – «что-то, что сделано для продажи». Продукт обеспечивает способ извлечения прибыли.
У продукта есть пользователи, люди;
Продукт предоставляет базовую функциональность, которая закрывает проблемы и отвечает потребностям пользователей;
Продукт имеет бизнес-модель, источники доходов, независимую прибыль и убыток (P&L) или возврат инвестиций (ROI).
Продукт разрабатывается и поддерживается системой людей, компонентов и процессов.
Определение продукта обуславливает, какие организационные элементы (люди, компоненты, процессы и системы) необходимы для разработки и запуска продукта. Если ваш продукт – «Ипотека», то Владельцем Продукта, вероятно, является человек из бизнеса, который понимает рынок. Бэклог Продукта может содержать такие элементы, как «Кредитные предложения для малого бизнеса», а пользователи, вероятно, будут клиентами, которые платят деньги. Ипотека – это широкое определение продукта, когда оно содержит все детали, необходимые для создания комплексного решения для конечного пользователя.
Как определить продукт?
Определение продукта включает в себя несколько компонентов, действий и предоставляет решения для потребностей и проблем конечных пользователей. Вы можете определить свой продукт, используя следующие два шага:
Шаг 1 — Определите необходимые организационные элементы для разработки и поддержки продукта.
Начните с элементов, ваших компонентных команд, которые вы в настоящее время называете продуктами, активностей, людей и процессов, которые есть в вашей группе. Затем изучите, как связана между собой работа, чтобы понять существующие типы зависимостей для разработки, поддержки и обслуживания вашего продукта.
Типичные шаги для достижения этой цели:
Определите типичных внешних конечных пользователей для вашей группы.
Определите постоянные потребности, которые эти конечные пользователи хотят решить, или задачи, которые они должны выполнить.
Определите фичи для каждого из пользователей, которые они используют для удовлетворения потребностей или выполнения своей работы.
Определите каналы, через которые пользователи используют функции для удовлетворения своих потребностей/проблем и т. д. (Например, Браузер, Приложение, API, Connector или Helpdesk)
Затем, определите организационные элементы, которые вам необходимы для разработки фичи и удовлетворения пользователя. Сделайте это, изучая путь, как каждый элемент функциональности проходит через вашу организацию в руки клиента. Начните с каналов, проработайте компоненты, системы, людей и процессы до конца пользовательского пути.
Шаг 2 – Проясните источники доходов
Правильное определение продукта определяет группу, достаточно широкую, чтобы включать источники доходов. Без этого команды, скорее всего, будут оторваны от проблем рынка, где стоит реальная ценность, и вместо этого будут сосредоточены только на части продукта.
На этом шаге задайте вопросы вопросы: “Производят ли идентифицированные организационные элементы продукт, который генерирует доход для организации? Или есть недостающие части для этого?”. Также неплохо найти ответы на следующие вопросы:
Как элементы вместе генерируют деньги? Например, может ли определение продукта иметь плату за использование? Продажа активов? Абонентская плата? Лицензирование? Если нет, что нужно добавить к определению продукта?
Имеет ли определение продукта независимый P&L? Если нет, то какие организационные элементы отсутствуют?
Какие KPI можно назначить определению продукта? Например, можете ли вы назначить увеличение валового дохода? Увеличение новых клиентов? Удовлетворенность клиентов?
Если вы не можете дать содержательный ответ на все вышеупомянутые вопросы, то определение вашего продукта слишком узкое, и вам необходимо его расширить.
Определение продукта завершено?
К этому шагу, вы определили набор организационных элементов, которые вместе создают ценность для конечных пользователей и имеют независимый источник дохода. Результат обычно включает десятки компонентов, навыков, видов деятельности и сотни людей.
С такой большой группой вы можете спросить себя: «Как я могу создать эффективные кросс-функциональные команды, которые включают все эти компетенции? В случае более чем десяти групп, мы рекомендуем организовать команды среди Области Ценностей и содержать зависимости для каждой области.
В первой части мы обсудили важность следования ценностям Скрама для создания атмосферы доверия и психологической безопасности, которая так необходима для эмпирического контроля. Во второй части мы прояснили ценности и сформулировали конкретное поведение, через которое они проявляются. В этой статье мы расскажем как запустить движок обратной связи, чтобы помочь команде следовать ценностям Скрама.
Движок обратной связи
Известна латинская сентенция: Turbato melius capiuntur flumine pisces, что буквально означает «в мутной воде рыба ловится лучше». В одной из басен древнегреческого поэта Эзопа говорится о рыбаке, который мутил воду вокруг сетей, загоняя туда ослеплённую рыбу. Для поддержания ценностей нужна прозрачность и частые циклы обратной связи, чтобы команда понимала куда плывет. Поэтому Скрам-команды инспектируют и адаптируют ценности и взаимоотношения на Ретроспективе Спринта.
Подход, который мы часто используем с командами, требует навыков использования ненасильственной коммуникации (NVC). Сессия обратной связи состоит из нескольких шагов:
Скрам-мастер дает каждому карточки: две зеленые и одну красную.
Скрам-мастер просит написать обратную связь коллегам, опираясь на примеры конкретного поведения (вторая часть). Зеленая карточка — поведение, поддерживающее ценности, красная — нарушающее их. Обратная связь дается в формате ненасильственной коммуникации. Она может быть адресована как всей команде, так и конкретному человеку.
Карточки зачитываются по очереди, а Скрам-мастер фасилитирует открытый диалог, помогая команде высказываться без оценок, интерпретаций и обвинений.
Ненасильственная коммуникация — подход, который команды могут использовать не только во время воркшопа, но и в повседневной работе. Не нужно ждать Ретроспективы, чтобы дать обратную связь. Важно обучить базовым навыкам ненасильственной коммуникации перед первой сессией по обратной связи.
В первой части мы разобрали важность ценностей Скрама для создания и поддержания атмосферы доверия и психологической безопасности в команде. Следование ценностям Скрама поддерживает эмпирического контроль: инспекцию, адаптацию и прозрачность. Ценности работают каждый день, помогают принимать решения и регулируют наше поведение. Поэтому в этой статье мы обсудим, как участники команды проясняют ценности, а затем формулируют их на уровне конкретного поведения, чтобы держать друг друга ответственными за их соблюдение.
Алгоритм формулирования ценностей
Обратите внимание на то, что ценности всегда абстрактны. Например, что означают любовь, уважение, смелость? Каждый из нас вкладывает собственные смыслы. Поэтому ценности сначала проясняются или калибруются, чтобы очертить их границы. А затем проявляются на уровне поведения. Ведь мы не можем достоверно знать, а тем более управлять намерениями и мотивацией других людей, они скрыты от нас.
Как правило, все, что мы можем сделать, это наблюдать за поведением людей — их планами, решениями и действиями — и пытаться со временем интерпретировать их отношение к этим планам, решениям и действиям. Попытка измерить отношение — скорее догадка, чем надежная оценка (Эдмондс, С. Крис. Движок культуры)
Для формулировки ценностей я использую алгоритм, позаимствованный в книге Culture Engine:
Формулировка ценностей (1-2 слова)
Определение и калибровка ценностей (несколько предложений)
Давайте попробуем применить алгоритм. Первый пункт очевиден — в Скрам уже заложены пять ценностей: уважение, открытость, смелость, преданность и фокус. Поэтому начнем со второго пункта.
…команды уже некоторое время производят продукт. В постоянно меняющейся бизнес-среде возникают вопросы о штатной перестройке, развитии и оптимальном составе команды.
✥ ✥ ✥
Стейкхолдеры больше всего довольны командами, которые оправдывают их ожидания, поэтому команда стремится сделать все необходимое, чтобы снизить вариативность прогнозов.
В проектном менеджменте часто путают людей с человеческими ресурсами. Это приводит к «управлению ресурсами», и спрос увязывается с пропускной способностью (capacity) каждой команды (или иногда с пропускной способностью каждого члена команды), которая вносит свой вклад в результат.
В результате людей часто перебрасывают из команды в команду при старте новых проектов или при возникновении кризисов, связанных с поставками. Это ведет к нестабильности и дополнительным расходам из-за:
администрирования, чтобы отслеживать, над чем работают люди;
сниженной эффективности, так как командам нужно интегрировать нового участника (эффективно создавая новую команду), которому в свою очередь нужно узнавать о команде и продукте;
действия «закона Брукса» («Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»).
Если команды формируются из пула ресурсов, утилизация ресурсов часто приводит к многозадачности, когда люди распределяются по нескольким командам и часто по нескольким продуктам. Добавьте к таким командам меняющиеся требования, и нестабильность становится просто невыносимой. Стабильные и нестабильные части системы должны быть сбалансированы, поэтому там нужно что-то изменить. Много лет эту задачу решали с помощью “заморозки” требований, чтобы постоянно меняющиеся ресурсы могли поставить продукт в прогнозируемый (хотя бы примерно) срок. Жесткая фиксация требований к продукту не позволяет учиться и игнорирует изменения, которые могут создать Наибольшую ценность, поэтому это не хорошее решение.
Поэтому:
Сохраняйте команды стабильными и избегайте перетасовки людей между командами. Стабильные команды обычно знают свою пропускную способность, что позволяет бизнесу иметь некоторую предсказуемость. Закрепите членов команды за одной командой, если это возможно.
