O que observar quando contratar uma empresa de desenvolvimento de software

Escolher uma empresa para contratar o desenvolvimento de um sistema pode ser uma tarefa bem cansativa, devido ao volume de detalhes que precisam ser discutidos antes de assinar um contrato.

Algumas pessoas já tiveram experiências negativas com projetos de software, gerando eventualmente o medo dos problemas se repetirem.

Trabalhando com isso há tanto tempo, tendo participado de dezenas de projetos, mas também vendo o que acontece ao nosso redor, posso listar alguns pontos de atenção pra te ajudar no momento da escolha de um novo provedor de serviços de desenvolvimento.

Comunicação

De acordo com Manuel Pis e Matthew Skelton, no livro Team Topologies , a forma como o time se comunica refletirá diretamente na qualidade do software desenvolvido. Uma equipe que não se entende resulta em um software confuso também.

Mas não me refiro só a comunicação do time interno, que é algo que você não terá controle ao contratar. O que quero falar aqui é da comunicação entre cliente e fornecedor. Comunicação, é pra mim, um dos aspectos mais prioritários a se discutir, afinal…

Como será o atendimento e a troca de informações no dia a dia?

Ao nos comunicarmos falamos de expectativas, buscamos entender exatamente o que o cliente quer, discutimos o que pode ser feito ou não, validamos datas para entregas, e obtemos feedback.

Já vi algumas maneiras de manter comunicação; por documentação, por email, por telefone, reuniões constantes.. acho que já vi de tudo. Atualmente o que acredito que funciona melhor é comunicação em tempo real, é o cliente e “nós” num canal no slack conversando e discutindo sempre que necessário, numa frequência quase sempre diária.

Importante também é ter um ponto único de contato, normalmente com o próprio gerente do projeto. Se houver intermediários, haverá falha de comunicação.

Lembro-me de um estudo que apontou que a comunicação (ou falta dela) era a causadora da maior parte dos problemas no desenvolvimento de software, e acredito nisso.

Além das perguntas e respostas do dia a dia, acho essencial uma reunião periódica para mostrar o que está sendo feito, discutir os detalhes e ter certeza que estamos no caminho certo.

Entregas realísticas

Antes de falarmos em prazos para as entrega, precisamos falar de entregas realizáveis. 

É possível ser feito o que se espera?

Já vi este erro acontecer diversas vezes em projetos de empresas que nos procuram, com o projeto interrompido porque não foi possível termina-lo, uma vez que as expectativas não condiziam com a realidade.

Às vezes ao negociar com um time de vendas, na ânsia de fechar mais um contrato, ou por falta de atenção e conhecimento, o projeto é iniciado sem ser viável de ser concluído. Espera-se mais do que é possível ser feito na prática.

O que recomendo aqui é ter sempre pessoas técnicas na negociação, e que garantam que é possível ser implementado o projeto no determinado prazo e preço. 

A maneira de fazer isso é atravéz de uma estimativa de software, onde seu possivel fornecedor te fará uma série de perguntas bem específicas, tentando entender todos os detalhes do projeto, para chegar a uma estimativa realista.

Se o fornecedor não fizer isso, provavelmente existem partes ocultas, que poderão mais frente inviabilizar o desenvolvimento do projeto.

Quando o entendimento do projeto não consegue ser aprofundado, mas ainda assim é preciso uma boa estimativa, realizar uma fase de descoberta por ser uma boa opção, separando algumas horas para explorar mais a ideia, eventualmente até desenvolvendo um POC (Prova de conceito).

Frequência de entregas

Antigamente, a empresa desenvolvia um sistema por cinco, seis meses, e então fazia uma única entrega ao cliente, no final do desenvolvimento. Não tinha espaço para feedback nem mudanças. Uma alteração neste ponto significava mais horas, um novo contrato.

Hoje em dia o padrão é Continuous Delivery (CD), ou seja, entrega constante. Quanto mais vezes o cliente puder experimentar o que está sendo feito e dar seu feedback, melhor para o processo como um todo. Então olhe com cuidado qualquer outra proposta que não siga esse modelo.

Uma frequência incrível seria uma ou mais versões por semana (é como temos feito aqui). Uma a cada quinzena é ok. Uma por mês seria o mínimo absoluto.

Acompanhamento de falhas

Pode ser assustador saber quantos erros estão acontecendo no seu computador, enquanto você lê este post. Algumas centenas com certeza já se foram nestes últimos dois minutos.

Quando um software é desenvolvido, por mais que seja testado, é bem provável que vá apresentar algumas falhas quando utilizado. Neste sentido, é importante procurar saber como irão acompanhar os erros em tempo real, dos primeiros usuários em diante.

No começo deste século se salvava os erros em arquivos de log no servidor, e o que acontece, é que ninguem olhar estes arquivos. No geral só são olhados quando a coisa explode, mas ai, já tem tantos outros erros ali de tanto tempo, que ninguém vai querer investigar.

Hoje em dia, existem diversas ferramentas para auxiliar com o monitoramento proativo, que devem ser adotadas no principio do desenvolvimento, tais como Rollbar, Sentry, LogRocket.

Com estas ferramentas a equipe de desenvolvimento é avisada de uma nova falha assim que ela acontece, e eventualmente pode realizar a correção antes mesmo do cliente ser avisado pelo usuário, reduzindo a frustração do próximo usuário.

Aqui na App Masters, recebemos direto no nosso slack a notificação de um erro novo, um erro que se repete, ou um erro que já tinha sido resolvido e volta a acontecer. Ali mesmo no canal já discutimos as possíveis causas e soluções.

Pode have mudanças de requisitos durante o projeto?

Isso dependerá da cultura e metodologias utilizadas pela empresa de desenvolvimento. Mas, o importante aqui é discutir isso, saber se será possível uma mudança, como ela ocorreria, e quais as condições.

Ninguém quer um projeto que muda o tempo todo, dá muito trabalho e acaba causando perda de tempo. É preciso ter um foco. Mas um projeto que nunca muda, é difícil também de se imaginar.

Eu prefiro que mude. O software está sendo desenvolvido para facilitar a vida de alguém, e em determinadas entregas pode ser percebido que existe uma maneira melhor de se alcançar aquele objetivo. Eu quero um software que seja bom, não que seja de acordo com os requisitos iniciais.

Responder a mudanças ao invés de seguir um plano

Manifesto Ágil

Quando se mudam os requisitos, você terá que optar por atrasar um pouco a entrega ou desenvolver este novo item em substituição de outro que estava na fila. Em alguns casos implicará em mais tempo de trabalho, então pode impactar nos custos.

Mas não deixe de conversar sobre isso, para saber o que acontecerá quando você perceber que precisa mudar um pouco o rumo, porque isso provalmente irá acontecer.

De quem é o código fonte?

Existem empresas que cobram um valor a mais para “ceder” o código fonte do projeto aos clientes. Fique atento se esse for o caso, e pense como lidar com isso.

O que recomendo é desde o primeiro dia do projeto, 100% do material criado esteja em repositórios de código e em pastas compartilhadas, com acesso completo pelo cliente. Sem desculpas. Todos os artefatos do desenvolvimento devem pertencer ao cliente.

O caso onde isso não é possível, é quando se contrata o desenvolvimento de um sistema, que já será feito “por cima” de outro existente. Empresas de ERP normalmente fazem assim, o cliente precisa de tudo aquilo, e algo mais, dai realmente é inviável fornecer todo o código fonte já desenvolvido. Mesmo o código fonte produzido só pra este cliente, não serve de nada sem o restante.

Manutenção

Outro ponto importante a ser falado, é sobre a continuidade do sistema. É bom imaginar que após desenvolvido ele terminará, e não precisará fazer mais nada. Mas na real é difícil de imaginar isso, até porque ajustes e correções irão surgir por algum tempo mesmo após a conclusão.

Os usuários descobrirão bugs e precisarão de pequenos ajustes.

Então é bom que seja planejado alguns meses de suporte, com um volume X de horas, um padrão específico de comunicação e feedback.

Contrato

Se falamos em contratar, sabemos que existe um contrato. É importante ler com atenção ao contrato e exigir que estejam definidos ali todos estes pontos acima, e demais pontos que te preocupam.

Uma cláusula que pode ajudar e que recomendo, é o pagamento acontecer mediante entregas (e aceite do que foi entregue), e de acordo com o percentual do projeto já realizado.

Assim você evita pagar o projeto todo antes de ver algo funcionando, e evita problemas maiores lá na frente.

Prezar por uma boa relação

Muito além disso tudo, contratar uma empresa de desenvolvimento é o inicio de uma longa relação. Desde o primeiro contato as negociações devem correr tranquilamente, sem enrolação, sem desculpas esquisitas, e com transparência total.