Dubaralho – Mídia e Design

Mídia e Design

A cada 25 palestras que você participa, com certeza 30 vão falar de Scrum e não tenho dúvidas que o tema de todos os eventos nem era Scrum. :D

E uma ferramenta importante no Scrum, é o Kanban, que eles insistem em querer fazer um formato digital, mas nada tão simples e interativo como o tradicional onde todos olham o tempo todo, sem necessidade de login, senha, abrir navegador, alt+tab e etc.

Porém todos os kanban que vejo, são bem feios, alguns dão até medo e em muitos casos acabam poluindo o local de trabalho.

Com isso, a galera do Design da empresa onde trabalhamos fez uma proposta de 3 tipos de quadros kanban.

Kanban UX

Leia o restante do artigo e baixe o arquivo em PDF com autorização para mudar no Illustrator.

1. Kanban para UX

Na nossa primeira experiência com o Kanban, utilizamos o modelo da imagem abaixo, nele todas as etapas do método de Design, desde da Compreensão (Briefing) até Look&Feel e Design Final estavam distribuidas sem distinção na coluna de “Em Andamento”.

Este mostra os entregráveis ao lado, principalmente para quem está iniciando, é bem importante observar.

UX

Download Kanban UX  (PDF)

Depois de um tempo, percebemos que este primeiro kanban não nos ajudava a ter uma noção muito clara de onde estávamos em cada tarefa.

2. Kanban para UX – Incremental

Com a experiência de uso, vimos a necessidade em dividir em mais etapas, de acordo com o método de Design de UX que utilizamos. Com isso, criamos um novo Kanban como é mostrado abaixo.

A área de Design cria software, sites, intranet, extranet e são muitos clientes internos de diversas áreas.

Como a área de Design funciona como um pool de recursos para todos os projetos da empresa, analisamos que o Scrum “clássico” ainda não se adapta as nossas necessidades de acordo com os processos internos. Mesmo assim optamos por utilizar uma ferramenta que o Scrum também utiliza que é o Kanban.

O kanban abaixo é bem mais detalhado nele os post-its ficam cada um na sua fase do projeto. Procuramos mostrar o que siginifica cada fase e algumas ferramentas e entregáveis que podem ser utilizadas, um resumo do nosso método.

ux-detalhado

Download kanban UX – Incremental (PDF)

3. Kanban para Design Gráfico/Comunicação

Nossa área é como se fosse uma agência dentro de uma empresa e dividimos em 2 partes, Designer Gráfico/Comunicação e User Experience e também fizemos um quadro especial para quem trabalha mais na parte gráfica e comunicação.

No lado esquerdo colocamos alguns tópicos da identidade visual alguns pontos importantes da estratégia de branding que precisam ser analisados antes e durante a execução do projetos de Design Gráfico/Comunicação.

Designer Gráficono

Download Kanban – Designer Gráfico e Comunicação (PDF)

Ps.: Créditos extras para o Georges e  o Juliano na criação dos nossos experimentais kanbans! sintam-se a vontade para críticas e ideias para melhora-los.

——————————–

Atualizaçao:

Acabamos deixando de dizer como e com que materiais fizemos realmente o nosso kanban. Entao segue…

O quadro de suporte fizemos com a metade de uma placa de dayfoam, as partes impressas foram feitas com impressora jato de tinta comum em papel sulfite A4, depois foi só recortar e colar com cola bastão sobre a placa.

As linhas que dividem a coluna foram feitas depois de tudo e a lápis, assim podemos inclusive reaproveitar a mesma placa quando mudamos do primeiro para o segundo tipo de kanban, que tinha bem mais colunas.

Blog Widget by LinkWithin

Nenhum post relacionado.

13 comentários

  1. Fabio Ferrari dia 29 de October de 2009 às 3:58 am

    O problema de montar um Kanban muito bem desenhado é o desencorajamento da mudança do processo por melhoria contínua (Kaizen).
    Um Kanban precisa ser mais vivo que possível, permitindo ajustes e experimentos de mudança de processo em pequenos incrementos.
    Já vi Kanbans de diversos tipos, alguns com Kanban desvios por um tipo de FastTrack, outros que incorporam preceitos de criticidade e/ou dificuldade e ainda outros que implementam até desvios por limitação de estoque de trabalho em curso (WIP).
    Este engessamento do Kanban é exatamente uma das críticas mais forte dos defensores do Lean/Kanban contra o SCRUM.

  2. melina alves dia 29 de October de 2009 às 1:18 pm

    Muito inteligente e funcional seus “Kanbans”. Já baixei aqui;
    Obrigada por disponibilizar.

  3. melina alves dia 29 de October de 2009 às 1:25 pm

    Ops, o link para “Download Kanban UX (PDF)” está com
    arquivo errado.

    :)

  4. Carlos Gustavo Xavier dia 29 de October de 2009 às 1:48 pm

    Mandou bem Hélio! Vou passar pra todos da empresa.

  5. helio.costa dia 29 de October de 2009 às 5:20 pm

    Menlina,

    Arrumamos, obrigado

  6. Gabriela dia 30 de October de 2009 às 3:59 am

    A primeira vez que ouvi falar de Kanbam e Kainzen foi no mestrado (Ergonomia, na Eng. Produção). Visitamos algumas indústrias, e os quadros eram sempre bem “rústicos”. Por isso acho esquisito isso de Kanbam digital, porque a idéia mesmo é poder mudar e dar visibilidade, fazendo com que todos do posto tenham “responsabilidade” pelo estado do trabalho. Por isso achei a forma de vocês usarem muito boa mesmo. Não é porque a gente trabalha “com computador” que a gente tem que fazer tudo “no computador”.

  7. André Faria Gomes dia 30 de October de 2009 às 4:03 am

    Bacana Cara!!!

  8. Luiz Faias Jr dia 30 de October de 2009 às 4:38 am

    Olá Hélio,

    Acredito que tanto faz se o kanban é digital ou não, se é feio ou bonito. O importante é a preocupação de entrega e melhoria contínuas como citou o Fábio Ferrari acima.

    Na minha empresa temos o kanban físico, que dá uma visão rápida para todos os envolvidos e torna o trabalho mais transparente e também temos o digital através de um software livre chamado Pronto que desenvolvemos.

    http://pronto.bluesoft.com.br

    Ficou bem legal o design. Parabéns.

    Abraço

  9. Ricardo Longa dia 30 de October de 2009 às 5:55 am

    O negócio é unir o útil ao agradável e criar um painel digital com um bom sistema para apoio ao SCRUM (como por exemplo o PRONTO, citado acima) substituindo assim o quadro físico. Este painel digital deve ser Touch Screen.

    Logo, temos um software (melhor controle) + o “kanban físico”.

    Lembra daquela tela touch screen utilizada no Fantástico?

    Um abraço!

  10. Georges Herzog dia 30 de October de 2009 às 12:06 pm

    Ferrari e Luiz,

    Concordo com vocês quando dizem que o Kanban deve ser o mais simples possível de ser alterado… Afinal ele deve trabalhar de acordo com os nossos métodos (que vão se alterando com o tempo) e não nós nos moldarmos em função dele. Alias já estamos na segunda versão do nosso Kanban e acho que não deve ser a última.

    Mas o negócio é o SEGUINTE, ehehe o nosso Kanban é para designers e todos tem acesso a ferramentas de edição (Photoshop, Illustrator…) assim acho do que fácil de se editar.

    E Ferrari se tu tiver precisando de uns servicinhos de design pra alterar o kanban da sua área me dá um toque ae!!! ehehe
    abração!!

  11. Alberto Sasso de Sá dia 30 de October de 2009 às 1:31 pm

    Grande (ou seria pequeno) Hélio…
    Legal disponibilizar pros visitantes do blog o kanban que usamos.
    Está sendo muito útil e funcional usar o kanban. Não sei se um software seria tão utilizado e atualizado como o nosso (físico).
    Abraço

  12. tiago jaime machado dia 3 de November de 2009 às 8:50 pm

    RSS Feeds completos por favor!

  13. Vinicius Serpa dia 30 de December de 2009 às 5:51 am

    Apesar de ter ficado com uma cara boa achei que mistura um pouco alguns conceitos.

    No painel genérico uma sugestão seria não estipular de maneira fixa quais seriam as atividades desempenhadas em cada sprint por dois motivos: imagino que nem todas as atividades são executadas em todo sprint e segundo e mais importante, os sprints devem ser orientados às estórias. O cliente ou product owner pode não estar diretamente interessados em “pesquisas de usuário”, “mapas conceituais”, “wireframes” ou “protótipos”.

    No painel detalhado, as atividades de compreensão e pesquisa não deveriam ser realizadas exatamente durante o sprint mas sim no product backlog e posteriormente no planejamento do sprint, para que seja possível estimar qual o esforço/tempo necessário para entregar cada estória. Sem essas informações teoricamente não seria possível estabelecer quais estórias poderiam ser entregues.

    De qualquer forma esse é apenas um ponto de vista, o mais importante é fazer a metodologia realmente funcionar na prática.

Escreva um Comentário