No artigo de hoje vou explicar para quê serve, como criar um e como tornar a experiência com modelos de maturidade mais lúdica e interessante para os times. A ideia não é esgotar o assunto, mas dar ideias e uma introdução a quem busca este tipo de abordagem.

O quê é um Modelo de Maturidade?

Segundo a Wikipedia, em uma tradução livre, maturidade é uma medida da habilidade de uma organização de melhorar continuamente em uma disciplina em particular, sendo que a maioria dos modelos de maturidade certificam pessoas/cultura, processos/estruturas e objetos/tecnologia.

No âmbito de processos de desenvolvimento de sistemas temos modelos de maturidade, como CMMI (Capability Maturity Model Integration) e MPSBR (Melhoria de Processos do Software Brasileiro), e mais especificamente dentro dos métodos ágeis, temos um exemplo de modelo de maturidade no método Kanban. chamado KMM ou Kanban Maturity Model.

Basicamente, um modelo de maturidade te guia através de práticas e processos cada vez mais evoluídos para a obtenção de um nível desejado de proficiência e qualidade na execução de suas atividades. Modelos de maturidade são divididos em níveis, onde para se obter a certificação de que você chegou em um nível, geralmente tem-se de resolver um desafio ou fazer uma prova.

Por que criar um modelo de maturidade?

Todas as empresas e times querem evoluir, certo? Afinal, melhoria contínua é um dos objetivos primários da agilidade. Embora a melhoria contínua orgânica e artesanal tenha o seu valor, muitas vezes as empresas possuem um norte técnico e de processos a ser seguido.

Ter um modelo de maturidade claro, coerente e transparente ajuda e muito os times a atingirem esses objetivos e chegar nesse norte.

Se a sua empresa não depende de modelo de maturidade de mercado para conseguir clientes (CMMI é exigido em licitações, por exemplo), criar um modelo de maturidade próprio permite ter algo customizado às suas necessidades.

É importante ter em mente que o objetivo de um modelo de maturidade não é rotular que time é melhor ou pior, mas orientar a todos o caminho que a empresa espera que eles sigam, sendo algo de comum adoção em transformações ágeis e digitais de corporações, por exemplo.

Mas como tornar mais interessante e divertida essa busca por melhoria contínua direcionada através de um modelo de maturidade? Com gamification!

O que é gamification?

Gamificação é o uso de técnicas de design de jogos para enriquecer contextos geralmente não associados aos mesmos. Geralmente, atividades gamificadas incluem obtenções de pontos (como em programadas de fidelidade), classificação dos “jogadores” (como em “funcionário do mês”), emblemas de conquistas (como nas insígnias de escoteiros) e muito mais. Note que citando estas características eu já dei vários exemplos de uso do gamification no mundo real.

Ao adicionar elementos de jogos em atividades não relacionadas aos mesmos, agrega-se mais leveza à condução destas atividades, as torna mais divertidas, cria muitas vezes uma competição saudável e aumenta o engajamento do pessoal, pois é muito comum as pessoas engajarem em jogos bem construídos, sejam eles virtuais ou reais.

Como criar um modelo de maturidade gamificado?

Eu vou te fornecer um método, ok? Mas entenda que não é uma resposta para qualquer situação – a popular “bala de prata” que muitos procuram. É apenas um jeito de fazer, que já apliquei e deu muito certo, mas no meu contexto.

Qual era o contexto? Uma corporação financeira com quase 20 anos que decidiu fazer uma transformação ágil e digital em sua TI. Estou falando de centenas de pessoas de todas as skills possíveis que trabalhavam com arquiteturas fragmentadas (ou emergentes, mas sem se conectarem), quase sem processos de desenvolvimento (poucos times usavam PMI e menos ainda usavam métodos ágeis) e muitos, mas muitos desafios, além da vontade de mudar pra melhor, é claro!

O primeiro passo é entender quanto tempo o jogo vai durar. Sim, isso mesmo. Todo jogo tem início, meio e fim. Ninguém aguenta jogar o mesmo jogo pra sempre. Podem haver continuações depois? Sim, mas você precisa ter início, meio e fim no seu jogo ou as pessoas irão perder o interesse mais cedo ou mais tarde.

No meu caso, a duração do jogo era um ano. Queríamos fazer a referida transformação em um ano.

O segundo passo é entender qual é o final do jogo. Todo jogo tem de ter um final épico, que envolva uma grande transformação dos personagens, a superação de muitos desafios. Onde você espera que sua empresa/times estejam depois do jogo ter terminado?

No meu caso, esperávamos que após um ano os times estivessem todos rodando métodos ágeis (Scrum, Kanban, etc) e programando nos padrões da arquitetura corporativa definida pela empresa (stack de tecnologia, padrões de segurança, ferramental de desenvolvimento, etc).

Alcançado esse objetivo, entendíamos que a transformação teria sido finalizada com sucesso e, de quebra, acreditamos que afetaríamos a cultura da empresa positivamente.

O terceiro passo é entender qual a situação atual. Frente ao objetivo proposto para o tempo dado, o quão longe estamos de chegar lá? Note que essa metodologia de racionalizar um desafio não é minha, é de Toyota Kata, de Mike Rother, mas isso é papo pra outro momento. Se queremos chegar lá em x meses, quantos passos serão necessários? É viável esse salto evolutivo neste tempo?

No meu caso era viável, sim, pois as metas eram bem razoáveis. O cenário da época não era desesperador, apenas daria bastante trabalho. Tínhamos forte patrocínio da diretoria da empresa, o que foi vital para conseguirmos seguir adiante.

O quarto passo é quebrar o desafio em etapas, que seriam os níveis do modelo de maturidade. Você deve quebrar em um número de etapas suficiente para dar sensação de progresso aos times, mas não tantas que cheguem ao ponto de atrapalhar de mais, pois o avanço entre os níveis tem uma série de requisitos.

No meu caso quebramos o ano em 4 trimestres, onde a cada três meses fazíamos uma aferição dos resultados obtidos para ver quais times evoluíram dentro do modelo ou não.

Dependendo do número de níveis e da duração do seu jogo, você poderá associar uma temática à ele. Sim, pois todo jogo tem um tema central, certo?

Temas possíveis e comuns incluem artes marciais (trocando faixa a cada nível), escalada do Everest (alcançando acampamentos na montanha), treinamento Jedi (de youngling a Jedi master), RPG (que tal os níveis das classes de personagem?) e por aí vai.

Associar uma temática não é um passo obrigatório, mas altamente recomendável. A temática, quando bem escolhida, abre um leque de oportunidades para comunicação dos desafios, premiações e cria uma empatia enorme com os times, principalmente quando se usa elementos muito conhecidos da cultura pop.

No meu caso, usamos artes marciais como tema e definimos cores de faixa para simbolizar o nível de cada time dentro da evolução do modelo de maturidade. Apesar de não ser algo que muitos na empresa praticassem, foi algo que encontramos que todos conheciam bem o bastante e que tinha um simbolismo poderoso.

O passo seguinte é definir as regras para troca de níveis dentro do modelo. Sim, você tem de pensar como que os times e a empresa saberão quem está em qual nível e como avançar de um nível pra outro. Avaliações frias como provas não são recomendadas aqui, mas você terá de ter algum tipo de avaliação de qualquer forma, afinal, é um jogo e ele possui regras.

No meu caso, cada nível tinha uma série de microdesafios. Cada microdesafio era parte importante para se vencer o desafio do nível, que só era alcançado com 100% de microdesafios entregues. Cada microdesafio tinha um nome, uma descrição que dizia como ele era alcançado e uma categoria.

Para cada categoria (DevOps, Práticas Ágeis, etc), existia um consultor encarregado que não apenas avaliava os times naquele tema, mas também tinha a função de educar os times de como chegar lá.

E por fim, a comunicação. O jogo só fará sentido e os jogadores buscarão evoluir dentro dele somente se houver comunicação eficiente. Comunicação dos prazos, das regras, dos desafios. Comunicação das premiações, que podem ser apenas simbólicas, reconhecendo publicamente os times que vencem cada etapa ou mais materiais como prêmios lúdicos como adesivos com insígnias dos desafios, cartazes e bandeiras para os times, etc.

Evoluir tecnicamente times de desenvolvimento de uma grande empresa não é uma tarefa fácil (no meu caso eram mais de 40 times e 420 pessoas). Nem pra quem está organizando a transformação, nem pra quem está sendo transformado.

Comunicar bem sobre o jogo é uma maneira de tornar tudo mais real, mais tátil. Ajuda a garantir o engajamento e a tornar claro o que a empresa espera que os times alcancem.

E você, tem alguma experiência com modelos de maturidade? Alguma dúvida? Alguma sugestão? Deixe nos comentários!