Empresas de TI: como avaliar e contratar

Empresas de TI é um guarda-chuva que cobre quatro negócios bem diferentes: quem desenvolve software, quem sustenta infraestrutura, quem revende e implanta sistemas de terceiros e quem presta consultoria. Contratar bem começa em saber qual dos quatro resolve o seu problema, porque o mesmo briefing entregue aos quatro volta com quatro propostas incomparáveis.

Este texto é para quem vai contratar e não quer decidir por indicação solta nem por preço. Ele separa os tipos de fornecedor, lista os critérios que de fato preveem se o projeto vai terminar, mostra como ler uma proposta sem ser especialista e aponta os sinais que antecedem os contratos que dão errado.

Os quatro tipos de empresa de TI

A confusão começa no nome. Quatro modelos de negócio muito distintos se apresentam como empresa de TI, e cada um resolve uma classe de problema:

• Desenvolvimento de software. Constrói o que não existe pronto: sistema interno, produto digital, integração sob medida. Cobra por time ou por escopo, e o risco é de escopo, não de operação.
• Infraestrutura e suporte. Mantém o que já roda: rede, servidores, backup, estações, help desk. Cobra por contrato mensal com nível de serviço, e o risco é de disponibilidade.
• Revenda e implantação. Vende licença de um software de terceiro e faz a implantação. A receita principal costuma vir da licença, e isso precisa ser sabido antes de pedir uma recomendação de ferramenta.
• Consultoria. Decide o que fazer antes de alguém fazer. Diagnóstico, arquitetura, escolha entre construir e comprar, plano. Cobra por tempo de especialista e o entregável é decisão, não código. É o recorte de consultoria de tecnologia.

Muita empresa faz mais de um, e não há problema nisso. O problema é contratar um tipo esperando o outro: pedir arquitetura a quem fatura por hora de desenvolvimento, ou pedir recomendação neutra de ferramenta a quem ganha comissão da licença. O panorama do que esse mercado entrega está em quais serviços de TI são mais procurados pelas empresas.

Por que “a melhor empresa” é a pergunta errada

Não existe ranking útil de empresas de TI, e listas de melhores servem para conhecer nomes, não para decidir. A razão é estrutural: o que faz um fornecedor ser excelente para uma empresa é exatamente o que o torna inadequado para outra.

Uma casa de 200 pessoas com processo maduro entrega previsibilidade e cobra por ela; para um projeto de três meses com escopo em aberto, essa mesma previsibilidade vira lentidão e custo. Um time de seis pessoas entrega velocidade e proximidade; para um sistema que precisa de plantão 24 horas, essa mesma estrutura vira risco. Se quiser uma visão do mercado antes de entrar nos critérios, ela está em melhores empresas de tecnologia da informação, mas a decisão não sai de lá.

A pergunta que decide é outra: qual fornecedor é o certo para este problema, neste prazo, com esta equipe interna do lado de cá. As três variáveis mudam a resposta, e a terceira é a mais esquecida.

Os sete critérios que preveem o resultado

Depois de um número razoável de contratações observadas, os sinais que se repetem nos projetos que terminam bem são estes:

1. Experiência no seu tipo de problema, não no seu setor. Quem já integrou ERP com e-commerce resolve o seu caso mesmo vindo de outro segmento. Conhecer o setor ajuda na conversa; conhecer o problema entrega o projeto.
2. Quem vai trabalhar, nominalmente. Peça os nomes e o tempo de casa de quem ficará no projeto. Proposta que apresenta o sócio e entrega um time que você nunca viu é o padrão mais comum de frustração.
3. Como eles lidam com mudança de escopo. Escopo muda sempre. O que diferencia é ter um processo declarado para isso, com impacto de prazo e custo estimado antes da decisão, em vez de discussão depois do fato.
4. O que acontece quando o projeto acaba. Código, credenciais, documentação e acesso são seus. Contrato que não diz isso com clareza é dependência desenhada.
5. Capacidade de dizer não. Fornecedor que concorda com tudo na reunião comercial concorda porque ainda não pensou. O que questiona o pedido, propõe um recorte menor ou avisa que algo vai custar caro está fazendo o trabalho.
6. Referências que você mesmo escolhe. Peça três clientes, e converse com um que você escolheu da lista, não o indicado. Pergunte o que deu errado, porque em todo projeto algo deu.
7. Quanto do seu tempo eles vão consumir. Todo projeto exige participação interna. Fornecedor que promete autonomia total está subestimando o projeto ou planejando decidir sem você.

Repare que nenhum dos sete é tecnologia específica. Linguagem, nuvem e framework aparecem na proposta e quase nunca são o que faz o projeto falhar.

Como ler uma proposta sem ser técnico

Três leituras dizem quase tudo, e nenhuma exige domínio técnico.

A primeira é a granularidade. Uma proposta com três linhas e um valor total é um cheque em branco: não dá para negociar escopo nem medir progresso. Uma que quebra o trabalho em entregas com prazo e critério de aceite permite cortar uma parte sem refazer tudo.

A segunda é o que está fora. Proposta boa declara o que não faz: migração de dados, treinamento, integração com o sistema legado, suporte depois da entrega. Ausência dessa seção não significa que está incluso; significa que a conversa vai acontecer depois, em posição pior.

A terceira é a premissa. Todo prazo assume alguma coisa sobre o seu lado: que a API do sistema atual existe e está documentada, que alguém responderá dúvidas em 48 horas, que os dados estão em formato utilizável. Premissas escritas são gestão de risco; premissas implícitas são o motivo de metade dos atrasos. O trabalho de fechar essas pontas antes do contrato está descrito em definir o escopo de um produto digital.

O que perguntar na primeira reunião

• Quem trabalhou no projeto mais parecido com o meu, e essa pessoa está disponível? Separa portfólio de capacidade atual.
• O que costuma dar errado em projetos como este? Quem responde “nada” não tem experiência suficiente ou não vai contar.
• Qual a menor versão disso que entrega valor? Testa se o fornecedor pensa em resultado ou em tamanho de contrato.
• De quanto tempo da minha equipe vocês precisam por semana? A resposta honesta costuma ser mais do que você esperava.
• Como fica se eu quiser trocar de fornecedor no meio? A reação a essa pergunta diz mais que a resposta.

Sinais de alerta

• Estimativa firme antes de entender o problema. Número cravado na primeira reunião é âncora comercial, não estimativa.
• Desconto por assinar rápido. Pressa na assinatura costuma ser pressa de faturamento, e o custo aparece na execução.
• Tecnologia definida antes do problema. Quando a solução já está escolhida antes de o problema ser descrito, você está comprando o que eles têm para vender.
• Nenhuma pergunta sobre o seu processo atual. Quem não pergunta como funciona hoje vai automatizar o que existe, defeitos inclusive.
• Contrato sem critério de aceite. Sem definição escrita de pronto, a discussão sobre o que falta acontece com o projeto já entregue.

Como o preço se forma

Valor de projeto de TI é, quase sempre, hora de gente. O que muda entre propostas é a composição: quantas pessoas, de que senioridade, por quanto tempo, mais a margem e o risco que o fornecedor assume. Entender isso desarma a negociação por desconto, que costuma apenas trocar o time sênior pelo júnior sem mudar o preço.

Há dois modelos, e a escolha importa mais que a taxa. Escopo fechado transfere o risco para o fornecedor e cobra por isso; funciona quando o problema está bem definido e não deve mudar. Time alocado mantém o risco com você e sai mais barato por hora; funciona quando o escopo vai evoluir e existe alguém do seu lado para priorizar. Escolher escopo fechado com requisito indefinido é a combinação que produz aditivo, e ela é a origem mais comum de projeto que dobra de preço.

Por onde seguir

Se a dúvida ainda é o que contratar antes de quem contratar, o passo anterior é o diagnóstico, tratado em consultor de TI, e a decisão sobre ter ou não liderança técnica própria em CTO as a service. O critério de escolha do parceiro, num recorte mais amplo que o de fornecedor de projeto, está em como escolher um parceiro de tecnologia. Se o que você vai contratar é construção, o recorte é software sob medida, e vale antes checar se o problema não se resolve ligando o que já existe, em integração de sistemas. E quando o que está em jogo é um produto, e não um sistema interno, a conversa começa antes do fornecedor: em product discovery.

Perguntas frequentes