Como começamos a lançar recursos duas vezes mais rápido (estudo de caso)

Publicados: 2022-03-10
Resumo rápido ↬ Quando as empresas confiam em seu aplicativo para o trabalho diário, você precisa ser ágil o suficiente para atender rapidamente às suas necessidades. Se você não fizer isso, outros definitivamente farão. No mundo implacável do SaaS, atrasar um recurso crítico (ou apressar um pedaço de código cheio de bugs) significa perder clientes. Um fluxo de trabalho ágil sólido pode fazer toda a diferença.

Quando as empresas confiam em seu aplicativo para o trabalho diário, você precisa ser ágil o suficiente para atender rapidamente às necessidades delas. Se você não fizer isso, outros definitivamente farão. No mundo implacável do SaaS, atrasar um recurso crítico (ou apressar um pedaço de código cheio de bugs) significa perder clientes. Um fluxo de trabalho ágil sólido pode fazer toda a diferença.

Processo de desenvolvimento ágil
O ciclo de desenvolvimento, o núcleo de qualquer abordagem ágil, é constantemente revisado e aprimorado. (Ver versão grande)

Somos a equipe por trás do Active Collab , um aplicativo de gerenciamento de projetos com um conjunto cada vez maior de recursos e uma base de usuários considerável. Isso significa que mesmo a menor alteração na funcionalidade afetará um grande número de pessoas.

Leitura adicional no SmashingMag:

  • Como lançar novos recursos sem prejudicar os usuários fiéis
  • A lista de verificação de lançamento do site - 15 verificações essenciais antes de entrar no ar
  • Uma abordagem centrada no usuário para web design para dispositivos móveis
  • Como lançar qualquer coisa
Mais depois do salto! Continue lendo abaixo ↓

Portanto, o processo de desenvolvimento precisa ser executado sem problemas e dentro de um padrão, com atrasos reduzidos ao mínimo. Antes que qualquer alteração chegue ao usuário final, ela passa por cinco fases cruciais: feedback, design, desenvolvimento, garantia de qualidade e implantação . Neste artigo, compartilharei o que aprendemos (da maneira mais difícil) sobre cada uma das etapas em mais de oito anos no negócio.

Um alerta

Antes de entrar em detalhes, vamos ver como tudo isso aconteceu. Depois de anos adicionando recursos sem escrutínio suficiente, nosso aplicativo estava sofrendo com o inchaço de recursos. Adicionamos tantas funcionalidades ao longo dos anos que os novos usuários ficaram intimidados pela enorme complexidade da interface do usuário (para nunca mais voltar). Sabíamos que tínhamos que reconstruir do zero, mesmo que isso significasse reescrever cada recurso do zero.

Depois vieram os atrasos. Os recursos para novas versões estavam constantemente atrasados. Por exemplo, um desenvolvedor júnior deveria desenvolver uma integração com o QuickBooks. Não previmos com precisão a complexidade, as habilidades ou o conhecimento necessário. Além disso, ele era o único designado para essa tarefa, e ninguém poderia rapidamente ajudá-lo. Como resultado, o que era para ser um trabalho de duas semanas acabou levando cinco. Essas foram algumas bandeiras vermelhas.

Data limite
Prazos perdidos podem ter implicações graves. (Ver versão grande)

Era claramente hora de mudar para uma abordagem mais ágil. Pegamos o que gostamos de vários métodos ágeis (e não tão ágeis), combinamos com experiência e criamos nossa própria versão, que vem entregando ótimos resultados desde então.

Vamos dar uma olhada mais de perto no caminho que um recurso deve percorrer antes de ser oferecido ao usuário final.

Feedback-Decisão-Design-Desenvolvimento-Teste-Liberação
Para garantir a qualidade, um novo recurso é introduzido somente após ter passado por todas essas etapas. (Ver versão grande)

Da sugestão ao recurso

Em nosso fluxo de trabalho, um novo recurso começa a tomar forma muito antes de chegar à equipe de desenvolvimento e geralmente nasce do feedback do usuário. Isso não é coincidência - costumávamos lançar recursos que ninguém precisava, geralmente apenas porque um usuário era particularmente barulhento ou simplesmente achávamos que algo seria ótimo ter. Em vez de imaginar quais recursos nossos usuários podem precisar, agora tomamos decisões com base na demanda real.

Se você gosta de manufatura enxuta, diria que nossos clientes “puxam” certos recursos solicitando-os com mais frequência do que outros. Nossas equipes de suporte e vendas são uma grande parte do processo porque estão constantemente em contato com usuários que compartilham suas necessidades e ideias.

Com base no feedback, nossas equipes atualizam um formulário parecido com este:

Formulário de feedback
O feedback coletado e salvo usando este formulário é essencial para decidir quais recursos chegam ao roteiro. (Ver versão grande)

Quando não tivermos todas as informações de que precisamos, entraremos em contato diretamente com os clientes. Isso geralmente é feito com pesquisas direcionadas em uma amostra cuidadosamente selecionada. O importante é ouvirmos. Nenhum feedback é perdido em nós. É sempre reconhecido e documentado.

O próximo passo é a análise. Contamos as pontuações a cada mês para ver qual recurso recebeu mais votos. Além disso, com a categorização adequada, obtemos uma perspectiva mais ampla sobre quais partes do nosso software precisam ser trabalhadas. Por exemplo, se o calendário estiver recebendo muitas reclamações, consideraremos a reformulação de toda a seção, em vez de introduzir o recurso que recebeu mais votos (como exportação de calendário).

No entanto, mesmo quando os resultados chegam, a decisão de introduzir um recurso não é definitiva. Antes de entrar em nossa lista de tarefas, sempre fazemos uma verificação completa de sanidade:

  • Quais benefícios esse recurso trará para os usuários?
  • Ele se encaixa na nossa filosofia de produto?
  • Isso adicionará complexidade desnecessária?
  • Ele combina bem com a interface e a funcionalidade existentes?
  • Temos os recursos para entregá-lo em um prazo razoável?

Quando um recurso passa na lista de verificação e os proprietários do produto o aprovam, é hora de ir para a prancheta.

Projetando para o usuário

A experiência nos ensinou que adicionar um novo recurso não significa apenas colocá-lo em cima da interface do usuário - você precisa misturá-lo com o design existente, com o usuário em mente. Se você não fizer isso, logo acabará com um aplicativo tão complexo que apenas alguns poucos corajosos conseguirão passar pelos primeiros cinco minutos do teste (sim, já estivemos lá). A estética também é importante para uma boa primeira impressão, mas nossa principal preocupação é a facilidade de uso . Um recurso precisa ser adicionado de uma maneira que pareça natural para o usuário.

Mantemos as coisas em perspectiva perguntando: Onde o usuário espera que essa opção esteja?

Para os usuários existentes, é importante que o novo design siga os padrões com os quais eles estão familiarizados e não interrompa seu fluxo de trabalho. Além disso, existem padrões e convenções da indústria com os quais todos (inconscientemente) estamos acostumados. Nunca espere que seus usuários mudem completamente seus hábitos. Eles provavelmente procurarão em outro lugar se a interface não for intuitiva.

Pegue atalhos de teclado. Você pode criar seu próprio conjunto de atalhos e esperar que os usuários os aprendam (eles provavelmente não aprenderão). Ou você pode adicionar aqueles que as pessoas já usam. Muitos de nossos usuários já usam o Slack, por exemplo, então adicionamos um atalho com o qual eles já estão familiarizados ( Command + K para saltos rápidos também funciona no Active Collab ).

Janela de salto rápido no Active Collab
Command + K abre esta janela, que permite ao usuário saltar rapidamente para uma página no Active Collab. (Ver versão grande)

Quando os fluxos do usuário estão em vigor, nosso designer de UX simula o design no Sketch. Raramente usamos HTML nos estágios iniciais. As visualizações do Sketch bem pensadas nos dão flexibilidade suficiente para que não precisemos retroceder quando começamos a codificar. O design inicial geralmente acaba correspondendo a cerca de 80% do produto final. O resto é adicionado e ajustado ao longo do caminho.

Maquetes de design de recursos
Maquetes de design inicial são a base para o desenvolvimento posterior. (Ver versão grande)

Outra etapa importante do processo de design é a cópia. Nossos redatores dedicam muita atenção a cada palavra. Temos até nosso próprio guia de estilo, para soar o mais acessível e fácil de entender possível. Por exemplo, dizer “certificado de segurança” em vez de “certificado SSL” transmite em termos leigos algo com o qual um usuário comum pode não estar familiarizado.

Quando tudo isso é feito, o recurso é atribuído a uma equipe de desenvolvimento. A equipe é composta por um gerente de projeto, um desenvolvedor líder e vários desenvolvedores de back-end e front-end, dependendo da carga de trabalho. O gerente de projeto garante que tudo corra bem e dentro do cronograma, enquanto o desenvolvedor líder cuida do lado técnico das coisas. Eles também coordenam e orientam desenvolvedores juniores.

Hora de começar as coisas

Nossas reuniões iniciais não são reuniões motivacionais chatas. São oportunidades para uma equipe de desenvolvimento (composta por desenvolvedores juniores e seniores) se reunir com o gerente de projeto e o proprietário do produto.

Em vez de permitir monólogos vazios, nos concentramos em colocar as palavras de todos em tarefas acionáveis. Ao longo do dia, acontecem três reuniões importantes :

  • O proprietário do produto apresenta o recurso fornecido para a equipe, as ideias por trás dele, os projetos iniciais e os resultados esperados.
  • Em seguida, a equipe tem sua própria reunião na qual discute o plano de ação, os possíveis problemas e o cronograma de testes.
  • A reunião final conta com a presença de todos os envolvidos, e o plano toma sua forma final. No final desta reunião, a equipe fornece estimativas para demonstrações e uma data final de entrega.

Três reuniões podem parecer muito para um dia, mas é assim que garantimos que os problemas sejam resolvidos desde o início. Preencher as lacunas neste estágio economiza muito tempo para nossos desenvolvedores, falsas partidas e retrocessos. As reuniões também estimulam o trabalho em equipe e fazem com que todos sintam que suas contribuições são bem-vindas.

Reunião de equipe
As equipes passam o tempo que precisam discutindo todos os aspectos do trabalho à frente.

Após as reuniões, a equipe terá todas as informações necessárias:

  1. Que? Esse é o escopo do recurso e inclui tudo o que precisa ser feito, bem como possíveis bloqueadores e gargalos. Tentamos antecipar o maior número possível de cenários e casos extremos. Prever todos eles não é fácil; eles muitas vezes surgem à medida que avançamos.
  2. Por quê? O proprietário do produto estima o valor comercial de um recurso e explica por que vale a pena o esforço. Dessa forma, a equipe obtém uma visão clara dos benefícios para os clientes e para o produto. O principal motivador aqui é que todos devem entender por que seu trabalho é importante e como ele contribui para a empresa como um todo.
  3. Quão? Ao descrever as etapas necessárias para concluir um recurso , garantimos que nossos desenvolvedores nunca percam a bússola. Também definimos expectativas realistas adicionando uma tag de complexidade. Optamos por tamanhos de camisetas - S pode ser resolvido em poucas horas, enquanto XXL leva semanas ou mais para ser concluído.
  4. Quem? O líder da equipe é responsável por concluir um recurso ou tarefa no prazo e por atualizar o proprietário do produto sobre o progresso. Outros membros da equipe são atribuídos a seu próprio conjunto de subtarefas, para que fique perfeitamente claro quem é responsável pelo quê. Manter isso o mais transparente possível nos ajuda a ver se alguém está com dificuldades ou causando atrasos.
  5. Quando? Com tudo considerado, estima-se uma data de vencimento . Se uma tarefa estiver atrasada, analisamos os motivos e usamos essa experiência na próxima vez. Dessa forma, um prazo perdido se torna uma oportunidade de aprendizado e não uma fonte de estresse.

O dia do pontapé inicial pode ficar agitado, mas também é muito frutífero. Todos contribuem com ideias e comentários. Uma tarefa se transforma de um slate vazio em um hub para comentários, edições e atualizações. No final do dia, a equipe de desenvolvimento tem uma visão clara do trabalho à frente e um terreno sólido para construir.

Uma tarefa no Active Collab
Todas as informações importantes estão disponíveis no item de tarefa. É também onde os membros da equipe se comunicam e publicam atualizações sobre seu progresso. (Ver versão grande)

Passamos por esta lista de verificação antes de começar o trabalho:

  • recurso explicado,
  • etapas para conclusão descritas,
  • valor comercial atribuído pelo proprietário do produto,
  • complexidade atribuída pela equipe,
  • dependências de recursos e bugs identificadas,
  • critérios de desempenho identificados (se necessário),
  • demonstrações agendadas,
  • datas de início e término definidas pelo líder da equipe.

Este é o momento em que uma tarefa passa para a coluna “Em andamento”.

Tarefa movida para a coluna Em andamento
Quando um recurso é iniciado, a tarefa é movida para a coluna "Em andamento". (Ver versão grande)

É hora de codificar!

Trabalho em equipe em exibição

Nossos desenvolvedores nunca trabalham sozinhos — é sempre um esforço de equipe e é de longe a maneira mais eficiente de lançar novos recursos. Antes que as equipes fossem introduzidas, um desenvolvedor (júnior) ficava preso em um problema e poderia ficar andando em círculos por dias (sem que ninguém percebesse). Ou, se não fossem do tipo solitário, estariam constantemente distraindo colegas e gerentes.

Por outro lado, com equipes, misturamos pessoas com diferentes conjuntos de habilidades e níveis de experiência. Isso significa que todos recebem um conjunto de tarefas apropriadas ao seu nível. Além disso, os seniores têm o benefício de aprender a gerenciar e treinar colegas de equipe juniores – e os juniores podem pedir ajuda. Como é um esforço de equipe e todos estão trabalhando para o mesmo objetivo, as perguntas não são consideradas distrações, e a equipe pode resolver qualquer problema com muito mais eficiência. A equipe se torna uma entidade auto-organizada, dividindo o trabalho em fases (ou sprints) e apresentando seu trabalho durante as demonstrações.

Mostra e diz

De acordo com o cronograma, a equipe fará uma demonstração para o proprietário do produto. O objetivo das demonstrações é mostrar o desempenho de um recurso em seu estado atual e onde ele precisa de mais polimento. É uma verificação da realidade que não permite desculpas como: “Só precisa de alguns toques finais” (toques que levariam mais um mês). Além disso, se as coisas começarem a tomar um rumo errado, os proprietários de produtos reagirão rapidamente.

Reuniões semanais

Começamos com pequenas reuniões diárias regulares com a participação de todos os desenvolvedores. Cada desenvolvedor descreveria brevemente em que estava trabalhando, seus problemas, seus bloqueadores e se precisava de ajuda. Logo ficou óbvio que essas reuniões precisavam ser mais focadas e fornecer resultados tangíveis. Então, passamos a ter reuniões com equipes individuais cerca de uma vez por semana. É assim que os proprietários do produto e o gerente de projeto são mantidos informados e todos os problemas potenciais são tratados no local.

Colocando à prova

O código está escrito, as demos foram bem-sucedidas, tudo parece estar se encerrando bem… até você liberar o recurso e ver que o aplicativo trava. É por isso que todos os recursos que fazemos passam pela garantia de qualidade (Q/A). Sempre. Nosso testador passa meticulosamente por todos os cenários possíveis, verificando todas as opções e executando testes em diferentes ambientes. Um recurso raramente passa na Q/A de primeira.

Procurando por erros
Q/A garante que nenhum bug passe. (Ver versão grande)

Para aumentar a produtividade, costumávamos permitir que os desenvolvedores iniciassem novos recursos durante essa fase, mas isso resultou em muitos recursos atrasados ​​e semi-acabados. Portanto, agora a equipe de desenvolvimento se mantém ocupada trabalhando em pequenas tarefas de manutenção enquanto seu recurso está sendo revisado. Se o Q/A encontrar um problema, os desenvolvedores o corrigirão imediatamente e o enviarão novamente. O processo é repetido até que o recurso passe na Q/A e passe para a revisão de código.

É quando um desenvolvedor sênior garante que o código seja escrito de acordo com nossos padrões. Uma etapa final antes do lançamento é escrever a documentação — você não quer ser inundado por e-mails de suporte depois de lançar um recurso que ninguém sabe como usar. Nossos redatores também atualizam as notas de lançamento e escrevem materiais de marketing, como anúncios por e-mail e postagens no blog.

Aqui está nossa definição de “pronto”:

  • auto-testes escritos,
  • Perguntas e respostas concluídas e todas as tarefas resultantes concluídas,
  • revisão de código concluída e código mesclado ao mestre,
  • notas de versão atualizadas,
  • dependências de recursos e bugs identificadas.

A tarefa chegou ao estágio final, chamado de “Release Q”.

Dia de lançamento

Dia de lançamento: terça-feira
Nosso objetivo é um lançamento de terça-feira. (Ver versão grande)

Ao escolher um dia para novos lançamentos, imediatamente decidimos contra sexta e segunda-feira. Sexta-feira não é bom porque quaisquer problemas potenciais não seriam resolvidos até segunda-feira; além disso, a equipe de suporte já estava bastante ocupada. Segunda-feira não é o melhor momento porque qualquer atualização importante requer preparação, o que teria que ser feito no fim de semana. É sempre bom deixar um dia para os retoques finais. Isso reduz as opções para três dias – e optamos pela terça-feira. Aqui está o porquê:

  • Temos segunda-feira para revisar o lançamento e adicionar toques finais antes da implantação.
  • Se houver alguma frase não traduzida (nosso aplicativo da web está disponível em sete idiomas), temos tempo suficiente para concluir a tradução.
  • A equipe de marketing tem tempo de sobra para enviar boletins informativos e anúncios via mídia social.
  • Estamos disponíveis para fornecer suporte de atualização de forma rápida e eficiente pelo resto da semana.
  • Se um prazo tiver passado por qualquer motivo, ainda temos quarta ou quinta-feira para concluir o trabalho.

Dia de Atividade Gratuito

O dia após um grande lançamento é um dia livre para a equipe. É quando eles aprendem novas habilidades ou fazem qualquer coisa relacionada ao trabalho que acham interessante. Embora todos estejam ansiosos para saber qual recurso lançaremos no dia seguinte, a equipe ainda não discute isso. Em vez disso, eles vão relaxar e talvez assistir a uma apresentação sobre a história do Erlang, ou terminar de ler aquele artigo sobre por que o PSR-7 e o middleware são importantes para o desenvolvimento PHP moderno, ou ter sua própria discussão retrospectiva. É um dia bem merecido para recarregar a bateria e comemorar um trabalho bem feito.

Dia de caça aos insetos

Além de desenvolver novos recursos importantes, sempre há trabalho a ser feito nos existentes. Seja uma correção de bug, uma atualização de design ou uma pequena alteração na funcionalidade, a equipe precisa cuidar disso em um tempo razoável.

Caçando insetos
Limpar o backlog de bugs é muito mais rápido quando um dia é dedicado apenas a isso. (Ver versão grande)

É por isso que temos dias de caça aos insetos pelo menos uma vez por mês. É quando todos os desenvolvedores param de trabalhar em seus principais projetos e voltam sua atenção para a manutenção. Este esforço concentrado provou ser um grande sucesso. Quando todos trabalham apenas em bugs no mesmo dia e estão disponíveis para ajudar uns aos outros, a equipe resolve um grande número de problemas.

Qual é o resultado?

O lançamento de um grande recurso agora leva cerca de três semanas em média, desde o início até o desenvolvimento, teste, revisão de código, documentação e lançamento final. Um recurso de complexidade equivalente costumava nos levar 45 dias. Do nosso ponto de vista, isso representa um aumento de 100% na produtividade . Realizamos isso com os mesmos recursos e pessoas, a única diferença é um fluxo de trabalho aprimorado.

Portanto, se temos uma lição para você, é esta: nutrir uma cultura da empresa que elimine o medo da mudança tornará sua equipe melhor no que faz. Não importa se você chama isso de Scrum, Kanban ou Lean, desde que ajude sua empresa a crescer. Experimentação e inovação estão no centro de qualquer abordagem ágil. Não tenha medo de testar soluções diferentes, medir resultados e, com base nos resultados, modificar as práticas existentes. Bons resultados virão.