Seu desenvolvedor consegue construir. A pergunta não é essa
Uma construção interna compete com o seu roadmap e não com um prazo, e essa diferença decide mais projetos do que qualquer comparação técnica.
A pergunta sobre capacidade é a fácil
Seu desenvolvedor consegue construir. Na maioria dos casos isso é simplesmente verdade, e qualquer comparação que comece lançando dúvida sobre isso merece desconfiança.
As perguntas interessantes são outras. O que deixa de ser construído no lugar, e se um projeto sem prazo algum dia é concluído.
O preço invisível
Uma construção interna custa aquilo que estava em seguida no roadmap. Esse preço nunca aparece como linha de orçamento, e por isso raramente aparece na decisão.
Se o que seu desenvolvedor entregaria no lugar é o produto pelo qual seus clientes pagam, a automação é cara de um jeito que a nota fiscal nunca mostrará. Se o time está genuinamente ocioso, a aritmética se inverte e construir internamente é claramente certo.
O movimento útil é tornar isso explícito. Nomeie a funcionalidade ou correção que vai atrasar. Ponha uma data nela. Mostre essa data a quem é dono do roadmap e veja se a troca ainda parece óbvia.
Por que projetos internos se esticam
Eles competem com um roadmap e não com um prazo, e um projeto sem data de entrega não tem mecanismo para terminar.
O padrão é consistente o bastante para ser planejado. A construção começa rápido e bem. Depois chega um problema urgente de cliente, depois um release, depois alguém sai, e a automação vira aquilo que se pega entre outras coisas.
Seis semanas de trabalho espalhadas por oito meses não são seis semanas de trabalho. O problema operacional segue sem solução por esses oito meses, e os requisitos escorregam por baixo do sistema meio construído.
A entrega externa não é mais rápida porque as pessoas são melhores. É mais rápida porque o trabalho tem uma data, um escopo fixo e nada mais disputando as mesmas horas. Se construir internamente, a correção é dar ao projeto essas três coisas em vez de torcer.
O que cada lado realmente ganha
| Interno | Agência | |
|---|---|---|
| Conhece seus sistemas não documentados | Sim | Aprende, ao custo de dias |
| Tem data de entrega | Raramente | Por contrato |
| Já viu isso falhar | Às vezes | É isso que você está comprando |
| Ainda está lá no quarto mês | Sim | Só se contratado |
| Depende de uma pessoa permanecer | Normalmente | Não |
| Custo na nota | Nenhum | Real |
| Custo para o roadmap | Real | Nenhum |
As duas últimas linhas são a comparação inteira, e apontam em direções opostas. Todo o resto é detalhe.
O arranjo que costuma bater os dois
Não uma escolha. Uma divisão.
Entrega externa contra uma data, propriedade interna desde a primeira semana. A pessoa que vai ser dona do fluxo participa da construção em vez de receber um documento de passagem no fim, e o conhecimento se transfere por participação e não por papel.
É esse o modelo com que trabalhamos, e por isso a condição do dono nomeado pertence à proposta e não à última semana. Ele também produz o que uma construção interna produz naturalmente e uma externa muitas vezes não: alguém que realmente entende por que o sistema faz o que faz.
Sobre contratar para isso
Só se você tiver trabalho de automação suficiente para manter a pessoa interessada, e essa régua é mais alta do que parece.
Um engenheiro de automação é um ponto único de falha de um jeito que uma agência não é. O trabalho também tem um problema de retenção que ninguém menciona: construir os três primeiros fluxos é interessante, mantê-los enquanto os sistemas ao redor mudam não é. Empresas que contratam para isso e depois ficam sem coisas novas para construir tendem a perder a pessoa em um ano e herdar um sistema que só ela entendia.
Se o pipeline é real, um fluxo por trimestre indefinidamente, contratar ganha na economia por larga margem. Se são dois projetos e depois manutenção, compre as construções e fique com a propriedade.
Antes de qualquer um dos dois
Nenhum caminho ajuda se o processo não estiver pronto, e nem fornecedor nem funcionário deveriam orçar antes de alguém ter contado. A semana de medição se aplica igualmente a uma construção interna, e um time interno é, se alguma coisa, mais propenso a pular a medição por já acreditar que conhece o processo.
Ele normalmente conhece a própria parte. Isso é outra coisa, e por que a maioria dos mapas de processo é inútil trata exatamente dessa lacuna.
01Sai mais barato construir automação internamente?+
Na nota fiscal, quase sempre. No custo total, depende de algo que a maioria das comparações deixa de fora inteiramente, que é o que o seu desenvolvedor deixa de fazer. Uma construção interna tem um preço real igual ao que estava em seguida no roadmap, e esse preço é invisível porque nunca aparece como linha de orçamento. Se o que ele construiria no lugar é o produto pelo qual seus clientes pagam, a automação é muito mais cara do que parece, ainda que nenhum dinheiro mude de mãos. Se seus desenvolvedores estão genuinamente ociosos, a conta se inverte e construir internamente passa a ser a resposta direta. O movimento útil é tornar o custo de oportunidade explícito antes de decidir: nomeie a funcionalidade ou a correção que vai atrasar, ponha uma data nela, e veja se a troca ainda parece óbvia para quem é dono daquele roadmap.
02Por que projetos internos de automação demoram tanto mais?+
Porque competem com um roadmap em vez de com um prazo, e um projeto sem data de entrega não tem mecanismo para ser terminado. O padrão é consistente o bastante para ser planejado: a construção começa rápido e bem, depois chega um problema urgente de cliente, depois um release, depois alguém sai, e a automação vira aquilo que se pega entre outras coisas. Seis semanas de trabalho espalhadas por oito meses não são a mesma coisa que seis semanas de trabalho, porque o problema operacional que ela deveria resolver segue sem solução por esses oito meses e os requisitos escorregam por baixo dela. A entrega externa não é mais rápida porque as pessoas são melhores; é mais rápida porque o trabalho tem uma data, um escopo definido e nada mais disputando as mesmas horas. Se você construir internamente, a correção é dar ao projeto essas mesmas três coisas em vez de torcer.
03O que um desenvolvedor interno faz genuinamente melhor?+
Duas coisas, e ambas valem dinheiro de verdade. Ele conhece seus sistemas, inclusive os não documentados, o campo que significa outra coisa diferente do nome, e a integração que alguém escreveu quatro anos atrás e ninguém tocou desde então. Um time externo gasta seus primeiros dias descobrindo exatamente isso, e num parque incomum esses dias podem ser uma fatia significativa do projeto. A segunda vantagem é permanência: ele ainda está lá no quarto mês, quando um fornecedor muda um formulário, e o conhecimento dele sobre o fluxo se acumula em vez de ir embora com um contrato. É por isso que o arranjo mais forte normalmente não é escolher entre os dois, e sim dividir: entrega externa contra uma data, propriedade interna desde a primeira semana, para que quem herda tenha estado na sala o tempo todo em vez de receber um documento de passagem.
04Devemos contratar alguém especificamente para automação?+
Só se você tiver trabalho suficiente para manter a pessoa interessada, e essa régua é mais alta do que parece à primeira vista. Um engenheiro de automação é um ponto único de falha de um jeito que uma agência não é, e o trabalho tem um problema de retenção que ninguém avisa: construir os três primeiros fluxos é genuinamente interessante, e mantê-los enquanto os sistemas ao redor se mexem não é. Empresas que contratam para isso e depois ficam sem nada novo para construir tendem a perder a pessoa dentro de um ano e herdar um sistema que só ela entendia. Se o pipeline é real, um fluxo por trimestre indefinidamente, contratar ganha na economia por larga margem. Se são um ou dois projetos e depois manutenção, compre as construções e fique com a propriedade, que custa uma fração de um salário e não depende de uma pessoa permanecer.
