Escrito por: Diego Curumim, Rafael Marujo, Luana Conde
Introdução
Construir um time do zero nunca é uma tarefa fácil, são muitos detalhes envolvidos, dinâmica do mercado, prioridades, afinidade, confiança, saúde física e mental, construção de processos e muita mão na massa, principalmente mão na massa. Sair de um time cross e ser alocado em uma squad, não é algo que seja do dia para a noite. Criar processos para essa mudança de escopo é essencial para o sucesso do time e da empresa.
Entender as vantagens e desafios de cada modelo pode te ajudar a construir um time sólido e estruturado mas com alta adaptabilidade, autonomia e com qualidade nas entregas.
Vamos lá?
Pontapé inicial
Quando se é a única pessoa atuando como UX em uma empresa, criar uma rotina é importante para o planejamento, para que os processos fiquem bem definidos e possam nos ajudar no futuro. Mas não se engane, amadurecer essa rotina e criar uma base sólida leva tempo, ainda mais com o dia a dia sendo tocado em paralelo.
Foram por volta de alguns meses atuando sozinho até colocar a casa em ordem, criando um planejamento, um backlog e organizando a base dos arquivos para então começar a procurar quem seria a próxima peça do time.
Você pode utilizar uma escala de divisão do seu tempo, por exemplo:
60% para entregas do dia a dia e 40% para planejamento. Claro que cada um irá dividir seu tempo da melhor maneira possível, mas é importante ter essa divisão para que os objetivos sejam alcançados.
Formando um time
Pronto, agora a casa estava arrumada. Estava no momento de dar um passo a mais. Nesse ponto, é essencial ter uma visão de que tipo de time e profissionais seriam ideais para atuar ao seu lado, afinal a maior parte do seu dia você trabalhará com eles. Focar em skills é importante, mas ter pessoas que mantém o ambiente leve é imprescindível. Com a chegada do segundo designer, o caminho para a maturidade do time estava avançando, mas continuávamos servindo squads e produtos de uma forma geral.
O primeiro processo de um novo integrante do time é um onboarding, feito com calma para que a pessoa possa ter tempo para entender o produto, como funcionam as cerimônias e ter visão geral dos arquivos e ferramentas (documentação, organização, criação e outros) tudo isso com liberdade para comunicação.
Foram mais alguns meses aperfeiçoando as entregas, melhorando a comunicação, criando e amadurecendo processos. Com o aumento das demandas, a necessidade de uma terceira pessoa já era uma realidade. Foi então que alguns meses depois a terceira peça do time chegou.
Com isso, o time se tornou enxuto, extremamente capaz e não havia mais necessidade de expansão, mas sim, aprimorar a qualidade da organização dos entregáveis e da construção dos nossos processos.
Bem, nem tudo é perfeito e todo time, independente do tamanho, precisa estar em constante adaptação, e apesar da rotina criada, backlog definido e processos sendo construídos, os desafios de ser um time cross ainda eram muitos.
Vantagens de ser um time cross
Ser um time cross tem suas vantagens e pode funcionar bem se for em empresas com poucos colaboradores ou poucas squads.
Podemos citar algumas vantagens como:
- Autonomia e liberdade para seguir processos e métodos definidos pelo próprio time;
- Definição do calendário de entregas de acordo com as prioridades negociadas;
- Priorização de backlog com stakeholders envolvidos;
- Proximidade entre os designers e desenvolvedores.
Com isso conseguimos ter mais agilidade nas entregas, já que todos os integrantes do time atuavam dentro da mesma atividade.
E os desafios de ser um time cross?
A curto prazo, o modelo cross funciona bem na formação de um time, o que vinha a calhar, já que o nosso estava engatinhando. Mas com o time e a quantidade de demandas aumentando, também ficou cada vez mais difícil de controlar os processos, acarretando alguns desafios como:
- Negociação diretamente com stakeholders, não somente com P.O;
- Alta rotatividade das priorizações;
- Mais atividades no backlog do que poderíamos entregar;
- Comunicação mais madura entre UX/Negócio;
- Falta de cerimônias;
- Capacity quase sempre no limite;
- Entregas não escaláveis;
- Pedidos de demandas top down;
- Comunicação do time extremamente alinhada;
- Redução do capacity do UX ponto focal;
- Vício de atuação do cross;
- Dificuldade na homologação;
- Outros.
Já utilizar alguns processos do modelo ágil, mesmo que de forma mais simples, também contribui para sanar alguns problemas.
Escopo de atuação
Como mencionado anteriormente, atuavamos de maneira cross, tendo um UX designer como ponto focal com quem as principais demandas eram sempre alinhadas, ou seja, seria a primeira pessoa a ser acionada caso aparecesse uma nova atividade.
Essa mesma pessoa era responsável pela passagem de conhecimento e acompanhamento da atividade dentro do time, e ao final, retornava a apresentação da atividade a quem havia solicitado.
Nesse ponto é essencial que o lead tenha a visão e skills para utilizar a metodología ágil, criando essa cultura desde cedo, afinal, dentro da maioria dos times e squads, é dessa maneira que atuam.
Rotina do cross
Para um time cross atuar da melhor maneira, é necessário um alinhamento interno entre os designers e que haja um ponto focal para centralização das demandas. Nesse processo, além de precisarmos sempre de um designer conduzindo as demandas, isso acabava reduzindo o capacity deste profissional no dia a dia, impactando na qualidade das entregas e no tempo hábil de execução.
Vimos que esse modelo de trabalho não fazia mais sentido, mesmo com um time mais maduro e com bom entendimento do produto, com processos de UX construídos e um backlog bem planejado.
Era então, o momento de mudar o escopo de atuação. Isso não é algo tão simples de ser feito, afinal, o modelo rodava bem apesar das dores.
Desafios na transição para as squads e no ágil
Levamos nossas dores para os nossos gestores, conversamos e entendemos que o time e processos estavam maduros o suficiente para a entrada em squads específicas, dedicando nosso capacity exclusivamente para as demandas de cada time, aliado com a evolução do produto e comunicação direta com os PO’s.
Essa transição não impactou só o time de UX, mas também todos os profissionais envolvidos na squad, ou seja, é algo que leva tempo e precisa de resiliência e adaptação. No começo essa adaptação foi mais complicada, pois estavamos bem acostumados com a atuação micro e mais centralizada no cross. Portanto, foi necessário um tempo de adaptação para entendermos na prática como funciona o modelo ágil e suas cerimônias (Review, retro, planning, etc…).
Vantagens da entrada do time nas squads
Com o passar das sprints, todo o time começou a colher os frutos da absorção do UX dentro da squad, o que colaborou com o trabalho dos desenvolvedores, arquitetos e outros integrantes.
Podemos citar alguns desafios que foram superados em sua totalidade ou parcialmente:
- Entregas validadas
- Maior capacity destinado às entregas
- Alinhamento nas cerimônias
- Entrosamento com os desenvolvedores
- Diminuição de demandas top down
- Entregas homologadas e validadas
- Aumento na qualidade dos entregáveis
Conclusão
Ambos os tipos de atuações, seja como time cross ou alocado em uma squad, tem suas vantagens e desvantagens, mas entendemos que a medida que o time se torna cada vez maior e mais complexo, o ideal é que os profissionais estejam focados em times especificos, reforçando a necessidade da continuação das próprias cerimônias e alinhamentos de UX, já que os nossos processos e entregas precisam ser alinhados no dia-a-dia.
Não queremos e nem podemos dizer qual modelo funciona para você ou para a empresa que você trabalha, trazemos aqui apenas nossa experiência pessoal, seguimos testando e revisando essas metodologias, corrigindo problemas e aperfeiçoando os pontos que necessitam de melhoria.
Agora gostariamos de saber:
Como você atua dentro de sua organização?
Você faria algo diferente do que relatamos aqui?
Deixe seu feedback do que achou para que possamos sempre melhorar e entregar o melhor para vocês.
Até a próxima estação!!🚉
