16 . 11 . 2017

Mesma metodologia, novas experiências

Quando se entra em uma nova empresa é preciso aprender e se adaptar a muitas coisas novas. Embora algumas ferramentas, metodologias e estrutura adotadas possam ser similares em diferentes empresas cada uma tem particularidades em seu modo de trabalho, que pode variar inclusive dentro da própria empresa dependendo do momento ou projeto.

Recentemente comecei a trabalhar como UX/UI Designer na Wiz e no meu primeiro projeto participei da Design Sprint, metodologia essa que já havia trabalhado em outras empresas. A Design Sprint é uma metodologia desenvolvida pelo Google para conceituar e tangibilizar uma ideia, um produto, suas implementações e funcionalidades em um curto espaço de tempo. A Wiz vem utilizando essa metodologia em seus projetos, e você pode saber um pouco melhor como isso vem sendo feito nesse texto que o Rafa escreveu sobre o assunto.

O projeto (ou vários projetos?)

O primeiro ponto que quero falar é sobre o primeiro projeto que trabalhei dentro da Wiz e como adaptamos a metodologia para ele. Normalmente a Design Sprint é feita para o desenvolvimento de novas ideias e produtos. Mas e se o produto que você precisar trabalhar já existir? E se esse produto for composto por diversos outros produtos? Bem, o desafio desse projeto foi exatamente esse, unificar em uma plataforma diversas ferramentas, funções e outras plataformas já existentes e comuns aos usuários.

Para isso, ao invés de fazer apenas uma semana de Design Sprint para o projeto completo foram realizadas 4 Design Sprints, cada uma voltada para uma ferramenta específica da plataforma.

Claro que tomar a decisão de seguir com o projeto dividido em várias Design Sprints tiveram vários impactos nos resultados e na maneira de trabalhar.

Os pontos negativos:

  • Foram necessárias duas semanas seguidas de Design Sprint, o que tornou o processo um pouco exaustivo física e mentalmente para o time;
  • Foram semanas diferentes para soluções diferentes que ao final deveriam se unificar em um só produto. Isso fez com que em alguns momentos do processo parecesse que as soluções não se conectavam em um único produto, fazendo com que retomássemos alguns pontos para que, como um todo, o produto fosse coerente e falasse a mesma linguagem;
  • Como foram várias semanas de trabalho, nem sempre o mesmo time conseguia estar presente o tempo todo. Dessa forma era necessário parar os trabalhos para fazer um alinhamento das decisões passadas sempre que alguém entrasse ou voltasse para o projeto.

Os pontos positivos:

  • O time passou bastante tempo junto, então ficamos muito integrados, o que resultou em uma convivência agradável e trabalhos satisfatórios;
  • Constante evolução! O produto foi evoluindo a cada semana fazendo com que ao final da última semana de Design Sprint tivéssemos um produto bem estruturado e consolidado. Diferente da metodologia tradicional, que ao final da semana se tem um protótipo que ainda vai passar por muitas alterações;
  • Foram feitos vários testes com o usuário. Como a cada semana fomos complementando nossa plataforma, sempre conseguimos testar as soluções desenvolvidas na semana vigente e as soluções das semanas anteriores, já com os ajustes provenientes dos resultados dos testes anteriores.

O time

Mesmo já tendo trabalhado com a metodologia percebi algumas diferenças quanto às minhas experiências pregressas. Uma delas foi quanto ao time. Nas minhas participações anteriores em Design Sprint sempre trabalhei com times apenas formados pelo PO (Product Owner), a maioria de designers ou a maioria de desenvolvedores, o que fazia com que muitas vezes as soluções ficassem enviesadas para um dos lados. Já na Wiz, tive a oportunidade de trabalhar com um time muito completo e bem estruturado.

Time esse composto por:

PO: Líder da unidade, responsável pela gestão das demandas e tomadas de decisão. Responsável pela visão, pelo produto final.

BD: Responsável pelo acompanhamento do projeto, apresentações de status e alinhamentos, homologação das demandas, controle de orçamento e contratos.

UX Designer: responsável pela tradução e detalhamento da visão do PO em uma experiência desejada. (Nesse projeto eu era responsável por essa tarefa).

UI Designer: especialista técnico em interface gráfica e com tecnologia. (Também fiquei responsável por essa tarefa).

DEV: time responsável por desenvolver e/ou acompanhar o desenvolvimento do fornecedor.

SM: responsável pela adoção da metodologia ASA. Acompanhamento dos prazos, dos gargalos, dos riscos do projeto.

Ainda podemos contar em alguns momentos-chave com a presença de um profissional de BI, um profissional responsável por planejar a jornada do cliente e, muito importante, aqueles que serão os usuários do produto.

Considero bastante relevante o fato de ter uma equipe com profissionais variados, que puderam, da sua forma e com seus conhecimentos específicos, agregar muito em pontos-chave no projeto. A opinião e soluções de todos foram importantes, o que fez com que o resultado respeitasse de forma equilibrada questões de modelo de negócio, experiência e tecnologia.

Metodologias para inspirar

No geral, considero que mesmo que em alguns momentos tenha sido cansativo trabalhar por várias semanas de Design Sprint nesse formato adaptado, foi muito proveitoso para o tipo de projeto em que estávamos executando. Ao final conseguimos construir em pouco tempo ferramentas individuais e agrega-las em um produto final que vai além de um MVP padrão.

E por mais que existam metodologias com processos definidos e testados é importante lembrar que projetos, culturas, pessoas e empresas são um universo de variedades. Metodologias devem ser uma base e inspiração para bons resultados, mas não significa que elas não posso ser adaptadas e melhoradas para atender de forma eficiente diferentes contextos.

Isabela Miranda, UX Designer na Wiz