Escopo aberto já foi pauta do nosso e-book de contratos ágeis. O texto de hoje trará novas informações e um olhar mais maduro.

Antes de tudo: o que é o escopo fechado

Para começarmos a mapear o cenário do escopo fechado, precisamos definir o que entendemos por escopo.

Escopo é o nosso limite de operação. É tudo aquilo que faz parte do compromisso de entrega que um fornecedor oferece a um cliente. Quando temos limites e abrangências determinadas antes do projeto começar, dizemos que o escopo é fechado.

Mas você já parou para pensar: porque continuamos a negociar projetos dessa maneira? Ou melhor, será que não existe outra forma de garantir que o serviço será feito com qualidade?

Bom, se você já passou pela experiência de ter que correr para cumprir um apertado prazo, sabe que o resultado final, muitas vezes, não agrada nem o cliente e nem a própria equipe.

E se os projetos fossem negociados assumindo que a mudança no pedido (escopo) seja parte do processo de entrega do trabalho?

E se, entregássemos menos do que o imaginado inicialmente pelo cliente, sem deixar de cumprir os objetivos de negócio, com um preço menor e num prazo mais curto do que o exigido pelo “projeto ideal”?

Pode parecer utopia, mas entendendo bem os elementos base de um projeto de desenvolvimento de software, é possível usufruir das vantagens do mundo digital e deixar para trás as analogias com o modo de produção industrial.

Você deve estar se perguntando: mas qual o problema com o modo de produção industrial?

No contexto de construção de pontes, carros e prédios faz todo sentido o planejamento ser o mais detalhado e antecipado possível para que o trabalho de execução siga todas as normas de segurança necessárias.

A questão é que esse processo dá pouca margem para mudança de plano pois dificulta a redefinição de prioridades ao longo do trabalho. E é justamente esta flexibilidade que o movimento agilista estimula.

“Responder a mudanças mais que seguir um plano.”
(Quarto valor do Manifesto ágil).

Importante deixar claro que quando nos dispomos a questionar o modo de produção industrial não é por um julgamento de valor moral, mas sim por motivos econômicos. Mudar o plano num processo industrial é caro e resulta no atraso da entrega final.

Até o começo da década, era comum encontrar softwares que demoravam semestres (ou anos!) para serem atualizados. Hoje em dia o processo de desenvolvimento de software evoluiu de tal maneira que os custos de mão-de-obra para atualizar um código que já está rodando praticamente zeraram. As atualizações já não são mais em período de meses, já acontecem em questão de horas e minutos.

As outras variáveis de um projeto de software

Nessa altura do texto você já deve estar se questionando como adotar o escopo aberto. E para conseguir defender essa mudança no seu ambiente de trabalho será preciso esclarecer outros pontos importantes. Afinal, como lidar com escopo aberto se o prazo e orçamentos forem fixos?

Para responder a essa importante pergunta, precisamos entender quais são as quatro principais variáveis de um projeto de software: o escopo, o prazo, o custo e a qualidade.

Para entender melhor como elas se influenciam, vamos imaginar o seguinte cenário:

Digamos que não haja flexibilidade na negociação do escopo. O prazo (cronograma) é fixo, pois está vinculado a uma campanha de Natal, e o custo é pré-determinado pela verba já separada para a campanha. Se não podemos negociar escopo, nem prazo, nem custo, o que infelizmente sofrerá com a variabilidade? A qualidade.

O cliente, na maioria dos casos, não vê o que acontece nos bastidores. O que chega pra ele é o que o time entrega. E se essa entrega vier cheio de problemas e bugs, arrumá-los custará tempo e grana – além do estresse que esses ajustes costumam causar em todos os envolvidos.

Estamos então diante de um paradoxo. A preocupação excessiva em seguir um plano à risca (escopo fechado), encaixá-lo no orçamento e seguir um cronograma apertado na maioria das vezes acaba sendo contraprodutivo – e caro!

Por isso levamos à sério a variável da qualidade. Ela influencia diretamente nos outros 3 pilares do projeto.

A primeira atitude que se pode adotar para começar a valorizar a qualidade é questionar a pessoa que disse que precisa de 100% do escopo planejado. Sempre dá para tirar alguma coisa, ou deixar para depois do lançamento. Sempre dá. Lembremos do Princípio de Pareto aplicado à esse contexto, onde 20% das funcionalidades geram aproximadamente 80% do valor que o usuário procura.

É nessa hora que entra em jogo a habilidade de conversar com cliente, e com os gestores envolvidos. Precisamos deixar de lado as disputas de ego e nos comprometer com que a entrega de valor seja o objetivo em comum entre todos que participam do projeto.

É importante considerar a influência dos fatores psicológicos, pois muita coisa pode estar em jogo durante um projeto. Uma ambição por promoção ou um desejo por mostrar eficiência. Ao mostrar que um trabalho com qualidade se paga – financeiramente e profissionalmente – diminuímos as objeções e resistências iniciais a um modelo mais aberto e flexível.

– Vamos se ajudar, pessoal.

Com base na nossa experiência aqui na Taller, a conversa acontece no seguinte tom:

“Bom, não vai ser possível fazer 100% do escopo planejado com o preço e o prazo que você quer. Vamos cortar juntos uma parte do escopo.”

Algumas partes vão saindo, outras ficam para depois.

O projeto prossegue. Problemas inesperados começam a surgir (o que é normal).
Neste momento uma conversa transparente situa o cliente dentro do processo:

“Essas atividades aqui vão atrasar porque seu time não aprovou o que foi feito. Essa outra aqui está nos dando mais trabalho do que o previsto… A gente precisa cortar mais escopo para dar conta de fechar tudo no prazo.”

Algo bem comum de acontecer é que uma parte das funcionalidades nunca venha a ser desenvolvida, pois com o tempo coisas mais importantes surgem e “furam a fila”.

E, convenhamos, algo que não é importante para ser feito no começo do projeto dificilmente passará a ser no final.

*Sobre priorização de escopo nós temos dois texto sobre Business Value Points (BVP), que é o método que utilizamos para separar o que é mais importante do que pode esperar:

• O que é BVP no desenvolvimento ágil?
• BVP na prática

Os custos ocultos do escopo fechado

Quando usamos o argumento econômico para justificar uma mudança para o modelo aberto de escopo não é à toa. Para quem desenvolve é um risco muito grande se comprometer com uma quantidade fixa a ser entregue, sem que considere que muitas mudanças ocorrerão no percurso. Por isso, o valor passado para o cliente terá uma margem de segurança (gordurinha, em bom português). E esse “extra” pode inviabilizar o fechamento de um projeto promissor.

Quando trabalhamos num modelo mais flexível, não existe a necessidade de incluir esse custo de risco na conta do orçamento. Além de ser vantajoso para o cliente é uma vantagem comercial que o fornecedor obtém no mercado em que atua.

E se você precisa de um argumento matador para ajudar a convencer o cliente da escolha pelo modelo de escopo aberto, questione:

“Por que pagar por funcionalidades que não serão usadas? Uma parte do seu escopo é desperdício. Não pague por isso.”

E a palavra desperdício, por mais impactante que possa soar, é o que precisa ser dito. Ainda mais se a verba para o projeto já vier pré-definida (o que é o mais comum).

Imagine-se na posição de quem está descrevendo o que precisa ser feito – um(a) gerente de setor, no caso. A intenção dele(a) será colocar o máximo de funcionalidade possível e imaginável dentro do valor disponível. Isso é torrar dinheiro.

Em um cenário onde o desperdício pode determinar o sucesso ou fracasso de um produto, quanto melhor for nossa capacidade de priorizar o que gera alto valor, de trabalhos que não são tão importantes, melhor para o negócio.

Os valores que uma empresa fornecedora precisa cultivar para adotar o escopo aberto

Já citamos a importância da transparência de ambas as partes durante o processo de negociação. Inclusive, a transparência é um tema recorrente no nosso blog.

Pare para pensar por um instante: que outros valores são importantes para fazer com que o escopo aberto funcione da melhor maneira possível?

Você já deve ter percebido a importância da comunicação constante entre os envolvidos. É justamente com um acompanhamento de perto que o cliente conseguirá apontar as mudanças de rumo assim que a necessidade surgir. Seja com encontros online diários, ou relatórios semanais. Essa troca precisa acontecer.

A metáfora do táxi nos ajuda a entender como a comunicação constante atua como fator-chave da equação do escopo aberto.

Digamos que tenhamos uma entrega para fazer no centro de uma cidade que não conhecemos – e pior, bem na hora do rush. Você avisa o motorista:

“Preciso que entregue este pacote na Rua X até às 19h de hoje.”
O motorista confiante responde que “Ok, entrego sim.”

No caminho tudo ia bem até que um acidente trancou completamente a via por onde o taxista seguia. Sem conseguir andar na velocidade prevista, o motorista chega ao destino com 30 minutos de atraso.

Quando o motorista liga avisando que atrasou a entrega provavelmente estaremos indignados. Bem provável que no final da corrida ambos estejam estressados e infelizes com o resultado do serviço.

Agora imagine que ao invés de deixarmos o motorista ir sozinho, estejamos dentro do táxi acompanhando o trajeto.

Mesmo que todos os imprevistos tenham acontecido, como estamos junto na situação, a culpa do atraso deixa de ser do taxista e passa a ser do motivo real do atraso. No caso, o trânsito. E durante o trajeto é possível ligar para o destino avisando sobre o atraso, olhar no Waze uma alternativa de rota, ou até saltar do táxi e ir à pé.

Tudo isso é possível quando existe comunicação constante entre cliente e prestador de serviço.

Escopo aberto não é bala de prata

Com os argumentos apresentados até agora seria sedutor imaginar que o escopo aberto seja a solução para todos os seu problemas.

É importante deixar claro que não é o escopo aberto que tende a dar certo, mas são os projetos que tendem a dar errado. E trabalhar escopo aberto é uma forma de responder rápido ao que pode vir a dar errado durante o processo de desenvolvimento de software.

Ser ágil é justamente a capacidade de mudar de direção rapidamente.

Outro ponto que vale ressaltar: cortar escopo não significa deixar de fazer o que foi pensado previamente. Muitos casos se resolvem simplificando funcionalidades complexas, deixando enxuta uma tarefa importante, sem que ela deixe de entregar o valor esperado para o usuário final.

A proposta deste texto não é entrar em detalhes específicos do que deve ou não ter um contrato de software. Entrando em contato com a Taller (contato@taller.net.br) podemos explicar como se dá a negociação e tirar outras dúvidas com relação a como mostrar para o time interno e clientes que escopo aberto é possível no contexto de desenvolvimento de software e áreas próximas.

**

Para entender melhor como organizamos o fluxo de projetos aqui na Taller recomendamos o e-book que conta nosso processo de transição “Do caos ao custo médio por demanda” e os podcast sobre análise de negócios com o Helal Ferrari, além do já citado podcast sobre o nosso Fluxo Unificado, que contou com a participação do nosso agile coach Celso Martins.

Um grande abraço, e deixe nos comentários suas dúvidas e complementos ao texto. Vamos transformar esse artigo numa grande conversa sobre como lidar com as variáveis de projeto, em especial o escopo aberto.

***

Artigo publicado originalmente em http://blog.taller.net.br/escopo-aberto/