С этой ролью легко получить разницу с вариантом из Экстремального Программирования: "Заказчик платит - вы делаете" уже не будет соответствовать реальности.
Для вендора контролов/компонент заказчиков много, целое сообщество клиентов, десятки тысяч, и даже если один из них хочет оплатить конкретное изменение, это вовсе не означает улучшение для всего сообщества клиентов и вендора. Кому-то, наоборот, даже хуже станет, проблемы появятся: "я думал это так работает и отдал новое приложение не проверив" и аналогичные негативные ситуации. А вендору может быть очень затратно и невыгодно: сделать сделали, а денег получили копейки, теперь зарплату платить нечем.
И если у вендора некоторый сотрудник исполняет роль "Представитель Заказчика"/"Product Owner", то от него требуются варианты задач в конечных приложениях/у конечных пользователей, а не варианты решений у разработчиков этих приложений. То есть решения тоже конечно хорошо бы посмотреть (особенно если они уже есть), но их лучше не использовать как основу для добавления нового функционала в продукте вендора. Даже если кому-то из клиентов удобно изложить свою задачу в виде конкретного решения, команде разработчиков не стоит способствовать такому формату общения: ведь в этом решении могут не быть учтены десятки сценариев просто потому, что клиенту они не важны/не подумал/не знал/и так понятно. Или даже подумал и "именно так у меня и должно работать": у нас же тут все таки сообщество, у каждого разные ожидания и свое "так должно работать". Или даже дальше: у каждого клиента есть свои клиенты со своими задачами из реального бизнеса и вот они-то и правда единственные, кто тут платит деньги всем разработчикам.
С вариантом изложения "задачи в терминах конечного пользователя" разработчикам вендора гораздо легче выбрать средства для реализации этого изменения в приложении. Мы же просто делаем часть функционала вместо разработчика приложения. Мы - часть его команды и такая организация общения/передачи информации может дать больший эффект.
Комментариев нет:
Отправить комментарий