O Pre-Sales Sob a Ótica de um Engenheiro: Transformando Especificações em um Cluster Operacional
Descubra o papel crucial do engenheiro de pre-sales na área de cibersegurança, desde a análise de requisitos técnicos até a implementação de soluções complexas. Entenda como traduzir as necessidades do cliente em projetos viáveis e como evitar armadilhas comuns no processo de vendas.
MundiX News·16 de abril de 2026·15 min de leitura·👁 9 views
Olá, pessoal do MundiX! Aqui é Vladislav Permyakov, engenheiro de pre-sales sênior da K2 Cyber Security.
Sejamos honestos: na visão de mundo do engenheiro médio, qualquer pessoa com o prefixo "Sale" (Vendas) provoca mais irritação do que simpatia. Não porque "vendedores são ruins", mas porque uma bela ideia comercial muitas vezes não resiste ao choque com a realidade. Por exemplo, um vendedor chega radiante, coloca um contrato assinado na mesa e diz: "Vendemos todo o nosso portfólio para eles!". Você abre a especificação, olha para a infraestrutura do cliente e percebe que essa gambiarra não vai funcionar. O parque de servidores está desatualizado, os canais de comunicação não suportam o tráfego e ninguém verificou a compatibilidade com o software legado. Mas o vendedor já está fechando um novo negócio, e você precisa fazer funcionar uma solução que tecnicamente não se encaixa nas tarefas do cliente.
A qualidade da implementação e a vida dos engenheiros dependem muito do que foi acordado na fase de vendas. Em algum momento, quis assumir o controle disso e, de repente, me vi no "lado sombrio" – tornei-me um engenheiro de pre-sales e reuni todo um departamento de desertores como eu.
O que faz um engenheiro de Pre-Sales?
Um engenheiro de pre-sales é, antes de tudo, um arquiteto que conhece os produtos do mercado de cibersegurança e suas características técnicas, analisa o estado atual da proteção do cliente e projeta soluções que aumentarão o nível de segurança da infraestrutura. Em segundo lugar, é uma pessoa com habilidades de comunicação com especialistas e gestores de diferentes níveis e com compreensão da componente financeira do negócio.
Para entender por que essa pessoa é necessária, basta olhar para o esquema desatualizado que ainda é encontrado em algumas empresas. Nele, o processo de vendas é gerido por um vendedor que sabe abrir portas para os gabinetes dos altos executivos, mas não entende a arquitetura das soluções.
Quando um cliente envia uma especificação técnica, faz perguntas técnicas específicas ou pede para avaliar uma opção de implementação, o vendedor geralmente envolve o primeiro engenheiro que encontra e pede para "estimar rapidamente a composição da solução". É improvável que um engenheiro, que está ocupado com um projeto atual e depurando um bug crítico, consiga mergulhar totalmente na tarefa. Na melhor das hipóteses, ele esboçará rapidamente uma especificação e uma estimativa de mão de obra com base em informações incompletas. Como resultado, o cliente recebe um estudo não muito preciso e os engenheiros acabam desenvolvendo uma aversão persistente à palavra "pre-sales".
Na verdade, 70% do pre-sales na nossa área é pura engenharia e arquitetura. Para ser eficaz nesta posição, é preciso conhecer o mercado de cibersegurança em toda a sua diversidade. Só no nosso portfólio, existem mais de 200 produtos, e todos eles precisam ser conhecidos ao nível das características arquitetónicas. Um "vendedor" puro e simples simplesmente não se lembrará das nuances de compatibilidade. Só uma pessoa que tenha lidado com estas caixas com as próprias mãos pode dizer o que se esconde por detrás das promessas do fornecedor. Portanto, é bom quando as pessoas passam de engenheiros de implementação para pre-sales: a experiência de projetos reais permite-lhes trabalhar detalhadamente nos custos de mão de obra e sentir as nuances que não podem ser lidas em nenhuma folha de dados.
Como engenheiro de pre-sales, desempenho o papel de elo de ligação, ou seja, pego na "ideia" do cliente e no "orçamento planeado" e transformo-os num cenário de trabalho. Verifico a viabilidade técnica, recolho as especificações, descrevo como é que vamos fazer isso numa proposta técnica. Transformo o abstrato "quero" em concreto "quanto custa e quais são os riscos". Se eu cometer um erro nos cálculos, a equipe de implementação terá que pagar com os seus nervos.
O Pipeline: Do Pedido Inicial à Proposta Comercial
Pode parecer que o pre-sales é uma grande reunião com o cliente, mas, na verdade, este trabalho pode ser dividido em 8 etapas.
Etapa zero – qualificação do pedido. O vendedor avalia de forma independente o quão real é o negócio, se existe um orçamento, se o perfil do cliente corresponde às nossas competências. A qualificação é aprovada. E agora?
Se o lead for adequado, começa a coleta de dados originais. O vendedor pode vir com documentação de concurso, uma especificação técnica de 200 páginas ou uma mensagem no Telegram da série "o cliente quer algo sobre firewalls, vou esclarecer o orçamento". Os dados de entrada quase nunca estão completos, portanto, a primeira tarefa do engenheiro de pre-sales é estruturar as informações dispersas. Para isso, temos questionários para cada tipo de solução, que ajudam a não perder informações críticas, como orçamento, prazos, arquitetura atual e características da infraestrutura.
Em seguida – análise primária. O engenheiro de pre-sales determina quais tipos de soluções estão envolvidos no projeto, avalia o que pode trabalhar sozinho e onde será necessário envolver engenheiros de práticas especializadas ou um arquiteto. Se o projeto for complexo (mais de duas ou três soluções de diferentes fornecedores ou uma arquitetura complexa), então não se pode prescindir de um arquiteto. É importante conhecer a sua equipe e as unidades adjacentes: num projeto complexo, o engenheiro de pre-sales deve entender quais colegas envolver.
Em seguida, há uma reunião interna da equipe: verificamos a compreensão da tarefa, distribuímos funções e preparamos perguntas para o cliente.
Depois, há uma reunião com o cliente, onde coletamos as informações de entrada que faltam.
Com base nas informações coletadas, preparamos especificações e estimamos os custos de mão de obra (mais sobre isso abaixo).
Tudo é reunido em um único pacote, após o qual o vendedor elabora uma proposta comercial.
Em seguida, realizamos a defesa da proposta comercial perante o cliente.
Às vezes, após a defesa da proposta comercial, preparamos um design conceitual do projeto-alvo: trabalhamos na arquitetura, descrevemos o estado-alvo e os requisitos de implementação. Isso aumenta significativamente as chances de vencer o concurso.
É importante notar que existem diferentes tipos de pre-sales, e o conjunto de documentos depende do pedido específico. Às vezes, o cliente precisa apenas do fornecimento de equipamentos, então preparamos uma especificação. Às vezes, apenas a implementação: o equipamento já foi comprado e precisamos de mãos e experiência, e então o principal documento é o cálculo dos custos de mão de obra. Mas, na maioria das vezes, os projetos envolvem tanto o fornecimento quanto a implementação, então calculamos ambos. Existem projetos-piloto, onde antes de celebrar um contrato, é necessário confirmar a operabilidade da solução e a integração bem-sucedida na infraestrutura do cliente. E, finalmente, o orçamento – os chamados "pre-sales longos": o cliente aloca um orçamento para o próximo ano, e precisamos dar uma estimativa de alto nível, à qual ele retornará em alguns meses. O tipo de pre-sales determina quais perguntas fazer e quais documentos preparar.
Os Documentos Essenciais
Toda a nossa metodologia se baseia em dois documentos:
Especificação (BOM, Bill of Materials) – uma lista de todos os equipamentos, materiais e licenças.
Cada fornecedor tem seu próprio método de elaboração de uma especificação: alguns têm um preço em acesso aberto, outros precisam solicitar preços. Em projetos complexos, o engenheiro de pre-sales coleta todas as especificações, verifica sua correção, verifica com o gerente técnico, se necessário, e envia para o vendedor em um único pacote.
Calculadora de Custos de Mão de Obra (ТРЗ) – tabelas com fórmulas, onde cada etapa do trabalho é descrita de acordo com o princípio: implantação de uma máquina virtual – 2 horas, escrita de uma política de segurança – mais 4 horas.
Cada solução é acompanhada por um arquivo ТРЗ separado. Usamos modelos da base de conhecimento, mas as horas neles são médias e precisam ser revisadas para cada projeto.
Etapas clássicas de implementação: levantamento, projeto, trabalhos de comissionamento, operação experimental e testes de aceitação. E cada etapa deve ter um documento de fechamento. Alocamos horas tanto para um engenheiro de nível médio quanto para um engenheiro líder (geralmente em uma proporção de 70/30, mas depende da complexidade), e também levamos em consideração o local de trabalho em cada etapa: por exemplo, o levantamento é realizado pessoalmente e o projeto, como regra, remotamente.
Uma história separada são as condições e restrições. Se o ТРЗ indicar o trabalho "criação de regras de firewall" sem a ressalva "não mais de 50 regras", o cliente tem o direito de exigir qualquer quantidade. Portanto, não apenas fixamos as restrições no cálculo dos custos de mão de obra, mas também garantimos que elas entrem na proposta comercial e na especificação técnica do contrato. Isso protege ambos os lados: todos entendem igualmente o escopo do trabalho.
Quando preencho essa tabela, estou realmente construindo um modelo virtual do futuro projeto. Mas até mesmo a calculadora mais precisa é inútil se houver informações de entrada incorretas e é aqui que começam os 30% restantes do pre-sales técnico.
Realizando o Diagnóstico
Os clientes confundem regularmente "dor" (problema) e "pílula" (solução) e vêm até nós com um diagnóstico pronto. Temos que ligar o modo Dr. House e descobrir onde realmente dói.
Para que você entenda do que estou falando, aqui está um caso da prática. Um grande cliente vem com um pedido específico: "Precisamos de um sistema de prevenção de intrusões (IPS), um hardware separado". Um vendedor ruim nessa situação encontrará e venderá a caixa mais cara. Um engenheiro, por outro lado, começará a cavar nessa situação.
"E o que você tem atualmente no perímetro? Qual NGFW você usa?" Acontece que eles têm um poderoso cluster NGFW de um fornecedor de ponta e aqui está o mais interessante: "Você sabe que já tem IPS? Simplesmente não está ativado por uma licença ou está desativado nas políticas para não sobrecarregar a CPU". Como resultado, em vez de um novo hardware por 5 milhões, vendemos uma licença para ativar a blade IPS e ajustar as assinaturas para não cortar o tráfego legítimo. Menos 90% do orçamento para hardware, mais um cliente que retorna regularmente com novas tarefas.
Calculando os Custos de Mão de Obra
Nas apresentações dos fornecedores, tudo é simples: "passo 1, passo 2 – e tudo funciona". Na realidade, é necessário descrever detalhadamente quais trabalhos cada etapa do projeto inclui. Em cada caso específico, a lista de trabalhos pode variar significativamente.
Uma história separada são as diferenças nas abordagens à documentação. As empresas comerciais jovens geralmente solicitam documentação de projeto utilitária, enquanto as estruturas estatais têm requisitos muito mais amplos para a composição, forma e conteúdo dos documentos. Isso afeta diretamente os custos de mão de obra. E, finalmente, cada cliente tem sua própria infraestrutura única e suas próprias características, portanto, o cálculo do ТРЗ será único.
Outro ponto não óbvio são os trabalhos ocultos. Os novatos geralmente esquecem de calcular o tempo na estrada (um objeto em uma zona industrial fora da cidade significa menos 4 horas de tempo de trabalho de um engenheiro na estrada), auditoria (antes de instalar algo novo, você precisa entender como o antigo funciona) e assim por diante.
A propósito, sobre a auditoria: o nível de levantamento precisa ser pensado separadamente. Se o cliente não tem uma compreensão de sua própria infraestrutura – inventário atualizado e diagramas de rede – então faremos esse trabalho. E para as etapas de levantamento e projeto, é necessário alocar significativamente mais horas do que no caso padrão.
E às vezes acontece que no início é simplesmente impossível avaliar o escopo exato do trabalho. Tínhamos um cliente que em um dia demitiu toda a equipe de TI, batendo a porta e nem mesmo passando os acessos. Era necessário implementar o NGFW, mas havia o risco de quebrar o mecanismo de publicação de serviços e simplesmente não havia um diagrama de rede. Na verdade, trabalhamos no formato black box: levantamos todos os processos de negócios do zero, identificamos qual tráfego era legítimo e qual não, e só depois disso formamos políticas de segurança. Esse caso foi difícil, pois muitos obstáculos surgiram, mas o cliente foi resgatado.
Iniciando o Piloto
O piloto também não é um passeio inofensivo. Digamos que o cliente esteja em dúvida: "Seu sistema DLP realmente não vai derrubar nossa rede? Vamos tentar". Pegamos um estande piloto com recursos moderados, colocamos 10 usuários do grupo de teste lá e tudo funciona perfeitamente. E então o cliente, embriagado com o sucesso, se oferece para implantar imediatamente nossa solução em toda a fábrica. O hardware está lá, a licença ainda é válida por um mês. Por que esperar?
Explicamos a diferença entre a arquitetura piloto e a arquitetura-alvo: este hardware é projetado para testes funcionais, não para testes de carga. Se você colocar tráfego de produção lá, o servidor vai parar em alguns minutos. Portanto, ao me preparar para o piloto, calculo com antecedência: se o cliente quiser deixar isso, qual hardware devo trazer inicialmente? Às vezes, trazemos imediatamente uma caixa poderosa.
Muitos tratam os pilotos com negligência, mas, na verdade, o piloto não é muito diferente de uma implementação completa: é necessário um regulamento, um plano de teste, um programa e metodologia de teste (ПМИ), documentos de relatório e uma justificativa financeira para a transição para a solução-alvo. Também mantemos o cliente e o fornecedor informados sobre o status do piloto – isso ajuda a identificar e eliminar problemas a tempo, em vez de acumulá-los até o final.
Matemática e Retrospectiva
Nas vendas, existe uma ilusão perigosa: assim que o contrato é assinado, o trabalho é considerado concluído. Para um engenheiro de pre-sales, este não é o fim. Chamamos isso de análise retrospectiva (Plan vs Fact). Digamos que eu calculei um projeto de implementação de VPN para 40 horas, mas na verdade acabou sendo 120. O projeto foi concluído, o cliente está satisfeito, mas para a empresa este projeto não é lucrativo.
Nós nos reunimos como uma equipe e começamos uma investigação. Geralmente existem três opções:
Erro de pre-sales, que não levou em consideração a arquitetura específica dos aplicativos. Conclusão: para este tipo de tarefa, introduzimos um coeficiente de complexidade e alocamos tempo adicional.
Erro de implementação, ou seja, a tarefa era padrão, mas exigia maior competência dos engenheiros. Portanto, é necessário realizar treinamento adicional.
Força maior ou defeito do equipamento – esses riscos devem ser considerados no contrato.
Com base nos resultados dessas análises, estamos constantemente aprimorando as calculadoras e ajustando os coeficientes de correção. É esta experiência acumulada que nos permite dar ao cliente um preço honesto. Sim, pode ser superior ao dos concorrentes, mas é final, sem acordos adicionais de milhões no meio do projeto.
Além da retrospectiva, existe outro processo sem o qual o engenheiro de pre-sales perde rapidamente a qualificação – atualização contínua do conhecimento. Reunimo-nos regularmente com os fornecedores, realizamos testes internos de produtos, fazemos treinamento de engenharia, participamos de conferências do setor, acompanhamos a comunidade e trocamos insights. A comunicação regular com os líderes técnicos dentro da empresa é igualmente importante. Eles são os primeiros a encontrar nuances que posteriormente determinam a precisão de nossos cálculos.
O que um Engenheiro de Pre-Sales Deve Saber Fazer
Resumindo, compilei uma lista completa de tarefas para um engenheiro de pre-sales em cibersegurança. Se você está considerando esta função ou quer entender o quão preparado você está para ela, percorra os pontos.
Trabalho com o cliente
Identificação e esclarecimento das necessidades do cliente.
Comunicação com especialistas técnicos do cliente, realização de apresentações e demonstrações.
Defesa da solução técnica perante o cliente.
Trabalho com up-sale e cross-sale: o cliente nem sempre expressa ou conhece todas as suas dores.
Projeto e Cálculos
Seleção de equipamentos, licenças e módulos de suporte (formação de uma especificação).
Decomposição do trabalho e cálculo dos custos de mão de obra.
Preparação da parte técnica da proposta comercial e descrição do trabalho.
Preparação de uma especificação técnica e/ou conceito.
Pilotos e Demonstrações
Organização e realização de testes piloto.
Preparação de estandes de demonstração para apresentação de soluções.
Preparação da documentação piloto: regulamento, ПМИ, relatório, justificativa financeira.
Comunicações e Coordenação
Negociações técnicas com fornecedores.
Construção de relacionamentos com distribuidores e fornecedores para organizar pilotos.
Coordenação da equipe de pre-sales: distribuição de tarefas, coleta de resultados.
Conexão de colegas de departamentos adjacentes em projetos complexos.
Análise e Desenvolvimento
Análise retrospectiva "plano/fato" dos custos de mão de obra.
Rastreamento da conversão e trabalho com o funil de vendas.
Preenchimento da base de conhecimento de pre-sales: artefatos, casos, modelos.
Atualização da experiência: reuniões com fornecedores, conferências, monitoramento de ameaças.
Geração de ideias: novas ofertas "prontas para uso", conjuntos complexos de soluções.
Promoção de serviços em plataformas externas: apresentações, artigos, eventos.
Conclusão
Me arrependo de ter pendurado o cabo do console em um prego? Não. A transição para o pre-sales técnico não é uma perda de qualificação, uma palavra mais correta seria conversão. Você troca a profundidade do conhecimento de uma tecnologia pela amplitude de uma visão de todo o mercado e pela capacidade de influenciar a arquitetura antes mesmo do primeiro parafuso ser apertado no rack. Esta transição significa que por trás de cada hardware você começa a ver um processo de negócios, por trás de cada licença – a dor de alguém e por trás de cada linha de especificação – as futuras noites sem dormir (ou a ausência delas) da equipe de implementação.
Espero ter dado a você uma ideia mais clara do trabalho de um engenheiro de pre-sales e, possivelmente, até o interessou. Se sim, aqui está um pequeno teste, porque habilidades são uma coisa, elas são adquiridas, e a predisposição para o trabalho é outra.
Você se sente apertado dentro dos limites de uma tecnologia?
Configurar o NGFW pela centésima vez ficou chato. Eu quero entender como ele se encaixa no ecossistema: proteção de contêineres, integração com a sandbox, razões para escolher este fornecedor em particular.
Você quer ver o Big Picture?
Irrita quando trazem um pedaço de tarefa ("encaminhar VLAN") sem contexto. Atrai desenhar diagramas do núcleo da rede aos pontos finais.
Você gosta de traduzir de "técnico" para "humano"?
Explicar ao cliente por que ele não precisa de um hardware separado não é uma tortura, mas um prazer.
Você está pronto para trocar o CLI pelo Excel?
A especificação para o sucesso do projeto é mais importante do que um script perfeitamente escrito. Se este pensamento não causa dor física, você está no caminho certo.
Você percebe o que está faltando?
O cliente veio para um firewall e você já está pensando: "O tráfego de e-mail deles é filtrado? Quem protege os contêineres?" A capacidade de ver as necessidades que o cliente ainda não percebeu se converte bem em up-sale e cross-sale.
Se você marcar mais de três "sim", parece que você já está apertado em uma tecnologia. Talvez seja hora de mudar a escala e, em vez de um projeto e algumas tecnologias, trabalhar com todo o mercado.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Olá, pessoal do MundiX! Aqui é Vladislav Permyakov, engenheiro de pre-sales sênior da K2 Cyber Security.
Sejamos honestos: na visão de mundo do engenheiro médio, qualquer pessoa com o prefixo "Sale" (Vendas) provoca mais irritação do que simpatia. Não porque "vendedores são ruins", mas porque uma bela ideia comercial muitas vezes não resiste ao choque com a realidade. Por exemplo, um vendedor chega radiante, coloca um contrato assinado na mesa e diz: "Vendemos todo o nosso portfólio para eles!". Você abre a especificação, olha para a infraestrutura do cliente e percebe que essa gambiarra não vai funcionar. O parque de servidores está desatualizado, os canais de comunicação não suportam o tráfego e ninguém verificou a compatibilidade com o software legado. Mas o vendedor já está fechando um novo negócio, e você precisa fazer funcionar uma solução que tecnicamente não se encaixa nas tarefas do cliente.
A qualidade da implementação e a vida dos engenheiros dependem muito do que foi acordado na fase de vendas. Em algum momento, quis assumir o controle disso e, de repente, me vi no "lado sombrio" – tornei-me um engenheiro de pre-sales e reuni todo um departamento de desertores como eu.
O que faz um engenheiro de Pre-Sales?
Um engenheiro de pre-sales é, antes de tudo, um arquiteto que conhece os produtos do mercado de cibersegurança e suas características técnicas, analisa o estado atual da proteção do cliente e projeta soluções que aumentarão o nível de segurança da infraestrutura. Em segundo lugar, é uma pessoa com habilidades de comunicação com especialistas e gestores de diferentes níveis e com compreensão da componente financeira do negócio.
Para entender por que essa pessoa é necessária, basta olhar para o esquema desatualizado que ainda é encontrado em algumas empresas. Nele, o processo de vendas é gerido por um vendedor que sabe abrir portas para os gabinetes dos altos executivos, mas não entende a arquitetura das soluções.
Quando um cliente envia uma especificação técnica, faz perguntas técnicas específicas ou pede para avaliar uma opção de implementação, o vendedor geralmente envolve o primeiro engenheiro que encontra e pede para "estimar rapidamente a composição da solução". É improvável que um engenheiro, que está ocupado com um projeto atual e depurando um bug crítico, consiga mergulhar totalmente na tarefa. Na melhor das hipóteses, ele esboçará rapidamente uma especificação e uma estimativa de mão de obra com base em informações incompletas. Como resultado, o cliente recebe um estudo não muito preciso e os engenheiros acabam desenvolvendo uma aversão persistente à palavra "pre-sales".
Na verdade, 70% do pre-sales na nossa área é pura engenharia e arquitetura. Para ser eficaz nesta posição, é preciso conhecer o mercado de cibersegurança em toda a sua diversidade. Só no nosso portfólio, existem mais de 200 produtos, e todos eles precisam ser conhecidos ao nível das características arquitetónicas. Um "vendedor" puro e simples simplesmente não se lembrará das nuances de compatibilidade. Só uma pessoa que tenha lidado com estas caixas com as próprias mãos pode dizer o que se esconde por detrás das promessas do fornecedor. Portanto, é bom quando as pessoas passam de engenheiros de implementação para pre-sales: a experiência de projetos reais permite-lhes trabalhar detalhadamente nos custos de mão de obra e sentir as nuances que não podem ser lidas em nenhuma folha de dados.
Como engenheiro de pre-sales, desempenho o papel de elo de ligação, ou seja, pego na "ideia" do cliente e no "orçamento planeado" e transformo-os num cenário de trabalho. Verifico a viabilidade técnica, recolho as especificações, descrevo como é que vamos fazer isso numa proposta técnica. Transformo o abstrato "quero" em concreto "quanto custa e quais são os riscos". Se eu cometer um erro nos cálculos, a equipe de implementação terá que pagar com os seus nervos.
O Pipeline: Do Pedido Inicial à Proposta Comercial
Pode parecer que o pre-sales é uma grande reunião com o cliente, mas, na verdade, este trabalho pode ser dividido em 8 etapas.
Etapa zero – qualificação do pedido. O vendedor avalia de forma independente o quão real é o negócio, se existe um orçamento, se o perfil do cliente corresponde às nossas competências. A qualificação é aprovada. E agora?
Se o lead for adequado, começa a coleta de dados originais. O vendedor pode vir com documentação de concurso, uma especificação técnica de 200 páginas ou uma mensagem no Telegram da série "o cliente quer algo sobre firewalls, vou esclarecer o orçamento". Os dados de entrada quase nunca estão completos, portanto, a primeira tarefa do engenheiro de pre-sales é estruturar as informações dispersas. Para isso, temos questionários para cada tipo de solução, que ajudam a não perder informações críticas, como orçamento, prazos, arquitetura atual e características da infraestrutura.
Em seguida – análise primária. O engenheiro de pre-sales determina quais tipos de soluções estão envolvidos no projeto, avalia o que pode trabalhar sozinho e onde será necessário envolver engenheiros de práticas especializadas ou um arquiteto. Se o projeto for complexo (mais de duas ou três soluções de diferentes fornecedores ou uma arquitetura complexa), então não se pode prescindir de um arquiteto. É importante conhecer a sua equipe e as unidades adjacentes: num projeto complexo, o engenheiro de pre-sales deve entender quais colegas envolver.
Em seguida, há uma reunião interna da equipe: verificamos a compreensão da tarefa, distribuímos funções e preparamos perguntas para o cliente.
Depois, há uma reunião com o cliente, onde coletamos as informações de entrada que faltam.
Com base nas informações coletadas, preparamos especificações e estimamos os custos de mão de obra (mais sobre isso abaixo).
Tudo é reunido em um único pacote, após o qual o vendedor elabora uma proposta comercial.
Em seguida, realizamos a defesa da proposta comercial perante o cliente.
Às vezes, após a defesa da proposta comercial, preparamos um design conceitual do projeto-alvo: trabalhamos na arquitetura, descrevemos o estado-alvo e os requisitos de implementação. Isso aumenta significativamente as chances de vencer o concurso.
É importante notar que existem diferentes tipos de pre-sales, e o conjunto de documentos depende do pedido específico. Às vezes, o cliente precisa apenas do fornecimento de equipamentos, então preparamos uma especificação. Às vezes, apenas a implementação: o equipamento já foi comprado e precisamos de mãos e experiência, e então o principal documento é o cálculo dos custos de mão de obra. Mas, na maioria das vezes, os projetos envolvem tanto o fornecimento quanto a implementação, então calculamos ambos. Existem projetos-piloto, onde antes de celebrar um contrato, é necessário confirmar a operabilidade da solução e a integração bem-sucedida na infraestrutura do cliente. E, finalmente, o orçamento – os chamados "pre-sales longos": o cliente aloca um orçamento para o próximo ano, e precisamos dar uma estimativa de alto nível, à qual ele retornará em alguns meses. O tipo de pre-sales determina quais perguntas fazer e quais documentos preparar.
Os Documentos Essenciais
Toda a nossa metodologia se baseia em dois documentos:
Especificação (BOM, Bill of Materials) – uma lista de todos os equipamentos, materiais e licenças.
Cada fornecedor tem seu próprio método de elaboração de uma especificação: alguns têm um preço em acesso aberto, outros precisam solicitar preços. Em projetos complexos, o engenheiro de pre-sales coleta todas as especificações, verifica sua correção, verifica com o gerente técnico, se necessário, e envia para o vendedor em um único pacote.
Calculadora de Custos de Mão de Obra (ТРЗ) – tabelas com fórmulas, onde cada etapa do trabalho é descrita de acordo com o princípio: implantação de uma máquina virtual – 2 horas, escrita de uma política de segurança – mais 4 horas.
Cada solução é acompanhada por um arquivo ТРЗ separado. Usamos modelos da base de conhecimento, mas as horas neles são médias e precisam ser revisadas para cada projeto.
Etapas clássicas de implementação: levantamento, projeto, trabalhos de comissionamento, operação experimental e testes de aceitação. E cada etapa deve ter um documento de fechamento. Alocamos horas tanto para um engenheiro de nível médio quanto para um engenheiro líder (geralmente em uma proporção de 70/30, mas depende da complexidade), e também levamos em consideração o local de trabalho em cada etapa: por exemplo, o levantamento é realizado pessoalmente e o projeto, como regra, remotamente.
Uma história separada são as condições e restrições. Se o ТРЗ indicar o trabalho "criação de regras de firewall" sem a ressalva "não mais de 50 regras", o cliente tem o direito de exigir qualquer quantidade. Portanto, não apenas fixamos as restrições no cálculo dos custos de mão de obra, mas também garantimos que elas entrem na proposta comercial e na especificação técnica do contrato. Isso protege ambos os lados: todos entendem igualmente o escopo do trabalho.
Quando preencho essa tabela, estou realmente construindo um modelo virtual do futuro projeto. Mas até mesmo a calculadora mais precisa é inútil se houver informações de entrada incorretas e é aqui que começam os 30% restantes do pre-sales técnico.
Realizando o Diagnóstico
Os clientes confundem regularmente "dor" (problema) e "pílula" (solução) e vêm até nós com um diagnóstico pronto. Temos que ligar o modo Dr. House e descobrir onde realmente dói.
Para que você entenda do que estou falando, aqui está um caso da prática. Um grande cliente vem com um pedido específico: "Precisamos de um sistema de prevenção de intrusões (IPS), um hardware separado". Um vendedor ruim nessa situação encontrará e venderá a caixa mais cara. Um engenheiro, por outro lado, começará a cavar nessa situação.
"E o que você tem atualmente no perímetro? Qual NGFW você usa?" Acontece que eles têm um poderoso cluster NGFW de um fornecedor de ponta e aqui está o mais interessante: "Você sabe que já tem IPS? Simplesmente não está ativado por uma licença ou está desativado nas políticas para não sobrecarregar a CPU". Como resultado, em vez de um novo hardware por 5 milhões, vendemos uma licença para ativar a blade IPS e ajustar as assinaturas para não cortar o tráfego legítimo. Menos 90% do orçamento para hardware, mais um cliente que retorna regularmente com novas tarefas.
Calculando os Custos de Mão de Obra
Nas apresentações dos fornecedores, tudo é simples: "passo 1, passo 2 – e tudo funciona". Na realidade, é necessário descrever detalhadamente quais trabalhos cada etapa do projeto inclui. Em cada caso específico, a lista de trabalhos pode variar significativamente.
Uma história separada são as diferenças nas abordagens à documentação. As empresas comerciais jovens geralmente solicitam documentação de projeto utilitária, enquanto as estruturas estatais têm requisitos muito mais amplos para a composição, forma e conteúdo dos documentos. Isso afeta diretamente os custos de mão de obra. E, finalmente, cada cliente tem sua própria infraestrutura única e suas próprias características, portanto, o cálculo do ТРЗ será único.
Outro ponto não óbvio são os trabalhos ocultos. Os novatos geralmente esquecem de calcular o tempo na estrada (um objeto em uma zona industrial fora da cidade significa menos 4 horas de tempo de trabalho de um engenheiro na estrada), auditoria (antes de instalar algo novo, você precisa entender como o antigo funciona) e assim por diante.
A propósito, sobre a auditoria: o nível de levantamento precisa ser pensado separadamente. Se o cliente não tem uma compreensão de sua própria infraestrutura – inventário atualizado e diagramas de rede – então faremos esse trabalho. E para as etapas de levantamento e projeto, é necessário alocar significativamente mais horas do que no caso padrão.
E às vezes acontece que no início é simplesmente impossível avaliar o escopo exato do trabalho. Tínhamos um cliente que em um dia demitiu toda a equipe de TI, batendo a porta e nem mesmo passando os acessos. Era necessário implementar o NGFW, mas havia o risco de quebrar o mecanismo de publicação de serviços e simplesmente não havia um diagrama de rede. Na verdade, trabalhamos no formato black box: levantamos todos os processos de negócios do zero, identificamos qual tráfego era legítimo e qual não, e só depois disso formamos políticas de segurança. Esse caso foi difícil, pois muitos obstáculos surgiram, mas o cliente foi resgatado.
Iniciando o Piloto
O piloto também não é um passeio inofensivo. Digamos que o cliente esteja em dúvida: "Seu sistema DLP realmente não vai derrubar nossa rede? Vamos tentar". Pegamos um estande piloto com recursos moderados, colocamos 10 usuários do grupo de teste lá e tudo funciona perfeitamente. E então o cliente, embriagado com o sucesso, se oferece para implantar imediatamente nossa solução em toda a fábrica. O hardware está lá, a licença ainda é válida por um mês. Por que esperar?
Explicamos a diferença entre a arquitetura piloto e a arquitetura-alvo: este hardware é projetado para testes funcionais, não para testes de carga. Se você colocar tráfego de produção lá, o servidor vai parar em alguns minutos. Portanto, ao me preparar para o piloto, calculo com antecedência: se o cliente quiser deixar isso, qual hardware devo trazer inicialmente? Às vezes, trazemos imediatamente uma caixa poderosa.
Muitos tratam os pilotos com negligência, mas, na verdade, o piloto não é muito diferente de uma implementação completa: é necessário um regulamento, um plano de teste, um programa e metodologia de teste (ПМИ), documentos de relatório e uma justificativa financeira para a transição para a solução-alvo. Também mantemos o cliente e o fornecedor informados sobre o status do piloto – isso ajuda a identificar e eliminar problemas a tempo, em vez de acumulá-los até o final.
Matemática e Retrospectiva
Nas vendas, existe uma ilusão perigosa: assim que o contrato é assinado, o trabalho é considerado concluído. Para um engenheiro de pre-sales, este não é o fim. Chamamos isso de análise retrospectiva (Plan vs Fact). Digamos que eu calculei um projeto de implementação de VPN para 40 horas, mas na verdade acabou sendo 120. O projeto foi concluído, o cliente está satisfeito, mas para a empresa este projeto não é lucrativo.
Nós nos reunimos como uma equipe e começamos uma investigação. Geralmente existem três opções:
Erro de pre-sales, que não levou em consideração a arquitetura específica dos aplicativos. Conclusão: para este tipo de tarefa, introduzimos um coeficiente de complexidade e alocamos tempo adicional.
Erro de implementação, ou seja, a tarefa era padrão, mas exigia maior competência dos engenheiros. Portanto, é necessário realizar treinamento adicional.
Força maior ou defeito do equipamento – esses riscos devem ser considerados no contrato.
Com base nos resultados dessas análises, estamos constantemente aprimorando as calculadoras e ajustando os coeficientes de correção. É esta experiência acumulada que nos permite dar ao cliente um preço honesto. Sim, pode ser superior ao dos concorrentes, mas é final, sem acordos adicionais de milhões no meio do projeto.
Além da retrospectiva, existe outro processo sem o qual o engenheiro de pre-sales perde rapidamente a qualificação – atualização contínua do conhecimento. Reunimo-nos regularmente com os fornecedores, realizamos testes internos de produtos, fazemos treinamento de engenharia, participamos de conferências do setor, acompanhamos a comunidade e trocamos insights. A comunicação regular com os líderes técnicos dentro da empresa é igualmente importante. Eles são os primeiros a encontrar nuances que posteriormente determinam a precisão de nossos cálculos.
O que um Engenheiro de Pre-Sales Deve Saber Fazer
Resumindo, compilei uma lista completa de tarefas para um engenheiro de pre-sales em cibersegurança. Se você está considerando esta função ou quer entender o quão preparado você está para ela, percorra os pontos.
Trabalho com o cliente
Identificação e esclarecimento das necessidades do cliente.
Comunicação com especialistas técnicos do cliente, realização de apresentações e demonstrações.
Defesa da solução técnica perante o cliente.
Trabalho com up-sale e cross-sale: o cliente nem sempre expressa ou conhece todas as suas dores.
Projeto e Cálculos
Seleção de equipamentos, licenças e módulos de suporte (formação de uma especificação).
Decomposição do trabalho e cálculo dos custos de mão de obra.
Preparação da parte técnica da proposta comercial e descrição do trabalho.
Preparação de uma especificação técnica e/ou conceito.
Pilotos e Demonstrações
Organização e realização de testes piloto.
Preparação de estandes de demonstração para apresentação de soluções.
Preparação da documentação piloto: regulamento, ПМИ, relatório, justificativa financeira.
Comunicações e Coordenação
Negociações técnicas com fornecedores.
Construção de relacionamentos com distribuidores e fornecedores para organizar pilotos.
Coordenação da equipe de pre-sales: distribuição de tarefas, coleta de resultados.
Conexão de colegas de departamentos adjacentes em projetos complexos.
Análise e Desenvolvimento
Análise retrospectiva "plano/fato" dos custos de mão de obra.
Rastreamento da conversão e trabalho com o funil de vendas.
Preenchimento da base de conhecimento de pre-sales: artefatos, casos, modelos.
Atualização da experiência: reuniões com fornecedores, conferências, monitoramento de ameaças.
Geração de ideias: novas ofertas "prontas para uso", conjuntos complexos de soluções.
Promoção de serviços em plataformas externas: apresentações, artigos, eventos.
Conclusão
Me arrependo de ter pendurado o cabo do console em um prego? Não. A transição para o pre-sales técnico não é uma perda de qualificação, uma palavra mais correta seria conversão. Você troca a profundidade do conhecimento de uma tecnologia pela amplitude de uma visão de todo o mercado e pela capacidade de influenciar a arquitetura antes mesmo do primeiro parafuso ser apertado no rack. Esta transição significa que por trás de cada hardware você começa a ver um processo de negócios, por trás de cada licença – a dor de alguém e por trás de cada linha de especificação – as futuras noites sem dormir (ou a ausência delas) da equipe de implementação.
Espero ter dado a você uma ideia mais clara do trabalho de um engenheiro de pre-sales e, possivelmente, até o interessou. Se sim, aqui está um pequeno teste, porque habilidades são uma coisa, elas são adquiridas, e a predisposição para o trabalho é outra.
Você se sente apertado dentro dos limites de uma tecnologia?
Configurar o NGFW pela centésima vez ficou chato. Eu quero entender como ele se encaixa no ecossistema: proteção de contêineres, integração com a sandbox, razões para escolher este fornecedor em particular.
Você quer ver o Big Picture?
Irrita quando trazem um pedaço de tarefa ("encaminhar VLAN") sem contexto. Atrai desenhar diagramas do núcleo da rede aos pontos finais.
Você gosta de traduzir de "técnico" para "humano"?
Explicar ao cliente por que ele não precisa de um hardware separado não é uma tortura, mas um prazer.
Você está pronto para trocar o CLI pelo Excel?
A especificação para o sucesso do projeto é mais importante do que um script perfeitamente escrito. Se este pensamento não causa dor física, você está no caminho certo.
Você percebe o que está faltando?
O cliente veio para um firewall e você já está pensando: "O tráfego de e-mail deles é filtrado? Quem protege os contêineres?" A capacidade de ver as necessidades que o cliente ainda não percebeu se converte bem em up-sale e cross-sale.
Se você marcar mais de três "sim", parece que você já está apertado em uma tecnologia. Talvez seja hora de mudar a escala e, em vez de um projeto e algumas tecnologias, trabalhar com todo o mercado.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
