O desenvolvedor e o equilibrista: é possível fazer um software sob medida sem medo do "taxímetro"?

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. Ou seja: o taxímetro rodou, o cliente pagou mas a empresa não chegou a lugar nenhum.

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

Comentários

Participe da comunidade, deixe seu comentário:

Deixe sua opinião!  Clique aqui e faça seu login.
    Pascoal Vernieri

    Pascoal Vernieri

    Entusiasta de metodologias ágeis. Especialista em Engenharia de Projetos de SW com certificações KMP I, KMP II, CSM, PMP tendo atuado em projetos de multinacionais como ORACLE, TOTVS e MORMAII. Nos últimos anos tenho atuado como consultor e facilitador do conhecimento buscado ajudar empresas de tecnologia a terem sucesso em sua jornada pela busca da agilidade por meio de práticas inspiradoras como Management 3.0, Design Thinking, Agilidade, Kanban tornando um ambiente leve e propício a mudanças.
    café com admMinimizar