Не могу оторваться от темы беклога, ведь это именно то место, где принимаются решения. Продолжу о вопросах вокруг технического долга и способности команды инвестировать в его уменьшение.
Идеальные продукты не существуют, каждый из них имеет свой набор компромисов. Модули и функциональные блоки приложений развиваются в разные стороны, с разной скоростью, для удовлетворения разных потребностей. Изменяются, форматы, масштабы, нагрузки, накапливаются данные. Работы по развитию выполняют люди. Инженеры принимают архитектурные и технические решения исходя из контекста конкретного момента.
В какой-то момент, по прошествии времени, члены команды могут высказать пожелания по переработке отдельных компонентов приложения для того, чтобы существующий код и архитектура не сказывались негативно на текущих и будущих возможностях членов команды оценивать и реализовывать изменения, чтобы открыть новые возможности с точки зрения перспективы развития и технологиии разработки.
Задача на рефакторинг попадает в беклог.
В идеальном мире, для того, чтобы она попала в условный спринт в перспективе ближайших 3 лет, она должна стать более ценной для команды/компании с точки зрения субъективно оцениваемой ценности, чем изменения, связанные с развитием расширяющим бизнес-возможности приложения/сервиса.
Как ответить на вопрос, имеет ли право команда на подобную инвестицию?
- Имеет. (точка)
- Имеет, поскольку сама вольна управлять собственными ресурсами, беклогом и определять приоритеты задач
- Имеет, если обладает ресурсами на эксперимент (вдруг инвестиция в рефакторинг не окупится)
- Имеет, если сможет подтвердить ценность
- Имеет, если сможет заработать и проводить эти работы из нераспредленной прибыли?
Следом идут закономерные вопросы:
- Что, если таких задач в беклоге нет? Не является ли подобная ситуация индикатором не управляемого риска?
- Что если таких задач в беклоге много? Почему это произошло, и что теперь делать с этим объемом?
- Будет ли полезно ввести и выдерживать резерв/норму минимального выделяемого объема мощностей команды для задач технического экспериментирования / рефакторинга?
- Что делать с мотивацией членов команды, отдельные или множественные предложения по рефакторингу от которых были отвергнуты, или в последний раз реализовывались не далее чем никогда?
Кто вообще может принимать эти решения? Может ли кто-то кроме команды совместно с владельцем продукта принимать решения о приоритетах, когда сравниваются внутренние и внешние задачи?
Если – нет, то как сопоставлять голоса разных членов продуктовой команды, когда маркетолог продукта говорит о безальтернативной приоритетности новых возможностей, а full back-end 🙂 разработчик говорит о необходимости выделения десятков условных часов инженеров на перестройку структуры хранилища данных и maintenance скриптов?
Может ли на эти вопросы ответить внутренняя корпоративная продуктивая команда, не обладающая действительной самостоятельностью?
“Вопросы … вопросы, требующие ответов. Загадки тьмы.”
