Voltar

Detalhes & prosperar: Como as equipes de Engenharia, Produto e Projeto da Gather corrigiram 116 bugs em duas semanas

Nossa equipe de EPD (Engenharia, Produto e Design) realizou um sprint de duas semanas totalmente focado nos detalhes da experiência do Gather , no qual foram corrigidos 116 bugs! Conversamos com três membros da equipe para dar uma olhada nos bastidores desse sprint exclusivo.

Voltar

Detalhes & prosperar: Como as equipes de Engenharia, Produto e Projeto da Gather corrigiram 116 bugs em duas semanas

Fotografia de Philip Wang
Morgan Smith

Há algumas semanas, nossa equipe de EPD (Engenharia, Produto e Design) decidiu testar um novo tipo de sprint: A Semana de Detalhes. Ou como a apelidamos internamente: Details & Thrive! 

Esse sprint foi totalmente focado nos detalhes da experiência do Gather . E, em apenas duas semanas, a equipe realizou 116 correções de bugs e melhorias na plataforma. Sério, uma salva de palmas para eles! 👏 

Para comemorar o trabalho árduo realizado nesse sprint, Liz George, Head of Community da Gather, sentou-se com três membros da equipe para dar uma olhada nos bastidores. 

Assista à gravação da transmissão ao vivo aqui ou leia a transcrição abaixo. 

‍Liz: Olá a todos, sou Liz George, diretora da comunidade aqui em Gather. Vou passar a palavra à equipe para fazer algumas apresentações.

Justin: Olá a todos, sou Justin Key, gerente de produtos da Gather e moro em Seattle. Em poucas palavras, meu trabalho como gerente de produtos é definir a visão, a estratégia e os requisitos de recursos para os produtos que criamos. Em seguida, faço parceria com a equipe de Design e Engenharia e outras partes interessadas internas e externas para levar esses produtos ao mercado. 

Josh: Olá a todos, eu sou Josh. Sou gerente de engenharia na equipe do aplicativo principal, com sede em Vancouver. E, como Justin disse, trabalhamos em estreita colaboração com o Produto e o Design para executar os recursos voltados para o usuário que criamos. 

‍Lau: E eu sou o Lau. Lidero a equipe de Design aqui na Gather. Nossos desafios estão em tudo, desde o design de interação até o visual e a marca. Também trabalho com a Engenharia e o Produto para definir esses problemas de uma forma super centrada no usuário. 

Liz: Incrível! No espírito do trabalho remoto, acho que seria ótimo se todos pudessem compartilhar nossas localizações. Estou na área da Baía de São Francisco.

‍Lau: Normalmente trabalho em Toronto, no Canadá, mas no momento estou em Dublin, na Irlanda. 

Josh: Como mencionei, geralmente estou em Vancouver, mas no momento estou em São Francisco. 

Justin: Estou baseado em Seattle. 

Liz: Muito bem, vamos direto ao assunto. Para os novos usuários, diga-nos o que é Gather e, de modo geral, no que a equipe de produtos está focada no momento .

Justin: Em um nível muito alto, o Gather ajuda equipes distribuídas ou remotas a criar espaços digitais que reúnem todos e fazem com que as interações virtuais pareçam mais humanas. Quando nossos clientes estão usando seu espaço virtual (seu escritório virtual), seja para colaborar em reuniões, trabalhar em um coworking ou passar pela mesa virtual de alguém, a conexão com sua equipe se torna uma experiência mais energizante, em que o trabalho produtivo, o trabalho colaborativo e a cultura da empresa podem acontecer independentemente de onde os membros da equipe estejam. 

Em termos de algumas das coisas em que estamos trabalhando, alguns exemplos são os aprimoramentos da nossa experiência de reunião, incluindo recursos como gravação de tela e integrações de calendário mais detalhadas para ajudar nossos usuários a agendar reuniões e participar de reuniões em Gather. Além de melhorias divertidas em nosso aplicativo para desktop, no próximo ano teremos um aplicativo móvel Gather totalmente novo, com o qual estamos muito animados!

‍Lau: Sim, definitivamente tudo o que o Justin descreveu. Quero dar um toque especial ao foco do design. GatherOs desafios de design da plataforma em si são muito interessantes e acho que são realmente diferentes de tudo o que existe no mercado. 

Estamos falando de uma plataforma em que as pessoas interagem umas com as outras, mas não é só isso, há também um mundo associado a ela. E estamos tentando realmente aprimorar a forma como as pessoas trabalham nesse espaço. 

A parte legal de trabalhar com esse produto é que estamos sempre criando novos padrões de interação, pegando coisas que pertencem a produtos existentes. Você tem os padrões de interface do usuário das plataformas de reunião que existem, e nós os estamos adaptando para esse mundo que é bastante novo na maneira como as pessoas podem se conectar umas às outras. 

Portanto, esse é um desafio muito legal que temos com o foco no trabalho remoto, além de garantir que as pessoas estejam facilmente conectadas umas às outras, independentemente de onde estejam no mundo ou até mesmo do fuso horário. 

Josh: Acho que Justin e Lau falaram perfeitamente sobre isso. Eles disseram tudo o que eu teria dito. 

Liz: Bem, isso significa que você será o próximo a responder à próxima pergunta! Então, hoje vamos falar sobre algo novo que a equipe fez: A Semana dos Detalhes. Você gostaria de compartilhar o que é isso e como é diferente de um sprint normal de Produto e Engenharia?

Josh: Justin, você quer começar e depois eu acrescentarei a perspectiva da engenharia? 

Justin: Sim, , vou dar o pontapé inicial. Então, mais uma vez, em um nível elevado, nós nos movemos muito rapidamente na Gather para trazer novos produtos e recursos para nossos clientes. A qualquer momento, temos vários projetos, nem sei dizer quantos estão em vários estágios de desenvolvimento. 

Com o passar do tempo, à medida que criamos, lançamos e repetimos novos recursos, inevitavelmente introduzimos bugs na experiência do cliente. E também identificamos as melhorias necessárias nos recursos, as alterações que queremos fazer ou o feedback do cliente que queremos incorporar. 

Portanto, com o nosso sprint Details and Thrive, o que essencialmente fizemos foi reservar um tempo para que toda a equipe se concentrasse em acertar esses detalhes. Corrigir esses bugs, incorporar essas pequenas solicitações de recursos incrementais e priorizar o trabalho focado em toda a equipe e dedicar tempo para trabalhar em nosso backlog de recursos mais amplo, enquanto pausávamos algumas das iniciativas de produtos maiores nas quais estávamos trabalhando. 

Josh: Para acrescentar a isso, do ponto de vista da engenharia, em muitas empresas, você está sempre tentando equilibrar "Como podemos avançar rapidamente?". "Como construir as coisas que realmente queremos lançar?" e "Como também garantir que elas sejam de alta qualidade?" 

E pode ser fácil cair um pouco demais em um lado ou no outro. Pode ser fácil tentar deixar as coisas tão perfeitas porque há tantas coisas que queremos criar para nossos usuários e realmente queremos ter certeza de que elas são ótimas. Mas podemos passar tanto tempo em uma coisa, tentando garantir que ela seja perfeita, que talvez não consigamos chegar a essas outras coisas. 

Por outro lado, podemos acabar fazendo o contrário, gastando tanto tempo tentando desenvolver todas as coisas interessantes que é fácil perder o foco nesses detalhes. 

Portanto, acho que isso nos deu a oportunidade de garantir que estávamos reservando um tempo explícito para os detalhes. E acho que também fomos muito intencionais com relação a isso. 

Isso nos permitiu ser realmente intencionais sobre o que queríamos fazer e garantir que tivéssemos tempo para fazê-lo, o que acho que foi fundamental. 

‍Lau: Acho que é muito importante observar também que a própria Gather é muito nova. Eu estava falando anteriormente sobre todos esses novos padrões de interação que temos. Quando começamos, começamos como experimentos. Será que isso vai pegar? Será que esse será o recurso certo para seguirmos em frente? Como vamos fazer isso evoluir para além de um MVP, por exemplo?

E com o passar do ano, em que olhamos para trás e dissemos "Ok, quais são as coisas que precisamos ajustar?", aprendemos muito com nossos experimentos iniciais. E não apenas aprendemos muito com isso, mas também vimos isso no mundo real com outras plataformas. 

Como tivemos uma grande repercussão nesse espaço, muitas outras plataformas também estavam pegando nossos padrões, imitando-os e colocando-os no mercado. 

Portanto, não apenas tínhamos nossa própria dívida com o Design e a Engenharia, mas também tínhamos uma dívida com as outras plataformas existentes por colocar coisas que estávamos experimentando. 

Portanto, esse período foi muito bom para fazermos uma retrospectiva e vermos como isso afetou nossa plataforma e a maneira como as pessoas se conectam umas com as outras, e como podemos melhorá-la para que as pessoas possam realmente fazer as coisas que precisam fazer no Gather de uma maneira fácil e agradável. 

‍Liz: Obrigada por compartilhar isso. Isso é algo realmente diferente de outras abordagens que já adotamos antes?

‍Lau: Acho que, sem dúvida, éramos um pouco mais experimentais no passado e, como Josh e Justin disseram, nos movemos com extrema rapidez. É ótimo que façamos isso porque podemos aprender muito rapidamente, mas também cometemos muitos erros ao longo do caminho. 

Então, olhando para trás e vendo: "Ok, talvez devêssemos ter feito isso de forma um pouco diferente". É esse aprendizado que podemos levar para o próximo desafio. Portanto, estamos aprendendo continuamente não apenas a trabalhar uns com os outros na Engenharia e no Produto, mas também a trabalhar dentro do espaço que é tão complexo na forma como todos nós nos conectamos uns aos outros. 

‍Liz: Vocês três têm funções extremamente diferentes. Pode me explicar qual foi sua função no sprint?

Justin: Em primeiro lugar, é um trabalho de equipe. Eu, especificamente, trabalhei com Josh e Lau e suas equipes para organizar e priorizar a lista de bugs e melhorias de recursos que queríamos trabalhar durante o sprint. Em seguida, dei minha opinião sobre cada um deles para garantir que tudo fosse criado e funcionasse como pretendido. 

Josh: Sim, como o Justin disse, foi sem dúvida um esforço extremamente colaborativo. Acho que para mim, como gerente de engenharia, eu só queria que a equipe tivesse as ferramentas certas e se sentisse apoiada. 

Como mencionei, havia muitas coisas que queríamos fazer. Houve a excelente publicação no blog: 116 bugs, detalhes e melhorias que fizemos.

Havia ainda mais ingressos do que isso. Tínhamos um monte de coisas que queríamos resolver. Portanto, era preciso garantir que a equipe se sentisse apoiada e entendesse como lidar com essas questões. 

Uma olhada em alguns dos ingressos concluídos, que organizamos no Linear.

‍Lau: Da mesma forma que Justin e Josh, trabalhávamos juntos todos os dias. Nós nos reuníamos por algumas horas todos os dias para garantir que todas as tarefas que havíamos coletado - desde o feedback dos usuários até a nossa própria equipe interna - fossem analisadas e classificadas adequadamente para que nossa equipe pudesse pegá-las facilmente, entendê-las e projetá-las ou desenvolvê-las. Portanto, esse foi o esforço colaborativo que realizamos. 

E, do ponto de vista do design, minha função era garantir que minha equipe de design se sentisse capacitada para tomar decisões com base nesses tíquetes. Eles tinham informações suficientes para que pudessem ir em frente e criar uma melhoria no formato pré-existente, mas também para garantir que o design acabasse sendo holístico. 

O feedback que recebemos e as tarefas que anexamos a esses tíquetes eram de todos os tipos de partes diferentes da plataforma. Portanto, desde o vídeo até as configurações, tudo estava espalhado por toda parte. Por isso, tive que garantir que toda a nossa equipe tivesse a mesma interface visual, padrões de interação e princípios de design que a nossa própria equipe tem, para garantir que tudo parecesse parte da mesma plataforma. 

Liz: Agora que já falamos sobre o que é. Como decidimos dedicar equipes inteiras a esses detalhes por duas semanas inteiras?Como decidimos dedicar equipes inteiras a esses detalhes por duas semanas inteiras?

Justin: Esse tipo de trabalho geralmente é colocado em nossa lista de pendências quando priorizamos os projetos maiores e mais estratégicos, como os que mencionei anteriormente. Individualmente, essas coisas são pequenas: esses bugs, essas melhorias de recursos. Mas, coletivamente, eles se somam e começam a afetar a percepção dos nossos clientes sobre o funcionamento do Gather . 

A certeza de que os detalhes estão corretos garante que o Gather seja uma experiência refinada e que atenda às necessidades e expectativas de nossos clientes. 

‍Lau: O design é essencialmente a busca constante de maneiras de melhorar nossa plataforma. Não esperamos por um determinado momento para ver como podemos melhorar as coisas. Estamos sempre olhando para as coisas e pensando: "Hmm, isso não parece muito bom". Assim, estabelecemos horários em nossas próprias semanas para garantir que esses pequenos problemas sejam resolvidos. 

Mas o que a Details Week fez foi nos ajudar a realmente nos concentrarmos nisso e a torná-lo nossa prioridade total. Assim como qualquer outro designer, nossa própria plataforma nos incomoda. Quanto mais a examinamos, mais imperfeições temos. Portanto, é uma lista interminável de melhorias que queremos fazer. 

Josh: Sim, e acho que o que eu queria acrescentar a tudo isso é que todos nós tínhamos o mesmo tipo de mentalidade. Estávamos todos trabalhando nisso ao mesmo tempo. 

Normalmente, estamos trabalhando em vários projetos paralelamente e pensando em vários problemas diferentes nesses grupos maiores. O Details and Thrive nos ajudou a entrar na mesma página sobre a tentativa de estar na mentalidade de eliminar esses detalhes menores e realmente melhorar o produto como um todo coletivamente. O que eu acho que foi muito útil e muito bom ter todos juntos ao mesmo tempo. 

Liz: Então, identificamos os problemas: Muitas dessas coisas estavam no backlog. Queremos ter certeza de que as coisas estão perfeitas porque estamos constantemente olhando para a tela e vendo esses bugs aparecerem. Como vocês decidiram em quais se concentrariam?

Justin: Pensando primeiro no processo, já tínhamos um acúmulo de bugs, feedback de recursos e solicitações de clientes que estávamos coletando ao longo de muitos meses de trabalho. 

Depois que decidimos que queríamos prosseguir com esse sprint Details and Thrive, também entramos em contato com a nossa organização interna mais ampla Gather para solicitar contribuições da equipe ou outros feedbacks ou solicitações de recursos que eles tivessem. No final, coletamos bem mais de 300 novas solicitações e recursos, que organizamos como tíquetes. Analisamos cada um deles, um a um, em todo o grupo aqui (Produto, Design e Engenharia) para priorizar o trabalho. 

Em seguida, Lau e eu trabalhamos juntos para adicionar a definição de Produto e Design onde precisávamos, para ajudar a definir o que realmente queríamos construir e como deveria ser a aparência e a sensação. E então reunimos a equipe. 

Josh pegou todos esses tíquetes e trabalhou com sua equipe para atribuí-los a diferentes engenheiros. Lau fez o mesmo com sua equipe de design. Em seguida, trabalhamos juntos durante cerca de duas semanas para trazer essas melhorias para a experiência do cliente no site Gather . 

Liz: Incrível! Como foi o processo de revisão e desenvolvimento?

Josh: Basicamente, passamos pelo mesmo processo que fazemos com outros recursos. Geralmente, temos uma ideia das coisas que queremos fazer. Como Justin disse, coletamos todos esses insights, então temos uma boa noção do que focar. 

E, quando começamos a trabalhar neles, fazemos uma revisão. Fazemos o controle de qualidade, uma revisão do design e uma revisão do código para garantir que a qualidade do código seja boa e que não estamos introduzindo mais problemas. À medida que adicionamos mais, queremos ter certeza de que estamos melhorando a qualidade à medida que avançamos. 

Depois que tudo estiver certo, revisaremos o código, aprovaremos e ele será mesclado e, normalmente, as coisas entrarão no ar em uma semana após a conclusão. 

‍Liz: Mudando um pouco de assunto, qual foi o seu bug favorito que a equipe corrigiu?

Josh: Para mim, tivemos muitas solicitações durante muito tempo para evitar que seu avatar fosse seguido. Isso acontece em muitos lugares: Por exemplo, às vezes você está fazendo uma demonstração e alguém sai um pouco e fica seguindo seu avatar de forma estranha, e você tem que sair ou entrar ou qualquer outra coisa.... 

Então, acrescentamos isso, e o esforço acabou sendo muito maior do que parecia à primeira vista. Não teríamos conseguido fazer isso sem esse tempo dedicado. E você sabe, acho que é algo muito impactante. Sei que é útil para mim, por isso fiquei muito empolgado com esse recurso específico. 

Um exemplo de como agora você pode impedir que as pessoas sigam seu avatar.

‍Lau: Vou falar em seguida. Não é bem um bug, mas é mais um recurso que acabamos fazendo. Portanto, tudo relacionado à experiência do hóspede - e minha parte favorita é a tag "Convidado". Portanto, quando você está em um ambiente de trabalho remoto e há uma nova pessoa que não faz parte do seu escritório, adicionamos uma tag "Convidado" ao nome dela e à lista de participantes para garantir que as pessoas saibam que essa pessoa não é um membro da equipe. 

Um exemplo da tag "Convidado" ao lado dos nomes e no Painel de participantes.

E acho que gosto muito disso por alguns motivos. Primeiro, se pensarmos em nossa experiência em um escritório na vida real, conhecemos nossos colegas de trabalho só de olhar para eles. Com sorte, você conhece o rosto deles e se lembra do rosto deles e, quando vê alguém novo, automaticamente o "reconhece" porque nunca viu aquele rosto antes. 

Mas aqui em Gather, estamos meio que escondidos atrás de avatares. Talvez eu troque meu avatar por um fantasma na época do Halloween (acho que no ano passado eu era um morcego no Halloween em Gather). E, às vezes, se eu não estiver com meu nome, talvez eu tenha "Batman" ou algo assim, para que ninguém saiba que sou eu. 

Portanto, se eu fosse um convidado e também me chamasse "Batman", talvez eles pensassem "Ah, esse é o Lau", mas não - na verdade, é um convidado. Portanto, ter essa tag direta realmente ajuda os gerentes de escritório e qualquer pessoa que esteja entrevistando ou procurando alguém específico a dizer rapidamente: "Ok, esse é um convidado". 

Eu penso nisso como a etiqueta "Olá, meu nome é..." quando você vai a uma conferência, e fica muito claro quem é quem nesse momento. 

‍Liz: Para mim, a tag Convidado é extremamente útil porque, na verdade, eu ia ter uma reunião com um membro da nossa equipe, mas olhei e vi que ela estava falando com alguém que era convidado. Então eu pensei: "Ah, preciso dar bastante tempo a ela, porque ela está falando com alguém de fora da empresa". E pude respeitar isso ao ver a tag Guest. Então, eu realmente gosto muito dessas filas não verbais. 

Justin: Um grande "mais um" para tudo o que vocês mencionaram. Vou ser breve: como usuário do Gather, gostei muito de algumas das melhorias incrementais que fizemos em nossas experiências de bate-papo e emotes. Coletivamente, elas facilitam ainda mais a comunicação com os colegas em Gather. Mesmo que essas coisas sejam relativamente pequenas e incrementais, elas contribuem muito para que nos sintamos mais conectados. 

Agora você pode enviar mensagens de bate-papo com várias linhas! Apenas um dos pequenos detalhes que corrigimos.

‍Liz: Que conselho você daria a outras equipes interessadas em fazer um Sprint de detalhes semelhante?

Josh: Acho que já falei sobre isso antes, mas reservar um tempo para isso é muito importante. É muito fácil se concentrar nos projetos maiores e fazer com que as coisas saiam, e às vezes surgem pequenos problemas que resolvemos rapidamente, mas há aquelas coisas intermediárias para as quais é difícil reservar tempo. 

E acho que foi muito importante termos definido esse tempo e o esculpido, e que todos estivessem com a mesma mentalidade. Portanto, acho que esse foi um aspecto fundamental que eu recomendaria se você fosse fazer algo assim. 

‍Lau: Meu conselho é que, quando estiver escrevendo tarefas ou quando estiver procurando organizar esses pensamentos ou feedbacks, tenha uma maneira muito boa de descrever o problema que está tentando resolver, por que está tentando resolvê-lo, como ele era antes e o que pensa sobre como ele poderia ser depois. 

Mesmo que isso provavelmente mude quando você entrar no processo de design, isso ajuda a fundamentar a ideia um pouco melhor para que haja menos tempo gasto tentando descobrir "O que isso significa?". 

Portanto, é mais como administrar as tarefas e definir as partes de sua plataforma nas quais você deseja se concentrar. 

Justin: Para encerrar, tudo isso é para tornar o Gather melhor para nossos clientes. Portanto, meu conselho seria: Coloque-se no lugar do seu cliente. Entenda como é a experiência cotidiana deles com seu produto. 

Se você não estiver acertando os detalhes, é bem provável que eles não gostem do seu produto. Ou, no mínimo, não ficarão tão satisfeitos quanto poderiam. Portanto, certifique-se de que está se preocupando com os detalhes em nome deles. 

De modo geral, a equipe concordou que esse tipo de abordagem funcionou muito bem para resolver muitos dos bugs e problemas que estavam causando problemas na experiência geral do Gather . Estamos animados para continuar compartilhando mais informações sobre nosso processo à medida que continuamos a tornar o Gather o melhor possível, pouco a pouco. Não deixe de conferir nosso blog Pixel-Perfect Details: 116 Bug Fixes & Improvements blog para ver tudo o que a equipe abordou.

Fique atento a mais transmissões ao vivo como esta, pois estamos apenas começando!

Melhorar as coisas, pouco a pouco.

- A equipe Gather

Volte a se sentir como uma equipe no Gather

Quero começar