No Scrum, os desenvolvedores devem conversar diretamente com os clientes (ignorando o pedido)?

Como o proprietário de um produto no scrum deve lidar com perguntas muito detalhadas da equipe sobre os recursos que estão implementando que ele não pode responder instantaneamente? Quando seria claramente a solução mais rápida para o desenvolvedor falar diretamente com o próprio cliente?

Gostaria de saber se a comunicação direta entre a equipe e o cliente prejudica o papel do proprietário do produto. Sinto que o pedido deve representar exclusivamente o cliente e, portanto, responder a todas as perguntas sobre os requisitos - mesmo que isso demore mais. Ignorá-lo parece enfraquecê-lo e, eventualmente, torná-lo supérfluo ...

Existe uma prática recomendada no scrum?

É sempre uma boa ideia (especialmente nos chamados projetos Ágeis) não aderir a algum culto de carga ou livro de texto dizendo "quem (não) deve falar com quem", mas ligue seu cérebro e faça o que for melhor projeto.

Embora a comunicação entre o pedido de compra e o cliente deva ser o padrão (devido aos motivos apontados por @PatrickHughes em seu comentário), você pode enfrentar uma situação em que um requisito de negócios complexo precisa ser esclarecido e a comunicação direta entre um desenvolvedor e um desenvolvedor. especialista em negócios irá acelerar muito as coisas. Em tal situação, deve-se evitar jogar "sussurro chinês" com a OP no meio e deixar que o desenvolvedor e o especialista em negócios conversem diretamente entre si - por esse contexto restrito.

No entanto, o pedido nunca deve ser ignorado. Idealmente, ele participa dessa conversa, provavelmente como moderador. Ele pode verificar se o cliente não apresenta requisitos completamente novos sobre a mesa durante a palestra, ou requisitos contrários ao que foi acordado anteriormente.

Isso depende também das pessoas envolvidas e da situação. O OP pode ter confiança suficiente no desenvolvedor específico e no especialista do cliente, para deixar os dois falarem sozinhos sobre um tópico específico e informar o que foi dito depois. Em outra situação, com outras pessoas envolvidas, ele pode preferir participar mais ativamente. Para acertar essas decisões é o núcleo de um bom gerenciamento de projetos.

Para os desenvolvedores, o proprietário do produto é o cliente. Idealmente (e sei que isso nem sempre é possível), o proprietário do produto deve ser um representante direto do cliente, um especialista em domínio e futuro usuário do sistema.
Essa é a melhor maneira de garantir que você tenha informações diretas e corretas disponíveis e as linhas mais curtas possíveis em seus processos.

O exemplo ideal é provavelmente a equipe com a qual estou trabalhando agora. O proprietário do produto é um especialista sênior em domínio e usuário final, com total autoridade para autorizar decisões de projeto no local (e a disposição e capacidade de realmente fazê-lo). Ele é parte integrante da equipe e auxilia diretamente o analista e o designer a escrever as histórias dos usuários, bem como programadores e testadores na criação do produto, fornecendo feedback quase instantâneo sobre perguntas de implementação e cenários de teste.
As linhas não podem ser realmente mais curtas do que ter seu futuro usuário sentado ao seu lado durante a codificação :)

Você deve se lembrar que o cliente da empresa que o emprega como desenvolvedor tem objetivos diferentes da empresa que o emprega.

O proprietário do produto deve representar os objetivos da sua empresa e não os objetivos do cliente. Portanto, se os desenvolvedores forem direto ao cliente, poderão prejudicar sua própria empresa.