Se você é um designer ou desenvolvedor, conhece muito bem essa história: os designers criam um belo protótipo ou conjunto de wireframes e os ‘jogam por cima do muro’ para os desenvolvedores. Como os desenvolvedores descobrem que partes dos projetos exigem muito trabalho ou são impossíveis de implementar, os projetos originais evoluem lentamente durante cada sprint.
O que começa quando o Tesla de projetos se transforma em um Subaru prático, com todos os recursos de segurança e sem frescuras … ou acaba parecendo uma scooter de ferro-velho sem rodas.
Os designers começam a murmurar algo sobre pixels e preenchimento, os desenvolvedores enviam mensagens Slack passivo-agressivas e os encontros para tomar café tornam-se gelados.
Por que todos nós não podemos simplesmente nos dar bem?
A inclusão de desenvolvedores no processo de design e de designers no processo de desenvolvimento pode ajudá-lo a desenvolver um fluxo de trabalho e resultados muito melhores, combinando seus diferentes conhecimentos e perspectivas. Realmente faz sentido ter essa divisão entre duas equipes construindo o mesmo produto?
No final, se você olhar mais profundamente, a verdadeira fonte de conflito vem de dois fatores:
- O sistema (ou a falta dele) no qual as duas equipes trabalham juntas
- Dinâmica da equipe e ambiente
O problema é que, quando você pesquisa na Internet as melhores práticas sobre como ajudar essas equipes a trabalharem melhor em conjunto, geralmente se depara com princípios extremamente vagos e de “autoajuda”: comunicar, colaborar e co-criar.
Durante a Sprint Couch Series da TNW, Trish Lamanna e Designer de Soluções Líder da Rangle.io, Omer Wazir, compartilharam como eles criaram sua própria abordagem integrada ao ‘Dev-ignOps’, permitindo que eles se tornem mais multifuncionais e auto-organizados e aumente a velocidade deles.
Aqui, compartilharemos como eles transformaram os três Cs em etapas práticas que eles poderiam operacionalizar no Rangle, além de conselhos sobre como criar o ambiente certo para operações multifuncionais bem-sucedidas.
1. Desenvolver um modelo de comunicação comum
De acordo com a equipe do Rangle, a comunicação não é sobre as ferramentas que você escolhe, é sobre o modelo que você usa para abordar problemas, tomar decisões e compartilhar informações. É importante escolher e desenvolver conscientemente um modelo de comunicação que funcione bem com o tamanho da sua equipe e os resultados que você deseja alcançar.
Lamanna explicou que, se as equipes não tiverem um modelo operacional definido, elas serão automaticamente padronizadas para um sistema em cascata no qual os designers criam o conceito de design, entregam aos desenvolvedores e passam para o próximo projeto. Ao mesmo tempo, não deixa espaço para loops e iterações de feedback multifuncional. Em grandes equipes com mais de 20 pessoas focadas em projetos complexos e trabalhosos, uma abordagem em camadas é muito mais prática.
Enquanto isso, equipes menores, com menos de cinco pessoas, tendem a usar uma abordagem abrangente para a solução de problemas, na qual todos se reúnem para debater, compartilhar feedback e tomar decisões. Não há hierarquias e a opinião de todos é ouvida, levando a soluções multifuncionais. Você verá isso normalmente em equipes de marketing menores trabalhando em melhorias de conteúdo para um CMS existente.
Mas e se você quiser o melhor dos dois mundos?
Em Rangle, Lamanna e Wazir foram encarregados de criar um aplicativo que se conectasse a um dispositivo médico com uma equipe de tamanho médio de 14 pessoas. Eles perceberam que uma abordagem puramente cheia ou em camadas não funcionaria para eles.
Em vez disso, eles decidiram criar uma abordagem de solução de problemas semi-enxame. Isso significava que, entre os fluxos de artefatos, eles se agrupavam para identificar possíveis problemas e criar um plano de ataque. Em seguida, eles se separavam para resolver esses problemas em uma estrutura baseada em camadas.
2. Estabelecer rituais de colaboração
Para operacionalizar seu modelo de comunicação, é necessário definir ‘rituais’ ou pontos de contato específicos, durante os quais suas equipes ou jogadores-chave se reúnem para colaborar. Isso pode estar na forma de:
- Revisões semanais da reunião da equipe interna
- Verificações intestinais do proprietário do produto
- Cerimônias e demonstrações
- Design para fluxos de tickets de desenvolvimento no Jira
Ao estabelecer rituais, a equipe do Rangle pôde incluir designers, desenvolvedores e proprietários de produtos no processo de solução, identificar problemas e oportunidades em potencial para funcionalidades adicionais logo no início e discutir como eles resolveriam outras dependências na linha.
Por exemplo, ao desenvolver um aplicativo médico para um cliente da UE, eles perceberam que precisariam considerar como a privacidade e os regulamentos GDPR já podiam ser integrados ao design e à codificação. Isso lhes permitiu chegar a um plano comum e coordenado com antecedência, sem ter que fazer alterações de última hora e demoradas em ambos os lados.
3. Crie um plano para facilitar a co-criação
Por fim, a cocriação tem como objetivo levar seu modelo de comunicação e rituais de colaboração e reuni-los em um plano comum de fluxo de trabalho.
Para criar um plano eficaz, é necessário considerar as questões práticas que podem dificultar ou facilitar a cocriação entre as duas equipes.
Algumas das questões consideradas por Rangle foram:
- Quais informações o design precisa compartilhar com o desenvolvimento para permitir que eles antecipem o que está por vir amanhã?
- O que pode ser feito em paralelo?
- Como a melhoria contínua acontece ao longo do tempo?
No final, o plano de co-criação de Rangle consistia em sprints em camadas semanais. O processo de design estava sempre uma semana à frente, dando aos desenvolvedores tempo para compartilhar feedback e preocupações antes que o design entregasse o próximo conjunto de componentes a eles. Dessa forma, os desenvolvedores já podiam antecipar o trabalho que viria durante o próximo sprint e as melhorias poderiam ser feitas continuamente ao longo do processo de design e desenvolvimento.
Criar um sistema inclusivo e integrado é ótimo, mas, como Lamanna mencionou, você também precisa se concentrar na criação das condições e comportamentos corretos para que ele realmente funcione.
4. Construa segurança psicológica
Criar um ambiente psicologicamente seguro é fundamental.
Segurança psicológica é a crença de que você pode compartilhar suas idéias, preocupações, opiniões e erros sem o medo de ser humilhado ou punido. Em um estudo , o Google descobriu que era o fator mais importante necessário ao criar equipes altamente eficazes.
Mesmo se você configurar vários ciclos de feedback e ciclos de revisão de design / código, eles não serão eficazes se as pessoas não sentirem que podem realmente falar livremente.
Em um TedTalk , a professora de Harvard Amy Edmonson (que cunhou o termo) compartilhou três maneiras de desenvolver um ambiente de trabalho psicologicamente seguro:
- Enquadre o trabalho como um problema de aprendizado
- Reconheça sua própria falibilidade
- Curiosidade do modelo
5. Torne seu trabalho transparente
Certifique-se de que ambas as equipes compartilhem um espaço comum onde possam ver o que os outros estão trabalhando entre rituais de colaboração.
Isso não precisa necessariamente vir de uma ferramenta de colaboração. Simplesmente imprimir desenhos e storyboards e colocá-los na parede de seu escritório, onde os desenvolvedores (ou qualquer pessoa da empresa) podem passear casualmente e ver os últimos designs durante uma pausa para o café podem realmente fazer uma enorme diferença.
No Rangle, Lamanna e Wazir compartilharam que todas as discussões do projeto, seja no Slack, Jira ou GitHub, aconteceram em canais públicos, para que as pessoas não fiquem de fora do circuito. Isso é especialmente importante agora, com a maioria das equipes trabalhando remotamente.
6. Desenvolver uma linguagem comum
Em um episódio da série Youtube do Designer vs Developer, do Google, o designer sênior de interação, Brendan Kearns, explicou que o redirecionamento geralmente acontece quando designers e desenvolvedores estão falando um idioma diferente.
Agora, mais e mais empresas estão criando sistemas de design, ou bibliotecas de designs e códigos, que podem ser facilmente reutilizados para diferentes projetos. O Airbnb chama sua versão de linguagem visual que permite criar produtos mais rapidamente e garantir consistência em toda a organização. Curiosamente, há alguns anos, a empresa também começou a trabalhar em uma ferramenta de IA que gera automaticamente esboços no código-fonte do produto.
Embora demore muito tempo, iniciar seu próprio ecossistema de biblioteca de projetos / desenvolvedores compartilhado, que pode ser desenvolvido continuamente ao longo do tempo, poupará muito tempo no futuro.
Confira esta interessante conversa do web designer Brad Frost para saber mais sobre o lado técnico dos sistemas de design.
7. Incentive o compartilhamento de conhecimento
É essencial compreender e respeitar a origem de cada lado. É surpreendentemente raro encontrar os unicórnios designer-desenvolvedor que sabem como criar uma estrutura de arame e codificá-la, mas é claro que, se você tiver sorte o suficiente para tê-los em sua equipe, eles geralmente preenchem a lacuna identificando possíveis problemas à frente tempo e conflitos mediadores.
Oferecer oportunidades de aprendizado e compartilhamento de conhecimento pode ajudar bastante a preencher a lacuna entre essas equipes. Quanto mais designers entenderem a codificação que precisa acontecer nos bastidores para criar seus designs, e mais desenvolvedores entenderão a importância de criar jornadas contínuas para o usuário, melhor.
Começando
Cada equipe, empresa e problema é diferente; portanto, você precisará testar, revisar e otimizar até encontrar o sistema que funciona melhor para você.
Como ponto de partida, Lamanna e Wazir sugerem primeiro considerar os resultados que você deseja alcançar e trabalhar a partir daí. Deseja tornar os prazos de entrega mais previsíveis? Fechar bilhetes mais rápido? Criar equipes auto-organizadas? Em seguida, crie um sistema que ajudará suas equipes a chegar lá.
