Spice girl manifesto

Eu sou um cara casado. De casamento já se vão oito ótimos anos de vida juntos. Mas nos conhecemos antes disso, mais ou menos uns cinco anos antes. Somando tudo posso dizer que temos uma excelente convivência, uma vida compartilhada por assim dizer a pelo menos treze anos. Ainda assim, não posso dizer que a conheço completamente. Não sei de todos os seus anseios ou vontades, de todos os seus desejos e existem muitos momentos em que ela diz uma coisa querendo dizer outra. Embora isso possa parecer um lamento, é só um fato, que eu aceitei e levo a nossa relação tendo isso em mente. Mas é bem interessante de se pensar que pessoas que dormem e acordam juntos, que compartilham suas vidas de maneira tão intensa não sejam capazes de compreender as vontades um do outro por completo, não é mesmo?

Se mesmo com toda essa intimidade eu aceito o fato do desconhecido, porque você exige do seu cliente algo diferente quando vai iniciar um projeto? Sério, o paralelo não é tão distante. Vocês mal se conhecem, são pessoas em última instância, não empresas. E são desejos/necessidades de pessoas que precisam ser traduzidos em requisitos de software. O mal entendimento desses desejos e vontade pode sim decretar o sucesso ou o fracasso de um projeto. Assim como em casa eu uso várias técnicas para entender o que minha esposa espera de mim, aplico o mesmo pensamento no trabalho.

Outro problema, é a distância entre o desenvolvedor e o cliente. A começar pelo idioma. Enquanto o desenvolvedor entende profundamente o que acontece dentro do software é bem incomum ver esse mesmo profissional entendendo o que acontece no lado do negócio. Mais incomum ainda é ver o contrário, pessoas de negócio que entendem como o software funciona. Assim, esses profissionais falam idiomas diferentes e sua compreensão fica defasada por conta disso.

Só para fins de curiosidade, o título desse post veio de um treinamento de Kanban, ministrado pelo próprio David Anderson, no qual ele disse que mais do que o manifesto ágil, precisávamos agora de um manifesto spice girl. Vendo o espanto dos alunos, ele explicou: So tell me what you want, what you really really want… enfim, entender o problema, a necessidade, é metade da solução.

A seguir eu alguns métodos que usei em algum da minha vida. Não os estou julgando (ainda)…

Questionários
Uma técnica bem antiga, no qual o analista redige questionários e os entrega aos usuários chave do sistema. Muito útil com equipes mais tímidas ou para captar o máximo de respostas de todos os membros da equipe.

Entrevistas
Quanto os questionários se mostram muito frios, uma investigação mais profunda se faz necessária. Marcar entrevistas com os usuários, isolados ou em grupo, pode ajudar a esclarecer diversos pontos que outros métodos deixaram em aberto.

Observação
Nada mais simples do que, ao se automatizar algum processo, observá-lo e ver como o mesmo ocorre, sem depender da narração de outra pessoa. Nós temos o hábito de suprimir etapas, acreditando que são óbvias, ou que estão subentendidas no que já foi dito. Para evitar assunções, veja por você mesmo.

Análise de documentos
Verificar como as informações são registradas atualmente nos permite mapear muito de como o sistema deve ser e inferir quais mecanismos e processos o sistema deve ter para que possa atender àquela necessidade. Reconheço que usei muito dessa técnica no passado.

Essas quatro técnicas foram das que mais usei quando o assunto era automatizar/informatizar um processo que já existia, ou fora dos computadores ou mesmo dentro, em planilhas ou sistemas isolados, integrando tudo. Poderia usar a palavra “simples” para descrever esses sistemas, afinal, buscavam “somente” transformar o processo atual em algo mais dinâmico e seguro. Muito embora ainda exista demanda para esse tipo de sistema, a maior parte dos trabalhos que chegam até mim na última década está bem longe disso. As pessoas chegam com novidades, apps, webapps, enfim, soluções para coisas que não existem no mundo real. Esse novo tipo de aplicação exige uma nova abordagem. Mais do que buscar entender como um processo funciona, agora precisamos validar como o processo foi imaginado para entender se tudo é como se pensou. Assim, seguem os que uso nesse tipo de situação:

Brainstorming
O bom e velho “toró de parpite”. Aqui buscam-se todas as ideias possíveis e mais tarde nós a validaremos e pensaremos em qual rumo tomar. A proposta é muito simples: gerar o maior número de insights sobre o problema que o nosso aplicativo quer resolver.

Prototipação
Existem diversos tipos de protótipos. Desde usando ferramentas, frameworks até mesmo o bom e velho papel e caneta. Sério, isso já me salvou em algumas situações. O nível de realidade que se vai usar aqui depende somente do nível de abstração que seu cliente e você conseguem suportar. Enquanto existem pessoas que conseguem entender alguns rabiscos no papel e imaginar como a partir daquilo surgirá um aplicativo, muitos outros têm dificuldade e precisam de um detalhamento mais próximo do resultado final. Cabe ir avaliando isso ao longo do levantamento de requisitos.

Use cases
Como eu já ouvi gente batendo forte em use cases eu sou obrigado a citá-los aqui. Sim, eles são bons e são necessários. Eu acho bobo voltar àquele debate sobre a documentação, mas só para mencionar, sim, existem documentos que são necessários e precisam ser atualizados, mesmo na visão do mais fundamentalista dos agilistas. A parte boba disso é acreditar que isso (ou o oposto) se aplica a todo e qualquer documento. Tendo isso como posto, já tive processos complexos que precisaram não só de um use case, mas também de um diagrama de sequência para ficar claro para todo mundo. Depois que a tarefa foi cumprida o documento foi desprezado, mas para a sua execução esses documentos foram de vital importância.

e finalmente User Stories!
Como eu gosto muito desse modelo, eu vou deixar aqui só um gostinho, deixo para um outro post falar mais sobre o assunto. O que eu preciso dizer de imediato é que é uma das formas mais simples de coleta de requisitos, trabalhando com uma língua que desenvolvedor e cliente conseguem entender, dividindo o trabalho em unidades que agreguem valor ao produto/projeto, definindo critérios claros de validação para que todos os envolvidos saibam sem sombra de dúvida que o trabalho foi concluído.

Conclusão
Sem o menor preconceito, já usei todas as técnicas acima, umas mais ou menos, sempre buscando entender o que meu cliente precisava. Um bom desenvolvedor vai ter sempre uma boa caixa de ferramentas preparada para usar a certa no momento mais propício. Entender o problema é metade da solução.

Tem-gente-que-nao-sabe-pedir

Posted on: 12 de Fevereiro de 2015, by :

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *