Владелец продукта – одна из ключевых ролей в SCRUM-процессе. Product Owner отвечает за составление и приоритезацию бэклога. И, традиционно считается, что бэклог – это основной способ взаимодействия между PO и командой разработки.

Но, как правило, PO отвечает за продукт целиком, в том числе и за его будущее развитие. И у него должна быть уверенность в высоком качестве. В том числе необходимо, чтобы с развитием продукта не росла стоимость разработки или продукт не завял в регрессионных ошибках. Если для продуктов с коротким жизненным циклом (несколько месяцев) это не представляет проблемы, то для продуктов, которые живут несколько лет, а может быть и десятков лет, эти вопросы становятся одними из самых важных.

Владельцу продукта для контроля и управления качеством такого инструмента как бэклог совершенно недостаточно. И нередко договорившись с командой лишь о составе работ через несколько месяцев (а если не повезет, то и через несколько лет) можно обнаружить, что развитие и сопровождение продукта стало слишком дорогим и сложным. Еще одной проблемой является непонимание PO и заказчиком причин высокой стоимости и медленной разработки.

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

Таким образом, для уверенности в будущем продукта, контракт Product Owner’а и команды необходимо расширять и, помимо бэклога, оговариваются архитектура, модели, тесты и многое другое. Но на этом пути PO ждет немало проблем. Так команда может не захотеть принимать навязанную архитектуру или выбрать технологию, к которой у PO не доверия. Возникают вопросы:

* О чем, кроме бэклога, договариваться с командой?
* Как это сделать?
* Какие факторы необходимо контролировать PO, а что лучше оставить на усмотрение команды?
* Как не убить мотивацию команды?
* И как отслеживать выполнение достигнутых договоренностей?

В докладе будут даны ответы на эти и другие вопросы. Будет рассказано, как наладить взаимодействие при минимальном вмешательстве в работу команды, но при этом сохранить уверенность в качестве продукта и полное понимание его особенностей.