Ao longo de minha carreira como desenvolvedor de software, consultor e gestor de projetos, pude perceber uma constante no mercado de tecnologia: a dificuldade que as empresas têm no modelo de gestão e implementação de software. Me refiro especificamente aos casos de desenvolvimento com terceiros — quando você mede (ou tenta medir) o tempo de produção a partir de uma estimativa de horas, que se torna o custo final do projeto.

“Custo final” em termos, pois como muitos que já terceirizaram a produção de programas podem afirmar, é muito comum os projetos se arrastarem por mais tempo do que o inicialmente acordado, por uma série de fatores, elevando também o orçamento. Outro pesadelo comum neste tipo de serviço é o resultado não ser satisfatório, em termos de features, usabilidade, design etc.

Não são poucos os casos que conheço de empresas que acabaram jogando fora um desenvolvimento inteiro — e que não custou barato — pelo simples fato de que o software não atendia os requisitos necessários. Em bom português: não era um produto viável para levar ao mercado.

### O taxímetro rodou, o cliente pagou mas a empresa não chegou a lugar nenhum.

Nos últimos anos, meu principal desafio tem sido o de entender a melhor maneira para desenvolver sistemas que não apenas fossem eficazes às contratantes, mas que principalmente não gerassem todo esse processo traumático de atrasos, entregas que não correspondem ao escopo e estouro no orçamento.

A resposta não vem em fórmula, mas aos poucos, a partir de testes e muita validação no mercado. Compartilho aqui alguns dos insights resultantes desse desafio, que tem como objetivo desmistificar algumas visões negativas sobre o desenvolvimento de software com terceiros.

Crie a estimativa de tempo — e escopo — em conjunto com o cliente

Quando uma empresa decide terceirizar a produção de um software, uma das primeiras missões internas é a equipe técnica definir uma estimativa de horas de desenvolvimento do projeto. Este é um ponto chave no processo, motivo de muita controvérsia e que merece atenção. Quando a equipe interna de uma empresa sugere o tempo que ela levaria para fazer determinada tarefa para um outro grupo de profissionais, não considera fatores como: a produtividade da equipe interna é idêntica à da equipe externa? essa estimativa, dada a rotina na empresa, não está considerando o acúmulo de outras funções?

Quando a empresa responsável pelo desenvolvimento recebe o “pacote pronto”, é natural que algumas entregas sejam feitas em tempo menor, enquanto outras estourem. O desafio principal do desenvolvedor, neste modelo, é ser um equilibrista, sem deixar de lado o principal: a qualidade do que está entregando.

Para resolver esta questão, chegamos a um denominador: em vez de receber pronto um projeto — com horas estimadas e especificações — entendemos que o ideal é construir este escopo em conjunto com o cliente, de maneira imersiva e colaborativa. Quando você começa um projeto se colocando dentro da empresa nos primeiros dois, três dias, passa a entender os objetivos, dores, necessidades e complexidades que aquele sistema pode resolver para o cliente, fazendo com que ambas as equipes estejam alinhadas — como se fosse um ateliê de software.

Ao final, saímos como uma série de atividades, que são produzidas em “ondas”, otimizando também o tempo de produção da equipe terceirizada e efetivando entregas a cada duas semanas. Parece uma saída simples — e é. A questão é você entender o nível de complexidade de cada momento do projeto e dar segurança à empresa ao longo do processo de desenvolvimento.

O modelo tradicional de desenvolvimento está falido

Durante anos, atuei em grandes empresas e consultorias que se baseavam na simples cobrança por hora para a entrega de serviços e produtos. É algo bastante corriqueiro no mercado, mas não tenho dúvidas que se trata de um modelo falido. Em geral, há atrasos nas entregas, estouro de prazo, a equipe de desenvolvimento acaba sendo muito cobrada e o custo da falta de gestão ou da baixa maturidade em gestão será pago por alguém: a contratada ou a contratante. E isso é ruim para ambos os lados.

Na maneira convencional, a entrega de um software terceirizado costuma ser testado plenamente ao final da entrega. Mas se não houver conformidade em alguma coisa, lá vai a equipe novamente para a produção, refazer processos e recolocar o taxímetro para rodar. E esse filme, infelizmente, é muito comum no mercado. Para evitar esse drama, existe a figura do “quality assurance”, uma pessoa do contratante que fará o controle de qualidade de cada entrega, junta com as etapas anteriores, revisa e decide se está ou não em conformidade.

Quer agilidade? Kanban > Scrum

A partir de experiências pregressas, e do redesenho de processos que fiz em algumas empresas, notei por exemplo que o Kanban (um modelo de gestão visual tão simples quanto eficiente) é muito melhor para desenvolvimento de projetos com esta pegada mais ágil, de entregas curtas e validação rápida com o cliente, do que o tradicional Scrum.

Este método deixa muito visível o que está sendo trabalhado, que equipes estão trabalhando e o que de fato foi entregue que agregou valor ao projeto. Isto o torna muito mais transparente na relação de cliente e fornecedor. Talvez seja assunto para um outro artigo, mais detalhado sobre esse tema, mas deixo aqui a dica para quem procura repensar processos e ganhar agilidade.

Em resumo…

O ganha-ganha acontece quando há uma relação de confiança e comprometimento. Muitas contratantes ainda optam pelo “taxímetro” porque de certa forma é uma maneira mais simples de cobrar por aquilo que está pagando. O valor financeiro, ao final das contas, é o mesmo, o que fará diferença é a forma como o projeto é conduzido. E o sucesso se mede quando há aprendizado para ambas as partes, criando uma relação saudável e inspiradora — além, claro, de um produto incrível que gere resultados e novos negócios.

Publicado também no Medium


FAQ: Desenvolvimento de Software com Terceiros: Desafios e Estratégias para Sucesso

1. Por que os projetos de desenvolvimento de software com terceiros frequentemente sofrem com atrasos e estouros de orçamento?

Os projetos de desenvolvimento de software com terceiros muitas vezes sofrem com atrasos e estouros de orçamento devido à falta de uma estimativa precisa de tempo e escopo, além da ausência de um controle de qualidade contínuo ao longo do processo.

2. Como evitar a insatisfação do cliente em relação ao resultado final do projeto terceirizado?

Para evitar a insatisfação do cliente, é fundamental envolvê-lo no processo de definição do escopo do projeto de forma colaborativa, garantindo que as expectativas estejam alinhadas desde o início e realizando entregas incrementais para obter feedback constante.

3. Qual é o problema do modelo tradicional de cobrança por hora no desenvolvimento de software terceirizado?

O modelo tradicional de cobrança por hora no desenvolvimento de software terceirizado pode levar a atrasos nas entregas, estouro de prazos e custos adicionais, pois não incentiva a eficiência e a entrega de valor ao longo do processo.

4. Como garantir a qualidade do software desenvolvido por terceiros?

Para garantir a qualidade do software desenvolvido por terceiros, é importante contar com um processo de "quality assurance", onde uma pessoa do contratante realiza o controle de qualidade de cada entrega, revisando e validando se está em conformidade com os requisitos.

5. Por que o método Kanban pode ser mais adequado para projetos de desenvolvimento de software com entregas curtas e validação rápida?

O método Kanban é mais adequado para projetos de desenvolvimento de software com entregas curtas e validação rápida, pois oferece uma gestão visual transparente do trabalho em andamento, facilitando a identificação de gargalos e a alocação eficiente de recursos.

6. Como garantir uma relação saudável e inspiradora entre contratante e contratado em projetos de desenvolvimento de software terceirizados?

Uma relação saudável e inspiradora entre contratante e contratado em projetos de desenvolvimento de software terceirizados é garantida quando há confiança, comprometimento e aprendizado mútuo ao longo do processo, resultando em um produto final de qualidade que atenda às necessidades do cliente.

Esta FAQ aborda os desafios específicos e oferecer estratégias para garantir o sucesso em projetos de desenvolvimento de software com terceiros.