Money Talks: Como falar de negócios como engenheiro

Jason Raede Blocked Unblock Seguir Seguindo 11 de janeiro

Quando recebi as chaves da organização de engenharia da minha empresa anterior, fiz o que sabia: dei um pulo de cabeça e foquei na arquitetura e no código. E eu pensei que estava fazendo um ótimo trabalho. Nós escalamos com sucesso a plataforma para lidar com um fluxo massivo de tráfego, entregamos recursos (principalmente) no prazo e tivemos vários clientes corporativos extremamente satisfeitos. Mas sempre houve um senso de desalinhamento e desconfiança em nossas reuniões executivas. Nós lutamos para chegar a acordo sobre estratégia e prioridade. Os requisitos eram ambíguos e não podiam ser esclarecidos. As expectativas de entrega foram mantidas ocultas e artificialmente preenchidas sem colaboração. Nós fomos bem sucedidos , mas algo estava nos impedindo de nos tornarmos uma máquina bem lubrificada.

Acontece que havia toda uma outra metade do meu trabalho que eu estava negligenciando.

Uma empresa de software “bem lubrificada” pode transformar ideias em receita com apenas uma pequena fricção.

O que eu não sabia na época era que, enquanto todos nós estávamos falando inglês, estávamos falando línguas diferentes. Todas as pessoas de negócios sabiam que provavelmente deveriam confiar em mim, porque minha equipe e eu provamos que poderíamos enviar recursos e escalar o sistema. Mas havia muitos olhares em branco ao falar sobre arquitetura de sistema e pontos de história. Eles nunca realmente entenderam e apreciaram o que a engenharia estava fazendo e a incrível habilidade e pensamento envolvidos. Da mesma forma, os engenheiros nunca realmente entenderam como o que eles estavam construindo contribuiu para o crescimento do negócio. Houve uma grande desconexão e fomentou o tribalismo de “negócios versus engenharia” que eu já vi em muitas empresas disfuncionais.

Nossas conversas eram muito parecidas com as de Carol com o chefe de cabelos pontudos.

O truque, como aprendi desde então, é encontrar um terreno comum. Então, qual é o fator unificador em todas as unidades de negócios? Valor Um vice-presidente de vendas pode facilmente entender e apreciar um feito de engenharia se o valor que ele fornece for claro e tangível. O verdadeiro desafio é: como usar dados para prever e medir o valor de um novo recurso? Uma correção de bug? Ou, Deus me livre, que tal um refator ou um upgrade de infraestrutura?

Perfuração para baixo para valor

Com o processo adequado de pesquisa e pensamento, você pode voltar a um valor bastante preciso para quase todas as iniciativas de engenharia; Isso permite que você fale sobre até mesmo desenvolvimentos de back-end em termos de dinheiro, e torna muito mais fácil a comunicação com o lado não técnico da casa.

O valor dos recursos é relativamente fácil de quantificar, pois os recursos geralmente têm um impacto direto em seus clientes e, portanto, sua receita:

  • Quantos mais clientes é estimado para trazer? ? Qual é a receita média por cliente?
  • Quanto tempo os clientes passarão no aplicativo? ? Quanto a probabilidade de gastos aumenta como um fator de tempo no site?
  • Que efeito terá na pontuação do NPS? ? Como a pontuação média do NPS afeta nossa receita?

Para correções de bugs e refatores, o valor é mais difícil de quantificar. Geralmente há mais de dois graus de separação entre a tarefa e o valor. Eu gosto de pensar nisso em termos de custo de oportunidade:

  • Qual é o custo de não consertar o bug imediatamente? ? Quantos clientes não podem usar o site? ? Quanta receita vamos perder?
  • O que acontecerá se não refatorarmos o sistema de pagamento agora? ? Quantas compras não conseguiremos processar se o sistema de pagamento falhar em grande escala?

SRE / devops é o mais difícil, mas ainda é possível:

  • Quanto vai diminuir o tempo de construção? ? Quanto mais os engenheiros poderão produzir em um determinado sprint? ? Quantos mais recursos podemos construir neste trimestre ? Quanto de receita a capacidade adicional de recursos trará?
  • O que acontecerá se não tivermos redundância de banco de dados multi-AZ? ? Qual é a probabilidade de uma falha do AZ? ? Quanta receita será perdida se o site ficar inativo por uma hora enquanto criamos um banco de dados em um novo AZ?

Agora, como você pode dizer, fazer isso com números reais requer muitos dados. E garantir que você tenha os dados certos, acessíveis, estruturados de uma maneira utilizável, no momento em que você precisa tomar uma decisão, é difícil . No entanto, a maior parte do valor dessa prática vem do processo de pensamento, e não dos números reais por trás dele. Seu COO pode não entender a complexidade do teste de carga, mas definitivamente entenderá que o tempo de inatividade devido a problemas de dimensionamento é caro e evitável. Um executivo de contas pode não entender uma mudança do MySQL para o MongoDB, mas definitivamente entenderá o benefício de poder integrar mais rapidamente novos clientes corporativos com um modelo de dados mais flexível.

Benefícios Tangenciais

Acompanhar diligentemente esse processo não apenas ajuda na comunicação e alinhamento em toda a empresa, mas naturalmente torna a priorização mais fácil e ajuda os engenheiros a se responsabilizarem mutuamente.

A prioridade de uma determinada iniciativa agora pode se tornar uma função do valor esperado em relação à complexidade do desenvolvimento, em vez de ser impulsionada pelo sentimento de instinto, acenos de mão e conhecimento do setor. Portanto, é muito mais fácil explicar por que você deve refatorar o sistema de autenticação antes de criar a integração do Salesforce. As pessoas podem discordar, mas elas não concordam com o valor, não com sua opinião profissional. Isso é importante, pois impede que as coisas fiquem pessoais.

Tem gosto de porcaria. Mas às vezes faz o trabalho.

Também é muito mais fácil evitar preconceitos na tomada de decisões. Eu estive lá: é difícil ficar longe de refatorar o serviço de código de espaguete que você escreveu há quatro anos que ainda assombra você até hoje. Mas se você fizer sua pesquisa e colocar um valor no refatorador, de repente você pode se sentir melhor em fazê-lo até o próximo ano. Se funcionar e for coberto por sua infraestrutura de monitoramento, o valor de um refatorador provavelmente não será tão alto até que você tenha um recurso valioso nos livros que o exigem.

Por fim, tornar claro o valor de uma iniciativa de engenharia para todos ajuda os engenheiros a entenderem o quão importante o que estão fazendo é atingir os objetivos da empresa. Mesmo os melhores engenheiros podem ser motivados a realizar uma tarefa tipicamente chata (como fazer o maldito front end funcionar no IE 10), se eles entenderem e concordarem com o benefício. Uma equipe de engenharia entusiasmada é de alto desempenho.

Na prática

Recentemente, adotamos totalmente essa metodologia em Fincura e obtivemos resultados muito positivos até o momento. Nossos gerentes de produto (para recursos e bugs) e arquitetos (para melhorias de infraestrutura e sistema) fazem suas pesquisas e estimam o valor comercial relativo (usando uma escala de 1 a 5) de uma iniciativa. Os engenheiros fazem furos na estimativa de valor e aplicam sua própria estimativa de complexidade de desenvolvimento usando pontos de história. Depois, colaboramos para dividir a iniciativa em componentes que podem ser entregues, otimizando a entrega do maior valor de negócios com a menor complexidade de desenvolvimento . É claro que sempre há dependências e datas de marcos que não podem ser transferidas, mas essa prática facilitou um sentimento de confiança mútua e responsabilidade entre empresas e engenharia que nunca vi antes em uma empresa de software. Todos estão alinhados com prioridade e podemos evitar distrações dispendiosas à medida que trabalhamos em direção a nossos objetivos elevados.

Em postagens futuras, estarei explorando mais sobre como usamos os dados para tomar decisões e obter alinhamento à medida que nos esforçamos para ser a máquina bem oleada e lendária.