Devemos construí-lo? A pergunta que fazemos antes de escrever qualquer código

Quando uma organização recorre a uma empresa de desenvolvimento de software, a expectativa costuma ser que a conversa termine numa proposta para construir algo: uma nova aplicação, a substituição de um sistema obsoleto, uma plataforma que ligue processos desconectados. É uma suposição compreensível, mas salta uma pergunta que deveria ser respondida antes de alguém falar de tecnologia, orçamentos ou datas de entrega.

Devemos mesmo construí-lo?

Na Libertas Software Research (LSR), acreditamos que saber se se deve desenvolver software é tão importante como saber como. Por vezes, uma aplicação por medida é exatamente o que é preciso. Por vezes, uma plataforma SaaS consolidada satisfaz perfeitamente a necessidade, ou ligar os sistemas que já tem produz o resultado sem o custo e a perturbação de os substituir. O objetivo é melhorar o funcionamento de uma organização, não acrescentar mais uma aplicação a um ambiente já complicado.

Comece pelo problema, não pela solução

As organizações tendem a descrever a solução que acham que precisam em vez do problema que têm. «Um painel de relatórios» ou «uma app para substituir as nossas folhas de cálculo» parece bem definido, mas diz pouco sobre o que motivou o pedido.

Pense num relatório de gestão mensal montado à mão a partir de várias folhas de cálculo e sistemas. Demora dias e, quando chega, os dados já estão desatualizados. A conclusão óbvia é que precisa de software de relatórios. Olhando mais de perto, o verdadeiro problema são muitas vezes dados desconectados e processos inconsistentes: um projeto de integração modesto, não uma nova aplicação. E se a investigação mostrar que precisa de fluxos de trabalho ou controlos especializados que nenhum produto suporta, é nesse momento que o desenvolvimento por medida merece o seu lugar.

Quando comprar faz mais sentido

O mercado comercial é maduro. CRM, contabilidade, agendamento, gestão documental e business intelligence têm produtos com anos de refinamento. Se um satisfizer as suas necessidades sem restrições irrazoáveis, uma substituição por medida acrescenta pouco valor.

Mas compare o custo total de propriedade, não os preços da subscrição. Um produto de 500 £ por mês são 30.000 £ em cinco anos, antes de acrescentar configuração, integrações, licenças adicionais ou alterações aos seus próprios processos. Verifique como o preço escala, se pode exportar os seus dados e o que acontece se o fornecedor mudar de modelo. E desconfie de forçar o negócio a abandonar atividades que realmente o distinguem só porque um produto assume o contrário.

Por vezes a resposta é ligar o que já tem

A maioria das organizações acumula sistemas ao longo do tempo: finanças num, operações noutro, apoio ao cliente num terceiro. Cada um funciona bem; simplesmente não comunicam entre si, e daí resultam atrasos, duplicação de esforço e informação inconsistente.

Substituir tudo por uma única aplicação é tentador, mas arriscado. As plataformas existentes guardam anos de conhecimento operacional e integrações ocultas. Uma camada de integração cuidadosamente desenhada (ligação de APIs, automatização de transferências, consolidação de relatórios a partir de fontes fidedignas) pode prolongar a vida desses investimentos. Exige reflexão cuidadosa sobre autenticação, propriedade dos dados, tratamento de erros e auditabilidade, mas recomendar integração em vez de substituição não é engenharia de segunda. Muitas vezes é a decisão arquitetural mais ponderada.

Quando o por medida é o investimento certo

Alguns requisitos realmente não cabem nos produtos convencionais: operações especializadas, necessidades invulgares de segurança ou de dados, ou software que é ele próprio uma vantagem competitiva. Aqui, o software por medida permite que a arquitetura siga a forma como o negócio realmente funciona.

Essa flexibilidade traz uma responsabilidade a longo prazo de manutenção, segurança, testes e suporte. Um sistema pode cumprir a especificação original e ainda assim ser um mau investimento se for difícil de manter ou não se puder adaptar. O desenvolvimento por medida justifica-se quando os benefícios de uma solução construída de propósito superam tanto o custo inicial como o compromisso contínuo de a possuir.

Nem todos os problemas precisam de mais software

Por vezes o problema é o processo. Aprovações, relatórios e passos administrativos acumulam-se ao longo dos anos, muito depois de as circunstâncias que os criaram terem desaparecido. Automatizá-los exatamente como estão apenas preserva a complexidade.

Se um documento precisa de cinco aprovações, não pergunte como automatizar cinco aprovações, pergunte porque existe cada uma e que risco cobre. O software é excelente a aplicar regras consistentes, mas não lhe pode dizer se o processo é sensato. Simplificar um fluxo de trabalho ou clarificar responsabilidades pode trazer ganhos reais sem outro sistema para aprender e suportar.

Olhe para além do custo inicial

Os projetos por medida têm um grande custo inicial enquanto o SaaS distribui o seu custo por subscrições, o que faz a comparação parecer desequilibrada. Uma comparação justa abrange toda a vida útil: implementação, licenciamento, alojamento, suporte, manutenção, integração, formação e alterações futuras.

Inclua também o custo de não fazer nada. Um processo ineficiente que consome 20 horas de trabalho por semana são cerca de 1.040 horas por ano. A uma taxa ilustrativa de 35 £ por hora, são cerca de 36.400 £ por ano, assumindo que o tempo pode realmente ser recuperado e redirecionado. Acrescente a má qualidade dos dados e as decisões lentas, mais difíceis de quantificar mas igualmente reais. A melhor opção não é a mais barata, mas a que tem a melhor combinação de valor, risco aceitável e sustentabilidade a longo prazo.

Porque recomendaria uma empresa de software não construir software?

É uma pergunta justa. Se recomendarmos um produto ou uma pequena integração, isso é menos trabalho de desenvolvimento no papel.

Mas há uma diferença entre fornecer capacidade de desenvolvimento e atuar como parceiro de investigação e arquitetura de software. O nosso trabalho começa antes de existir a especificação: compreender o problema, ponderar as opções e ajudá-lo a decidir onde investir. Isso tem valor seja qual for o resultado, e normalmente ainda há trabalho de análise, arquitetura, planeamento e integração a fazer mesmo quando o desenvolvimento por medida não é a resposta.

Recomendar desenvolvimento de que não precisa é contraproducente. Um projeto entregue a tempo e conforme a especificação falha na mesma se não era a solução certa. Ajudar um cliente a evitar despesa desnecessária constrói o tipo de confiança que perdura.

Poder construir não é razão para construir

A IA e as ferramentas modernas tornam o código mais rápido e barato de produzir. Isso é útil, mas torna o pensamento prévio mais importante, não menos, porque o esforço que antes obrigava a perguntar «precisamos mesmo disto?» está a desaparecer. É perfeitamente possível construir algo tecnicamente excelente, entregá-lo com eficiência e descobrir que era a resposta errada.

Antes de o desenvolvimento começar, queremos respostas claras sobre o problema de negócio, o custo de o deixar por resolver, que requisitos os produtos existentes não conseguem satisfazer, como será medido o sucesso (tempo de processamento, exatidão, visibilidade, conformidade, não número de funcionalidades) e quem vai operar e dar suporte à solução depois.

Haverá projetos em que o software por medida é claramente o certo, outros em que a integração oferece melhor valor, e outros em que uma plataforma pronta a usar faz o trabalho. O que importa é que a recomendação resulte da compreensão da sua organização, não de uma suposição sobre o que uma empresa de software quer vender.

Antes de perguntar como devemos construir algo, vale a pena apurar se devemos mesmo construí-lo.

A Libertas Software Research trabalha com organizações para investigar, avaliar, desenhar e desenvolver soluções de software, com foco na manutenibilidade a longo prazo, no valor operacional e no investimento tecnológico informado.