Перевод оригинальной статьи Сезарио Рамоса.
Этот блог-пост – глава-прототип моей готовящейся к выходу книги Coaching Agile Organizations.
В первой части блог-поста, я объяснил, как идентифицировать организационные элементы для включения их в ваше определение продукта. В этом блоге я объясню, как вы можете уточнить определение продукта для организации эффективных кросс-функциональных команд.
Некоторые элементы равнее, чем другие.
Ниже представлен упрощенный вид организационных элементов одного из моих клиентов.
Мы обнаружили, что некоторые организационные элементы требуются чаще, чем другие для разработки функциональности. Чем чаще требуется конкретный элемент, тем сильнее зависимость. Мы визуализировали силу зависимостей с помощью тепловой карты (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. Бас Водди называет это случайной специализацией.
ПРИМЕЧАНИЕ. Не всем командам необходимо знать все обо всех элементах определения продукта с самого начала. Команды могут иметь свою специализацию до тех пор, пока все команды в группе смогут выбирать все элементы из верхней части Бэклога Продукта.
