Не могу оторваться от темы беклога, ведь это именно то место, где принимаются решения. Продолжу о вопросах вокруг технического долга и способности команды инвестировать в его уменьшение. 

Идеальные продукты не существуют, каждый из них имеет свой набор компромисов. Модули и функциональные блоки приложений развиваются в разные стороны, с разной скоростью, для удовлетворения разных потребностей. Изменяются, форматы, масштабы, нагрузки, накапливаются данные. Работы по развитию выполняют люди. Инженеры принимают архитектурные и технические решения исходя из контекста конкретного момента.

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

Задача на рефакторинг попадает в беклог.

В идеальном мире, для того, чтобы она попала в условный спринт в перспективе ближайших 3 лет, она должна стать более ценной для команды/компании с точки зрения субъективно оцениваемой ценности, чем изменения, связанные с развитием расширяющим бизнес-возможности приложения/сервиса.

Как ответить на вопрос, имеет ли право команда на подобную инвестицию?

• Имеет. (точка)
• Имеет, поскольку сама вольна управлять собственными ресурсами, беклогом и определять приоритеты задач
• Имеет, если обладает ресурсами на эксперимент (вдруг инвестиция в рефакторинг не окупится)
• Имеет, если сможет подтвердить ценность
• Имеет, если сможет заработать и проводить эти работы из нераспредленной прибыли?

Следом идут закономерные вопросы:

• Что, если таких задач в беклоге нет? Не является ли подобная ситуация индикатором не управляемого риска?
• Что если таких задач в беклоге много? Почему это произошло, и что теперь делать с этим объемом?
• Будет ли полезно ввести и выдерживать резерв/норму минимального выделяемого объема мощностей команды для задач технического экспериментирования / рефакторинга? 
• Что делать с мотивацией членов команды, отдельные или множественные предложения по рефакторингу от которых были отвергнуты, или в последний раз реализовывались не далее чем никогда?

Кто вообще может принимать эти решения? Может ли кто-то кроме команды совместно с владельцем продукта принимать решения о приоритетах, когда сравниваются внутренние и внешние задачи? 

Если – нет, то как сопоставлять голоса разных членов продуктовой команды, когда маркетолог продукта говорит о безальтернативной приоритетности новых возможностей, а full back-end 🙂 разработчик говорит о необходимости выделения десятков условных часов инженеров на перестройку структуры хранилища данных и maintenance скриптов?

Может ли на эти вопросы ответить внутренняя корпоративная продуктивая команда, не обладающая действительной самостоятельностью?

“Вопросы … вопросы, требующие ответов. Загадки тьмы.”