SNIPPET: O cliente (não) sabe o que quer?!
A motivação para escrever esse snippet é um comentário, do Eduardo Pires, no post BDD na prática – parte 4 – Partindo do TDD. Veja:
[..]O que me deixa em dúvida é que na maioria das vezes o desenvolvedor não tem toda a visão das funcionalidades que irão atender o negócio do cliente (nem o analista de negócios, muito menos o cliente). Sendo assim as coisas sempre saem daquele jeito que todos conhecem.
Me leva a pensar:
O BDD é indicado apenas para situações onde a equipe tem domínio suficiente sobre o negócio do cliente?[..]
Você concorda com ele?! Eu não.
Penso que, em muitos casos, temos níveis altos de incerteza. Aliás, quando é assim, o objetivo precisa ser minimizar essa incerteza. Qualquer coisa além disso é desperdício. Para isso, o segredo é trabalhar com um “produto mínimo viável”. Ou seja, escrever a menor aplicação possível, que atenda um conjunto “aparentemente” estável de requisitos, e entregar para o cliente.
E você? O que acha?
Um dos principais objectivos de BDD é clarificar com o cliente os seus requisitos através de cenários e exemplos concretos. Ou seja, aplica-se precisamente quando a equipa não tem domínio de negócio. O problema pode ser a falta de acesso/disponibilidade do cliente, como no meu caso. Ainda assim nós estamos usando BDD pela sua componente de documentação executável (executable specification) e tentamos que o cliente pelo menos reveja as features e confirme se estamos especificando correctamente o que ele quer.
O cliente nunca sabe o que quer, ele sabe apenas a próxima coisa que ele quer.
Por isso concordo que entregar a menor aplicação possível e evoluí-la de acordo com a necessidade do cliente é a mehlor forma possível de se trabalhar. Desta maneira não perdemos o alinhamento da necessidade e permitimos que o cliente tenha participação criativa no desenvolvimento, uma vez que vendo o software em funcionamento é mais provável que este encontre pontos de melhoria.
O argumento acima não impede que usemos BDD nem o torna menos util, pois o cliente sempre sabe o que espera quando executa uma ação no sistema, e podemos mapear este pequeno pedaço de comportamento e evoluí-lo com o tempo.
Se falamos de desenvolvimento evolutivo e metodologias ágeis, obviamente teremos nossas specifications ágeis e variando durante o projeto.
Olá, Eu sou o motivador do post, logo quero registrar minha opinião
O que eu disse foi:
“O cliente na maioria das vezes não tem a visão de todas as funcionalidades que irão atender ao seu negócio”
Dentro de meus estudos entendo que o BDD estimula o contato entre cliente/analistas/desenvolvedores onde juntos são responsáveis pela a escrita de cada funcionalidade do sistema, questionando-se e baseando-se em cenários do negócio do cliente.
Vou contar um case que ocorreu comigo:
Trabalhei em um projeto para um banco (o 2º maior do Brasil), o banco pediu um projeto (que começou grande e ficou enorme após uma série de reuniões).
O cliente sabia o que pedia e por conta dele mesmo o projeto cresceu mais.
No levantamento inicial a diretoria do banco dava a necessidade aos responsáveis da minha empresa onde depois seria feito um mais detalhado com as áreas responsáveis.
Nesse momento entra o BDD certo?
Pois é… para cada reunião demoravam-se cerca de 2 semanas até a próxima (isso durante o levantamento). Impossível. Colocamos um analista de negócios full-time no local para acompanhar o processo das áreas e fazer o entendimento junto ao cliente.
O problema:
Todo o negócio estava em sistemas (mega antigos), os encarregados e responsáveis das áreas não sabiam como funcionavam os processos, eles sabiam operar os processos dentro do sistema:
[...] Fazemos uma planilha, depois importamos no sistema, ai o sistema faz o processamento e [...]
O cliente não sabia quais eram as regras de decisão, como funcionava o cálculo de risco, que critérios eram necessários para ir para o caminho X ou Y.
O sistema era de uma consultoria que não prestava mais serviço há mais de 5 anos.
Estou citando sobre o departamento de cobrança e recuperação de crédito.
Um banco pode falir se as coisas não funcionarem direito lá!
Mas quem sabia como funcionava? Só o sistema (sem documentação, claro!)
O projeto atrasou, o cliente reclamou, a diretoria do banco ameaçou e etc…
Poderíamos usar o BDD mesmo assim? Acredito que sim, mas teria melhoras?
A ideia não é justamente todos escreverem juntos (feedback constante) ?
Mesmo com o levantamento feito pelo analista o cliente não aprovava, pois não tinha conhecimento o suficiente para colocar o nome e assinar em baixo.
O cliente não aceitou receber “um pedaço” por vez, talvez ele estivesse se recusando a ter seu problema resolvido, fato, mas e nesses cenários o que o BDD recomenda?
Vejam, eu sou a favor do BDD, se alguém já passou por um projeto com um cliente difícil desse e conseguiu o sucesso utilizando BDD gostaria de conhecer como.
Abc’s !!!