Портал №1 по управлению цифровыми
и информационными технологиями

Технический долг и беклог

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

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

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

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

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

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

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

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

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

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

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

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

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

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Самое свежее

  •  
  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT