Dinâmica “Troca de Papéis”

Publicado em por

Baseada na técnica “Um dia na vida”, a Dinâmica “Troca de Papéis, também visa “sentir na pele” o que o outro sente. Suas dificuldades, sucessos, processos e tudo o que envolve a atividade cujo problema irá receber a solução.

A diferença está no desenrolar das atividades e nos seguintes itens: Um maior aprofundamento no trabalho do outro, a área de negócio/cliente também efetuar a troca de papeis (é uma opção) e a presença de uma etapa posterior para validar a solução pensada.

Objetivos:

  • Aprofundar as informações sobre os requisitos de uma solução ou de parte dela.
  • Trabalhar a empatia entre os membros da equipe de desenvolvimento e as do negócio
  • Desenvolver a comunicação entre o time de solução
  • Aprofundar o conhecimento sobre o problema, projeto e o produto.
  • Verificar se a solução pensada é a mais adequada.

Utilização

  • Refinamento(Scrum): Refino de uma ou mais histórias (afins)
  • Imersão (Design Thinking)

Facilitação (Responsável pela organização)

  • Product Owner (Scrum)
  • Analista de Negócios ou
  • Product Manager

Participantes

  • Product Owner (Scrum), Analista de Negócios, Analista de Requisitos ou o responsável pelo detalhamento das informações
  • Representante da área de negócio / cliente

Primeira etapa

Primeiramente, essa etapa, consiste em o designer, ou quem precisa entender melhor o problema, viver como seu cliente, executando todas as suas tarefas.

Normalmente, separa-se um dia para isso, o “treinado” vai para a área de negócio, aprende o oficio e o executa. O ideal é que não se fale sobre desenvolvimento ou utilização do produto, nem como o ideal seria.

Em técnicas mais tradicionais o cliente mostra o trabalho, apontando as dificuldades, explicando o que o sistema tem de problemas, etc…

Mas, o teor não deve ser esse, porque senão vai acabar induzindo, o analista a pensar como ele, quando o importante é desenvolver, dentre outros aspectos, sua própria visão. O que naturalmente deve refletir o que está se passando.

O aprofundamento deve vir de um insight seu e não de algo relatado, pois isso significa que as dores foram mesmo sentidas.

O cliente deve ensinar o trabalho, como se o analista/PO/Designer, fosse alguém que estivesse começando na empresa naquele momento.

Deve falar tudo, nos mínimos detalhes, para que o outro seja capaz, de efetuar as tarefas sozinho. Assim, o profissional de produto, poderá captar não somente o problema a ser resolvido, mas também as regras que fazem parte da atividade.

Todo este treinamento deve ser feito, em uma etapa separada, como acontece quando há um novo colaborador, o que pode ser em um dia, ou em uma metade deste tempo.

Com o treinamento feito, é momento de o dia da troca ser vivido. O ideal é que, não se espaçar muito um dia do outro, o bom é fazê-lo até no seguinte.

Deve-se ficar o tempo todo daquelas horas úteis, na função do outro e assumi-la por completo.

Atender telefones, responder a e-mails, aos colegas, ao líder, enfim, fazer tudo o que o outro faz, mesmo que não tenha a ver diretamente, com o objetivo do projeto.

Devemos lembrar, que não é somente uma atividade executada no dia, são várias e que podem não estar ligadas ao problema, mas interferem nele de toda sorte. É importante viver todas as dificuldades sim, isso ajuda no desenvolvimento de uma melhor solução.

Tem que ser percebido, que há dias muito atribulados, em que se executa várias atividades ao mesmo tempo, dentre elas aquela em que a solução está sendo desenhada. Isso contribui para o entendimento do problema, como um todo e, também, para a empatia ser bem mais completa.

O projetista não deve ter medo de errar, deve viver tudo verdadeiramente.

Claro que há momentos de grande risco. Neste caso, o “dono da tarefa” assume sua execução, tal qual seria feito com um estagiário ou novo colaborador. Mas, no geral, o erro deve ser permitido, até porque, deve-se descobrir/viver como resolvê-lo.

O dia deve se desenrolar normalmente, o analista nem deve passar em sua mesa de origem. Deve vestir a camisa do cliente do início ao fim. Pensar como ele. Agir como ele. Trabalhar como ele. Todas as oito horas de trabalho.

Se quiser, pode guardar as informações coletadas, mas de preferência que ele se esqueça quem é, o papel que desempenha e o que está fazendo ali. Enfim, não precisa gastar tempo anotando tudo e esquecendo de viver seu dia.

O ganho é feito quando se internaliza a experiência, quando vivemos aquela verdade.

No dia seguinte, tudo volta ao normal. As lições aprendidas podem ser escritas em um artigo de blog, vídeo ou áudio, mas de uma forma cotidiana, contando a experiência. Nada muito extenso pois o objetivo é o compartilhamento da vivência, do sentimento e de informações coletadas que mereçam ser armazenadas.

Não é preciso um documento formal, um artefato, o ganho realmente é superior a ferramentas e regras, e a emoção não tem como ser documentada.

Segunda Etapa

Antes de mais nada, essa etapa pode ou não ser feita, é opcional. Trata-se da inversão da troca, na qual o cliente/área de negócio vai para a TI (ou centro de produto) executar o trabalho do analista. Essa operação é um pouco mais restrita pois normalmente o profissional não está somente naquele projeto.

Assim, o dia todo talvez não possa ser aplicado, mas a atividade de organização das informações, construção de algum artefato, presença em cerimônias e outras atividades do projeto em que ele normalmente não participa é possível.

A empatia é amplamente trabalhada, pelo cliente!

O cliente tem oportunidade de ver todo o trabalho que é feito, com o resultado de suas informações. Ele pode verificar todas as dificuldades envolvidas nessa transcrição, sentir como é transformar seu trabalho e conhecimento, e em ferramentas para o desenvolvimento do produto/sistema.

Desta forma, o analista ensina basicamente como se faz e o deixa fazer. Ele viverá “na pele” o início da transformação, como é que tudo acontece.

Com essa visão, ele terá despertado o interesse em passar suas informações da forma mais clara que puder, poderá completá-las e a tendência é que, ao entender melhor o funcionamento, aumente sua motivação para contribuir com o projeto.

Terceira Etapa

Por fim, após o desenho da solução ser concluído, pode-se repetir a troca de papeis, mas desta vez com a nova ferramenta que coincidência modelada. Executa-se tudo o que foi feito da primeira vez, porém não mais daquela forma.

Claro que o trabalho, não pode ser feito em plenitude, uma vez que não se tem ainda o produto pronto, mesmo que esse momento ocorra depois de uma ou mais sprints. Mas há como avaliar pelo menos o protótipo ou o MVP, dependendo do que será apresentado para validação.

Primeiramente, é importante verificar, se aquelas dores sentidas no primeiro momento estão contempladas, pelo menos em parte, do que se pensou para saná-las. É preciso vivê-las novamente, mas tratá-las agora com o “remédio” da solução.

Enfim, o objetivo principal aqui, é saber se o que foi pensado, está de acordo com o sentido. Esse momento de verificação, pode ainda ser repetido ao final de cada sprint, ou a cada parte da solução entregue.

Não é somente um teste, é a vivência, é a prática.

Logo, isso ajudará muito na construção das etapas seguintes, uma vez que, as lições aprendidas vão sendo construídas, ao longo de todo o processo.

Definitivamente, fica a cargo de cada equipe, a forma e a quantidade de documentação da experiência. Se acharem que vale o registro para a posteridade e que o conhecimento gerado será útil, melhor que o façam. Mas, não é obrigatório, porque, como dito anteriormente, o valor de todo esse trabalho está na internalização das “dores”, na emoção da vivência. Pois, frequentemente, não conseguimos passar o que foi sentido em palavras.

Flavia NobreInformações sobre a autora:

Flavia Nobre é Analista de Negócio e vem aplicando práticas ágeis e seus conhecimento de Product Owner no seu contexto dia a dia.

 

 

Colaboradora