Muito se fala hoje em dia sobre Desenvolvimento Ágil, Scrum, Startup Enxuta e outros termos famosos no mundo do empreendedorismo. Metodologias que prometem um lançamento mais rápido no mercado, correções e melhorias contínuas, possibilidades de mudanças estratégicas durante o desenvolvimento e chances muito maiores de sucesso.
No entanto, ao explicar para um novo empreendedor, ou até mesmo gerentes e diretores de grandes empresas, as vantagens destes métodos, muitos receios surgem rapidamente, e o principal é sempre o mesmo: “Como posso fechar um contrato com uma empresa de desenvolvimento sem definir em detalhes o que irei receber no final do projeto?”
Se você se encaixa em um desses perfis, prometo que este post será bastante esclarecedor.
Projetos ágeis, ao contrário do que muitos acreditam, possuem um escopo que define o que deve ser feito. Tal escopo existe antes de o projeto ser iniciado e continua a existir ao longo do projeto até que ele seja encerrado. Entretanto, ao contrário de modelos tradicionais de desenvolvimento, este escopo não é fixado em contrato. Ou seja, caso o empreendedor perceba a necessidade de fazer ajustes no escopo para que a solução leve em conta seu aprendizado ao longo do projeto, ou mudanças nas circunstâncias, ele pode. Em projetos ágeis, o escopo é revisado frequentemente para garantir que equipe dedique seus esforços ao que é mais prioritário em cada etapa do projeto.
Como o escopo não é fixo, como você pode saber o que será entregue ao final do projeto, quanto será gasto e qual será o tempo total consumido? Para compreendermos essa questão, vamos começar tratando de um assunto fundamental: previsibilidade.
A ilusão da previsibilidade
O que torna o contrato tradicional, de escopo fechado, tão atraente para o empreendedor? Ele acredita que contará com:
- Custo previsível
- Prazo previsível
- Escopo previsível
Ou seja, acredita que sabe exatamente o que receberá, quando e por qual preço, o que é um cenário extremamente atrativo para qualquer um disposto a investir em um novo projeto!
Olhando pelo lado da empresa que prestará o serviço de desenvolvimento, no caso, nosso lado, as perspectivas também são muito interessantes:
- Receita previsível
- Prazo previsível
- Demanda previsível
Isto é, em teoria, saberíamos exatamente o que precisa ser feito, quanto iremos faturar com o projeto e quando estaremos livres para alocar a equipe em outra demanda.
Bom, enfim, se é um cenário bom para o empreendedor e é bom para a empresa que desenvolverá o sistema, então onde está o problema?
O problema está na Premissa da Previsibilidade, que se divide em duas:
- 1) O empreendedor sabe exatamente o que deseja no início do projeto.
Nos projetos de software (Aplicativos Android e iOS, Sites institucionais, Painéis Administrativos, Sistemas embarcados, e qualquer outro), o empreendedor tipicamente não sabe com exatidão como deseja que o software seja.
O que ele sabe é o problema que tem em seu dia-a-dia e espera que o software o ajude, ou as ideias únicas que pretende colocar no mercado com seu nova solução. Isto é, ele sabe de forma geral O QUE o software deve fazer, e quais problemas deve resolver.
E durante o projeto, é comum esta visão de negócio permanecer basicamente inalterada, com pouca ou nenhuma mudança. Por outro lado, o empreendedor precisa saber com bastante clareza que, quando falamos de software, para todo problema existem inúmeras maneiras de solucioná-lo.
Por exemplo, uma grande empresa, com mais de 10 mil funcionários, gostaria de avaliar seus funcionários anualmente para que pudesse identificar deficiências de formação e solucioná-las através de treinamentos apropriados. Avaliar essa quantidade de pessoas leva à necessidade de construir um sistema e a empresa investe na contratação de uma Software House para desenvolvê-lo. Existem inúmeras formas e tecnologias que poderiam ser empregadas para construir um sistema desse gênero. Empreendedor e fornecedor podem acordar uma abordagem, traçando um escopo inicial e, ao longo do projeto, descobrir a possibilidade de simplificar ou facilitar partes do sistema fazendo algo que não havia sido previsto originalmente. Note que, neste caso, altera-se a forma de resolver o problema, mas este permanece inalterado ao longo de todo o projeto.
Esperar que a visão de negócio, os problemas que devem ser resolvidos, isto é, O QUE o software deve fazer, se mantenham estáveis é algo razoável, pois é comum acontecer, mas esperar que a solução necessariamente seja a mesma imaginada originalmente, isto é, COMO o software deve atacar cada ponto, é pouco produtivo, porque raramente acontece.
A possibilidade de durante o desenvolvimento podermos aprender, aprimorar e realizar mudanças de abordagem é algo muito positivo. Diria mais, atualmente, no mundo extremamente dinâmico que vivemos, essa flexibilidade é vital para novos projetos!! Vital porque garantem que a solução estará continuamente sendo atualizada para gerar o máximo de valor para os usuário finais, além de poderem resultar em economia de dinheiro e tempo para o empreendedor, quanto para a empresa que faz o desenvolvimento.
Como se pode notar pelo exemplo, no início do projeto de software, o empreendedor e a equipe visualizam soluções que representam o escopo inicial do projeto. Ao longo do tempo, à medida que aprendem mais e avançam, é comum surgirem formas alternativas de resolver o problema, às vezes mais simples, mais rápidas de implementar ou com resultados mais expressivos. Se tais alternativas já fossem conhecidas desde o início do projeto, poderiam fazer parte do escopo original, mas como é comum que elas só sejam descobertas ao longo do projeto, é importante que possam ser incorporadas.
Como o empreendedor aprende ao longo do projeto, ele naturalmente reavalia suas necessidades e prioridades e, portanto, altera o escopo para incorporar seu aprendizado. A visão do sistemas, e quais pontos precisam ser atacados pelo software (O QUE) permanece praticamente o mesmo, mas a forma de resolver cada ponto (COMO) está continuamente em evolução. Sendo assim, fica bastante claro que o escopo não é algo previsível, e fixá-lo freqüentemente se revela uma má idéia (veremos mais à frente o porquê).
- 2) A empresa de desenvolvimento é capaz de estimar com perfeição e entregar o sistema no dia combinado.
Supondo que o empreendedor realmente soubesse tudo o que quisesse e como seria cada detalhes da solução, não mudando nem um mínimo detalhe ao longo do desenvolvimento, bastaria que a empresa contratada fizesse uma boa estimativa para que a previsibilidade sobre o escopo e as demais variáveis do projeto fosse viável.
Entretanto, para que a estimativa fosse minimamente acertada, seria preciso que o empreendedor comunicasse todos os detalhes do sistema para a equipe e que a mesma compreendesse tudo perfeitamente. Isso é difícil devido a pelo menos dois problemas sérios:
- O empreendedor normalmente não conta todos os detalhes, até porque não os conhece. Em qualquer sistema que tenha mais que uma meia dúzia de funcionalidades, a quantidade de detalhes tende a ser extremamente elevada. Sistemas são complexos, porque existem muitas combinações que podem gerar os mais diversos tipos de comportamentos, muitos dos quais inesperados. Estes detalhes, inúmeros dos quais não serão ditos pelo empreendedor, fazem grande diferença no custo e no prazo do desenvolvimento. Portanto, não sabê-los antecipadamente torna o esforço de estimar o sistema bastante limitado.
- Ainda que o empreendedor apresentasse todos os detalhes seria preciso que a equipe compreendesse tudo corretamente. Como as especificações dos projetos costumam ser expressas de forma escrita, a equipe pode interpretar o que lê das mais diversas formas, o que dá margem para que ela erre feio na estimativa simplesmente por ter interpretado incorretamente os requisitos.
Por tudo o que foi dito, e ao contrário do que muitos gostariam de acreditar, previsibilidade normalmente não passa de uma ilusão na área de software.
O empreendedor acaba se convencendo que acredita na proposta e o fornecedor também se convence que acredita naquilo que está propondo. Todos estamos habituados a ver que os projetos simplesmente não saem como o previsto e estatísticas, como as produzidas pelo Standish Group (Chaos Report 2015), vem confirmando isso há décadas. Então, o que fazer?
Que tipo de previsibilidade podemos esperar?
Em desenvolvimento de software, é importante que empreendedores e desenvolvedores compreendam que:
- Previsibilidade de escopo é inviável na maior parte dos casos
- Escopo fixo, ao invés de representar previsibilidade, prejudica os envolvidos, especialmente o empreendedor
O primeiro ponto já comentamos, então passemos para o segundo.
Quando o empreendedor opta por um escopo fixo, está apostando que não aprenderá nada ao longo do projeto e que nada diferente ocorrerá em seus processos de negócio. Raramente isso é verdade. O empreendedor aprende e as empresas convivem cada vez mais com ambientes de negócio que avançam com rapidez e demandam mudanças em seus projetos de software. Portanto, optar por um escopo fixo significa correr um risco, bem elevado, de que o software final não atenda às reais necessidades do empreendedor e de seus usuários finais. Embora isso já seja suficientemente grave, não é tudo.
Segundo as estatísticas do Standish Group, mais de 60% das funcionalidades de um software comercial típico jamais são utilizadas quando colocadas em produção. Ou seja, se a equipe de desenvolvimento produzir exatamente o que está no escopo original, ela provavelmente estará produzindo uma grande quantidade de funcionalidades que jamais serão usadas. Em outras palavras, mais de 60% do investimento poderá ser jogado fora porque não irá gerar nenhum valor, por não ser usado.
De fato, a melhor forma de administrar um projeto de software é rever permanentemente as prioridades e assegurar que apenas funcionalidades essenciais, isto é, que serão usadas de verdade, sejam colocadas no sistema. Só é possível saber quais são estas funcionalidades ao longo do desenvolvimento, enquanto o empreendedor aprende com o software que está sendo construído, especialmente quando o desenvolvimento é iterativo, como no caso do Scrum.
Ser iterativo significa receber um software funcionando a cada final de iteração, o que permite utilizar as funcionalidades, aprender com elas e rever que funcionalidades ainda poderão trazer valor para o projeto com base no feedback concreto daquelas já implementadas. Perder essa oportunidade, fixando um escopo no início, é extremamente prejudicial para o próprio empreendedor.
Bom, afinal, o que é um contrato de escopo negociável?
É um contrato que se baseia na premissa (bastante realista) de que não existe previsibilidade sobre o que será feito no software. Embora seja possível haver previsibilidade em relação aos gastos e ao tempo. Como se poderá observar, é também uma forma de alinhar os interesses do empreendedor e da empresa que irá desenvolver o software.
Existem quatro variáveis essenciais que precisam ser abordadas em qualquer contrato de desenvolvimento:
- Custo
- Prazo
- Escopo
- Qualidade
O tradicional contrato de escopo fixo determina claramente qual será o custo, o prazo e o escopo. A qualidade pode até ser abordada, mas normalmente é sacrificada assim que o prazo aperta. Já o contrato de escopo negociável segue outro caminho. Visto que as quatro variáveis são conflitantes até certo ponto, não é possível fixar todas elas. Uma alternativa é fixar:
- Custo
- Prazo
- Qualidade
Assim, permite-se que o escopo absorva as incertezas do projeto. Neste caso, o empreendedor continua sabendo o quanto irá gastar, bem como quanto tempo o projeto irá durar. O que ele não sabe com exatidão é o que irá receber, isto é, COMO o software abordará cada um dos problemas a serem corrigidos. Mas, na verdade, se pararmos bem para pensar, o empreendedor já não sabia disso no caso do contrato de escopo fixo, ele apenas tinha a ilusão de saber, a ilusão da previsibilidade do escopo. Portanto, ele não perde absolutamente nada e adicionalmente estamos assumindo uma relação contratual mais honesta e realista.
Por sua vez, a qualidade pode ser tratada no contrato determinando que o projeto seja desenvolvido utilizando práticas que assegurem elevados padrões de qualidade, tais como:
- Desenvolvimento Orientado a Testes
- Programação em Par
- Refatoração
- Código Coletivo
- Desenvolvimento Iterativo
- Integração Contínua
As práticas de Desenvolvimento Ágil são organizadas de modo a assegurar que as prioridades sejam respeitadas e revistas periodicamente, bem como altos padrões de qualidade sejam mantidos. Desenvolvendo software de forma iterativa, ou seja, entregando mais funcionalidades a cada Sprint (períodos variando de 2 a 4 semanas), o empreendedor tem inúmeras oportunidades de rever as prioridades, bem como avaliar o trabalho da equipe. Isso permite que ele aprenda ao longo do projeto, incorpore o seu aprendizado ao sistema e decida o que tem valor ou não e, portanto, deve ser implementado ou não.
Esta decisão é o que permite que ele atinja a data alvo com um software que tenha, no mínimo, as funcionalidades que mais irão gerar valor para ele. Isto é, se não for possível desenvolver todas as funcionalidades, queremos assegurar que as funcionalidades que ficarem de fora do sistema sejam aquelas que produziriam menos valor, porque as mais valiosas já são implementadas no início do projeto. Esta filosofia costuma ser mais valiosa para o empreendedor, porque ao final ele tem um software que atende às suas necessidades e prioridades reais e não as que ele achava que tinha no início do projeto.
E o que fazer se o empreendedor contratar uma equipe inadequada para o projeto?
Em qualquer contrato, independente do tipo, existe o risco de que a equipe não corresponda às expectativas do empreendedor. É importante que o empreendedor conheça a capacidade real da equipe o quanto antes e, com base na sua observação, possa decidir se deseja ou não continuar com ela. Em contratos de escopo fixo, especialmente em projetos tradicionais com desenvolvimento sequencial, o empreendedor só saberá se fez uma boa escolha após o projeto já ter avançado muito, pois o código demora a ser produzido, portanto, o feedback demora a aparecer.
No Desenvolvimento Ágil, o empreendedor começa a receber funcionalidades prontas e pode utilizá-las já ao final da primeira Sprint. Tendo ainda mais funcionalidades, na Sprint seguinte e assim sucessivamente. Isto fornece inúmeras oportunidades para avaliar e decidir se deseja ou não continuar com a equipe, o que ajuda a administrar o risco do projeto.
Sendo assim, na prática, primeiramente, antes mesmo do projeto começar, é preciso estimar o tempo necessário e a quantidade de pessoas a serem alocadas na equipe. Para isso, pode-se fazer um levantamento inicial de funcionalidades como em qualquer projeto. Não existe mágica neste sentido. A empresa que fará o desenvolvimento e o empreendedor terão que conversar sobre a visão do que o futuro sistema deverá fazer e quais serão suas funcionalidades. Com base nisso, pode-se estimar o número de pessoas recomendável, bem como o prazo desejado.
O custo do projeto naturalmente é proporcional à quantidade de tempo e pessoas alocadas ao projeto. Neste momento, ninguém tem certeza se todas as funcionalidades imaginadas no escopo original estarão prontas no prazo combinado, pois nem ao menos sabemos se serão todas estas as funcionalidades que serão desenvolvidas ou se elas serão modificadas ao longo do tempo.
Portanto, ao invés de buscar previsibilidade e uma estimativa perfeita, o que se espera neste momento é identificar valores que sejam razoáveis, tanto para o tempo, quanto para o custo e o número de pessoas. Feito isso, o contrato para este modelo Ágil de projeto poderia seguir o exemplo a abaixo:
O projeto terá a duração de oito meses, sendo 8 Sprints de 4 semanas. A equipe terá seis desenvolvedores ao custo de R$ X mil/mês. empreendedor e equipe devem discutir as funcionalidades a serem desenvolvidas ao início de cada Sprint. Caberá à equipe de desenvolvimento indicar o número de funcionalidades possível de serem entregues por Sprint. Os pagamentos serão mensais e o empreendedor tem a opção de permanecer com a equipe de desenvolvimento ou encerrar o projeto sem ônus a qualquer momento.
Portanto, voltando à pergunta inicial, o que o empreendedor pode fazer se a equipe começar a produzir pouco ou com má qualidade?
O contrato é simples. Indica quantas pessoas serão alocadas, por quanto tempo e qual o custo delas por mês. Parece ser basicamente um contrato de locação de mão-de-obra com pagamento baseado em utilização de horas. Mas não é, pois há um detalhe fundamental para se compreender a filosofia deste modelo de contratação: o empreendedor tem opções de saída. Isto é, o empreendedor pode cancelar o contrato sem nenhum ônus, ou seja, sem ter que pagar multas contratuais.
Neste exemplo, já ao final do primeiro mês, o empreendedor já terá recebido um software relativo a primeira Sprint. Ou seja, terá tido oportunidade de utilizar o trabalho concreto produzido pelos desenvolvedores, permitindo avaliar se a equipe está caminhando com um ritmo adequado ou não. Sendo assim, ao longo de todo o projeto, o empreendedor pode decidir se mantém ou troca a equipe de desenvolvimento.
Infelizmente, errar na contratação de uma equipe é mais comum do que se imagina. Entretanto, o pior é quando erros como esses são descobertos tardiamente, quando o custo de repará-los é muito elevado. Errar é natural e é uma possibilidade que todo empreendedor deve enfrentar e não temer, pois aprendemos e evoluímos com os erros. O que devemos temer é levar tempo demais para descobrir que erramos. Isso é o que o desenvolvimento Ágil e o contrato de escopo negociável procuram evitar.
Iterações a cada Sprint permitem descobrir cedo se o emprendedor errou na contratação. Contratos de escopo negociável permitem reverter uma contratação inadequada cedo, ainda no início do projeto, quando poucos recursos foram investidos. Assim ajuda a administrar o risco do empreendedor, além de alinhar objetivos.
Alinhando interesses! Parcerias de sucesso são aquelas que são boas para ambos os lados!
No exemplo apresentado, ao começar um projeto, a equipe de desenvolvimento só terá garantia do faturamento do próximo mês (considerando um aviso prévio de 30 dias), pois o empreendedor pode encerrar a parceria se não estiver satisfeito. Portanto, como naturalmente desejamos participar do projeto nos outros seis meses subseqüentes, temos todas as razões para nos esforçarmos ao máximo para fazer um excelente trabalho, com agilidade e qualidade, visando a manutenção da parceria até a entrega final.
Por outro lado, não temos nenhuma razão para rejeitar as mudanças propostas pelo empreendedor, porque o escopo não está fixado e o pagamento não está atrelado a ele. Sendo assim, o empreendedor pode alterar funcionalidades ao longo do projeto sem que isso afete a capacidade da equipe de cumprir o contrato. Os interesses ficam alinhados. Todos querem um trabalho que atenda da melhor forma possível às necessidades do empreendedor e de seus usuários finais porque isso beneficiará tanto a equipe de desenvolvimento quanto o empreendedor.
No modelo de contrato tradicional, onde o escopo é fixado, alterações sugeridas pelo empreendedor tendem a gerar custos extras elevados, pois, como o escopo é fixado no contrato, mudanças efetuadas nele afetam a capacidade da equipe de cumprir o contrato. Sendo assim, é comum que em contratos deste tipo muitas vezes, e infelizmente, levem empreendedores e desenvolvedores a se tornarem adversários em um jogo no qual o empreendedor tenta maximizar a quantidade de funcionalidades que recebe e os desenvolvedores tentem minimizar o esforço e as funcionalidades.
Além disso, tais contratos tendem a ser mais caros, pois as equipes de desenvolvimento prevêem que os empreendedores farão alterações no escopo e, por isso, adicionam esse risco em suas estimativas de esforço.
Por fim, CONFIANÇA!
No contrato de escopo negociável a empresa que faz o desenvolvimento fica relativamente vulnerável pelo fato de o empreendedor ter o direito de suspender o contrato se não estiver gostando do trabalho, e o grande ponto de virada para essa instabilidade é a confiança que será gerada no processo.
O Desenvolvimento Ágil recomenda que o empreendedor participe do desenvolvimento e isso é essencial para a boa evolução do projeto. Se o mesmo estiver envolvido no dia-a-dia do projeto, conhecerá melhor o trabalho da equipe, seu ritmo, seus pontos fortes, seu empenho e comprometimento. Ou seja, a equipe estando realmente dedicada a fazer um bom trabalho ele conseguirá notar isso.
E não existe nada mais poderoso para estabelecer uma relação de confiança entre empreendedor e desenvolvedores que aproximar ambas as partes tanto quanto possível e criar um histórico de credibilidade. Isso ocorre naturalmente quando a equipe de desenvolvimento entrega consistentemente as funcionalidades acordadas em cada Sprint.
Conclusão
O desenvolvimento ágil com contratos de escopo negociável é, definitivamente, a primeira decisão certeira que novos empreendedores precisam tomar para buscarem chances muito maiores de sucesso em seus projetos.
Esse modelo garantirá:
- Flexibilidade para aprendizado evolutivo durante o desenvolvimento
- Desenvolvimento de funcionalidades que realmente gerem valor para os clientes
- Ajustes estratégicos de percurso de forma muita rápida
- Agilidade na entrega e validação do projeto no mercado
- Correções contínuas na solução
- Projetos mais baratos, sem margem de risco devido a mudanças de escopo
- Errar é uma possibilidade, mas erre rápido. Acompanhamento e validação contínua da performance da equipe de desenvolvimento.
E você? Possui um projeto para ser desenvolvido?
Envie seu contato para a Buildbox e uma especialista entrará em contato para fazer um entendimento da sua solução!
