quebra-cabeça

Gestão da Priorização de Demandas por Importância, Retorno Investido e Necessidade

Olá Pessoal

Certamente você já se encontrou na situação de receber inúmeras demandas ao mesmo tempo. Todas com aquele senso de urgência singular dado por cada departamento. Nestes momentos, caro amigo PO, como você gerencia e organiza tudo ? Por onde começar ? Quais critérios estabelecer ?

Pois bem, sabemos que não há, de forma alguma, uma formula mágica e que cada empresa e situação pode ser tratada de uma forma única. Entretanto, existem várias técnicas que podem nos auxiliar nestas definições. Então, vamos analisar três abordagens que podem ser utilizadas para priorização. Aplicaremos elas em conjunto para cada momento de nossa gestão. Utilizaremos as técnicas GUT, Peso Relativo e MoSCoW.

Interessou ? Então vamos lá ?

Definindo Importância

Para iniciarmos não precisaremos ter grandes descrições das demandas, mas precisaremos entender a importância de cada uma para a organização. Para esta primeira abordagem utilizaremos a técnica GUT (Gravidade Urgência Tendência) para priorizarmos nosso backlog de solicitações.

O GUT é uma técnica de priorização por importância, obtida através da multiplicação dos três fatores analisados. São eles:

  • Fator de Impacto (Gravidade): É analisado o impacto da demanda quanto a sua gravidade. O que a não implementação da demanda gera de impacto a empresa?
  • Fator de Tempo (Urgência): É analisado o impacto da demanda quanto ao tempo de resposta para a solução. Quanto mais o tempo passar o que pode acontecer ?
  • Fator de Tendência (Tendência): É analisado o impacto da demanda quanto ao que pode acontecer com o passar do tempo sem a solução. Se nada for feito a situação tende a se manter, nada acontecer ou só a piorar ?

Uma boa prática, para auxilia-lo neste momento, é definir para cada escolha uma justificativa. Só não esqueça de um detalhe muito importante para o sucesso desta abordagem. Você está lidando com interesses distintos e não pode definir nenhum destes fatores sozinho. Então, recomendo a você juntar seus clientes em uma sala, apresentar a lista de demandas e propor o exercício em conjunto.

Peça que cada solicitante justifique cada um dos três fatores referente a sua demanda. Em seguida leia-os para todos e abra um espaço para uma breve explicação do demandante. Por fim, solicite a todos que avaliem todas as demandas dentro do intervalo de 1 a 5 sendo sempre o de maior número o de maior peso. Ao final deste processo multiplique GxUxT de cada um, por fim some o de todos. Atualize a planilha e veja aquele que obteve o maior valor.

Esta é uma forma democrática de negociar e sensibilizar a todos quanto as atuais demandas, lembre-se de ter nessa reunião pessoas com entendimento gerencial quanto as necessidades da empresa.

Organize suas demandas em uma planilha simples. Após obter os valores de prioridade, organize do maior para o menor.

Demanda Gravidade Urgência Tendência Prioridade(GxUxT)
Demanda 1 5 3 4 60
Demanda 2 3 2 2 12
Demanda 3 4 3 1 12
Demanda 4 4 5 4 80
Demanda 5 3 3 3 27

Crie sua planilha com o peso para que o possa atribuir. Avalie ou escolha a melhor nomenclatura conforme a sua necessidade. Lembre-se do objetivo da abordagem. Um exemplo:

Peso Gravidade

(Fator de Impacto)

Urgência

(Fator de Tempo)

Tendência

(Fator de Tendência)

5 Extremamente grave Precisa de ação imediata Irá piorar rapidamente
4 Muito grave É urgente Irá piorar em pouco tempo
3 Grave O mais rápido possível Irá piorar
2 Pouco grave Pouco urgente Irá piorar a longo prazo
1 Sem gravidade Pode esperar Não irá mudar

Excelente PO, já temos nossas prioridade de demandas organizada por importância, e o mais importante é que conseguimos isso alinhados com nossos clientes.

Definindo ROI

Entramos agora no segundo momento de nossa priorização. Sabemos por onde começar, mas precisamos de mais detalhes sobre as nossas demandas. Vamos levantar alguns épicos com nossos clientes do que eles precisam exatamente. Perceba que não estamos buscando nos aprofundar em detalhes. Estamos otimizando nosso trabalho não realizando esforço desnecessário. Isso é Lean, isso é o princípio ágil:

Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

 Perfeito. Utilizaremos neste momento a técnica do peso relativo. Alinhando junto ao nosso cliente prioridades em função do retorno investido. Não entrarei em grandes detalhes sobre esta técnica pois tem um post abordando somente ela. Para saber como ela funciona com detalhes confira Aqui

Definindo as reais necessidades

Agora que já sabemos o que é mais importante. Quais desejos trarão maior retorno e deverão ser priorizados, finalmente entraremos nos detalhes e escreveremos as estórias desejadas por nossos clientes.

Vamos agora priorizar nosso escopo entendendo as reais necessidades demandadas no projeto. Lembre-se sempre que fizemos isso tudo para entregar valor ao nosso cliente. Nossa missão de sermos assertivos ainda não terminou.

Então vamos finalizar nossa construção do product backlog utilizando a técnica MoSCow. Trata-se de uma técnica muito simples onde classificamos nossas estórias da seguinte forma:

  • Must Have (Deve Ter): Classificamos todas as estórias que são essenciais para nosso cliente. Perceba que é daqui que construiremos o nosso MVP.
  • Should Have (Deveria Ter): Classificamos as estórias que tem importância ao projeto, mas sua implementação não é essencial.
  • Could Have (Poderia Ter): Classificamos aqui as estórias que não são importantes aos nossos clientes, mas que costumam ser aquelas que geralmente causam o encanto. A famosa cereja do bolo. Não devemos ignorar essas estórias, pois podemos utiliza-la em estratégias de negociação ou até mesmo na evolução do produto.
  • Won’t Have for Now (Não Terá por enquanto): Por fim classificamos as estórias que neste momento do projeto não geram valor ao nosso cliente. Lembre-se que o backlog sofre refinamento constante e as estórias estão sempre sujeitas a reclassificações conforme a necessidade e feedbacks do cliente.

Excelente. Saímos de um cenário nebuloso e construímos toda uma gestão e identificação de prioridades e necessidades alinhados com nosso cliente. Passamos a fazer a gestão de nosso portfolio de forma mais segura e assertiva. Só não esqueça que esse é um trabalho constante e sempre será preciso negociar e alinhar expectativas.

Agora que temos tudo pronto, vamos alinhar logo tudo com a equipe de desenvolvimento que já está ansiosa para iniciar a construção do MVP.

Espero que tenha gostado. Curta, Compartilha e Comente.

Abraço!

Einstein

Menos “achismo” e mais técnica – Priorização pelo ROI

Olá Pessoal

Na preparação de projetos ágeis, antes do start oficial da codificação, é necessário estabelecer o MVP (Minimum Viable Product) para iniciar o desenvolvimento de um potencial entregável estabelecido nas iterações acordadas. É preciso construir o Product Backlog e refinar gradativamente seus itens de acordo com a prioridade atribuída.

Neste momento, meu caro amigo PO, você precisa estar ciente que há uma grande expectativa do seu trabalho para a fluidez do projeto.

O time aguarda ansiosamente por suas definições para então ajudar a construir o Sprint Backlog e iniciar as Sprints. Enquanto isso o cliente cobra prazos e deseja o produto.

Então PO, antes de começar é preciso refletir nas suas atribuições e responsabilidades. É seu papel:

Ser um visionário: Entenda que o time vai se guiar pela visão que você der a eles de aonde vão chegar e isso precisa estar atrelado a expectativa do cliente

Negociar: Entenda que negociação não é simplesmente dizer que não dá ou impor uma forma de acontecer. Lembre-se que o melhor jeito de resolver situações de conflito é através do modelo ganha-ganha.

Planejar as entregas: Você deve construir o quanto antes o roadmap do produto para que tenha a visão clara de para onde está indo e de onde já veio. Defina os marcos de suas releases e trabalhe entregando o quanto antes e continuamente.

Planejar Sprints: Monte as Sprints com atividades alinhadas com o cliente.

Validar entregas: Reviews são momentos importantes. Você ajudou a definir o conceito de pronto. É sua responsabilidade analisar se as entregas estão em conformidade.

Gerar e entregar valor para o cliente: Todo o seu trabalho só terá sentido se você estiver entregando valor ao seu cliente. Não trabalhe com a síndrome do PO. O cliente está lá para ser ouvido. Então, entenda o que ele quer e precisa.

Trabalhar com Foco Do Cliente (outside in): Busque o feedback constante. Ouça sempre a opinião do seu cliente. O foco tem que ser naquilo que de fato interessa mais a ele.

Encantar o cliente: Esteja sempre alinhado com a expectativa e entendendo bem as necessidades do seu cliente.

Priorizar o Product Backlog: Utilize técnicas e não trabalhe no achismo.

Alinhados com o seu papel e sabendo que para desenrolar todo andamento precisamos ter o backlog priorizado. Focaremos em como priorizar o PBL através de uma das diversas técnicas existentes, utilizaremos o Peso Relativo para priorização do backlog.

A técnica de peso relativo é uma abordagem para analisar aquilo que possui maior prioridade. Entendendo-se mais prioritário aquilo que possui o melhor retorno sobre o investimento, o famoso ROI. Em outras palavras esta pode ser a melhor abordagem para o PO lidar com clientes que não sabem por onde começar, onde tudo é prioridade. Através de um alinhamento estratégico o PO poderá demonstrar qual épico será o melhor a iniciar e por onde poderá definir o Produto Mínimo Viável. Desta forma evite o achismo quanto ao que deve ser iniciado nestas situações. Se tudo é prioritário, demonstre aquilo que de fato trará melhor retorno ao seu cliente naquele momento.

Dito isso, vamos entender melhor a abordagem.

Para obter seu MVP você deve estar de posse de alguns épicos e temas levantados com o seu cliente. Neste momento ainda não precisaremos de grandes detalhes, pois precisamos entender melhor estas necessidades.

Junto ao seu cliente defina qual o objetivo do projeto. Está informação irá ajuda-lo a identificar aquilo que gera valor. Liste em conjunto com o cliente aquilo que ele anseia de retorno com o projeto com base no objetivo.

Exemplo:

  • Redução de Custos
  • Aumento da satisfação do cliente
  • Aumentar as vendas
  • Aumentar a carteira de clientes
  • Obter reconhecimento do mercado, etc…

Em paralelo a este alinhamento o time precisa estimar inicialmente os épicos e temas que você já levantou com o seu cliente. Esta visão macro irá ajuda-lo a entender melhor sua priorização.

De posse destes levantamos vamos tabelar os dados para extrairmos algumas informações:

Atribua valores de 0 a 10, ou qualquer outro intervalo de forma crescente, na matriz que relaciona os épicos com os valores. As colunas seguintes tratam apenas do somatório destes pesos e o percentual que representam quanto ao total. Na coluna de estimativa coloque o que foi analisado pelo time. O custo é o percentual dessa estimativa.

Por fim, teremos a prioridade que nada mais é que o ROI. É calculado da seguinte forma:

ROI = Benefício/Custo

Analisando nosso exemplo podemos entender que o épico de integração de mídias sociais é o mais prioritário quanto ao custo benefício. Logo, este será um recurso de entrega mais rápida e de melhor investimento.

Perceba que em nosso exemplo este item não é o de maior benefício. Contudo, a técnica também leva em consideração o custo proporcional, ou seja, não adianta o item representar o percentual elevado quanto ao seu benefício tendo um custo elevado. A ordenação de priorização acontecerá em função dos itens que apresentarem o maior equilíbrio quanto ao benefício e o custo.

Então, lembre-se que esta não é a única solução para priorização. Existem diversas técnicas e abordagens onde cada uma pode ser utilizada conforme a necessidade do projeto. O importante é estar familiarizado com o maior número que puder e aplicar aquela que for mais conveniente de acordo com a situação.

Deixe seu comentário, curta e compartilhe se puder.

Abraço!

kaizen

Nós não temos desculpas, temos solução – Kaizen

Olá Pessoal

Quando pensamos em melhoria contínua nos encontramos em um cenário de busca por práticas que nos levem a evoluir os processos em que estamos tendo rendimento negativo.

O “O que” e o “Como Fazer”, são questões que precisam ser respondidas por equipes e gestores nestas situações.

Hoje apresentarei a vocês uma dinâmica, criada e aplicada por mim, para trabalhar o foco do cliente voltado a solução de problemas.

Se animou ? Então vamos lá!

Entrada: Uma lista com feedbacks negativos

Objetivo: Promover o debate das avaliações negativas com foco na solução

Competências Trabalhadas: Foco do cliente, visão sistêmica, foco no resultado

Duração: 1h

Saída: Plano de ação

Aplica-se em: retrospectivas, giro do ciclo PDCA, busca pela melhoria contínua.

Então vamos aos detalhes do processo!!

PAPÉIS E RESPONSABILIDADES

A dinâmica proposta é um jogo, e para começar organize as pessoas envolvidas em equipes. Defina um personagem central, alguém que será o juiz da competição. Para esta função escolha alguém totalmente imparcial, que não tenha ligação alguma com a situação do projeto. Nós queremos utilizar a disputa para estimular soluções, logo, a decisão de um time vitorioso é puramente ilustrativa.

Por fim, estabeleça um facilitador que explicará as regras e conduzirá o jogo.

DINÂMICA DO JOGO

Prepare os feedbacks e os organize em pequenos cartões. Na parte principal coloque o tema e no verso descreva em detalhes a avaliação negativa. Posicione todos os cartões em um quadro ou parede para que possam ser escolhidos e discutidos gradativamente.

O juiz deverá selecionar qual cartão será debatido. O facilitador irá ler e as equipes terão 1 minuto para realizar perguntas sobre o assunto. Em seguida serão dados 3 minutos para sejam elaboradas soluções para o problema em questão.

Ao término do tempo o facilitador pedirá que as equipes leiam suas propostas e o juiz deverá decidir de qual gostou mais.

REGRAS DO JOGO

O foco do jogo é não dar desculpas ou justificativas. É natural que a equipe tente se explicar sobre os feedbacks negativos, mas o intuito, nesse momento, não é querer saber o que aconteceu e sim que sejam levantadas sugestões para que os problemas não ocorram mais.

Então, o juiz deverá também atuar como radar das equipes. Se ele julgar que uma equipe está se justificando ou dando alguma desculpa a mesma deverá ser penalizada e deverá dizer em conjunto o nome do jogo: “NÓS NÃO TEMOS DESCULPA, TEMOS SOLUÇÃO!!”, isso poderá ocorrer em qualquer momento do jogo.

A penalização serve de quebra-gelo entre as pessoas. Lembre-se de conduzir o jogo de uma forma descontraída e dando liberdade para as equipes serem criativas em suas soluções. Uma outra sugestão é ao final de cada rodada a equipe que não tiver sua proposta escolhida também repetir o nome do jogo para dinamizar as rodadas.

O objetivo não é ter uma equipe vencedora, mas sim promover a reflexão dos times em soluções. Todas as sugestões serão recolhidas e consideradas.

Ao término do jogo reúna-se com a equipe e pegue todos os cartões de propostas de soluções. Elimine aqueles com ideias similares. Peça a equipe que cada um escolha um cartão e dê o prazo de quando entregará a solução.

Ao fechar este exercício você terá o seu plano de ação para as correções dos problemas apontados.

RESULTADO

Durante o jogo conseguimos causar o envolvimento necessário da equipe para a busca de solução quanto as avaliações negativas. Através da dinâmica conseguimos pegar as sugestões dadas e em uma rodada de refinamento estruturarmos em um plano de ação para correção dos problemas.

Isso é melhoria contínua, é o que os japoneses chamam de Kaizen!!

Além disso, é possível avaliar, na equipe, competências que poderão ser melhor desenvolvidas através de atribuições dadas ao longo do projeto.

O mais importante desta abordagem é o envolvimento e engajamento do time com as soluções apresentadas. Não discutimos culpados, nem justificativas, trabalhamos apenas com soluções neste jogo.

Espero que tenham gostado da dinâmica e caso cheguem a aplicar em suas equipes não deixe de deixar o feedback de como foi seu resultado.

Abraço

shuhari

Shu Ha Ri

Olá Pessoal

Não é novidade que a filosofia oriental influencia modelos e práticas de gestão no mundo. As artes marciais, por exemplo, ditam ensinamentos que foram difundidos em guerras e ampliados aos cenários competitivos dos negócios.

No ambiente marcial, um Sensei é aquele que treina seu discípulo a sempre buscar a evolução gradativa. Se o seu aprendiz é capaz de fazer 100 movimentos que o levem a exaustão absoluta. O Sensei será aquele que o treinará para atingir o centésimo primeiro movimento, fazendo então com que seu pupilo supere seus limites e atinja um novo estágio, superando sua condição anterior.

Esta prática é o que constantemente encontramos nos projetos. Quantos prazos recebemos que nos pareceram impossíveis ? Quantas metas improváveis não já foram alcançadas ? Quem nunca achou aquele líder de projeto um louco e depois refletiu em como ele era um visionário ?

Equipes de projetos constantemente utilizam boas práticas de desenvolvimento e também estudam diversos modelos, metodologias, frameworks e métodos com o intuito de aplicar em suas organizações o que melhor convém.

Alistair Cockburn, criador da metodologia ágil Crystal e um dos 17 gurus que assinaram o manifesto ágil é um dos grandes disseminadores do conceito oriental oriundo da arte marcial Aikido chamado Shu Ha Ri.

shuhari

Shu Ha Ri

Para entender um pouco melhor sobre este conceito na perspectiva do aikido deixo a vocês um trecho da entrevista com o Sensei Okomura, 8º dan. O Shihan Aikikai Shigenobu Okumura desempenhou um papel significante no desenvolvimento do Aikido no pós-guerra. Nesta primeira de uma entrevista de duas partes, ele fala sobre seu treinamento inicial na Manchuria e suas experiências da guerra, enfatizando a importância do conceito do “Shu, ha, ri”.

Em nossa última entrevista você nos falou sobre “Shu, Ha, Ri.” Poderia nos dizer mais sobre essas idéias

Esses são os três estágios do treinamento, isto é, manter (shu) o kata (forma), quebrar (ha) o kata e afastar-se ou libertar-se (ri) do kata.

Esses conceitos se aplicavam da mesma forma às tradicionais artes marciais Japonesas? 

Sim. Esses conceitos não se aplicam só às artes marciais como também a todos os ensinamentos no Japão. Eles são os três estágios de qualquer tipo de prática. Eu acho que disse a você dessa última vez, mas um alemão chamado Nietzsche (filósofo Friedrich Nietzsche, 1844-1900) explicou a mente humana usando metáforas e descreveu o primeiro estágio como um camelo, o segundo como o Leão e o último estágio como um bebê. No primeiro estágio, como um camelo, você deve atravessar um deserto durante uns 30 ou 40 dias, sem ter o que comer ou beber. Em outras palavras, é um período severo de testes de perseverança. Esse é o estágio do “shu”, de manter a paciência. O próximo estágio, “ha”, significa quebrar. O terceiro estágio é para alcançar o estado de ser como um bebê, que é completamente íntegro e puro. Um bebê é perfeitamente livre. As coisas são iguais no ocidente. Entretanto, Nietzsche era tido como ateu no mundo filosófico do ocidente. Não era um cristão. Entretanto, em minha opinião, ele teve um modo de pensar muito oriental. Os termos shu, ha, ri vieram de termos Zen, você sabe. Portanto, o melhor estado é ri, para separar de alguma coisa. Você vive uma vida despreconceituosa. Assim, se você é um iniciante ou está numa classe iniciante, você tem que imitar o kata com precisão. É exigido de você que repita uma forma padrão muitas e muitas vezes, o que é muito duro. Então você passa pelos níveis do Kyu e então para o nível da escala de Dans, quando terá entendido as formas do kata. Aí então é o momento de você trabalhar sua individualidade. Todo mundo, grande, pequeno ou alto, deve exibir individualidade, o que significa uma cisão do que você aprendeu anteriormente. Você continua a fazer isso até cerca do 4o ou 5o Dan. Aí você alcança um nível ainda mais alto, tornando-se verdadeiramente livre. Quando você se movimenta, você pode executar uma técnica sem tê-la pensado em sua mente. Entretanto, no caso da educação na Europa, a individualidade é enfatizada desde o começo. Há poucos casos em que as pessoas começam a aprender com Kata.

Fonte: http://www.aikikai.org.br. Confira a entrevista completa aqui.

O Shu Ha Ri é um conceito rico da filosofia oriental e tem sua síntese extraída na  avaliação de três níveis: manter, separar e transcender. Pois bem pessoal, agora vamos juntar todas essas informações para nos situarmos em uma análise pela perspectiva do nosso mundo de projetos:

Shu: as equipes neste estágio utilizam as técnicas no modelo original, seguem exatamente os preceitos a risca. Adquirem nesta fase a experiência e maturidade necessária para atingir o nível seguinte.

Ha: indivíduos nessa fase já possuem conhecimento em mais de um modelo e tendem a experimentar as abordagens buscando o melhor resultado possível em seus projetos. Neste nível temos as aplicações dos modelos híbridos.

Ri: No último nível os indivíduos estão em um estágio de maturidade onde são capazes de criar seus próprios modelos e técnicas. Possuem experiência e vivencia que possibilitam aplicar boas práticas criadas baseadas nos sucessos e aprendizados dos projetos vividos.

A filosofia deste conceito busca a evolução de equipes quanto a auto-percepção e também a avaliação de times em uma visão Top Down. Imaginem vocês a desenvolverem equipes que encontram-se no estado Shu até atingirem o Ri. É um longo percurso a ser trilhado possibilitando diversos modelos de desenvolvimento de pessoas quanto a técnicas e habilidades pessoais.

Este conceito é trabalhado de formas diversas e aprofundadas por Alistair em consultorias, cursos e livros aplicados em grandes empresas. Em seu site ele expõe relatos de grandes empresas que adotaram a filosofia.

Espero que tenham ficado curiosos sobre o assunto e que busquem conhecer um pouco mais. Agora que você já está familiarizado com o Shu Ha Ri consegue dizer em qual dos três níveis está ?

Abraço!

C1- Simulação

A magia da simulação

Olá Pessoal

Fala-se muito da importância de se prever impactos da mudança e de se otimizar processos com o intuito de reduzir custos ou tempo de execução. O curioso é que não vemos com tanta frequência o discurso da busca pela simulação dos processos para análise de cenários para melhor tomada de decisão antes da transformação ocorrer.

Imagine você a ter que reduzir custos utilizando apenas o seu feeling empresarial. Poderá realizar essa atividade com maestria durante algumas oportunidades, mas pense o quão arriscado está sendo atuar na mudança de processos sem antes ter a oportunidade de simular cenários e descobrir o que seria o melhor para sua organização.

Neste post vou apresentar a vocês um exemplo muito simples, mas que trará a dimensão do poder desta abordagem.

Vamos analisar um processo de aprovação de currículo. Não trabalharemos com nada complexo pois o foco é apenas mostrar um único exemplo da utilização da simulação. Entendendo a abordagem você poderá seguir por caminhos mais detalhados e se quiser estarei nos comentários para interagir e criar posts com esse intuito caso exista feedback para o propósito.

As Is - Aprovação de Curriculo - exemplo

As Is – Aprovação de Curriculo – exemplo

O processo acima aborda uma análise de currículo. Vamos fazer a leitura em conjunto instanciando processo. Acompanhe o percurso do token na descrição:

O processo inicia com o candidato realizando o envio do currículo. O mesmo é recebido e separado para avaliação, esta atividade é realizada por uma secretaria. A mesma analisa se o currículo enviado é da área de TI ou da área Administrativa. Neste momento de triagem o token pode divergir para uma das duas áreas. Vamos analisar quando a divergência segue o caminho:

  • TI: O Gerente da TI realiza uma análise do currículo, esta análise resulta em mais duas novas possibilidades. No caminho feliz, o token segue com o currículo aprovado e o gerente realiza o agendamento da prova técnica do candidato e finaliza o processo. Caso o currículo não seja aprovado o processo é finalizado com uma mensagem de reprovação.

  • Administrativo: O Gerente do Administrativo faz a análise do currículo do candidato. Esta ação resulta em duas novas possibilidades. Se o currículo for aprovado o gerente agenda uma entrevista e finalizado o processo. Caso o currículo não seja aprovado o processo é finalizado com uma mensagem de reprovação.

Bem, agora que já entendemos o processo vamos avaliar algumas informações importantes.

Você já deve ter mapeado quem são os participantes, então vamos aqui revisa-los, porém acrescento algumas informações que serão importantes para nossa simulação. São eles:

Participantes

Qtd Custo por Hora
Candidato

500

0 R$/h

Secretária

1

46 R$/h

Gestor de TI

1

159 R$/h

Gestor de Admin

2

159 R$/h

Excelente. Agora temos bem claro quem são nossos participantes, a sua quantidade e quanto custa a hora de cada um. Estamos prontos para simular nosso processo de avaliação de currículo.

Iremos analisar dois aspectos neste exemplo, custo e utilização do recurso. É possível considerar outras situações e extrair mais informações para tomada de decisão, mas vamos nos manter nestes dois únicos pontos. Vejamos então o resultado da nossa simulação:

C1- Simulação

C1- Simulação do As Is

Para este cenário estabeleci a duração das atividades e o percentual dos gateways nos pontos de divergência. Em nosso exemplo iremos nos ater em dois pontos, manteremos a mesma configuração para as mudanças de cenário.

Resource Utilization Total fixed cost Total unit cost Total cost
Secretaria

8,33%

0

R$2.760,00

R$2.760,00
Avaliador Adm

5,20%

0

R$11.897,97

R$11.897,97
Avaliador TI

2,55%

0

R$2.914,47

R$2.914,47
Candidato

0,01%

0

R$- R$-
Custo Total R$17.572,44

O resultado da nossa simulação nos dá uma informação importante. Quantos de nós em nossos processos e rotinas, já tão conhecidas e corriqueiras, sabemos evidenciar quanto nos custa o passo a passo que seguimos. Sabemos responder com clareza ou estimar de forma contundente quanto custa nosso processo ?

A simulação nos possibilita esta resposta assim como a identificação dos gargalos em nosso processo!!

Excelente, estamos começando a entender o poder que este recurso nos dá. Agora, você já deve ter percebido que um processo tão simples está tendo um custo elevado. Você conseguiu identificar quem poderia estar tornando o processo tão caro ?

É isso mesmo, os nossos avaliadores são gerentes e possuem o valor da hora elevada. O nosso processo não está otimizando o tempo destes recursos e com isso está se tornando caro. Então, precisamos otimizar as atividades realizadas por estes recursos para que consigamos um custo menor nessa execução.

Aposto como você já está ai cheio de ideias para melhorar este processo e reduzir este custo. Se quiser deixe a sua ideia de melhoria nos comentários para debatermos posteriormente.

Então vamos ao nosso To Be. Veja só, nós mapeamos nosso processo. Desenhamos e analisamos. Identificamos pontos de melhoria e agora iremos desenhar um processo proposto. Veja abaixo a seguinte proposta:

To Be - Aprovação de Curriculo - exemplo

To Be – Aprovação de Curriculo – exemplo

Acompanhe. Nesta proposta fizemos as seguintes alterações no processo.

A escolha quanto a área ficou com o candidato, que em nosso exemplo não nos gera custo. O mesmo escolhe a área e então encaminha o currículo. Perceba que eliminamos a triagem feita pela secretaria. O direcionamento é feito diretamente ao gestor responsável.

A última alteração que foi realizada é quanto ao executor das tarefas de agendamento que passaram a ser feitas pela secretaria, ou seja, os gestores passaram apenas a avaliar os currículos.

E então, será que estas pequenas alterações renderam algum resultado ?

To Be - c1 - Simulação

To Be – Simulação

Vamos analisar a simulação do nosso processo proposto. Veja:

Foram mantidas as mesmas parametrizações de proporção nos gateways e duração das atividades. Deste novo cenário obtivemos o seguinte resultado:

Resource Utilization Total fixed cost Total unit cost Total cost
Secretaria

4,93%

0

R$1.633,00 R$1.633,00
Avaliador Adm

3,48%

0

R$7.977,03 R$7.977,03
Avaliador TI

1,37%

0

R$1.562,97 R$1.562,97
Candidato

0,01%

0

R$- R$-
Custo Total R$11.173,00

Sensacional. Percebam que com nossas alterações, mínimas, no processo conseguimos uma redução de R$ 6.399,44, ou seja, 36% do custo. Isso foi possível pois reduzimos a carga de trabalho nos recursos que possuem as horas mais caras no processo.

Nós mapeamos o processo, desenhamos o modelo As Is. Analisamos e com base em uma fundamentação tornou-se possível propor um cenário de melhorias, To Be.

Conseguimos então propor mudanças e mensurar os impactos das mesmas sem partirmos para implementação real. Apenas simulando o processo conseguimos identificar custos, gargalos, sugerir melhorias, analisar possibilidades, medir impactos, quantificar e justificar o retorno da mudança proposta em uma escala mínima de um pequeno exemplo.

A simulação é sem dúvida um recurso poderoso no processo de mudança e melhoria contínua. Espero que tenha ficado claro para você e que tenha despertado o seu interesse em tirar proveito deste recurso.

Abraço!

The Bug Hunter

Olá Pessoal

Neste post irei explicar um pouco sobre o processo The Bug Hunter que criei para ajudar na qualidade do produto entregue ao cliente. Vamos tratar sobre o modelo e algumas boas práticas, mas antes quero deixar claro os resultados obtidos em uma equipe!

Motivação e Resultados:

Em um cenário onde não se possui uma equipe de testes, na reta final da entrega de um projeto, rodamos o processo e tivemos como resultados alguns números interessantes.

  • Em uma semana de competição foram identificados 25 bugs;
  • Dos 25 listados foram corrigidos durante a competição 21 bugs;
  • Os bugs foram encontrados e corrigidos, também, por membros que não faziam parte do time de desenvolvimento do projeto e estavam alocados para outras entregas, que no seu tempo livre participavam da competição;
  • A diferença do primeiro para o segundo colocado foi de apenas 3 pontos, sendo que o segundo colocado fazia parte de outro projeto;
  • O time se integrou e os competidores passaram a olhar com mais detalhes o projeto. O time ficou motivado e não tratou do desafio como trabalho, mas como um jogo que era divertido jogar.
  • A integração do time só ocorreu de fato quando o gestor da área resolveu participar e começou a pontuar. Quando foi disparado o e-mail para o setor com a pontuação do gestor o time reagiu. Este foi um fator chave para o sucesso da competição e neste ponto podemos parar na seguinte reflexão:

Quando um líder quer que seus liderados façam algo. O líder vai lá e faz primeiro, desta forma seus liderados o seguirão, não por uma ordem, mas por um exemplo.

O que é o The Bug Hunter?

Como o nome em si sugere trata-se de um processo que deve ser encarado como uma competição, onde o vencedor é aquele que mais encontra e corrige bugs de um determinado projeto. A ideia é simples e os resultados também.

Em que tipo de equipe é viável rodar este processo?

Você pode ter sua equipe organizada em um “Testers Team”, um time responsável por verificar todas as atividades previstas do desenvolvimento do seu projeto, ou simplesmente não possuir essa estrutura e rodar o modelo com seu time padrão multitarefa e multidisciplinar, isso não irá importar pois a questão além de tudo é motivacional e você poderá extrair resultados satisfatórios em ambos os casos.

Em que fase do meu projeto devo aplicar o The Bug Hunter?

Inicialmente você deve analisar como estão sendo feitas suas entregas junto ao cliente. Se você está trabalhando de forma incremental como entregas parciais cabe então para cada uma dessas fases a aplicação da competição. É interessante realizar a competição com o prazo de 1 semana para a entrega do produto completo ou modulo.

Quem deve participar do The Bug Hunter?

A beleza do jogo está em abrir a competição para todo o setor, independente de ser desenvolvedor da linguagem dominante do projeto ou de fazer parte do time de desenvolvimento, alias conseguir o envolvimento daqueles que não fazem parte do time que está codificando é o grande trunfo da integração entre todos para a competição.

Como faço para o time avaliar o projeto?

O ideal é que você disponibilize no seu servidor web o projeto apontando para o seu ambiente de teste. Dessa forma todos poderão participar, independente de terem participado ou não do desenvolvimento. Outra opção é liberar o fonte do projeto para todos, para que possam baixar e rodar localmente em suas máquinas, mas atenção, fique atento nos commits e controle “quem está fazendo, o que, e aonde” para evitar que ocorram conflitos no código bem as vésperas de disponibiliza-lo ao cliente.

Como faço o controle do The Bug Hunter?

Você pode realizar o controle através de uma simples planilha de excel. Lembre-se que quem quer fazer não precisa da ferramenta perfeita, precisa da ideia e da capacidade de gerir. É interessante que durante todos os dias de competição você encaminhe um e-mail para todo o setor atualizando os bugs encontrados e o ranking atual. Isso ajudará a estimular quem já participa e quem apenas está achando curiosa a competição.

Que premiação devo entregar?

Você mais do que ninguém conhece a realidade do seu setor e sabe muito bem as coisas que deixarão seu time animado. A única coisa que não recomendo é que se dê dinheiro como retorno para a competição, isso não criará uma cultura positiva e lembre-se que este modelo é apenas uma forma de motivar que seu time faça melhor ainda um trabalho que já é obrigação. Você pode adotar turnos ou dias de folga, pizzas, rodízio em algo. Pense sempre em uma forma de integrar todos e que seja positiva para todo o ambiente.

O que preciso ter para iniciar o The Bug Hunter?

Como premissa básica, possuir seu projeto no estágio mais próximo de ser disponibilizado ao cliente, isso é algo que você, que conhece bem o escopo, poderá determinar.

  • Você deverá determinar a duração da competição, quando vai iniciar e terminar.
  • Qual será a premiação para o vencedor.
  • Como será o regulamento, quais as regras da competição.

Sanadas estas questões inicias já podemos partir para uma visão mais prática do processo.

Definição de Intervalo, Pontuação, Premiação e Regulamento

Vou exemplificar para vocês como poderia ser um modelo da planilha para o controle:

Imagem

No exemplo acima montei uma tabela me baseando em 10 linhas, informando os pontos chaves para começar a disputa. Informei a duração e estabeleci das regras.

  • Vamos entender cada linha:

Linha 1: Defini para o processo The Bug Hunter o projeto que será avaliado para a competição;

Linha 2: Defino em uma coluna os Tipos de Bug que irão pontuar e na outra os detalhes do regulamento.

Linha 3: Defino na primeira coluna que todo Bug de Visão valerá 1 ponto e na coluna ao lado o intervalo que será feita a avaliação;

Linha 4: Defino na primeira coluna o segundo tipo de bug, sendo esse de Negócio com peso de 3 pontos e ao lado já informo a premiação, sendo que o campeão ganhará uma pizza;

Linha 5: Defino o ultimo tipo de bug na primeira coluna, sendo Bug de DAO para persistências de dados, valendo também 3 pontos. Ao lado continuo dando ênfase para a premiação;

Linha 6: Defino neste ponto de forma clara o intervalo, que dia exato inicia e que dia exato termina.

Linha 7: Estabeleço o primeiro ponto de como funciona. Neste momento defino como farei o controle e como o competidor deve proceder para pontuar, já valorizando os pontos para aquele que encontra e, principalmente, corrige o problema;

Linha 8: Estabeleço neste momento o segundo ponto de funcionamento, e neste instante dou a possibilidade de qualquer pontuar, bastando apenas listar os problemas encontrados;

Linha 9: Neste ponto elimino os “espertinhos” que queiram pontuar uma vez para cada bug encontrado e para cada um desses bugs ganhar novos pontos efetuando em um segundo momento as correções;

Linha 10: Na última linha deixo claro quem pode participar da competição.

Controle e Acompanhamento de Resultados

Agora vamos a um exemplo de como seria o acompanhamento e controle.

Imagem

A primeira linha da tabela é o cabeçalho com as informações que devem ser preenchidas.

Repare o Seguinte ponto!

Na linha 2 o Thor encontra o Bug e ele mesmo corrige, por ser um erro de Negocio valia 3 pontos, como foi ele mesmo que corrigiu ganhou os 3×2 ficando com 6 pontos. Se ele apenas tivesse encontrado o erro ficaria apenas nos 3 e o bug ficaria em aberto para que outro pudesse corrigir e pontuar.

Na ultima linha o Cap. America encontra um bug de Visão e ganha 1 ponto, mas ele não corrige e deixa em aberto. O Thor chega e corrige e ganha o ponto do “Cap.America x 2”, ou seja, 1×2 ficando com 2 pontos e passando a frente do Cap. America que por ter apenas encontrado ficou com 1. Dessa forma estimula-se e encoraja-se a correção.

É interessante categorizar os competidores por cores, isso facilita na contagem dos pontos.

Se você chegou até o final deste extenso post saiba que trata-se de uma ideia simples e não original que foi apenas tratada com seriedade e organizada através de uma visão de processo. Se gostou do modelo sinta-se a vontade para conversar e aplicar no seu setor e se puder me retorne com o resultado que conseguiu, seja ele positivo ou negativo.

Valeu pessoal até a próxima.

Abraço!

super-profissional

A Bala de Prata

Olá Pessoal

Trataremos neste post sobre uma reflexão, algo que é obvio mas que merece dois segundos de atenção.

Pois bem, é comum para o critério de seleção toda empresa constatar que um profissional extraordinário, de TI, pode ser a melhor aquisição para o setor, mas será mesmo?

Ao longo de alguns processos seletivos pude avaliar alguns candidatos e perfis. Não é fácil achar um profissional que realmente fuja a curva, talvez seja essa a grande tentação para que um indivíduo assim “tenha que fazer parte da sua equipe”. Mas é preciso ressaltar muito bem o conceito de equipe antes de incorporá-lo.

Não é raro profissionais bons não se adequarem a uma equipe e ao modelo de processo da empresa. Estou falando de fato de casos excepcionais, de profissionais que realmente são diferenciados, se você já teve a oportunidade de avaliar alguém assim talvez entenda do que falo. Profissionais assim tem um leve ar egocêntrico em sua personalidade e são menos suscetíveis a aderência de modelos e padrões internos. Este individuo é alguém exponencial, capaz de produzir muito, e sem ajuda. É daqueles que você entrega um projeto e ele resolve sozinho. Basicamente o sonho de consumo de qualquer Direção distante de boas práticas e uma visão além. Mas cá entre nós, é tentador um super-profissional assim, pensem na redução custo. Você tem 3 pelo preço de 1. Sensacional. Será mesmo?

Ter alguém que produz muito, mas produz só, é benéfico para um setor?

Um projeto de um homem só merece parabéns ou será que tende a um alerta para a gestão, afinal o conhecimento compartilhado é um dos fatores de sucesso para a evolução de uma equipe, as práticas ágeis fomentam essa ideia.

É claro que o “super-profissional” pode ser completamente moldável ao seu processo interno, a questão não é essa. O questionamento está no “deposito de fé” sobre aquele único profissional. Por mais incrível que seja um único membro não pode ser considerado a “bala de prata”. Lembre-se que você gerencia recursos e a integração destes pode ser um fator diferencial.

Uma empresa que cria ilhas e mitos dentro de seu próprio setor cria também “pais de projetos”, ou seja, após sua super entrega realizada com custo bastante reduzido, afinal você utilizou sua bala de prata, você passa a ter uma única pessoa a oferecer suporte e manutenção de trabalho, um único conhecedor das regras, um único responsável. Não me entendam errado, é perfeitamente possível outros conhecerem e se integrarem após a entrega, mas até lá você precisa criar a ponte e os novos membros terão que fazer a travessia. E falo de uma ponte de madeira, no melhor estilo Indiana Jones.

Note que a partir deste momento você já passa a ser refém de um profissional, a saída dele pode ser prejudicial para o suporte e evolução do projeto.

Quando você deixou claro para sua equipe que apenas a sua bala de prata resolveria a situação, criou também um mito de complexidade, psicologicamente você traz aos membros menos experientes algo lógico.

Se a “bala de prata” resolve qualquer problema complexo sozinho e se a bala de prata fez o “Projeto A” sem a ajuda de ninguém. Logo o “Projeto A” é extremamente complexo.

 

Esse mito causa na sua equipe uma cultura ruim e a medida que você for renovando seu quadro esse mito será propagado e você terá então semeado o mito do super desenvolvedor, o mito do projeto que ninguém consegue entender, o mito que só “indivíduo A” pode resolver.

Você terá desestruturado completamente sua equipe sobre o conceito de equipe, o conceito de time.

Enfim, não me entendam errado, filosoficamente todos estes pontos são pautados em experiências vivenciadas em um respectivo modelo de processos, mas que acredito que possam servir, de alguma forma, como reflexão sobre determinados contextos.

Por fim quero apenas terminar ressaltando que não é interessante criar “balas de prata” e sim trazer um pilar mais solido para um alicerce já montado.

Abraço!