Menos é Mais – Engenharia de Software
Um dos grandes problemas com as técnicas de levantamento de requisitos convencionais é que se dá ao cliente a liberdade total para inventar características “essenciais” ao projeto.
Premissas das Análises Estruturada e Essencial como “recursos infinitos”, “prazo infinito” e técnicas de entrevista como brainstorm deixaram um legado de mal costume e não cabem mais nos tempos de hoje, quando a competição é extremamente acirrada e quem chega primeiro leva uma fatia considerável do mercado. Quando o levantamento de funcionalidades é feito dando-se liberdade total ao cliente, cria-se o compromisso de construir um projeto muito maior do que a necessidade real e imediata, gerando uma expectativa com chance quase total de frustração.
Posts anteriores:
Além desse inchaço de requisitos, a fase de análise dessa grande quantidade de requisitos causa uma fase muito longa de criação de diagramas, modelos abstratos e redação de textos, de onde devem partir as reuniões de validação de entendimento que geram mais confusão.
Nos processos convencionais, inicia-se então uma fase de projeto, em níivel mais baixo, que afasta o cliente da solução que ele espera, pois começam a surgir os detalhes mais técnicos. A partir daí, vem a implementação de todo o conjunto de funcionalidades levantadas na primeira fase. Mesmo que seja escolhido um modelo híbrido interativo + cascata, até que o cliente possa ver o mínimo que seja do projeto pronto, vai se passar um período considerável. E muito provavelmente o cliente chegará à conclusão de que a implementação não corresponde ao que ele imaginava para o software.
A solução? Menos! Menos tudo! Menos reuniões, menos requisitos, menos análise, menos modelos e diagramas. Definindo um pequeno conjunto de características que abordem o núcleo do problema a ser solucionado, é possível trabalhar num processo iterativo curto, de trabalho conjunto do desenvolvedor com o cliente, que terá contato com algo concreto, como o funcionamento das telas da aplicação. Dessa maneira, será possível avaliar o mais cedo possível se o entendimento está correto para ambos, desenvolvedor e cliente. Com o escopo reduzido, eventuais correções podem ser feitas até mesmo durante a apresentação, e como as iterações são curtas e frequentes, rapidamente o cliente terá um produto que funciona nas mãos.
Saímos de um cenário que entregava uma solução da qual o cliente não participou, conceitualmente errada, com funcionalidades não essenciais e depois de um longo prazo para um cenário novo que entrega em curto intervalo de tempo um produto que resolve o problema primário do cliente, com sua direta participação. Isso garante menor custo e maior satisfação. É isso o que se chama de “release early, release often”. Entregue cedo, entregue frequentemente.
Obviamente, o produto não precisa estar 100% acabado, com as maquiagens visuais de interface e artimanhas para produtividade de operação, mas o já estará operacional, guardando dados e gerando informação. Claro que esta foi apenas uma visão rápida, superficial, para caber num blog post. Façam seus comentários e poderemos discutir as idéias apresentadas. Até a próxima.
