sábado, 25 de junho de 2011

Quando Analista de Negócios não faz o seu Papel

teatro 

Uma das grandes causas de fracasso de um projeto é a péssima analise do negócio. Isso acontece quando analista de negócios não faz o seu papel de facilitador entre o cliente e a equipe.

Não estou afirmando que analista de negócios deve saber tudo sobre o negócio. Mas procurar o cliente e as partes interessadas para aprender sobre o negócio e elaborar os requisitos do cliente, são processos que fazem parte do seu trabalho. Mantendo uma comunicação freqüente entre o cliente, as partes interessadas e a equipe.

Geralmente, o fracasso da analise do negócio é causada pela pouca comunicação com o cliente, as partes interessadas e a equipe. Conseqüentemente, analista de negócios acaba levantando requisitos sem valor para desenvolvimento do produto, frustrando o cliente com produto sem valor e a equipe pelo fracasso do projeto. Situação lamentável que leva ao retrabalho e a possível demissão do analista de negócios.

Ta-ta for now

5 comentários:

  1. Todas as pessoas são falíveis, errar é inerente ao ser humano.
    Contudo, o que precisamos discutir é o erro sistêmico, por exemplo, quando Analista de Negócio falha por diversas vezes e isto acaba por comprometer os resultados dos projetos.

    Para mitigar este risco, uma das soluções é fazer
    protótipo, PoC (provas de conceitos) e simulações antes da equipe começar a desenvolver o produto.
    Uma outra boa pratica á fazer entregas constantes e usar o modelo iterativo/incremental para o cliente final.

    ResponderExcluir
  2. Obrigado professor Rildo pelo comentário. Realmente o ser humano é sujeito a errar.
    Suas sugestões para mitigar o risco na analise de negócios são ótimas. Tinha pensado em entregas constantes em um modelo iterativo/incremental, acho uma excelente prática.

    ResponderExcluir
  3. Este comentário foi removido pelo autor.

    ResponderExcluir
  4. Concordo com o Rildo. Ele foi muito feliz na colocação dele. Acredito que os protótipos são uma das melhores formas de alinhar conceitos com o cliente. Desta forma o cliente consegue vislumbrar a solução q será implementada e diminuir os riscos de projeto.
    Quanto à estregas constantes e incrementais penso q seja uma prática necessária e que deve ser seguida sempre. Mas o que vejo muito, e não recomendo, é equipe começar a desenvolver o sistema pelos cadastros de dados e atividades "satélite" do sistema (de menor importância), ao invés de começar desenvolvendo as atividades principais do sistema.

    ResponderExcluir
  5. Obrigado pelo comentário dotDicas.

    ResponderExcluir