Os 5 principais desafios no processo de desenvolvimento de produtos de infraestrutura de e-mail

Publicados: 2023-03-20

A infraestrutura de e-mail é o sistema interconectado que permite o envio, recebimento e armazenamento de mensagens eletrônicas. Como tal, desempenha um papel vital na facilitação da troca de informações, seja B2B ou B2C.

Nesse sentido, o Radicati Group Inc. estima que o número total de e-mails enviados chegará perto de 400 bilhões em 2027. E o número de usuários em todo o mundo deve chegar a 5 bilhões, no mesmo ano.

Como o volume de tráfego de e-mail continua crescendo, é difícil negar a importância de ter uma infraestrutura de e-mail robusta e confiável.

No entanto, desenvolver e manter uma infra-estrutura de e-mail confiável tem seus problemas. Neste artigo, discutimos os cinco principais desafios que as organizações enfrentam no processo de desenvolvimento de produtos de infraestrutura de e-mail e fornecemos soluções práticas para superá-los.

1: Escalabilidade

O desafio

Como o tráfego continua crescendo, a infraestrutura de e-mail pode ter dificuldades para lidar com a carga. As empresas precisam tomar medidas preventivas para acomodar o crescimento e evitar interrupções no serviço.

O brainstorming das medidas em paralelo com o desenvolvimento do conceito é favorável. Caso contrário, os desenvolvedores precisam fazer isso com o lançamento do MVP ou correm o risco de:

  • Produtividade perdida
  • Diminuição da satisfação do cliente
  • Perdas financeiras potenciais
  • Queda nas classificações de autoridade de domínio
  • Queda na reputação do remetente

As soluções:

  • Infraestrutura baseada em nuvem
  • Balanceamento de carga

O uso de infraestrutura baseada em nuvem

Com infraestrutura baseada em nuvem, os desenvolvedores aproveitam a escalabilidade e a confiabilidade dos serviços de e-mail de terceiros. Por sua vez, eles garantem os recursos necessários para atender às crescentes necessidades dos clientes.

Parece promissor, mas como isso realmente funciona?

Os serviços de e-mail de terceiros usam centros de dados grandes e centralizados para armazenar e processar dados. Assim, as empresas de desenvolvimento de software podem aproveitar as vantagens das tecnologias e recursos mais recentes sem investir em seus próprios. E isso ajuda a matar dois coelhos com uma cajadada só:

  1. A abordagem reduz muito os custos operacionais.
  2. Ele também fornece às organizações uma solução escalável para atender às suas crescentes necessidades.

O importante a enfatizar aqui é que você deve desenvolver uma infraestrutura baseada em nuvem passo a passo. Isso significa que é melhor começar a executar algumas tarefas na nuvem e dimensionar as próprias tarefas com base na carga atual (neste caso, o volume de e-mails ou solicitações do usuário).

Mas as tarefas baseadas em nuvem não devem ser dimensionadas ad hoc, é crucial determinar a respectiva estratégia de desenvolvimento de produto. Ainda mais importante, você precisa saber se existem desafios e gargalos associados a isso.

A implementação do balanceamento de carga

Antes de se aprofundar um pouco mais, lembre-se de que o balanceamento de carga deve ser implementado junto com a infraestrutura baseada em nuvem. Na melhor das hipóteses, dentro de uma fase de desenvolvimento do produto.

Agora, o balanceamento de carga refere-se à distribuição de cargas de trabalho em várias arquiteturas e tarefas na nuvem. O principal benefício é que o produto existente se torna capaz de lidar com o aumento do volume, mesmo em picos de tráfego.

Como as cargas de trabalho são distribuídas em vários servidores, nenhum servidor é limitado pelo volume de tráfego de e-mail. Portanto, as chances de interrupções de serviço e gargalos são significativamente menores.

Melhor ainda, os algoritmos de balanceamento de carga podem ser usados ​​para ajustar dinamicamente a distribuição de cargas de trabalho, geralmente com base em dois fatores:

  1. O número de solicitações.
  2. O poder de processamento de cada servidor.

Construindo uma baita plataforma de acomodação

Em 2012, o processo de desenvolvimento de produtos do Airbnb estava em um estágio crucial.

Eles estavam atingindo o público-alvo bem na cabeça, escalando toda a plataforma. Mas o feedback do usuário revelou um número alarmante de casos extremos envolvendo solicitações de alteração, disputas e reembolsos. Na época, tudo isso era tratado manualmente por e-mail, sem back-end para dar suporte ao processamento de solicitações, o que colocava uma pressão significativa no dimensionamento dos negócios.

O Airbnb estava enfrentando uma escolha arriscada – contratar mais de 1.000 pessoas em um ano ou construir uma estrutura automatizada para lidar com casos extremos.

Sim, eles escolheram o último.

Jonathan Golden, gerente de produto do Airbnb na época, teve que priorizar impiedosamente. O objetivo principal era criar um plano para uma solução de nuvem automatizada (estrutura de back-end) que manuseasse e categorizasse os casos extremos.

Com a estrutura em vigor, o Airbnb foi desbloqueado rapidamente e continuou escalando de 300% a 600% ao ano. Observe que esses percentuais se referem ao crescimento exponencial inicial do Airbnb.

No entanto, há mais conclusões de desenvolvimento de produto neste exemplo do que apenas mover tudo para a nuvem e automatizar fluxos de trabalho.

  • É essencial primeiro lidar com um desafio técnico manualmente. Caso contrário, os desenvolvedores podem não estar bem cientes dos problemas de raiz.
  • Uma empresa não deve esperar muito antes de aplicar automação de dimensionamento, balanceamento de carga ou qualquer outra coisa. Se você não fizer isso a tempo, é provável que os desafios cresçam tanto que se torne significativamente mais difícil superá-los.
  • Sempre tente criar uma solução ou estrutura que possa ser aplicada a outras questões no roadmap do produto. Isso torna suas equipes muito mais ágeis.

2: Segurança

O desafio

A segurança da infraestrutura de e-mail, ou a falta dela, é vital porque afeta diretamente a capacidade das organizações de se comunicarem efetivamente com clientes em potencial.

Uma equipe de desenvolvimento de produto precisa enfrentar esse desafio em um estágio inicial, bem antes do produto mínimo viável. Mas não para por aí. Auditorias de segurança regulares devem ser uma prioridade, mesmo se você estiver lidando com um produto acabado.

Como as informações confidenciais geralmente são trocadas por e-mail, uma violação de segurança pode resultar na exposição de informações confidenciais. Isso pode ter sérias consequências para as organizações, incluindo danos à reputação, perda da confiança do cliente e possíveis repercussões legais.

Além disso, é importante que todas as equipes entendam os possíveis riscos de segurança para evitar violações que possam burlar a criptografia e os protocolos de segurança. Um desses riscos é a engenharia social, mas falaremos mais sobre isso em uma das seções a seguir.

As soluções:

  • Criptografia
  • Protocolos seguros
  • Atualizações regulares de medidas de segurança

Protocolos seguros, como SSL e TLS, fornecem serviços de criptografia e autenticação para dados de e-mail em trânsito. Devido a isso, eles podem ser considerados como a primeira linha de defesa no roteiro do produto de infraestrutura de e-mail. Além disso, as organizações devem revisar e atualizar regularmente as medidas de segurança interna.

Como?

Por exemplo, uma empresa que desenvolve o software precisa estabelecer políticas internas para engenheiros e outras partes interessadas para limitar o acesso à base de código, gits, etc. Ao mesmo tempo, a empresa deve ter protocolos claros sobre como e por que alguém pode receber maior privilégios de acesso.

As equipes de desenvolvimento geralmente usam o princípio de lista de privilégios para obter um nível mais alto de segurança. Isso significa que mais acesso é fornecido sob demanda e muito poucas pessoas têm acesso a tudo.

Mencionamos anteriormente SSL e TLS que criptografam dados em movimento (dados em trânsito). Mas as empresas também precisam considerar a criptografia de dados em repouso e estabelecer diferentes níveis de acesso a esses dados.

“Prometo mindinho, não vamos hackear você!”

Este é um caso de negócios negativo, mas mostra claramente que sempre há dois aspectos da segurança – o software e as pessoas.

Em janeiro de 2023, o Mailchimp sofreu uma violação de segurança (a terceira em 12 meses), expondo os dados confidenciais de 133 clientes. E a engenharia social foi a estratégia que os golpistas usaram para obter acesso a informações confidenciais.

Basicamente, isso significava que os fraudadores online usavam funcionários inocentes e provavelmente inexperientes do Mailchimp para obter acesso a dados protegidos. Os golpistas roubaram as credenciais dos funcionários, invadindo as pessoas, não o sistema em si. No entanto, as informações confidenciais de cerca de 133 clientes foram expostas.

O resultado final é que o aspecto técnico da segurança precisa ser à prova de balas. Mas, ao mesmo tempo, uma empresa precisa estabelecer procedimentos e educar os funcionários sobre como evitar se tornar phishing ou qualquer outro tipo de vítima online.

3: Confiabilidade

O desafio

A confiabilidade determina a capacidade de um sistema funcionar corretamente e consistentemente ao longo do tempo. Como tal, está entre os maiores obstáculos durante diferentes iterações de um novo processo de desenvolvimento de produto.

Por que?

Sem confiabilidade, os usuários não podem ter certeza de que seus e-mails serão entregues e recebidos conforme o esperado, acabando por destruir a proposta de valor. Claro, esse é o caso da infraestrutura de e-mail, mas há um quadro maior aqui.

A confiabilidade do produto final em SaaS impacta diretamente a reputação da marca e sua capacidade de entrega. Seja um MVP ou um produto já bem-sucedido, ele precisa suportar vários tipos de falhas, como aumento do uso de RAM, picos de solicitações de usuários, cargas inesperadas de infraestrutura etc.

A solução:

  • Implementação de sistemas de redundância e backup
  • Monitoramento regular da infraestrutura

A redundância envolve ter várias cópias dos mesmos dados armazenados em locais diferentes. Portanto, se um sistema falhar, haverá um backup a ser usado. Várias tecnologias permitem isso, principalmente o balanceamento de carga, onde os e-mails são distribuídos em vários servidores para reduzir o risco de falha.

Em seguida, o monitoramento regular da infraestrutura fornece métricas que permitem aos desenvolvedores detectar e resolver problemas antes que se tornem problemas reais. Isso pode ser feito com ferramentas de monitoramento e verificações regulares do sistema. Ou, às vezes, as equipes de desenvolvimento podem aplicar a análise SWOT durante o teste de conceito para determinar as melhores abordagens.

Falando em monitoramento, é melhor que os desenvolvedores criem alarmes além do monitoramento. Por exemplo, os alarmes devem ser definidos para as seguintes circunstâncias:

  1. Se os processos começarem a consumir mais memória.
  2. Se houver problemas específicos de processamento/computação de dados.
  3. No caso de 500 respostas de código.

Esses alarmes estão relacionados ao suporte de arquitetura interna e gerenciamento de produtos de plantão; ambos devem ser estabelecidos durante o processo de desenvolvimento de software ou com o lançamento do produto soft.

Em inglês simples, quando há um alarme acionado por um evento preocupante, um engenheiro deve pular direto para ele, mesmo que seja no meio da noite.

Como os gigantes fizeram isso

O próprio Google é um ótimo exemplo de estratégia de design de produto que superou com sucesso os desafios de confiabilidade desde o início. Sua infraestrutura é projetada para apresentar vários níveis de redundância. Isso permite que o gigante do mecanismo de pesquisa garanta que os e-mails dos usuários sejam entregues e recebidos conforme o esperado, mesmo no caso de uma falha interna.

Outro exemplo é a Microsoft, que implementou uma infraestrutura de e-mail altamente confiável por meio do uso de balanceamento de carga e sistemas de backup. Essas medidas ajudaram a Microsoft a garantir que seu serviço de e-mail permaneça altamente confiável, mesmo diante de um crescimento significativo e aumento da demanda.

Mas, infelizmente, não é mais assim. Durante o ciclo de vida do produto, houve alguns pontos de inflexão em que a Microsoft pode ter falhado em realizar pesquisas de mercado e análises de concorrentes adequadas — mais sobre isso na seção Gerenciando expectativas de desempenho .

4: Interoperabilidade

O desafio

A interoperabilidade indica a capacidade da infraestrutura de e-mail, ou qualquer serviço SaaS, de se integrar e funcionar bem com outros aplicativos.

Normalmente, as integrações devem incluir:

  1. Gestão de relacionamento com o cliente (CRM)
  2. Planejamento de recursos empresariais (ERP)
  3. Armazenamento de dados

Qual é o benefício?

A capacidade de trocar informações perfeitamente entre diferentes aplicativos ajuda as empresas a tomar decisões informadas e baseadas em dados. Além disso, permite simplificar os processos relacionados ao produto. O bônus é que a alta interoperabilidade também contribui para uma experiência de usuário muito melhor.

Apenas observe que esse aspecto deve ser abordado ao fazer um brainstorming do conceito do produto. E vale a pena pesar as opções de integração em relação ao que está disponível no mercado-alvo.

A solução:

  • Padrões abertos
  • Compatibilidade entre plataformas

Padrões abertos são especificações publicamente disponíveis que permitem que diferentes sistemas funcionem juntos.

Os principais padrões abertos com infraestrutura de email incluem Simple Mail Transfer Protocol (SMTP), Post Office Protocol versão 3 (POP3) e Internet Message Access Protocol (IMAP).

Quanto à compatibilidade, a infraestrutura de e-mail deve ser projetada para funcionar com diferentes sistemas operacionais (Windows, macOS e Linux), bem como diferentes navegadores da web (Google Chrome, Mozilla Firefox, Safari, etc).

No entanto, a incorporação de padrões abertos e a garantia da compatibilidade entre plataformas não são isentas de desafios. Pegue o SMTP, por exemplo, os desenvolvedores geralmente precisam fazer ajustes específicos nele e talvez até adicionar criptografia. Para obter facilmente essa e outras correções específicas do produto, é aconselhável usar plataformas interconectadas, como AWS.

Por fim, as equipes de desenvolvimento precisam prestar muita atenção a assinaturas, soluções de spam, registros DNS e muito mais, relacionadas ao bom funcionamento de seu software com integrações de terceiros.

Em poucas palavras, isso se resume a seguir os formatos e protocolos padrão em cada etapa do processo de desenvolvimento do produto. Posteriormente, os engenheiros podem personalizar os fluxos de trabalho de back-end e front-end quando necessário.

Corte-nos um pouco de Slack

Se você acredita que o Slack conseguiu reinventar a forma como colaboramos, não se engana. Mas a questão é como eles fizeram isso.

Vamos desconsiderar o fato de que o Slack tinha uma solução estável no estágio de entrada no mercado. E vamos esquecer uma estratégia de marketing espirituosa que conseguiu converter hordas de trabalhadores de TI frustrados. O importante aqui é o que acontece após a conversão.

Em primeiro lugar, a barra para entrar no Slack é muito baixa. No entanto, abrange a maioria dos casos de uso que você pode imaginar. Então, migrar suas equipes para o Slack é bastante simples. O gerenciamento de usuários é descomplicado e a lista de integrações é infinita…

Dependendo do tamanho e escopo do seu negócio, você pode conectar Jira, Notion, Coda, aplicativos do Google e outros para ter todas as notificações e canais de dados sob o mesmo teto. Tudo isso em dias ou mesmo horas.

O mais impressionante é que a interoperabilidade do Slack é praticamente definida e esquecida. Depois de integrar tudo o que você precisa, você estará sempre a um clique de uma fonte de dados ou comunicação. E essa experiência do usuário é difícil de rivalizar.

5: Gerenciando Expectativas de Desempenho

O desafio

O desafio de gerenciar as expectativas de desempenho é garantir que o produto atenda às necessidades e requisitos dos usuários finais. Por causa disso, é seguro equiparar as expectativas de desempenho com as expectativas do usuário, especialmente ao desenvolver SaaS.

Para ser claro, o sucesso de um produto de infraestrutura de e-mail, ou qualquer SaaS, depende muito de quão bem os usuários finais e clientes-alvo o percebem. Isto é – quão bem o produto satisfaz as expectativas de desempenho do usuário.

Com a crescente dependência do e-mail, os usuários esperam que a infraestrutura seja segura, rápida e confiável. Além disso, os usuários querem que seja:

  • Fácil de usar
  • Acessível a partir de vários dispositivos
  • Ser capaz de lidar com o tráfego de e-mail em escala

A solução:

  • teste
  • Otimização
  • Comunicação clara
  • Loops de feedback

Correndo o risco de afirmar o óbvio, testes regulares e otimização precisam ser parte integrante de qualquer processo de desenvolvimento de produto. Pode envolver a realização de pesquisas, grupos focais, testes A/B para coletar feedback do usuário, etc.

A comunicação clara anda de mãos dadas com os testes, pois ajuda a criar confiança e transparência. Frequentemente, a comunicação inclui atualizações públicas regulares sobre o processo de desenvolvimento, informando os usuários sobre mudanças na infraestrutura e abordando quaisquer preocupações de desempenho geradas pelo usuário.

Toda a comunicação e testes dão aos desenvolvedores um feedback qualificado do cliente que, por sua vez, auxilia no atendimento de suas necessidades e expectativas. A etapa crítica aqui é integrar o feedback fornecido aos processos de desenvolvimento do produto.

Simplesmente, isso significa estar atento a todas as desvantagens de um sistema. Talvez até fazendo análises de negócios para entender melhor qual metodologia aplicar para melhorar o produto sem prejudicar sua comercialização.

Em seguida, a etapa crucial é transformar todas as descobertas em tarefas e atualizações acionáveis ​​para simplificar ainda mais o seu software.

Mas, ao testar e monitorar seu aplicativo, algumas coisas devem ser lembradas. Por exemplo, testes de estresse determinam se o código está lento. No entanto, o fato de algo estar lento não exige uma atualização. As equipes de desenvolvimento precisam de uma compreensão sólida de quais atualizações são críticas para o desempenho e quais podem ser priorizadas para o uso ideal dos recursos.

A batalha dos gigantes

Conforme mencionado anteriormente, esta seção explora as áreas em que a Microsoft possivelmente falhou nas expectativas de desempenho, abrindo caminho para o sucesso dos concorrentes. Há um pouco de história nisso, envolvendo tanto a Apple quanto o Google.

Quando lançaram o MPP (Mail Privacy Protection) em setembro de 2021, a Apple já havia vencido o Google na participação de mercado de clientes de e-mail. Na época, a participação da Apple estava próxima a 59%, o Google estava em torno de 28%, mas o Outlook da Microsoft estava muito atrás, em cerca de 5%.

Agora, quais poderiam ser as razões pelas quais a Microsoft foi derrotada?

Para encontrar a resposta, devemos olhar um pouco mais para o passado.

O Google lançou o Gmail em 1º de abril, quase duas décadas atrás. E não demorou muito para a Microsoft perceber que não era uma piada de primeiro de abril. O pai do Windows se esforçou para permanecer dominante por cerca de dez anos. Mas uma vez que o Gmail assumiu o mercado em 2015, foi principalmente uma espiral descendente para o Outlook.

Mas por que?

É seguro argumentar que os motivos são expectativas de desempenho fracassadas. Basicamente, o Gmail era mais rápido e fácil de usar e oferecia uma interface muito mais simplificada. Juntamente com mais recursos e armazenamento muito maior (1 GB – 500 vezes mais do que o Outlook na época), não é de surpreender que o Gmail tenha vencido.

Avançando para hoje, está claro que o Google poderia estar em apuros semelhantes aos da Microsoft uma década atrás. Agora, a principal expectativa de desempenho que falhou é o rastreamento. Dado o número de e-mails de entrada, seja de marketing ou transacional, as pessoas preferem manter seus eventos de e-mail ocultos.

Claro, o fato de que está se tornando cada vez mais difícil rastrear taxas de abertura, geolocalização e dispositivos dá azia aos profissionais de marketing. Mas as estatísticas mostram que é exatamente isso que os usuários esperam.

As equipes de desenvolvimento de e-mail da Apple perceberam a tendência desde o início e foram as primeiras a oferecer uma solução viável para reduzir ao mínimo o ruído do e-mail. Esse tipo de expectativa de desempenho, monitoramento e atualizações podem levar a Apple a dominar o espaço do cliente de e-mail em um futuro previsível.

Construa bons produtos

Até agora, você deve ter uma compreensão sólida dos desafios críticos no processo de desenvolvimento de produtos. Para destacar, realmente não importa que tipo de produto você está desenvolvendo.

Os desafios descritos são agnósticos ao nicho e, em grande parte, ao ciclo de desenvolvimento do produto. Mesmo se você estiver apenas no estágio de concepção, certamente deseja que o produto seja seguro, confiável e escalável. Então, quando você chegar ao estágio inicial, não pare com a triagem e validação da ideia do produto.

Finalmente, é importante lembrar que o processo de desenvolvimento de produto requer muita pesquisa, análise e planejamento de implementação em cada etapa do caminho. A boa notícia é que este artigo forneceu um roteiro sólido e as principais áreas nas quais você deve se concentrar.

5 desafios de desenvolvimento de produtos de infraestrutura de e-mail