Trabalhando em uma organização grande, geralmente os membros da equipe de desenvolvimento não conseguem obter acesso direto ao cliente para reunir requisitos. É possível / aconselhável fornecer uma lista de perguntas a um gerente de contas para que eles possam reunir requisitos em seu nome?

• Possível: sim :-)

• Recomendável: somente se realmente não houver outro caminho. Isso resultaria facilmente em requisitos muito frágeis e pouco compreendidos. E os problemas podem aparecer apenas posteriormente, durante os testes de implementação ou aceitação.

Idealmente, a coleta de requisitos deve ser uma série de discussões detalhadas entre cliente e desenvolvedor (s).Os clientes geralmente têm idéias muito fracas do que realmente querem, implementando sua primeira descrição vaga, como é quase inevitavelmente levaria a problemas. Portanto, os desenvolvedores devem poder determinar o preço de cada ideia / história / requisito, o que ajuda os clientes a priorizar suas necessidades e fornecer feedback técnico sobre o que é possível e viável. Além disso, eles devem entender o domínio do problema com a profundidade necessária, a fim de fornecer a melhor solução técnica para o problema do cliente. E ao longo do caminho, eles devem garantir que entenderam o cliente adequadamente, o que significa pedir esclarecimentos e repetir com frequência o que eles entenderam com suas próprias palavras durante as sessões de comunicação (além de fornecer protótipos / maquetes de IU das idéias do cliente).O melhor meio para isso é a comunicação oral - se não for possível pessoalmente, uma videoconferência ou telefone é a próxima melhor opção.

Ter uma pessoa não técnica como canal de comunicação entre clientes e desenvolvedores limita severamente a eficiência da comunicação. Mesmo o envio e recebimento de documentos por e-mail seria melhor, onde não há pelo menos intermediário, portanto há menos uma possibilidade de mal-entendidos.

Embora eu concorde com Péter Török que um intermediário pode limitar a eficiência, ter um não-desenvolvedor conversando com usuários finais pode aumentar a eficácia da comunicação.

Descobri que os desenvolvedores e os usuários finais costumam conversar juntos, mas ainda se entendem mal porque são de "mundos diferentes". Ao falar as mesmas palavras, eles podem entender que significam coisas completamente diferentes ... Um intermediário que entende a mentalidade / linguagem do usuário final e do desenvolvedor pode valer seu peso em ouro, melhorando a compreensão mútua do que é necessário / o que será desenvolvido.

Dito isto, perguntar a um gerente, seja ele um gerente de contas ou qualquer outro tipo de gerente, não é o caminho a seguir. Fazer a ponte entre os mundos desenvolvedor e usuário final é uma habilidade e não algo que você faz "como um aparte".

Em suma, essa maneira de trabalhar é repleta de perigos e foi uma das razões pelas quais o Manifesto Ágil nasceu.

{má tentativa de humor} Implore, peça emprestado, lute, trapaceie, roube, encante, vá ao pub, faça o que puder para realmente se envolver com o usuário final {/ má tentativa de humor}

Mas, falando sério, se você não puder obter acesso, verifique se há um ciclo rápido de feedback. Portanto, sim, você pode fazer perguntas através do gerente de contas (se você pode acessar o cliente diretamente, mesmo que remotamente por e-mail ainda seja melhor), mas faça-o todos os dias e forneça um protótipo o mais rápido possível para que o cliente experimente.

Caso contrário, você tem um risco enorme de entregar algo que o cliente final realmente não deseja.

Eu trabalho em uma organização de médio e grande porte e temos uma equipe de soluções de negócios que tem muitos analistas de negócios. Eles fazem um trabalho importante, pois entendem muito bem o processo de negócios e traduzem o que a empresa deseja e o que o desenvolvedor entende. Funciona de outra maneira também. Se eu detectar algum problema de design e / ou arquitetura ou propuser uma maneira alternativa de resolver o problema, converso com eles e eles, por sua vez, nos negócios.

Em uma empresa de grande porte, há muitas coisas a considerar, além de técnicas, ao fazer um requisito. Assim como os problemas de treinamento da equipe, como não impactar um cliente com uma alteração, como um processo de compensação existente para tornar sua pergunta um problema, ou "John" é marketing, usa essa função e você não pode simplesmente mudar isso etc.

Para responder sua pergunta, se você possui uma estrutura, use-a. Dê a eles a lista de perguntas para acompanhamento com os gerentes de contas comerciais.

Você está jogando a versão de coleta de requisitos do jogo por telefone. Na melhor das hipóteses, isso causará muita ineficiência na comunicação. Na pior das hipóteses, causará requisitos reunidos incorretamente. A importância desse ciclo de feedback e sua eficiência é um dos principais motivos pelos quais o Representante do Cliente é uma das funções mais valiosas (e mais difíceis de dimensionar) de uma equipe Agile.

NÃO

Tomando sua pergunta literalmente, a resposta não pode ser outra coisa senão um retumbante "NÃO! NÃO! MIL E VINTE E QUATRO VEZES NÃO!" a menos que o "Gerente de contas" também seja consultor, analista e desenvolvedor treinado

Se houver um intermediário não treinado no processo, é melhor enviar as pesquisas dos usuários por e-mail e apenas ligar o gerente de contas. Ele / Ela não pode agregar valor ao processo, mas certamente pode distorcer as comunicações.

A função apropriada do gerente de contas nesse processo é participar da conversa como parte interessada , não jogar middleware ou analista amador.