Seguindo com a série de posts-resposta, vou aproveitar mais um e-mail que recebi para falar de um assunto que é campeão em dúvidas e discussões: como trabalhar com os designers. A questão é a seguinte:
Gostaria de tirar uma dúvida (ou mesmo sugestão) sobre como vcs estão trabalhando ai na Globo.com com os designers, arquitetos de informação, etc, inseridos nos times ágeis.
A empresa onde trabalho tem um “setor” de criação artística muito forte, alias, excelentes profissionais, e eles trabalham independentes praticamente do desenvolvimento.
Devido a maneira da empresa gerir seus projetos – waterfall – eles fazem toda a parte de criação e entregam um wireframe+layout de telas prontos pras equipes de desenvolvimento, ai é cada um por si.
Como estamos fazendo um processo de migração de waterfall pra desenvolvimento ágil, esse ponto específico do pessoal de criação inseridos nas equipes ágeis ainda deixa muitas dúvidas, na maneira que eles podem fazer parte dos times.
Talvez esse tenha sido um dos maiores problemas que tivemos na adoção de Scrum aqui na Globo.com, ou pelo menos é um dos problemas que têm durado mais tempo. Novamente, não acho que exista uma receita de bolo, cada time ou empresa precisa encontrar a melhor forma de trabalhar. Vou me limitar a dar algumas idéias e falar do que temos tentado fazer aqui para integrar desenvolvimento e design.
Por último, vou falar especificamente de Scrum porque é o que usamos aqui (apesar de usarmos também práticas e conceitos de XP e Lean), mas as mesmas idéias servem para outros processos similares.
O ponto de vista do processo
Do ponto de vista do Scrum, o correto seria desenhar a cada história que fosse feita somente as partes da tela necessárias para a conclusão da história.
Fazer todo o design antes nos mínimos detalhes não é o mais indicado porque para isso é preciso fazer um levantamento de requisitos para entender as necessidades e é exatamente assim que funciona a fase de análise e levantamento de requisitos do waterfall (ou seja, o que não queremos fazer).
Outro problema é que se no início de um projeto você só trabalha telas, o que você irá entregar no fim de um Sprint? Com certeza não será software funcionando e toda aquela história de antecipação do ROI vai por água a baixo.
Por fim, um dos objetivos do desenvolvimento com Scrum é produzir software de maneira iterativa e incremental. A cada Sprint deveria ser entregue uma pequena parte do produto funcionando e quando isso é feito, o Product Owner pode chegar em qualquer ponto do projeto e perceber que o investimento em mais um Sprint já não vale mais a pena como valia no início – porque as histórias que sobraram darão um retorno bem menor do que o valor investido em um Sprint – e ele pode decidir que é necessário encerrar o projeto por razões econômicas óbvias e partir para outro.
O ponto de vista do desenvolvedor
Os princípios de desenvolvimento ágil também não deixam dúvidas. Big Design Up Front (BDUF) é coisa de cascateiro, e as práticas de desenvolvimento como Test-Driven Development (TDD) fomentam justamente o desenvolvimento incremental.
Do ponto de vista do desenvolvedor ágil também é um erro desenvolver todo o design antecipadamente.
O ponto de vista do designer
Só depois de muitas conversas com o Cainã Nunes e o André Braz – dois dos melhores “criativos” que temos aqui na Globo.com – é que eu consegui entender o problema de verdade. Eu não sou nem de perto um especialista no assunto (e nem pretendo ser), mas vou tentar explicar o pouco que eu entendo.
Para entendê-los, precisamos entender a diferença entre “design de interface” e “design de UX”.
Desenhar uma tela qualquer é muito fácil. No início da minha carreira quando eu trabalhava em uma agência de desenvolvimento de sites cansei de mudar e algumas vezes até fazer layouts. Depois que você aprende a usar direitinho o Photoshop e o Fireworks é realmente muito muito muito fácil desenhar uma tela, desenhar objetos diversos e entregar qualquer coisa. Não que todos os designers façam isso, mas que é fácil fazer uma tela qualquer é.
O problema é que aqui na Globo.com nós não queremos fazer somente telas. Além do design e beleza em sí, estamos preocupados com a experiência do usuário (a famosa UX). Ao contrário de desenhar uma simples tela, projetar a UX é muito muito muito difícil. Em UX, não basta ter uma tela, ela precisa ser fácil de usar, os usuários precisam querer usá-la e a experiência de uso tem que ser memorável – porque isso fará com que os usuários queiram voltar. Isso é tão difícil de fazer que muitas vezes falhamos, mas essa é a nossa mentalidade e como queremos desenvolver nossos produtos.
Quando falamos de projetar a UX, vários fatores além do Photoshop ou Fireworks estão envolvidos (veja o experience design manifesto para ter uma idéia). Aspectos como ergonomia, sentimento e psicologia entram em cena. Alguns projetos que fazemos são testados exaustivamente com usuários comuns no laboratório de usabilidade, e mesmo assim continua difícil de alcançar o resultado que queremos.
Pense friamente e veja como todas essas “loucuras” fazem muito sentido. Independente do processo que usamos, não é isso que queremos dar para os nossos usuários nos produtos que desenvolvemos?
O problema
O problema é que para projetar a experiência do usuário, os designers acreditam que é difícil (ou impossível) pensar em pequenas partes do site e que é preciso pensar na experiência como um todo. Isso vai totalmente de encontro com a forma que o processo funciona e que os desenvolvedores trabalham…
Para ser muito sincero, eu não entendia porque eles não gostavam da idéia de ir refatorando o design e ir adaptando conforme as partes fossem sendo desenvolvidas. O que eu sempre entendi é que indivíduos e interações devem estar acima do processo, então ao invés de ficar procurando respostas no processo precisamos confiar nessas pessoas – que são especialistas no que fazem – e junto com elas encontrar uma saída.
Isso não nos exime da responsabilidade de fazê-los entender claramente como funcionam os processos e princípios de desenvolvimento ágil para que eles saibam o impacto das suas decisões e ajudem a encontrar uma forma de trabalhar que seja compatível com essa realidade.
Harmonia entre desenvolvimento e criação
Depois de muitas tentativas e erros, a forma de trabalhar mais próxima do ideal que eu consigo enxergar é uma mistura dessas três visões.
Os projetistas de UX podem e devem sempre pensar na visão do todo mas não necessariamente precisam entrar em todos os detalhes de cada uma das telas. Com a visão inicial do projeto os designers já têm muitas informações que precisam para começar a trabalhar na experiência do usuário e devem desde já pensar no produto como um todo, mas mais uma vez, isso não quer dizer que tudo precisa ser feito e pensado nos mínimos detalhes antes do projeto. Abaixo ao BDUF!
Na nossa equipe os designers têm feito sketches, wireframes e desenhos à mão para discutir funcionalidades e usabilidade. Muitas vezes isso é feito durante as discussões do Sprint planning e re-pensado algumas vezes durante o Sprint. Depois, durante o desenvolvimento, a cada história que vai sendo desenvolvida o time vai implementando junto com os designers, que vão fazendo as pequenas partes necessárias para aquela funcionalidade específica e ao mesmo tempo o design da experiência como um todo é continuamente revisto e refatorado para atender à visão do projeto.
A idéia é mais ou menos como a do cone da incerteza: no início do projeto você têm uma vaga idéia de como será na prática a experiência do usuário, e essa certeza vai continuamente aumentando até que depois de algum tempo (mais próximo do fim) você tem certeza absoluta de como ela será.
Ainda não estamos craques em fazer isso mas promete funcionar bem melhor do que tudo que já tentamos.
Concluindo
Você é realmente ágil quando não existe algum processo burocrático que te impede de fazer alguma coisa com mais eficiência. Criar um processo ou ambiente que impeça as pessoas de trabalhar ao invés de facilitá-las vai totalmente de encontro à agilidade.
Para citar um exemplo, o próprio criador do Scrum – Jeff Sutherland – achou melhor adaptar o processo na sua empresa para fazer o design das telas antes do desenvolvimento. Nessa empresa os sistemas são feitos para serem usados por médicos e eles vêem o sistema como algo que dificulta o trabalho (torna menos ágil), portanto, a usabilidade do software tem que ser perfeita. Sendo o design tão crítico e tão importante para o sucesso do projeto, eles decidiram se organizar para trabalhar com definição de telas e criação de protótipos antes do desenvolvimento. E não adianta achar que todos os projetos devem ser assim; cada caso é um caso!
As pessoas precisam conversar mais e entender as motivações das outras e o que as levam à tomada de decisão. Quando você consegue entender de verdade o lado do outro (dos designers no meu caso) você começa a entender quais são as reais motivações para o que ele está fazendo. O designer no meu time não queria atrapalhar o processo fazendo todas as telas antes, ele simplesmente queria fazer um trabalho espetacular de usabilidade e essa era a melhor forma que ele conhecia. Fazer um trabalho excelente de UX foi exatamente o que o gerente de UX pediu para ele e é essa a direção que a empresa quer seguir. Só depois que eu me dispus a entender como funciona a cabeça dele (e de todos os outros de UX) é que eu estou conseguindo pensar de outra forma. Agora existem muito mais chances que a adaptação que estamos fazendo no processo funcione melhor.
Então, respondendo a pergunta do post: como trabalhar com os designers? Pense fora da caixa! Aqui estão algumas idéias e opiniões, mas que eu aconselho é que cada time experimente e encontre a sua resposta.
Se você ficou decepcionado com a resposta e achava que eu ia te dar uma regra para ser seguida sem precisar pensar, talvez você esteja procurando nas metodologias ágeis a resposta errada e precise de alguma outra coisa que dê isso para você.