A definição entre escopo aberto ou fechado está diretamente relacionada ao sucesso de um projeto de software
Dentro de um projeto de software, o escopo é tudo o que a fábrica de software, equipe outsourcing ou equipe interna se comprometem a entregar de valor dentro dos limites de um prazo e de um custo. Tudo normal e bem claro. Nem tanto. Porque, na hora de fechar o contrato do projeto, a pergunta é: escopo aberto ou fechado?
Essa decisão é fundamental porque o escopo tem a ver com o grau de liberdade que o cliente tem para modificar requisitos ao longo da execução do projeto. Parece uma decisão simples de tomar, mas não é, mesmo quando o cliente já tem uma ideia clara do que precisa e, às vezes, até um MVP concebido subsidiando o planejamento da entrega.
Quanto de gordura colocar em um prazo e em um orçamento? Quanto um projeto deve ter de flexibilidade a mudanças? E se os entregáveis mudarem, qual o impacto disso?
Não é incomum que, ao longo do processo, o que estava claro torne-se obscuro, o que parecia um prazo adequado vire o dobro do tempo, um orçamento definido seja um gasto fora de controle e, ao final, uma grande entrega seja uma entrega medíocre ou, no pior dos casos, obsoleta desde o lançamento.
Leia mais: Software de prateleira ou personalizado: como saber qual é o ideal?
Então, neste post, junto com a definição das características de escopo aberto e fechado vamos entender como decidir sobre um deles.
Obtendo o escopo de um projeto de software
Ninguém sai por aí escrevendo código, mesmo em low-code. Todo projeto tem um escopo definido, seja aberto ou fechado, que contém entregas, prazos, previsão de time, budget etc., seja ele desenvolvido por uma fábrica de software ou pelo time interno da organização.
Saiba mais: Qual o método da Supero para recrutar profissionais de TI em questão de dias
O escopo pode partir tanto de uma inception total do projeto quanto de uma sequência de MVPs – mínimo produto viável, aqueles 20% do produto que geram 80% do seu valor.
Há algumas metodologias para defini-los. Aqui na Supero, usamos e praticamos com nossos clientes a Lean Inception para a obtenção de MVPs, mas é possível trabalhar com a Design Sprint, a Inception etc., nos seus diferentes níveis de abrangência.
Trabalhar com um escopo, em suma, é essencial tanto para projetos longos, em que não se tem absoluta certeza sobre seu desenvolvimento e tecnologias desde o começo - como produtos inovadores -, quanto para projetos curtos, em que há certeza sobre o que precisa ser desenvolvido.
Então, o que varia no escopo aberto em relação ao escopo fechado? A possibilidade de modificação ao longo da execução.
Projeto de escopo fechado
O projeto de software de escopo fechado é elaborado com alto nível de detalhe, geralmente englobando todas as estapas de desenvolvimento, para completa previsibilidade e controle sobre o que será entregue, em termos de prazos, custos e profissionais.
Para isso, antes da execução, o projeto de escopo fechado envolve uma longa etapa de planejamento, que o desdobra em um plano de entregas, cuja finalidade é reduzir os riscos do contratante e controlar o orçamento e o cronograma.
Como, por suas características, ele é menos passível de modificação pelo cliente, é ideal para projetos maduros e pequenos, ou seja, que sabidamente não vão ter tanta margem para modificação nem erro.
A vantagem é que esse tipo de escopo de projeto de software oferece segurança sem que o cliente precise se envolver tanto com o trabalho. Tudo está definido antecipadamente e a entrega será de acordo com o contratado – pelo menos, assim esperamos.
Na prática, a fábrica de software fará um orçamento baseado nas entregas, prazos e equipe necessários, pelo qual o cliente pagará integralmente.
Desvatagens do escopo fechado
As desvantagens do escopo fechado têm a ver com a extensão do planejamento e o longo período de incubação do projeto.
O primeiro pode levar a estimativas erradas, que geram prejuízos tanto para a fábrica de software quanto para o cliente. Não é raro que projetos estimados em 1.000 horas acabem com 3.000 horas, o que acaba afetando todos os envolvidos.
Já o longo perído de incubação pode levar, apesar da previsibilidade de todo o projeto, a um software funcional, mas que não atende as expectativas do cliente ou que os usuários não amam. Tendências e inovações tecnológicas, assim como o comportamento dos usuários, mudam rapidamente, modificando também as necessidades de uma aplicação.
Considerar o trabalho com MVP, com ciclos curtos de incremento e iteração com validação com stakeholders e usuários, é fundamental para evitar problemas como esse.
Leia mais sobre desenvolvimento iterativo e incremental no nosso Guia Scrum.
Projeto de escopo aberto
O escopo aberto pretende resolver alguns problemas do escopo fechado. No projeto aberto, o desenvolvimento do escopo passa por ciclos curtos de inspeção e adaptação, que envolvem diretamente o cliente e até usuários, para o acompanhamento do trabalho, obtenção de feedback e de aprendizado validado para um tomada de decisão contextualizada sobre os próximos passos do projeto.
Esse tipo de projeto parte da premissa de que nem tudo é previsto no planejamento inicial do escopo e, portanto, precisamos mantê-lo aberto, para criar espaços para modificá-lo – se necessário para a qualidade do projeto, mesmo que às expensas do prazo e dos custos.
Por isso, o escopo aberto trabalha com um horizonte de tempo e de custos, priorização e formação de times mais flexíveis ou sob demanda. Na prática, isso significa que, mesmo havendo uma estimativa de escopo, orçamento e prazo a se ater, o cliente paga pelo que receber de fato.
O escopo aberto é ideal para projetos grandes ou contínuos e inovadores, sobre o qual há mais incerteza e, consequentemente, grandes possibilidades de mudanças e de erros de planejamento, além de muito espaço para novos insights.
Desvantagens do escopo aberto
A principal desvantagem do escopo aberto tem a ver com a própria vantagem da flexibilidade, que pode gerar caos na tomada de decisão.
Fábricas de software que não definem com o cliente regras claras para mudanças nos requisitos, como análise de viabilidade técnica e de impactos tanto em esforço quanto custos e negócios, podem ter problemas com prazos e entregas, bem como preço, que pode ficar alto demais.
O melhor dos dois mundos
Se abordagens unilaterais tanto em escopo fechado quanto em escopo aberto têm desvantagens, a possibilidade é achar uma terceira via, em que se busca o melhor dos dois mundos.
Na prática, isso significa definir o escopo e adotar boas práticas de agilidade típicas de projetos de escopo aberto, como as seguintes:
- Fazer Lean Inception para obter estimativa de MVP, custos, equipe e esforços, e sobretudo desenhar um projeto que pode ser modificado de maneira simples.
- Fazer product backlog: desdobrar o MVP em um backlog, considerando histórias dos usuários.
- Adotar a gestão visual e sistema puxado.
- Diminuir os ciclos de desenvolvimento.
- Entrega de software funcional ao fim de cada iteração.
- Comunicação constante: validar funcionalidades prontas com stakeholders e usuários para mudar na hora certa.
- Mexer no escopo, não no prazo: não gerar impedimentos para alterações no escopo.
Escopo aberto vs. Escopo fechado: o projeto certo para a finalidade certa
Vimos que o escopo aberto funciona bem com projetos inovadores, com maior grau de incerteza sobre funcionalidades-chave, grandes ou contínuos. Já o escopo fechado é a melhor decisão para projetos menores, sem margem de erro e de muitas mudanças.
Analisar o projeto que a organização tem em mãos, enxugá-lo ao máximo com metodologias como MVP e Lean Inception, e mantê-lo suficientemente fechado para ser um guia e suficientemente aberto para ser ajustado de acordo com necessidades é o melhor dos dois mundos.
Se, na teoria, isso é simples, na prática a decisão ainda pode ser complicada, sobretudo com questões contratuais.
Por isso, não deixe de conversar com quem soma 17 anos de experiência na concepção e execução de projetos de software para os mais variados segmentos do mercado.
Conheça também: Como funciona o outsourcing de TI da Supero?
Fale com um de nossos consultores, sem compromisso.
