Melhor colaboração ao trazer designers para o processo de revisão de código

A colaboração suave entre desenvolvedores e designers é algo que todos aspiram, mas é notoriamente difícil. Mas com a web avançada de hoje, é difícil — se não impossível — criar um produto realmente excelente sem a colaboração entre disciplinas. Devido à variedade de tecnologias necessárias para construir um produto, o produto só pode realmente ter sucesso quando todas as disciplinas – desenvolvedores e designers, criadores de conteúdo e estrategistas de experiência do usuário – estão profundamente envolvidos desde os estágios iniciais do projeto. Quando isso acontece, todas as extremidades do que é necessário para construir um produto se unem naturalmente em um todo unificado e, portanto, um ótimo produto.

Por causa disso, ninguém está mais promovendo processos em cascata. No entanto, envolver outras pessoas desde o início, especialmente pessoas de outras disciplinas, pode parecer assustador. Na pior das hipóteses, leva ao “design por comitê”.

Além disso, designers e estrategistas de conteúdo geralmente têm experiência em campos em que um único gênio criativo ainda é o ideal. Ter alguém provando seu trabalho pode parecer uma ameaça à sua criatividade.

Então, como você pode envolver as pessoas desde o início para evitar a cascata, mas também para garantir que você não esteja se preparando para o projeto pelo comitê? Encontrei minha resposta ao aprender sobre revisões de código.

O Ah! Momento

Em julho de 2017, fundei a Confrere junto com dois desenvolvedores e rapidamente contratamos nosso primeiro engenheiro (eu não sou desenvolvedor, sou mais UX ou designer de conteúdo). Nossa colaboração estava funcionando surpreendentemente bem, tanto que em nossas retrospectivas, o tema recorrente era que todos sentíamos que estávamos “fazendo certo”.

Sentei-me com meus colegas para tentar identificar o que exatamente estávamos “fazendo certo” para que pudéssemos tentar preservar esse sentimento mesmo com o crescimento da empresa e a expansão da equipe. Chegamos à conclusão de que todos apreciamos o envolvimento de toda a equipe desde o início e que estávamos sendo honestos e claros em nosso feedback um para o outro. Nosso CTO Dag-Inge acrescentou: “Funciona porque estamos fazendo isso como pares. Você não está sendo repreendido e apenas recebendo uma lista de falhas”.

A palavra “par” é o que me deu o momento aha. Percebi que aqueles de nós que trabalham com UX, design e conteúdo têm muito a aprender com os desenvolvedores quando se trata de colaboração.

A revisão por pares na forma de revisões de código é essencial para como o software é construído. Para mim, as revisões de código oferecem inspiração para melhorar a colaboração em nossos próprios campos, mas também um modelo para colaboração entre campos e disciplinas.

Se você já estiver familiarizado com revisões de código, fique à vontade para pular a próxima seção.

O que é uma revisão de código?

Uma revisão de código pode ser feita de várias maneiras. Hoje, a forma mais típica de revisão de código acontece na forma das chamadas pull requests (usando uma tecnologia chamada git). Conforme ilustrado abaixo, as solicitações pull permitem que outras pessoas da equipe saibam que um desenvolvedor concluiu o código que deseja mesclar com a base de código principal. Também permite que a equipe revise o código: eles dão feedback sobre o código antes de ser mesclado, caso precise de melhorias.

As solicitações pull têm papéis claramente definidos: há um autor e um(s) revisor(es).

Como exemplo, digamos que nosso engenheiro sênior Ingvild tenha feito uma mudança no fluxo de inscrição do Confrere. Antes de ser mesclado na base de código principal e ser enviado, ela (o autor) cria um pull request para solicitar uma revisão de nosso CTO Dag-Inge (o revisor). Ele não fará nenhuma alteração no código dela, apenas adicionará seus comentários.

Cabe a Ingvild como ela quer agir sobre o feedback que recebeu na revisão. Ela atualizará sua solicitação de recebimento com as alterações que achar adequadas.

Quando o(s) revisor(es) aprovarem a solicitação pull, Ingvild poderá mesclar suas alterações com a base de código principal.

Por que se incomodar em fazer revisão de código?

Se você nunca fez revisão de código, o processo acima pode parecer burocrático. Se você tiver dúvidas, aqui está uma tonelada de postagens de blog e pesquisas acadêmicas sobre as vantagens da revisão de código.

As revisões de código definem o tom para toda a empresa de que tudo o que fazemos deve estar aberto ao escrutínio de outras pessoas e que esse escrutínio deve ser uma parte bem-vinda do seu fluxo de trabalho, em vez de ser visto como ameaçador.

— Bruce Johnson, cofundador da Full Story

A revisão do código reduz o risco. Ter alguém revisando seu trabalho e também saber que alguém revisará seu trabalho ajuda a eliminar erros e aumenta a qualidade. Além disso, garante consistência e ajuda cada membro da equipe a se familiarizar mais com a base de código.

Quando bem feita, a revisão de código também cria uma cultura de colaboração e abertura. Tentar entender e criticar o trabalho de outras pessoas é uma excelente maneira de aprender, assim como obter feedback honesto sobre seu trabalho.

Sempre ter pelo menos duas pessoas examinando o código também reduz as ideias de “meu” código e “seu” código. É o nosso código.

Considerando essas vantagens, uma revisão não deve ser apenas para código.

Revise os princípios para todas as disciplinas, não apenas o código

Com revisões, há sempre um autor e um ou mais revisores. Isso significa que você pode envolver as pessoas desde o início sem cair no projeto por comitê.

Primeiro, devo mencionar dois fatores importantes que afetarão a capacidade de sua equipe de fazer avaliações benéficas. Você não precisa necessariamente dominá-los, mas, no mínimo, deve aspirar ao seguinte:

• Você e seus colegas respeitam uns aos outros e as disciplinas uns dos outros.
• Você é suficientemente autoconfiante em seu próprio papel para sentir que pode tanto dar quanto receber críticas (isso também está ligado à segurança psicológica da equipe).

Mesmo que não estejamos revisando o código, há muito o que aprender com as práticas recomendadas existentes para revisões de código.

Dentro de nossa equipe, tentamos seguir os seguintes princípios ao fazer avaliações:

1. Critique a obra, não o autor.
2. Seja crítico, mas permaneça afável e curioso.
3. Diferenciar entre a) Sugestões b) Requisitos, c) Pontos que necessitam de discussão ou esclarecimento.
4. Mova as discussões de texto para cara a cara. (contagens de vídeo)
5. Não se esqueça de elogiar as partes boas! O que é inteligente, criativo, sólido, original, engraçado, legal e assim por diante?

Esses princípios não foram realmente escritos até depois de discutirmos por que nossa colaboração estava funcionando tão bem. Todos nós sentíamos que já podíamos fazer perguntas e sugerir melhorias, e que nossas motivações eram sempre construir algo grande juntos, e não criticar outra pessoa.

Como estávamos sendo claros sobre o tipo de feedback que estávamos dando e também nos lembrando de elogiar o bom trabalho um do outro, fazer avaliações era uma força positiva e não desmotivadora.

Um exemplo

Para dar uma ideia de como nossa equipe usa a revisão em todas as disciplinas e ao longo de um processo, vamos ver como os diferentes membros de nossa equipe alternaram entre os papéis de autor e revisor quando criamos nosso fluxo de inscrição.

Etapa 1: levantamento de requisitos

Autor: Ida (UX)

Revisores: Svein (estratégia), Dag-Inge (engenharia), Ingvild (engenharia).

As sessões de quadro branco podem ser exaustivas se não houver estrutura para elas. Para manter a produtividade e a criatividade, usamos a estrutura autor/revisor, mesmo para algo aparentemente tão básico quanto brainstorming em um quadro branco. Nesse caso, em que estávamos criando os requisitos para nosso fluxo de inscrição, eu fui o autor, e o restante da equipe deu seu feedback e atuou como revisor. Como eles também sabiam que poderiam revisar o que eu criei na etapa 2 (muito mais oportunidades para ajustes, sugestões e melhorias), trabalhamos rapidamente e conseguimos concordar com os requisitos em menos de 2 horas.

Passo 2: Maquete com microcópia

Autor: Ida (UX)

Revisores: Ingvild (engenharia), Eivind (design), Svein (estratégia).

Como autor, criei uma maquete do fluxo de inscrição com microcópia. O fluxo de inscrição fez sentido, tanto do ponto de vista do usuário quanto da engenharia? E como poderíamos melhorar o fluxo de uma perspectiva de design e front-end? Nessa fase, era fundamental trabalhar em um formato em que fosse fácil para todas as disciplinas darem feedback (optamos pelo Google Docs, mas também poderia ter sido feito com uma ferramenta como o InvisionApp).

Etapa 3: implementar o fluxo de inscrição

Autor: Ingvild (engenharia)

Revisor: Ida (UX) e Dag-Inge (engenharia).

Tínhamos concordado com o fluxo, os campos de entrada e a microcópia e, portanto, cabia a Ingvild implementá-lo. Graças ao Surge, podemos criar automaticamente URLs de visualização das alterações para que as pessoas que não conseguem ler o código também possam dar feedback nesta fase.

Etapa 4: teste do usuário

Autor: Ida (UX)

Revisor: Os usuários.

Sim, consideramos o teste do usuário uma forma de revisão. Trouxemos nosso fluxo de inscrição recém-criado cara a cara com usuários reais. Essa etapa nos deu uma tonelada de insights, e as mudanças mais significativas em nosso fluxo de inscrição vieram como resultado.

Etapa 5: projetar

Autor: Eivind (design)

Revisores: Ingvild (engenharia) e Ida (UX).

Quando o design aparece de repente aqui na etapa 5, pode parecer muito com um processo em cascata. No entanto, nosso designer Eivind já estava envolvido como revisor desde a etapa 2. Ele deu vários comentários úteis nessa fase e também pôde começar a pensar em como poderíamos melhorar o design do fluxo de inscrição além dos módulos existentes em nosso sistema de design. Nesta etapa, o Eivind também pode ajudar a resolver alguns dos problemas que identificamos nos testes do usuário.

Etapa 6: Implementação

Autor: Ingvild (engenharia)

Revisor: Eivind (design), Ida (UX) e Dag-Inge (engenharia).

E então voltamos à implementação.

Por que a revisão funciona

Em resumo, há sempre apenas um autor, evitando assim o design por comitê. Ao envolver uma série de disciplinas como revisores desde o início, evitamos ter um processo em cascata.

As pessoas podem sinalizar suas preocupações com antecedência e também começar a pensar em como podem contribuir mais tarde. Os papéis claramente definidos mantêm o processo nos trilhos.

Passo a passo de revisão regular

Inspirando-se nas orientações de código, também fazemos orientações de revisão regulares com diferentes focos, guiadas pelos seguintes princípios:

• O passo a passo é feito em conjunto.
• Uma pessoa é responsável pela revisão e documentação.
• A ideia é identificar problemas , não necessariamente resolvê-los.
• Escolha um formato que forneça o máximo de contexto possível, para que seja fácil agir de acordo com as descobertas posteriormente (por exemplo, InvisionApp para revisões visuais, Google Docs para texto e assim por diante).

Fizemos revisões passo a passo para coisas como auditorias de acessibilidade, revisão de solicitações de recursos, auditoria da implementação do design e avaliações de usabilidade heurísticas.

Quando fazemos nossas revisões trimestrais de acessibilidade, nosso consultor de acessibilidade Joakim primeiro analisa a interface e os documentos e prioriza os problemas encontrados em uma Planilha Google compartilhada. Joakim, então, nos orienta sobre as questões mais importantes que ele identificou.

Reunir-se pessoalmente (ou pelo menos em vídeo) para analisar os problemas ajuda a criar um ambiente de aprendizado, em vez de uma sensação de ser supervisionado ou microgerenciado.

Se você está sempre preso a algo que deve ser lançado ou corrigindo o que está na parte superior da sua caixa de entrada, as revisões podem ajudar a remediar isso. Se você reservar meio dia regular para revisar o trabalho que já fez, poderá identificar problemas antes que eles se tornem urgentes. Também pode ajudá-lo a reorientar e garantir que suas prioridades estejam seguindo as linhas certas. Talvez sua equipe não deva começar a criar esse novo recurso antes de você ter certeza de que os recursos existentes estão de acordo com seus padrões.

O teste do usuário é uma forma de revisão

Uma motivação importante para revisões de código é reduzir o risco. Ao fazer isso toda vez que você introduz uma mudança ou adiciona algo novo ao seu produto, e não apenas quando você suspeita que algo não está à altura, você diminui a chance de enviar bugs ou recursos abaixo da média. Acredito que devemos olhar para o teste de usuário da mesma perspectiva.

Veja bem, se você deseja reduzir o risco de envio com grandes problemas de usabilidade, o teste do usuário deve fazer parte do seu processo. Apenas ter seus designers de UX revisando a interface não é suficiente. Vários estudos descobriram que mesmo os especialistas em usabilidade falham em identificar todos os problemas reais de usabilidade. Em média, 1 em cada 3 problemas identificados pelos especialistas eram alarmes falsos — na prática, não eram problemas para os usuários. Mas pior, 1 em cada 2 problemas que os usuários de fato tiveram, foram ignorados pelos especialistas.

Ignorar o teste do usuário é um risco tão grande quanto pular a revisão do código.

A revisão significa a morte para a criatividade?

As pessoas que trabalham com design, experiência do usuário e conteúdo geralmente têm formação educacional de escolas de arte ou talvez literatura, nas quais o único criador ou gênio artístico criativo é saudado como o ideal. Se você voltar na história, esse costumava ser o caso dos desenvolvedores também. Com o tempo, isso mudou por necessidade, à medida que o desenvolvimento da Web se tornou mais complexo.

Se você se apegar à ideia de criatividade vindo de algum lugar profundo dentro de você, a ideia de revisão pode parecer ameaçadora ou assustadora. Alguém se intrometendo em seu trabalho inacabado? Ai. Mas se você pensar na criatividade como algo que pode surgir de muitas fontes, incluindo diálogo, colaboração ou qualquer forma de inspiração (de fora ou de algum lugar dentro de você), uma revisão é apenas um ativo e uma oportunidade.

Enquanto estivermos construindo algo para a web, não há como colaborar com outras pessoas, seja dentro do nosso próprio campo ou de outros. E uma boa ideia sobreviverá à revisão.

Vamos criar algo grande juntos.