Por que documentos de requisitos longos?

Por que documentos de requisitos longos?

Você realmente precisa de documentos de requisitos super detalhados e super longos? Eu já vi documentos assim com mais de 50 páginas! Será que eles estão ajudando o seu time? Mesmo documentos não tão grandes como os casos de uso? Será que eles ajudam ou atrapalham?

Antes de chegar a alguma conclusão, vou voltar um pouco no tempo…

O Início

Quando eu comecei a programar, em meados dos anos 1990, não usava documentos de requisitos desse tipo.  A gente conversava, entendia o que tinha que ser feito e depois …. programava. Simplesmente, programava. Ou fazia no máximo um protótipo em papel mesmo antes de programar.

Você já deve ter feito isso pelo menos uma vez na vida. Nem que seja na faculdade. Estou certo? E o mais impressionante é que isso costumava funcionar! Não é mesmo?

Mas em algum momento (para mim aconteceu em meados dos anos 2000) veio aquela ideia de que se você não tem um processo definido e documentos sendo produzidos no meio deste processo você não está sendo profissional de verdade. Você está no go horse total!

E naquela época o processo mais aceito e conhecido era o RUP. O RUP tem seus pontos fortes, como ser iterativo e incremental. Como atacar os principais riscos de um projeto no início. Mas, na maioria das vezes, entendemos errado o RUP e acabamos com processos inflexíveis e cheio de documentos no meio do caminho. Cheio de burocracia entre o que o cliente queria e a solução, que é simplesmente código em produção.

E foi assim que chegamos nos documentos de requisitos super detalhados e super longos. De alguma forma, naquele momento, entendemos que um analista de requisitos tinha que especificar tudo com o cliente, produzir um documento de requisitos e passá-lo pra frente para um arquiteto ou direto para um programador.

E aí criamos um novo problema…. Os documentos de requisitos tem que ser entendidos pelo analista, pelo cliente, pelo desenvolvedor, na verdade por qualquer um que precise ler aquele documento mesmo que não tenha participado da sua escrita.

Mas a linguagem escrita tem o poder de ser muito ambígua. É muito difícil escrever um documento e todos entenderem a mesma coisa. É nesse momento que as equipes começam a se preocupar com a forma do documento, criando várias padronizações, campos com valores predeterminados, etc.

E isso acaba só aumentando o problema…. Passamos a nos preocupar mais com a forma do que o conteúdo. O programador devolve um documento de requisitos para o analista por que o documento não estava no padrão X, por que faltou tal informação obrigatória, …. E o problema do cliente (sistema funcionando) vai ficando em segundo plano….. E sua equipe está agora um apontando os dedos um para o outro tentando achar um culpado pelos atrasos e bugs.

Eu já trabalhei em alguns ambientes que funcionavam assim… E você?

O time passou então a seguir o processo pelo somente para atender ao processo e não para resolver a necessidade do cliente.

A Redescoberta

Então, por volta de 2011 e 2012, eu voltei a descobrir que o que eu fazia lá no início não estava tão errado assim. Sim, eu precisava de um processo. Mas de um processo que conectasse as pessoas certas em volta de atender as necessidades do cliente. Não de um processo só para ter um processo e ficar bem na fita.

Foi nessa época que eu descobri o XP e o Scrum que traziam uma mensagem diferente do que eu tinham visto antes. A necessidade do cliente voltava a ser o problema, voltava a ser o centro da atenção. Todo o processo de desenvolvimento deveria estar lá para atender ao cliente.

A ideia de um time formado por pessoas com habilidades diferentes em torno de um objetivo comum estava mais forte do que nunca. É esse time trabalhando junto que permite eliminar aqueles documentos de requisitos gigantes.

É nesse contexto que surgiram as Histórias de Usuário com toda a sua simplicidade.  Elas registram os requisitos sem entrar em muitos detalhes.  Deixando o time se concentrar no que realmente importa: resolver os problemas dos clientes, criar software e colocar na mão do cliente…

Mas não adianta tentar usar toda essa simplicidade das histórias de usuário com o mindset antigo. É por isso que eu montei um mini curso de histórias de usuário. Esse mini curso vai começar a te mostrar como usar as histórias de usuário de forma realmente efetiva.

Quase ia me esquecendo…. o mini curso é GRATUITO. São 3 vídeo aulas de cerca de 10 minutos cada. E um PDF de bônus.

Para ter acesso à esse mini curso, clique aqui e tenha acesso imediato.

Um abraço!

Seu comentário aqui

%d blogueiros gostam disto: