Como terceirizar o desenvolvimento de um app sem se dar mal
O manual de operação do fundador não-técnico para tocar um desenvolvimento terceirizado de modo que o app seja entregue, funcione e seja seu no final.
Uma fundadora que a gente conhece pagou R$ 300 mil a uma agência bem avaliada para construir um app de marketplace. Nove meses depois, ela tinha uma demo que rodava no celular do dono da agência e em nenhum outro lugar, um código que ninguém fora daquela casa conseguia abrir e uma fatura de “escopo adicional”. Quando pediu o código-fonte, descobriu que o contrato dizia que a agência era dona dele até o pagamento final, e o pagamento final dependia de um lançamento que vivia escorregando. Ela tinha terceirizado o desenvolvimento e, sem perceber, terceirizado o controle do único produto da empresa.
Esse é o risco de verdade, e não é o que os resultados de busca avisam.
Terceirizar o desenvolvimento de um app é contratar um time de fora para projetar e construir o seu software em vez de contratar engenheiros você mesmo. Bem feito, é o caminho mais rápido para um fundador não-técnico colocar um produto real no mercado sem virar gestor de tecnologia. Mal feito, produz exatamente o desastre acima. A diferença quase nunca está na qualidade dos desenvolvedores. Está em você ter mantido a alavancagem nos cinco pontos em que os fundadores a entregam de mão beijada. Este é o manual para mantê-la.
Se você ainda está decidindo se vale a pena terceirizar, comece pela nossa análise sobre montar time interno versus terceirizar. Este artigo parte do princípio de que você já tomou essa decisão e agora precisa tocá-la.
Primeiro, saiba o que você está realmente comprando
“Terceirização” é uma palavra só para quatro arranjos bem diferentes, e as histórias de fracasso costumam começar com o fundador comprando o errado.
O primeiro é o freelancer: uma pessoa, por hora ou por projeto, barato, rápido e um ponto único de falha. O segundo é o staff augmentation, em que você aluga um ou mais desenvolvedores que trabalham sob a sua direção mas seguem na folha de outra empresa. A gente escreveu um texto inteiro sobre como o staff augmentation funciona na prática; em resumo, ele te dá as mãos mas espera que você forneça a cabeça. O terceiro é o projeto de escopo fechado, em que um estúdio cota um preço para entregar uma coisa definida. O quarto é o time dedicado, um esquadrão contínuo que funciona como o seu departamento de engenharia sem ser seu funcionário.
Para um primeiro app com um fundador não-técnico, o projeto de escopo fechado e o time dedicado costumam ser os formatos certos. Freelancers quebram no momento em que uma pessoa some, e o staff augmentation só funciona quando alguém do seu lado consegue de fato dirigir engenheiros. Escolha o arranjo que combina com quanta capacidade de julgamento técnico você consegue fornecer, não o de menor preço de etiqueta. Onde esse time fica geograficamente, no país, perto ou do outro lado do mundo, é uma decisão separada, com seus próprios trade-offs.
Fase 1: feche o escopo antes de sair cotando
O maior erro dos fundadores é ligar para as agências primeiro e escrever o escopo depois. Você acaba deixando quem vai dar lance no trabalho definir o trabalho. Claro que o escopo cresce.
Antes de falar com qualquer um, escreva três coisas em português claro. O que o app precisa fazer para o seu primeiro usuário de verdade. O que ele explicitamente não vai fazer na versão um. E como você vai saber que deu certo. Você não precisa de uma especificação técnica. Precisa de uma descrição clara o bastante para que dois fornecedores diferentes cotem mais ou menos a mesma coisa. Quando as cotações voltam muito diferentes, a distância está medindo a ambiguidade do seu escopo, não a diferença de competência entre eles.
Esse documento também é a sua defesa contra a frase mais cara do software, “escopo adicional”. Uma mudança só é adicional se não estava na descrição original. Se a descrição mora na sua cabeça, toda divergência se resolve a favor do fornecedor. Se mora no papel, você tem uma referência que os dois lados concordaram.
Um estudo da McKinsey com Oxford sobre grandes projetos de TI descobriu que eles estouram, em média, cerca de 45 por cento do orçamento, e os estouros vêm mais de objetivos mal definidos e requisitos que mudam do que de código ruim. Você não vai vencer esse risco na engenharia. Você o administra decidindo o que vai construir antes de pagar alguém para construir.
Sinal de alerta: o fornecedor que dá um preço e um prazo fechados antes de fazer uma única pergunta difícil sobre os seus usuários. Ou está chutando, ou está planejando faturar a diferença.
Fase 2: escolha sem ser vendido
Todo guia de “como terceirizar” que ranqueia para essa busca foi escrito por uma empresa que quer ser a resposta. Leia para o que eles revelam, depois avalie fornecedores por coisas que o marketing deles não consegue forjar.
Peça para conversar com os engenheiros que de fato vão tocar o seu build, não com o vendedor e não com um líder de ar sênior que aparece no pitch e some depois da assinatura. Peça uma referência de um projeto que deu errado ou desandou, e escute como descrevem o que aconteceu. Um time que narra um fracasso com honestidade já acertou contas com o próprio trabalho. Um time só com cases triunfantes ou é novo ou está editando.
Pergunte como eles fazem o handoff do código, por escrito, antes de assinar. Onde o repositório fica? Quem é dono das contas? O que acontece com o seu projeto se você parar de trabalhar com eles mês que vem? Um bom parceiro responde na hora porque já foi perguntado antes. O parceiro errado trata a pergunta como sinal de desconfiança, o que já te diz tudo.
Sinal de alerta: o preço muito abaixo dos outros. Desenvolvimento de app tem um piso real de horas qualificadas. Uma cotação bem abaixo do grupo é uma cotação para uma coisa diferente, menor ou mais frágil do que você acha que está comprando, e a diferença aparece como “escopo adicional” lá na frente.
Fase 3: estruture o acordo para a alavancagem ficar com você
Esta é a fase que salvou ou afundou cada fundador da nossa história de abertura, e ela se resume a três cláusulas que a maioria passa o olho.
Propriedade intelectual. O contrato precisa dizer que você é dono de todo o trabalho produzido, código-fonte incluído, na criação, não no pagamento final. Código encomendado não é automaticamente seu: na maioria das jurisdições, sem uma cessão por escrito, quem escreveu o código guarda direitos sobre ele (a lei de direitos autorais dos EUA é explícita nisso). É uma correção de um parágrafo e a frase mais importante do acordo. A gente aprofunda no documento inteiro no nosso guia sobre o contrato de desenvolvimento de software.
Pagamento atrelado a marcos que funcionam, não ao calendário. Pague por progresso demonstrável e publicado: uma tela de login que de fato loga, um checkout que de fato cobra. Nunca pague uma parcela gorda no fim, e nunca deixe o pagamento adiantar a entrega em mais de um marco. O dinheiro é a sua única alavancagem. Gaste por último.
Acesso desde o dia um. Você deve ser dono do repositório, das contas de nuvem, do domínio e das fichas nas lojas de app desde o primeiro commit, com o fornecedor trabalhando dentro das suas contas. Se esses ativos estão no nome do fornecedor, você não tem um produto. Você tem um refém.
Sinal de alerta: qualquer versão de “a gente transfere tudo no final”. Tudo deve ser seu desde o começo. O handoff deveria ser um não-evento porque nada nunca saiu da sua guarda.
Fase 4: toque o build mesmo sem saber ler código
Os fundadores acham que não ser técnico significa não conseguir gerir o trabalho. É o contrário. As coisas que afundam builds terceirizados são visíveis para qualquer um que esteja prestando atenção, e nenhuma exige ler uma linha de código.
Exija software funcionando a cada uma ou duas semanas, rodando em um aparelho real, não um slideshow de progresso. Software que existe pode ser clicado. Software descrito num status pode ser qualquer coisa. Se passarem três semanas sem nada que você consiga abrir e tocar, esse é o aviso, por melhor que o relato soe.
Mantenha uma pessoa nomeada do lado deles responsável pela entrega, e um tomador de decisão do seu lado que responde em até um dia. A maioria dos builds terceirizados não fracassa por engenharia ruim. Eles emperram porque uma pergunta ficou uma semana na caixa de entrada do fundador e o time construiu em volta do silêncio. Resposta lenta é um custo escondido que você paga em escopo.
Fique de olho num desvio específico: o build que vive somando funcionalidades que nenhum usuário pediu. Isso é feature creep, e um time terceirizado tem um incentivo silencioso a favor dele, porque mais funcionalidade significa mais horas faturáveis. O seu documento de escopo é o remédio. Qualquer coisa fora dele é uma conversa, não um padrão.
Fase 5: seja dono do ativo no handoff
A relação termina de uma de duas formas. Ou foi montada para que o handoff seja nada, ou você descobre na pior hora que não consegue viver sem as pessoas que estão indo embora.
Antes do pagamento final, confirme que você consegue entregar o projeto para um time diferente e que ele consegue tocar. Isso significa que o código está no seu repositório, as contas estão no seu nome, existe um documento escrito de como fazer deploy e rodar a coisa, e alguém que não seja o autor original já abriu e entendeu. Se só uma pessoa no mundo consegue manter o seu app vivo, você não terminou de terceirizar. Você só trocou de quem depende.
Um handoff limpo também é o teste honesto de o trabalho ter sido bom. Software feito para ser entregue é feito com clareza, porque o time sabia que outra pessoa ia ler. Software feito para te manter preso é feito para te manter preso. Você vai sentir a diferença na primeira vez que tentar ir embora.
Quanto custa, com honestidade
Os fundadores buscam um número e não existe um. Um app simples de um time competente costuma ficar na casa das dezenas de milhares de reais; um produto complexo, multifacetado, com pagamentos e recursos em tempo real, chega à casa das centenas de milhares. As faixas honestas, e o que as move, estão na nossa análise sobre quanto custa desenvolver um app.
O enquadramento mais útil: barato e queimado sai mais caro que justo e terminado. O marketplace de R$ 300 mil que não produziu nada custou muito mais que um build de R$ 450 mil que foi ao ar, porque o primeiro também custou nove meses, a janela de captação que aqueles meses continham, e a reconstrução. Precifique o resultado inteiro, não a fatura.
O teste de verdade
Tire as fases e uma pergunta decide: em cada passo, com quem está a alavancagem? Se a resposta é sempre “comigo, por desenho”, porque você fechou o escopo primeiro, pagou por prova, foi dono dos ativos desde o dia um e construiu rumo a uma saída limpa, então terceirizar o desenvolvimento do app é a jogada mais inteligente que um fundador não-técnico pode fazer. Se a alavancagem escorrega para o fornecedor, nenhum talento do lado dele te salva, porque os incentivos dele e os seus se separaram sem alarde.
Você não precisa aprender a programar. Você precisa se recusar a entregar o controle da única coisa sobre a qual a sua empresa roda. Isso é uma decisão, e ela é inteiramente sua.
Perguntas frequentes
Quanto custa terceirizar o desenvolvimento de um app?
Um app direto de um time qualificado costuma cair na casa das dezenas de milhares de reais. Um produto complexo, com pagamentos, vários tipos de usuário ou recursos em tempo real, pode chegar à casa das centenas de milhares. A variável é o escopo, não o valor da hora, e é por isso que um documento de escopo apertado é o controle de custo mais barato que você tem. Veja a nossa análise de custos completa para as faixas e o que as move.
Quanto custa pagar alguém para desenvolver um app?
As mesmas forças valem, seja esse “alguém” um freelancer, um estúdio ou um time dedicado. Um freelancer sozinho cota o menor número e carrega o maior risco de ponto único de falha. Um estúdio ou time dedicado custa mais e absorve esse risco. Compare o resultado e a propriedade no total, não o preço de etiqueta.
Quais são os quatro tipos de terceirização?
Para desenvolvimento de app, os quatro práticos são: o freelancer (uma pessoa, mais barato, mais arriscado), o staff augmentation (desenvolvedores alugados que você dirige), o projeto de escopo fechado (um estúdio entrega uma coisa definida por um preço combinado) e o time dedicado (um esquadrão contínuo que funciona como o seu departamento de engenharia). A maioria dos primeiros builds se encaixa no projeto de escopo fechado ou no time dedicado.
É seguro terceirizar o desenvolvimento de um app?
Sim, quando o contrato te dá o código-fonte e as contas desde o dia um, o pagamento segue marcos que funcionam, e o build é montado para um handoff limpo. O perigo nunca é só o lugar ou o time. É um acordo estruturado para a alavancagem ficar com o fornecedor. Estruture para ela ficar com você.
Terceirizar o desenvolvimento de app é legal?
Sim. Contratar um time de fora, no país ou no exterior, para construir o seu software é padrão e legal. O único ponto jurídico que importa para você é a propriedade intelectual: garanta uma cessão por escrito de todo o trabalho produzido para que o código seja, sem ambiguidade, seu.