A BurnRate está impulsionando o sucesso da receita com o Blazor

Conheça Robert McLaws, um veterano em .NET e empresário experiente que tem paixão por ajudar as pessoas a terem sucesso. Ao longo de sua carreira, McLaws testemunhou como os capitalistas de risco (VCs) e suas centenas de bilhões em investimentos não conseguiram melhorar significativamente as taxas de sucesso das startups. Mesmo após 50 anos de investimentos de capital de risco, pelo menos 70% das empresas ainda fracassam em todos os estágios de crescimento.

Essa estatística alarmou McLaws. Assim, ele se propôs a ajudar os fundadores e líderes de receita a sistematizar seu processo de contratação e a traçar seu próprio curso de crescimento sem se preocupar com fórmulas de planilhas. Ele viu uma oportunidade para a tecnologia fazer alguns cálculos valiosos e específicos que tornariam o planejamento do crescimento escalável mais fácil e preciso.

Criando um algoritmo humano

Anos atrás, o McLaws criou uma estrutura de aplicativos usando ASP.NET para criar um produto de análise financeira no espaço de imóveis comerciais. A criação de modelos de capacidade para complexos de apartamentos coloca-o no caminho para se aprofundar nos modelos de capacidade de vendas de SaaS e como a capacidade humana para o trabalho afeta a capacidade de uma empresa de gerar receita.

Foi quando ele teve a ideia do BurnRate, um sistema de planejamento de receita, demanda e número de funcionários para equipes de entrada no mercado. McLaws sentiu que confiar na intuição e adivinhação para determinar os níveis de pessoal para as principais equipes de receita, como marketing, vendas e sucesso do cliente, não era um caminho sustentável para o crescimento.

Em vez disso, ele acreditava que havia uma ciência para isso: um algoritmo que poderia ajudar as empresas a crescerem de forma mais inteligente usando o que ele chamou de "Algoritmo de Pessoas". Como ele disse, "essas equipes [de sucesso do cliente, marketing e vendas] são responsáveis por trazer dinheiro para a empresa em primeiro lugar, portanto, era essencial fazer os cálculos corretamente e torná-los fáceis o suficiente para que as equipes de receita os usassem intuitivamente."

Escolhendo a stack tecnológica correta

A experiência de McLaws em matemática financeira o ensinou que linguagens de programação que usam matemática de ponto flutuante, como JavaScript, não eram suficientes para construir sistemas financeiros. A base desse algoritmo precisaria estar em C# para fornecer resultados confiáveis que pudessem ser validados de forma consistente.

Quando ele deixou sua empresa anterior para iniciar a BurnRate, teve que deixar sua estrutura de aplicativos para trás e reinventá-la do zero. A primeira versão do .NET Core tinha acabado de ser lançada, então era o momento perfeito para reconstruí-lo para a era moderna.

O back-end era bastante simples, com SQL do Azure e Microsoft Restier mais do que capaz de lidar com as necessidades de API consultáveis do projeto. No .NET Core, seu florescente "Algoritmo de Pessoas" era extremamente rápido e capaz de lidar com cálculos profundamente complexos a partir de dados altamente estruturados em frações de segundo.

No entanto, organizar os dados financeiros da empresa de forma a permitir que as empresas criem vários cenários e alterne entre eles exigia uma profundidade arquitetônica que ele não havia previsto.

"Colocar em camadas cenários, cenários principais, escalas de tempo e resultados planejados versus reais [resultados] juntos em um modelo foi o suficiente para fazer minha cabeça girar. Foram meses de trabalho intenso e repetidas tentativas para fazer funcionar", disse ele. McLaws disse que o número de testes de unidade que o BurnRate usa em seu algoritmo para garantir a funcionalidade correta "é provavelmente uma ordem de grandeza maior do que a maioria das outras empresas construídas com seu aplicativo. Estamos pedindo às empresas que tomem decisões sobre o futuro de todos os seus negócios com isso plataforma. Não podemos errar."

A BurnRate criou toda a estrutura de teste de software livre chamada Breakdance para aumentar a produtividade do teste de unidade e escrever testes mais consistentes em menos tempo.

O front-end apresentou desafios diferentes. McScripts começou a criar protótipos da interface do usuário BurnRate usando uma combinação de Webpack, TypeScript e Knockout, mas enfrentou vários obstáculos. No momento, o Webpack não tem definições de TypeScript para ajudar a facilitar a configuração de builds.

"Com JavaScript — uma linguagem em que qualquer coisa pode ser qualquer coisa, e tudo pode ser trocado em tempo de execução — a falha é uma configuração padrão. O sucesso precisa ser obtido, geralmente por meio de uma grande incompatibilidade mental," McLaws disse.

Quando ele finalmente fez tudo funcionar e teve seu primeiro protótipo totalmente funcional, a equipe teve problemas de dimensionamento, especialmente ao gerar planos de contratação para empresas com centenas de funcionários.

"Quando estávamos tentando descobrir como dimensioná-lo e lidar com as atualizações da interface do usuário, os recálculos e o lado do servidor, estávamos retrocedendo," disse ele. "Estava ficando cada vez mais irregular no navegador quando você tentava renderizar as coisas."

Como o Blazor iluminou o caminho para a escalabilidade

O Blazor entrou no mercado por volta dessa época e era uma nova tecnologia de front-end.

"A promessa de C# de ponta a ponta no navegador com JavaScript mínimo foi muito boa para ignorar," disse McLaws.

O uso de C# entre o cliente e o lado do servidor não apenas tornou o desenvolvimento de aplicativos "muito mais fácil", de acordo com McLaws, mas também desempenhou um papel crítico em tornar a IU do BurnRate tão confiável quanto seus cálculos.

Podemos escrever testes de unidade na mesma linguagem em que estamos escrevendo o código de back-end. Aquilo é enorme! Por que você não iria querer construir dessa maneira? Ele eliminou milhares de linhas de código e foi tão intuitivo para qualquer pessoa que passou cinco segundos no mundo do WPF."

Com o Blazor, a BurnRate conseguiu avançar "muito, muito rapidamente." Em vez de três anos, a equipe construiu um protótipo funcional do Blazor em questão de semanas e portou completamente várias centenas de milhares de linhas de código em menos de um ano.

Boa parte desse tempo foi gasto na criação de novas ferramentas de código aberto para que outras empresas também pudessem criar aplicativos Blazor mais rapidamente, uma abordagem que se encaixa no espírito útil de McLaws.

"As pessoas tendem a esquecer que quando você está construindo uma plataforma como BurnRate, você não precisa apenas do aplicativo voltado para o cliente; você também precisa do aplicativo por trás do aplicativo para alterações de banco de dados e administração do sistema," disse ele.

"Portanto, criamos BlazorEssentials, uma biblioteca que habilita o estilo de arquitetura MVVM (Model-View-ViewModel) do XAML no Blazor. Ele nos permite separar corretamente a aquisição de dados da exibição de dados em nossos aplicativos. Isso traz um nível de simplicidade e consistência para nossa arquitetura de aplicativo. Agora 100% da nossa base de código é testável em uma única linguagem com padrões previsíveis."

Aproveitar o Azure DevOps para Integração Contínua e Entrega Contínua (CI/CD) altamente automatizadas permite que a equipe da BurnRate se mova ainda mais rápido.

"Seja um novo aplicativo ou um novo utilitário para um aplicativo existente, podemos enviar para produção em questão de horas", disse McLaws.

À medida que a BurnRate crescia, era necessário garantir a estabilidade do produto para que ele fosse incorporado às principais operações diárias dos clientes. A McLaws confiava na Microsoft.

Entregando soluções sem comprometimento

"Escolhi a Microsoft há muito tempo, e ela nunca me decepcionou," disse ele.

McLaws é um veterano de .NET de 23 anos e cinco vezes MVP da Microsoft, com suas contribuições de código aberto totalizando mais de 1,4 bilhão de downloads. Até hoje, ele continua desenvolvendo com a Microsoft, sabendo que existem recursos e uma comunidade para construir grandes coisas juntos. Com o Blazor, a equipe BurnRate foi capaz de criar o aplicativo e cumprir a visão de McLaws sem fazer concessões.

Em sua opinião, nunca houve "nenhuma outra plataforma além do .NET que pudesse suportar esse [nível] de escalabilidade estável", disse ele. De acordo com ele, o Blazor capacitou sua equipe enxuta a desenvolver de forma mais inteligente e rápida.