Author Archives: Fabrício Yutaka Fujikawa

  • 0

Gestão do Conhecimento: medindo ROI através das Lições Aprendidas

Category : Bússola Digital

Sabe aquelas situações em que determinada rotina ou atividade de trabalho ficou prejudicada porque o funcionário “responsável” tinha faltado ou estava de férias, e nada estava documentado? “Ih, isso tem que ser com Fulano.” Pior é quando você descobre que o Fulano agora é um ex-funcionário e saiu brigado do grupo. E não se trata apenas de rotinas administrativas, não. Isto é muito comum, por exemplo, em desenvolvimento de software. “Ih, essa parte foi Sicrano quem fez… só ele que sabe mexer.” São os chamados conhecimentos tácitos, que ficam confinados à cabeça de algumas pessoas.

Falando sobre outro tipo de conhecimento, é provável que já tenha vivenciado várias experiências positivas — que representam oportunidades concretas de aumento de receitas ou de redução de custos — serem mal aproveitadas nas empresas. Pense em quantas situações você já viu alguma coisa ser feita de forma diferente e dar certo. Várias, correto? Agora, pense em quantas dessas situações geraram mudanças de rotinas, processos e procedimentos. Continua pensando? Pois é… é difícil mesmo. A cultura, se é que existe, é de aproveitar experiências negativas para melhorias de processos. Pouco se fala das experiências positivas.

Para resolver esses e outros problemas, entra em cena a Gestão do Conhecimento. Dentro desse tema, parte fundamental são os programas de Lições Aprendidas.

Lição Aprendida pode ser definida como “um processo de transferência de experiência entre pessoas de uma mesma organização, seja ela uma experiência positiva ou negativa. Uma Lição Aprendida precisa ter um certo grau de ineditismo. Algo que todos já sabem não é uma lição e sim um consenso. Algo que se aprendeu por não ter seguido um procedimento ou padrão também não é uma lição. Padrões e procedimentos foram feitos para serem seguidos e se existe uma lição nisso é ‘Siga o procedimento’.” (Alexandre Bello em Revista Gestão do Conhecimento, edição 06).

A Lição Aprendida, então, é fruto de um resultado diferente do que era esperado. Ora, se já havia um resultado esperado, é bem provável que existisse uma forma de medir se esse resultado foi atingido, ou não. Assim, na grande maioria das vezes, dá para medir os resultados de uma Lição Aprendida. Esse é um aspecto crucial para convencer a alta gestão a investir nas Lições Aprendidas: é possível medir o retorno sobre o investimento.

Vamos ver alguns casos práticos?

Em 2008, prestando serviços para um jornal de São Paulo, tivemos uma Lição Aprendida originada de uma experiência positiva: na 5a. feira, antevéspera da eleição, a área cliente pediu para gerarmos uma tabela das zonas e seções eleitorais. Consultamos os dados fornecidos pelo TRE e vimos que seria possível, porém, dado o prazo, a entrega seria bem no conceito MVP: aplicaríamos um XHTML para gerar um HTML básico, sem layout, formatação, etc. A área topou e conseguiu fazer à parte o tratamento das informações para que elas fossem publicadas nas edições do fim de semana. Com isso, as vendas aumentaram 30% em relação ao histórico de outras eleições. Muito bacana, né?

Ainda sobre eleições, mas falando sobre o mundo digital, também participamos de projetos para a divulgação dos dados de apuração do TRE nas eleições de 2008 e 2010. Nestes casos, todo o aprendizado que ganhamos em 2008 foi utilizado em 2010: tivemos uma reunião formal de passagem de conhecimento entre os analistas para se falar sobre as dificuldades e as experiências positivas. O novo time aproveitou o conhecimento adquirido na experiência anterior, incorporou novos conhecimentos tecnológicos que surgiram durante o período e a apuração de 2010 foi fantástica: no primeiro turno, chegamos a receber uma chamada de um dos principais portais do Brasil para a nossa página, dada a velocidade com que conseguíamos disponibilizar as informações. Resultado para os executivos? Aumento expressivo da audiência do site durante o período da apuração. De novo, aprendizado organizacional convertido em resultados concretos para a empresa. Veja o registro da época no blog da Tecnologia.

Mais recentemente, no Projeto Olímpico, tivemos outra Lição Aprendida a partir de uma experiência positiva. Mudamos de um sprint quinzenal para um sprint semanal, com o objetivo do time ter um aprendizado mais rápido do método, pois era a primeira experiência com Scrum para a maioria dos integrantes. Fixamos a 3a feira como o dia dos ritos (review, retrospectiva e plannings). Tivemos dois resultados positivos não imaginados: primeiro, ficou muito claro que o time passou a ser mais rápido que a definição de requisitos. Com isto, começamos a ter impedimentos nas histórias, que se tornaram evidentes nas reviews, e as definições passaram a ser “puxadas” junto às áreas responsáveis, gerando uma força colaborativa muito boa. O outro resultado foi mais curioso: a 2a feira, tradicionalmente um dia meio chatinho, ganhou outra cara: passou a ser o dia da véspera da entrega e com uma “pegada” bem acima do normal.

Para fechar, duas dicas importantes.

A primeira: Lição Aprendida deve ser capturada enquanto ainda está bem fresca na memória. Evite deixar para registrar semanas ou meses depois, “no final do projeto”. Capture assim que possível. É a sua melhor garantia de aprendizado.

A segunda: outro dia, lendo um post da Annelise Grip, conheci a ferramenta Learning Canvas. Achei bem interessante e fiquei com vontade de experimentá-la. Tem tudo a ver com Lições Aprendidas (com foco em experiências negativas).

Que tal você compartilhar as suas experiências com Lições Aprendidas também?


  • 0

Como Controlar a Qualidade no Mundo Ágil?

Em outras palavras, como fazer software rápido, mas fazer bem-feito? Afinal, uma vez que as práticas ágeis de desenvolvimento de software estejam em pleno uso na sua empresa por seus times, é bem provável que você encontre alguns problemas em relação ao processo de desenvolvimento:

  • novas releases quase sempre acompanhadas de novos bugs;
  • dúvidas se o esforço de desenvolvimento está indo para valor adicionado ao produto ou para manutenções corretivas;
  • não-conformidades e divergências em relação ao padrão corporativo (mesmo entre analistas de uma mesma equipe);
  • diferentes padrões de desenvolvimento e metodologia entre os times;
  • falta de sinergia entre as equipes e dificuldades para fazer um rodízio entre os analistas de times diferentes (afinal, cada equipe faz do “seu” jeito).

Uma solução tradicional seria montar um time de controle de qualidade para inspecionar os artefatos e testar as releases, apontar as não-conformidades, bugs e rejeitá-los. Simples, porém um paradoxo conceitual. Afinal, todo o ganho de agilidade nas entregas pode ser colocado em risco se deixarmos para descobrir, lá no finalzinho, que parte do software precisa ser refeita. Facilmente, para cada correção, podemos adicionar algumas semanas no prazo final. Ou, então, aquela correria de entrega final, com custos de horas-extras e a penalização motivacional do time, além de prejudicar a qualidade do produto (“testa aí, rapidinho…”).

É possível fazer diferente, com bons resultados. Podemos contar o caso, ocorrido numa grande organização, onde atuamos na causa-raíz do problema (a falta da cultura de testes e a baixa aderência à metodologia de desenvolvimento pelos desenvolvedores), e não apenas nos sintomas (artefatos com não-conformidades e bugs), focando na importância de se construir software com qualidade desde o início.

Em conjunto com a equipe de qualidade, criamos indicadores para acompanhamento das entregas e do trabalho dos desenvolvedores, tangibilizando os pontos fortes e os pontos de melhoria. Livres do rigor acadêmico, alguns indicadores eram simplesmente valores booleanos que indicavam se uma prática era seguida. Eles foram divididos em quatro grandes temas:

  • Processo de Desenvolvimento de Software
  • Produto
  • Eficiência e Melhoria Contínua
  • Cliente/Negócio

Fizemos uma apresentação dos indicadores para todos os desenvolvedores na reunião geral da Gerência de Desenvolvimento de Produtos, mas a receptividade deixou a desejar: alguns desenvolvedores sentiram-se “auditados”. Sempre acreditando no trabalho colaborativo, fizemos encontros com cada equipe para esclarecer dúvidas e reforçar o foco na melhoria do processo, e não no controle individual de desempenho.

 

Também para melhorar a comunicação com os times, criamos um rito ao final de cada sprint, a Retrospectiva Técnica, em que o time de qualidade apresentava para cada célula de desenvolvimento a sua planilha de indicadores, e eram levantados pontos de melhoria e respectivos planos de ação.

Após dois anos de trabalho, tivemos sólidos resultados.

Melhoria da Qualidade do Software Produzido

Redução direta do custo do desenvolvimento. A relação de causa e efeito foi visível: os times mais aderentes à metodologia de desenvolvimento tinham menos defeitos no software produzido. Além disso, identificamos que estava ocorrendo muito trabalho em correções de funcionalidades que já tinham sido dadas como concluídas. E, pior, sem reflexo em nenhuma métrica de acompanhamento, já que o indicador de defeitos, inicialmente, só monitorava sistemas em Produção. Mudamos o conceito do indicador para abranger as manutenções corretivas em todas as funcionalidades concluídas pelos times, mesmo que ainda não estivessem em Produção. Assim, cobrimos este aspecto da qualidade já na fase de desenvolvimento. Descobrir defeitos mais cedo sai mais barato.

Criação de Comunidade de Práticas: Fórum de QA

Conseguimos um compartilhamento contínuo de conhecimento tácito entre os participantes através de encontros periódicos. As reuniões de retrospectiva técnica foram fundamentais, pois permitiram o compartilhamento de experiências e debates, incluindo “lavagem de roupa suja”, com os desenvolvedores apresentando suas insatisfações e críticas com a metodologia. Isto permitiu uma melhoria contínua do processo. Tanto que elas evoluíram para uma comunidade de práticas, chamada de Fórum de QA, formada por representantes de todas as equipes de desenvolvimento, onde também tivemos troca de experiências, discussões sobre dificuldades, sugestões e dúvidas técnicas que ocorriam no dia-a-dia dos times.

Ampliação do Uso dos Cenários de Testes

Na metodologia de desenvolvimento da empresa, um documento muito relevante era o Cenários de Testes, escrito pelos próprios desenvolvedores, no formato “Given-When-Then”, de especificação comportamental (BDD). Com o passar do tempo, vários outros pontos de utilização dos documentos dos cenários de testes, não imaginados inicialmente, foram identificados:

  • na validação do PO técnico;
  • na validação do cliente;
  • na review;
  • na ambientação de novos colaboradores;
  • no apoio à equipe que cuidava da operação do software em Produção;
  • na definição dos cenários para testes de performance.

O fato de os documentos serem criados na plataforma Google Docs, disponível via internet para todos os usuários da empresa, e não só os da Tecnologia, viabilizou e liberou todo o potencial de uso dos artefatos, que se tornaram a principal forma de compartilhamento e reuso de conhecimento explícito na metodologia.

Automatização dos Testes

À medida que a cultura de desenvolvimento orientado a testes (a partir dos cenários de testes) foi absorvida pelos analistas, começamos a buscar soluções para automatização. Ao final do trabalho, todos os times já executavam testes automatizados: tanto os unitários, como também os testes de interface. Testes de regressão que levavam algumas horas para serem feitos manualmente, passaram ser executados em cerca de 20 minutos. Com os deploys constantes de seus produtos, isto representou uma redução significativa de custos para a empresa.

Simplificação da Planilha de Acompanhamento dos Indicadores

Ao longo do tempo, o acompanhamento dos indicadores foi simplificado, e reduzimos os indicadores para apenas quatro: um para cada tema. O objetivo foi focar no essencial e tornar a metodologia de acompanhamento mais leve.

Pesquisa de Satisfação com a Metodologia de Desenvolvimento

Tivemos 73,9% de avaliações positivas, respondidas pelos desenvolvedores e Scrum Masters.

Apoio e Patrocínio são Fundamentais

Mudar cultura é complexo. A alta gerência precisou atuar em alguns momentos como mediadora entre as equipes de desenvolvimento e a Equipe de QA, mantendo saudável a relação entre os analistas envolvidos. Sem este apoio, a iniciativa teria fracassado, sem dúvidas.

Nossa experiência mostrou que é possível fazer software rápido e bem-feito. Trabalhar na causa-raíz do problema, na cultura de desenvolvimento, é uma jornada árdua, que exige paciência e evangelização, mas compensa com resultados concretos, duradouros e, sim, mensuráveis.


  • 0

Gestão do Conhecimento e Lições Aprendidas na Implantação de Scrum

Category : Bússola Digital

Olá,

Tudo bem? Uma dúvida muito comum para quem vai contratar uma consultoria para implantar o Scrum é: “Como fazer a gestão do conhecimento da implantação do Scrum?”

A preocupação é garantir que a equipe interna absorva o conhecimento sobre o método Scrum, para que possa andar sozinha depois.

Saiba neste depoimento de Cláudio Barizon (*) quais foram suas experiências com o tema e as lições aprendidas de sua primeira implantação de Scrum com uma consultoria externa, quando era Gerente de Desenvolvimento de Produtos da Infoglobo:

  • A opção de contratar uma consultoria externa para implantar a metodologia Scrum
  • A escolha de um produto digital como projeto piloto para a implantação
  • A importância da base conceitual teórica do Scrum para o sucesso de uma implantação
  • A gestão do conhecimento na implantação do Scrum
  • Lições aprendidas: o que funcionou bem e o que não funcionou bem
  • A gestão das pessoas na formação de um time Scrum
  • Como o próprio Scrum ajudou na implantação da metodologia ágil

(*) Cláudio Barizon é Diretor de Negócios Digitais da ViaDigital.Solutions e liderou a implantação das metodologias ágeis na TI da Infoglobo

Veja a seguir alguns pontos de destaque:

A opção de contratar uma consultoria externa para implantar a metodologia Scrum: “O consultor Juan Bernabó nos apresentou como faríamos o projeto e nos ajudou muito a entender o novo modelo de atuação: como funcionava, que práticas eram essas.”

A escolha de um produto digital como projeto piloto para a implantação: “Assim que conhecemos o Scrum, para a gente ficou claro que ela seria muito aderente a um produto digital.”

A importância da base conceitual teórica do Scrum para o sucesso de uma implantação: “Na minha humilde opinião, várias das práticas já vinham sendo usadas de maneira instintiva, mas na verdade a gente não tinha a base conceitual correta e foi muito bom entender como funcionava e poder melhorar a forma de aplicar essas práticas.”

A gestão do conhecimento na implantação do Scrum: “Nós tínhamos o interesse de gerar aprendizado para algumas pessoas do nosso time. Então, nós inserimos algumas pessoas da nossa equipe nesse time de projeto (o projeto piloto) para elas absorverem o processo, como que criando um ‘cinturão’ de pessoas nossas ao redor desse time. Isso acabou não funcionando tão bem.”

A gestão das pessoas na formação de um time Scrum: “Tivemos muito atrito, muito calor, muita fricção e um pouco de vaidade porque eram pessoas de times diferentes.”

Lições aprendidas: o que funcionou bem e o que não funcionou bem: “As pessoas podem até ser de equipes diferentes, mas elas precisam se ver e se comportar como um time só. (…) A partir daí, começamos a usar scrum masters internos, porque achamos importante que a pessoa conhecesse os processos internos da empresa.”

Como o próprio Scrum ajudou na implantação da metodologia ágil: “Usamos as próprias práticas do Scrum para avaliar o que estava funcionando e não estava funcionando na implantação do Scrum. O apoio (do consultor) foi fundamental para a gente ter pensado nas perguntas certas e encontrado suas respostas.”

Espero que tenha gostado e que a experiência seja útil, caso esteja pensando em implantar uma metodologia ágil. Por favor, deixe seus comentários abaixo.

Um abraço,

Fabrício Yutaka Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0

Você Sempre Usou Post-it Errado!

Category : Bússola Digital

Duvida? Veja neste vídeo como uma simples mudança na forma de tirar o post-it do bloco faz toda a diferença para a sua durabilidade.


(clique na imagem para assistir)

Fonte: Exame


  • 3

Melhorar a performance dos times pode ser mais simples do que parece

Category : Bússola Digital

Olá,

Tudo bem? Hoje trago um vídeo bem interessante. É rápido (menos de 7min) e gera um impacto muito forte na nossa compreensão de performance de equipes, fluxo de trabalho, gargalos e otimização de processos.

Ele compara o tempo de escoamento da água de uma garrafa e mostra como pode cair de 18s para 12s com uma pequena alteração no sistema, sem nenhum componente novo, e como ainda pode diminuir para 4s se for introduzido um simples agente externo.

Clique na imagem para assistir o vídeo:

Tempo gasto para tirar a água da garrafa

Tempo gasto para tirar a água da garrafa (clique aqui para assistir no Youtube)

No primeiro caso, temos muita atividade, mas pouca vazão. O vídeo faz uma analogia com os conflitos corporativos que vemos no dia-a-dia entre diferentes equipes de uma empresa e os processos internos que não geram valor. Pode ser que até exista a otimização local de cada equipe, mas não há o pensamento no todo, de forma conjunta.

Já o segundo exemplo seria para os casos em que há um objetivo comum às equipes e elas perseguem juntas esse objetivo. Isto gera um fluxo contínuo, com todos caminhando no mesmo sentido e regulados pela vazão das entregas.

O que acho bacana neste caso é que não há nenhum novo agente externo. Ainda na analogia corporativa, bastaria que as equipes tivessem um objetivo comum, com metas claramente definidas e convergentes, para que o trabalho e as entregas fluissem melhor.

No último exemplo, houve a introdução de um agente externo e uma evolução mais significativa ainda. A analogia que o vídeo faz é que é possível ter um ambiente corporativo de calma, sem conflitos, estável e também com alta performance de entregas.

E, por que não?, uma cultura genuinamente colaborativa.

Um dos aspectos marcantes nas metodologias ágeis é que elas permitem evoluções como essas na performance dos times. Longe de dizer que tudo funciona às mil maravilhas e perfeitamente, mas é fato que elas viabilizam esse tipo de evolução, porque muitos de seus fundamentos e conceitos são baseados em trabalho colaborativo e na teoria das restrições.

Quem me apresentou este vídeo foi o Jesuino Lopes aqui da ViaDigital.Solutions. Espero que você tenha gostado. Por favor, deixe seus comentários abaixo.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0
Simplificar: menos pode ser mais

Simplificação – A Arte de Maximizar o Trabalho Não Realizado

Olá,

Tudo bem? Li a frase do título deste post no texto 10 Product Owner Questions, que relaciona 10 perguntas importantes para Product Owners. O post sugere que Scrum Masters podem fazer essas perguntas aos POs, como uma forma de coaching.

No final, apresento o link da matéria completa e vou destacar apenas 3 perguntas: as duas primeiras falam sobre características que vemos constantemente nos projetos em que atuamos e a última porque tem a ver com trabalho colaborativo, uma filosofia que acreditamos e pregamos no dia-a-dia.

1) Como você sabe se o seu produto é bem-sucedido e entrega valor?

Sim, é uma pergunta difícil, muito difícil. Por exemplo, tente responder você em relação à última tarefa que estava fazendo. Nada fácil, não é? Daí vem a importância da pergunta: se não sabemos a resposta, de que adianta fazer o produto (ou a tarefa)?

Mesmo que não seja viável medir o sucesso do produto e sua entrega de valor, é importante exercitar este raciocínio. Repare que “não ser viável medir” é diferente de “não ter métricas”.

Por exemplo, para este texto que estou escrevendo, uma possível métrica de sucesso e de entrega de valor poderia ser o percentual de pessoas que refletiram sobre suas próprias atividades, priorizaram algumas e despriorizaram outras, a partir da sua leitura.

É claro que, na prática, medir isso seria muito difícil. Mas, a métrica existe. Percebe a diferença? (E notou que o título do artigo está alinhado com a métrica?)

2) Que funcionalidades devem ser removidas do produto? Como você sabe que elas devem ser removidas? Como você pode afirmar que uma funcionalidade não pode ser removida?

A gente costuma bater muito nesta tecla em relação às histórias do backlog, mas o que achei interessante nesta pergunta foi que ela fala sobre funcionalidades já presentes no produto. Isso mesmo: trabalho já realizado. Por que então gastar mais trabalho para remover um trabalho já desperdiçado?

O autor do texto fala que é importante remover as funcionalidades que tem um ROI negativo, e que entender as funcionalidades realmente essenciais e o quão enxutas elas podem ser, é uma habilidade fundamental para aumentar a agilidade do produto.

Fiquei pensando se a gente fazia isso em nossos próprios projetos. Daí me lembrei de um aplicativo para o qual fomos contratados para fazer a manutenção evolutiva. Recentemente, sugeri remover de uma lista de um filtro de busca cerca de 90% dos seus itens, pois eles resultavam em um resultado vazio quando eram usados como filtro.

Acho que pode ser considerado um caso que se enquadra nesta pergunta: nossa proposta foi a de enxugar uma funcionalidade já existente, removendo opções que, no fundo, não tinham utilidade e prejudicavam a experiência do usuário.

Simplificar: menos pode ser mais

Simplificar: menos pode ser mais (foto: Ana Cotta)

3) Você ficaria tranquilo deixando a equipe de desenvolvimento rodar os próximos dois sprints sem falar com você?

Apesar de parecer o contrário, uma resposta positiva para esta pergunta depende muito de uma cultura de trabalho colaborativo. Quando o PO tira férias, por exemplo, ele tem um substituto que assume bem seu lugar? Se o PO realmente ficar indisponível, a equipe de desenvolvimento consegue falar com outros stakeholders, se necessário?

Para isso, primeiramente, o PO tem que:

  • passar as histórias com um bom nível de detalhes para o time;
  • comunicar a visão e estratégia de produto para todos;
  • deixar o backlog organizado com as próximas histórias razoavelmente detalhadas e priorizadas.

Enfim, o PO tem que fazer adequadamente o seu “dever de casa”, o que é ótimo, porque ele ganha mais tempo livre para focar nas suas outras atividades: estudo de mercado e concorrência, principalmente.

Mas, acima de tudo, as pessoas envolvidas tem que trabalhar colaborativamente pelo objetivo comum e não pensando apenas na sua área de conhecimento ou no seu departamento.

 

Espero que você gostado! Leia aqui a matéria 10 Product Owner Questions e deixe seus comentários abaixo.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0

Por que o post-it funciona tão bem nas metodologias ágeis?

Tags :

Category : Bússola Digital

Olá,

Tudo bem? Já falei um pouco sobre minha experiência com post-its no texto do Barizon “Como é que de quadros e post-its vai sair um software bom para os clientes?“. Eu uso post-it no meu dia-a-dia e entendo que não é uma solução mágica, nem se adequa a todos os cenários. Mas, nas experiências que tive, ele funcionou bem, muito bem mesmo.

Entretanto, outro dia li um post no LinkedIn, chamado “A Incrível Fábrica de Post-Its“, que me chamou a atenção para este ponto: os quadros e post-its são realmente uma das coisas mais marcantes nas metodologias ágeis. Por isso mesmo, ainda hoje são uma das mais controversas.

Então, resolvi trazer outros fatos e me aprofundar um pouco mais nas experiências que eu vivi, para alimentarmos uma discussão saudável.

Post-it gera motivação

Como integrante de time scrum, escrevi junto com meus colegas vários post-its de tarefas, o me dava uma sensação de autonomia e empoderamento muito fortes: a gente decidia o que seria feito para entregar a história priorizada.

Isso me dava muita motivação. Eu sou um profissional que preciso acreditar que o que estou fazendo tem valor. Para mim, é muito difícil fazer as coisas simplesmente porque tem que ser feitas. Acredito que a maioria dos profissionais de TI, ou melhor, não só de TI, mas da era do conhecimento, são guiados por esse tipo de motivação também.

Post-it não substitui documentação técnica

Há um mito de que quem usa os post-its é contra a documentação técnica. É engano! Se o time decidir que um artefato de documentação é importante e tem valor, o time cria um post-it para ele.

Na maioria dos projetos em que trabalhei, a gente gerou, por exemplo, um post-it para criar o diagrama de arquitetura da solução, representando as integrações entre os diversos componentes, porque a gente entendia que esse diagrama tinha vários benefícios:

  • apoiar na análise dos impactos de novas implementações ou manutenções no código existente;
  • mapear cenários de testes;
  • explicar a solução técnica para novos colaboradores do time;
  • consultas diversas no dia-a-dia.

Esse mesmo diagrama de arquitetura também ganhava um post-it para ser atualizado quando necessário. Por exemplo, num projeto, quando mudamos a solução de pagamentos online, criamos um post-it para atualizar esse diagrama.

Quadros e post-its são fáceis e todo mundo entende

Quando usamos um quadro scrum básico, o entendimento do quadro é imediato: histórias e suas tarefas, com 3 status (a fazer, fazendo e feito), por quais andam os post-its. Eventualmente, um 4o. status indesejado (impedido).

Nos times em que usei Kanban, o quadro também era simples de ser entendido. Era só mostrar o quadro, explicar as etapas e como os post-its deveriam caminhar. Pronto, com 15 minutos de conversa qualquer pessoa entendia o quadro.

Mas o bacana disso tudo é que o quadro scrum ou quadro kanban é a representação visual de um processo de trabalho. Nesse sentido, eles estabelecem um modelo mental coletivo do trabalho. Em outras palavras, todo o time tem um mesmo entendimento sobre o trabalho a ser feito. Isto é muito poderoso, porque alinha os esforços na mesma direção!

1 post-it + 1 post-it = 3 post-its

Por mais clichê que isto pareça, quem trabalhou num time ágil, já deve ter tido esse momento em que olhou para o seu quadro e “caiu a ficha“: caramba, o que a gente entrega como time é muito mais do que eu faço sozinho e é muito mais do que a soma dos nossos post-its.

Isto também dá uma motivação e orgulho de pertencer ao time difíceis de explicar em palavras. Mas a gente sente e isso aparece nas retrospectivas do time.

Os post-its organizam o trabalho da equipe

Imagine você trabalhando com 3, 4, 5 pessoas num time, todas mexendo no mesmo código-fonte, em que elas chegam em horários diferentes para trabalhar e vão embora também em momentos diferentes. Quando você começa o dia seguinte, como saber por onde começar, ou em que ponto o colega parou no dia anterior?

Os post-its respondem isso de forma muito eficaz, rápida e simples: é só olhar para o quadro e seguir o fluxo dos post-its.

Tanto quando atuei como scrum master, como quando era gestor do time, esta característica também me ajudava bastante: era só olhar para o quadro para saber o que dependia de minha ação.

Outra situação é quando você trabalha numa equipe geograficamente distribuída. Teve um projeto em que a gente estava no Rio de Janeiro, o cliente em Sorocaba e um fornecedor técnico em Miami. Além da distância, neste caso também tinha uma diferença de fuso horário. O que usamos? Quadro e post-its digitais (ferramenta Trello).

Post-its são divertidos

Pode parecer bobagem, mas para mim faz muita diferença. Você prefere trabalhar aborrecido ou trabalhar feliz?

Pequenas diversões ajudam a construir um ambiente de trabalho mais feliz. Mexer com os post-its para lá e para cá é lúdico, é divertido. Parece um jogo, em que você tem que andar com as peças para ganhar o jogo.

Mas não é um jogo em que sou eu contra um colega de trabalho. É o time todo, junto, andando com as peças. Isso é gostoso de fazer; é muito melhor do que ficar mudando o status de uma tarefa numa planilha ou num sistema.

Uma vez fiz com minha família uma “retrospectiva do ano“. No final de 2015, a minha filha mais velha pediu para a gente lembrá-la sobre como era o “jogo” que a gente tinha feito daquela vez.

Nas palavras dela, explicando por que gostou dos post-its:

“De início essa ideia de usar post-its pareceu meio simples, ainda mais com toda a tecnologia que temos hoje em dia. Mas a verdade é que escrever à mão e mover os post-its pra lá e pra cá acabou sendo bem mais dinâmico e divertido do que ficar olhando para uma tela de computador.”

Post-it só para mim?

Talvez você notado que falei muito em equipe, time, no coletivo. Será que o post-it funciona para o trabalho individual? Eu acho que sim. Eu uso, principalmente, porque acho mais prazeroso. Talvez esteja influenciado pela ferramenta digital que adoto, que dá mobilidade, tem ótima usabilidade, etc. Mas acho que usaria mesmo se fosse com post-its de papel.

 

Voltando ao artigo original que me motivou a pensar neste assunto, acho importante fechar com dois tópicos:

Post-it não gera software de qualidade: não é porque você usa quadros e post-its que você vai gerar software de qualidade. Quem faz um software bem feito é uma boa equipe de desenvolvimento. A metodologia ágil, e os quadros e post-its como suas ferramentas, ajudam a entregar valor mais rapidamente e a organizar o fluxo de trabalho para uma boa performance do time.

Agora, se o valor entregue é de fato um valor, depende muito da competência do Product Owner. Já se o software entregue está bem feito, depende da competência técnica do time de desenvolvimento, não dos post-its.

Tarefas e compromissos com datas: para isto, eu recorro à velha e boa agenda. 🙂

 

Fontes de referência

 

O que você achou? Qual a sua experiência com os post-its? Deixe seus comentários.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0

5 exemplos de quadros kanban para TI

Tags :

Category : Bússola Digital

Olá,

Tudo bem? Uma das características principais do quadro kanban é a sua flexibilidade: ele pode ser adaptado a qualquer tipo de trabalho e processo de negócio.

Por isso, deve-se controlar a tentação de começar com um quadro perfeito, extremamente detalhado, e iniciar com um quadro bem simples, o mais simples possível, para que seja adaptado à medida que as necessidades surgirem.

Por outro lado, começar a partir de alguns exemplos pode ajudar a acelerar o início e também te dar boas inspirações sobre o que usar e o que deixar de lado.

Este post, baseado no artigo original “Managing IT projects: kanban board examples for IT operations“, reúne 5 exemplos de quadros kanban feitos para equipes de TI (Tecnologia da Informação), mas que podem ser adaptados para qualquer processo de negócio e tipo de trabalho.

5 exemplos de quadros Kanban para TI

Os exemplos de quadros kanban foram divididos em 5 categorias:

  • por tipo de demanda
  • por prioridades variáveis
  • por subtimes de conhecimentos específicos
  • para projetos e dia-a-dia
  • para processos específicos

Quadro kanban por tipo de demanda

Este quadro kanban é perfeito para equipes de operações e atende ao cenário em que existem demandas planejadas, rotinas de manutenção, incidentes em produção (não-planejados) e demandas ad hoc (aquelas que surgem “do nada”). As raias horizontais diferenciam os tipos de demanda.

Quadro kanban para TI: por tipo de demanda

Quadro kanban para TI: por tipo de demanda (clique para ampliar)

Quadro kanban por prioridades variáveis

Já este é o quadro kanban ideal para quando temos aquela situação em que “as prioridades mudam a todo instante”. Nas raias horizontais, ele mostra o que está em andamento, o que está em espera e o trabalho que foi despriorizado. Achei interessante porque o quadro deixa bem claro o quanto de esforço foi gasto em atividades que foram despriorizadas, o que pode levar a ótimas reflexões internas.

Quadro kanban para TI: por prioridades variáveis

Quadro kanban para TI: por prioridades variáveis (clique para ampliar)

Quadro kanban por subtimes de conhecimentos específicos

Nesta configuração, o quadro kanban mostra nas raias horizontais o trabalho de subtimes que tenham conhecimentos específicos. Uma coisa interessante na imagem é que a região marcada com linhas diagonais indica que o limite de capacidade daquela etapa foi atingido, impedindo que novas atividades sejam “puxadas” para ela. (Pode parecer contraintuitivo, mas limitar a capacidade de trabalho é uma das bases da agilidade do método Kanban. Falarei sobre este assunto num próximo texto.)

Quadro kanban para TI: por subtimes de conhecimentos específicos

Quadro kanban para TI: por subtimes de conhecimentos específicos (clique para ampliar)

Quadro kanban para projetos e dia-a-dia

Este acho que é o quadro kanban mais genérico de todos os exemplos. Trabalhar em um projeto específico e também em atividades do dia-a-dia é um cenário muito comum. Repare que na raia “Projetos em Andamento” (“Active Projects”), o quadro kanban reflete o processo de trabalho da equipe através de suas divisões verticais, da esquerda para a direita (Test Design, Code, Test, Deploy). Esta também é uma outra característica fascinante dos quadros kanban: facilitar o entendimento coletivo sobre o processo de trabalho. (Bem mais simples que os tradicionais fluxogramas, não?)

Quadro kanban para TI: para projetos e dia-a-dia

Quadro kanban para TI: para projetos e dia-a-dia (clique para ampliar)

Quadro kanban para processos específicos

Se o quadro kanban anterior era o mais genérico, acho que este é o que dá mais conexão com a sua realidade, porque é fácil de entender o mapeamento do processo de trabalho no quadro kanban e dá vontade de customizar logo o quadro para a sua realidade, para o seu processo de trabalho.

Quadro kanban para TI: para processos específicos

Quadro kanban para TI: para processos específicos (clique para ampliar)

 

Vale reforçar o conselho de sempre começar com o quadro mais simples possível, para sair logo da inércia, e adaptá-lo com o passar do tempo. É incrível como, se você usar o quadro kanban no dia-a-dia, as necessidades de adaptação se tornam evidentes rapidamente. E, ao fazer as adaptações, você e seu time sentem a melhoria no processo de trabalho e passam a internalizar cada vez mais o conceito de melhoria incremental e contínua, que é também uma das bases teóricas dos modelos ágeis de gestão.

Fontes de referência:

Este post foi baseado no artigo “Managing IT projects: kanban board examples for IT operations“, que também é a fonte original de todas as imagens.

 

Espero que tenha gostado! O que você achou? Deixe seus comentários abaixo.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 4
Agenda com tarefas do dia

Como fazer o seu dia render?

Olá,

Tudo bem? Desde que me tornei um (feliz) empreendedor adepto do home office, em Setembro/2015, comecei a procurar um método para organizar bem meu dia-a-dia.

Já tinha experimentado por um tempo o método GTD (Getting Things Done), de David Allen, quando fui coordenador de TI na Infoglobo. Li seu livro Produtividade Pessoal e, na época, me agradou.

Livro Produtividade Pessoal, de David Allen

Livro Produtividade Pessoal, de David Allen

Só que desta vez eu procurava algo um pouco diferente, para eu produzir de forma mais eficaz, mas também me fizesse sentir mais dono do meu tempo, já que eu realmente tinha mais autonomia sobre ele.

Eu já conhecia o autor Cal Newport, professor de ciências da computação na Universidade de Georgetown. Pesquisando sobre o assunto, encontrei em um de seus artigos a sua metodologia de planejamento diário.

O título do artigo logo me chamou a atenção: “The Importance of Planning Every Minute of Your Work Day” (numa tradução livre, “A importância de planejar cada minuto de seu dia de trabalho“).

Ora, de imediato, discordei! Afinal, onde já se viu querer planejar cada minuto do seu dia?! Lógico que não vai funcionar!

Porém, como já conhecia o autor, e tinha me identificado com ele, resolvi ler o artigo para conhecer o método. Basicamente, ele consiste em, diariamente, planejar as suas atividades, criando e bloqueando fatias de tempo específicas para cada atividade. Durante essas fatias de tempo, concentração e foco total na tarefa definida.

Gostei muito e coloquei em prática! Veja uma agenda diária minha (as partes hachuradas mencionavam nomes que preferi não expor):

Agenda com tarefas do dia 30/11/2015

Agenda com tarefas do dia 30/11/2015

Três preocupações comuns para quem acaba de conhecer o método (eu realmente tive as duas primeiras):

1) Vale a pena mesmo investir tempo nesse planejamento? Segundo o autor, uma semana de 40 horas de trabalho bem distribuído segundo esse método equivale a uma semana de 60 horas de trabalho adhoc. Não sei quantificar, mas minha percepção é de que funciona, mesmo. Quando chego na fatia de tempo de trabalho, simplesmente a executo e não me preocupo com as outras coisas. Ou melhor, digo “não” para as outras coisas. Email fechado, redes sociais fechadas, etc. Dependendo do nível de concentração que preciso, WhatsApp no silencioso também.

2) E aquelas atividades, não planejadas, que eu sei que vão aparecer (geralmente, no meu email)? Neste caso, o autor também recomenda uma solução simples: crie uma fatia de tempo para elas. Por exemplo, 1 ou 2 horas para checar o email e encaminhar as demandas. Ele, inclusive, sugere uma estratégia para a incerteza natural dessas fatias de tempo: “process client requests; if I have downtime during this block, work on project X”.

3) Será que funciona para trabalhos de natureza criativa? Segundo o autor, sim, porque garante uma dedicação consistente de foco e esforço às atividades criativas. Além disso, a tranquilidade por saber que sua agenda está organizada permite você se aprofundar nesses seus “blocos criativos” e gerar mais valor. Eu acrescentaria que você pode também escolher o seu melhor momento do dia para trabalhar nessas atividades. Por exemplo, eu gosto de escrever mais pela manhã e tenho feito assim. E, de fato, saber que eu tenho um bloco de tempo definido para isso, mas também para as minhas outras atividades, no meu caso, me dá muita tranquilidade e prazer para escrever.

Refletindo sobre o método de Cal Newport, vejo algumas práticas parecidas com o método Scrum: bloquear tempo, foco em uma coisa de cada vez, representar visualmente o trabalho, uma divisão clara entre planejar X executar e a flexibilidade para mudanças.

Aliás, falando em falando em planejar X executar, num outro artigo o autor fala sobre planejar o dia seguinte ao final do dia anterior. Isto eu fiz umas poucas vezes e gostei também, mas confesso que ainda não consegui incorporar como hábito.

Sua metodologia na verdade é bem mais abrangente e aborda também o planejamento semanal e a longo prazo. Se você achar interessante, podemos abordar num texto futuro. Espero que tenha gostado. Veja aqui o artigo original do autor sobre o planejamento diário e deixe seus comentários. 🙂

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais


  • 0
Retrospectiva Scrum

O que será que o próprio time acha da retrospectiva?

Tags :

Category : Bússola Digital

Olá,

Quem ainda procura por uma oportunidade de trabalhar com Scrum na prática, costumar ter muitas curiosidades. (Não estou falando de curso de Scrum, refiro-me ao dia-a-dia, a fazer parte de um time Scrum de verdade.)

Um dos ritos mais intrigantes costuma ser a retrospectiva. Particularmente, eu acho o rito mais importante, porque é nela que vejo a oportunidade concreta da melhoria contínua dos processos.

Outro dia recebi um depoimento de um analista que trabalhou com a gente no Portal do Gerenciamento das Obras do Parque Olímpico. Veja o que ele disse sobre a retrospectiva (vou deixar exatamente com as palavras dele):

Po esqueci de falar na auto avaliação, acho q é outro ponto excelente, a “lavagem de roupa suja” ajuda a ver se tem algum gargalo na equipe/processo ou ate te faz refletir como vc poderia contribuir melhor em todo o processo.

É bacana, não é?! Um ponto importante é que ele estava bem desmotivado antes de usarmos o Scrum e depois virou completamente o jogo, realizando todo o seu potencial como profissional. “Dê autonomia ao time, que ele te entrega resultados.”

É fato.

Um abraço,

Fabrício Fujikawa
ViaDigital.Solutions
Métodos de startups aplicados a soluções empresariais

PS: a foto que ilustra a matéria é deste post (em Inglês) que, curiosamente, incentiva a abolir a retrospectiva. Coloquei o link aqui porque sou a favor da pluralidade de ideias. Vale conferir. 🙂


Receba nosso Boletim

Grátis, diretamente em seu email, artigos sobre métodos de startups aplicados a soluções empresariais.