Quem aprova orçamento de tecnologia costuma decidir no escuro: aceita um prazo sem saber por que ele escorrega, assina um contrato de sistema sem entender o que está assumindo e ouve que a IA aumentou a produtividade sem ver o número por trás. Este curso entrega o repertório para sustentar essas conversas. Cada módulo abre com o essencial para quem decide, ancora o conceito técnico numa estrutura que você já domina, orçamento, contrato, dívida, apólice, e fecha com a pergunta exata para levar ao time ou ao fornecedor. Todo número traz fonte, data e selo indicando se foi confirmado em fonte primária.
Ao final você sustenta as conversas que hoje acontecem sem você. Vai saber por que uma alteração aparentemente simples leva três semanas, o que responder quando o fornecedor diz que a estimativa é de seis meses, onde mora o risco irreversível no sistema da sua empresa, que perguntas fazem um time técnico mostrar evidência em vez de opinião, e o que a evidência pública de 2026 realmente sustenta sobre produtividade com inteligência artificial, incluindo os resultados que contrariam o discurso de venda.
O percurso linear dos 16 módulos continua sendo o caminho completo. Se você tem um objetivo específico, entre por uma destas rotas. A Executiva foi desenhada para quem decide e não vai operar: não passa por terminal nem por código e para no ponto da decisão.
Conselho, CEO, CFO, COO e diretoria sem formação técnica
Ler uma estimativa com critério próprio, questionar uma proposta de fornecedor, entender o custo real da IA em engenharia e assinar uma política de uso que você compreende de fato.
Gerente de produto, líder de projeto, head de operações e quem convive com time técnico todo dia
Conversar de igual para igual sobre entrega: entender o caminho de uma mudança até produção, o que é um contrato de API e como interpretar um relatório de incidente.
Quem vai executar, quem está migrando de carreira e quem quer o percurso completo
O curso inteiro, na ordem, incluindo dados, performance e o apêndice de terminal. É o caminho mais longo e o único que cobre tudo.
A natureza do ativo que você aprova, o vocabulário que destrava a conversa técnica e o mecanismo real por trás do prazo que escorrega.
Toda compra de software cria uma obrigação recorrente que não aparece no contrato de aquisição. O valor que você aprova hoje paga a primeira versão; manter essa versão funcionando é uma linha de custo que só termina quando o sistema é desligado. Isso importa porque orçamentos de tecnologia costumam ser aprovados como investimento de projeto (CAPEX) e consumidos como despesa de operação (OPEX), e a distância entre os dois é onde estouram os planos de três anos. A decisão que cabe a você é definir, antes da assinatura, quem paga a manutenção, por quanto tempo e sob qual critério de qualidade. Dá para delegar a escolha da tecnologia, o desenho da arquitetura e a montagem do time. Não dá para delegar a pergunta sobre o custo de propriedade ao longo do ciclo de vida.
O texto que o computador executa. É matéria-prima: sozinho não entrega capacidade nenhuma ao negócio.
O código somado ao que faz ele rodar fora da máquina de quem o escreveu: configuração, testes, documentação, dependências de terceiros e rotina de instalação.
O software em operação real, com clientes, dinheiro, integrações externas e obrigação legal de guardar registro. É onde o resultado aparece e onde o prejuízo acontece.
Trabalho contínuo para o sistema continuar fazendo o mesmo que já fazia, apesar de mudanças externas: atualização de segurança, adaptação a nova regra fiscal, troca de versão de dependência.
Soma do que se paga para construir, operar, manter e um dia desativar um sistema. O preço de compra costuma ser a menor parcela dessa soma.
Escolha entre dois caminhos com custos diferentes, sem opção obviamente superior. Quase toda decisão técnica relevante tem essa forma, e o custo escolhido é sempre pago por alguém.
O contrato foi assinado em março, o sistema entrou no ar em outubro e o projeto foi dado como encerrado na reunião de diretoria. Dois anos depois, a mesma diretoria discute um orçamento de reforma quase do tamanho do original, com o mesmo fornecedor, para um sistema cujo propósito ninguém mudou. Esse ciclo se repete em empresas de qualquer porte, e a causa costuma ser um erro de classificação que virou erro de expectativa: software foi tratado como ativo comprado quando se comporta como passivo assumido.
Máquina comprada tem vida útil previsível, manual de manutenção e valor de revenda. Software não tem nenhum dos três. Ele degrada mesmo sem ser usado, porque o mundo em volta muda: o navegador atualiza, a adquirente troca o protocolo de pagamento, a Receita altera o layout do arquivo, o autor de uma biblioteca abandona o projeto, a legislação exige um campo novo. Nada disso acontece dentro do seu sistema. Tudo isso obriga o seu sistema a mudar.
Quando a empresa compra uma empilhadeira, o custo do ano seguinte é combustível, revisão e seguro, e o fabricante nem precisa continuar existindo para ela seguir levantando paletes. Quando a empresa compra um sistema, o custo do ano seguinte é gente: alguém precisa acompanhar as mudanças externas, aplicar correções de segurança, ajustar o comportamento quando a operação muda e atender às três da manhã quando tudo para. Essa conta se comporta como folha de pagamento, e é assim que ela deve entrar no plano plurianual.
Software entra no orçamento na linha de gente, e a linha de gente não tem data de término.
Três palavras chegam como sinônimos na proposta comercial e representam coisas com preços muito diferentes. Vale separar antes de discutir valor.
Código é o texto executável. Comprar código sem o resto equivale a comprar aço sem a ponte.
Software é esse código somado a tudo que o faz funcionar em outro lugar: configuração, testes, documentação, dependências, instalador. É o produto entregável.
Sistema é o software em operação, com usuários reais, dados reais, integrações com bancos e adquirentes, picos de acesso e falhas de rede.
A maior parte das disputas com fornecedor nasce de um contrato escrito no nível de software e cobrado no nível de sistema. O fornecedor entrega o pacote que a cláusula descreve, a empresa esperava a operação funcionando, e a diferença entre as duas leituras vira aditivo contratual.
| Camada | O que você está comprando | Onde o custo volta |
|---|---|---|
| Código | O texto executável e a propriedade intelectual sobre ele | Na troca de fornecedor: sem o código e sem quem o entenda, trocar vira reconstruir |
| Software | O pacote instalável, com testes, documentação e dependências de terceiros | Nas atualizações de dependência e correções de segurança, que continuam depois da entrega |
| Sistema | A operação viva: servidores, monitoramento, plantão, suporte e evolução | Todo mês, enquanto a operação existir |
Contrato que descreve apenas a camada de software transfere a camada de sistema para o comprador sem dizer isso em nenhuma cláusula. Como a transferência não tem redação própria, ela só aparece na primeira fatura de operação.
Todo projeto de software é negociado em três eixos, e a aritmética entre eles é fechada: apertar um obriga a ceder em outro.
| Eixo | O que ele controla | A pergunta que cabe a você |
|---|---|---|
| Tempo | Data de entrega, janela de mercado, prazo regulatório | Por que essa data, e o que acontece de concreto se ela escorregar um mês? |
| Escopo | Quantidade de funcionalidades e profundidade de cada uma | O que precisa existir na primeira versão para a operação não parar? |
| Qualidade | Confiabilidade, desempenho, segurança e facilidade de manutenção | Quanto custa, em dinheiro e em reputação, cada falha que chegar ao cliente? |
Fornecedor que promete os três eixos no melhor nível está cedendo em qualidade, porque é o único eixo invisível no momento da entrega. Escopo faltando aparece na demonstração. Prazo estourado aparece no calendário. Qualidade baixa aparece dezoito meses depois, na forma de um custo de manutenção que ninguém orçou e de uma janela de indisponibilidade no dia de maior faturamento.
Titus Winters, engenheiro do Google e autor principal de Software Engineering at Google, resume a diferença de forma econômica: engenharia de software é programação integrada ao tempo. Programar resolve o problema de hoje. Engenharia resolve o problema de hoje de um jeito que continue resolvido quando quem escreveu já tiver saído, quando o volume tiver multiplicado e quando a regra de negócio tiver mudado duas vezes.
Para quem aprova orçamento, a tradução é direta: o preço de compra é a menor parcela de uma série. Um sistema barato de construir e caro de manter custa mais no terceiro ano do que um caro de construir e barato de manter, e a escolha entre os dois é sua. O time técnico apresenta as opções e o custo de cada uma. Quem define o horizonte de amortização é quem responde pelo resultado da empresa nesse horizonte.
R$ 919,7 bi
Movimentação do setor brasileiro de TIC em 2025
Equivalente a 7,2% do PIB nacional
2,15 milhões
Trabalhadores formais projetados no macrossetor de TIC ao fim de 2026
Crescimento de 1,6% no ano
58,8%
Parcela dos profissionais de tecnologia da informação em desenvolvimento de sistemas
O restante se divide entre infraestrutura, suporte e gestão
3,3x
Quanto o salário em software supera a média nacional
Custo de manutenção é, na prática, custo de gente cara
Fonte: Brasscom, Relatório Setorial 2025 e projeções para 2026 divulgadas pelo Teletime em 07/07/2026.
Esses números mudam a negociação de compra em dois pontos concretos.
O primeiro é o preço da hora de manutenção. Quando a remuneração média da função supera em mais de três vezes a média do país, cada hora de manutenção não prevista sai cara, e o fornecedor conhece esse número melhor do que você. Contrato sem teto de horas de manutenção, num mercado assim, é cheque com valor em aberto.
O segundo é a disponibilidade de quem cuida do que já existe. Com quase seis em cada dez profissionais de tecnologia da informação alocados em desenvolvimento de sistemas, o mercado tem gente construindo coisa nova e comparativamente pouca gente disposta a manter sistema antigo de outra pessoa. A consequência prática é que manutenção é o serviço mais difícil de recontratar depois que o time original se dispersa, e o preço de recontratá-lo reflete essa dificuldade.
Aprovação que gera passivo cego
Coluna a evitar
Aprovação que gera passivo administrado
Coluna recomendada
Falta discutir a herança, que é a parte mais cara e a menos documentada. Executivo troca de cadeira a cada três ou quatro anos; sistema fica quinze. Quem aprova a compra quase nunca é quem paga a fatura de manutenção no quinto ano, e esse descasamento de horizonte explica boa parte das decisões que parecem irracionais quando vistas de fora.
O antídoto custa quinze minutos e cabe num documento. No momento da aprovação, registre três informações, um parágrafo cada: qual problema de negócio esse sistema resolve, qual alternativa foi descartada e por qual motivo, e qual é o custo anual esperado de mantê-lo vivo sem nenhuma funcionalidade nova. Quando o seu sucessor abrir esse registro, ele decide com contexto. Sem o registro, o desfecho padrão é reconstruir do zero por falta de informação, pagando de novo o que já foi pago.
Antes de assinar qualquer contrato de software, faça uma pergunta ao fornecedor e exija a resposta por escrito: qual é o custo anual de operação e manutenção deste sistema no terceiro ano, supondo que nenhuma funcionalidade nova seja pedida? Resposta boa tem número, tem premissa declarada (quantas pessoas, em qual regime, com qual tempo de resposta) e admite faixa de variação. Quem responde 'depende do que vocês pedirem' está falando de evolução, e evolução é outra rubrica. Complete com a segunda pergunta: quanto esse custo muda se a manutenção for levada para dentro de casa em dois anos, e o que precisa ser entregue hoje para que isso seja possível?
Você consegue separar, em qualquer proposta que chegue à sua mesa, o preço de construção do compromisso de operação, sabe identificar qual dos três eixos (Tempo, Escopo ou Qualidade) o fornecedor está cedendo em silêncio, e formula por escrito a pergunta que revela o custo do terceiro ano antes da assinatura.
O rastro de revisão de cada alteração, a memória que sobrevive à saída das pessoas e o caminho completo de uma mudança até chegar ao cliente.
A estrutura que define o custo da próxima mudança, os contratos que ligam a empresa às outras e o lugar onde o erro não tem volta.
O que quebra com crescimento, como saber que quebrou antes do cliente ligar e o risco que entra pela cadeia de fornecedores e pela regulação.
O que a evidência de 2026 sustenta sobre produtividade, quanto custa de fato, como medir retorno sem se enganar e que time a empresa precisa montar.
Material opcional. Quem não pretende executar comando nenhum pode encerrar o curso na etapa anterior sem prejuízo de raciocínio.
Chief Strategy Officer da Nuvini (Nasdaq: NVNI), Founder da Brasil GEO, cofundador da NAIA e cofundador da AI Brasil. Foi CMO da Semantix, empresa brasileira de dados e IA listada na Nasdaq.
Este curso faz parte do material educacional gratuito da Brasil GEO. Cada afirmação numérica traz fonte, data e um selo indicando se o dado foi confirmado em fonte primária ou se ainda depende de verificação. Onde a evidência pública é conflitante, o conflito aparece escrito no texto em vez de ser resolvido a favor da tese mais confortável.
Plataforma de visibilidade algorítmica com análises contínuas em ChatGPT, Gemini, Claude e Perplexity. R$ 99/mês nos primeiros 3 meses com cupom ALE99. Ideal para aplicar o que você aprendeu em Engenharia de Software para Executivos.
Sem cartão para começar · cancele quando quiser · cupom ativo por 3 meses consecutivos
Um fornecedor apresenta a estimativa de um sistema como uma data única: 14 de novembro. Qual é a melhor devolutiva de um executivo que entende engenharia?
Cursos do portal que aprofundam ou complementam o que você estudou aqui.
Seleção automática baseada nos tópicos, audiência e jornada desta página.