Lidar com o desfasamento do âmbito e o Gold Plating em projectos de software

No caso dos projectos de TI, o Scope Creep (proveniente do site do proprietário) e o Gold Plating (proveniente do PM, Scrum Master ou dos programadores) são as ameaças mais comuns. Alterações não controladas no projetoA adição de novas funcionalidades ou a introdução de alterações fazem, sem dúvida, parte das ameaças que afectam a eficiência e a rapidez dos projectos. No passado, tivemos a oportunidade de cooperar com startups e grandes empresas como a Livenation / Ticketmaster, Stroer ou Agora (o maior grupo de media da Europa). Durante este tempo, coordenei muitos projectos de TI - especialmente os relacionados com desenvolvimento de software. Esta experiência permitiu-me compreender que não importa se trabalha numa pequena ou grande empresa: se quer ter sucesso, tem de estar um passo à frente da sua concorrência.

Gostaria de partilhar as minhas ideias sobre o desenvolvimento eficaz de projectos de desenvolvimento de software. Como CCO na Codest, implementamos projectos todos os dias para empresas globais em todo o mundo. A abordagem correta da gestão é a primeira etapa fundamental que influencia posteriormente o êxito do projeto. Distingo quatro princípios básicos, mantendo os quais permitiram nós para desenvolver um modelo de gestão verdadeiramente eficaz. Graças a eles, evitamos problemas posteriores - incluindo os relacionados com o "scope" da plantação de ouro. Aqui estão eles:

1. Metodologista. Independentemente da dimensão do projeto ou do seu grau de avanço, implementamos sempre uma metodologia adequada que nos permita gerir o projeto de forma coerente com as Ágil abordagem. Neste caso, o metodologista Scrum ajuda-nos. E, graças a isso, temos todas as fases do projeto sob controlo. Cada membro concentra-se em tarefas estritamente definidas. Desta forma, evitamos distracções desnecessárias e mantemos a máxima eficiência do trabalho.

2. MVP. Este pode ser considerado o nosso princípio fundamental. Se quiser criar uma aplicação, faça-o, mas numa gama muito básica. Poupará tempo e evitará o risco de esgotamento do orçamento. A visão inicial do produto é frequentemente verificada e alterada mais tarde. Ao longo do tempo, o cliente pode mudar de ideias relativamente às caraterísticas necessárias de uma aplicação, o que, por sua vez, gera custos desnecessários e prolonga o trabalho.

A abordagem MVP funciona bastante bem. Criamos uma aplicação que tem, por exemplo, 20% de todas as funcionalidades, mas já é capaz de verificar o seu valor no mercado. Desta forma, o cliente recebe o feedback dos utilizadores e sabe quais as caraterísticas que o seu produto deve ter para ser eficaz. De seguida, concentramo-nos no desenvolvimento destes elementos. Um ótimo reflexo deste processo é o gráfico que se segue:

3. Testes. O teste de funcionalidades individuais da aplicação está diretamente relacionado com o MVP. Caso se verifique que algo não funciona como deveria, é melhor rejeitá-lo e procurar uma solução alternativa. Na Codest, conhecemos clientes que, desde o início, impuseram a forma final de uma aplicação e tinham a certeza de que esta era a única visão correta. Não gostaria de me alongar sobre os efeitos posteriores desta abordagem. É por isso que considero necessário sublinhar mais uma vez que a simplicidade é a chave do sucesso.

4. Desenvolvimento. A construção da aplicação deve começar com UX, Design, Backend e Frontend. Em suma, tudo começa com as tarefas simples "obrigatórias" que compõem o produto MVP. Depois de atingida esta fase de desenvolvimento, pode concentrar-se no desenvolvimento da funcionalidade chamada "nice to have".

Resumo

Na minha opinião, estes são quatro princípios básicos que são excelentes para gerir projectos de desenvolvimento de software. Esta abordagem reduz os riscos de distracções desnecessárias, horários de trabalho mais longos e ineficiências em termos de custos.

Para terminar, deixem-me dar-vos mais um exemplo. Há algum tempo, recebemos a especificação de um projeto de um cliente. Juntámo-nos imediatamente ao equipa para o avaliar. O cliente esperava que criássemos o produto num prazo de doze meses. De acordo com a nossa abordagem, propusemos uma abordagem MVP e um período de desenvolvimento de três meses. No final, conseguimos convencer o cliente. Após alguns meses, ficaram impressionados com a solução. O cliente recebeu o seu produto funcional num prazo relativamente curto. No caso de várias funcionalidades, decidiram alterar o projeto assumido logo no início.

O modelo que descrevi neste artigo é a nossa forma de implementar com sucesso projectos de desenvolvimento de software. Acredite, esta solução não só melhora o trabalho e torna-o eficaz, como também, consequentemente, ajuda a evitar o âmbito do creep e do gold plating.