Миф о proxy product owner

Достаточно часто в аутсорсинговых Scrum проектах происходит ситуация, когда владелец продукта (лучший перевод, который я смог придумать для термина "product owner") доступен только в ограниченные промежутки времени и только узкому кругу членов команды.
Причин тому масса:
  • разница во времени
  • низкий уровень владения иностранными языками членов команды
  • занятость владельца продукта на других проектах и другие.
Естественно, пытливый отечественный ум эту проблему быстро "нащупал" и так же быстро, не вдаваясь в детали, нашел для нее решение — прокси. Причем прокси на стороне аутсорсера. Решение это, как правило, по началу нравится обоим сторонам. Казалось бы, все в выиграше:
  • заказчик получает свободную минутку для игры в cut the rope
  • команда -  мгновенные ответы на все интересующие их вопросы
  • прокся -  возможность указать в резюме, что был "проксёй над владельцем продукта".
Все счастливы. Первые неколько месяцев. В течении этих нескольких месяцев происходит тотальное и повсеместное делегирование. Снача прокся отвечает на мелкие вопросы по улучшению дизайна и исправлению грамматических ошибок в требованиях. Затем медленно, но уверенно он начинает решать вопросы о требованиях к системе. Чуть позже прокси начинает приоретизировать беклог (и да я это видил своими глазами). И опофеозом всего происходящего становится проведение демо, которое принимает прокси.
В процессе так называемого делегирования происходит масштабнейшая катастрофа, состоящая в потере коммуникации между владельцем продукта и командой. Как правило, симптомами такой потери являются:
  • владелец продукта потерял представление о том, что реализовано, а что не реализовано в приложении
  • прокси понимает сложность тех или иных задач и способен спрогнозировать эстимейт команды, владелец продукта считает простые задачи сложными, а сложные задачи простыми и не готов к диалогу относительно оценок команды
  • у команды создается впечатление, что проект бросает из стороны в сторону, команда перестает понимать цели проекта
  • команда не понимает потребностей пользователей системы
Причина всего происходящего в одном - неверном решении о создании позиции прокси владельца продукта. Владелец продукта работает в свой области годы или даже десятилетия. Все это время он потратил на то, что бы почувствовать свое дело, его понять и осознать. Ни один даже самый лучший эмпатик не сможет за несколько дней (которые как правило отводятся проксе) понять то, что этот человек понимал в течении очень долгого времени.
Собственно я вижу несколько простых приемов, которые куда более эффективно, чем введение прокси владельца продукта, смогут решить проблемы коммуникации между командой и ограниченным во времени заказчиком:
  • командировки команды к владельцу продукта и наоборот. Если по каким-то причинам совместная работа - не вариант, можно хотя-бы договориться с владельцем продукта о временном окне, в котором он доступен для членов команды и подстраивать проведение всех значимых мероприятий под это окно
  • обязательное присутствие владельца продукта на ретроспективе. Никакие meeting minutes не дадут сторонам того понимания друг-друга, как даст час совместного рассмотрения проблем, возникших за спринт
  • изучение всеми членами команды, а не только одним, специфики бизнеса заказчика его предметной области. Коллективный разум способен на поразительные вещи
Самое главное, владелец продукта не должен быть богом. Он просто человек, которого нужно воспитывать и который куда больше команды заинтересован в успешном выпуске продукта.