Quando foi a última vez que seu projeto terminou dentro do prazo e do custo? O Time fez muitas horas extras? Atendeu todo o escopo do projeto? Vamos ver neste artigo sobre a ilusão de segurança que temos em projetos com escopo fechado e como sair dessa armadilha.
A gestão de projetos de software, assim como o modelo cascata de engenharia de software são muito influenciados pelas engenharias tradicionais. Nelas há uma enorme etapa de análise na qual “todo” o escopo do projeto é levantado, analisado e detalhado. Com base nisso, o cronograma do projeto é criado, os recursos são estimados, o custo é orçado, levado para o cliente e depois de algumas idas e vindas é finalmente aprovado.
A grande vantagem desse tipo de contratação é que ela traz conforto para o contratante e contratado. O escopo é conhecido, o prazo e o custo também. “Sabemos” quem e quais as atividades estarão sendo realizadas na terça-feira da 2ª semana que ocorrerá daqui há 10 meses.
Triângulo de Ferro de Restrições Projetos (Escopo, Prazo e Custo)
E qual o problema com isso?
Começamos com o problema da metáfora da construção em engenharia civil ser utilizada para construção de software. Nesse post já falamos do perigo de utilizarmos a metáfora da engenharia civil para tratar projetos de desenvolvimento de softwares.
Na engenharia, se você deseja construir uma estrada que vai do Ponto A até o Ponto B, você pode fazer todo um estudo prévio para saber qual a distância entre os pontos, análise do terreno, tipo de materiais, entre outros. No final, você conseguirá estimar um custo e prazo baseado nessas variáveis. Além disso, a forma como se constrói estradas é relativamente estável, ou seja, o contexto da construção não muda frequentemente e o processo de construção também pode ser mais facilmente replicado.
Já em projetos de desenvolvimento de software, o ponto de chegada é desconhecido. Você pode partir do Ponto A, descobrir que não faz sentido chegar no Ponto B, ir para o Ponto C, desviar para o D. Pode ser que você tenha que subir montanhas, atravessar os mares ou descobrir que nos primeiros 100 metros não faz sentido construir o resto do caminho. A “estrada” do software é mal definida e seu produto provavelmente nunca estará concluído. Ele sempre pode melhorar, evoluir e se adaptar às necessidades mutantes do negócio.
Pergunte-se. Se você tivesse que começar um projeto de software hoje, você saberia dizer exatamente: quais as tecnologias serão utilizadas? As pessoas envolvidas no projeto? Quais funcionalidades darão retorno a empresa? Qual a reação dos usuários ao utilizar o seu produto? Você sabe exatamente o que estará fazendo daqui a um ano no seu trabalho? Se não, como esperar isso de um projeto?
Assumindo riscos altíssimos
Já que o início e o fim da construção do software são incertas, você sabe o risco que está assumindo ao fechar o escopo de um projeto nas fases iniciais?
Quando Boehm escreveu sobre o Cone da Incerteza Aplicado a Projetos de Software em 1981, ele considerava que o erro da estimativa no início do escopo de um projeto pode ser de até 8x. Esse erro vai reduzindo conforme vamos conhecendo mais sobre e o problema e a solução que estamos fazendo.
Cone da Incerteza (Boehm, 1981)
Em termos práticos, digamos que você é o responsável por um projeto de software. Seu cliente faz um briefing sobre o que ele deseja e você, muito competente, faz um belíssimo trabalho de análise, planejamento e medição do tamanho do projeto. Com base nessa medição, você estimou o custo total do projeto em R$ 1 milhão e o prazo em 1 ano. Na sua visão é tudo tão concreto que você se compromete com uma data exata. No dia 25/06 do ano seguinte, o cliente terá o projeto dele em mãos.
Infelizmente, independente do trabalho árduo de planejamento, medição e previsão que você teve, o Cone da Incerteza vai atuar no seu projeto e gritar que você fechou seu escopo cedo demais e seu projeto pode custar até R$ 4 milhões e durar 4 anos.
O cliente não sabe o que quer
“Mas a culpa disso não é minha, o problema é que o cliente não sabe o que quer e fica mudando o escopo do projeto toda hora”.
Livre-se de princípios inválidos. O cliente não sabe o que quer e isso é um FATO! Trabalhamos na economia do conhecimento e toda vez que você cria algo e coloca na mão dos seus clientes / usuários há uma reação ao seu produto. Há um impacto no negócio e suas métricas, novas ideias surgem, altera-se o comportamento das pessoas com relação ao problema que o software soluciona e o escopo muda.
Além disso, quem disse que o cliente é a melhor pessoa para descrever o software para você? Ele é a pessoa que sofre do problema e espera que você dê a solução para esse problema.
Quando você vai ao médico, você receita o seu tratamento ou conta para ele o problema e espera vir dele um tratamento?
E os contratos de “fábricas” de software
Mas aí temos um problema. Hoje contrato as “fábricas” de software com o escopo fechado. Existem diversas formas de contratar projetos de software sem a necessidade de fechar o escopo. Veja neste vídeo do Marcos Garrido um dos modelos para quem está saindo do escopo fechado.
Continue acompanhando nosso blog que em breve publicaremos alguns artigos específicos sobre contratação de projetos de software.
Pontos importantes para sair dessa enrascada.
Seja ágil, mas não um ágil qualquer, meia bomba utilizando paradigmas tradicionais disfarçados de ágil. Seja #TrueAgile:
- utilize ciclos curtos de feedback (planejamento, construção e entrega);
- priorize e construa o que é mais importante primeiro;
- valide o que você está fazendo o tempo todo, meça os resultados do que está sendo entregue;
- medir o seu produto e saber o que está dando retorno e o que não está dando retorno é fundamental para definirmos em quais funcionalidades vamos investir.
O mais importante, nunca se esqueça: “Responder a mudanças mais que seguir um plano” (Manifesto Ágil, 2001)
Quer saber mais sobre esse assunto? Veja os links abaixo:
- Faça o nosso treinamento de Certified Scrum Product Owner (CSPO).
- Leia os posts sobre:
- Leia também muitas outras dicas no Livro Scrum do Rafael Sabbagh
