Construir, configurar ou comprar: como decide um comitê com critérios claros

Há uma cena que se repete em muitos comitês. Alguém apresenta uma necessidade: um processo que hoje vive em planilhas, um portal que os clientes pedem, uma aprovação que se perde no e-mail. Três pessoas à mesa trazem, cada uma, uma resposta já formada. Tecnologia diz que se construa, porque «assim fica exatamente como precisamos». Finanças diz que se compre um produto, porque «é mais barato e já existe». Operações diz que se configure o que já se tem, porque «para que gastar mais».

As três respostas podem estar certas. Nenhuma está por padrão. O erro mais caro dessa decisão raramente é escolher o caminho errado entre três razoáveis: é escolher sem ter posto sobre a mesa os critérios que distinguem um caminho do outro, e assinar um contrato sem saber o que realmente se está comprando.

Este artigo é para quem responde por essa decisão: direção-geral, finanças e tecnologia em uma empresa de médio ou grande porte. Não é um guia técnico nem uma comparação de marcas. Propõe seis critérios para decidir, uma tabela para levar ao comitê, as perguntas que convém fazer antes de assinar um desenvolvimento sob medida e uma explicação honesta de por que tantos sistemas feitos sob medida acabam em resgate.

Os três caminhos, nas palavras do comitê

Antes de comparar, convém que todos falem da mesma coisa.

Configurar o que já se tem. O ERP, o CRM, a plataforma de fluxos ou o core da empresa já trazem capacidades que talvez não sejam usadas, ou sejam usadas pela metade. Configurar é ajustar parâmetros, regras, formulários e relatórios dentro do que o fabricante suporta. Não se escreve código novo, ou se escreve muito pouco, e o sistema continua sendo o do fabricante.

Comprar um produto. Adquire-se uma solução já construída para um problema que muitas empresas compartilham: faturamento, folha de pagamento, administração de apólices, conciliação. Paga-se uma licença ou uma assinatura, adapta-se à operação por meio de configuração e aceita-se que algumas coisas serão feitas à maneira do produto. Aqui «comprar» inclui tanto o pacote tradicional quanto o serviço em nuvem.

Construir sob medida. Desenvolve-se um sistema para o processo particular da empresa. Há código próprio, decisões próprias e, se o contrato estiver bem feito, titularidade própria. Também há responsabilidade própria sobre o que se construiu: alguém precisa mantê-lo, testá-lo e alterá-lo.

Existe um quarto caminho, que convém mencionar para que não entre sem nome: combinar. Muitas vezes a resposta correta é um produto para a parte que se parece com a de outras empresas e uma peça sob medida para a parte que distingue a da empresa. Os três caminhos não são excludentes; o que muda é onde se traça a linha.

Seis critérios para decidir

1. Quanto o processo diferencia

Esta é a pergunta de fundo. Se a maneira como a empresa faz algo é parte do motivo pelo qual os clientes a escolhem ou pelo qual as margens dela são diferentes, esse processo merece atenção própria. Se é um processo que qualquer empresa do ramo faz igual (fechar a contabilidade, emitir um comprovante fiscal, pagar a folha), construí-lo raramente constrói vantagem.

Um teste útil para o comitê: um concorrente poderia comprar amanhã o mesmo produto e operar igual a nós? Se a resposta é sim, provavelmente não vale a pena construí-lo. Se a resposta é não, e essa diferença é justamente o que se quer proteger ou escalar, então construir, ou pelo menos construir a parte que diferencia, merece estar na mesa.

O teste tem um reverso que se esquece: nem tudo o que a empresa acredita que a distingue a distingue de verdade. Com frequência o «único» é um hábito acumulado ao longo de anos, não uma vantagem. Antes de pagar para reproduzir um hábito, convém perguntar se o cliente notaria a ausência dele.

2. Quanta urgência há e o que custa esperar

Um produto que já existe pode ser colocado para operar em menos tempo do que um que ainda vai ser projetado, mas «menos tempo» não é «pouco tempo»: é preciso configurá-lo, migrar dados, treinar e conectá-lo. Uma configuração dentro do que já se tem costuma ser a mais rápida das três. Um desenvolvimento sob medida é, em geral, o que mais demora a dar o primeiro resultado, a menos que seja entregue por partes e a primeira parte seja útil por si só.

A urgência deve ser expressa em dinheiro ou em risco, não em ansiedade: que receita é adiada, que sanção se aproxima, que cliente se perde a cada mês de espera. Com essa cifra o comitê pode comparar o custo de esperar com o custo de cada caminho. Sem ela, a urgência costuma acabar decidindo pelo caminho que parece mais rápido na apresentação, que muitas vezes não é o que chega mais rápido.

3. Quanta integração exige

Aqui muitos comitês se enganam, porque olham a tela e não as conexões. Um sistema novo raramente opera sozinho: lê e escreve no ERP, recebe dados dos canais, entrega informação à contabilidade, responde a uma autoridade. O trabalho de integração costuma ser a parte menos visível do projeto e a que mais surpreende.

Cada caminho o enfrenta de maneira diferente. Um produto traz conectores para os sistemas mais comuns, e a pergunta é se os da empresa estão entre eles e a que custo. Configurar dentro do que já se tem reduz o número de conexões novas, porque o sistema já está conectado. Construir sob medida dá liberdade para conectar o que for preciso, mas cada conexão é trabalho que se paga, se testa e se mantém; e o fabricante do sistema ao qual se conecta pode mudar as regras dele.

Uma pergunta concreta para levar a qualquer fornecedor, seja de produto ou de desenvolvimento: com quais sistemas da empresa ele se conecta, por qual interface suportada pelo fabricante e quem responde quando uma das duas partes muda?

4. Quem vai mantê-lo

Um sistema não termina no dia em que é entregue. A partir dali é preciso corrigir falhas, adaptar-se a mudanças de regulação, atualizar componentes que deixam de receber suporte e atender os pedidos do negócio. Esta é a parte do custo que menos aparece nas propostas, e a que mais pesa ao cabo de alguns anos.

Em um produto, a manutenção da base é feita pelo fabricante, e a empresa paga por isso. Em uma configuração, é feita pelo fabricante da plataforma, mais quem tiver feito os ajustes. Em um desenvolvimento sob medida, é feita por quem a empresa decidir, e aí está a pergunta de fundo: essa pessoa ou equipe existe, tem a documentação necessária e consegue se sustentar no tempo? Um sistema que depende da memória de quem o programou é um risco disfarçado de ativo.

5. Custo total, não preço de entrada

A comparação mais frequente em um comitê é entre o preço do produto e o orçamento do desenvolvimento. É uma comparação incompleta. Para decidir, o custo deve ser visto ao longo de vários anos e com todas as linhas:

• Aquisição: licenças ou assinatura em um produto; horas ou preço do projeto em um desenvolvimento.
• Implementação: configuração, migração de dados, integração, testes e treinamento. Em um produto, convém pedir separadamente e por escrito licenças, configuração, migração, integração, testes e treinamento.
• Operação: infraestrutura, suporte, monitoramento e as pessoas dedicadas a atendê-lo.
• Mudança: o que custa adaptar o sistema quando o negócio muda. Em um produto, costuma depender do fabricante e do calendário dele; em um sob medida, depende da capacidade de manutenção.
• Saída: o que custaria deixar o sistema e levar os dados e as regras para outro lugar.

Nenhum dos três caminhos vence em todos os casos nessa análise. Um produto pode sair mais barato em cinco anos e mais caro em dez se o negócio se afasta do que o produto pressupõe. Um desenvolvimento pode sair mais caro no início e mais barato se o que se construiu evita pagar licenças por usuário que crescem com a empresa. O importante é que a conta exista, que seja do comitê e não de quem vende, e que seja feita com as linhas acima.

6. A saída do fornecedor

É o critério que quase ninguém põe na planilha no dia da decisão e que mais se lamenta depois. Cada caminho cria uma dependência diferente, e convém nomeá-la.

Com um produto, a dependência é do fabricante: do preço, do calendário de versões e da permanência dele. A pergunta é o que acontece com os dados e as regras se amanhã se quiser trocar de produto: podem ser exportados, em que formato, com que documentação?

Com uma configuração, a dependência é dupla: do fabricante da plataforma e de quem fez os ajustes. As regras de negócio ficam dentro da ferramenta; se não estiverem documentadas fora dela, tornam-se difíceis de reproduzir.

Com um desenvolvimento sob medida, a dependência é de quem o construiu, e se reduz ou se agrava conforme o que o contrato disser. Código no repositório da empresa, documentação, testes, acessos e um repasse verificável reduzem a dependência e viabilizam avaliar a passagem para outra equipe. Sem eles, o fornecedor original tende a se tornar imprescindível. A seção seguinte trata disso.

A tabela para levar ao comitê

A tabela a seguir resume como se comporta cada caminho diante dos seis critérios. É um guia de raciocínio, não uma medição: os valores descrevem tendências, e o caso concreto pode se afastar delas.

Duas observações sobre como usá-la. Primeira: não conte quantas células «favorecem» cada coluna; os critérios não pesam igual para todas as empresas. Um comitê com uma urgência regulatória pode dar ao segundo critério um peso que outro comitê não daria. Segunda: a tabela serve sobretudo para descobrir desacordos. Se dois membros do comitê avaliam uma célula de modo diferente, ali está a conversa que vale a pena ter antes de contratar quem quer que seja.

Cenário (ilustrativo, sem cliente). Uma distribuidora de médio porte, com operação em vários estados, quer substituir o processo pelo qual os executivos de conta dela autorizam descontos especiais, que hoje se resolve por e-mail e uma planilha compartilhada. O comitê avalia os seis critérios. O processo de autorização tem regras próprias que variam por cliente e por produto, e o negócio as considera parte da maneira de vender da empresa: diferenciação alta. A urgência é moderada: há perdas, mas nenhum prazo-limite. A integração exige ler preços e estoques do ERP e escrever a aprovação de volta: duas conexões. A manutenção seria responsabilidade de uma equipe interna pequena. Ao somar os custos em cinco anos, um produto de fluxos de aprovação genérico sai mais barato em licenças, mas obrigaria a programar justamente as regras que diferenciam a empresa, dentro de uma ferramenta alheia. Um desenvolvimento completo sai mais caro, mas concentra o esforço nessas regras. O comitê decide combinar: um produto de fluxos para o percurso da solicitação e uma peça sob medida para o cálculo de qual desconto pode ser autorizado, com o código e a documentação dessa peça em nome da empresa. As cifras do cenário são omitidas de propósito: o que importa é a ordem das perguntas, não os números.

O que perguntar antes de assinar um desenvolvimento sob medida

Se o comitê chega à conclusão de que convém construir, ou construir uma parte, o contrato passa a ser o instrumento que determina se a empresa termina com um ativo ou com uma dependência. Quatro blocos de perguntas organizam essa revisão. Todas devem ter resposta por escrito antes de assinar.

De quem é o código

A pergunta parece óbvia e é a que mais gera mal-entendidos. Quem paga por um sistema costuma dar por certo que lhe pertence. A Ley Federal del Derecho de Autor (LFDA, a lei federal mexicana de direitos autorais) estabelece regras específicas, e convém conhecê-las. O que segue é uma leitura do texto vigente dela no site da Cámara de Diputados (a câmara de deputados mexicana); não substitui o parecer da área jurídica da empresa.

• Os programas de computador são protegidos nos mesmos termos que as obras literárias, tanto em código-fonte quanto em código-objeto (art. 102).
• Toda transmissão de direitos patrimoniais é onerosa e temporária, e os contratos pelos quais se transmitem, assim como as licenças de uso, devem ser celebrados por escrito; do contrário, a lei os declara nulos de pleno direito (art. 30).
• O artigo 33 prevê um prazo de cinco anos quando a transmissão não o fixa; para os programas de computador, o artigo 103 exceta expressamente essa limitação. A redação da cessão e o alcance dela devem ser revisados com a área jurídica.
• Em uma obra por encomenda, o artigo 83 estabelece, salvo pacto em contrário, uma regra a favor de quem a encomenda. Para que uma obra seja considerada realizada por encomenda, o artigo 83 bis exige que os termos do contrato sejam claros e precisos, e na dúvida prevalece a interpretação mais favorável ao autor.
• Os direitos patrimoniais sobre um programa criado por empregados no exercício das funções correspondem, salvo pacto em contrário, ao empregador (art. 103, primeiro parágrafo). Se quem desenvolve o programa são empregados do fornecedor e atuam no exercício das funções, esses direitos nascem no fornecedor; se intervêm subcontratados ou prestadores independentes, convém verificar por escrito a cadeia de titularidade. O que chega à empresa chega pelo que o contrato disser.

A conclusão prática não é que a lei tire o código da empresa; é que convém deixar a titularidade por escrito, com palavras explícitas. Perguntas para o contrato:

1. Quem é o titular dos direitos patrimoniais sobre o sistema entregue e a documentação dele, e isso está escrito?
2. A transmissão é cessão de direitos ou licença de uso, exclusiva ou não exclusiva? São coisas distintas, com consequências distintas.
3. O que acontece com as ferramentas, bibliotecas e componentes próprios do fornecedor que são reutilizados no projeto? É frequente que o fornecedor conserve os dele e conceda uma licença de uso; então convém saber se essa licença é perpétua, se é transferível e se permite que outra equipe mantenha o sistema.
4. Há prazo, território e condições da transmissão, e ficam inscritos onde a lei prevê para produzirem efeitos perante terceiros (art. 32)? Esta é uma consulta para o advogado, não uma afirmação geral.

Licenças de terceiros

Quase nenhum sistema moderno é escrito do zero: é montado com componentes de código aberto, bibliotecas comerciais, serviços em nuvem e ferramentas de desenvolvimento. Cada um tem licença própria, e cada componente pode impor condições distintas. O contrato deve identificar quais se aplicam a cada componente e ao uso concreto que a empresa fará do sistema.

Perguntas para o contrato:

1. Existe uma lista de todos os componentes de terceiros, com a licença e a versão de cada um? Peça-a como entregável.
2. Alguma licença limita como a empresa pode operar, modificar ou distribuir o sistema?
3. Quais componentes têm custo recorrente (assinaturas, serviços em nuvem, chaves) e em nome de quem estão contratados? Se estão em nome do fornecedor, no dia em que a relação terminar o sistema pode deixar de funcionar.
4. Quem responde se um componente deixa de receber suporte ou surge uma falha de segurança nele?

Critérios de aceite

«Entregar o sistema» não é uma data, é uma condição. Se a condição não está escrita, a entrega é negociada no final, quando o orçamento está gasto e a pressão é máxima, e a parte que mais perde é a que tem menos margem para esperar.

Perguntas para o contrato:

1. O que o sistema deve poder fazer para ser aceito, expresso em situações que a empresa possa observar e repetir? «Que funcione bem» não é um critério; «que uma solicitação com estas características seja aprovada neste percurso e fique registrada com quem, quando e por quê» é.
2. Quem executa os testes de aceite, em que ambiente e com quais dados? Convém que participe alguém que não construiu o sistema.
3. O que ocorre com os defeitos encontrados depois de aceitar, e por quanto tempo o fornecedor os corrige sem custo?
4. São entregues testes automáticos junto com o código? São eles que permitem mudar o sistema depois sem apostar.
5. Os pagamentos estão ligados a partes entregues e aceitas, e não apenas à passagem do tempo?

Repasse

O dia da entrega é quando o conhecimento do sistema está concentrado em quem o fez. O repasse é o processo pelo qual esse conhecimento passa a quem vai operá-lo.

Perguntas para o contrato:

1. O que é entregue além do programa: código-fonte no repositório da empresa, documentação de como está montado e como se instala, instruções de operação e de recuperação diante de falhas?
2. Quem receberá o repasse do lado da empresa, está identificado e tem tempo para isso? Um repasse a «a equipe de TI» sem nomes costuma ficar em uma apresentação.
3. É possível reconstruir o sistema do zero a partir do que foi entregue, e alguém alheio ao fornecedor comprovou? Esta é uma das provas mais reveladoras que existem sobre se houve um repasse de verdade.
4. Que suporte há durante um período posterior e sob que condições, e o que acontece se a empresa preferir que outra equipe o mantenha?

As respostas claras permitem detectar os temas que o contrato deve resolver; a suficiência das cláusulas deve ser validada pela área jurídica antes de assinar. Se alguma resposta se torna vaga, essa vagueza é um dado e convém tratá-la como tal.

Por que tantos sistemas sob medida acabam em resgate

«Resgate» é a palavra usada quando uma empresa tem um sistema que opera, que ninguém quer tocar e que já não consegue evoluir no ritmo do negócio. Nem todos começaram mal. As causas se acumulam, e várias são visíveis desde a assinatura.

Primeira causa: o tamanho e a duração elevam o risco mais rápido do que se supõe. Há evidência empírica sobre isso. Bent Flyvbjerg e Alexander Budzier analisaram 1.471 projetos de TI e constataram que o estouro médio de custo foi de cerca de 27 %; mas essa média esconde uma cauda: cerca de um em cada seis projetos teve um estouro médio de 200 % e um atraso de quase 70 % [1]. Um estudo posterior, com uma amostra de 5.392 projetos de TI, constatou que os estouros seguem uma distribuição de lei de potência: muitos projetos com desvios pequenos e uma cauda de projetos com desvios extremos, de modo que os projetos de TI são «muito mais arriscados em custo do que normalmente supõem os decisores» [2]. Os autores propõem como explicação possível a interdependência entre componentes: um problema em um pode desencadear reações em outros [2].

O que isso significa para um comitê: a pergunta correta não é «quanto vai se desviar em média», mas «o que acontece se cairmos na cauda». Um orçamento que só resiste ao caso médio não é um orçamento prudente. Essas cifras são de alta confiança quanto à origem (revisadas na fonte), mas descrevem amostras de projetos de TI em geral, não unicamente desenvolvimentos sob medida; não devem ser lidas como a probabilidade de o projeto da empresa falhar.

Segunda causa: o fracasso é medido mal e citado pior. É comum ver em apresentações de venda percentuais de fracasso de projetos de software atribuídos ao relatório CHAOS do Standish Group. Convém saber que essas cifras foram questionadas com método. Eveleens e Verhoef, na IEEE Software (2010), sustentam que as definições de sucesso do Standish se baseiam unicamente na exatidão da estimativa de custo, tempo e funcionalidade; que essa medida é unilateral e infla os percentuais de projetos «fracassados»; e que calcular a média de cifras produzidas por processos de estimativa distintos, cada um com um viés desconhecido, torna os resultados desprovidos de significado. Ao aplicar essas definições aos próprios dados (5.457 previsões de 1.211 projetos reais), concluíram que as cifras do Standish não refletiam a realidade dos casos estudados [3]. Por isso este artigo não cita percentuais do CHAOS como dado. Se alguém os apresentar em uma proposta, pergunte pela fonte e pela definição de fracasso que ela usa. A ressalva vale nas duas direções: tampouco há base para afirmar que todos os projetos dão certo.

O que permanece de pé, com as duas fontes anteriores, é uma conclusão prudente: o risco existe, é assimétrico e é subestimado quando se julga pelo caso típico.

Terceira causa: compra-se uma tela e não um ativo. Muitos sistemas sob medida são contratados pelo que se vê: as telas, o fluxo. O que não se vê (os testes, a documentação, o repositório, a lista de componentes de terceiros) é o que decide se o sistema pode evoluir. Quando esses entregáveis não foram pedidos, o sistema funciona no dia da entrega e se torna ingovernável na primeira mudança importante. Esta é a causa mais evitável de todas, e as quatro séries de perguntas da seção anterior existem para isso.

Quarta causa: o sistema depende de uma pessoa. Um programador que conhece todo o sistema é uma força enquanto está e um risco quando sai. É a razão pela qual a documentação e o repasse devem pesar no contrato tanto quanto as funções.

Quinta causa: construiu-se o que já existia. Com frequência, uma parte do sistema reproduz capacidades que um produto ofereceria a menor custo de manutenção. Quando essa parte requer mudanças constantes por regulação ou por padrões, a empresa acaba sustentando, com o orçamento próprio, o que um fabricante sustenta para milhares de clientes. O critério de diferenciação da primeira seção existe para evitar isso.

Sexta causa: não há um critério de saída. Nenhum sistema dura indefinidamente. Se o contrato não previu como extrair os dados e as regras, substituí-lo é outro projeto de alto risco. Um sistema que não pode ser abandonado acaba sendo conservado por inércia, o que o converte em uma versão lenta de um resgate.

Nenhuma dessas causas é inevitável nem exclusiva dos desenvolvimentos sob medida: os produtos têm as próprias versões (adaptar o negócio ao produto sem perceber, por exemplo). A diferença é que em um desenvolvimento sob medida várias dessas causas podem ser reduzidas com decisões tomadas antes de assinar e com acompanhamento durante a execução, que é o motivo deste artigo.

Como levá-lo ao comitê: uma folha, cinco perguntas

Para que esta conversa não fique no geral, propomos uma folha de uma página que qualquer comitê pode montar em uma tarde:

1. Que processo é, e quanto o distingue? Com o teste do concorrente que poderia comprar o mesmo produto.
2. O que custa esperar? Em dinheiro ou em risco, por mês.
3. Com quais sistemas se conecta e por qual interface? Uma lista, não uma frase.
4. Quem o manterá daqui a três anos? Com nome ou com perfil, e com a documentação dele.
5. Como saímos? O que a empresa leva, em que formato e em nome de quem fica.

Se o comitê não consegue responder a alguma das cinco, esse vazio é o primeiro entregável, antes de qualquer proposta. E se várias respostas são «não sabemos», provavelmente não falta um fornecedor: falta informação para decidir.

O que a Hábil faz

A Hábil ajuda organizações a ordenar essa decisão antes de se comprometerem com um caminho: o que convém configurar, o que convém resolver com um produto e o que de fato vale a pena construir. Essa é a ideia da página Desenvolvimento sob medida, onde se explica como o escopo é acordado, o que é entregue e em nome de quem fica.

Se uma parte do que a empresa precisa se parece com o que fazem outras empresas, convém revisar o escopo, as condições e as integrações aplicáveis dos nossos produtos: Retícula, Pauta e Cuadre. O que um deles cobre se configura em vez de ser programado, e um projeto sob medida pode se concentrar no que de fato é só da empresa.

Se o comitê já identificou o processo, as integrações e os critérios de saída, pode confrontar o caso com a Hábil em uma primeira conversa, sem custo. Escreva para nós pelo WhatsApp para pedi-la.