« HE:labs
HE:labs

Designer em um time ágil (Parte 1)

Postado por Beatriz Correia em 03/11/2014

Como é começar em um time ágil, como funciona essa metodologia, quais as expectativas sobre o designer do time, quais são os principais erros de iniciante e como se antecipar a eles?

Há mais ou menos um ano atrás, eu estava tendo a minha primeira experiência com a metodologia ágil de desenvolver software. Ter que se adaptar à esse sistema foi também uma oportunidade para aprender sobre trabalho em equipe e desenvolvimento de produto. Enquanto eu revisava um material para falar sobre o assunto em uma palestra, achei que seria interessante compartilhar parte dele aqui. Vamos lá:

Metodologia Ágil & Iterações

Alguns de vocês já devem conhecer como a metodologia ágil funciona. O desenvolvimento ágil é uma metodologia de desenvolvimento de software que visa minimizar os riscos de investimento. Funciona de maneira que você quebre o desenvolvimento em pequenas metas, validações que são desenvolvidas em períodos curtos. Aqui na HE:labs esses períodos tem a duração de 4 dias úteis.

A metodologia toma como partida a idéia de que o cliente aprende sobre as necessidades do seu negócio à medida que são feitas essas validações semanais, facilitando que ele direcione mais seguramente o desenvolvimento do seu software. Uma das razões pelo qual as pessoas tem optado pelo desenvolvimento ágil atualmente, é que a metodologia mais tradicional - conhecida como desenvolvimento em cascata - é tida como burocrática e lenta.

Os períodos curtos de desenvolvimento da metodologia ágil são chamados de ITERAÇÕES. Aqui na HE:labs as iterações geralmente funcionam assim:

Dia 1

Reunião de planning com o cliente, onde ele explica sobre o produto dele, suas expectativas a curto e longo prazo e quais são as expectativas dele de implementação para aquela iteração em particular. O time conversa, analisa o material e o que deve ser feito, tira dúvidas, sugere melhorias e cada um apresenta pro cliente uma visão realista do que acha que cabe ser feito naquela iteração. É feita uma priorização de funcionalidades e o que fica definido é documentado.

Dias 2 e 3

Nos dias dois e tres o time se concentra em implementar as funcionalidades que foram definidas na reunião de planning. No ínicio de cada dia de implementação é feita uma reunião interna para alinhar o time, como no final de cada dia é feita uma outra para verificar o progresso do time no desenvolvimento.

Dia 4

O dia quatro começa como os outros dias de implementação, mas parte dele é destinada a testes e refinamentos. No final do dia é feita a entrega para o cliente, juntamente com o roteiro de testes para que o cliente possa testar as funcionalidades que ele havia previamente requisitado. E na semana seguinte, começa tudo de novo, já com feedback do cliente e em alguns casos, feedback de comportamento do usuário também.

Agora, vamos dizer que você (designer) vá começar num time ágil. O que seu novo time espera de você?

Expectativas do time sobre o designer

Vou citar algumas expectativas que o time geralmente tem sobre o designer da equipe, segundo as minhas experiências.

1. Quem melhor deve compreender o conceito do produto. É importante que você entenda que apesar de estar toda equipe trabalhando no produto, quem mais deve estar familiarizado com o conceito dele é você designer, porque é sua responsabilidade fazer com que os usuários entendam o produto com facilidade e tenham uma boa experiência através dele. Você tem o poder sobre isso uma vez que é você quem define a identidade visual do produto, a interface que é a experiência do usuário com o sistema.

2. Estar em sintonia direta com o cliente. O cliente sabe o que ele quer para o negócio dele mas isso não significa que ele também saiba organizar as próprias idéias a converter isso em informação pra você com facilidade. Cada caso é um caso. E você precisa muito entender quais são as expectativas dele em relação ao produto. Então é esperado que você construa uma boa relação e comunicação com o idealizador desse produto, para que tenha êxito na hora de desenvolve-lo visualmente.

3. Conhecer o contexto do produto. É importante que você saiba onde está pisando. Então, como em qualquer área de design, você não pode desenvolver nada às cegas, sem conhecer o mercado, os usuários e as principais referências desse produto. Isso nem sempre vai estar à sua disposição e "mastigadinho". Então outra expectativa sobre o designer do time - na verdade acho que em qualquer time onde exista um designer - é que você faça o seu "dever de casa" e fique por dentro do contexto do produto antes de apresentar qualquer solução. Pois o seu cliente antes de tomar a decisão de investir nesse produto, pode ter certeza que ele pesquisou bem antes e conhece esse background.

4. Ser organizado em relação à tecnologia (Essa é para os designers que também são front-enders.) É importante que você descubra quais são as referências do seu cliente em relação à front-end. Que tipo de experiência ele pretende passar aos usuários dele. Principalmente para você saber de antemão se é algo que você domina com facilidade ou se pode ser que você perca um tempinho a mais passando por uma curva de aprendizado com aquela tecnologia.

5. Conheça o seu time É essencial que você conheça as habilidades e limitações do seu time e que deixe claro quais são as suas, porque assim vocês podem se ajudar nos pontos mais urgentes e gerar alternativas rápidas para possíveis problemas de implementação. Conhecer o time também é importante na hora da reunião de planning para você não vender uma funcionalidade para o cliente que o seu time não domina.

Assim eu vou encerrando a primeira parte de "O designer em um time ágil". Os próximos capitulos serão:

  • Como iniciar no time.
  • Principais erros de iniciante.
  • Organizando o front-end para a metodologia àgil.
  • Trabalhando em cima dos feedbacks.
  • Conclusão.

Compartilhe

Sabia que nosso blog agora está no Medium? Confira Aqui!