Joana Kerr Sua empresa precisa de um novo software para resolver determinado problema e busca uma equipe para desenvolvê-lo. Porém, ao procurar fornecedores, você percebe que não tem todas as informações solicitadas para uma definição de escopo coerente com o esperado e financeiramente viável. Contudo, você quer contratá-los justamente para encontrar formas de desenvolver o que ainda não existe, de modo a resolver questões que ainda não têm solução. Sendo este um projeto caro, como garantir a qualidade da entrega e reduzir os riscos financeiros ao longo do processo de desenvolvimento?
Essa é uma das grandes dificuldades encontradas na definição de escopo, visto que as soluções costumam ser encontradas/construídas ao longo do projeto de software. Por isso, é habitual trabalhar com um escopo aberto, mas também é comum enfrentar problemas com prazos e gastos imprevistos neste tipo de projeto.
Para ajudá-lo a evitar esse tipo de risco financeiro em projetos de software, preparamos uma série de três artigos e vídeos sobre o tema. Nesta semana, começamos com este, sobre os riscos financeiros na definição de escopo. Depois falaremos dos riscos relacionados à qualidade do software e, posteriormente, traremos informações importantes a respeito do custo total de propriedade.
Planejamento e modelagem de software em detalhes é caro e incerto
Diante das incertezas da definição de escopo no início do projeto, as últimas duas gerações de desenvolvedores se dedicaram a criar métodos extremamente detalhados para planejar o processo de desenvolvimento de software. A exemplo desses, estão a Análise Estruturada e o Processo Unificado.
Ambos criados para viabilizar a construção de softwares de qualidade, baseados no escopo inicial, prevendo situações e evitando surpresas durante o desenvolvimento. A proposta é criar modelos que orientem o processo de desenvolvimento em todas as fases do projeto, considerando seus requisitos, as necessidades do usuário, as questões técnicas do projeto, os testes e a implantação.
São metodologias muito boas em termos de detalhamento e qualidade de esboço, mas incapazes de prever todas as variáveis do desenvolvimento. Então, quando algo sai do planejado ou dos problemas já previstos (o que quase sempre acontece em algum momento), todo o projeto é comprometido. Consequentemente, todo o trabalho inicial de levantamento de requisitos, planejamento e modelagem de software em detalhes, torna-se disfuncional!
Projetos grandes geram mais imprecisões na definição de escopo
Quanto maior o projeto, maiores os riscos de ter que refazer tudo se não houver aprovação ou se surgirem falhas nas etapas finais do processo. Mesmo que todos os detalhes e variáveis do projeto sejam milimetricamente calculados nas fases iniciais, a chance de ter gastos não previstos, posteriormente, é enorme!
Por este motivo, entendemos que o mais seguro é dividir qualquer grande projeto em diversos projetos pequenos individuais. Em vez de dividir o projeto em fases que envolvem o todo e apresentar as fases ao cliente, a ideia é trabalhar o todo em cada pequeno projeto de partes diferentes do software, de modo a entregar em prazos menores o sistema pronto. Não todo o sistema de uma vez, mas uma parte específica por vez, sendo entregue de forma real: já desenvolvido, testado e funcionando.
Basear a definição de escopo na “quebra” do projeto reduz riscos
Imagine o valor total de um grande projeto sendo também dividido em partes menores, a serem pagas a cada pequena entrega de software realmente funcionando! Se o projeto for estimado para ficar pronto em 5 meses e for dividido em 10 partes, por exemplo, depois de duas semanas você já recebe algo pronto, tendo desembolsado apenas um décimo do valor total.
Nesse momento, você provavelmente vai avaliar o que foi entregue e pode ser que queira fazer mudanças. Por ser uma parte pequena do projeto, será mais fácil e barato implementar essas mudanças e, dependendo do caso, sua equipe já saberá dessa sua preferência nos próximos pequenos projetos a desenvolver. O resultado será, a cada entrega, receber um software com mais qualidade e alinhado às suas expectativas.
Bem diferente dos casos em que o cliente passa meses acompanhando o projeto na teoria e, no final do prazo de desenvolvimento, quando recebe o software funcionando, verifica que não era bem isso que estava imaginando! O custo e o tempo necessários para tais ajustes são incomparáveis aos da situação anterior, de “quebra” do projeto em partes menores.
Portanto, na hora da contratação de uma equipe e da definição de escopo para o desenvolvimento do software da sua empresa, negocie considerando pequenas entregas reais! Ainda surgirão imprevistos, mas com certeza você economizará tempo e dinheiro, e ainda terá um software com muito mais qualidade, ao final do projeto!
Por Joana Kerr
5 de novembro de 2024
