Ao escolher projetos de escopo fechado, é importante entender os diversos riscos envolvidos, já que eles impactam no orçamento, nos prazos e também no produto que será entregue ao cliente. Este artigo examina os 10 maiores riscos de desenvolver um software com escopo fechado, por que eles ocorrem e como você pode evitá-los.
O projeto de escopo fechado tem um orçamento e lista de funções fixos, acordados no início do projeto. As principais vantagens de projetos de escopo fechado são as sensações de segurança e controle, pois a fábrica de software deve desenvolver o sistema pelo valor já combinado.
Por isso, muitas vezes, o que parece uma solução no início do desenvolvimento do software pode se tornar inviável ao longo do projeto. Explicaremos quais os riscos que devem ser contornados para evitar prejuízos financeiros e de tempo e, no final, o custo ou produto ficarem longe do que o cliente espera.
Risco é a incerteza sobre algo ser diferente do esperado e gerar consequências negativas. É calculado pela sua probabilidade de acontecer e pelo prejuízo que pode causar.
O que pode dar errado em projetos de software com escopo fechado?
24% dos projetos de desenvolvimento de software não são concluídos; 52% deles custam mais de 180% a mais que de suas estimativas originais. (CHAOS Report/Standish Group)
No início de um projeto de desenvolvimento de software com escopo fechado, o cliente informa as funções que deseja. Baseado nisso, são geradas noções de custo e prazo para firmar um contrato com o investimento total e data de entrega do projeto.
No entanto, ainda na fase de fechamento do contrato, é praticamente impossível prever tudo que a fábrica de software deve entregar. Mesmo que o fornecedor saiba o que o cliente quer, os detalhes sobre como deve ser desenvolvido não foram escritos e prototipados, ou seja, o comportamento exato de cada função do software web ou aplicativo ainda não existe.
Esse detalhamento requer o trabalho de Analistas de Sistemas e UI/UX Designers para realizar a Engenharia de Requisitos do Projeto. Tais profissionais criam descrições técnicas detalhadas (os requisitos) e design de interfaces (protótipos) para cada funcionalidade.
Há um grande perigo no projeto quando o investimento e prazo são fixados antes que esses detalhes estejam definidos.
Como garantir o total exato a ser investido sem ter documentos de requisitos e protótipos? Seria como definir o preço para construir uma casa sem ver a planta detalhada antes.
Quais os 10 principais riscos de desenvolver um software com escopo fechado?
A rigidez do contrato de escopo fechado ou desenvolvimento de software com escopo fechado tem consequências em várias fases do projeto, podendo causar:
1. Entendimento falho:
Como os detalhes técnicos do projeto (descrições detalhadas de funcionalidades, integrações, arquitetura do software, etc.) ainda não existem, o entendimento da equipe sobre como cada função do software deve se comportar certamente terá falhas e divergências frente ao que o cliente deseja.
2. Design e Usabilidade do software prejudicados:
Em complemento ao item anterior, o design de telas e da experiência do usuário podem ser falhos. Como o preço e prazo da prototipação já foram definidos, ela pode ou não contemplar personalizações identificadas em tempo de projeto e desejadas pelo cliente que tornariam o sistema web ou aplicativo melhores.
3. Estimativas erradas:
A falta de detalhamento exato das funcionalidades faz com que o time responsável por desenvolvê-las gere estimativas de esforço e prazo erradas frente ao que o cliente ou usuário final realmente querem.
4. Dificulta melhorias ou inovações no software:
No detalhamento técnico e prototipação do projeto, profissionais encontram diversas formas de torná-lo mais eficiente, de fácil uso ou barato.
Por isso, em projetos de escopo fechado, é difícil aproveitar essas vantagens pela necessidade de renegociar o investimento e prazo de entrega. Isso dificulta que o software seja o melhor que poderia ser.
5. Aumento do escopo e novas negociações:
Qualquer item diferente do descrito no contrato inicial que for identificado no detalhamento das funções, design de telas, desenvolvimento (programação) e teste do sistema ou aplicativo será incrementado no escopo do projeto.
O impacto são novas negociações, mais custos e alterações de prazo. Isso é muito provável de acontecer, pois seria raro que cada caraterística do projeto fosse pensada previamente, sem alterações posteriores.
6. O aumento do retrabalho:
Pode ser alto devido às alterações no projeto. Ou seja, o tempo será consumido em tarefas que talvez não precisassem ser refeitas, caso outro modelo de trabalho para desenvolver software fosse adotado, como a metodologia ágil seguindo os princípios do Manifesto Ágil.
7. Comprometimento da qualidade:
O custo do fornecedor para cumprir com alterações em um projeto de custo e prazo fixos pode comprometer a qualidade dos processos e profissionais envolvidos na produção.
8. Prazos estourados:
Qualquer divergência nas necessidades do cliente ou atividades do projeto (altamente provável) exigirá que os prazos sejam renegociados.
9. Linha de produção “fordista”:
O cliente paga por atividades que não agregam valor ao negócio, já que todas elas foram inicialmente planejadas e “devem” ser entregues, mesmo que não façam mais sentido ao longo do processo de desenvolvimento. Em resumo, quer dizer que o sucesso é medido pela lista de entregas, e não pelo impacto positivo causado pelo produto.
10. Expectativas frustradas:
Qualquer um dos riscos acima frustra a expectativa do cliente, até porque normalmente acontecem de forma conjunta.
Resultado: a qualidade do projeto de desenvolvimento de software é prejudicada e há desperdício de tempo e dinheiro.
Leia também: - Como definir o escopo de projeto de software - Gestão de riscos em projetos de Desenvolvimento de Software - Escopo aberto ou fechado: O que são e qual deles escolher?
Como evitar os riscos de projetos de software com escopo fechado?
Basicamente, é preciso equilibrar três fatores de restrição conhecidos como o Triângulo do Projeto – escopo, prazo e custo. Portanto, se um dos fatores for alterado, ao menos um dos demais também precisa ser adaptado.
Resumidamente, é natural que:
- Se o escopo do projeto mudar, o prazo ou custo serão alterados.
- E se o prazo do projeto mudar, o escopo ou custo serão alterados.
- Também, se o custo do projeto mudar, o escopo ou prazo serão alterados.
Boas práticas para contratar desenvolvimento de software com escopo fechado:
Você deve ficar atento aos seguintes aspectos:
1. Entenda como a precificação foi feita
Como contratante, é fundamental que você saiba como o fornecedor fez a composição de preço para desenvolver o projeto. E caso não haja detalhes claros e plausíveis sobre como, por exemplo, o valor de investimento foi definido, é muito provável que a proposta não seja realmente confiável, baseada em um “chute”, gerando frustrações no projeto.
2. Combine quem deve pagar por bugs no software
Todos desejamos receber um produto sem defeitos. Mesmo assim, bugs e problemas acontecem no software e até por isso a figura do Quality Analyst (QA) é fundamental.
Nesse contexto, tenha clareza sobre:
- Qual é o prazo de garantia do fornecedor para corrigir problemas no software?
- Quem deve pagar pelo trabalho de corrigir bugs?
- Quem deve pagar eventuais custos gerados por problemas e falhas do(s) sistema(s)?
3. Verifique o prazo de alocação da equipe
Após combinar o escopo fechado do projeto e aprovar a proposta comercial, certifique-se de que conhece o prazo que o fornecedor terá para alocar a equipe necessária e iniciar os trabalhos. Não necessariamente a empresa fornecedora já tem uma equipe aguardando para iniciar, por isso, saiba qual é esse prazo e ajuste seu cronograma
4. Defina ações para prazos ou estimativas estourados
O cumprimento de prazos e do investimento são itens básicos de um projeto de escopo fechado. Mesmo assim, é importante definir o que acontece (termos, eventuais multas, acordos) caso isso não seja devidamente cumprido.
5. Conheça o processo para alterações de escopo do projeto
Muitas empresas que atuam com desenvolvimento de software com escopo fechado têm processos para gerenciar alterações no escopo do projeto. Normalmente esse processo envolve: analisar e descrever a mudança, estimar o impacto em tempo de desenvolvimento e gerar um aditivo de proposta comercial para o cliente.
Mas mesmo que esse pareça ser o processo natural, antes de escolher o seu fornecedor nós indicamos que você converse e confirme essas etapas.
6. Veja o que fazer em caso de más interpretações
Todos nós já ouvimos a frase: “O combinado não sai caro”.
Mesmo assim, as partes podem ter entendido o que foi combinado de maneiras diferentes. Como vimos acima no artigo, entre os riscos de desenvolver um software com escopo fechado está a falta do detalhamento exato das funcionalidades, o que pode gerar divergências de entendimento. Ou seja, antes de contratar um fornecedor, questione quais serão as atitudes tomadas caso isso aconteça e, mais importante do que isso: quem arca com os impactos que essas divergências causam no projeto.
7. Saiba o que acontece se profissionais saírem do projeto
Ao contratar uma empresa de prestação de serviços para desenvolver o seu projeto, é natural que um time seja montado. E se tratando de pessoas, podem haver mudanças em suas vidas pessoais e/ou profissionais que façam integrantes do time saírem do projeto.
Como contratante, você precisa conhecer os processos e garantias que o seu fornecedor tem para evitar que esse risco afete o projeto, ou que o impacto seja mínimo.
Para diminuir os riscos e as lacunas que causam problemas em projetos de escopo fechado, também recomendamos que você faça, acima de tudo, um Plano de Gerenciamento de Riscos – um documento que estabelece as estratégias, funções, responsabilidades e questões de orçamento.
Como diz o provérbio, “é melhor prevenir do que remediar”.
É por isso que é preciso encontrar o maior número possível de riscos potenciais em relação ao projeto, desde o orçamento a determinadas funcionalidades do software.
- Analise a viabilidade o mais objetivamente possível, visando garantir que um projeto seja operacional, legal, financeira e tecnicamente viável.
- Confirme o plano de execução do projeto e do escopo com as partes interessadas antes do início do projeto. As funções e responsabilidades devem ser claramente definidas no termo de abertura do projeto, de preferência com uma Matriz RACI(Responsible Accountable Consulted and Informed).
Para conferir mais informações sobre escopo de projeto e como gerenciar riscos com matriz RACI basta clicar aqui.
É possível desenvolver um projeto de escopo fechado com Metodologias Ágeis?
A resposta é sim, desde que com alguns cuidados.
“Não há como aplicar na totalidade, mas é possível usar práticas ágeis em cerimônias com a equipe, organização do backlog e entregas parciais do projeto ao cliente. O segredo está em priorizar o escopo, alinhar as expectativas e remover o que ficou fora do orçamento”, explica Arthur Teixeira, COO da UDS.
A parceria com uma empresa confiável pode ajudá-lo a evitar os riscos de desenvolver um software com escopo fechado, com isso, oferecendo segurança e agilidade em projetos Web e aplicativos mobile.
Você sabia? A UDS é especialista em soluções de desenvolvimento de software em ciclos curtos de entrega.
