As startups de software hoje têm uma vantagem significativa sobre as de cinco a dez anos atrás, em parte devido à proliferação de provedores de hospedagem em nuvem de hiperescala, como Google Cloud Platform (GCP), Amazon Web Services (AWS) e Microsoft Azure. Com uma infinidade de serviços gerenciados disponíveis com o clique de um botão, eles podem prototipar rapidamente sua solução e colocá-la no mercado em tempo recorde e em escala quase infinita. Embora possa parecer mais simples hoje, preparar uma startup para escalar na nuvem ainda exige uma consideração cuidadosa.

Tenho a sorte de ter feito parte de várias organizações de tecnologia por mais de vinte anos, desde startups iniciantes, até empresas financiadas por capital de risco e capital privado, e até mesmo conglomerados globais com IPOs. Aprendendo com tantas pessoas talentosas e mentores ao longo do caminho, eu “escolho a dedo” as lições aprendidas, ferramentas, técnicas e processos para levar adiante.

Em um esforço para “pagar adiante”, gostaria de compartilhar algumas lições aprendidas. Este primeiro artigo da série apresentará conceitos e recursos que considero úteis para criar e dimensionar startups de software. No segundo artigo , vamos projetar uma startup fictícia de namoro online para ilustrar como essas peças se encaixam. No terceiro artigo , ilustramos como eles informam sua arquitetura de nuvem usando o GCP.

• Parte 1: histórico e introdução à metodologia
• Parte 2: implementando metodologias com startup fictícia
• Parte 3: projetando e dimensionando a infraestrutura de nuvem

No início de 2020 decidi tentar algo novo; em vez de construir e desenvolver startups de software, comecei a aconselhá-las e apoiá-las juntando-me a um parceiro de nuvem com raízes em Israel chamado DoiT International . Nossa empresa é totalmente remota e, desde então, cresceu de cerca de 50 pessoas para quase 500 globalmente em pouco mais de dois anos, suportando mais de US$ 1 bilhão em consumo anual de nuvem. Fico constantemente admirado com o quão bem preservamos nossa cultura por meio de um crescimento tão rápido, ao mesmo tempo em que atraímos e retemos tantas pessoas talentosas.

Milhares de organizações escolhem a DoiT como seu parceiro de serviços em nuvem. Eles se beneficiam de consultoria e suporte gratuitos e ferramentas de software de última geração projetadas para cumprir a promessa original da nuvem — concentre-se em seu produto e clientes e não se preocupe com o resto. Embora adoraríamos pensar que é tão simples, normalmente é precedido por nossos clientes com equipes técnicas altamente qualificadas.

Uma tendência que notei recentemente é o crescimento de startups de software em estágio inicial que adotam a tecnologia de nuvem e que podem não ter grandes equipes ou profundo conhecimento em nuvem. Como empresário de software, espero que compartilhar as lições aprendidas em minha “vida passada” e no DoiT torne sua jornada ainda mais bem-sucedida.

Os primeiros dias

Dando um passo para longe da tecnologia, vamos primeiro explorar a jornada desde a identificação de um problema até a construção de uma empresa dedicada a resolvê-lo e além. Existem algumas metodologias e estruturas populares além das melhores práticas de nuvem que você pode apreciar à medida que sua organização amadurece.

Cada técnica ilustrada acima é iterativa em si, mas como veremos no próximo artigo desta série, a saída de cada uma informa as outras.

TL;DR; Recursos online úteis

Em vez de explicar as técnicas e os conceitos acima, recomendo assistir a esses vídeos para preencher as lacunas e servir como uma cartilha para colocá-los em ação.

• Devo construir uma startup (14 min)— Michael Seibel, Y Combinator
• Estratégia vs planejamento (9 min) — HBR [use um plano de 1 página como OGSM]
• Resumo do Lean Startup (13 min) — Eric Ries
• Validando sua ideia de negócio (9 min) — Eric Ries
• Lean UX (60 min) — Jeff Gothelf
• Usando a tela Lean UX (15 min) — Jeff Gothelf
• Produto de construção (59 min) — Michael Seibel, Y Combinator
• Como planejar um MVP (13 min) — Michael Seibel, Y Combinator
• Mapeamento da história do usuário (50 min) — Jeff Patton
• Guia definitivo para mapeamento de histórias de usuários — Nick Muldoon, Easy Agile
• Arquitetura de software com o modelo C4 (35 min) — Simon Brown
• Construindo uma cultura de experimentação no Spotify (47 min) — Ben Dressler
• DevOps vs SRE (44 min) — Seth Vargo, Google

Depois de reconhecer um problema que você se sente compelido a resolver, ajuda a pintar uma imagem de onde você está indo e alguns indicadores-chave de que você está no caminho certo para agregar valor. Isso é semelhante a como a Amazon exigia que as equipes redigissem o comunicado à imprensa que descrevia o que estavam construindo no futuro, antes de serem aprovados para construí-lo.

Cerca de 10 anos atrás, durante uma sessão de planejamento de um dia inteiro, um mentor que abriu o capital de sua empresa e depois a vendeu para a Oracle por quase US$ 2 bilhões, apresentou-me o OGSM Framework . Significa Objetivos, Metas, Estratégias e Medidas. Obriga você a pintar de forma concisa onde você estará 3 a 5 anos no futuro, algumas metas mensuráveis ​​ao longo do caminho, enquanto se aprofunda em estratégias e táticas de curto prazo para realizá-las.

Você acaba com um plano de negócios de uma página, um documento vivo que você revisita e refina, que toda a equipe pode reunir e alinhar o foco de todas as atividades. Por exemplo, se alguma atividade não mapeia para uma estratégia definida para atingir um objetivo, você questiona se realmente vale a pena fazer ou se atualiza sua estratégia.

Alguns podem se perguntar qual é a diferença de outra estrutura popular de Objetivos e Principais Resultados (OKR). OGSM olha para anos no futuro, enquanto OKR se concentra principalmente em objetivos de curto prazo. Dependendo do estágio de sua empresa, a introdução de OKR pode fazer sentido, mas muitas vezes uma única visão de longo prazo que todos podem apoiar é a necessária “Estrela do Norte”.

Existem muitas outras técnicas, como análise SWOT, 5 Forças de Porter, Balanced Scorecard ou 3 Horizontes da McKinsey, que podem alimentar seu plano estratégico geral, mas o OGSM continua sendo minha ferramenta pessoal para estreitar o foco de uma equipe no que importa e compartilhar o visão maior.

Ideação

Orientar princípios e processos no início de sua jornada pode ajudar a alinhar as equipes à medida que você cresce. Acredito que uma cultura orientada por dados e uma mentalidade de medir tudo devem fazer parte de sua cultura e vir do topo e ser evidentes em todas as interações.

Alguns dos meus recursos favoritos que reforçam essa cultura experimental incluem Lean Startup (e o Lean Canvas) de Eric Ries e Lean UX de Jeff Gothelf. Quase todos os consultores e incubadoras de startups aconselham os fundadores a medir tudo, iterar rapidamente e criar um produto mínimo viável (MVP) para testar sua ideia no mercado. Tudo isso ressoa com os princípios “Lean”.

Jeff Gothelf leva os princípios “Lean” em uma direção que adoro porque se aplica a todas as equipes, departamentos e ideias em organizações de qualquer tamanho. A premissa é “não sabemos nada” e, para aprender [o que os clientes querem] e o que realmente resolve um problema, aplicamos o método científico - formulamos uma declaração de hipótese, testamos durante a medição, analisamos os resultados e corrigimos o curso conforme necessário . O valor dessa abordagem é minimizar o desperdício de esforço e validar que você está resolvendo os problemas certos mais rapidamente.

Projeto

Quando vejo pessoas negligenciando a documentação de seus sistemas e arquitetura de software, isso me lembra de alguém tentando construir uma casa com uma pilha de madeira. Claro que você pode descobrir eventualmente, mas seria muito mais rápido com menos erros se tivesse um plano. Duas das minhas técnicas favoritas para design de produto incluem User Story Mapping e o C4 Model .

Ao anotar as coisas, você garante um entendimento compartilhado e responsabiliza todos pela entrega do que foi acordado.

Há alguns anos, fui convidado como palestrante para o CTO Summit anual da empresa de private equity (PE), Francisco Partners . Participei de outras sessões e uma das mais intrigantes foi um dos parceiros que aconselhou outros CTOs e executivos de portfólio sobre o rastreamento de métricas em suas organizações de produtos. Uma das métricas que me surpreendeu, mas agora faz todo o sentido, é medir a quantidade de retrabalho para avaliar a eficácia dos gerentes de produto. Desde então, perguntei a outros líderes de engenharia se eles medem o retrabalho e a maioria aprecia, mas ainda não.

O retrabalho é uma métrica importante que você pode impactar ao reservar um tempo para entender o cliente e priorizar a entrega do valor mais imediato a ele. Isso é exatamente o que o exercício de mapeamento da história do usuário ajuda a facilitar ao forçar a colaboração entre várias partes interessadas. Meu argumento a favor disso, em qualquer estágio da empresa, é que é muito mais barato e rápido mover algumas caixas em um quadro branco compartilhado do que iniciar ciclos de desenvolvimento que mais tarde resultarão em retrabalho.

Sou o primeiro a admitir que tive alguns diagramas de arquitetura feios na minha época; Eu testemunhei ainda mais. É importante reservar um tempo para anotar sua arquitetura e sua relação com outros sistemas. O Modelo C4 é uma das melhores maneiras de fazer isso de maneira padrão sem exigir conhecimento de UML. Conforme descrito nos links de vídeo acima, a prática padrão é projetar até 3 níveis de profundidade (visão de componente). Existem produtos como o IcePanel que tornam isso mais fácil, ou vários plugins ou ferramentas em outras plataformas. É mais rápido do que você imagina, e ilustramos isso no próximo artigo desta série.

Construir

Vamos supor que sua equipe seja bem versada nesta fase. À medida que você cresce, a adoção de uma estrutura bem definida para implementar as ideologias ágeis pode ajudá-lo a escalar. Se você seguir os princípios “Lean” e mudar suas prioridades com base no aprendizado, já está no caminho certo. À medida que o foco da organização muda de velocidade e inovação para crescimento e estabilidade, esteja atento aos pontos de inflexão e à composição da equipe ao longo do caminho.

Operacionalize

Junto com o amadurecimento de suas práticas de desenvolvimento de produtos, você também desejará manter uma cultura de responsabilidade compartilhada. É aqui que entram os princípios do DevOps. O Google compartilhou sua implementação de DevOps chamada Site Reliability Engineering (SRE), e muitas organizações adotaram essas práticas.

Embora possa não ser necessário ter uma equipe ou função separada, equipes mínimas com engenheiros que tenham propensão para operações, monitoramento e automação pagarão dividendos. Exploraremos esses conceitos com mais detalhes quando nos aprofundarmos na inicialização de exemplo e definirmos sua arquitetura e infraestrutura de nuvem.

Planejando o crescimento

À medida que uma startup cresce além da pequena equipe fundadora, também aumenta a complexidade da comunicação e da governança, conforme ilustrado abaixo.

As empresas resolveram esses desafios de dimensionamento reconhecendo pontos de inflexão de seus negócios e formando equipes dedicadas, em sua maioria autônomas, para enfrentar desafios específicos.

Um ótimo recurso para dimensionar sua equipe de software, por exemplo, é esta postagem de blog de Seth Blank , que recomendo fortemente a leitura. Blank adverte que os processos e, em alguns casos, até mesmo as pessoas que ajudaram a empresa a decolar podem, em algum momento, se tornar um obstáculo para seu crescimento e escalabilidade futuros, ou devem ser direcionados para “a próxima coisa”. É aqui que os 3 Horizontes da McKinsey se tornam relevantes para o planejamento estratégico futuro. Por outro lado, um Blank diferente, Steve Blank, argumenta por que não é mais válido hoje .

Existe outro recurso chamado “ Topologias de equipe ” que fornece um modelo prático, passo a passo e adaptável para design de organização e interação de equipe. O foco é simplificar a organização e a plataforma com o que eles chamam de plataforma viável mais fina (TVP).

Outro conceito que considero útil para dimensionar uma organização ou produto é o AKF Partners Scale Cube . Aprendi sobre isso pela primeira vez há muitos anos, quando foi mencionado em um livro intitulado “ The Art of Scalability ” que comprei para os líderes de minha equipe em uma startup anterior - também é outra referência útil a qualquer momento, pulando para capítulos relevantes conforme necessário.

Quase todos podem concordar, no entanto, à medida que sua empresa continua a crescer e forma equipes dedicadas, a necessidade de governança e processos bem definidos, documentação, orientação e treinamento cresce com ela. Testemunhei muitas organizações neste estágio recentemente também buscando orientação sobre a melhor forma de estruturar sua infraestrutura de nuvem para acomodar com eficiência suas várias equipes. Abordaremos isso mais adiante nesta série.

Na parte 2 desta série , exploramos a união dessas peças para projetar, construir e dimensionar uma startup fictícia de software de namoro online.

Obrigado por ler até aqui, e espero que goste da parte 2 .