7 erros das PME ao comprar software à medida

A maioria das pequenas empresas que se queima num projeto de software à medida não se queima por causa de maus programadores. Queima-se semanas antes de começar qualquer programação: numa reunião de arranque, numa troca de e-mails, num aperto de mão, por uma decisão que na altura parecia pequena. Quando o código chega, o erro já está cozinhado lá dentro. A boa notícia é que estes erros se repetem de forma aborrecidamente previsível, o que significa que são evitáveis se souber reconhecê-los.

Vi muitos destes projetos por dentro, dos dois lados da mesa. Alguns tornaram-se ferramentas sem as quais uma empresa já não se imaginava a trabalhar. Outros acabaram num ecrã de início de sessão a meio, numa disputa tensa sobre uma fatura e num fundador a jurar que nunca mais arrisca em algo à medida. O frustrante é o pouco que separava os dois desfechos. A tecnologia raramente era o problema. As decisões em torno da tecnologia quase sempre eram.

Eis então os sete erros que vejo repetidamente quando uma pequena empresa encomenda software à medida. Nenhum exige formação técnica para ser evitado. Basta saber que existem antes de assinar seja o que for.

Erro 1: comprar uma solução antes de entender o problema

O erro mais caro acontece primeiro, e soa inofensivo: «Precisamos de uma aplicação que faça X.» Quando alguém diz isto em voz alta, já decidiu quase sempre a forma da solução — um painel, um portal, uma aplicação móvel — sem que ninguém tenha escrito o verdadeiro problema em linguagem simples. O desenvolvimento entrega então fielmente a coisa errada, e bem acabada.

Bom software parte de um enunciado do problema, não de uma lista de funcionalidades. «A nossa equipa de escritório volta a digitar cada encomenda dos e-mails no sistema de contabilidade, e isso ocupa duas pessoas meio dia» é um problema. «Precisamos de um CRM à medida» é um palpite sobre uma solução para um problema que ninguém se deu ao trabalho de nomear. O primeiro pode resolver-se de forma barata e medir-se. O segundo é um convite aberto a gastar dinheiro.

Erro 2: tentar construir tudo de uma vez

O software à medida parece uma compra que se faz uma vez por década, por isso tenta-se enfiar uma década de desejos na versão um. Cada departamento acrescenta um pedido. A cada «já que estamos com isto» dá-se um sim. O âmbito incha, o prazo triplica, e o projeto desmorona sob a própria ambição muito antes de alguém o conseguir usar.

As empresas que têm sucesso fazem o contrário. Escolhem a fatia mais dolorosa do problema e constroem essa primeiro: uma coisa real, a funcionar, em produção dentro de um par de meses. Depois deixam o uso real dizer-lhes o que vem a seguir. Isto não é apenas mais barato; é mais seguro. Aprende se a ideia funciona enquanto a aposta ainda é pequena, em vez de descobrir, ao fim de seis meses e uma fatura pesada, que desenhou a coisa errada.

Por baixo disto está uma verdade dura: ainda não sabe verdadeiramente do que precisa. Ninguém sabe, no início. A sua compreensão do problema vai mudar no momento em que pessoas reais tocarem numa ferramenta real. Construir tudo à partida fixa os seus palpites mais precoces e menos informados. Construir por fatias mantém-no flexível, e mantém o orçamento sob controlo enquanto ainda está a aprender.

Erro 3: escolher apenas pelo preço

Pede três orçamentos. Um é drasticamente mais barato do que os outros. Alívio: fica com esse. Esta é uma das formas mais fiáveis de transformar um projeto pequeno num caro, porque o orçamento barato quase nunca significa que o trabalho é mais barato. Costuma significar que os dois lados entenderam a tarefa de forma diferente.

Um número baixo sinaliza muitas vezes uma de várias coisas: o fornecedor subestimou o âmbito porque não fez perguntas suficientes, planeia obter a sua margem mais tarde com pedidos de alteração, ou é inexperiente e ainda não sabe o que não sabe. Nenhuma acaba bem para si. O preço de capa é o número menos útil da proposta. O que importa é se o fornecedor compreende claramente o seu problema, faz perguntas incómodas e é honesto sobre o que não está incluído.

Erro 4: esquecer que o software não é uma compra única

O software à medida é muitas vezes apresentado, e comprado, como uma peça de mobiliário: paga-se uma vez, é-se dono para sempre. Não é assim. O software vive num mundo em movimento: os sistemas operativos atualizam-se, os navegadores mudam, chegam correções de segurança, o seu negócio transforma-se, as ferramentas a que se liga mudam as suas regras. Uma ferramenta que ninguém mantém vai deixando de funcionar e depois parte-se no pior momento possível.

Isto atinge duramente as pequenas empresas porque o custo de manutenção é invisível na assinatura. Compara dois orçamentos pelo preço de construção e nunca faz a pergunta que mais importa: quanto custa manter isto vivo e saudável todos os anos? Alojamento, atualizações, pequenas correções, a alteração ocasional à medida que o negócio evolui: planeie-o como uma rubrica normal e contínua, tal como faz com o seguro ou a contabilidade. Costuma ser modesto, mas só se contar com isso.

Erro 5: deixar os requisitos vagos e sem responsável

«Vocês são os especialistas, construam algo bom» soa generoso. Na verdade, é assim que os projetos derivam. As pessoas que melhor compreendem o seu negócio são você e a sua equipa, não os programadores. Se entrega um briefing difuso e desaparece, o fornecedor preenche as lacunas com os seus melhores palpites, e vai descobrir esses palpites no pior momento: na entrega, quando alterá-los custa mais caro.

Dois papéis têm de ser preenchidos do seu lado, e as pequenas empresas costumam não preencher nenhum. O primeiro é um único decisor: uma pessoa que pode dizer sim, resolver desacordos entre departamentos e não está demasiado ocupada para responder a perguntas durante semanas. O segundo é a disposição para ser específico naquilo que importa: os casos-limite, a exceção estranha que o seu negócio sempre tratou à mão, a regra que todos conhecem mas ninguém escreveu. É exatamente isso que o software tem de acertar.

Erro 6: não perguntar de quem são o código e os dados

Este é o silencioso, e é o que mais dói anos depois. Paga por software à medida e parte do princípio de que é seu. Depois a relação com o fornecedor azeda, ou ele sobe os preços, ou simplesmente desaparece, e descobre que não se consegue mexer. Não tem o código-fonte. Os dados vivem num sistema a que só ele acede. Toda a sua operação depende agora de uma empresa em que já não confia, e não tem qualquer alavanca.

Nada disto exige um advogado para ser evitado. Exige três perguntas simples feitas antes de começar, enquanto ainda tem todo o poder negocial: De quem é o código-fonte quando isto estiver terminado? Posso exportar todos os meus dados, num formato utilizável, sempre que quiser? E se nos separarmos, com o que fico exatamente? Um parceiro sério responde a isto sem pestanejar. Hesitar aqui é o maior sinal de alarme de todo o processo.

• Obtenha por escrito que o código-fonte é seu, ou que tem uma licença clara e justa sobre ele.
• Confirme que pode exportar os seus próprios dados num formato padrão, quando quiser, sem pedir autorização.
• Garanta que o trabalho está documentado o suficiente para outro programador o poder retomar.
• Evite a dependência de tecnologia proprietária onde uma tecnologia simples e conhecida faria o mesmo trabalho.
• Acorde à partida o que acontece ao alojamento e às contas se algum dia mudar de fornecedor.

Erro 7: tratar o lançamento como a meta

O software é entregue, funciona, todos respiram de alívio. O projeto é dado como concluído. Seis meses depois, metade da equipa voltou em silêncio à velha folha de cálculo, e a cara ferramenta nova é usada por duas pessoas para uma só coisa. A construção teve sucesso. A adoção falhou, e são dois problemas completamente distintos.

As pessoas não resistem a ferramentas novas por serem tolas ou teimosas. Resistem porque o novo é desconhecido e o velho ainda funciona, mais ou menos. Vencer isso exige um esforço deliberado que ninguém orçamentou: alguma formação, uma razão clara de por que a mudança ajuda a elas em particular, alguém que responda às perguntas tolas sem julgar nas primeiras semanas, e uma decisão firme de reformar o velho para que não haja um refúgio para onde escorregar.

1. 1
   Lance primeiro a um grupo pequeno

   Disponibilize a ferramenta a algumas pessoas dispostas antes de toda a equipa. Vão encontrar as arestas e tornar-se os seus defensores internos.
2. 2
   Mostre o ganho pessoal, não o da empresa

   «Isto poupa dinheiro ao negócio» não motiva ninguém. «Isto significa que deixa de digitar moradas duas vezes» traz as pessoas para o seu lado.
3. 3
   Nomeie uma pessoa de referência para as dúvidas

   No primeiro mês, alguém fica responsável pelas perguntas tolas. O atrito na primeira semana é o que mata a adoção para sempre.
4. 4
   Desligue mesmo o velho

   Enquanto a velha folha de cálculo existir, as pessoas continuarão a usá-la. Quando o novo funcionar, retire o refúgio: com suavidade, mas com clareza.

Juntar tudo: a mentalidade do comprador

Releia esses sete pontos e um fio comum atravessa-os. Quase nenhum é técnico. Falam de clareza, propriedade e contenção: conhecer o seu problema antes de comprar, construir em pequenos passos, julgar os fornecedores pela compreensão e não pelo preço, planear para a vida da ferramenta e não só para o seu nascimento, manter-se envolvido, proteger a sua saída e tratar o lançamento como o início do trabalho a sério.

O software à medida é, de facto, um dos melhores investimentos que uma pequena empresa pode fazer assim que ultrapassa as ferramentas-padrão que toda a gente partilha. Um sistema moldado exatamente à volta da forma como você trabalha, em vez de forçar o seu negócio a contorcer-se em torno do produto de outra pessoa, é uma vantagem real e duradoura. As empresas que lá chegam não são as de maiores orçamentos. São as que evitaram os sete erros acima, e isso é uma questão de discernimento, não de dinheiro.

Perguntas frequentes