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

Как так? Ведь это довольно несложный инструментальный навык в копилке Скрам-мастера/Аджайл-коуча. Есть масса паттернов декомпозиции в открытом доступе. Дело в том, что декомпозиция — верхушка айсберга. Если не созданы соответствующие условия на уровне организационной системы, то декомпозиция буксует. Более того, это касается любого Agile-инструмента. Ровно так же “не взлетают” стори поинты, Цели Спринтов и другие практики.

Итак, менеджеры, Владельцы Продуктов и/или команды сопротивляются попыткам разбиения, а вы не уверены, почему это происходит? Перечислю четыре основные причины.

Причина 1. Фиксированный скоуп

Часто в организациях роль Владельца Продукта выполняет не представитель бизнеса, а вчерашний менеджер проекта или прокси, который не отвечает за успех продукта и его стратегию, не владеет бизнес-моделью и видением. Прокси перемещается между разработкой (RnD) и бизнесом. В такой структуре возникает “контрактная игра”, в которой прокси дает “коммитменты” бизнесу, привязанные к определенному скоупу. Раз скоуп фиксирован, то зачем тратить дополнительные усилия на декомпозицию, если “эти задачи обязательно нужно сделать”? Еще одна из причин фиксированного скоупа кривое целеполагание, привязанное к большой пачке задач, которое, скажем, нужно завершить к концу квартала.

Фундаментальное решение —  избавление от прокси, работа напрямую с настоящим Владельцем Продукта представителем бизнеса и адаптивное планирование.

Причина 2. Неполная кросс-функциональность.

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

Фундаментальное решение — переход к кросс-функциональным и кросс-компонентным фиче-командам, снижение зависимостей.

Причина 3. Высокие транзакционные расходы.

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

Фундаментальное решение — снижение транзакционных расходов.

Причина 4. Фокус на индивидуальной продуктивности.

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

Примеры организационных элементов, поддерживающих индивидуальную эффективность:

  • Функциональные менеджеры, развивающие и оценивающие разработчиков вдоль узких треков.
  • Трекинг профильных задач.
  • Индивидуальные награды.
  • Зарплаты, привязанные к должностям (тимлид, техлид и т.д.)
  • Матричная структура.

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

Подводим итоги

Мы разобрали четыре основные причины, почему декомпозиция “не взлетает”. Фундаментальные решения не быстрые, но действенные и генеративные (создают новую реальность). Запаситесь терпением и чувством юмора, и начинайте менять организационную систему. Постепенно, шаг за шагом. С той скоростью, которая для вас комфортна. А декомпозиция и другие Agile-практики со временем заработают!

Great! Next, complete checkout for full access to Scrum.ru Consulting.
Welcome back! You've successfully signed in.
You've successfully subscribed to Scrum.ru Consulting.
Success! Your account is fully activated, you now have access to all content.
Success! Your billing info has been updated.
Your billing was not updated.