Quando um projeto começa a afundar?
Todo projeto de TI começa de forma parecida. Há planos ambiciosos, cronograma, apresentação das primeiras maquetes e a convicção de que, em alguns meses, a empresa estará a usar um sistema moderno. A princípio tudo parece promissor, mas com o tempo surgem os primeiros atrasos. O prazo é adiado por uma semana, depois por um mês. O número de erros aumenta, a comunicação com o fornecedor fica cada vez mais difícil, e as respostas seguintes passam a ser: "Só mais um pouco", "É só um pequeno ajuste" ou "Já estamos na reta final."
Em certo momento percebe-se que, em vez de um produto pronto, a empresa tem um projeto inacabado que ninguém quer assumir.
Esse é um cenário bem mais frequente do que se imagina.
O maior problema não é o código
A maioria dos empresários presume que, se o projeto não funciona, a culpa é do código mal escrito. De fato — às vezes é exatamente isso. Na prática, no entanto, o problema costuma estar mais profundo.
Falta documentação. A arquitetura foi criada "no calor do momento". Não há testes automáticos. Integrações foram feitas de forma provisória. Funções adicionais foram acrescentadas sem analisar o impacto no sistema como um todo. Como resultado, até uma pequena alteração causa novos erros.
É um pouco como reformar uma casa sem um projeto. Cada cômodo pode ser terminado, mas com o tempo percebe-se que as paredes não estão onde deveriam, as instalações foram feitas de forma aleatória e a reconstrução fica cada vez mais cara.
Quando vale a pena dizer "pare"?
Um dos momentos mais difíceis para o proprietário da empresa é decidir interromper a colaboração com o fornecedor atual. Muitos empresários adiam essa decisão por tempo demais.
Por quê?
Porque o projeto já consumiu muito dinheiro.
Porque é uma pena abandonar.
Porque talvez "ainda dê certo".
A psicologia chama isso de efeito dos custos afundados. Quanto mais já investimos, mais difícil é admitir que a direção atual não leva a lugar algum.
Entretanto, às vezes a melhor decisão não é continuar despejando orçamento no mesmo problema, mas parar o projeto e analisar a situação com calma.
Será que todo projeto pode ser salvo?
Não. — E vale dizer isso honestamente.
Há projetos cuja reparação custaria mais do que recriá-los do zero. Também acontece que a tecnologia usada já está obsoleta ou que a arquitetura foi projetada de modo a impedir o desenvolvimento futuro.
Por isso o primeiro passo nunca deve ser prometer resultados.
O primeiro passo deve ser uma auditoria.
Só depois de analisar cuidadosamente o código, a documentação, a infraestrutura e os processos é possível responder se vale mais a pena consertar a solução existente ou iniciar um novo projeto.
Um bom parceiro tecnológico não dirá o que o cliente quer ouvir.
Dirá o que é melhor para o negócio.
Como é, na prática, salvar um projeto?
Ao contrário do que se pensa, não se começa programando.
Primeiro é preciso entender com o que estamos lidando.
Analisamos a arquitetura do sistema, a qualidade do código, a forma de comunicação entre módulos, a segurança dos dados, o desempenho e as possibilidades de evolução. Verificamos a documentação, o histórico de alterações e as tecnologias utilizadas. Frequentemente, já após alguns dias fica claro onde está o problema real.
Só então surge um plano de ação.
Às vezes basta organizar o código e corrigir alguns elementos-chave. Outras vezes é necessário reconstruir módulos selecionados. Também acontece que a solução mais sensata é criar um novo sistema reaproveitando o que já foi produzido.
Não existem dois projetos idênticos.
Assim como não existe uma única receita para resgatá-los.
Por que assumir um projeto é mais difícil do que criar um novo?
Essa pergunta ouvimos frequentemente de clientes.
A resposta é simples.
Ao criar um sistema do zero, conhecemos cada decisão de projeto. Sabemos por que uma solução foi escolhida e quais eram as premissas.
Ao assumir o projeto de outrem, primeiro precisamos reconstruir esse conhecimento.
É como assumir a construção de uma casa de uma equipe que deixou o canteiro sem plantas, sem documentação e sem informações sobre o que foi feito.
Por isso resgatar projetos exige não só habilidades de programação, mas também experiência em arquitetura, análise e design.
Um parceiro tecnológico deve estar ao seu lado também quando surgem problemas
Um bom software house não se reconhece por como inicia um projeto.
Reconhece-se por como reage quando surgem dificuldades.
Nem tudo pode ser previsto. Mudam-se requisitos de negócio, tecnologias e necessidades dos usuários. O essencial é se a equipe é capaz de encontrar soluções, comunicar riscos claramente e tomar, em conjunto com o cliente, as melhores decisões.
É nesses momentos que se constrói confiança.
Como trabalhamos na Web24?
Abordamos projetos que exigem transição com grande cautela.
Não fazemos promessas após a primeira conversa.
Primeiro analisamos a situação. Verificamos o que foi feito, o que pode ser aproveitado e o que exigirá reconstrução. Só depois preparamos uma recomendação e um plano de ações.
Nosso objetivo não é escrever mais milhares de linhas de código.
Nosso objetivo é levar o projeto até o ponto em que ele comece a apoiar de fato o crescimento do negócio.
Resumo
Se o seu projeto ficou travado, o fornecedor parou de responder, o cronograma existe apenas na teoria e as correções geram novos erros, isso ainda não significa que tudo está perdido.
Em muitos casos o problema pode ser resolvido.
Mas é preciso começar por um passo: uma análise séria da situação.
Porque antes de começar a resgatar um projeto, vale primeiro descobrir por que ele começou a afundar.
