Negócios
Última Atualização:
João Pedro Carvalho
Quem chega a esta encruzilhada costuma formulá-la como uma escolha de fornecedor: assinar uma plataforma que já existe ou pagar a alguém para desenvolver uma à medida. Posta assim, a decisão parece técnica, e por isso é frequentemente delegada em quem percebe de tecnologia.
É a delegação errada. A escolha entre comprar e desenvolver é uma decisão de alocação de capital, de atenção da gestão e de risco. Determina onde é que a empresa vai ter dinheiro imobilizado, quem é que passa a ter uma responsabilidade permanente que antes não tinha, e o que é que acontece à operação quando algo correr mal. Nada disto se resolve olhando para funcionalidades.
Há uma pergunta anterior que muda tudo e que raramente se faz: este processo é aquilo que te distingue dos teus concorrentes ou é apenas aquilo que tens de fazer para operar? Um restaurante precisa de faturar, de gerir turnos e de controlar consumos, mas nenhuma dessas coisas é a razão pela qual os clientes voltam. Uma empresa de logística que descobriu um método próprio de consolidar cargas está noutra posição: aí o processo é o negócio.
A resposta a esta pergunta não determina sozinha a decisão, mas determina o ponto de partida. Comprar é o caminho por defeito. Desenvolver tem de justificar-se contra ele, e a justificação tem de ser numérica.
O erro de forma: comparar uma mensalidade com um orçamento
Coloca 2 propostas lado a lado. Uma diz 45€ por utilizador por mês. A outra diz 55.000€ para desenvolver. Quase toda a gente compara estes números diretamente, e quase toda a gente se engana, porque não têm a mesma forma.
A mensalidade é um custo recorrente visível. Aparece todos os meses, incomoda todos os meses, e por isso é revista. O orçamento de desenvolvimento é um número único e visível que arrasta atrás de si uma cauda de custos recorrentes invisíveis, que ninguém orçamentou e que ninguém revê, porque não chegam em fatura separada. Chegam em horas de pessoas que já estão na folha de salários.
A cauda inclui, no mínimo:
Alojamento e infraestrutura, que continuam a existir e a ser faturados mesmo nos meses em que ninguém mexe numa linha de código.
Correções, porque nenhum sistema sai perfeito da primeira vez e porque as falhas escolhem sempre o pior momento para aparecer.
Adaptações a mudanças externas, das quais nunca escapas: alterações fiscais, novas obrigações de faturação, integrações que mudam de versão, sistemas operativos que deixam de suportar bibliotecas antigas.
Segurança, que é trabalho contínuo e não uma caixa que se assinala uma vez no arranque e nunca mais se revisita.
Evolução, porque o negócio muda e o sistema tem de acompanhar essa mudança, sob pena de deixar de ser uma alavanca e passar a ser um travão.
Substituição de quem sabe, o custo mais subestimado da lista, e o que aparece exatamente na cena do jantar de despedida.
O lado da compra também tem cauda, e vamos lá chegar. A diferença é que a cauda da compra está em grande parte no contrato, escrita, e a cauda do desenvolvimento está em pressupostos que ninguém escreveu.
A lente contabilística ajuda a ver isto. Desenvolver empurra dinheiro para o balanço e para a demonstração de resultados de vários exercícios seguintes. Comprar deixa-o no período a que respeita. Uma opção consome tesouraria hoje, a outra consome margem todos os meses, e é a mesma distinção entre investimento em ativo e gasto operacional que qualquer gestor já encontrou noutras decisões. São 2 perfis de risco distintos.
A maior análise empírica publicada sobre desvios em projetos de tecnologia foi feita na Universidade de Oxford por Bent Flyvbjerg e Alexander Budzier. Examinaram 1.471 projetos, comparando orçamentos e benefícios estimados com custos e resultados reais, num universo que ia de sistemas de gestão integrada a plataformas de relação com clientes.
O desvio médio de custo foi de 27%. Esse número, dizem os autores, esconde o que interessa. Quando se desenha a distribuição dos desvios aparece uma cauda pesada, e 1 em cada 6 projetos era o que eles chamam um cisne negro: desvio de custo de 200%, em média, e desvio de prazo de quase 70%. A conclusão que tiram é precisa e pouco confortável: o problema dos projetos de tecnologia não é serem particularmente propensos a desvios médios altos, é haver entre eles um número desproporcionado de catástrofes.
Os casos que documentam ilustram o mecanismo melhor do que qualquer média. A Levi Strauss iniciou uma migração de sistemas com um orçamento abaixo de 5 milhões de dólares e acabou a registar um encargo de 192,5 milhões contra resultados, depois de ter fechado centros de distribuição durante uma semana por não conseguir satisfazer encomendas. A Kmart lançou um projeto de modernização de 1,4 mil milhões e percebeu, um ano depois, que o sistema estava tão personalizado que a manutenção se tornaria proibitivamente cara, o que a levou a lançar um segundo projeto de 600 milhões para corrigir o primeiro.
A amostra tem limites que mudam a forma de a ler. É composta em 92% por organizações do setor público, em 83% por projetos com origem nos Estados Unidos, e o custo médio por projeto era de 167 milhões de dólares. Não é uma amostra de PME. Os autores registam, ainda assim, que não encontraram diferenças relevantes entre o setor público e as organizações privadas e europeias que compunham o resto da amostra.
O que se transporta não é a percentagem, é o teste de esforço que os autores propõem, e esse funciona em qualquer escala. Consegues absorver o embate se o teu maior projeto tecnológico derrapar 400% e entregar entre 25% e 50% dos benefícios prometidos? E consegues absorver se 15% dos projetos secundários, aqueles que ninguém acompanha de perto, excederem os custos em 200%?
Se a resposta a qualquer uma destas perguntas for não, isso não significa que não deves construir. Significa que tens de partir o projeto em pedaços pequenos o suficiente para que a resposta passe a ser sim.
A estimativa que te deram já nasceu curta
Há uma segunda razão para desconfiar do número que está em cima da mesa, e não tem nada a ver com má-fé de quem o produziu.
Roger Buehler, Dale Griffin e Michael Ross publicaram no Journal of Personality and Social Psychology um conjunto de 5 estudos sobre a forma como as pessoas estimam quanto tempo vão demorar a terminar aquilo que começaram. No primeiro, perguntaram a estudantes finalistas quando entregariam a tese. A previsão média foi de 33,9 dias. O tempo real foi de 55,5 dias. Apenas 29,7% cumpriram a própria estimativa.
O detalhe que interessa vem a seguir. Aos mesmos participantes foi pedida uma previsão pessimista, assumindo que tudo corria o pior possível. A média dessa previsão foi de 48,6 dias, ainda abaixo do tempo real, e mesmo na hipótese mais negra que conseguiram imaginar, menos de metade dos participantes cumpriu o prazo que tinham dado. Pedir a alguém para ser conservador não resolve o problema, porque o enviesamento não está na dose de otimismo, está no método.
Quando os investigadores gravaram o raciocínio em voz alta durante a estimativa, encontraram a explicação. Cerca de 74% dos pensamentos referiam-se a cenários futuros, quase sempre a descrever como o trabalho iria correr bem. Apenas 7% referiam experiências passadas com tarefas semelhantes. As pessoas não estavam a mentir sobre o passado, estavam simplesmente a não olhar para ele.
O achado mais útil para quem tem de decidir aparece no quinto estudo. Observadores externos, a prever quando é que outra pessoa terminaria a mesma tarefa, apontaram 8,5 dias contra os 5,5 dias previstos pelos próprios. O tempo real foi de 6,8 dias. Os observadores erraram por excesso, os próprios erraram por defeito, e os observadores recorreram ao histórico 20 vezes mais do que quem ia fazer o trabalho.
Daqui saem 2 consequências práticas, e nenhuma delas é desconfiar do teu fornecedor.
A primeira é que a estimativa de esforço nunca deve vir apenas de quem vai executar. Alguém que conheça o domínio mas não vá pegar no trabalho produz um número sistematicamente diferente, e a discrepância entre ambos é informação valiosa por si só. A segunda é que a correção do enviesamento exige mais do que recordar o passado. Num dos estudos, os participantes a quem foi pedido que descrevessem experiências anteriores continuaram a subestimar exatamente como os restantes. O enviesamento só desapareceu no grupo que teve de construir explicitamente um cenário que ligasse o que tinha acontecido antes ao que estava a estimar agora.
Os próprios autores sublinham um limite: eliminar o enviesamento não melhorou a exatidão absoluta das previsões. As estimativas deixaram de ser sistematicamente curtas e passaram a errar em ambas as direções. A correção protege-te de ser enganado sempre para o mesmo lado, e é por isso que pertence à mesma família dos métodos de decisão que não dependem da intuição de quem decide.
Se há um número que devia estar escrito na parede de qualquer sala onde se decidem estas coisas, é o peso da manutenção no custo total de um sistema ao longo da vida.
Jussi Koskinen, da Universidade da Finlândia Oriental, compilou os estudos empíricos disponíveis sobre custos de manutenção e o quadro que resulta é notavelmente consistente apesar de décadas de distância entre os trabalhos. Zelkowitz e coautores apontavam 67% em 1979. Lientz e Swanson, no estudo clássico feito em 487 organizações, apuraram mais de 50% do tempo do pessoal. McKee chegou a valores entre 65% e 75%. Eastwood registou 75% em empresas da lista Fortune 1000. Erlikh, já em 2000, colocou o valor acima de 90%.
A dispersão é grande e as definições diferem entre estudos, o que obriga a tratar qualquer destes números com cautela. A direção, porém, não se discute em lado nenhum: construir é a parte barata, manter é a parte cara, e a proporção entre ambas não é próxima de metade e metade.
Há um segundo dado na mesma compilação que explica porque é que isto acontece e que raramente é discutido. Estudos sobre o trabalho de quem faz manutenção mostram que aproximadamente 50% do tempo é gasto a compreender código que já existe, antes sequer de o alterar. Não a programar. A perceber o que lá está.
Traduz isso para a tua empresa. Quando compras, quem gasta esse tempo é o fornecedor, e o custo está diluído entre milhares de clientes que pagam a mesma mensalidade. Quando desenvolves, esse tempo é teu. E quando a pessoa que escreveu o sistema sai, o tempo que alguém vai precisar para compreender o que ela fez não é uma inconveniência, é metade do custo de manutenção a ser pago outra vez do zero.
É por isto que documentação não é burocracia num projeto de desenvolvimento à medida. É a única coisa que impede a empresa de comprar 2 vezes o mesmo conhecimento.
Onde é que o teu negócio se distingue mesmo
Falta o critério que separa os casos em que desenvolver compensa daqueles em que é uma distração cara. E o critério não é a complexidade, nem a dimensão, nem o orçamento disponível.
Desenha as etapas pelas quais o teu negócio transforma matéria-prima, tempo ou informação em algo que um cliente paga. Este exercício de mapear onde é que cada etapa acrescenta ou destrói valor responde à pergunta melhor do que qualquer comparação de funcionalidades. Em cima dessa sequência, marca as etapas em que fazes alguma coisa que os teus concorrentes não fazem, ou fazes de uma maneira mensuravelmente melhor.
Na esmagadora maioria das empresas, essas etapas são muito poucas. Faturação não é uma delas. Contabilidade não é. Processamento de salários não é. Gestão documental não é. Correio eletrónico, agendamento, assinatura digital, controlo de assiduidade, nenhuma dessas coisas é uma vantagem competitiva, e desenvolver qualquer uma delas à medida é pagar por trabalho que dezenas de empresas já fizeram melhor e que continuam a manter por ti.
Sempre que a resposta for que o processo é igual ao dos outros, compra. Sempre que a resposta for que o processo é o motivo pelo qual ganhas negócio, a conversa muda de natureza, porque aí não estás a comprar eficiência, estás a proteger a razão de existires.
Há ainda um caso intermédio que confunde muita gente. Às vezes o processo é banal mas a combinação é rara: a empresa faz o que os outros fazem, só que ligado de uma maneira que ninguém liga. Nesse cenário, o que vale a pena construir não é o processo inteiro, é a ligação. Compras as peças e desenvolves a costura, que é habitualmente uma fração do custo e do risco.
A compra também tem custos escondidos, e são de outra natureza.
A escala tem preço. O modelo de preço por utilizador é atrativo com 8 pessoas e desconfortável com 60. Uma empresa que triplica a equipa triplica a fatura sem receber nada de novo em troca, e é aqui que muitas decisões acertadas envelhecem mal. Se estás numa fase de crescimento rápido, este cálculo tem de ser feito com a estrutura futura, não com a atual, o mesmo cuidado que se exige a qualquer decisão de preparar o negócio para crescer sem partir.
A personalização acumula dívida do outro lado. Muita gente compra e depois configura tanto que acaba com um sistema tão específico como se o tivesse construído, mas sem controlo sobre ele. Cada campo adicional, cada automatismo, cada relatório à medida é uma peça que vai ter de ser refeita quando o fornecedor mudar alguma coisa, e o fornecedor vai mudar.
O plano de evolução não é teu. A funcionalidade de que precisas pode entrar no ano que vem, pode entrar nunca, e a decisão não passa por ti. Quem compra troca controlo por velocidade, o que é normalmente um bom negócio, desde que se saiba que a troca foi feita.
O fornecedor é um risco de continuidade. Pode ser comprado, pode mudar de posicionamento, pode descontinuar o produto, pode simplesmente fechar. Uma dependência operacional num terceiro é uma relação que se gere ativamente, com as mesmas cautelas de qualquer outra relação com fornecedores críticos da operação, e não algo que se assina e se esquece.
As integrações são o custo real. O preço da licença raramente é o que dói. O que dói é ligar o sistema novo ao que já existe, e esse trabalho tem de ser orçamentado à parte, com a mesma desconfiança com que se orçamenta desenvolvimento à medida, porque é desenvolvimento à medida.
O bloqueio deixou de ser apenas contratual
Aqui está uma alteração recente do enquadramento europeu que muda a matemática desta decisão e que ainda não entrou na conversa da maioria das empresas.
O Regulamento (UE) 2023/2854, conhecido como Regulamento dos Dados, é aplicável desde 12 de setembro de 2025 e dedica um capítulo inteiro à mudança entre prestadores de serviços de tratamento de dados. Segundo a página explicativa da Comissão Europeia, os prestadores de serviços em modelo de plataforma e de aplicação têm de disponibilizar interfaces abertas e, no mínimo, exportar dados num formato corrente e legível por máquina, enquanto os prestadores de infraestrutura têm de assegurar equivalência funcional quando o cliente muda para um serviço do mesmo tipo.
O ponto que mexe diretamente com a decisão de comprar é este: os encargos de mudança de fornecedor desaparecem por completo a partir de 12 de janeiro de 2027, incluindo os encargos de transferência de dados para fora da plataforma. Entre janeiro de 2024 e essa data vigora um regime transitório em que só podem ser cobrados os custos efetivamente incorridos. O capítulo sobre cláusulas contratuais abusivas acrescenta uma camada de proteção pensada em especial para empresas pequenas, contra condições impostas em regime de aceitar ou recusar.
Na prática, um dos argumentos históricos a favor de construir, o medo de ficar preso a um fornecedor que depois cobra caro pela saída, perdeu grande parte da força jurídica em serviços contratados no espaço europeu.
E há uma ironia que vale a pena conhecer antes de decidir. O regime tem um artigo que exclui destas obrigações os serviços cuja maioria das características principais tenha sido construída à medida das necessidades específicas de um cliente e que não sejam oferecidos em escala comercial alargada. Por outras palavras, encomendar um sistema feito à tua medida pode significar ficar de fora exatamente das proteções de saída que a lei criou para quem compra do catálogo. Este é um ponto que merece confirmação jurídica antes de sustentar uma decisão, mas a direção é clara e é o inverso da intuição comum.
A camada fiscal muda a conta mais do que esperas
Nenhuma comparação entre comprar e desenvolver está completa sem a leitura fiscal, e é aqui que se perdem quantias que ninguém contabilizou.
Uma assinatura é gasto do período a que respeita e reduz o lucro tributável desse período, independentemente do momento em que é paga. Desenvolvimento capitalizado não. Entra como ativo e recupera-se ao longo de vários anos, o que significa que o esforço de tesouraria é imediato mas o alívio fiscal é diferido, e essa diferença tem valor real quando a empresa está a crescer e precisa de liquidez.
O detalhe técnico interessa. Um esclarecimento técnico publicado pela APOTEC descreve o enquadramento com precisão: na tabela anexa ao Decreto Regulamentar 25/2009, os programas de computador aparecem com o código 2440 e uma taxa máxima de 33,33%. Como a taxa mínima fiscalmente aceite corresponde a metade da taxa máxima, o período de vida útil utilizável sem correções ao resultado vai de 3 a 6 anos.
A armadilha está no que acontece fora desse intervalo. As quotas mínimas de amortização que não sejam contabilizadas como gasto no período a que respeitam não podem ser deduzidas em nenhum outro período. Uma empresa que capitalize 350.000€ de desenvolvimento e decida amortizar em 10 anos, por prudência contabilística ou por vontade de suavizar o resultado, perde definitivamente uma parte da dedução. A escolha do prazo não é um pormenor de fecho de contas, é dinheiro, e vale ler com atenção como funcionam as regras de depreciação e amortização de ativos antes de assinar o que quer que seja.
No outro extremo, há empresas que desenvolvem alguma coisa boa e descobrem que podem licenciá-la a terceiros. Aí entra o regime que permite deduzir ao lucro tributável parte dos rendimentos de direitos de autor sobre programas de computador, um dos benefícios fiscais que a maioria das empresas não usa. E entra com uma condição que apanha quase toda a gente de surpresa.
A Autoridade Tributária pronunciou-se sobre isto numa ficha doutrinária relativa ao artigo 50.º-A do Código do IRC. O entendimento é que só cabem na norma os rendimentos que qualifiquem como royalties, ou seja, aqueles em que uma parte dos direitos sobre o programa é efetivamente transferida, ou em que o programa não é inteiramente estandardizado mas adaptado ao adquirente. Licenças de uso de programas estandardizados, em que o cliente recebe apenas os direitos necessários para utilizar o produto, são rendimentos comerciais e ficam de fora do benefício.
O contraste com o que a maioria das pessoas assume é grande. Vender muitas licenças iguais de um produto próprio não dá acesso ao regime. Licenciar tecnologia adaptada a cada cliente pode dar. Como todo o enquadramento fiscal muda com detalhes contratuais e depende de registo prévio dos direitos, isto exige validação com o contabilista certificado e com um fiscalista antes de contar com qualquer poupança.
Como fazer a conta a sério
O exercício seguinte usa premissas hipotéticas e declaradas, escolhidas para mostrar a forma da conta. Os teus números serão outros; a estrutura é a mesma.
Uma empresa com 12 utilizadores compara 2 propostas, com um horizonte de 5 anos.
Comprar. Assinatura de 45€ por utilizador por mês, com uma subida anual de preço de 5%, mais 7.000€ de implementação e integrações no primeiro ano. O total no horizonte é de 42.806€.
Desenvolver. Orçamento de 55.000€, alojamento e infraestrutura de 250€ por mês, e manutenção anual estimada em 20% do custo de construção a partir do segundo ano. Sem qualquer derrapagem, o total é de 114.000€.
Agora aplica-se a correção que a evidência sobre projetos de tecnologia recomenda. Ajustando o custo de construção pelo desvio médio de 27% encontrado na amostra de Oxford, e recalculando a manutenção sobre esse valor, o total sobe para 140.730€.
A diferença é de mais do triplo, e a decisão parece óbvia. Só que a conta tem uma variável que a inverte.
Se a mesma empresa tiver 60 utilizadores em vez de 12, mantendo todo o resto, o custo de comprar sobe para 186.030€ e passa a ser mais caro do que desenvolver. O ponto de cruzamento, com estas premissas, situa-se por volta dos 45 utilizadores. A resposta certa não depende da natureza do sistema, depende de quantas pessoas o vão usar e de quanto tempo o vais manter.
Daqui saem os elementos que qualquer comparação séria tem de conter:
Um horizonte explícito, nunca inferior a 5 anos, porque horizontes curtos favorecem artificialmente o desenvolvimento.
O número de utilizadores no fim do horizonte, e não o de hoje.
A manutenção como linha orçamental própria, com uma percentagem assumida e escrita.
Uma correção de derrapagem aplicada ao lado do desenvolvimento, com base em projetos comparáveis e não na estimativa de quem os vai executar.
O custo de saída de ambos os lados, incluindo migração de dados e período de sobreposição de sistemas.
O efeito fiscal do momento em que cada gasto é aceite.
É exatamente este tipo de decisão, entre automatizar, comprar ou construir dentro de portas, que se trabalha em detalhe na imersão CHECKMATE: Processos, onde a discussão deixa de ser sobre ferramentas e passa a ser sobre desenho de operação.
Os caminhos do meio que quase ninguém explora
A decisão é quase sempre apresentada como binária e quase nunca o é. Entre comprar tudo pronto e construir de raiz existe uma escala, e a maior parte das empresas fica melhor servida algures no meio dela.
Configurar. Usar a ferramenta como ela é, adaptando o processo em vez do produto. É a opção mais barata e a que mais gente rejeita por orgulho, não por análise.
Integrar. Manter várias ferramentas de catálogo e desenvolver apenas as ligações entre elas. O trabalho é pequeno, o valor é grande, e a dependência fica distribuída.
Estender. Comprar uma plataforma que exponha interfaces de programação e construir por cima aquilo que é específico do teu negócio. Ficas com a manutenção do núcleo entregue ao fornecedor e o controlo daquilo que te distingue.
Construir com ferramentas visuais. As plataformas de low-code permitem hoje resolver internamente aplicações que há alguns anos exigiam uma equipa. Trazem os seus próprios problemas de dependência, mas mudam o cálculo em projetos pequenos e médios.
Construir a sério. Reservado para o que é mesmo diferenciador, com equipa própria ou parceiro estável, documentação a sério e orçamento de manutenção aprovado à partida.
A regra prática que resulta disto é simples de enunciar e difícil de cumprir: compra o núcleo, constrói a orla. O núcleo é aquilo que qualquer empresa do teu setor precisa. A orla é aquilo que só tu fazes. Quase todas as histórias que acabam mal começaram por construir o núcleo.
Quando construir é mesmo a decisão certa
Há situações em que a análise aponta claramente para desenvolver, e ignorá-las por medo seria tão errado como construir por vaidade.
Constrói quando o processo é o produto. Se aquilo que vendes é o resultado de um método próprio, entregar esse método a uma ferramenta genérica é apagar a diferença que te sustenta.
Constrói quando o número de utilizadores torna o modelo de licença insustentável. O exercício acima mostra isso com clareza: acima de determinada dimensão, a assinatura deixa de ser a opção barata e passa a ser uma renda perpétua sobre o crescimento.
Constrói quando o mercado não te serve. Setores estreitos, com regras próprias ou volumes atípicos, ficam frequentemente sem oferta adequada, e forçar uma ferramenta genérica sai mais caro em trabalho manual do que sairia construir.
Constrói quando existe uma restrição real de dados ou de regulação que impede o recurso a um serviço externo. É menos comum do que se invoca, mas existe.
E constrói quando já tens a competência internamente e ela está subaproveitada. Uma equipa técnica que existe e que não tem trabalho suficiente muda a aritmética, porque o custo marginal deixa de ser o custo total.
Fora destes casos, a probabilidade de estares a construir por outra razão qualquer, geralmente a sensação de controlo, é elevada.
O contrato que resolve metade dos problemas futuros
Se a decisão for desenvolver com um parceiro externo, há cláusulas que custam pouco a negociar antes e custam muito a não ter depois. Nenhuma delas é exótica e todas são recusadas com regularidade por fornecedores que preferem a ambiguidade.
Fixa a titularidade por escrito e sem margem para interpretação: quem fica com o código, quem o pode alterar, quem pode contratar outra pessoa para lhe mexer. Deixar isto implícito é a origem da maioria das disputas nesta área.
Trata a documentação como entregável e não como cortesia, com um critério de aceitação verificável: uma pessoa competente que nunca viu o projeto consegue instalar e alterar o sistema apenas a partir dela.
Exige acesso ao repositório desde o primeiro dia, e não na entrega final, com o histórico completo de alterações. É a diferença entre acompanhar um projeto e receber uma caixa fechada.
Negoceia o depósito de código em custódia, o mecanismo habitualmente designado por escrow, para o cenário em que o fornecedor desaparece. Justifica-se sobretudo quando o sistema é crítico para a operação diária.
Garante a exportação de dados em formato aberto, sem custo e sem dependência da boa vontade de ninguém, e testa esse mecanismo pelo menos uma vez enquanto a relação ainda está boa.
Define as condições de saída e de transferência, incluindo a transmissão de conhecimento a quem vier a seguir, com prazo, âmbito e preço escritos no contrato.
Estas cláusulas são o equivalente contratual de um plano de contingência: escrevem hoje, com calma, o que acontece no dia em que a relação correr mal. E só se negoceiam bem antes de assinar.
Os sinais de que a decisão foi errada
Nenhuma escolha destas é irreversível, e reconhecer cedo um erro custa uma fração do que custa defendê-lo durante 3 anos. Os sintomas são diferentes conforme o lado.
Se compraste e a decisão foi errada, vais notar que a empresa mantém folhas de cálculo paralelas para fazer aquilo que a ferramenta não faz, que a fatura mensal cresce mais depressa do que a faturação, que passas mais tempo a contornar o sistema do que a usá-lo, e que pediste ao fornecedor a mesma funcionalidade 3 vezes sem resposta útil.
Se desenvolveste e a decisão foi errada, os sinais são outros. Cada alteração pequena demora semanas. Só uma pessoa consegue mexer no sistema sem partir alguma coisa. O sistema está parado há meses numa versão que ninguém quer atualizar por medo. Já existe no mercado uma alternativa melhor por uma fração do custo de manutenção que estás a suportar. E ninguém sabe dizer quanto é que o sistema custou realmente no último ano.
Em qualquer dos casos, a pergunta a fazer não é se a decisão original estava certa. É se, sabendo o que sabes hoje, voltarias a tomá-la. Quando a resposta é não, o custo já gasto é irrelevante para a decisão seguinte, por mais que doa.
O perigo desta decisão está na assimetria entre o que se vê e o que se paga. O lado da compra mostra o custo todos os meses, em fatura, num sítio onde é impossível esquecê-lo. O lado do desenvolvimento mostra um número na assinatura do contrato e esconde o resto em horas de pessoas que já lá estavam, em conhecimento que vive numa cabeça só, e num prazo que a investigação sobre previsão humana diz que nasceu curto sem que ninguém tenha mentido. Decidir bem, aqui, significa escrever a conta inteira antes de assinar: horizonte longo, manutenção como linha própria, o número de utilizadores que a empresa vai ter e não o que tem hoje, e uma correção de derrapagem que não veio de quem vai executar o trabalho. Feita assim, a resposta costuma aparecer sozinha, e na maior parte dos casos aponta para comprar quase tudo e construir muito pouco. Esse pouco é que faz a diferença, e é precisamente por isso que merece o dinheiro e a atenção que se estava a gastar no resto.
