Na parte 1 desta série , exploramos metodologias e estruturas que considero úteis na criação e crescimento de startups de software. O objetivo desta postagem é ilustrar como você pode aplicar essas técnicas para minimizar o desperdício de esforço e como o planejamento de seu negócio de software se traduz em sua infraestrutura de nuvem.

Pré-requisitos para avançar

• Você leu a parte 1 da série
• Você está familiarizado com as estruturas/metodologias que exploramos abaixo assistindo aos links de vídeo compartilhados na parte 1

O diagrama acima ilustra os principais conceitos das metodologias mencionadas. Para esta postagem, vamos nos divertir inventando uma startup fictícia de encontros on-line e “dimensioná-la”. Vamos ilustrar a aplicação desses princípios e o relacionamento da estratégia da empresa com as necessidades de produto e crescimento e como eles informam nosso projeto de infraestrutura de nuvem.

Identifique o problema que estamos resolvendo e para quem

Assuma que você e outras pessoas estão fartos de serem solitários, e as soluções existentes não funcionam. Você já foi a casamentos, muitos na verdade, e já foi a bares, e até tentou aplicativos populares, mas ainda sente que algo está faltando. Você é apaixonado por esse problema e acredita que é a equipe para ajudar a resolver a solidão das pessoas, inclusive a sua. Vamos primeiro analisar as estratégias potenciais de outras soluções.

Isenção de responsabilidade

Eu nunca usei um aplicativo de namoro online, então estou apenas “adivinhando” quais recursos e funcionalidades eles incluem. Usando o que está na televisão ou nas manchetes sobre vários aplicativos populares, podemos fingir que estamos construindo um concorrente. Se minhas suposições estiverem erradas, ou se não explorarmos todos os tipos de relacionamento, peço que você suspenda a descrença para ilustrar esses conceitos .

eHarmony

Este serviço tinha uma teoria de que, ao combinar com base em um perfil científico de personalidade, as pessoas se sentiriam menos intimidadas. Sua estratégia é tornar a personalidade o fator principal, eles atrairão pessoas menos confiantes em sua aparência e ainda solitárias, capitalizando um mercado inexplorado.

Inflamável

Este serviço tinha uma teoria de que muitas pessoas eram solitárias, mas não buscavam relacionamentos de longo prazo. A estratégia deles era substituir as conexões casuais e capturar essa parte do mercado.

Bumble

Este serviço tinha uma teoria de que as mulheres se sentiriam mais confortáveis ​​em uma plataforma se pudessem escolher com quem se envolveriam. A estratégia deles era deixar as mulheres decidirem se enviariam a primeira mensagem após uma partida.

eTumble — NOVO!

Nossa suposição é que as pessoas são solitárias e que as soluções no mercado ainda não resolveram a solidão em escala global . Acreditamos que a solução vencedora é uma combinação das três acima. Suspeitamos que, no fundo, os buscadores de encontros casuais prefeririam ter uma chance de uma conexão pessoal mais profunda por meio da correspondência inicial de personalidade, mas as mulheres escolhem se desejam interagir.

As práticas de Lean Startup aconselham operar como um “grande experimento”, fazendo suposições ousadas e depois observar (não perguntar) o comportamento dos usuários, enquanto itera rapidamente. Freqüentemente, liberamos ideias usando uma tela “Lean” , mas presumiremos que nossa equipe já fez isso acima. Vamos começar!

Começando com uma visão e estratégia

análise SWOT

Ao reconhecer as forças internas (forças, fraquezas) e externas (oportunidades, ameaças), você pode aproveitar uma análise SWOT para identificar melhor o que deve ocorrer para ter sucesso.

Essa análise informa o design do produto à medida que você testa hipóteses para resolver os altos e baixos inevitáveis. Por exemplo, se a alta rotatividade de usuários for uma ameaça, você pode priorizar os recursos que mantêm as pessoas voltando à sua plataforma. Dado um ponto fraco foi a falta de experiência em psicologia na equipe, você sabe ao contratar ou atrair consultores, a quem direcionar. Se a equipe tem experiência limitada com aplicativos concorrentes, você sabe que uma tarefa é usá-los, e ir a encontros - uma vitória, vitória.

Definir plano estratégico inicial usando OGSM

No estágio inicial, seu objetivo será obter um produto mínimo viável (MVP) lançado rapidamente para começar a observar o comportamento do usuário e testar hipóteses iterativamente. No mundo do software, costumamos brincar que os protótipos sempre se tornam produção, apesar de nossas melhores intenções. Investir alguns dias para fazer um brainstorming com sua equipe para documentar estratégias e medidas pode reduzir o retrabalho e acelerar o design e o desenvolvimento de seu produto — vamos explorar como a seguir.

Observe no exemplo do OGSM acima, já começamos a identificar nossas futuras necessidades de equipe, produto, métricas e infraestrutura. Precisaremos de experiência em aplicativos móveis, aprendizado de máquina e desenvolvimento de API. Também precisaremos de tradução de idiomas, ofuscação de texto e imagem e aceitação de pagamentos online. Para públicos globais, precisamos atender aos requisitos regulamentares e de privacidade, especialmente na União Europeia.

Lean UX

O Lean UX é mais conhecido entre as equipes de produto, onde o autor Jeff Gothelf teve seu humilde começo. Acredito que a eficácia de comunicar qualquer ideia por meio de declarações de hipóteses garante a conscientização em toda a organização e não apenas nas equipes de produto. Acho que o Lean UX pertence à estratégia e à visão e é usado em todos os lugares.

Cada estratégia, e subseqüentemente tática (recurso), no plano OGSM acima é essencialmente uma hipótese. Quanto mais expressamos nossas ideias nessa estrutura, mais acionáveis ​​e focadas elas se tornam. Por exemplo, a estratégia de que alcançaremos nossos objetivos “fornecendo um local mais seguro para interagir” pode ser formulada como:

“Acreditamos que [milhões de usuários] se juntarão ao nosso serviço se [as mulheres] [se sentirem mais seguras para interagir] com [apenas elas escolhendo iniciar uma conversa após as partidas].”

Isso se traduz livremente em “Acreditamos que [resultado comercial] será alcançado se [usuário] obtiver [benefício] com [recurso]”. conforme descrito na tela Lean UX. Às vezes, troco esse formato por outro definido nos princípios ágeis de “Product Discovery”, mas a premissa é a mesma — comunicação estruturada .

Você pode ver a natureza iterativa dessas metodologias ao combiná-las. Se ainda não o fez, recomendo que revise os vídeos sobre Lean UX na parte 1 desta série .

Design de produto

Voltando aos princípios “Lean”, uma vez que você tenha suposições ou hipóteses ousadas sobre o problema que está resolvendo, para quem está resolvendo e como pretende resolvê-lo, você deve iterá-las e testá-las rapidamente.

Em vez de perguntar aos usuários, é sempre melhor observar o comportamento deles para validar suas suposições, e é por isso que o lançamento de um MVP é recomendado. Em um produto ao vivo, você também pode aproveitar as ferramentas de teste A/B ou sinalizadores/alternâncias de recursos.

Não precisamos de todos os recursos ignorados em nosso OGSM imediatamente para testar nossas teorias, mas agora temos uma compreensão holística de para onde estamos indo. Em seguida, priorizamos o que nosso MVP deve oferecer para maximizar o valor do usuário à medida que iteramos rapidamente . Para isso, usaremos o User Story Mapping .

Mapeamento da história do usuário

O que você vê acima já é a versão seis! Começando com uma visão holística, mapeei rapidamente a jornada geral do usuário. Em seguida, embaralhei as caixas e priorizei novamente as histórias de usuários para identificar a menor quantidade que poderíamos fornecer para testar os resultados desejados para o público-alvo.

Ao testar hipóteses ao longo do caminho, você aplica suas descobertas e continua a editar esses “documentos vivos” de maneira ágil, em vez de perder tempo com especificações detalhadas estagnadas.

Arquitetura do modelo C4

Agora temos informações para nos ajudar a definir nossa arquitetura de software e sistema, mas fazê-lo de maneira padronizada costuma ser negligenciado. Certifique-se de ter um plano (ou modelo) do que está construindo para se comunicar com eficiência com outras partes interessadas. Embora a UML continue sendo um padrão de longa data, o modelo C4 mais leve é ​​o que eu recomendo hoje.

Para abreviar este artigo, ilustraremos um exemplo parcial de nossa arquitetura para o eTumble. Embora existam 4 níveis para C 4 , a prática padrão é ilustrar apenas o mais profundo necessário; o nível de “Código” que efetivamente seria a notação UML geralmente é ignorado.

Conforme observado em meu aviso acima, este é um aplicativo fictício e nunca usei um serviço de namoro online, portanto, essas são suposições fundamentadas para ilustrar o processo.

Muitas vezes, começo a esboçar ideias no papel para pensar no design. Assim que tiver uma ideia geral do que é necessário, listo os elementos da arquitetura para destacar os detalhes. Por exemplo, sabemos que vamos precisar de uma base de dados, mas a nossa estratégia implica um jogo global. Precisamos decidir se podemos começar com Postgres ou MySQL para lançamento, e quão difícil pode ser migrar para um sistema distribuído como Cockroach DB ou Cloud Spanner do GCP.

Experimentando um “bloqueio de escrita” às vezes enquanto olho para caixas e linhas em uma tela, acho que usar uma planilha como abaixo torna mais fácil mover coisas ou inserir linhas conforme penso em mais coisas, antes de diagramar.

Em alguns aplicativos, você pode simplesmente copiar/colar como no IcePanel , mostrado abaixo. Há suporte para Markdown, que é ainda mais rápido quando você se familiariza.

Espero que isso demonstre a rapidez com que você pode transferir o que escreveu para uma ferramenta de diagramação - levando menos de uma hora para produzir belos diagramas. Imagine se envolver com designers e engenheiros com os projetos acima e como eles seriam muito mais rápidos (e mais baratos).

Escalando as coisas

Insinuações anteriores de que iríamos “dimensioná-lo” significavam que prevíamos nossas necessidades futuras com base em nosso plano estratégico e nossa visão geral ilustrada no mapa da história. Mencionei o AKF Scale Cube anteriormente e, ao aplicar seus princípios de eixos xyz, concluí que nossa escala global e dezenas de milhões de usuários precisarão de um design sem estado, sistema orientado a eventos, arquitetura de microsserviço e, eventualmente, várias equipes, com hospedagem abrangendo várias regiões geográficas em uma plataforma de nuvem pública.

• Nosso eixo x ( duplicar e dimensionar ) é acomodado por aplicativos sem estado, em contêineres e hospedagem em nuvem pública.
• Nosso eixo y ( specialized ) é acomodado por microsserviços criados especificamente, acionados por HTTP/RPC ou por mensagens Pub/Sub. Isso também ajuda a definir como você provavelmente aumentará suas equipes, permitindo autonomia e baixo acoplamento para possuir uma peça-chave de valor no sistema; isso geralmente se alinha à linha de base UX ilustrada no mapa da história.
• Nosso eixo z ( dividir coisas semelhantes ) é acomodado pela regionalização. Não abordamos isso completamente em nosso exemplo fictício. Vamos supor que, dada a estratégia global, as restrições jurisdicionais em sistemas e soberania de dados, moedas estrangeiras, idiomas e estratégias futuras de entrada no mercado (GTM) de vendas de canal possam influenciar a forma como expandimos esse eixo. Pode até ser baseado em onde encontramos/possuímos talentos para nossa equipe, ou mesmo como descreve “Topologias de Equipe”, a carga cognitiva da equipe.

O que aprendemos e construímos até agora:

Tempo gasto até agora projetando eTumble, nossa startup fictícia de namoro online:

• Lean [Inicialização | UX] canvas — não o ilustramos, mas normalmente é nesse ponto que você começa a escrever qual problema está resolvendo, para quem está resolvendo e os benefícios/valor que oferece. Você pode validar sua ideia com um “MVP de cortina de fumaça” e uma página de destino, por exemplo. Assista aos vídeos da parte 1 para saber mais.
• Análise SWOT - identificamos pontos positivos que queríamos explorar e negativos que precisamos resolver, informando nosso plano OGSM. (30 min; espere várias horas)
• Plano OGSM - identificamos os principais recursos, tecnologias, métricas e equipe que precisaremos para implementar nossa estratégia, informando nosso mapa da história. (1 hora; espere 1–2 dias)
• Mapa da história — organizamos e priorizamos histórias de usuários, identificando nosso candidato a MVP, informando nossaarquitetura holística conforme ilustrado acima. (3 horas; espere 1–2 dias)
• Arquitetura do modelo C4 — identificamos sistemas, bancos de dados e componentes necessários, informando nossa infraestrutura necessária. (3 horas; espere 2–5 dias)

Alimentados com esses “documentos vivos”, nossa equipe e as partes interessadas agora têm uma compreensão compartilhada de por que estamos fazendo o que estamos fazendo, como planejamos vencer (ou pelo menos teorias para testar) e o que vamos construir para resolver o problema geral.

Investir esse tempo para colaborar e anotar as coisas também simplifica o processo de projetar infraestrutura de nuvem, repositórios de código-fonte e o monitoramento/métrica de que precisaremos para dar suporte ao eTumble. Exploraremos isso e muito mais na parte 3 desta série .

Obrigado por ler até aqui, e espero que você goste de um mergulho técnico mais profundo na parte 3 .