Software à medida ou de prateleira: como decidir

Posta assim, a pergunta não tem resposta. Ninguém quer mandar programar de novo uma tabela de clientes, e ninguém quer que o processo que ganha os seus clientes acabe num campo de observações porque o programa não o previa. A decisão útil não é entre dois caminhos: é sobre onde passa a linha entre eles, dentro da sua operação.

A dicotomia é falsa, e é isso que a torna perigosa

Na prática, quase nenhuma empresa compra software totalmente à medida nem totalmente de prateleira. Quem manda desenvolver de raiz acaba a usar componentes feitos por outros; quem compra um produto acaba a configurá-lo até ele deixar de se parecer com o da empresa ao lado.

Discutir «medida ou prateleira» no abstrato é escolher um lado antes de olhar para o problema, e as duas escolhas cegas falham de maneiras conhecidas. Tudo à medida produz um sistema que só uma pessoa entende e que fica parado no dia em que essa pessoa muda de emprego. Tudo padrão produz uma operação que se vai adaptando ao software até já não saber explicar porque é que faz as coisas daquela maneira.

Que parte da sua operação é realmente diferente?

Há um teste que resolve a maior parte dos casos: se um concorrente competente fizesse isto, faria de forma parecida? Se a resposta for sim, é matéria comum, e pagar para a desenhar de novo é pagar duas vezes por algo que já existe e já foi testado por muita gente. Registar um cliente, guardar um documento, controlar quem vê o quê — ninguém ganha um cliente por fazer isto de maneira original.

Se a resposta for não, a padronização começa a custar. Imagine uma oficina que recolhe a viatura em casa do cliente e a devolve lavada, com um relatório fotográfico do que foi feito. Nada disto é uma etapa padrão de um funil de vendas: é a razão pela qual aquele cliente não vai à oficina da esquina. Empurrar esse percurso para um campo de texto livre é deixar de o poder medir, repetir e melhorar — ou seja, é deixar de poder geri-lo.

A pergunta, então, não é «isto é especial?», porque toda a gente acha que o seu caso é especial. É «isto explica por que motivo os clientes nos escolhem?». Se explicar, merece desenho próprio. Se não explicar, merece um padrão e a paz de espírito que vem com ele.

Cada campo feito à medida é um compromisso de manutenção

É o argumento que costuma faltar na decisão. Software à medida não custa o que custa a fazer: custa o que custa a manter. Antes de aceitar qualquer desenvolvimento, convém saber quem o atualiza quando o resto do sistema mudar, quem o percebe quando quem o escreveu já não estiver, e como é testado no dia em que uma regra do negócio ou uma obrigação legal mudar.

Isto não é um argumento contra medida. É um argumento a favor de a usar onde se justifica, e de perguntar, em cada caso, quem fica com a responsabilidade a longo prazo. A pergunta a fazer a um fornecedor não é «conseguem fazer isto à medida?», porque a resposta é sempre sim. É outra: «isto que vão fazer entra no produto que mantêm, ou fica a viver só na minha instalação?»

A diferença entre as duas respostas decide quem paga a manutenção nos anos seguintes, e é uma das rubricas que aparecem quando se discute custo a sério em vez de comparar valores mensais.

O sinal de que a prateleira está a ficar apertada

Não é a queixa de que falta uma funcionalidade — essa queixa existe em qualquer sistema e muitas vezes é hábito, não necessidade. O sinal verdadeiro é a operação começar a mentir ao sistema, e aparece de três maneiras:

• O campo de observações passa a conter o estado real do trabalho, escrito em prosa, que ninguém consegue consultar depois.
• A equipa cria convenções combinadas entre si — um prefixo no título, uma etiqueta com um significado que não está escrito em lado nenhum — para representar o que o sistema não tem.
• Nasce uma folha de cálculo ao lado, só para o passo que não cabe, e ao fim de pouco tempo é ela que manda.

Quando qualquer uma destas três aparece, já não é uma questão de preferência: há informação operacional a viver fora do sistema, e mais cedo ou mais tarde alguém vai decidir com base numa fotografia incompleta sem saber que está incompleta.

O caminho que não obriga a escolher

Base padrão onde o padrão serve, desenho próprio onde diferencia, tudo sobre a mesma estrutura de dados. É um princípio simples de dizer e exigente de cumprir, porque obriga quem configura a resistir a duas tentações opostas: resolver tudo com um campo novo, ou responder a tudo com «o sistema não faz isso assim».

É essa a lógica do nosso modelo de trabalho: uma base CRM comum, e módulos ajustados ao negócio de cada cliente. Se está a avaliar plataformas com esta arquitetura, vale a pena saber o que separa uma modularidade real de aplicações separadas vendidas em conjunto — está tratado em como escolher um CRM modular.

E leve à demonstração o processo que não encaixa em lado nenhum. Não o mais simples: o mais estranho, aquele que costuma ser explicado com um «isto no nosso caso é diferente». A pergunta a fazer sobre ele é tripla: resolve-se com configuração, com um módulo que já existe, ou com desenvolvimento novo? Quem responde às três com clareza está a dizer-lhe exatamente onde passa a linha. Quem responde «fazemos tudo o que precisar» ainda não olhou para o problema.