BT

Novidades O InfoQ vem desenvolvendo uma série de novas funcionalidades para melhorar sua experiência com o site. Confira!

Enfrentando super problemas com jogos colaborativos

| por Ben Linders Seguir 9 Seguidores , traduzido por Luiz Rodrigues Seguir 0 Seguidores em 22 set 2017. Tempo estimado de leitura: 7 minutos |

Super problemas são problemas grandes, complexos e contínuos que só conseguem ser resolvidos através da colaboração. O fator chave para a colaboração funcionar é o uso de Serious Games, jogos nos quais os participantes voluntariamente concordam em seguir determinadas regras para gerar um resultado melhor e mais duradouro.

Luke Hohmann, CEO da Conteneo, fará uma apresentação na Lean Agile Scotland 2017 entitulada "Awesome Superproblems". A conferência ocorrerá de 4 a 6 de outubro em Edimburgo:

A conferência Lean Agile Scotland abrange uma grande variedade de tópicos, trazendo uma visão holística sobre o que é necessário para se desenvolver um bom software. O evento contará com boas palestras para abrir a cabeça e introduzir aos participantes novas ideias, além de sessões para ajudar quem é novo em Lean e Agile a começar sua jornada. O InfoQ fará a cobertura do evento através de sessões de perguntas e respostas, resumos e artigos.

O InfoQ perguntou a Hohmann o que faz dos super problemas algo tão difícil de resolver, quais as condições necessárias para a colaboração funcionar na resolução de problemas, e como escalar retrospectivas a um nível organizacional.

InfoQ: O que são os "super problemas"?

Luke Hohmann: Atualmente eu defino um super problema como um problema que tem as seguintes características: é incrível, no sentido de gerar um senso de reverência, medo ou admiração; e é "super", no sentido de que não pode ser resolvido por uma pessoa só, deve-se envolver outras pessoas para resolver o problema.

InfoQ: O que faz este tipo de problema ser tão difícil de ser resolvido?

Hohmann: Existem muitos fatores que geram desafios à resolução de super problemas Trago aqui alguns que destaco na minha experiência.

Talvez o fator mais proeminente esteja exatamente na forma como você fez a pergunta: você usou a palavra "resolvido". É o equivalente a perguntar como "resolver" o problema de comer, ou o de dormir, ou de ir ao banheiro. Você pode talvez resolver o problema, mas ele vai sempre voltar. É um problema contínuo.

O que transforma estes problemas contínuos em super problemas são o seu escopo e a sua escala: planejar o orçamento de uma cidade, o futuro do trabalho, gerenciar recursos naturais escassos, lidar com a mudança climática. Nós não podemos "resolver" nenhum desses problemas. Mas nós precisamos lidar com eles, assim como nós precisamos lidar com comer, dormir e ir ao banheiro.

InfoQ: Quais são as condições necessárias para a colaboração funcionar na resolução de problemas?

Hohmann: Acredito que a colaboração funciona melhor ao usar jogos e as suas semânticas como base para a colaboração. Eu vou usar o jogo Prune the Product Tree da Innovation Game® como exemplo e convido o leitor a usar o seu jogo ou técnica de retrospectiva favorita para testar os conceitos.

  • Existe um objetivo, ou algo a ser alcançado. Por exemplo, no Prune the Product Tree o objetivo é dar forma a um produto ou serviço que atenda às necessidades dos clientes.
  • O participante tem um entendimento claro dos recursos que estão à disposição, dos seus papéis e de como usar estes recursos (as regras para engajamento e interação, incluindo regras sobre aquisição e descarte de recursos). Continuando nosso exemplo, os participantes do Prune the Product Tree têm uma quantidade limitada de maçãs que representam funcionalidades do produto. Talvez seja possível imaginar uma variação do Prune the Product Tree na qual os participantes possam "ganhar" mais maçãs se apresentarem idéias convincentes.
  • Os participantes têm uma definição clara de espaço ou "campo do jogo". As vezes isso pode ser feito usando uma árvore física real; nós estamos vendo cada vez mais organizações se tornando remotas e usando a plataforma Conteneo Weave para abordar os problemas relacionados a times distribuídos e assim conseguir escalar.
  • Existe feedback claro quanto ao progresso. No Prune the Product Tree todos os participantes conseguem ver os resultados.
  • Os resultados da colaboração tem impacto real. O Prune the Product Tree funciona melhor quando os participantes acreditam que seu feedback vai afetar o produto ou serviço em questão.
  • Os participantes são voluntários. Eles não são forçados a colaborar.

Perceba que os jogos são a base da colaboração. Colocar essa base em prática significa abordar diferentes dimensões do espaço de design multidimensional da colaboração. Algumas das dimensões mais comuns são:

  • Presencialmente ou online: as vezes a colaboração pode ocorrer presencialmente, como em um time Scrum participando da Release Planning. As vezes, a colaboração é online: como quando milhares de times se envolvem em orçamentos participativos.
  • Estrutura do time: os times podem ser estáveis ou dinâmicos; homogêneos ou heterogêneos; baseados em estruturas existentes ou formados na hora, dependendo dos objetivos de quem desenhar o jogo. Os times podem ser formados somente por stakeholders internos ou por clientes/parceiros e stakeholders externos.
  • Síncrono ou assíncrono: os participantes podem trabalhar juntos em tempo real ou de forma assíncrona.

InfoQ: Na prática, como funciona o voluntariado?

Hohmann: Acredito que a participação voluntária ocorre tranquilamente quando a colaboração já faz parte da cultura do time. Fazem parte desta cultura as regras comportamentais do time, geralmente expressas através de acordos de equipe. Por exemplo, o Guia do Scrum define a cerimônia de Sprint Planning. Você pode alegar que a participação dos membros do time na Sprint Planning é "obrigatória", e não "voluntária" em um time Scrum. Mas na prática, os times com que trabalho logo percebem o valor da Sprint Planning e voluntariamente escolhem continuar fazendo a cerimônia. Esta participação voluntária permanece enquanto o time continuar percebendo valor neste framework colaborativo - e colaboração é exatamente a forma como o framework permite ao time atingir seus objetivos.

Há algum tempo o InfoQ entrevistou Hohmann sobre Retrospectivas em Larga Escala Usando Jogos Online onde ele explicou porque jogos online são ideais para retrospectivas em larga escala.

Hohmann: Jogos online têm um custo mais baixo, geram resultados mais rapidamente e permitem às retrospectivas serem conduzidas em momentos convenientes para os times envolvidos, além de possibilitar uma melhor análise dos dados. Os formatos online permitem que pessoas introvertidas ou que falam uma língua que não é a língua oficial da empresa possam expressar melhor seus pensamentos.

InfoQ: Como você escala retrospectivas a um nível organizacional?

Hohmann: O Conteneo é pioneiro em escalar retrospectivas, com algumas sessões tendo de 12 a 60 times ágeis. O processo é bastante objetivo:

  • Garanta que a liderança da companhia está em busca de melhorar a performance de múltiplos times. Deve-se ter certeza de que a liderança está ciente de que talvez sejam identificados alguns problemas mais complexos e difíceis de resolver.
  • Encontre um ou mais tipos de retrospectivas que possam ajudar a organização a encontrar oportunidades de melhoria. A retrospectiva Sailboat, por exemplo, é uma boa candidata porque é metafórica, flexível e permite aos times identificar tanto impedimentos quanto formas de ganhar velocidade.
  • Encontre um time de pessoas que facilitarão as retrospectivas. Os Scrum Masters são a escolha mais natural, dado que eles conseguem ser neutros.
  • Agende uma retrospectiva com cada time. Nossa experiência mostra que fazer isto com técnicas de retrospectivas presenciais demora muito e é entediante. É altamente recomendável usar uma plataforma propícia à colaboração em escala.
  • Analise os dados dos times nas seguintes dimensões:
    • Categoria: é um impedimento associado a pessoas, processo, tecnologia ou outra coisa? Existe algum padrão nos problemas e categorias?
    • Escopo: existe algum impedimento que o time possa resolver (que esteja dentro da área de atuação do time e sob sua responsabilidade) ou é algo que a organização precisa discutir? Para exemplificar a diferença, digamos que uma retrospectiva organizacional identifique uma série de mudanças importantes de infraestrutura, como atualizar do Angular 1.6 para o Angular 4. Tendo um ou dois times envolvidos, coordenar a mudança deve ser bem fácil. Mas com 30, 70 ou mais de 100 times, será necessário criar um projeto que permeie todos os times (um projeto de nível organizacional).
  • Monte uma lista de mudanças com estimativas de custo e impacto.
  • Envolva o time, permitindo a ele selecionar o impedimento a ser atacado
  • Comece a trabalhar!

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT