Sei que muitas consultorias de Tecnologia não vão gostar de ler isso aqui, mas, ainda hoje, compra-se e vende-se desenvolvimento de software “in an old fashioned way”, pois é ainda um bom negócio. Veja o caso dos “buracos” no post anterior.
Sem dúvida, este modelo “tradicional” é mais confortável para ambas as partes: para quem está vendendo e para quem está comprando. No entanto, ela pode não ser ideal, principalmente, para quem está investindo. Quantas vezes gastou-se muito mais do que o previsto? Ou os prazos de entregas foram sistematicamente postergados, sem a entrega definitiva?
O processo orçamentário nas empresas é normalmente complexo, pois o “cobertor é sempre curto”. Mas, uma vez que um projeto que requeira desenvolvimento está na lista, é importante que a estimativa de esforço e custo esteja o mais completa possível. Qual é o gerente que quer pedir aportes sistemáticos aos seus diretores? Assim, neste modelo tradicional, o escopo “precisa” conter tudo. É ou não é? E pede-se mesmo aquelas funcionalidades que talvez nunca serão utilizadas. Mas esta é a hora de fechar o orçamento e ninguém quer ser responsável por esquecer de estimar alguma função. Mas a “nova” TI não é mais aquela que anota pedido, é aquela que entende o problema e atua de forma pragmática para resolver da melhor forma possível (que diz respeito em atender à necessidade do cliente, com o esforço otimizado e custo reduzido).
No outro lado, tem a empresa de consultoria ou fábrica de software que será contratada para fazer aquele desenvolvimento e que não quer perder dinheiro. Assim, seu orçamento tem aquela “gordurinha”, que é tratada como o risco do projeto. Não é assim que funciona? Assim, fazendo o balanço, o projeto já nasce com gordura nos dois lados. Confortável para todo mundo, correto? Claro que não! O investimento que a empresa vai fazer poderia ser cuidado de forma mais diligente. Será que aquele escopo imaginado no momento do orçamento vai se manter inviolável? A minha experiência mostra que não. Nunca! A mudança de escopo é uma certeza. Ah, mas não tem problema… Tem “gordurinha” (e tem para que o contratante não volte com o “pires na mão”, pedindo mais dinheiro).
A contratação de um projeto através de métodos ágeis ainda acaba gerando um certo desconforto. Existem alguns modelos de contratação, mas ninguém gosta ou quer contratar algo sem um escopo fechado ou a data de entrega firmada. No entanto, as estimativas podem ser feitas de forma bem assertivas, principalmente se tomar por base a forma de contratação tradicional, aquela descrita acima. Quando os conceitos são utilizados adequadamente e o foco no valor é priorizado acima de tudo, todas as funcionalidades sem importância, mas que tinham sido orçadas originalmente, podem ficar de fora da entrega. A prioridade é em tudo aquilo vai trazer valor para o negócio, retorno. Desta forma, existe uma grande chance de se entregar o projeto antes do prazo estimado previamente (lembre-se: lá tinha tudo!).
Além disso, com a entrega em ciclos e sabendo que as mudanças são inevitáveis, é muito provável que novas necessidades apareçam. Com a priorização bem feita e foco no valor para o negócio, basta continuar fazendo estas prioridades, mesmo que elas venham mudando ou evoluindo. É bastante provável que você tenha um produto ou um software num tempo mais curto do que o que queria. Ele vai estar completo? Provavelmente ainda não. Mas em algum momento, você vai poder chegar à conclusão que o que você já tem em mãos é o que precisa para atingir os resultados esperados pelo negócio, sem um bando de funcionalidades desnecessárias (lembre-se: você está entregando o que tem valor).
No outro caso, provavelmente, as mudanças de escopo frequentes vão fazer você revisar seu orçamento (mesmo com as gordurinhas) e entrar no desagradável processo de renegociação do contrato, e provavelmente os prazos serão furados. Muitos destes projetos, com tantas alterações acabam nem sendo finalizados. Muitas vezes, quando o produto está pronto já se passou tanto tempo que as necessidades do mercado já mudaram (time to market perdido!) e o projeto deixa de ser estratégico e passa a ser um grande elefante branco. Quem é que nunca passou por isso?
Mas esta é uma quebra importante de paradigma: uma mudança cultural que não é fácil e bastante contraintuitva. Mas funciona! Pode apostar!
