Antes de dar início a qualquer projeto de TI é crucial definir qual o modelo será seguido para evitar desperdício de tempo e recursos. É o que se chama de escopo de projeto de software, que pode ser aberto ou fechado, cada um com os seus próprios requisitos e respectivas características.
Um bom escopo de projeto de software inclui detalhes como metas, custos, orçamento, membros da equipe, entre outros aspectos importantes. O principal objetivo do escopo é servir como base e referência central para todas as tarefas associadas ao projeto.
Seja qual for o produto a ser desenvolvido, o projeto sempre envolve três restrições principais conhecidas como Triângulo de Ferro: custo, tempo (prazo) e escopo.
- O custo se refere ao valor que será investido para a realização do projeto, como recursos financeiros, aquisições e até riscos.
- O tempo estabelece o prazo para entrega do produto.
- O escopo explica o que estará contido em toda a jornada do desenvolvimento: é a definição do limite entre o que será feito e o que não será.
Essas restrições estão presentes tanto em projetos de escopo fechado quanto nos de escopo aberto, mas são trabalhadas de forma diferente em cada um.
Basicamente, é preciso equilibrar os três fatores de restrição conhecidos – escopo, tempo e custo. 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 tempo ou custo serão alterados.
- E se o tempo do projeto mudar, o escopo ou custo serão alterados.
- Ou se o custo do projeto mudar, o escopo ou tempo serão alterados.
Qual dos modelos de escopo é o melhor?
Escolher qual modelo será adotado não é tão simples, pois depende de diversos fatores.
No desenvolvimento de software, é comum ouvir que os projetos tradicionais são de escopo fechado e os projetos ágeis são de escopo aberto.
Nem sempre é tão simples assim. É preciso entender que para definir custo, prazo e escopo são feitas estimativas, mas elas não são exatas.
Logo, não é possível fixar as três variáveis do Triângulo de Ferro. Tudo vai depender das necessidades do negócio. Daí por que definir a escolha do modelo aberto ou fechado é decisiva para o sucesso do projeto.
Antes de fazer a escolha, é necessário entender as principais diferenças entre esses dois modelos de contrato. Vamos lá?
Características e diferenças entre escopo aberto e fechado
Digamos que você saia de casa para um passeio de bicicleta ao longo de um trajeto de 10 km com o tempo estimado de 30 minutos.
Hipótese a) Se você só tiver 30 minutos disponíveis, precisará encaixar os 10 km nesse período. Isso pode resultar em uma variação entre 8 km (chegar mais rápido) ou até 11 km (risco de atrasar).
Hipótese b) Mas se você precisa apenas chegar a um local que fica a 10 km de sua casa, então você pode ajustar a distância e talvez chegar lá em 25 minutos ou 35 minutos.
Isso quer dizer que a flexibilidade das variáveis (fixa/ajustável) depende diretamente das necessidades do cenário.
É possível comparar a Hipótese a com o modelo de escopo fechado e a Hipótese b com o de escopo aberto? Também depende – nesse caso, do tipo de solução que o cliente está buscando.
Projetos de escopo fechado têm escopo fixo, mas o tempo e o custo podem variar. Nesse modelo, o cliente define exatamente qual será a entrega, quando ela vai ocorrer e quanto vai custar. Geralmente envolve um longo estágio de planejamento.
Projetos de escopo aberto têm o tempo e o custo fixos, mas o escopo é variável. Nesse modelo, os prazos e valores não são definidos previamente, assim, não há um caminho rígido: é possível adaptar os processos ao longo da jornada, descobrindo e ajustando as entregas a cada etapa.
No escopo aberto, o cliente só vai pagar pelas horas de trabalho utilizadas no desenvolvimento do projeto. Além disso, ele pode mudar de ideia, adicionar funcionalidades, solicitar testes e ajustar o processo conforme desejar.
Quais os problemas mais comuns do escopo fechado?
• Risco de sair do escopo
O alto nível de detalhamento pode criar uma expectativa de segurança, previsibilidade e controle. Mas essa segurança só é real em situações em que o escopo definido é estável e todas as partes cumprem de forma integral o que foi previamente combinado. Se houver alterações durante o processo, das duas uma: ou se refaz todo o escopo, alterando custo e prazo, ou a entrega não será completa.
• Desconexão com o cliente
A participação do cliente se concentra apenas no início e no final do projeto, sem a necessidade de acompanhamento frequente: afinal, tudo o que será desenvolvido já está definido. Não há necessidade de interação e feedback. O cliente pode acreditar que tudo ficou claro, mas a interpretação da equipe contratada pode ser diferente. O resultado final será a decepção de ambos.
• Adeus, inovação
O escopo fechado é engessado para acolher projetos inovadores. Afinal, ao tentar definir antecipadamente todos os detalhes, o que há de inovador nisso?
• Falsas estimativas
Estimar significa analisar a probabilidade com base nas informações disponíveis. No escopo fechado, isso ocorre apenas na fase de planejamento: o tempo e o custo são calculados em função do esforço de implementação. Como neste modelo estas variáveis são flutuantes, qualquer oscilação ou ajuste significa atraso na entrega.
Para contornar as variáveis, as estimativas de tempo acabam propositalmente aumentadas pela equipe. Mais tempo resulta em um custo maior. É a chamada “superestimativa do buffer”.
• 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. Isso quer dizer que o sucesso é medido pela lista de entregas, e não pelo impacto positivo causado pelo produto.
• Design e usabilidade do software prejudicados
No escopo fechado, como o preço e prazo da prototipação já foram definidos, pode ou não contemplar personalizações identificadas em tempo de projeto e desejadas pelo cliente que tornariam o sistema web ou aplicativo melhores.
Esta rigidez pode comprometer a qualidade porque, para atender à lista de requisitos, às expectativas criadas e às estimativas de orçamento e prazo, é comum cortar etapas de verificação. Ou seja, a entrega é realizada a tempo, dentro do custo, mas sem os devidos testes.
Quais são as vantagens do escopo aberto?
Em vez de apenas uma etapa de planejamento, nos projetos de escopo aberto existem ciclos de trabalho que passam por fiscalização e adaptação. As entregas são feitas a cada Sprint (duas semanas) ou a cada item concluído (o que pode gerar uma cadência diária, por exemplo). Dessa forma é possível reajustar o escopo com frequência, dentro do prazo e custo fixados.
No escopo aberto, o cliente acompanha o trabalho de perto, tornando-se, por assim dizer, um membro da equipe. É uma realidade mais ágil e menos burocrática: a cada nova sprint, a equipe agrega novos conhecimentos que são avaliados por todos e aplicados durante o desenvolvimento.
O principal objetivo desta agilidade é eliminar o desperdício e focar nas entregas baseadas em valor. Dado que o planejamento é realizado constantemente durante o projeto, ele é adaptável, moldado ao cenário atual do projeto. Isso significa que se o negócio do cliente sofrer alguma alteração é possível incluir, excluir ou modificar itens em função desta nova realidade.
Essa análise é a base para a priorização dos itens. Ao priorizar o que oferece mais valor, toda a lógica de trabalho muda, e a famosa “Síndrome do Aluno Atrasado” (que sempre entrega no último momento) é naturalmente combatida neste processo.
A previsibilidade se torna mais real do que em projetos de escopo fechado. Após algumas sprints, a equipe pode ter mais certeza sobre o andamento e a qualidade da entrega; assim, torna-se possível realizar projeções com base em dados confiáveis. No final da jornada, há mais garantia de que o produto atenda completamente os requisitos do negócio/cliente.
Criatividade e inovação vs. exatidão e controle?
Esse é um dilema muito parecido com a escolha entre desenvolvimento de software com Método Ágil ou com o Método em Cascata (Waterfall).
O modelo de contratação em escopo fechado é comumente associado quando o cliente já possui clareza sobre o seu problema e sabe a solução mais adequada para resolvê-lo. Isso pode ser um problema, já que não há espaço pra inovar e ajustar o projeto se for preciso. E embora elimine riscos de estourar o orçamento ou o cronograma, a entrega pode não ser a esperada pelo cliente.
O modelo de escopo aberto é ideal para projetos que busquem uma solução perfeita, criativa e inovadora, mesmo que o cliente não saiba exatamente como alcançá-la. Nesse caso, a empresa contratada vai adaptar os serviços, fazer mudanças ao longo da jornada do produto até chegar no ponto da máxima qualidade exigida pelo cliente.
Escopo aberto ou escopo fechado?
Essa decisão vai depender dos objetivos do projeto e do próprio perfil de negócios do cliente.
Por isso, uma das primeiras etapas da construção de um software é a descoberta desses objetivos e perfis. Conforme o time de desenvolvimento se aprofunda no projeto e amadurece o objetivo, as previsões se tornam mais assertivas e o próprio projeto evolui.
Na UDS, esse processo é chamado de Discovery.
Como acertamos nas entregas: a importância do Discovery e do Design Sprint
Quando nos envolvemos pela primeira vez com um novo cliente, o foco principal é construir a confiança entre nossa equipe e a dele. O processo de Discovery é uma etapa em que conhecemos a equipe do cliente, o seu negócio e as necessidades urgentes que o fizeram buscar esta parceria.
As atividades de Discovery são sessões de descoberta projetadas para desvendar os desafios do negócio, trazer o feedback ao cliente e garantir que todos os envolvidos estejam alinhados. Esse processo identifica como gerar mais valor em determinado contexto ou jornada e entender que tipo de equipe será necessária para desenvolver o projeto.
Depois de identificar desafios e oportunidades, é o momento de definir planos para aproveitá-las.
É aí que entra o Design Sprint, um processo que visa acelerar projetos que ainda estão na fase de ideias e construir a base para que o desenvolvimento do produto se inicie o mais rápido possível.
Em outras palavras, o Design Sprint agiliza a tomada de decisões sobre o produto e elimina hipóteses que não foram baseadas na real necessidade do consumidor, propondo soluções alinhadas aos objetivos do negócio.
Mas nem sempre a empresa precisa identificar aspectos de descoberta ou aplicar a etapa da Design Sprint para saber qual o melhor escopo para seu projeto: o desenvolvimento do produto segue direto para a sua construção – incluindo os riscos inerentes a esta decisão, que variam conforme a maturidade do negócio.
É inegável, porém, que processos ágeis como esses promovem a consistência entre escopo, desenvolvimento e produto e aumentam a vantagem competitiva, já que a empresa alcança resultados mais rápidos em seu mercado de atuação, gerando real valor para o negócio.Precisando desenvolver uma solução de software adequada às necessidades do seu negócio? Entre em contato com os especialistas da UDS.
