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
- Receita previsível
- Prazo previsível
- Demanda previsível
- 1) O empreendedor sabe exatamente o que deseja no início do projeto.
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.
- 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.
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
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
- Custo
- Prazo
- Qualidade
- Desenvolvimento Orientado a Testes
- Programação em Par
- Refatoração
- Código Coletivo
- Desenvolvimento Iterativo
- Integração Contínua
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$ 15 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 contrato é revisado a cada dois meses, quando o empreendedor tem a opção de permanecer com a equipe de desenvolvimento ou encerrar o projeto sem ônus.
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 é, de tempos em tempos, o empreendedor pode cancelar o contrato sem nenhum ônus, ou seja, sem ter que pagar multas contratuais. Neste exemplo, ao final dos primeiros dois meses, o empreendedor já terá recebido um software relativo a duas Sprints. Ou seja, terá tido duas oportunidade de utilizar o trabalho concreto produzido pelos desenvolvedores. Isso representa informação suficiente para saber se a equipe está caminhando com um ritmo adequado ou não. Sendo assim, ao longo de todo o projeto, a cada dois meses, 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 de contrato apresentado, ao começar um projeto, a equipe de desenvolvimento só terá garantia do faturamento dos primeiros dois meses, pois ao final desse tempo 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 após os primeiros dois meses 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.