Construindo um kanban board para o seu time de design (em atualização)
Tão importante quanto ter visibilidade das tarefas que estão sendo trabalhadas pelo seu time é saber em que momento do processo de design elas estão, assim, você como líder poderá atuar de maneira estratégica na orientação de seus liderados, terá controle sobre a carga de trabalhado destinada a cada pessoa podendo balanceá-laevitando sobrecarga ou atrasos de entrega e terá respostas na ponta da língua quando te questionarem prazos ou qualquer outro tipo de informação. A maneira mais eficiente que conheço e pratico já faz alguns anos sem precisar ficar perguntando ou caçando informações com as pessoas é a gestão visual.
O conceito de gestão visual é bastante antigo e foi consolidado com os métodos ágeis para organização de processos em times de engenharia do software, o método Kanban é o mais utilizando onde, através de cartões e colunas é possível reconhecer rapidamente as demandas. Por conta da praticidade, sua utilização tem sido cada vez mais disseminada para outros contextos inclusive o de design. Se você é líder de design e ainda não utiliza, está perdendo tempo e a oportunidade de construir com seu time um ambiente mais dinâmico e eficiente.
Montar um quadro de gestão visual que exponha as informações que você precisa e fomente um processo coerente com a necessidade do time não é algo simples, mas calma! Vem comigo que vou te ensinar como criar um quadro legalzudo agora mesmo.
Neste artigo você vai aprender sobre:
1- Como definir um processo de design
2- Como transformar o processo de design em um quadro Kanban
3- Como organizar tarefas em um quadro Kanban
4- Como obter informações sobre cada tarefa
5- Como acompanhar a produtividade do seu time
1- Como definir um processo de design
O primeiro passo é definir um processo de design coerente com a realidade do seu time. Não é necessário inventar algo super novo, até porquê eu aposto que minimamente seu time já utiliza um processo mesmo sem perceber e que provavelmente é parecido com o double diamond, então, por via das dúvidas comece com ele e inclua outras etapas importantes. Como por exemplo, uma coisa que times de design pecam em não fazer ou fazem de maneira muito superficial é a documentação e isso é extremamente prejudicial pois detalhes acabam sendo esquecidos que dificultam a contextualização. Outra coisa que pode ser inclusa é um moento de review para garantir a qualidade da entrega. Portanto, sugiro incluir no processo inicial um momento para cada um desses pontos.
(imagem)
Pode ser mais complexo dependendo da maturidade do seu time e empresa, a minha sugestão é que a primeira versão tenha os seguintes objetivo:
Envangelizar processos e práticas
Ter visibilidade do tempo médio de entrega
Expor e entender os maiores gargalos
quando o comportamento estiver natural, simplifiar as etapas será importante.
O próximo passo é identificar quais são as possíveis abordagens de design. Você deve concordar comigo que existem diversas maneiras de "fazer de design", processos que podem incluir mais explorações ou menos explorações, mais validações ou menos validações, tudo isso depende do risco que se pode tomar. Porém, não importante qual a abordagem, no fim todas elas vão passar pelas etapas que já desenhamos ali em cima, não concorda?! A diferença está nas práticas, entregavéis e mensuração. Com isso, vão existir demandas que irão precisar de uma análise profunda sobre um problema ou oportunidade para então serem levantadas hipóteses de solução, mas também irão existir demandas que já serão provenientes de hipóteses, que precisarão de um processo mais focado na construção de solução ou ainda, se é algo mais provisório para ser testado e evoluído. Nessa minha linha de pensamento já é possível identificar tipos diferentes de demandas que poderão relacioanar diretamente a abordagem mais ideal:
(1) Investigação
Seria um processo focado em pesquisa, com o objetivo de reconhecer problemas e levantar oportunidades que irão direcionar o futuro de um produto ou serviço.
(2) Validação de hipótese
Seria um processo focado transformar uma ideia em solução para ser testada e muitas vezes evoluída a partir do aprendizado mensurado pelo uso dela. É possível tomar um risco maior. Normalmente um quick-win.
(3) Solução "final"
Seria um processo focado em remodelagem ou mesmo construção do zero de uma solução. Também será mensurado e evoluído em algum momento, mas neste momento o risco é maior, é preciso ter mais certeza do que vai ser implementado para que resolva de modo efetivo um determinado objetivo.
Tá fazendo sentido pra você?! Agora vem o pulo do gato!
Com a definição do processo de design e tipos diferentes de abordagens , temos mimamente um processo 🙌🏻
Você pode até mergulhar na especificação dele definindo que tipo de entregáveis e ações são possíveis em cada etapa. Uma dica: construa ou ao menos validade com seu time.
EM ATUALIZAÇÃO DAQUI PARA BAIXO!!!
DoR e DoD
No meu exemplo abaixo inclui momentos de aprovação após as etapas de ideação, prototipação e validação. O racional é o seguinte:
- No momento de descoberta os designers estarão levantando informações e isso já é algo que costuma ser bastante colaborativo com outros especialistas, ao final desta análise vários insights já terão sido gerados e poderão ser exploradas aquelas ideias mais promissoras em baixa fidelidade. Porém, antes de partir para um protótipo de alta fidelidade ou mesmo um teste, é importante alinhar se o caminho que estamos seguindo atende as necessidades de negócios, por isso, momento proprício e requirido de alinhamento.
- Após a prototipação é legal que todos tenham conhecimento de como a solução será testada para que, se for necessário alterações, saibam da onde estava para onde foi.
- Após a validação, pode ser ela qualitativa ou quantitativa, é um momento muito importante de compartilhar os aprendizados e alinhar as alterações necessárias. Após a alteração, no meu exemplo aqui o time não precisaria de um outro momento de check-out pois estou assumindo que existe uma confiança de que o alinhado será feito.
Se no seu time tiver algo diferente disso, onde é necessáiro oficializar mais vezes, inclua mais etapas de aprovação ou, se não for necessário e isso já for um comportamento natural, não inclua (depois te conto por quê é importante expor esse tipo de etapa).
(imagem)
2- Como transformar o processo de design em um quadro Kanban
Pra começar é simples, as etapas viram colunas. Adicional a isso, todo quadro Kanban terá uma fica de tarefas a fazer e uma de tarefas concluídas, uma inicio e outra no final respectivamente.
(imagem)
Os diferentes tipos de tarefa poderão ser identificados com cores e, caso o seu time ainda atenda projetos diferentes ou squads diferentes, você pode identificar com o nome delas para facilitar a filtragem da informação, assim como colocar o nome ou a foto do responsável pela tarefa a qual deverá ser representada em um card.
(imagem)
Show de bola, não?! Mas, Ju, onde eu coloco isso tudo?
Talvez sua empresa já utilize uma ferramenta de gestão visual como o Jira que é bem comum, mas você pode utilizar um Trello, ou um Miro e até mesmo o Figjam. Não coloque a ferramenta como uma barreira, pode ser até post-it colado na parede desde que todos os membros do seu time possam ver esse quadro. O importante é que esse quadro seja exclusivo do seu time e de mais nenhum outros, cada um deve ter o seu com as colunas e tipos de tarefas ideais para a realidade em que trabalham.
Ahhh, no Jira e no Trello é possível configurar certinho as etapas que cada tipo de tarefa é obrigada a passar e isso facilita horrores a vida.
(imagem)
3- Como organizar tarefas em um quadro Kanban
Agora a brincadeira vai ganhar forma e ficar mais divertida, eu prometo!
Cada artefato gerado pelo designer não precisará de uma tarefa. Ou seja, se uma demanda necessitar de entrevistas, benchmarking, geração de alternativas, prototipação, teste de usabilidade e sabe lá mais o que, a tarefa será única pois o quadro Kanban tem o objetivo de dar visibilidade da etapa de design e não do entregável. Vai por mim, essa é a melhor coisa. Se for criado uma tarefa para cada artefato, uma demanda teria nesse exemplo pelo menos cinco card, é insano e nem faria sentido no formato de etapas que estamos criando aqui. É possível? É. Mas ai o quadro precisaria ter etapas diferentes e seu time que lute pra ficar gerenciando 500 cards (eles vão odiar e você também), imagine encontrar um card no meio de tanta poluíção visual? Se for necessário expor os artefatos, construa um check-list como descrição da tarefa.
(imagem)
Com tudo o que definimos até agora você tem todos os elementos exigidos pela metolodologia Kanban, falta apenas organizar sprints. Sim, isso mesmo. O time de engenharia da sua empresa eu aposto que trabalha por sprints, seu time de design também deveria fazer isso se já não faz.
Eu te disse que ia ficar mais divertido… pois bem, com essa organização de sprints você conseguirá negociar as prioridades de um modo mais efetivo e visual. Por exemplo,
Como resolvemos
Para nós ficou nítido que não poderíamos continuar encarando o processo de design igual ao de desenvolvimento, mas que obviamente não poderíamos obrigar o desenvolvimento a seguir o nosso processo. Então, decidimos:
(1) criar um quadro Kanban exclusivo para o fluxo de design com steps que representassem a nossa metodologia de trabalho e que eliminasse a necessidade da criação de diversas tarefas. Passamos então a ter os steps: backlog, to do, discovery, ideation, prototyping, validation, documentation e done. Abrimos também as possibilidades para status de postergado (tarefas que por algum motivo perderam a prioridade, mas que logo voltarão a ser trabalhadas) e cancelado (tarefas que por algum motivo perderam a prioridade, mas que não voltarão a ser trabalhadas seja a médio ou longo prazo).
Com isso, cada demanda passou a receber apenas uma tarefa e ao visualizar o nosso quadro Kanban, hoje é possível entender qual é o processo de design e em que momento a demanda está.
(2) criamos filas de aprovações para expor momentos nos quais a tarefa eventualmente fica em stand by por precisar de um direcionamento do stakeholder ou validação técnica. Lembrando que essa "burocracia" precisou ser criada devido ao nosso contexto de consultoria e com o objetivo de minimizar principalmente o retrabalho. Com isso também passamos a ter melhor visão de quanto tempo realmente o designer passou trabalhando e quanto tempo ficou esperando. Conseguimos expor aonde estão os gargalos do processo, cobrar com maior efetividade a atenção dos aprovadores ou validadores e criar ações efetivas para destravar as demandas.
(3) criamos tipos diferentes de tarefas para representar os fluxos de trabalho e facilitar o filtro e extração das métricas. Com isso passamos a ter previsibilidade e aprender com o nosso histórico de tarefas. Ou seja, sabemos agora quanto tempo em média leva uma tarefa que entra para o fluxo de discovery, delivery e review, então quando por ventura questionam o tempo de entrega temos maior assertividade na "promessa".
(4) flexibilizamos a "escolha" de status de acordo com o tipo de tarefa. Fluxos diferentes representam também steps diferentes. Não faz sentido uma tarefa do tipo review passar pelo status de discovery, por exemplo. Assim como nem sempre uma tarefa do fluxo de research passará por um momento de prototipação. Logo, é possível pular steps.
(5) criamos raias no quadro Kanban para agrupar tipos diferentes de tarefas. Assim fica mais fácil encontrar as coisas.
Implementando DoR e DoD
Tudo lindo, tudo maravilhoso, mas nem tanto…
Se não temos uma tarefa para cada artefato, como garantimos/expomos que eles serão gerados? Como sabemos que temos todas as informações necessárias para definir quais artefatos precisarão ser gerados? Como garantimos que os aprovadores e validadores corretos sejam envolvidos?
Criamos então uma espécie de briefing que na verdade as metodologias ágeis chamam de DoR (definition of ready) e um check-list de artefatos chamado de DoD (definition of done). Esses itens são preenchidos/definidos assim que a tarefa é movida do backlog para o to do.
Abaixo você confere alguns tópicos que normalmente são preenchidos:
DoR (definition of ready)
- Mapeamento de stakeholders e validadores;
- Descrição da história (EU…COMO…QUERO…);
- Critérios de aceite;
- Regras de negócios;
- Expectativas e dores;
- Quais serão os usuários impactados;
- Hipóteses já levantadas;
- Entendimento das limitações técnicas;
- Revisitar/aplicar o Design System;
- Alinhamento expectativas e objetivos com a validação com o demandante;
- Alinhamento do perfil de usuários ou stakeholders que participação da validação, contatos, roteiro, etc.;
- Acesso ao ambiente de homologação.
DoD (definition of done)
- Pesquisa qualitativa e/ou quantitativa realizada;
- Benchmarking e/ou análise de interface atual;
- Mapeamento de hipóteses;
- Alinhamento técnico;
- Mapeamento de cenários;
- Mindmap de conteúdo e/ou estrutura;
- Propostas iniciais das telas e fluxos em baixa ou média fidelidade;
- Compilação das descobertas e montagem da defesa de design;
- Alinhamento técnico da aplicabilidade das ideias;
- Alinhamento com stakeholders sobre o caminho a ser seguido;
- Criação do protótipo em alta fidelidade;
- Revisão dos textos validando interpretação, gramática e tom de voz;
- Organizar o Handoff de UI.
É claro que são exemplos e, de novo, nem todos os tópicos servem para qualquer tipo de tarefa. A análise e definição é realizada entre Líder e Designer antes de atualizar o status da tarefa de to do para discovery.
Fora isso, nós também temos políticas para bloqueio de tarefas, expurgo, limitamos o WIP (work in progress) do time e outros detalhes.
Métricas
E tudo isso serve para quê?!
Organizar a vida do designer. Dar visibilidade. Extrair métricas, analisar e definir ações.
As métricas que normalmente analisamos, são:
- Lead time: tempo que um cartão leva para passar por todo o quadro Kanban;
- Cycle time: tempo que o card fica em uma determinada coluna;
- Throughput: vazão de entregas realizadas em determinado período (por dia, semana ou mês).
- Aging: tempo de envelhecimento de um card fica parado em um determinado step, normalmente de aprovação;
- Work in progress (WIP): quantidade de cartões que são trabalhados paralelamente;
- Cumulative flow diagram (CFD): comparativo entre quanto trabalho foi feito, o que está em andamento e quanto tempo será necessário para que determinado escopo seja concluído.
Ufa! Quanta coisa.
E se eu te disser que ainda não é o ideal?!
Pois bem, não é.
Por mais que um quadro Kanban nos traga uma visão linear do processo de design ele não é assim na realidade. Basta pensar… quantas e quantas vezes chegamos no momento da prototipação e percebemos que faltou um detalhe lá na pesquisa e precisamos voltar? Quantas e quantas vezes fizemos um teste de usabilidade e o resultado nos fez voltar para os ajustes?
Hoje tentamos resolver essas coisas com as políticas, poderíamos resolver de outras formas que eu nem vou citar para não deixar nenhum agilista de cabelo em pé com as minhas ideias 😝. Confesso pra você que até chegarmos nesse modelo levamos meses, alteramos diversas vezes e ainda vamos mexer mais. Melhoria contínua sempre!
De qualquer forma, espero que esse conteúdo te inspire, te dê ideias e base para adaptar à sua realidade.
