Design System, ágil e um time multidisciplinar
Quando pensamos em ágil, na maioria da cabeça das pessoas (pelo menos eu acho) vem um time formado apenas por analistas ou engenheiro(a)s de software. E como funciona dentro de um design system? Como é formado o time de design system?
Neste texto, irei comentar um pouco sobre a minha experiência como engenheira de software e a evolução nos processos de criação que tivemos dentro do design system da TOTVS.
O time
O nosso time iniciou com pessoas de diferentes áreas de formações acadêmicas. Composto inicialmente por 2 designers e uma desenvolvedora (eu). No decorrer dos meses vieram outras pessoas, e por fim ficamos com 4 designers e 1 desenvolvedora. Eu sempre atuei em times compostos inteiramente por analistas e engenheiro(a)s, mesmo em outra experiência de trabalho onde eu fazia pesquisas, sempre trabalhei apenas com desenvolvedores dentro do time.
Confesso que no início eu pensei que seria um tanto desafiador e realmente foi! Porque essas áreas tem formas de se comunicar diferentes, processos diferentes, formas de resolver problemas diferentes, entre outras.
E posso te falar? Superou as minhas expectativas! Sabe o motivo?
A sprint é do time!
Porque estamos construindo um produto único, o design system. Todos os integrantes do time estão imersos nas mesmas regras de negócio, todos trabalhando juntos para a construção de um único produto.
Isso traz a vantagem de ter menos falhas na comunicação entre designers e analistas. Com isso, tivemos que fazer alguns ajustes nos papéis, processos e na comunicação, para garantir a qualidade do produto e também a saúde do time.
Definição de papéis
No começo, não tinhamos definição de papéis dentro do time e nem de processos. Então sentimos a necessidade de ter alguém do time planejando os itens e priorizando as tarefas. Com isso, inserimos o nosso primeiro papel do ágil: Product Owner (PO).
E quem seria esse Product Owner? A pessoa que mais entende do negócio. E foi aí que escolhemos o Henrique Peixe para iniciar essa empreitada.
Ele já fazia parte do time de designers, mas ter essa separação de papéis foi essencial para desenharmos uma estratégia de negócio para o design system.
Definição de processos
Agora nós tínhamos três designers, um PO e uma desenvolvedora. Mas que processo de entrega iríamos seguir?
Decidimos então seguir um modelo de entrega baseado no Scrum, com criação de backlog, sprints, retrospectiva, entre outras cerimônias e tarefas que envolve o Scrum.
Também incluímos no nosso processo as validações das tarefas que eram entregues. Tanto as tarefas de design quanto as de desenvolvimento de software, tinha que ter uma validação final de pelo menos 2 pessoas, para ver se o que foi entregue estava com o seguintes pontos:
- as tarefas de design estava de acordo com aquilo que eu como desenvolvedora necessitava para poder escrever o componente.
- as tarefas que eu fazia como desenvolvedora eram validadas pelos designers para verificar se saiu tudo de acordo com o planejado e também para encontrar possíveis falhas (bugs).
Para que essas validações acontecessem, sentimos a necessidade de criar um ambiente no Github onde os designers pudessem fazer essa validação sem ter que montar um ambiente com o código. Como utilizamos o Storybook, criamos esse ambiente utilizando o Chromatic.
Também criamos um processo que foi aprimorado com o tempo, relacionado ao estado das tarefas. Utilizamos o trello para criar o nosso quadro de tarefas. Colocamos nele colunas para indicar backlog, itens da sprint, em progresso, pronto, o que estava aguardando validação, o que estava em validação e a nossa coluna de tarefas que estava em impedimento.
A criação de um backlog e planejamento único foi muito importante para priorizarmos as nossas entregas de acordo com um objetivo. Mesmo sendo o nosso foco principal a criação de um piloto, isso foi importante para mapearmos as dependências entre as tarefas.
Nas retrospectivas, sempre mapeávamos as melhorias e as lições aprendidas começaram a ser documentadas e transformadas em tarefas para poder melhorar na próxima sprint conforme o tempo que tínhamos disponível.
Esses processos foram muito importantes para conseguirmos trabalhar em um time com profissionais de diferentes áreas. Tendo como foco que todas as entregas são responsabilidade do time, todos os integrantes ajudam os demais integrantes a tirar os impedimentos das tarefas, bem como estar sempre validando as entregas.
Por fim, adotamos o ágil dentro do nosso time, adaptado as nossas necessidades.
Mais previsibilidade nas entregas
Para ter mais previsibilidade e planejamento nas entregas do time, entrou um outro papel do ágil dentro do time: Scrum Master.
E estamos em uma nova etapa onde iremos planejar os itens da sprint baseado em estimativas e pontuação (Planning Poker).
Daí você pode estar pensando, como o time irá pontuar um item da qual ele não tem conhecimento e não é da sua área de formação acadêmica? É possível? Sim, é possível! Porque o time vai ganhando experiência com as entregas, vai alinhamento o grau de complexidade e esforço que cada tipo de tarefa leva para ser feita juntos. Até mesmo por meio de contextualização de cada tarefa e comparação de pontos de outras tarefas já realizadas. O planning poker tem sido um formato super legal de se trabalhar.
Concluindo
Enfim! Está sendo uma experiência incrível ser imersa no mundo do design e ao mesmo tempo eles conhecerem mais do meu mundo como desenvolvedora.
Um ponto extremante positivo ao se trabalhar com designers, na minha opinião como desenvolvedora, é que eles tem a mente bastante a aberta para mudar processos e inovar.
Tivemos dificuldades? Sim, como todo o time, mas com um feedback constante utilizamos ela para evoluirmos juntos.
E unimos o foco do design e do manifesto ágil: pessoas!
Algumas referências que podem te ajudar
Conheça o nosso github: https://github.com/animaliads.
É isso pessoal, espero que tenham gostado! E nos vemos na comunidade!
