A era das especificações já passou. Os desenvolvedores não devem mais estar isolados dos usuários. O constante feedback é importante para a evolução do produto e o entendimento por parte da equipe só acontece com esse contato próximo.
Levantar, no geral, traz uma conotação de que os requisitos estão lá, espalhados, é só uma questão de juntá-los num único documento e, voila, a especificação está pronta e completa.
A realidade é um pouco diferente. É preciso uma atenção muito maior ao processo para acompanhar o dinamismo do mercado atual. Um produto especificado a priori, é, por definição, obsoleto no momento do lançamento. A ideologia do agile é baseada, quase que completamente, nessa premissa de que o software precisa evoluir e ser atualizado constantemente, para que o produto final seja eficiente.
Requisitos são descobertos
O processo de levantamento de requisitos passa então a ser, uma etapa on the fly, quase que trocando o pneu do carro com o carro ainda andando. Conforme vamos desenvolvendo o software, os usuários utilizam, avaliam e devolvem feedback, permitindo uma evolução do software mais objetiva e, espera-se, com menos desperdício.
No mercado como um todo, especialmente os que têm como alvo o consumidor final, são regidos pela máxima “o cliente tem sempre razão”. Em TI, a máxima é exatamente o contrário: “o cliente nunca sabe o que quer”. Eu acredito que o melhor lugar é o meio: “o cliente sabe o que quer, mas não como quer”.
A papel principal da equipe de TI em um projeto é a adequação. Desenvolver, de modo geral, vem se tornando commodity. O grande desafio está na adequação. Milhares de soluções concorrentes são lançadas a todo momento, qual vamos utilizar?
Diferente de outras áreas, TI não é uma área exata (mesmo que alguns gostem de dizer que sim). Os contextos são muito variados e o que funciona na minha empresa, possivelmente não funcionará na sua. Fazer esse “de-para” é a grande dificuldade.
Nem lá, nem cá
Mesmo que as especificações a priori hoje não sejam mais utilizadas, ou muito pouco utilizadas, partes dela ainda tem muito valor. Muitos que entenderam mal o agile, saem botando a mão na massa no dia 0, utilizando como escudo a frase tão repetida “errar rápido para evoluir rápido”. Porém, iniciar tão cedo pode ter o efeito oposto, começar sem entender o mínimo pode trazer atrasos, muito desperdício e ruído.
Entender bem o problema, o contexto e suas variáveis é essencial para um projeto bem sucedido. Utilizar um bom mapeamento do que se sabe, entender profundamente como tudo é feito atualmente, traz consigo o benefício de muitos insights, que não se revelariam de outra forma.
Descobrir os requisitos depende desse equilíbrio. O conhecimento do que é atual e a experimentação. O novo e o velho. Especificar demais atrasa e engessa o projeto. Entender de menos depende de muita experimentação e perde em profundidade. Encontre a sua medida ideal e não pule etapas.
