Designer no time ágil: adaptação e novas práticas
Ser designer em um time ágil nem sempre é fácil devido à diversidade das tarefas que exercemos e ao fato de que a maioria das práticas foi elaborada para desenvolvedores. Por este motivo, decidi compartilhar a experiência que tive ao trabalhar com um time que não possuía processos para designers.
Não vou descrever o que é certo ou errado — até porque estou bem longe de ser especialista no desenvolvimento ágil –, mas compartilharei como algumas práticas e conversas diárias com colegas do time ajudaram nesta fase de adaptação dentro de uma nova squad.
Prazer, pode me chamar de designer! =)
É comum designers entrarem em um time no meio de uma necessidade urgente de melhoria. Somos chamados, a princípio, porque é necessária alguma mudança pra gerar valor naquele momento. Foi neste cenário que entrei e não era possível construir um processo desde o início que contemplava as tarefas e cerimônias de Design.
Nos primeiros dias foi uma correria: entendimento do produto, pesquisa, serviços disponíveis, wireframe, refinamento, testes com usuários, etc. A demanda é extensa e exige muita dedicação e horas de uma pessoa ou duas — no caso de um Product Designer ou uma dupla de UX e UI.
Apesar deste momento atribulado, algo importante que aprendi é a necessidade de se apresentar para os integrantes do time. Conversas com os colegas podem ajudar nesta etapa. As pessoas podem não saber exatamente o que fazemos, por isso é preciso estar aberto para o diálogo, descrever e exemplificar o que faz parte do nosso escopo de trabalho.
Dentro do contexto que vivi e em experiências trocadas com outros designers, acredito que uma maneira de se apresentar e falar sobre o nosso trabalho é montar uma apresentação para o time.
Nesta apresentação, tente ser didático: mostre os processos, cerimônias do time de Design, o escopo do trabalho (o que faz e o que não faz) e fale um pouco sobre você também. Desta forma, todos poderão ter uma visão geral de quem é você e da sua atuação dentro da equipe.
Daily para todos
A Daily é uma cerimônia importante para um time ágil. Nela é compartilhado o que foi feito no dia anterior, impedimentos são levantados, o trabalho do dia é priorizado e todos tem visibilidade das demandas.
Apesar desta importância, nem sempre os designers participam das Dailys. Isto ocorre por diversos motivos e cito alguns que já vivenciei: o time pode acreditar que é um espaço para desenvolvimento da engenharia e o designer faz parte apenas da concepção do produto, ocorrer incompatibilidade de agenda entre as cerimônias específicas da área de Design e a Daily do time, ou, até mesmo, designers não verem importância em participar.
Vou defender a importância de participarmos das Dailys, porque é neste encontro diário que conseguimos dar visibilidade para o desenvolvimento das nossas demandas, apontar prováveis impedimentos, mostrar quando estamos na parte de pesquisas ou testes, perceber quando o Desenvolvedor Front-end vai terminar uma estória e terá que puxar outra que tem dependência de Design, quando o Desenvolvedor Back-end poderá puxar o desenvolvimento de um serviço para o fluxo, etc.
É durante a Daily que se alinha o desenvolvimento diário da equipe e a sua realização deve ser em um horário e local em que todos possam participar. Designers fazem parte deste processo e participar é importante para melhorar a sintonia e performance do time. Por isso, peça um espacinho para as tarefas de Design no board (quadro de controle de atividades) e participe sempre que possível.
Um espaço no board para chamar de seu
O Design no board é um assunto complexo. Alguns designers nem mesmo têm um espaço para suas tarefas nos boards de seus times, trabalhando, às vezes, somente com alinhamentos verbais com os POs (Product Owners — responsáveis pelo produto).
Mesmo quando Design está inserido no board, já vi formatos bem diferentes uns dos outros. Alguns estão no Upstream (etapas para amadurecimento e validação de ideias), outros em um board apartado só para Design ou, até mesmo, em um board unificado para toda squad.
O que pude observar onde atuei, e em conversa com colegas, é que não existe uma fórmula para este assunto. Acredito que um bom caminho é trocar ideias e alinhar qual será o melhor formato para todo o time. O mais importante é ter este espaço no board que reflita as etapas diárias do desenvolvimento das tarefas de Design. Este espaço ajudará na definição de um backlog, no acompanhamento das estórias durante as Dailys, na visibilidade das demandas, na metrificação e definição de um WIP (Work in Progress — trabalho em andamento) e no alinhamento do desenvolvimento total do time.
Aponte a necessidade e importância de ter o seu espaço no board para o AM (Agile Master — facilitador do time ágil) da sua equipe. Desde o começo, tenha um tempo disponível para conversar e interagir com a pessoa que faz a gestão ágil e, assim, descobrir a melhor maneira de participar de todas as práticas e processos do seu time.
Quem é próximo não é esquecido ;)
Métodos ágeis incentivam a comunicação em tempo real e o compartilhamento de informações constante entre integrantes do time. Quanto maior for a troca de conhecimento, melhor entenderemos sobre o produto e a equipe poderá contemplar a experiência do usuário no desenvolvimento de novas funcionalidades.
Pode ser um pouco difícil e demorado para um designer que inicia na squad se adaptar. Isto pode ocorrer pela natureza das nossas demandas — diferentes do restante do time –, porque as pessoas já estão acostumadas a atuar de uma maneira e entramos com trabalho e pensamento diferente, ou simplesmente porque somos novos e existe um tempo de adaptação para todos. Independentemente do motivo, sou favorável a uma proximidade entre todos os integrantes.
No começo, interagimos muito com o AM para encontrar nosso lugar, explicar nossas necessidades, práticas diárias e construir juntos uma boa interação com o time. O PO também pode ser um parceiro na hora de defender sua atuação. Muitos destes profissionais gostam de trabalhar com designers, exercitando a visão do usuário para o produto. Trabalhar de uma maneira harmoniosa e conjunta com o PO me auxiliou no entendimento do produto, na visão de negócios e na defesa da importância da experiência do usuário para outras gerências.
Outro ponto que fico sempre atenta é manter um canal aberto de conversa com todos. A troca de conteúdo com os Desenvolvedores Front-ends pode ser bem intensa durante o desenvolvimento das telas. Deixo claro que podem sempre me procurar para tirar dúvidas. Esta interação constante diminui a quantidade de erros nas Reviews.
Também me esforço para manter esse canal de comunicação com QAs (Quality Assurance — análise de qualidade) e Desenvolvedores Back-ends. Apesar de interagir um pouco menos com estes profissionais, ainda temos assuntos para alinhar e conhecimento para partilhar. Os QAs são responsáveis pela verificação de todo fluxo antes de ir para produção. Após as Reviews alinhamos os ajustes e validamos novamente marcando outra reunião, ou pelo canal de comunicação da squad. Por fim, esta proximidade com os Desenvolvedores Back-ends é necessária para entendermos sobre os serviços disponíveis, os que serão implementados, extrair dados de bancos pra construir uma análise quantitativa da experiência do usuário.
A presença e a comunicação — seja local, ou pelos canais remotos — são atividades valiosas para o time e para o produto e, por isto, exerço estas dentro das equipes que atuo. Inclusive participo de almoços, cafés e happy hours. Esta troca, fora da empresa, também ajuda no team building (construção do senso de equipe) e, às vezes, constrói amizades.
Cerimônias importam
Quem atua com design em um time ágil, comumente está pelo menos uma Sprint (etapas ou ciclo de desenvolvimento do projeto) à frente dos desenvolvedores. Apesar desta diferença de tempo, faço questão de participar das cerimônias para entender do desenvolvimento e colaborar com as estórias que concretizei.
Antes mesmo das cerimônias do Ágil, puxo alguns processos do Design Thinking para o time, no intuito de entender a viabilidade do que executei e agregar conhecimento dos desenvolvedores ao produto. Assim que termino o wireframe, marco um refinamento com a equipe para apresentar o fluxo e esboços das telas. Este encontro também serve para alinhar se é possível utilizar ou construir componentes do Design System e serviços de back-end.
Tão importante quanto alinhar bem o que será feito, é poder rever o que subirá em produção. A Review é este evento onde todos se reúnem para poder olhar o trabalho final que foi desenvolvido. Nesta cerimônia faço questão de estar presente, porque posso enxergar detalhes que podem passar despercebidos pelos outros integrantes. Inclusive, já recebi feedbacks de que a minha presença agregou muito para o time e produto. Acho este momento tão importante que se a squad não tem costume de fazer Reviews, acredito que designers devem puxar esta reunião, para ter melhor controle de que a entrega será disponibilizada no formato correto para o usuário.
Para finalizar, temos a Retrospectiva ao término da Sprint. Confesso que já me senti um pouco deslocada nesta cerimônia para a adaptação de processos de desenvolvimento do time. Acredito que isto ocorreu porque o foco maior costuma estar no trabalho dos desenvolvedores. Eles são a maioria e falam do que vivenciaram, porém, com o passar do tempo, fui me sentindo mais à vontade e ganhando confiança para expor as necessidades e sucesso do Design. Inclusive foi na Retro que recebi o feedback de que minha presença era importante na Review e que pude apontar a necessidade de processos para Design.
Cerimônias são eventos importantes para times ágeis. Participar traz um alinhamento melhor, permite a adaptação dos processos e ajuda no entendimento total de onde estamos atuando. Tento participar sempre, aprendo muito durante estas práticas e posso compartilhar com todos a experiência do usuário.
Compartilhando conhecimento
Conhecimento é poder e quando partilhamos o que sabemos, empoderamos pessoas. Compartilhar com a equipe os trabalhos que realizo se tornou um grande objetivo nos últimos tempos. Apresentar resultados de pesquisas, dados gerados, testes realizados, ou qualquer informação relacionada à experiência do usuário, traz para dentro do time o ser humano. Nossos produtos são feitos para pessoas, então nada mais justo que suas necessidades sejam ouvidas.
Apresentar esses trabalhos pode ser difícil quando os desenvolvedores entendem que são relevantes somente paro o processo de Design. Nem sempre todos aparecem nas reuniões, mas, com o tempo, enxergam valor nesta troca de conteúdo e gostam de saber como o produto que desenvolvem é avaliado e utilizado pelos usuários.
Quando necessário, apresento os resultados para outras pessoas que não são do time, mas estão envolvidas com o produto, como coordenadores e gerentes das áreas relacionadas. Esta ação possibilita uma comunicação transparente com todos os envolvidos.
Durante estas apresentações, podemos partilhar conhecimento, aprender com a troca, levantar hipóteses e alcançar soluções que agregarão valor para o usuário e, consequentemente, para o produto.
Designers atuando na facilitação
Após o estágio de compartilhar todos os trabalhos realizados, vem o desafio da facilitação. Essa prática vai além da troca de conhecimento, incentiva os participantes a entenderem os problemas dos usuários e levantar soluções. Neste contexto, designers propõem uma nova mentalidade para o time, onde todos podem e devem pensar na experiência do usuário.
Dominar este papel de facilitadora é o grande desafio que encontro hoje em minha carreira. Sinto a necessidade de exercitar este cenário dentro do time, para conseguir um maior envolvimento de todos no levantamento de hipóteses, suposições e desenvolvimento contínuo para entregar valor ao nosso cliente final.
É uma mudança cultural para a equipe e também para nós designers. Temos que desenvolver novas habilidades, criar espaços colaborativos, abrir mão do controle total das ações da experiência do usuário e confiar que o processo contínuo de aprendizado vai gerar melhores resultados para o produto e para as pessoas que o utilizam.
Antes juntos do que só
“Nenhuma disciplina tem todas as respostas. Essa é a natureza do nosso meio digital. A colaboração cria um trabalho melhor. Revisão e interação tornam os produtos melhores.” – Jeff Gothelf e Josh Seiden, Lean UX: Designing Great Products with Agile Teams
Todas as ações que descrevi nos tópicos anteriores, e que me esforcei para aplicá-las na prática, são reflexo do que penso ser o melhor caminho para minha atuação dentro de um time ágil. Acredito que o trabalho colaborativo e aprendizado contínuo em equipe traz soluções melhores e gera valor para os usuários e produto.
Quando entrei na nova equipe e procurei por práticas de Design dentro do time ágil, não encontrei exemplos de quem aplicou no seu time. Percebi que este não é um assunto amplamente discutido por profissionais da área e geralmente quando apresentado está longe da realidade de muitas empresas.
Resolvi, então, compartilhar o aprendizado que vivenciei na prática e me ajudou na adaptação e interação com a equipe e seus processos. Espero que também possa ajudar mais designers em uma situação parecida e que levante algumas reflexões sobre nossa atuação e participação dentro de times ágeis.
Minha expectativa é que este relato abra mais um canal de comunicação, com o objetivo de compartilhar conhecimento e disseminar o aprendizado do Design dentro da metodologia Ágil. Fiquem à vontade para entrar em contato e trocarmos experiências, ou simplesmente conversarmos sobre o assunto.
