É possível fazer um software sob medida sem medo do “taxímetro”?

Não são poucos os casos de empresas que acabaram jogando fora um desenvolvimento inteiro pelo simples fato de que o software não atendia os requisitos necessários.

Por Pascoal Vernieri*

Em minha carreira como desenvolvedor de software, consultor e gestor de projetos, percebi uma constante no mercado de TI: 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 é muito comum os projetos se arrastarem por mais tempo do que o inicialmente acordado, devido a 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 trauma de atrasos, entregas que não correspondem ao escopo e um estouro no orçamento.

A resposta não vem em fórmula, mas a partir de testes e validação no mercado. Compartilho aqui alguns insights, com o objetivo de desmistificar algumas visões negativas sobre o desenvolvimento de software com terceiros.

1. CRIE A ESTIMATIVA DE TEMPO – E O ESCOPO – EM CONJUNTO COM O CLENTE 

Quando uma empresa decide terceirizar a produção de um software sob medida, 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.

LEIA TAMBÉM: Como evitar o caos no gerenciamento de empresas em crescimento

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, com 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.

2. 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.

3. 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 artigo mais detalhado, mas deixo aqui a dica para quem procura repensar processos e ganhar agilidade.

RESUMINDO A ÓPERA:

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.

*Pascoal Vernieri é CEO e fundador da Plathanus Consultoria e Gestão e escreve para o SC Inova sobre metodologias ágeis e gestão de projetos