Todo profissional que trabalha com desenvolvimento de software já passou por algumas experiências frustrantes: Atrasar a entrega de um projeto; entregar o projeto com baixa qualidade; precisar investir o dobro do tempo da entrega com correções. Geralmente, estes problemas vêm todos juntos. Sabe como resolver isso? Escopo aberto!
O que é escopo?
Antes de entendermos o que é escopo aberto, precisamos dar um passo atrás e entender o que é escopo.
Literalmente falando, escopo é o ponto em que se mira, que queremos atingir.
Trazendo para o mundo de desenvolvimento de software, escopo é a definição detalhada do que deve ser feito.
Quando temos toda essa definição descrita detalhadamente antes do projeto iniciar, nós temos um projeto de escopo fechado.
Geralmente o cliente te procura com uma lista de funcionalidades, cada uma delas muito bem detalhada e fala:
Preciso que vocês desenvolvam um software que faça tudo isso. Quanto tempo demora?
A equipe se junta, analisa de forma minuciosa o que foi solicitado e então volta ao cliente com uma série de dúvidas. O cliente vai analisar as dúvidas, responder algumas, pressupor outras, e então o projeto vai tomando corpo.
Após diversas idas e vindas, o prazo é definido pelo desenvolvedor, já com uma gordura de pelo menos 50% para garantir imprevistos. O gestor então pega este prazo e multiplica por 2, pois já teve problemas com atrasos antes e quer se previnir desta vez. Chegamos ao prazo ideal!
O projeto se inicia. Alcançamos metade do prazo e somente 25% do projeto desenvolvido. Por quê? Imprevistos. Muitos deles ocorrem. Algo foi planejado de forma errada, a dificuldade técnica foi maior do que a prevista, o cliente demorou pra sanar dúvidas que já não haviam sido sanadas antes do projeto começar.
Qual o resultado disso? Mais um projeto de escopo fechado, sem escopo aberto. Mais um projeto atrasado!
Se toda vez o projeto atrasa, por que continuamos trabalhando desta forma?
Nós não sabemos prever nada!
O ser humano tem muita dificuldade em fazer estimativas. Nassim Taleb explica isso de forma extraordinária em seu livro “A lógica do Cisne Negro”. Basicamente ele mostra, estatisticamente, que a cada erro ao tentar prever um prazo, a nova previsão acaba sendo maior que o prazo anterior.
Exemplo hipotético: A previsão inicial para entregar uma linha de metrô é de 1 ano. Ao término do prazo e ao constatar o atraso, o novo prazo é de mais 1 ano e meio. Ao término deste novo período, é constatado novo atraso, e então passamos a ter um novo prazo com mais 2 anos. E assim seguimos…
Voltando ao desenvolvimento de software, esta é uma premissa para os dois lados. Quase sempre o cliente não sabe exatamente o que quer. Isso implica em uma série de suposições ao definir o escopo.
Do lado técnico, fazemos várias outras suposições sem nenhum tipo de experimentação. Desenvolvimento de software é algo que se assemelha muito quando olhamos para o todo, mas é completamente singular ao olharmos nos detalhes. Muitas definições prévias se mostram equivocadas quando colocadas em prática, e o nosso planejamento inicial quase sempre não prevê isso.
Como trabalhar com escopo aberto
Apesar de sermos péssimos previsores de futuro, nós somos ótimos em sempre continuar tentando prever. Está intrínseco na nossa natureza. Por mais que tentemos não prever, quando percebemos já estamos prevendo.
Por isso temos sempre que estarmos atentos ao nosso modus operandi e tentar seguir algumas premissas básicas para não cometermos o mesmo erro duas vezes.
Seja sempre transparente com seu cliente
Como expliquei no começo do texto, quando trabalhamos com escopo fechado sempre colocamos gordura. O cliente mais experiente já sabe disso, então sempre aperta o prazo inicial. É aquele famoso jogo de “você finge que me engana e eu finjo que acredito”.
Tudo isso acontece porque as partes envolvidas não querem assumir os riscos implícitos. Um lado tenta sempre jogar pro outro e com isso ninguém ganha.
Ao adotarmos uma postura de transparência, a responsabilidade é dividida, consequentemente os riscos também. É preciso haver compreensão de ambas as partes de que desenvolvimento de software não é um processo exato. O cenário sempre muda. Não existem garantias em um jogo em que as regras sempre mudam no meio do caminho.
A única forma de conseguir atingir objetivos sem que nenhum dos lados percam é focando em resolver o problema das pessoas interessadas.
Priorize baseando-se na geração de valor
Quando falamos de qualquer trabalho, de uma forma geral, nos baseamos em quatro variáveis, que são escopo, custo, prazo e qualidade. Todas elas estão intimamente ligadas e qualquer alteração em uma delas temos influência direta em todo o grupo.
Aqui na Codevance nós NÃO negociamos qualidade. A alta qualidade é uma premissa de todos os projetos. Com isso, temos somente três variáveis que podemos manejar. Caso mantenhamos o escopo e o prazo fixo, o custo aumenta. Caso mantenhamos o custo e o escopo fixos, o prazo aumenta. Prazo e custo geralmente são variáveis em que o cliente não quer mexer. Só nos resta reduzir o escopo.
Para reduzirmos o escopo temos que olhar todas as funcionalidades solicitadas e começar a eliminar o que é menos importante. A partir do momento em que tudo é importante, nada é importante, ou seja: Sempre temos o que eliminar!
Para fazer isso, devemos sempre olhar para as funcionalidades categorizando-as em dois grupos:
- Qual o valor gerado ao nosso cliente?
- Qual a dificuldade de implementação?
Nosso objetivo é sempre priorizar o que gera mais valor ao nosso cliente e o que gera menos dificuldade para implementarmos.
Não planeje, resolva problemas
Para tentar trazer ao mundo real os conceitos e a mentalidade citados acima, vamos imaginar o problema do João.
Ele é dono de uma loja de calçados. Ele vem até você e diz que precisa de um sistema de gestão para sua loja.
Sua loja vende muito bem. Entretanto, quando ele vai fazer o balanço, demora muitas horas para fazer a conciliação entre vendas, estoque, fluxo de caixa, folha de pagamento e etc. Isso gera diferenças de caixa, atrasos para fazer novas compras, atrasos para pagar seus funcionários. Tudo por causa da desorganização.
Diante disso, ao invés de começar a planejar um software com vários módulos, você vai perguntar pra ele “João, onde você perde mais tempo?“. Ele responde que demora muito para conciliar as diferentes vendas feitas no dinheiro, no cartão de crédito, no cartão de débito e no cheque.
Com a resposta dele, você então vai tentar entender como funciona o processo de venda dele. Resumidamente, ele faz tem um talão de pedidos em que a cada nova venda uma folha deste talão é preenchida. O maior trabalho está em somar todas estas folhas no fim do mês.
Então, você começa a atacar somente este problema da forma mais simples possível: Faz um simples cadastro que recebe a data da venda, o número de controle da folha de pedido, o valor total e a forma de pagamento. Agora, a cada venda feita o atendente cadastra estes dados no sistema, depois de preencher a folha de pedido.
No fim do próximo mês, ao invés do João gastar 4 horas somando todos os talões, ele simplesmente aperta um botão e aparece a soma de todas as vendas, separadas por tipo de pagamento.
Você resolveu um problema! Você não definiu escopo. Simplesmente mapeou um problema e buscou uma solução. Isso é escopo aberto!
Claro que o exemplo acima é simplista. Mas a idéia é transmitir a mentalidade por trás dessa abordagem.
Update:
Ótima palestra referente o assunto:
**
E ai? Na sua empresa vocês desenvolvem utilizando o modelo de escopo aberto ou de escopo fechado?
Aqui na Codevance nós trabalhamos somente com escopo aberto.
Inclusive, estamos com uma promoção imperdível: O primeiro ciclo de entrega tem garantia! Se você não gostar da entrega, seja o motivo qual for, nós encerramos a parceria e você não paga nada!
Clique aqui para saber como nós podemos te ajudar!
Você concorda com o tema? Discorda? Tem algo a acrescentar?
Deixa seu comentário aí embaixo e me procure nas redes sociais para continuarmos o papo. Os links estão logo embaixo!
Abraços
