O Team Ramp Up garante maior velocidade de recurso?
Publicados: 2020-03-28Um dos principais elementos essenciais ao aumentar as equipes para aumentar a velocidade de lançamento é a transferência de clareza das equipes de produto para as equipes de sprint
Uma execução suave do sprint é o resultado de contribuições notáveis vindas das equipes de produto e sprint
A filosofia de 'certo na primeira vez (FTR)' ajuda todos os membros da equipe a se alinharem a um objetivo comum
Quando as startups passam do estágio inicial para o estágio de crescimento, suas prioridades mudam significativamente. Entre todos os outros, a feature velocity se destaca como prioridade e desempenha um papel crucial na busca pelo crescimento.
O fundador de uma startup de capital semente com a qual eu estava trabalhando, que recentemente elevou sua rodada série A, me pediu para dobrar a equipe de engenharia para liberar novas funcionalidades em seis meses. No entanto, esse é o único fator relevante na redução do tempo de ciclo? Para responder, decidi abordar os aspectos ignorados por trás desse “equívoco” predominante.
Embora a capacidade de recursos seja um dos fatores críticos que impulsionam lançamentos frequentes para produção, isso por si só não pode garantir a redução do tempo de ciclo. Ao construir produtos para mais de 16 startups, testemunhei a transição do estágio inicial para o estágio de crescimento várias vezes. A partir dessa experiência, aqui estão alguns fatores cruciais que estou compartilhando para que os fundadores de startups considerem.
Transmitir clareza: o essencial de cima para baixo
Um dos principais elementos essenciais ao aumentar as equipes para aumentar a velocidade de lançamento é a transferência de clareza das equipes de produto para as equipes de sprint. Quando um sprint começa com ambiguidade ou não tem histórias suficientes para começar, a taxa de entrega do sprint é afetada negativamente. Histórias vagamente definidas ou inclusão de tarefas no meio do sprint diminuem o ritmo, como resultado, as equipes de sprint não entregam conforme o planejado.
Uma execução suave do sprint é o resultado de contribuições notáveis vindas das equipes de produto e sprint. A equipe de produto pode desempenhar seu papel preparando e compartilhando o roteiro com a equipe de sprint pelo menos para o trimestre, para que a equipe possa planejar suas entregas de acordo.
Por outro lado, a equipe de sprint deve continuar pressionando a equipe de produto para obter um backlog de produto e prepará-lo semanalmente / quinzenalmente para garantir uma entrega focada.
Automatize para liberar 'Bug-Free'
“Eficiência é fazer as coisas direito; eficácia é fazer as coisas certas.” - Peter Drucker
Quando você pensa em automação, é um exemplo da última categoria. No momento em que o desenvolvimento de recursos ganha velocidade, é altamente provável que a produção seja interrompida, a menos que os processos corretos estejam em vigor. Se o produto não for estável o suficiente para lidar com o desenvolvimento de novos recursos, sua equipe gastará mais tempo corrigindo problemas do que criando novos recursos. Consequentemente, sua velocidade de engenharia diminui.
É aqui que o CI/CD (integração contínua e implantação contínua) entra em cena. Aqui, a unidade exaustiva, a integração e a cobertura de testes de automação garantem que o que for enviado não quebre o sistema.
Recomendado para você:
Como a estrutura do agregador de contas do RBI está definida para transformar as fintechs na Índia
Empreendedores não podem criar startups sustentáveis e escaláveis por meio do 'Jugaad':...
Como o Metaverse transformará a indústria automobilística indiana
O que significa a provisão antilucratividade para startups indianas?
Como as startups de Edtech estão ajudando a qualificação da força de trabalho da Índia e se preparando para o futuro
Ações de tecnologia da nova era esta semana: os problemas do Zomato continuam, EaseMyTrip publica...
Não apenas construa mais, senão você quebra mais
O retrabalho é um grande assassino de produtividade e pode ser resultado de vários fatores, como histórias vagamente definidas, falta de teste de desenvolvimento, falta de cobertura de teste e assim por diante. O retrabalho pode consumir a produtividade, pois consumiria o tempo e os esforços dos engenheiros de controle de qualidade nos testes e regressão, dos desenvolvedores na depuração e dos gerentes de versão no relançamento.
Desacelerar um pouco pode ajudar sua equipe a entregar mais rapidamente e agregar valor, pois a velocidade efetiva é sempre altamente recompensadora do que apenas a velocidade.
A filosofia do 'first-time-right (FTR)' ajuda todos os membros da equipe a se alinharem a um objetivo comum: entregar um código robusto e estável na primeira vez. É sempre saudável gastar algum tempo extra para determinar a qualidade do código, em vez de se apressar e ficar preso ao retrabalho.
Algumas das maneiras testadas e comprovadas de melhorar a taxa de FTR são a limpeza regular do backlog, a reiteração de histórias, demonstrações regulares para o gerente de produto. Em vez de apenas reunir requisitos, a equipe de sprint deve estar mais focada em elucidá-los para melhorar a taxa de FTR.
Estruture sua equipe para sprints paralelos
Quando sua startup tem uma pequena equipe de produto, todos trabalham principalmente em um ou dois recursos ao mesmo tempo (geralmente aplicável a uma equipe de 4 a 6 membros). No entanto, à medida que a expectativa aumenta para fornecer vários recursos, é altamente recomendável que você forme várias subequipes com áreas de foco distintas. Dessa forma, cada subequipe consegue executar seu sprint e definir seu roteiro.
Em comparação com uma grande equipe, equipes menores nascidas de uma estrutura de 'separação lógica' são mais eficazes e produzem melhores resultados. Equipes individuais para microsserviços, diferentes linhas de produtos e vários componentes estão entre alguns exemplos da abordagem de 'separação lógica'.
Durante a reestruturação, é sempre essencial incluir pelo menos um membro da equipe principal anterior em cada uma dessas subequipes para manter o DNA. Embora a coordenação entre equipes para entregas implique uma sobrecarga adicional, essa é uma troca justificada.
Acompanhar o uso do recurso junto com a velocidade
A experiência do usuário é a métrica mais importante para medir o sucesso de uma nova versão de recurso. À medida que você começa a fornecer vários recursos em velocidade, a experiência do usuário geralmente fica em segundo plano. Quando seu produto tem recursos limitados, a interação do usuário continua sendo uma curva suave e contínua.
No entanto, quando você começa a lançar novos recursos, há uma grande chance de os usuários ficarem sobrecarregados e sua experiência ser impactada.
Para alcançar uma melhor adoção do usuário, acompanhar o envolvimento do usuário junto com a velocidade do recurso continua sendo o melhor caminho a seguir. Embora a pesquisa exaustiva do usuário seja uma maneira comprovada, outras significativas estão sendo lançadas inicialmente para usuários selecionados por meio de sinalizadores de recursos, testes AB e rastreamento da jornada do usuário (por meio de ferramentas de análise de amplitude ou semelhantes) após cada nova versão.
Não perca seus membros principais
Este pode ser um aspecto muito comumente ignorado, mas permanece firme como muito importante. Equipes pequenas não precisam necessariamente de processos e possuem uma estrutura ágil, e a voz de todos é ouvida. Quando essas equipes avançam para um estado em que os processos são configurados e novos membros funcionais e de engenharia são adicionados, o gerenciamento saudável é a única maneira de evitar o caos.
À medida que sua equipe de engenharia cresce com sucesso, uma equipe de produto bem capacitada é essencial para alimentar a equipe de engenharia continuamente. Um churn se torna inevitável quando os membros da equipe não têm um trabalho significativo, mas nenhuma startup gostaria de perder seus membros principais. Nesse caso, a alta direção tem a chave para garantir o bom relacionamento com as pessoas e entender bem a dinâmica.
Os aprendizados que compartilhei aqui são da experiência com várias startups ao longo dos anos. Espero que seja útil para os fundadores de startups, que já têm muito o que fazer, de forma que não acabem reinventando a roda.