Написать эту статью меня подтолкнул недавно проведенный воркшоп по декомпозиции. Как сказал один из участников, “теперь я понимаю, почему декомпозиция не взлетает. Все дело в организационной системе”.
Как так? Ведь это довольно несложный инструментальный навык в копилке Скрам-мастера/Аджайл-коуча. Есть масса паттернов декомпозиции в открытом доступе. Дело в том, что декомпозиция — верхушка айсберга. Если не созданы соответствующие условия на уровне организационной системы, то декомпозиция буксует. Более того, это касается любого Agile-инструмента. Ровно так же “не взлетают” стори поинты, Цели Спринтов и другие практики.
Итак, менеджеры, Владельцы Продуктов и/или команды сопротивляются попыткам разбиения, а вы не уверены, почему это происходит? Перечислю четыре основные причины.
Причина 1. Фиксированный скоуп
Часто в организациях роль Владельца Продукта выполняет не представитель бизнеса, а вчерашний менеджер проекта или прокси, который не отвечает за успех продукта и его стратегию, не владеет бизнес-моделью и видением. Прокси перемещается между разработкой (RnD) и бизнесом. В такой структуре возникает “контрактная игра”, в которой прокси дает “коммитменты” бизнесу, привязанные к определенному скоупу. Раз скоуп фиксирован, то зачем тратить дополнительные усилия на декомпозицию, если “эти задачи обязательно нужно сделать”? Еще одна из причин фиксированного скоупа кривое целеполагание, привязанное к большой пачке задач, которое, скажем, нужно завершить к концу квартала.
Фундаментальное решение — избавление от прокси, работа напрямую с настоящим Владельцем Продукта представителем бизнеса и адаптивное планирование.
Причина 2. Неполная кросс-функциональность.
Декомпозиция на небольшие, представляющие конечную ценность, элементы Бэклога Продукта, поддерживает инкрементально-итеративную разработку. Это значит, что команда будет часто переделывать тот код и архитектуру. Например, чтобы получить фичу, помещающуюся в Спринт, команда уменьшает ее скоуп с помощью паттерна "бизнес-правила". Допустим, это требует изменения в компоненте, которые не находится под контролем у команды. Другое подразделение хочет быть локально эффективными и может не пойти вам навстречу в реализации лишь части бизнес-правил. Велика вероятность, что они они будут аргументировать свой отказ тем, что “не хотят переделывать затем это снова”. К тому же, вам нужно приглашать их на свой PBR, обучать паттернам декомпозиции.
Фундаментальное решение — переход к кросс-функциональным и кросс-компонентным фиче-командам, снижение зависимостей.
Причина 3. Высокие транзакционные расходы.
Работать с небольшими рабочими пакетами выгодно, если транзакционные расходы относительно невысоки. Но если, к примеру, регрессионное тестирование не автоматизировано и занимает неделю-другую времени, то попытки декомпозиции не найдут понимания. Организации экономически выгоднее собрать большой пакет работы и лишь затем применить к нему регрессию или любой другой дорогой транзакционный процесс.
Фундаментальное решение — снижение транзакционных расходов.
Причина 4. Фокус на индивидуальной продуктивности.
Фокус на завершении работы в Спринте и работа с маленькими элементами подразумевает, что участники Скрам-команды будут иногда работать не по своей профильной специализации. Если же организационная система стимулирует индивидуальную эффективность, то декомпозиция встретит понятное сопротивление.
Примеры организационных элементов, поддерживающих индивидуальную эффективность:
- Функциональные менеджеры, развивающие и оценивающие разработчиков вдоль узких треков.
- Трекинг профильных задач.
- Индивидуальные награды.
- Зарплаты, привязанные к должностям (тимлид, техлид и т.д.)
- Матричная структура.
Фундаментальное решение — перестройка системы на такую, которая поддерживает горизонтальное развитие и коллаборацию, а значит и декомпозицию.
Подводим итоги
Мы разобрали четыре основные причины, почему декомпозиция “не взлетает”. Фундаментальные решения не быстрые, но действенные и генеративные (создают новую реальность). Запаситесь терпением и чувством юмора, и начинайте менять организационную систему. Постепенно, шаг за шагом. С той скоростью, которая для вас комфортна. А декомпозиция и другие Agile-практики со временем заработают!
