E vem aí a sessão de promessas para o ano que vem.
Se você está na dúvida do que prometer, aqui seguem algumas sugestões:
PROMETO...
... aprender a dizer "não".
... parar por alguns instantes por dia e reavaliar o que foi feito e o que deve ser feito.
... disciplinar meus funcionários, isto é, dar o que eles precisam e não o que eles querem.
... aprender a dizer "sim".
... me focar bem no trabalho, durante o expediente, deixando as distrações de lado.
... ter mais bom-humor no dia-a-dia.
... resolver mais problemas, mesmo quando eles parecem impossíveis.
... parar de reclamar e me esforçar mais.
... me esforçar mais, mas também viver a vida!
... adotar padrões de qualidade para tudo o que faço.
... falar menos e fazer mais.
... falar menos e escutar mais.
... falar mais.
... dar atenção especial à minha equipe.
... incentivar, orientar e elogiar minha equipe, quase sempre.
... disciplinar, orientar e repreender minha equipe, quando necessário!
... fazer o que deve ser feito e não aquilo que eu acho que deve ser feito.
... fazer o que deve ser feito com qualidade!
... fazer o que deve ser feito e um pouco mais, caso seja vontade do cliente (mesmo que de forma subjetiva).
... viver mais! Com paixão por tudo aquilo que faço!
Ufa!
Essas são minhas sugestões. Algumas irei aplicar, outras deixei como exemplo pra vocês :)
FELIZ 2008!
sexta-feira, 28 de dezembro de 2007
quinta-feira, 27 de dezembro de 2007
Ambiente multi-tarefas..... bom ou ruim?
Salve, senhores e senhoritas ;)
Gostaria hoje de abordar um assunto que TODOS nós, invariavelmente, passamos, já passamos ou iremos passar: a convivência em um ambiente multi-tarefas.
Mas que diabo é isso: ambiente multi-tarefas?
Nos primórdios da computação, o sistema operacional que a grande maioria utilizava era o MS-DOS. Não conhece? Digite "cmd" no seu "executar" do Windows e você verá o DOS simulado :)
A vida era procedural, sequencial, monótona. Não existia a internet ainda... quer dizer, até existia (eu cheguei a usar um sistema de internet que era baseado em "DOS" da UFRGS), lá nos primórdios de 1994-1995.
Se você queria editar um texto, você apenas editava o texto. Se queria jogar, só jogava. Se queria programar, só programava. Se queria usar a internet, só usava um serviço seja de http, gopher - nem sei explicar o que é isso, hoje em dia haha - ou até mesmo chats.
Sim, muitos dirão que em 1994-1995 já existia o Windows. Mas notem que estou contextualizando a coisa! ;)
O Windows veio com o conceito de "multi-tarefas". Agora, se você fosse compilar seu código, você podia ficar jogando paciência, lendo as notícias de algum site jurássico ou então editando algum texto! Era o fim do "nada para fazer". O Windows não foi o primeiro sistema operacional multi-tarefas. Mas foi o que popularizou o conceito.
Agora pensem: a geração de trainees, estagiários e júniores cresceram nessa época. Eu tenho 50% disso no sangue, eu diria. A informação, para eles, se tornou algo banal, de fácil acesso. Criou-se nas empresas, então, o nosso ambiente multi-tarefas!
O ambiente onde todos os funcionários não conseguem se focar em uma coisa só. Eles programam, fazem a leitura das notícias das celebridades, mandam emails, falam no MSN, olham fotos e ainda encontram tempo para conversar com o colega do lado - sobre futebol, trabalho, política e futilidades. Tudo isso em um intervalo de 1 ou 2 minutos!!!!
Notem uma coisa em comum nas atividades citadas acima... 99% delas envolvem INTERNET. Agora vem a questão principal do tópico: a internet no trabalho é prejudicial ou é uma ferramenta poderosa e indispensável?
O meu trabalho é a ilustração caricata e perfeita do céu e o inferno nessa questão. O meu chefe, PhD e de grande capacidade profissional (principalmente técnica) bate o pé em todas as reuniões para que nós cortemos 100% da internet. Usaríamos a Internet, no melhor dos casos, só na fase de concepção/pesquisa do projeto. Depois disso "Unable to connect to host" pra todos!
Eu já sou da ala do "meião", ou seja, a internet É sim uma ferramenta poderosa e imprescindível. Mas ao mesmo tempo é o maior vilão e rouba-tempo que existe no mercado. Então é simples: instala-se um sistema para monitorar e repreender aqueles que abusarem. MSN, por exemplo, pode ser abolido. Podemos usar algum programa tipo o Skype que pouca gente usa para bate-papo, apenas para nos comunicarmos no trabalho (com uma conta de empresa para cada).
O grande "X" da questão disso é que é monitorar apenas não ajuda. Vocês sabem como é o ser humano... não cansa de achar formas para burlar o sistema. Então basta olhar o relatório, identificar os abusos e repreender os envolvidos. De preferência, nas primeiras vezes, de forma pública. Isso inibe o abuso, não tenho dúvidas. E ao mesmo tempo, a Internet fica disponível para o uso do "bem".
Talvez uma forma mais simpática ainda é estipular intervalos para "descanso". Algo como das 16h-16h20 TUDO é liberado para que a pessoa faça o que quiser: bater papo, jogar, etc. É a "hora do descanso". Não sei se existem programas que habilitem isso, mas seria uma forma bem legal também de usar.
O fato é que o ambiente multi-tarefas que existe na maioria das empresas geralmente não é benéfico. No mundo do desenvolvimento de tecnologia é pior ainda, pois a grande maioria das tarefas envolvem grande concentração e raciocínio. Como raciocinar tendo que se preocupar com a resposta da "Fernandinha Gata" no MSN (ainda mais se for uma gata mesmo!) ou na ansiedade em baixar todas as fotos de alguma atriz famosa?
E você, caro leitor, comente sobre suas experiências e seus pensamentos nesse post! Quem sabe algum de nós tem alguma solução bacana para resolver essa difícil equação?
Um grande abraço!
Gostaria hoje de abordar um assunto que TODOS nós, invariavelmente, passamos, já passamos ou iremos passar: a convivência em um ambiente multi-tarefas.
Mas que diabo é isso: ambiente multi-tarefas?
Nos primórdios da computação, o sistema operacional que a grande maioria utilizava era o MS-DOS. Não conhece? Digite "cmd" no seu "executar" do Windows e você verá o DOS simulado :)
A vida era procedural, sequencial, monótona. Não existia a internet ainda... quer dizer, até existia (eu cheguei a usar um sistema de internet que era baseado em "DOS" da UFRGS), lá nos primórdios de 1994-1995.
Se você queria editar um texto, você apenas editava o texto. Se queria jogar, só jogava. Se queria programar, só programava. Se queria usar a internet, só usava um serviço seja de http, gopher - nem sei explicar o que é isso, hoje em dia haha - ou até mesmo chats.
Sim, muitos dirão que em 1994-1995 já existia o Windows. Mas notem que estou contextualizando a coisa! ;)
O Windows veio com o conceito de "multi-tarefas". Agora, se você fosse compilar seu código, você podia ficar jogando paciência, lendo as notícias de algum site jurássico ou então editando algum texto! Era o fim do "nada para fazer". O Windows não foi o primeiro sistema operacional multi-tarefas. Mas foi o que popularizou o conceito.
Agora pensem: a geração de trainees, estagiários e júniores cresceram nessa época. Eu tenho 50% disso no sangue, eu diria. A informação, para eles, se tornou algo banal, de fácil acesso. Criou-se nas empresas, então, o nosso ambiente multi-tarefas!
O ambiente onde todos os funcionários não conseguem se focar em uma coisa só. Eles programam, fazem a leitura das notícias das celebridades, mandam emails, falam no MSN, olham fotos e ainda encontram tempo para conversar com o colega do lado - sobre futebol, trabalho, política e futilidades. Tudo isso em um intervalo de 1 ou 2 minutos!!!!
Notem uma coisa em comum nas atividades citadas acima... 99% delas envolvem INTERNET. Agora vem a questão principal do tópico: a internet no trabalho é prejudicial ou é uma ferramenta poderosa e indispensável?
O meu trabalho é a ilustração caricata e perfeita do céu e o inferno nessa questão. O meu chefe, PhD e de grande capacidade profissional (principalmente técnica) bate o pé em todas as reuniões para que nós cortemos 100% da internet. Usaríamos a Internet, no melhor dos casos, só na fase de concepção/pesquisa do projeto. Depois disso "Unable to connect to host" pra todos!
Eu já sou da ala do "meião", ou seja, a internet É sim uma ferramenta poderosa e imprescindível. Mas ao mesmo tempo é o maior vilão e rouba-tempo que existe no mercado. Então é simples: instala-se um sistema para monitorar e repreender aqueles que abusarem. MSN, por exemplo, pode ser abolido. Podemos usar algum programa tipo o Skype que pouca gente usa para bate-papo, apenas para nos comunicarmos no trabalho (com uma conta de empresa para cada).
O grande "X" da questão disso é que é monitorar apenas não ajuda. Vocês sabem como é o ser humano... não cansa de achar formas para burlar o sistema. Então basta olhar o relatório, identificar os abusos e repreender os envolvidos. De preferência, nas primeiras vezes, de forma pública. Isso inibe o abuso, não tenho dúvidas. E ao mesmo tempo, a Internet fica disponível para o uso do "bem".
Talvez uma forma mais simpática ainda é estipular intervalos para "descanso". Algo como das 16h-16h20 TUDO é liberado para que a pessoa faça o que quiser: bater papo, jogar, etc. É a "hora do descanso". Não sei se existem programas que habilitem isso, mas seria uma forma bem legal também de usar.
O fato é que o ambiente multi-tarefas que existe na maioria das empresas geralmente não é benéfico. No mundo do desenvolvimento de tecnologia é pior ainda, pois a grande maioria das tarefas envolvem grande concentração e raciocínio. Como raciocinar tendo que se preocupar com a resposta da "Fernandinha Gata" no MSN (ainda mais se for uma gata mesmo!) ou na ansiedade em baixar todas as fotos de alguma atriz famosa?
E você, caro leitor, comente sobre suas experiências e seus pensamentos nesse post! Quem sabe algum de nós tem alguma solução bacana para resolver essa difícil equação?
Um grande abraço!
quarta-feira, 26 de dezembro de 2007
Resenha do livro "Transformando suor em ouro"
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Este é um livro bem legal, também. Pode afastar muitas pessoas que pensam se tratar de um livro de "voleibol" ou de "esporte". É o famoso livro do Bernardinho, onde ele traça sua trajetória e faz paralelos com o mundo empresarial. Traz conceitos criados por ele como a "Roda da Excelência" e a "Escala de Valores".
Eu, como gosto de esporte (mas ando preguiçoso para praticá-los, vale ressaltar - pra ver se tomo juízo) tive uma leitura bem divertida com este livro. Tive curiosidade em saber como que um ex-jogador reserva conseguiu transformar a grande maioria dos times em que treinou em potências do esporte (principalmente o volei masculino).
O livro traz ensinamentos bem bacanas sobre alguns procedimentos que ele tomou durante seu treino (não, ele não fala nada sobre o episódio Ricardinho... embora ele seja bastante citado no livro - em 99% das vezes de forma positiva!).
O conceito principal do livro é pregar que é preciso suar muito e trabalhar mais ainda para obter seus resultados. E para motivar sua equipe, mesmo que esta esteja num nível de jogadores de seleção brasileira que já conquistaram tudo, deve-se esticar sempre a corda para deixá-los em uma zona desconfortável sempre. Entende-se por "zona desconfortável" a idéia de criar situações que façam com que sua equipe nunca pense que agora é "sentar e relaxar".
Algumas passagens são bem engraçadas, como a vez em que após a conquista de um título, ele fez com que os jogadores treinassem no dia seguinte, sem que fossem avisados sobre isso (eles achavam que era uma reunião apenas).
A roda da excelência, o Bernardinho que me desculpe, mas eu não consigo imaginar que ele consiga monitorar todos os conceitos que ele prega. A roda é uma adaptação do ciclo PDCA. São 11 conceitos como "liderança", "trabalho em equipe", "preserverança", "cumplicidade", etc.
Já a escala de valores é um "plus" da sua roda, com alguns novos conceitos. Mas tudo fica mais ou menos na mesma: foco na equipe.
Apesar do livro tentar, eu acho difícil traçar este paralelo que ele tentou fazer entre o volei e o mundo empresarial. O livro é bom, como eu disse. Tem alguns conceitos e ensinamentos (muitos deles implícitos) que valem a pena ler e pensar a respeito. Mas se você procura algo mais imediatista, algo como um "how to", sugiro o livro que citei abaixo "O gerente-minuto".
BOM PARA: quem gosta de ler biografias, sobre esportes, com o extra de que estará lendo sobre motivação e gestão de pessoas.
RUIM PARA: quem não gosta de ler ou quem quer um "how to".
RECOMENDADO PARA: Gestores de pessoas, que não pretendem encontrar na leitura uma receita de bolo.
AVALIAÇÃO FINAL: 3,5/5.
Este é um livro bem legal, também. Pode afastar muitas pessoas que pensam se tratar de um livro de "voleibol" ou de "esporte". É o famoso livro do Bernardinho, onde ele traça sua trajetória e faz paralelos com o mundo empresarial. Traz conceitos criados por ele como a "Roda da Excelência" e a "Escala de Valores".
Eu, como gosto de esporte (mas ando preguiçoso para praticá-los, vale ressaltar - pra ver se tomo juízo) tive uma leitura bem divertida com este livro. Tive curiosidade em saber como que um ex-jogador reserva conseguiu transformar a grande maioria dos times em que treinou em potências do esporte (principalmente o volei masculino).
O livro traz ensinamentos bem bacanas sobre alguns procedimentos que ele tomou durante seu treino (não, ele não fala nada sobre o episódio Ricardinho... embora ele seja bastante citado no livro - em 99% das vezes de forma positiva!).
O conceito principal do livro é pregar que é preciso suar muito e trabalhar mais ainda para obter seus resultados. E para motivar sua equipe, mesmo que esta esteja num nível de jogadores de seleção brasileira que já conquistaram tudo, deve-se esticar sempre a corda para deixá-los em uma zona desconfortável sempre. Entende-se por "zona desconfortável" a idéia de criar situações que façam com que sua equipe nunca pense que agora é "sentar e relaxar".
Algumas passagens são bem engraçadas, como a vez em que após a conquista de um título, ele fez com que os jogadores treinassem no dia seguinte, sem que fossem avisados sobre isso (eles achavam que era uma reunião apenas).
A roda da excelência, o Bernardinho que me desculpe, mas eu não consigo imaginar que ele consiga monitorar todos os conceitos que ele prega. A roda é uma adaptação do ciclo PDCA. São 11 conceitos como "liderança", "trabalho em equipe", "preserverança", "cumplicidade", etc.
Já a escala de valores é um "plus" da sua roda, com alguns novos conceitos. Mas tudo fica mais ou menos na mesma: foco na equipe.
Apesar do livro tentar, eu acho difícil traçar este paralelo que ele tentou fazer entre o volei e o mundo empresarial. O livro é bom, como eu disse. Tem alguns conceitos e ensinamentos (muitos deles implícitos) que valem a pena ler e pensar a respeito. Mas se você procura algo mais imediatista, algo como um "how to", sugiro o livro que citei abaixo "O gerente-minuto".
BOM PARA: quem gosta de ler biografias, sobre esportes, com o extra de que estará lendo sobre motivação e gestão de pessoas.
RUIM PARA: quem não gosta de ler ou quem quer um "how to".
RECOMENDADO PARA: Gestores de pessoas, que não pretendem encontrar na leitura uma receita de bolo.
AVALIAÇÃO FINAL: 3,5/5.
Confira esta resenha no meu novo blog:
Resenha do livro: "O gerente-minuto"
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Este livro fez parte do pacotão de livros que eu comprei, meses atrás. Vi a capa e lembrei que já havia ouvido falar sobre isso e comprei. Mas confesso que foi meio que a "rodo", sem pensar muito.
Fui para a praia neste primeiro feriadão (o de Natal) e decidi levar um livro pra ler. Escolhi este... poucas páginas, "uma leitura rápida" pensei. Doce engano meu!!
O livro "O gerente-minuto" é antigo, vi que sua primeira edição foi de 1981 (me corrijam se eu estiver errado) e também que já gerou, obviamente, uma série de outros livros a respeito.
Vamos ao principal: gostei MUITO do livro. Muito mesmo!! Bem objetivo, fácil e gostoso de ler. São 100 páginas, sendo que algumas páginas o texto não ocupa nem metade da página! Eu diria que quem gosta de ler, vai finalizar ele em uma tarde. Quem não gosta de ler, vai finalizar em duas tardes!
O livro conta de forma romanceada a estória de um gerente que decide buscar informações com um gerente de uma grande empresa, que é conhecido pela sua capacidade de obter resultados incríveis. Este gerente é o chamado "gerente-minuto", que o personagem principal vai desvendando durante o livro.
O conceito da "gerência-minuto", quando li na aba, me pareceu um tanto "auto-ajuda" demais: reservar um minuto do seu dia para avaliar seu trabalho, sua equipe, etc.
Mas quando entendi o conceito real disso, percebi o quanto atual e verdadeiro é o que o livro prega. São três conceitos:
Objetivos-minuto, elogios-minuto, repreensões-minuto. O sufixo minuto serve para indicar que tudo isso deve ser abordado no menor tempo possível, sem rodeios e com a maior antecedência possível.
Basicamente o livro prega a arte de delegar. Treinar seus subordinados para que eles se tornem independentes. O livro até traz um fluxograma bem interessante, no final, para entendermos o conceito. Vou tentar descrever:
+ Estabeleça sempre os "objetivos-minuto" com seus subordinados, de forma objetiva e clara. Ele recomenda que tudo deve caber em uma folha branca, no máximo 240 palavras.
+ Procure flagrar seus subordinados (especialmente os que estão começando) fazendo coisas certas ou "quase-certas" e aplique o "elogio-minuto".
+ Caso flagrar seu subordinado fazendo algo errado ou que necessite intervenção, aplique a "repreensão-minuto" o quanto antes.
O livro descreve de uma forma bem clara e objetiva as técnicas para aplicar estes três conceitos... eu confesso que não quero escrever aqui pois recomendo que vocês leiam mesmo o livro. Vale a pena, principalmente por ser de fácil absorção, mesmo para os que odeiam ler.
Ah, pra finalizar: quem pretende trabalhar com SCRUM, leia este livro!!! Vocês verão conceitos bem interessantes para utilizarem no dia-a-dia!!
BOM PARA: aquele gerente que precisa de orientação para lidar com seus subordinados.
RUIM PARA: quem não gosta de gente, ou quem acha que o problema são as pessoas.
RECOMENDADO PARA: Gerentes e executivos, juniores ou seniors. Ou então para quem tem subordinados. Aliás, é recomendado para todos que trabalham em alguma empresa!
AVALIAÇÃO FINAL: 5/5.
Este livro fez parte do pacotão de livros que eu comprei, meses atrás. Vi a capa e lembrei que já havia ouvido falar sobre isso e comprei. Mas confesso que foi meio que a "rodo", sem pensar muito.
Fui para a praia neste primeiro feriadão (o de Natal) e decidi levar um livro pra ler. Escolhi este... poucas páginas, "uma leitura rápida" pensei. Doce engano meu!!
O livro "O gerente-minuto" é antigo, vi que sua primeira edição foi de 1981 (me corrijam se eu estiver errado) e também que já gerou, obviamente, uma série de outros livros a respeito.
Vamos ao principal: gostei MUITO do livro. Muito mesmo!! Bem objetivo, fácil e gostoso de ler. São 100 páginas, sendo que algumas páginas o texto não ocupa nem metade da página! Eu diria que quem gosta de ler, vai finalizar ele em uma tarde. Quem não gosta de ler, vai finalizar em duas tardes!
O livro conta de forma romanceada a estória de um gerente que decide buscar informações com um gerente de uma grande empresa, que é conhecido pela sua capacidade de obter resultados incríveis. Este gerente é o chamado "gerente-minuto", que o personagem principal vai desvendando durante o livro.
O conceito da "gerência-minuto", quando li na aba, me pareceu um tanto "auto-ajuda" demais: reservar um minuto do seu dia para avaliar seu trabalho, sua equipe, etc.
Mas quando entendi o conceito real disso, percebi o quanto atual e verdadeiro é o que o livro prega. São três conceitos:
Objetivos-minuto, elogios-minuto, repreensões-minuto. O sufixo minuto serve para indicar que tudo isso deve ser abordado no menor tempo possível, sem rodeios e com a maior antecedência possível.
Basicamente o livro prega a arte de delegar. Treinar seus subordinados para que eles se tornem independentes. O livro até traz um fluxograma bem interessante, no final, para entendermos o conceito. Vou tentar descrever:
+ Estabeleça sempre os "objetivos-minuto" com seus subordinados, de forma objetiva e clara. Ele recomenda que tudo deve caber em uma folha branca, no máximo 240 palavras.
+ Procure flagrar seus subordinados (especialmente os que estão começando) fazendo coisas certas ou "quase-certas" e aplique o "elogio-minuto".
+ Caso flagrar seu subordinado fazendo algo errado ou que necessite intervenção, aplique a "repreensão-minuto" o quanto antes.
O livro descreve de uma forma bem clara e objetiva as técnicas para aplicar estes três conceitos... eu confesso que não quero escrever aqui pois recomendo que vocês leiam mesmo o livro. Vale a pena, principalmente por ser de fácil absorção, mesmo para os que odeiam ler.
Ah, pra finalizar: quem pretende trabalhar com SCRUM, leia este livro!!! Vocês verão conceitos bem interessantes para utilizarem no dia-a-dia!!
BOM PARA: aquele gerente que precisa de orientação para lidar com seus subordinados.
RUIM PARA: quem não gosta de gente, ou quem acha que o problema são as pessoas.
RECOMENDADO PARA: Gerentes e executivos, juniores ou seniors. Ou então para quem tem subordinados. Aliás, é recomendado para todos que trabalham em alguma empresa!
AVALIAÇÃO FINAL: 5/5.
Confira esta resenha no meu novo blog:
American way of life
Eu hoje assisti ao "Duro de Matar 4.0", de novo. Confesso que gosto dos filmes da série... embora este último não tenha sido do mesmo nível dos dois primeiros.
Notei uma coisa no filme e que, pensando novamente, me fez recordar de outra centena de filmes iguais. E como isso pode influenciar principalmente no "american way of life":
a individualidade, na frente do coletivo.
Vejam o John McClane. É o típico herói americano: valente, impiedoso, ele consegue atingir todos seus objetivos com um simples plano: "Salvar minha filha e matar todo o resto". Notem que em praticamente TODOS os filmes da série, o McClane extermina todos os inimigos e só então, minutos depois, que a "cavalaria" chega para dar o reforço.
Lembrem outros filmes famosos como Rambo (embora o primeiro filme esteja num contexto completamente diferente), Jason Bourne e outras dezenas.
Parenteses: não estou criticando os filmes, muito menos o "american way of life". Estou apenas tentando traçar um comparativo! :)
Até mesmo os EUA, como nação, costuma tomar todas as decisões sozinha e só depois consulta os demais (aqui sim, uma crítica!).
Levando isso tudo para o mundo empresarial: como a cultura americana trata dos problemas das suas empresas? Geralmente através da máxima "o problema são as pessoas". Então vemos como a grande maioria das empresas americanas tendem a liderar seus funcionários como se fossem únicos, esperando sempre que os heróis salvem suas empresas. Ok, eu não posso generalizar, eu sei! Porém, no fundo, há alguma verdade nisso, não é?
É só lembrar o que Taylor/Fayol/Ford faziam, nos primórdios da administração. "Funcionário é preguiçoso", costumavam dizer. "O mais produtivo é o chão para os demais", imaginem falar isso numa empresa, hoje em dia? Imaginem se eles vissem o foco que se dá em RH hoje em dia? Acho que morreriam de desgosto!
Foi então que os japoneses começaram a ver que o problema não são as pessoas... mas sim o contexto/cultura/sistema. E, graças a Deus, essa nova visão humanista começou a vingar (e como vingou! Toyota que o diga!).
Hoje, até mesmo o Donald Trump, com aquele topete e cara de mau, costuma falar sobre motivação e trabalho em equipe. Mesmo no seu programa do "Aprendiz", onde parece que o foco é na individualidade (já que as equipes brigam para apenas um ganhar)... mas se analisarmos bem, o vencedor é sempre aquele que consegue ser competente na gestão das outras pessoas!
Outro fato engraçado é que o modelo de "gestão de pessoas" é bem antigo, bastando olhar para o lado militar. O lema dos Marines, por exemplo, é "No one left behind" ou seja, "ninguém fica para trás". E isso vem desde, no mínimo, a Segunda Guerra Mundial.
Thank God que hoje quando falamos em "EUA", falamos em Google, Apple e Microsoft... três lugares onde a gestão de pessoas é um modelo para todos. Mas até mesmo a Coca-cola deve ter algo parecido... até mesmo a NASA (um dos principais modelos de gestão de projetos) tem este conceito de RH impregnado.
Felizmente, amigos, o "American way of life" continua produzindo seus "lone wolfs" apenas no cinema. Isso está deixando, aos poucos, de ser um traço cultural do povo deles. E, felizmente, pelo menos no mundo empresarial, o trabalho em equipe e a gestão de pessoas estão sendo mais valorizados.
Ufa, como não fui trabalhar hoje, tirei o dia para divagar um pouco ;)
Abração!
Notei uma coisa no filme e que, pensando novamente, me fez recordar de outra centena de filmes iguais. E como isso pode influenciar principalmente no "american way of life":
a individualidade, na frente do coletivo.
Vejam o John McClane. É o típico herói americano: valente, impiedoso, ele consegue atingir todos seus objetivos com um simples plano: "Salvar minha filha e matar todo o resto". Notem que em praticamente TODOS os filmes da série, o McClane extermina todos os inimigos e só então, minutos depois, que a "cavalaria" chega para dar o reforço.
Lembrem outros filmes famosos como Rambo (embora o primeiro filme esteja num contexto completamente diferente), Jason Bourne e outras dezenas.
Parenteses: não estou criticando os filmes, muito menos o "american way of life". Estou apenas tentando traçar um comparativo! :)
Até mesmo os EUA, como nação, costuma tomar todas as decisões sozinha e só depois consulta os demais (aqui sim, uma crítica!).
Levando isso tudo para o mundo empresarial: como a cultura americana trata dos problemas das suas empresas? Geralmente através da máxima "o problema são as pessoas". Então vemos como a grande maioria das empresas americanas tendem a liderar seus funcionários como se fossem únicos, esperando sempre que os heróis salvem suas empresas. Ok, eu não posso generalizar, eu sei! Porém, no fundo, há alguma verdade nisso, não é?
É só lembrar o que Taylor/Fayol/Ford faziam, nos primórdios da administração. "Funcionário é preguiçoso", costumavam dizer. "O mais produtivo é o chão para os demais", imaginem falar isso numa empresa, hoje em dia? Imaginem se eles vissem o foco que se dá em RH hoje em dia? Acho que morreriam de desgosto!
Foi então que os japoneses começaram a ver que o problema não são as pessoas... mas sim o contexto/cultura/sistema. E, graças a Deus, essa nova visão humanista começou a vingar (e como vingou! Toyota que o diga!).
Hoje, até mesmo o Donald Trump, com aquele topete e cara de mau, costuma falar sobre motivação e trabalho em equipe. Mesmo no seu programa do "Aprendiz", onde parece que o foco é na individualidade (já que as equipes brigam para apenas um ganhar)... mas se analisarmos bem, o vencedor é sempre aquele que consegue ser competente na gestão das outras pessoas!
Outro fato engraçado é que o modelo de "gestão de pessoas" é bem antigo, bastando olhar para o lado militar. O lema dos Marines, por exemplo, é "No one left behind" ou seja, "ninguém fica para trás". E isso vem desde, no mínimo, a Segunda Guerra Mundial.
Thank God que hoje quando falamos em "EUA", falamos em Google, Apple e Microsoft... três lugares onde a gestão de pessoas é um modelo para todos. Mas até mesmo a Coca-cola deve ter algo parecido... até mesmo a NASA (um dos principais modelos de gestão de projetos) tem este conceito de RH impregnado.
Felizmente, amigos, o "American way of life" continua produzindo seus "lone wolfs" apenas no cinema. Isso está deixando, aos poucos, de ser um traço cultural do povo deles. E, felizmente, pelo menos no mundo empresarial, o trabalho em equipe e a gestão de pessoas estão sendo mais valorizados.
Ufa, como não fui trabalhar hoje, tirei o dia para divagar um pouco ;)
Abração!
sábado, 22 de dezembro de 2007
Pedidos ao Papai Noel
Vamos pedir ao Papai Noel que, em 2008:
- Nossos superiores sejam mais atenciosos;
- Nossos subordinados sejam mais comprometidos;
- Nossos clientes valorizem nossos produtos;
- Os escopos mudem pouco;
- Os prazos sejam cumpridos;
- Os custos sejam mantidos;
- A comunicação seja efetiva;
- Nossos fornecedores respeitem os contratos;
- E que o stress do dia-a-dia seja menor!
Papai Noel deve estar pensando: "Não dá pra trocar tudo isso pela paz mundial?"
Feliz Natal, meus amigos!
Um abraço
- Nossos superiores sejam mais atenciosos;
- Nossos subordinados sejam mais comprometidos;
- Nossos clientes valorizem nossos produtos;
- Os escopos mudem pouco;
- Os prazos sejam cumpridos;
- Os custos sejam mantidos;
- A comunicação seja efetiva;
- Nossos fornecedores respeitem os contratos;
- E que o stress do dia-a-dia seja menor!
Papai Noel deve estar pensando: "Não dá pra trocar tudo isso pela paz mundial?"
Feliz Natal, meus amigos!
Um abraço
sexta-feira, 21 de dezembro de 2007
FELIZ NATAAAAAAL
Desejo a todos os amigos um feliz natal!
Muitas alegrias e sucesso profissional a todos nós!
Volto à ativa agora só na próxima quarta-feira, dia 26.
Um abração!
Muitas alegrias e sucesso profissional a todos nós!
Volto à ativa agora só na próxima quarta-feira, dia 26.
Um abração!
Resultado da reunião estratégica
Bom, para começar, a reunião começou com atraso de 1 hora... normal! Meus chefes são enrolados! hehe
Mas consegui reunir praticamente todos. E os sistemas que eu propus aqui no post abaixo, funcionaram!
Eu tentei definir para identificarmos pela cor do post-it se o item era "ambiente+infra", "processos+atividades" ou "RH+comunicação". Mas já na primeira rodada eu vi que isso complicaria muito. Então decidi que apenas iríamos identificar tudo e posteriormente eu faria uma filtragem para ver a qual domínio cada item pertencesse.
Nossa retrospectiva levantou, obviamente, mais coisas ruins do que boas. A boa ficou praticamente focada no RFID. Em coisas ruins, muito foco no pessoal: distrações, falta de comprometimento, alta rotatividade, falta de técnicos específicos, etc.
E levantamos MUITAS melhorias. Muitas mesmo. Não tivemos tempo de discutir todas, mas ao menos identificamos no minimo uma dezena delas.
Depois discutimos os projetos. Catorze deles foram levantados. Na primeira passada, conseguimos eliminar quatro deles. Sobraram 10.
Então começou as discussões sobre eles. Priorizamos eles (decidimos por "alto", "médio" e "baixo" para facilitar). Não preenchemos ainda o "valor de negócio" nem os outros campos, acho que isso ficará para a próxima reunião.
Conseguimos reduzir de catorze projetos, para QUATRO! Sendo que um deles, o de RFID, engloba diversas áreas pois ainda não decidimos ao certo para qual área iremos.
Combinamos que na próxima sexta-feira iremos continuar essa reunião, agora mais focado nos projetos e nas melhorias.
Às 18h em ponto encerramos a reunião. Espero que isso se torne um hábito.
Posso dizer que a estrutura abaixo foi bem razoável. Ajudou bastante a orientar a reunião. Método "aprovado" ;)
Abraços!
Mas consegui reunir praticamente todos. E os sistemas que eu propus aqui no post abaixo, funcionaram!
Eu tentei definir para identificarmos pela cor do post-it se o item era "ambiente+infra", "processos+atividades" ou "RH+comunicação". Mas já na primeira rodada eu vi que isso complicaria muito. Então decidi que apenas iríamos identificar tudo e posteriormente eu faria uma filtragem para ver a qual domínio cada item pertencesse.
Nossa retrospectiva levantou, obviamente, mais coisas ruins do que boas. A boa ficou praticamente focada no RFID. Em coisas ruins, muito foco no pessoal: distrações, falta de comprometimento, alta rotatividade, falta de técnicos específicos, etc.
E levantamos MUITAS melhorias. Muitas mesmo. Não tivemos tempo de discutir todas, mas ao menos identificamos no minimo uma dezena delas.
Depois discutimos os projetos. Catorze deles foram levantados. Na primeira passada, conseguimos eliminar quatro deles. Sobraram 10.
Então começou as discussões sobre eles. Priorizamos eles (decidimos por "alto", "médio" e "baixo" para facilitar). Não preenchemos ainda o "valor de negócio" nem os outros campos, acho que isso ficará para a próxima reunião.
Conseguimos reduzir de catorze projetos, para QUATRO! Sendo que um deles, o de RFID, engloba diversas áreas pois ainda não decidimos ao certo para qual área iremos.
Combinamos que na próxima sexta-feira iremos continuar essa reunião, agora mais focado nos projetos e nas melhorias.
Às 18h em ponto encerramos a reunião. Espero que isso se torne um hábito.
Posso dizer que a estrutura abaixo foi bem razoável. Ajudou bastante a orientar a reunião. Método "aprovado" ;)
Abraços!
quinta-feira, 20 de dezembro de 2007
Como planejei minha reunião anual da organização
Esse post é para aqueles que não tem a menor idéia de como fazer uma reunião anual da empresa, para avaliar o ano de 2007 e planejar o de 2008. Não pretendo dizer o que é certo ou errado, mas sim apresentar como eu planejei essa reunião. Sinta-se à vontade para adaptar essa estrutura ao seu gosto! :)
------------
Amanhã, sexta, teremos nossa reunião anual para avaliar o ano de 2007 e planejar o de 2008. Eu que convoquei a reunião, com a idéia de deixarmos bem claro o que todos nós pensamos, uma vez que são 7 stakeholders (incluindo gerentes, consultores, parceiros e chefes).
Reservei o turno inteiro da tarde para fazer a reunião. A idéia é torná-la bem ágil (vocês verão que há algo de - adivinhem - SCRUM! hehehe) e evitar a perda de foco. Ah, sim, e também a perda de informações.
A agenda foi definida dessa forma:
14h00 - 14h15 : Início da reunião e apresentação da estrutura que seguiremos
14h15 - 14h45 : Discussão sobre a relação grupo de pesquisa x empresa
14h45 - 15h45 : Retrospectiva 2007
15h45 - 16h00 : Intervalo
16h15 - 17h30 : Planejamento para 2008
17h30 - 18h00 : Encerramento
Discussão sobre a relação grupo de pesquisa x empresa:
O objetivo é deixar de forma clara para todos os envolvidos quais são as obrigações do GSE e quais são as obrigações da Innalogics. Como essa relação pode ser melhorada e otimizada para evitar sobreposições (recurso, infra-estrutura, etc.)
Retrospectiva 2007:
O objetivo é levantar o que fizemos de positivo neste ano que passou, o que podemos melhorar para o ano que vem e quais são as melhorias concretas que planejamentos atingir para 2008 (metas). Os pontos que serão discutidos são: infra-estrutura + ambiente ; atividades +
processos ; recursos humanos + comunicação. Levarei no dia algumas sugestões de tópicos para nos guiar.
Usaremos um painel similar ao que o SCRUM utiliza, com três colunas: "O que foi bem", "O que pode ser melhorado" e "Melhorias para o próximo ano", sempre norteando aqueles três conceitos que eu citei acima.
A questão "melhorias" será votada entre os integrantes da reunião. E elegeremos cinco (ou outro valor a ser combinado) que serão as principais a serem analisadas e transformadas em metas para o próximo ano.
É importante que aqui haverá bastante discussão e já servirá como base para o planejamento a seguir.
Planejamento para 2008:
O objetivo é apresentar todos os projetos que tivemos neste ano que passou, avaliar o nosso mercado de atuação e definir qual será o foco e quais serão as metas a serem atingidas para o próximo ano (de preferência nos próximos seis meses). Definiremos algumas ações
principais a serem tomadas para isto.
Utilizarei aqui o conceito de "Index cards" que apresentei em posts anteriores, para a definição do "product backlog". Podemos chamar isso de "project cards". :)
Ele é mais ou menos assim (esse aqui foi feito no paintbrush só para vocês entenderem):
A idéia é:
Nome do projeto: o nome do projeto em questão.
Prioridade: Valor de 1 a 150, sendo 1 a menor prioridade possível e 150 a maior prioridade possível. Deve-se aqui avaliar a criticidade do projeto.
Área de negócio: a área em que o projeto é aplicado. Ex: logística, vendas, telemetria, etc.
Valor de negócio: usando o mesmo intervalo de 1 a 150, a idéia aqui é considerar o projeto que melhor dará retorno comercial, financeiro e/ou de negócio.
Pontos fortes e fracos: descobrir as forças e fraquezas envolvidas no projeto, sejam elas internas (nossa organização, por exemplo) ou externas (mercado, por exemplo).
Situação do projeto: é um checklist com a situação atual do projeto.
[ ] Não iniciado (para projetos que estão em negociação ou similar)
[ ] Em execução (para projetos que estão ativos e em execução)
[ ] Stand-by (para aqueles projetos que encontram-se parados por algum motivo)
[ ] Encerrado (para projetos que estão encerrados ou cancelados por algum motivo)
Anotações: notas que serão tomadas durante as discussões que servirão como referência para a avaliação posterior.
O bacana disso é que teremos como mensurar e avaliar TODOS os projetos, facilitando a visualização para a tomada de decisão.
---------------
Dicas extras:
+ Para essas reuniões longas, procure fazer um intervalo de 15 a 20 minutos, para o pessoal descansar.
+ Nessas mesmas reuniões providencie alguns petiscos e água para que o pessoal possa se sentir mais à vontade.
+ Procure sempre interagir com o pessoal. Evite que a reunião se torne um "porre".
+ Siga ao pé da letra a agenda deixando claro que o tempo deve ser respeitado, para que todos assuntos sejam discutidos.
+ Caso um assunto se estenda demais, seja mediador: avise que o próximo tópico será discutido e que este assunto poderá ser retomado no final da reunião ou então em outro momento.
+ Medie a reunião, mas não tente ser o centro das atenções!
Ufa! Acho que é isso. Como eu disse, são alguns conceitos que eu irei aplicar. Não o que é "certo" ou "errado". Eu não sei o resultado disso, saberei amanhã (e vocês também, aqui mesmo!) :)
Um abração
------------
Amanhã, sexta, teremos nossa reunião anual para avaliar o ano de 2007 e planejar o de 2008. Eu que convoquei a reunião, com a idéia de deixarmos bem claro o que todos nós pensamos, uma vez que são 7 stakeholders (incluindo gerentes, consultores, parceiros e chefes).
Reservei o turno inteiro da tarde para fazer a reunião. A idéia é torná-la bem ágil (vocês verão que há algo de - adivinhem - SCRUM! hehehe) e evitar a perda de foco. Ah, sim, e também a perda de informações.
A agenda foi definida dessa forma:
14h00 - 14h15 : Início da reunião e apresentação da estrutura que seguiremos
14h15 - 14h45 : Discussão sobre a relação grupo de pesquisa x empresa
14h45 - 15h45 : Retrospectiva 2007
15h45 - 16h00 : Intervalo
16h15 - 17h30 : Planejamento para 2008
17h30 - 18h00 : Encerramento
Discussão sobre a relação grupo de pesquisa x empresa:
O objetivo é deixar de forma clara para todos os envolvidos quais são as obrigações do GSE e quais são as obrigações da Innalogics. Como essa relação pode ser melhorada e otimizada para evitar sobreposições (recurso, infra-estrutura, etc.)
Retrospectiva 2007:
O objetivo é levantar o que fizemos de positivo neste ano que passou, o que podemos melhorar para o ano que vem e quais são as melhorias concretas que planejamentos atingir para 2008 (metas). Os pontos que serão discutidos são: infra-estrutura + ambiente ; atividades +
processos ; recursos humanos + comunicação. Levarei no dia algumas sugestões de tópicos para nos guiar.
Usaremos um painel similar ao que o SCRUM utiliza, com três colunas: "O que foi bem", "O que pode ser melhorado" e "Melhorias para o próximo ano", sempre norteando aqueles três conceitos que eu citei acima.
A questão "melhorias" será votada entre os integrantes da reunião. E elegeremos cinco (ou outro valor a ser combinado) que serão as principais a serem analisadas e transformadas em metas para o próximo ano.
É importante que aqui haverá bastante discussão e já servirá como base para o planejamento a seguir.
Planejamento para 2008:
O objetivo é apresentar todos os projetos que tivemos neste ano que passou, avaliar o nosso mercado de atuação e definir qual será o foco e quais serão as metas a serem atingidas para o próximo ano (de preferência nos próximos seis meses). Definiremos algumas ações
principais a serem tomadas para isto.
Utilizarei aqui o conceito de "Index cards" que apresentei em posts anteriores, para a definição do "product backlog". Podemos chamar isso de "project cards". :)
Ele é mais ou menos assim (esse aqui foi feito no paintbrush só para vocês entenderem):
A idéia é:Nome do projeto: o nome do projeto em questão.
Prioridade: Valor de 1 a 150, sendo 1 a menor prioridade possível e 150 a maior prioridade possível. Deve-se aqui avaliar a criticidade do projeto.
Área de negócio: a área em que o projeto é aplicado. Ex: logística, vendas, telemetria, etc.
Valor de negócio: usando o mesmo intervalo de 1 a 150, a idéia aqui é considerar o projeto que melhor dará retorno comercial, financeiro e/ou de negócio.
Pontos fortes e fracos: descobrir as forças e fraquezas envolvidas no projeto, sejam elas internas (nossa organização, por exemplo) ou externas (mercado, por exemplo).
Situação do projeto: é um checklist com a situação atual do projeto.
[ ] Não iniciado (para projetos que estão em negociação ou similar)
[ ] Em execução (para projetos que estão ativos e em execução)
[ ] Stand-by (para aqueles projetos que encontram-se parados por algum motivo)
[ ] Encerrado (para projetos que estão encerrados ou cancelados por algum motivo)
Anotações: notas que serão tomadas durante as discussões que servirão como referência para a avaliação posterior.
O bacana disso é que teremos como mensurar e avaliar TODOS os projetos, facilitando a visualização para a tomada de decisão.
---------------
Dicas extras:
+ Para essas reuniões longas, procure fazer um intervalo de 15 a 20 minutos, para o pessoal descansar.
+ Nessas mesmas reuniões providencie alguns petiscos e água para que o pessoal possa se sentir mais à vontade.
+ Procure sempre interagir com o pessoal. Evite que a reunião se torne um "porre".
+ Siga ao pé da letra a agenda deixando claro que o tempo deve ser respeitado, para que todos assuntos sejam discutidos.
+ Caso um assunto se estenda demais, seja mediador: avise que o próximo tópico será discutido e que este assunto poderá ser retomado no final da reunião ou então em outro momento.
+ Medie a reunião, mas não tente ser o centro das atenções!
Ufa! Acho que é isso. Como eu disse, são alguns conceitos que eu irei aplicar. Não o que é "certo" ou "errado". Eu não sei o resultado disso, saberei amanhã (e vocês também, aqui mesmo!) :)
Um abração
quarta-feira, 19 de dezembro de 2007
Trabalhar em casa... você consegue?
Hoje acabei ficando em casa. As bolhas no meu pé me deixaram sem poder caminhar direito... então ficaria muito comprometido no trabalho. Decidi que trabalharia em casa. Me planejei pela manhã para estudar sobre a reunião de planejamento que teremos na sexta.
Já que este é um blog que visa apresentar algumas lições aprendidas, posso dizer que aprendi definitivamente outra lição: eu não nasci para trabalhar em casa. A minha grande limitação é como se concentrar no trabalho estando em um ambiente onde definitivamente NADA lembra trabalho?
O máximo que eu consegui, sobre trabalho, foi mandar alguns emails para as listas para discutir sobre a reunião e buscar alguns livros em PDF para referência.
Tentei então aproveitar para ler as revistas que chegaram: Você S/A e Info Corporate. O máximo que consegui foi folheá-las, sem compromisso. Ou eu estava jogando no computador, ou estava navegando a esmo, ou descia para brincar com minha labradora, ou então estava comendo. Trabalho? Nada.
Além de não produzir nada de útil, acabo percebendo que o meu ânimo também desmorona. Eu fico sem vontade para fazer nada... só quis sentar na poltrona e ficar pensando em qualquer outra coisa, menos trabalho. E o engraçado é que neste exato momento em que escrevo isso, estou renovado. É como se tivesse chegado em casa após o trabalho! Ou seja, inconscientemente estou pensando que realmente trabalhei.
Definitivamente eu não consigo trabalhar em casa. Isso requer uma organização e um esforço aos quais eu realmente não estou preparado, no momento. É preciso muita, mas MUITA disciplina.
E você, leitor? Consegue trabalhar em casa? Ou é como eu?
Abração!
Já que este é um blog que visa apresentar algumas lições aprendidas, posso dizer que aprendi definitivamente outra lição: eu não nasci para trabalhar em casa. A minha grande limitação é como se concentrar no trabalho estando em um ambiente onde definitivamente NADA lembra trabalho?
O máximo que eu consegui, sobre trabalho, foi mandar alguns emails para as listas para discutir sobre a reunião e buscar alguns livros em PDF para referência.
Tentei então aproveitar para ler as revistas que chegaram: Você S/A e Info Corporate. O máximo que consegui foi folheá-las, sem compromisso. Ou eu estava jogando no computador, ou estava navegando a esmo, ou descia para brincar com minha labradora, ou então estava comendo. Trabalho? Nada.
Além de não produzir nada de útil, acabo percebendo que o meu ânimo também desmorona. Eu fico sem vontade para fazer nada... só quis sentar na poltrona e ficar pensando em qualquer outra coisa, menos trabalho. E o engraçado é que neste exato momento em que escrevo isso, estou renovado. É como se tivesse chegado em casa após o trabalho! Ou seja, inconscientemente estou pensando que realmente trabalhei.
Definitivamente eu não consigo trabalhar em casa. Isso requer uma organização e um esforço aos quais eu realmente não estou preparado, no momento. É preciso muita, mas MUITA disciplina.
E você, leitor? Consegue trabalhar em casa? Ou é como eu?
Abração!
terça-feira, 18 de dezembro de 2007
Evento de confraternização da empresa
Hoje fizemos nosso evento de confraternização da empresa e do grupo de pesquisa, em um hotel fazenda. Muito bacana e bonito.
É impressionante como este tipo de evento é benéfico para o grupo. Hoje tive a oportunidade de conversar com diversas pessoas de outras equipes, conhecê-los melhor. Inclusive com meus chefes... já que no trabalho é raro poder conversar sobre assuntos banais. Também os próprios colegas de trabalho interagem bastante entre eles.
Como um evento de descontração foi bacana.
Na sexta-feira teremos uma reunião de avaliação do ano e planejamento para o próximo. Estarei a semana inteira preparando essa importante reunião, ainda mais que serão vários stakeholders envolvidos. Se não houver planejamento, corremos o risco de perdermos uma tarde e sair com nenhuma decisão ou meta.
Ah... resolvi jogar futebol depois de 1 ano parado. De pés descalços... estou com duas bolhas num pé e uma no outro pé. Ócios do ofício!
Abraços
É impressionante como este tipo de evento é benéfico para o grupo. Hoje tive a oportunidade de conversar com diversas pessoas de outras equipes, conhecê-los melhor. Inclusive com meus chefes... já que no trabalho é raro poder conversar sobre assuntos banais. Também os próprios colegas de trabalho interagem bastante entre eles.
Como um evento de descontração foi bacana.
Na sexta-feira teremos uma reunião de avaliação do ano e planejamento para o próximo. Estarei a semana inteira preparando essa importante reunião, ainda mais que serão vários stakeholders envolvidos. Se não houver planejamento, corremos o risco de perdermos uma tarde e sair com nenhuma decisão ou meta.
Ah... resolvi jogar futebol depois de 1 ano parado. De pés descalços... estou com duas bolhas num pé e uma no outro pé. Ócios do ofício!
Abraços
Dia de confraternização do grupo!
Terça-feira é o dia da confraternização anual do grupo. Vamos para um hotel fazenda passar o dia.
Vou poder praticar meu hobby de fotografia, pelo menos! :)
E praticar alguns esportes... pois a barriga só cresce hehehe
Então estou meio sem ter o que dizer. Amanhã posto algo interessante!
Abraços
Vou poder praticar meu hobby de fotografia, pelo menos! :)
E praticar alguns esportes... pois a barriga só cresce hehehe
Então estou meio sem ter o que dizer. Amanhã posto algo interessante!
Abraços
sábado, 15 de dezembro de 2007
PMP? CSM? CMMI? ISO?
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Vocês já pararam para pensar o real motivo de uma empresa ou um funcionário buscar alguma certificação?
Por que um gerente de projetos deseja se tornar PMP ou CSM (certified scrum master) ?
Por que uma empresa deseja se tornar CMMI 2, 3, 4, 5? Ou ter a certificação ISO?
Este texto abaixo foi escrito brilhantemente pelo colega da lista E-Plan, Ricardo Delarue. Achei que fecha com o que eu penso e então decidi colocá-lo na integra :)
PS: O Ricardo não é o Ricardão de posts anteriores! hehehe
--------------------
Situação 1:
Há uns 25 anos atrás, um dos diferenciais do mercado era falar inglës (ok, até hoje isso ainda é um diferencial), mas lembro-me de uma caso interessante, onde um colega de faculdade falava alemão pelos cotovelos, e havia uma oportunidade para engenheiro de produção na Osran (acho que é assim que se escreve). Ele passou por um processo seletivo cabeludo, inclusive de interpretação de normas técnicas em alemão (ele foi o único candidato que lia alemão perfeitamente bem) mas não foi o engenheiro escolhido pois não falava inglës. Até hoje lembro-me deste fato, pois me pareceu que ocorreu uma escolha do perfil do candidato de forma inadequada. Na minha opinião um recém formado que falasse alemão estaria muito mais
adequado a identidade natural da empresa. Até haviam reuniões em alemão. Esse meu colega no processo de seleção, até falou em alemão com o provável futuro gerente dele. Seria isso um processo de seleção inadequado ?
Situação 2
Quando estávamos todos migrando do lotus 123 (DOS) para o excel 3.0 (windows 3.1 for workgroups), há uns 17 anos atrás, um conhecido meu que era um bom usuário de Lotus 123, mas nunca tinha visto o windows / excel na frente, perdeu uma oportunidade em uma determinada empresa em que o processo de seleção exigia ambiente windows. Ok, entendo, sem problemas, o que ocorre é que a tal empresa ainda estava utilizando o lotus 123 em DOS, com monitor CGA fósforo verde e tudo, e não estava previsto nenhuma migração para o
ambiente windows. Seria isso um processo de seleção inadequado ?
Situação de hoje.
Faço um pergunta simples. Será que todas as empresas que solicitam um PMP no seu quadro de funcionários utiliza realmente o PMBOK como uma referëncia e ela, a empresa, o utiliza como instrumento que gera uma identidade a ela ? Será que algumas das empresas que estão contratando um PMP, estão muito mais atendendo a uma solicitação do cliente, do que realmente interessadas a implantar essa filosofia de gerenciamento de projetos e mudar sua identidade operacional ? Será que todo mundo que está contratando um PMP, realmente
necessita um PMP ? Será que existem agora, nesse momento, alguns PMP´s que foram contratados por serem PMP´s e estáo utilizando muito pouco do conhecimento que possuem no seu trabalho e estão tremendamente frustrados ? Seria isso um processo de seleção inadequado?
Ok, fiz o curso da Dinsmore em 2004, dei meu pitaco mandando um e-mail para os EUA para que eles corrigissem um erro bobo no PMBOK 2000, quando ele publicassem o 2004 (sim eles corrigiram), acho como já disse em e-mails passados, a filosofia do PMI excelente, mas continuo achando que ela serve de parametrização para gerar uma identidade operacional. Ainda não fiz a
prova, e nem vou fazer tão cedo, uma vez que por aqui no oriente médio, não existe esse nível de importäncia de um profissional ser ou não um PMP. Isso significa que só irei fazer a prova se o mercado daqui começar a exigir como está exigindo aí no Brasil.
Resumidamente, ser PMP é um enorme diferencial no mercado Brasileiro e em muitos outros países, e eu recomendo sem restrições que todos pelo menos conheçam a filosofia de trabalho do PMI, que é excelente, entretanto ao mesmo tempo, me parece que o que mais importa é a definição adequada do perfil do candidato no processo de seleção. Entender se será realmente
necessário contratar um PMP ou não, e de forma madura definir esse perfil. A empresa deverá evitar o risco da frustração do profissional, pois isso poderá gerar uma péssima performance do mesmo, que no fundo é o que nenhum empresário deseja.
Tapar o sol com a peneira tem chance de ser o mesmo que contratar um PMP, sem que os sócios da empresa, diretores, etc, estejam querendo efetivamente mudar sua identidade operacional para o que preconiza o PMI. Seria ruim para a empresa e para o profissional. Infelizmente eu conheço dois casos que servem como exemplo negativo, e em um dos casos, o PMP pediu sua demissão após 6 meses de contratado. Ele mesmo me disse que seria tolice continuar em
uma empresa trabalhando de forma oposta ao que preconiza o PMI.
Colegas PMP´s conheçam bem a empresa que estão querendo contratar-lhes. Colegas empresários, pensem se necessitam realmente que o profissional a ser contratado seja um PMP.
Ricardo Delarue
----------------
E você, leitor, o que acha disto?
Abraços!
Vocês já pararam para pensar o real motivo de uma empresa ou um funcionário buscar alguma certificação?
Por que um gerente de projetos deseja se tornar PMP ou CSM (certified scrum master) ?
Por que uma empresa deseja se tornar CMMI 2, 3, 4, 5? Ou ter a certificação ISO?
Este texto abaixo foi escrito brilhantemente pelo colega da lista E-Plan, Ricardo Delarue. Achei que fecha com o que eu penso e então decidi colocá-lo na integra :)
PS: O Ricardo não é o Ricardão de posts anteriores! hehehe
--------------------
Situação 1:
Há uns 25 anos atrás, um dos diferenciais do mercado era falar inglës (ok, até hoje isso ainda é um diferencial), mas lembro-me de uma caso interessante, onde um colega de faculdade falava alemão pelos cotovelos, e havia uma oportunidade para engenheiro de produção na Osran (acho que é assim que se escreve). Ele passou por um processo seletivo cabeludo, inclusive de interpretação de normas técnicas em alemão (ele foi o único candidato que lia alemão perfeitamente bem) mas não foi o engenheiro escolhido pois não falava inglës. Até hoje lembro-me deste fato, pois me pareceu que ocorreu uma escolha do perfil do candidato de forma inadequada. Na minha opinião um recém formado que falasse alemão estaria muito mais
adequado a identidade natural da empresa. Até haviam reuniões em alemão. Esse meu colega no processo de seleção, até falou em alemão com o provável futuro gerente dele. Seria isso um processo de seleção inadequado ?
Situação 2
Quando estávamos todos migrando do lotus 123 (DOS) para o excel 3.0 (windows 3.1 for workgroups), há uns 17 anos atrás, um conhecido meu que era um bom usuário de Lotus 123, mas nunca tinha visto o windows / excel na frente, perdeu uma oportunidade em uma determinada empresa em que o processo de seleção exigia ambiente windows. Ok, entendo, sem problemas, o que ocorre é que a tal empresa ainda estava utilizando o lotus 123 em DOS, com monitor CGA fósforo verde e tudo, e não estava previsto nenhuma migração para o
ambiente windows. Seria isso um processo de seleção inadequado ?
Situação de hoje.
Faço um pergunta simples. Será que todas as empresas que solicitam um PMP no seu quadro de funcionários utiliza realmente o PMBOK como uma referëncia e ela, a empresa, o utiliza como instrumento que gera uma identidade a ela ? Será que algumas das empresas que estão contratando um PMP, estão muito mais atendendo a uma solicitação do cliente, do que realmente interessadas a implantar essa filosofia de gerenciamento de projetos e mudar sua identidade operacional ? Será que todo mundo que está contratando um PMP, realmente
necessita um PMP ? Será que existem agora, nesse momento, alguns PMP´s que foram contratados por serem PMP´s e estáo utilizando muito pouco do conhecimento que possuem no seu trabalho e estão tremendamente frustrados ? Seria isso um processo de seleção inadequado?
Ok, fiz o curso da Dinsmore em 2004, dei meu pitaco mandando um e-mail para os EUA para que eles corrigissem um erro bobo no PMBOK 2000, quando ele publicassem o 2004 (sim eles corrigiram), acho como já disse em e-mails passados, a filosofia do PMI excelente, mas continuo achando que ela serve de parametrização para gerar uma identidade operacional. Ainda não fiz a
prova, e nem vou fazer tão cedo, uma vez que por aqui no oriente médio, não existe esse nível de importäncia de um profissional ser ou não um PMP. Isso significa que só irei fazer a prova se o mercado daqui começar a exigir como está exigindo aí no Brasil.
Resumidamente, ser PMP é um enorme diferencial no mercado Brasileiro e em muitos outros países, e eu recomendo sem restrições que todos pelo menos conheçam a filosofia de trabalho do PMI, que é excelente, entretanto ao mesmo tempo, me parece que o que mais importa é a definição adequada do perfil do candidato no processo de seleção. Entender se será realmente
necessário contratar um PMP ou não, e de forma madura definir esse perfil. A empresa deverá evitar o risco da frustração do profissional, pois isso poderá gerar uma péssima performance do mesmo, que no fundo é o que nenhum empresário deseja.
Tapar o sol com a peneira tem chance de ser o mesmo que contratar um PMP, sem que os sócios da empresa, diretores, etc, estejam querendo efetivamente mudar sua identidade operacional para o que preconiza o PMI. Seria ruim para a empresa e para o profissional. Infelizmente eu conheço dois casos que servem como exemplo negativo, e em um dos casos, o PMP pediu sua demissão após 6 meses de contratado. Ele mesmo me disse que seria tolice continuar em
uma empresa trabalhando de forma oposta ao que preconiza o PMI.
Colegas PMP´s conheçam bem a empresa que estão querendo contratar-lhes. Colegas empresários, pensem se necessitam realmente que o profissional a ser contratado seja um PMP.
Ricardo Delarue
----------------
E você, leitor, o que acha disto?
Abraços!
sexta-feira, 14 de dezembro de 2007
Lidando com uma equipe "não-madura" em projetos
Estou percebendo que o GRANDE desafio que eu tenho, ao gerenciar projetos em um ambiente acadêmico é de fato a gestão das pessoas envolvidas.
O meu chefe é uma pessoa maravilhosa. Extremamente competente no que faz e muito aberto para discussões e afins, além de muito bem relacionado (eu cada dia mais me impressiono com os contatos que ele tem). Os únicos "poréns" dele é que ele possui a cabeça muito orientada a pesquisas e empreendedorismo, e menos em mercado e empresa. Isso o torna uma pessoa que às vezes costuma "sair da casinha" com algumas idéias mirabolantes. Também dificulta a visão que ele tem da equipe, uma vez que algumas atividades ele considera triviais de serem feitas, mas isso para uma pessoa como ele, experiente.
E a minha equipe? Bem, é infelizmente composta por uma gurizada na faixa dos 20-22 anos. Poucos tem experiência em empresas e, os que tiveram, não trouxeram essa experiência para dentro do projeto. Portanto, por mais que eu insira mudanças e os force a sair da "zona confortável", eles tendem a em pouco tempo retornar a zona.
Isso aconteceu durante todo este mês... e eu posso citar alguns fatos como: provas, onde eles mostraram que a faculdade está em primeiro lugar; comprometimento, quando afirmam e reconhecem quando a produtividade cai, mas insistem nos mesmos erros (e portanto, o PDCA não é identificado!); distrações ao extremo, com conversas fora de hora principalmente.
E, lógico, vamos falar de mim. Eu errei muito nos primeiros seis meses. Assumi com pouquíssima experiência em um gerenciamento de projetos e ainda cai em um terreno que eu não tenho grandes conhecimentos (softwares embarcados). Tomei diversas decisões erradas... mas todas elas serviram para eu me aprimorar. Hoje eu posso olhar pra trás e ter a certeza de que faria tudo completamente diferente. Ainda me faltam coisas como aprimorar a comunicação (e talvez um pouco da desnibição, em alguns momentos) e também ser mais firme principalmente no controle do projeto. Considero também um erro grande meu, o qual busco melhorar a todo instante, a minha necessidade de sempre contextualizar tudo... então algumas vezes acabo perdendo tempo demais explicando o que não precisa ser explicado.
Um dos maiores desafios, portanto, em projetos acadêmicos é a gestão de pessoas. Saber tirar o máximo desse perfil que compõe 90% das equipes em projetos deste tipo e conseguir o comprometimento com resultados. Motivar, principalmente.
Posso dizer hoje (e sugerir a você, caro leitor) que uma das formas mais ineficazes de motivar sua equipe é aumentar o salário. Isso gerará um resultado diferenciado em no máximo um mês. Depois a coisa volta a ser como era antes... com a diferença que você está gastando mais.
Eu já sugeri para os próximos projetos que possam vir a acontecer no nosso laboratório: eu quero participar ativamente da escolha dos novos membros das equipes. Quero pessoas com as quais eu note que há comprometimento e, principalmente, motivação em trabalhar em um projeto destes.
Só para vocês terem uma idéia de como um projeto deste tipo é extremamente sub-valorizado por todas as equipes que eu conheço lá: eles trabalham QUATRO horas por dia e reecebem em torno de 1000-1200 reais. Este é o salário de muita gente que trabalha OITO horas e rala dia e noite.
Pessoas e informação. Eis o futuro de qualquer empresa.
Abraços!
O meu chefe é uma pessoa maravilhosa. Extremamente competente no que faz e muito aberto para discussões e afins, além de muito bem relacionado (eu cada dia mais me impressiono com os contatos que ele tem). Os únicos "poréns" dele é que ele possui a cabeça muito orientada a pesquisas e empreendedorismo, e menos em mercado e empresa. Isso o torna uma pessoa que às vezes costuma "sair da casinha" com algumas idéias mirabolantes. Também dificulta a visão que ele tem da equipe, uma vez que algumas atividades ele considera triviais de serem feitas, mas isso para uma pessoa como ele, experiente.
E a minha equipe? Bem, é infelizmente composta por uma gurizada na faixa dos 20-22 anos. Poucos tem experiência em empresas e, os que tiveram, não trouxeram essa experiência para dentro do projeto. Portanto, por mais que eu insira mudanças e os force a sair da "zona confortável", eles tendem a em pouco tempo retornar a zona.
Isso aconteceu durante todo este mês... e eu posso citar alguns fatos como: provas, onde eles mostraram que a faculdade está em primeiro lugar; comprometimento, quando afirmam e reconhecem quando a produtividade cai, mas insistem nos mesmos erros (e portanto, o PDCA não é identificado!); distrações ao extremo, com conversas fora de hora principalmente.
E, lógico, vamos falar de mim. Eu errei muito nos primeiros seis meses. Assumi com pouquíssima experiência em um gerenciamento de projetos e ainda cai em um terreno que eu não tenho grandes conhecimentos (softwares embarcados). Tomei diversas decisões erradas... mas todas elas serviram para eu me aprimorar. Hoje eu posso olhar pra trás e ter a certeza de que faria tudo completamente diferente. Ainda me faltam coisas como aprimorar a comunicação (e talvez um pouco da desnibição, em alguns momentos) e também ser mais firme principalmente no controle do projeto. Considero também um erro grande meu, o qual busco melhorar a todo instante, a minha necessidade de sempre contextualizar tudo... então algumas vezes acabo perdendo tempo demais explicando o que não precisa ser explicado.
Um dos maiores desafios, portanto, em projetos acadêmicos é a gestão de pessoas. Saber tirar o máximo desse perfil que compõe 90% das equipes em projetos deste tipo e conseguir o comprometimento com resultados. Motivar, principalmente.
Posso dizer hoje (e sugerir a você, caro leitor) que uma das formas mais ineficazes de motivar sua equipe é aumentar o salário. Isso gerará um resultado diferenciado em no máximo um mês. Depois a coisa volta a ser como era antes... com a diferença que você está gastando mais.
Eu já sugeri para os próximos projetos que possam vir a acontecer no nosso laboratório: eu quero participar ativamente da escolha dos novos membros das equipes. Quero pessoas com as quais eu note que há comprometimento e, principalmente, motivação em trabalhar em um projeto destes.
Só para vocês terem uma idéia de como um projeto deste tipo é extremamente sub-valorizado por todas as equipes que eu conheço lá: eles trabalham QUATRO horas por dia e reecebem em torno de 1000-1200 reais. Este é o salário de muita gente que trabalha OITO horas e rala dia e noite.
Pessoas e informação. Eis o futuro de qualquer empresa.
Abraços!
Gestão do conhecimento
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Eu costumo falar que a informação é o sangue da empresa. Sem ela, nada funcionará.
O futuro tende a mostrar que a informação será cada dia mais importante. Aquela empresa que tiver a informação correta, terá um grande diferencial competitivo no mercado. Aquela empresa que tiver conhecimento, terá um diferencial ainda maior!
Uma das coisas que eu senti falta no SCRUM é a gestão da informação e do conhecimento. E por isso que eu costumo dizer que o SCRUM não é de fato um gerenciamento de projeto, mas sim um gerenciamento de processo (minha opinião, é claro!).
Noto em listas que assino (nacionais e internacionais) que existem sempre os extremos: aqueles que acham que a documentação deve ser deixada de lado e aqueles que acham que a documentação é o principal de tudo.
Eu sou da turma do meio. É preciso documentar, mas com parcimônia! E vou dar um exemplo para cada um dos extremos, para ilustrar isso que digo:
Imagine uma empresa que gerou um software para um grande cliente, mas não se dedicou à documentação do mesmo. Colocou apenas alguns parcos comentários nos códigos. Dois anos depois, o cliente liga e pede uma extensão. O problema é que não restou ninguém da equipe que desenvolveu este sistema. E agora? Quanto tempo haverá de retrabalho? Quantas horas se perderão para que a nova equipe entenda estes códigos para só então começar a implantar o novo?
Por outro lado, imagine esta mesma situação, só que a empresa desenvolveu uma documentação de 350 páginas, frente e verso. UML's, documentos de visão, domínio, arquitetura, hardware, software, negócio, etc. quanto tempo essa nova equipe levará para encontrar a informação correta? Levante a mão quem aqui teria SACO para ler um documento técnico de 350 páginas (eu não levantei!).
Vejam como a falta e o excesso são ambos prejudiciais!
Pensem na própria internet, como um excesso de informações! Se queremos pesquisar sobre a utilidade de uma função de determinada linguagem de programação, o Google irá retornar centenas de sites! E lá se vai tempo perdido procurando qual é o site que tem a informação certa...
Portanto, eu sou daqueles que acha que é preciso haver um meio termo nisso. A informação precisa estar retida de alguma forma (documentos, principalmente) mas precisa ser de fácil acesso e localização. E, principalmente, deve conter apenas o ESSENCIAL!
Eu reli alguns documentos que gerei anteriormente e comecei a me dar conta o quão terrível eu escrevi! Os documentos que temos lá são ótimos documentos para um trabalho de conclusão... tem informações de utilidade duvidosa, para nossa empresa. Um exemplo típico foi que perdemos pelo menos duas páginas escrevendo sobre as empresas fabricantes de cada um dos componentes do nosso hardware. Francamente, o que isso agrega para nossa equipe? Ou mesmo para uma nova equipe?
Eu vou pegar um exemplo que lancei numa lista de SCRUM internacional e que gerou uma discussão bem saudável. Um dos maiores preceitos do SCRUM é a melhoria contínua nos processos, tudo isso baseado nas lições aprendidas.
Eu lancei na lista um questionamento sobre como o pessoal MANTINHA e ORGANIZAVA essas lições aprendidas. Muitos afirmaram que não havia necessidade de "rastrear" essas lições aprendidas... pois uma vez que foram identificadas, só precisávamos garantir que a equipe assimilasse-as para os próximos sprints.
Lancei então dois desafios:
1) Será que realmente ao final do sprint 395, a equipe lembraria quais foram as lições aprendidas no sprint 3?
2) As lições aprendidas "assimiladas" podem ser aplicadas na equipe. NA EQUIPE. E se, por acaso, outro projeto acontece com uma nova equipe e/ou Scrum Master? Como essas lições ficariam retidas na empresa?
Enfim, notem como não temos como fugir da documentação disso. Essas lições aprendidas são as informações principais das quais eu defendo tanto. E são essas informações, juntas, que geram o CONHECIMENTO que irá gerar realmente um valor tangível para a empresa.
Após algumas discussões, começamos a discutir sobre a utilização de uma ferramenta muito interessante para a retenção dessas lições aprendidas: o wiki! Acho que todos já entraram no "Wikipedia" e viram o quão poderosa é essa ferramenta de colaboração. Podemos citar, também, os blogs. Afinal, este meu próprio blog não tem como principal preceito a disseminação de "lições aprendidas"? :)
Enfim, como vocês puderam ver eu sou um defensor assíduo da necessidade da retenção da informação/conhecimento para uma empresa. Sem estes dois conceitos, posso afirmar tranquilamente que uma empresa perderá muito! Em competitividade, em retrabalho, em custos...
E você, meu amigo leitor, o que pensa disso? Comente! :)
Um abração
Eu costumo falar que a informação é o sangue da empresa. Sem ela, nada funcionará.
O futuro tende a mostrar que a informação será cada dia mais importante. Aquela empresa que tiver a informação correta, terá um grande diferencial competitivo no mercado. Aquela empresa que tiver conhecimento, terá um diferencial ainda maior!
Uma das coisas que eu senti falta no SCRUM é a gestão da informação e do conhecimento. E por isso que eu costumo dizer que o SCRUM não é de fato um gerenciamento de projeto, mas sim um gerenciamento de processo (minha opinião, é claro!).
Noto em listas que assino (nacionais e internacionais) que existem sempre os extremos: aqueles que acham que a documentação deve ser deixada de lado e aqueles que acham que a documentação é o principal de tudo.
Eu sou da turma do meio. É preciso documentar, mas com parcimônia! E vou dar um exemplo para cada um dos extremos, para ilustrar isso que digo:
Imagine uma empresa que gerou um software para um grande cliente, mas não se dedicou à documentação do mesmo. Colocou apenas alguns parcos comentários nos códigos. Dois anos depois, o cliente liga e pede uma extensão. O problema é que não restou ninguém da equipe que desenvolveu este sistema. E agora? Quanto tempo haverá de retrabalho? Quantas horas se perderão para que a nova equipe entenda estes códigos para só então começar a implantar o novo?
Por outro lado, imagine esta mesma situação, só que a empresa desenvolveu uma documentação de 350 páginas, frente e verso. UML's, documentos de visão, domínio, arquitetura, hardware, software, negócio, etc. quanto tempo essa nova equipe levará para encontrar a informação correta? Levante a mão quem aqui teria SACO para ler um documento técnico de 350 páginas (eu não levantei!).
Vejam como a falta e o excesso são ambos prejudiciais!
Pensem na própria internet, como um excesso de informações! Se queremos pesquisar sobre a utilidade de uma função de determinada linguagem de programação, o Google irá retornar centenas de sites! E lá se vai tempo perdido procurando qual é o site que tem a informação certa...
Portanto, eu sou daqueles que acha que é preciso haver um meio termo nisso. A informação precisa estar retida de alguma forma (documentos, principalmente) mas precisa ser de fácil acesso e localização. E, principalmente, deve conter apenas o ESSENCIAL!
Eu reli alguns documentos que gerei anteriormente e comecei a me dar conta o quão terrível eu escrevi! Os documentos que temos lá são ótimos documentos para um trabalho de conclusão... tem informações de utilidade duvidosa, para nossa empresa. Um exemplo típico foi que perdemos pelo menos duas páginas escrevendo sobre as empresas fabricantes de cada um dos componentes do nosso hardware. Francamente, o que isso agrega para nossa equipe? Ou mesmo para uma nova equipe?
Eu vou pegar um exemplo que lancei numa lista de SCRUM internacional e que gerou uma discussão bem saudável. Um dos maiores preceitos do SCRUM é a melhoria contínua nos processos, tudo isso baseado nas lições aprendidas.
Eu lancei na lista um questionamento sobre como o pessoal MANTINHA e ORGANIZAVA essas lições aprendidas. Muitos afirmaram que não havia necessidade de "rastrear" essas lições aprendidas... pois uma vez que foram identificadas, só precisávamos garantir que a equipe assimilasse-as para os próximos sprints.
Lancei então dois desafios:
1) Será que realmente ao final do sprint 395, a equipe lembraria quais foram as lições aprendidas no sprint 3?
2) As lições aprendidas "assimiladas" podem ser aplicadas na equipe. NA EQUIPE. E se, por acaso, outro projeto acontece com uma nova equipe e/ou Scrum Master? Como essas lições ficariam retidas na empresa?
Enfim, notem como não temos como fugir da documentação disso. Essas lições aprendidas são as informações principais das quais eu defendo tanto. E são essas informações, juntas, que geram o CONHECIMENTO que irá gerar realmente um valor tangível para a empresa.
Após algumas discussões, começamos a discutir sobre a utilização de uma ferramenta muito interessante para a retenção dessas lições aprendidas: o wiki! Acho que todos já entraram no "Wikipedia" e viram o quão poderosa é essa ferramenta de colaboração. Podemos citar, também, os blogs. Afinal, este meu próprio blog não tem como principal preceito a disseminação de "lições aprendidas"? :)
Enfim, como vocês puderam ver eu sou um defensor assíduo da necessidade da retenção da informação/conhecimento para uma empresa. Sem estes dois conceitos, posso afirmar tranquilamente que uma empresa perderá muito! Em competitividade, em retrabalho, em custos...
E você, meu amigo leitor, o que pensa disso? Comente! :)
Um abração
quinta-feira, 13 de dezembro de 2007
Estado da arte: SCRUM no meu trabalho!
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Salve, pessoal!
Sim, fiquei dois dias sem postar. Mas isso se deu por que estava preparando este material aqui, para vocês finalmente conhecerem como é o meu trabalho ;)
Então vamos lá!
AMBIENTE DE TRABALHO
Primeiramente, acho que vale mostrar como está o layout atual do nosso ambiente de trabalho. Esta é a localização do nosso laboratório. É uma sala-laboratório bem comum no nosso prédio da universidade. O laboratório encontra-se, nesta foto, do lado direito. A porta do lado esquerdo é a sala de reuniões, a qual utilizamos muito! O nosso dashboard (veja no capitulo a seguir) é um quadro branco que possui rodinhas, então facilita a mobilidade de um lado para o outro!
A sala de reuniões...
E este é o nosso ambiente de trabalho (desenvolvimento, principalmente):
Notem como não há um claro espaçamento físico do pessoal, ficam todos meio "amontoados". A equipe que está logo a frente é a minha equipe de trabalho. Ao lado direito vocês podem ver parte do nosso dashboard, onde fica o oasis da 3M (fabricante de post-its!).
Agora que vocês conhecem as condições de infra-estrutura do trabalho, vocês conseguem ter em mente mais facilmente a dificuldade que se tem para se concentrar no trabalho, não é? Lembram que eu reclamei estes dias de que havia muita conversa e barulho? Pois é. Notem que existe um espaço enorme e poucas divisões físicas entre as equipes. Aí neste espaço todo trabalham TRÊS equipes, mais dois ou três mestrandos.
Acontece que, se o cara lá de azul (lááá do fundo) resolve falar qualquer coisa do tipo: "E o Grêmio, hein?" esse assunto acaba se tornando geral e TODOS invariavelmente acabam participando da discussão. E em um ambiente de várias pessoas, essas discussões sempre acabam com risadas ou diálogos em voz alta. O tempo que se perde nisso é absurdo, considerando ainda que a maioria trabalha apenas QUATRO horas por dia. Horas produtivas deve ficar, atualmente, em torno de 1h30 se muito!
A minha idéia, para este laboratório, era que as três equipes tivessem uma divisória física. Não precisa ser necessariamente uma parede, mas algo que inibisse essa comunicação excessiva e desnecessária entre todos. Um ambiente aberto destes é propício demais para isso acontecer.
O bom-senso deve prevalecer, é claro. Mas é preciso criar alguns mecanismos para dizer, implicitamente, que quando se está ali é para trabalhar, não para perder tempo com futilidades (lembrem: são apenas QUATRO horas de carga horária! Eles tem outras 20h pra perder com essas coisas!).
DASHBOARD
Um dos principais itens do SCRUM é, sem dúvida alguma, o dashboard. É nele que se concentram todas as informações úteis sobre o sprint atual. Nosso dashboard é um quadro branco, mas cada empresa usa o que tem (nós usamos!). A foto a seguir mostra uma visão geral dele:
Notem que ele é nossa "divisória" também. Isso acabou gerando comentários das outras equipes (sempre na brincadeira, claro). Para eles, somos a "ala vip" do laboratório. Claro que a foto acima não mostra muita coisa. Portanto, tive o cuidado de fotografar mais de perto este dashboard e também colocar um informativo de como ele está dividido. A foto a seguir apresenta este informativo:
Como vocês podem ver, o dashboard está dividido em dois, indicando as duas equipes de trabalho. A equipe delta 1 (de cima) está responsável pelo software embarcado e o "core" do sistema. A equipe delta 2 (debaixo) é responsável pela parte gráfica do sistema, que é um sistema "add-on" ao nosso, apenas para torná-lo mais apresentável (já que será entregue em versão prototipada). O que significa cada item? Vamos lá:
Sprint backlog: são as funcionalidades previstas para serem implementadas neste sprint. O post contem o nome da funcionalidade, a estimativa prevista (escala Fibonacci) e a prioridade. Confesso que faltou identificar o valor do negócio... acho que vale a pena destacar isso, ao invés de deixar apenas "embutido" na prioridade.
Tasks regulares (planejadas): Os post-its amarelos representam aquelas atividades que foram planejadas na reunião de planejamento. Cada post-it é uma tarefa. O post-it contem o nome da tarefa, a duração em dias (neste primeiro sprint, decidimos que TODAS tarefas teriam 2 dias - para não perdermos tempo estimando cada uma) e depois o nome de quem está fazendo. Para fins de atualização do burndown, eu também comecei a marcar quando que elas foram encerradas, só indicando 6a-feira, 2a-feira, etc. para atualizar no dia seguinte.
Informações do sprint: é apenas um post-it indicando informações gerais como: identificação do sprint (sprint 1, sprint 2, etc), data de início, data de fim e qual é o objetivo do sprint (neste caso, decidimos que é "prover a funcionalidade de guiar em linha reta").
Sprint burndown (em dias): o burndown é atualizado sempre no dia seguinte, normalmente durante a daily meeting. É o gráfico que demonstra quantas horas foram vencidas e quantas faltam para encerrar o sprint. Pra mim, é uma das melhores métricas de produtividade já inventadas!
Tasks não-planejadas: os post-its rosas identificam aquelas tarefas que não foram planejadas e surgiram. Normalmente essas atividades incidem no burndown com o acréscimo de horas (o gráfico sobe!) e quase SEMPRE acontecem. Tivemos hoje um caso bem comum, que foi a má identificação de uma tarefa... deixamos ela muito grande, então tivemos que quebrá-la em três. Isso gerou 3 post-its rosas (não aparecem ainda na foto).
Atividades canceladas ou postergadas: esta área do dashboard eu achei bem interessante. Colocamos aqui todas as tarefas que, por algum motivo, foram canceladas ou então postergadas para outro sprint. Estas atividades impactam com a redução de horas no burndown e, para facilitar a visualização, deve ser indicada com algum texto no gráfico para indicar que isso aconteceu.
Impedimentos: os impedimentos são todos aqueles problemas que surgem e que impactam na produtividade da equipe. Até o momento só dois impedimentos ocorreram, que serão resolvidos até amanhã.
Enfim, notem como o dashboard é relativamente simples e extremamente informativo. Qualquer pessoa que saiba dessas informações que eu postei acima, pode chegar ali e saber no mesmo dia em que pé estamos no projeto. Hoje, por exemplo, fiquei bastante feliz ao chegar no trabalho e ver que minha equipe já estava de pé discutindo questões baseadas no dashboard (que foi a questão da quebra da atividade, como mencionei anteriormente).
Realmente, hoje eu confesso que não sei como gerenciava e controlava um projeto sem uma ferramenta dessas! :)
A foto abaixo apenas apresenta uma visão mais de perto destes quatro campos do lado direito do dashboard (informações do sprint, burndown, impedimentos e atividades canceladas):
TÍPICA MESA DE TRABALHO
Abaixo apresento uma foto que mostra uma típica mesa de trabalho... de um engenheiro da computação hehehe. Notem a organização! Mas admito que nunca vi eles se perdendo nesse ambiente. Então não tenho do que reclamar. Este tipo de mesa foi um dos principais fatores para a nossa mudança da empresa para o laboratório. Como receber um cliente em um ambiente assim? Logo, como não tínhamos espaço para dividir o setor comercial do desenvolvimento, a mudança foi a única solução.
Ah sim, notem lá em cima nosso "porco-aranha". Ele é o cofrinho ao qual o pessoal paga 50 centavos caso se atrasem para as reuniões diárias. Esse dinheiro, posteriormente, é rachado entre eles para uma confraternização. Como eu disse, notem que a equipe já fantasiou o porquinho com oculos, bigode e suiças! Ou seja, ele virou um mascote do time!
Ufa.
Com essas fotos, acho que consegui ilustrar bem o estado da arte em que nos encontramos lá no trabalho. Vocês puderam notar como o ambiente não é dos mais propícios, puderam ver como o SCRUM foi adaptado e está funcionando (gerando comentários gerais do tipo "por que não fizemos isso antes, hein?") e, principalmente, como todo esse processo é simples de ser aplicado!
Temos diversos desafios ainda a serem solucionados, muitos dos quais o SCRUM não prevê. Um exemplo é a gestão do conhecimento. Mas isso eu deixo para outro post ;)
Um abraço!
Salve, pessoal!
Sim, fiquei dois dias sem postar. Mas isso se deu por que estava preparando este material aqui, para vocês finalmente conhecerem como é o meu trabalho ;)
Então vamos lá!
AMBIENTE DE TRABALHO
Primeiramente, acho que vale mostrar como está o layout atual do nosso ambiente de trabalho. Esta é a localização do nosso laboratório. É uma sala-laboratório bem comum no nosso prédio da universidade. O laboratório encontra-se, nesta foto, do lado direito. A porta do lado esquerdo é a sala de reuniões, a qual utilizamos muito! O nosso dashboard (veja no capitulo a seguir) é um quadro branco que possui rodinhas, então facilita a mobilidade de um lado para o outro!
A sala de reuniões...
E este é o nosso ambiente de trabalho (desenvolvimento, principalmente):
Notem como não há um claro espaçamento físico do pessoal, ficam todos meio "amontoados". A equipe que está logo a frente é a minha equipe de trabalho. Ao lado direito vocês podem ver parte do nosso dashboard, onde fica o oasis da 3M (fabricante de post-its!).Agora que vocês conhecem as condições de infra-estrutura do trabalho, vocês conseguem ter em mente mais facilmente a dificuldade que se tem para se concentrar no trabalho, não é? Lembram que eu reclamei estes dias de que havia muita conversa e barulho? Pois é. Notem que existe um espaço enorme e poucas divisões físicas entre as equipes. Aí neste espaço todo trabalham TRÊS equipes, mais dois ou três mestrandos.
Acontece que, se o cara lá de azul (lááá do fundo) resolve falar qualquer coisa do tipo: "E o Grêmio, hein?" esse assunto acaba se tornando geral e TODOS invariavelmente acabam participando da discussão. E em um ambiente de várias pessoas, essas discussões sempre acabam com risadas ou diálogos em voz alta. O tempo que se perde nisso é absurdo, considerando ainda que a maioria trabalha apenas QUATRO horas por dia. Horas produtivas deve ficar, atualmente, em torno de 1h30 se muito!
A minha idéia, para este laboratório, era que as três equipes tivessem uma divisória física. Não precisa ser necessariamente uma parede, mas algo que inibisse essa comunicação excessiva e desnecessária entre todos. Um ambiente aberto destes é propício demais para isso acontecer.
O bom-senso deve prevalecer, é claro. Mas é preciso criar alguns mecanismos para dizer, implicitamente, que quando se está ali é para trabalhar, não para perder tempo com futilidades (lembrem: são apenas QUATRO horas de carga horária! Eles tem outras 20h pra perder com essas coisas!).
DASHBOARD
Um dos principais itens do SCRUM é, sem dúvida alguma, o dashboard. É nele que se concentram todas as informações úteis sobre o sprint atual. Nosso dashboard é um quadro branco, mas cada empresa usa o que tem (nós usamos!). A foto a seguir mostra uma visão geral dele:
Notem que ele é nossa "divisória" também. Isso acabou gerando comentários das outras equipes (sempre na brincadeira, claro). Para eles, somos a "ala vip" do laboratório. Claro que a foto acima não mostra muita coisa. Portanto, tive o cuidado de fotografar mais de perto este dashboard e também colocar um informativo de como ele está dividido. A foto a seguir apresenta este informativo:
Como vocês podem ver, o dashboard está dividido em dois, indicando as duas equipes de trabalho. A equipe delta 1 (de cima) está responsável pelo software embarcado e o "core" do sistema. A equipe delta 2 (debaixo) é responsável pela parte gráfica do sistema, que é um sistema "add-on" ao nosso, apenas para torná-lo mais apresentável (já que será entregue em versão prototipada). O que significa cada item? Vamos lá:
Sprint backlog: são as funcionalidades previstas para serem implementadas neste sprint. O post contem o nome da funcionalidade, a estimativa prevista (escala Fibonacci) e a prioridade. Confesso que faltou identificar o valor do negócio... acho que vale a pena destacar isso, ao invés de deixar apenas "embutido" na prioridade.
Tasks regulares (planejadas): Os post-its amarelos representam aquelas atividades que foram planejadas na reunião de planejamento. Cada post-it é uma tarefa. O post-it contem o nome da tarefa, a duração em dias (neste primeiro sprint, decidimos que TODAS tarefas teriam 2 dias - para não perdermos tempo estimando cada uma) e depois o nome de quem está fazendo. Para fins de atualização do burndown, eu também comecei a marcar quando que elas foram encerradas, só indicando 6a-feira, 2a-feira, etc. para atualizar no dia seguinte.
Informações do sprint: é apenas um post-it indicando informações gerais como: identificação do sprint (sprint 1, sprint 2, etc), data de início, data de fim e qual é o objetivo do sprint (neste caso, decidimos que é "prover a funcionalidade de guiar em linha reta").
Sprint burndown (em dias): o burndown é atualizado sempre no dia seguinte, normalmente durante a daily meeting. É o gráfico que demonstra quantas horas foram vencidas e quantas faltam para encerrar o sprint. Pra mim, é uma das melhores métricas de produtividade já inventadas!
Tasks não-planejadas: os post-its rosas identificam aquelas tarefas que não foram planejadas e surgiram. Normalmente essas atividades incidem no burndown com o acréscimo de horas (o gráfico sobe!) e quase SEMPRE acontecem. Tivemos hoje um caso bem comum, que foi a má identificação de uma tarefa... deixamos ela muito grande, então tivemos que quebrá-la em três. Isso gerou 3 post-its rosas (não aparecem ainda na foto).
Atividades canceladas ou postergadas: esta área do dashboard eu achei bem interessante. Colocamos aqui todas as tarefas que, por algum motivo, foram canceladas ou então postergadas para outro sprint. Estas atividades impactam com a redução de horas no burndown e, para facilitar a visualização, deve ser indicada com algum texto no gráfico para indicar que isso aconteceu.
Impedimentos: os impedimentos são todos aqueles problemas que surgem e que impactam na produtividade da equipe. Até o momento só dois impedimentos ocorreram, que serão resolvidos até amanhã.
Enfim, notem como o dashboard é relativamente simples e extremamente informativo. Qualquer pessoa que saiba dessas informações que eu postei acima, pode chegar ali e saber no mesmo dia em que pé estamos no projeto. Hoje, por exemplo, fiquei bastante feliz ao chegar no trabalho e ver que minha equipe já estava de pé discutindo questões baseadas no dashboard (que foi a questão da quebra da atividade, como mencionei anteriormente).
Realmente, hoje eu confesso que não sei como gerenciava e controlava um projeto sem uma ferramenta dessas! :)
A foto abaixo apenas apresenta uma visão mais de perto destes quatro campos do lado direito do dashboard (informações do sprint, burndown, impedimentos e atividades canceladas):
TÍPICA MESA DE TRABALHO
Abaixo apresento uma foto que mostra uma típica mesa de trabalho... de um engenheiro da computação hehehe. Notem a organização! Mas admito que nunca vi eles se perdendo nesse ambiente. Então não tenho do que reclamar. Este tipo de mesa foi um dos principais fatores para a nossa mudança da empresa para o laboratório. Como receber um cliente em um ambiente assim? Logo, como não tínhamos espaço para dividir o setor comercial do desenvolvimento, a mudança foi a única solução.
Ah sim, notem lá em cima nosso "porco-aranha". Ele é o cofrinho ao qual o pessoal paga 50 centavos caso se atrasem para as reuniões diárias. Esse dinheiro, posteriormente, é rachado entre eles para uma confraternização. Como eu disse, notem que a equipe já fantasiou o porquinho com oculos, bigode e suiças! Ou seja, ele virou um mascote do time!Ufa.
Com essas fotos, acho que consegui ilustrar bem o estado da arte em que nos encontramos lá no trabalho. Vocês puderam notar como o ambiente não é dos mais propícios, puderam ver como o SCRUM foi adaptado e está funcionando (gerando comentários gerais do tipo "por que não fizemos isso antes, hein?") e, principalmente, como todo esse processo é simples de ser aplicado!
Temos diversos desafios ainda a serem solucionados, muitos dos quais o SCRUM não prevê. Um exemplo é a gestão do conhecimento. Mas isso eu deixo para outro post ;)
Um abraço!
sábado, 8 de dezembro de 2007
Sprint burndown da 1a semana
Esses são os gráficos das duas equipes.
A equipe "delta 1", responsável pelo sistema principal, está se resolvendo bem. O sprint possui 28 pontos.
A equipe "delta 2", responsável pela parte gráfica do sistema, está com alguma dificuldade pois estão mexendo em uma tecnologia que eles não conheciam ("OpenGL"). O sprint está cotado em 14 pontos.
Detalhe: para o primeiro sprint, TODAS as tarefas (planejadas e não-planejadas) foram cotadas em dois dias (ou dois pontos).
Abraços!
A equipe "delta 1", responsável pelo sistema principal, está se resolvendo bem. O sprint possui 28 pontos.
A equipe "delta 2", responsável pela parte gráfica do sistema, está com alguma dificuldade pois estão mexendo em uma tecnologia que eles não conheciam ("OpenGL"). O sprint está cotado em 14 pontos.
Detalhe: para o primeiro sprint, TODAS as tarefas (planejadas e não-planejadas) foram cotadas em dois dias (ou dois pontos).
Abraços!
quinta-feira, 6 de dezembro de 2007
Joãozinho x Ricardão no mundo empresarial
O assunto rendeu! hehe
Reflexões pessoais, concordâncias, discordâncias... mas o fato é que é um assunto realmente polêmico a questão da "cultura pelo esforço".
Agora façamos outra analogia:
Joãozinho, o estudioso, é daqueles rapazes inteligentes que tem poucos, mas valorizados amigos. Tímido, não namorou na adolescência inteira. Dizia que era melhor ter três BONS amigos do que quinze amigos "superficiais".
Ricardão não. Era o xodó da turma. Amigo das gurias e dos guris, gostava de aprontar sempre que podia. Não era do tipo que batia em todo mundo, muito pelo contrário. Apenas não tinha a aptidão pelo estudo. Ao contrário de Joãozinho, dizia que gostava de ter vários amigos.
Ambos cresceram. Joãozinho se mostrou um profissional capaz. Vai fundo no que gosta de fazer (se formou cientista da computação) e é bastante eficiente no que faz. Mas, por motivos que ele não entende, é sempre relegado quanto à uma promoção.
Já Ricardão se tornou um importante executivo de uma empresa de advocacia. Não é lá muito de estudar (manteve este hábito), mas ainda assim toma suas decisões (a grande maioria acertada) na base do seu conhecimento empírico.
Por que isso aconteceu?
Ora, pelo simples fato que Joãozinho não desenvolveu duas das ferramentas mais importantes em uma pessoa bem sucedida: carisma e a comunicação.
Os Ricardões possivelmente manterão contato com seus quinze amigos. E conhecerão mais quinze amigos e assim será sempre, de forma exponencial. E com isso, ele fará sua network de contatos.
Muitos teóricos dizem que, hoje em dia, não basta ser bom naquilo que se faz. É preciso ter o famoso Q.I. (quem indica). Mas, pensando bem, é preciso mesmo ser teórico para ver isso acontecer? Aposto que você, que está lendo este post, já vivenciou uma situação assim. Um bom funcionário sendo preterido por outro que você não considera bom. Tenha a certeza que este bom funcionário não conhecia a pessoa certa.
Eu fui muito do Joãozinho quando pequeno. Tive poucos amigos (os quais eu cultivo até hoje). Mas nem tudo está perdido. Dia 15 terei minha festa de 10 anos do colégio. Pretendo reaver contato com a maioria dos colegas (também não vou sair distribuindo cartões pra todos né? hehe). Essa é uma grande maneira de começar o seu network de contatos.
A grande maioria da geração pré-internet foi criada de uma forma que está totalmente ultrapassada nos dias de hoje... onde a comunicação quase nunca era trabalhada corretamente. Os comunicativos eram tidos como os "Ricardões". E quem aqui nunca teve raiva/inveja/ódio de algum colega "Ricardão"?
Abraços!
Reflexões pessoais, concordâncias, discordâncias... mas o fato é que é um assunto realmente polêmico a questão da "cultura pelo esforço".
Agora façamos outra analogia:
Joãozinho, o estudioso, é daqueles rapazes inteligentes que tem poucos, mas valorizados amigos. Tímido, não namorou na adolescência inteira. Dizia que era melhor ter três BONS amigos do que quinze amigos "superficiais".
Ricardão não. Era o xodó da turma. Amigo das gurias e dos guris, gostava de aprontar sempre que podia. Não era do tipo que batia em todo mundo, muito pelo contrário. Apenas não tinha a aptidão pelo estudo. Ao contrário de Joãozinho, dizia que gostava de ter vários amigos.
Ambos cresceram. Joãozinho se mostrou um profissional capaz. Vai fundo no que gosta de fazer (se formou cientista da computação) e é bastante eficiente no que faz. Mas, por motivos que ele não entende, é sempre relegado quanto à uma promoção.
Já Ricardão se tornou um importante executivo de uma empresa de advocacia. Não é lá muito de estudar (manteve este hábito), mas ainda assim toma suas decisões (a grande maioria acertada) na base do seu conhecimento empírico.
Por que isso aconteceu?
Ora, pelo simples fato que Joãozinho não desenvolveu duas das ferramentas mais importantes em uma pessoa bem sucedida: carisma e a comunicação.
Os Ricardões possivelmente manterão contato com seus quinze amigos. E conhecerão mais quinze amigos e assim será sempre, de forma exponencial. E com isso, ele fará sua network de contatos.
Muitos teóricos dizem que, hoje em dia, não basta ser bom naquilo que se faz. É preciso ter o famoso Q.I. (quem indica). Mas, pensando bem, é preciso mesmo ser teórico para ver isso acontecer? Aposto que você, que está lendo este post, já vivenciou uma situação assim. Um bom funcionário sendo preterido por outro que você não considera bom. Tenha a certeza que este bom funcionário não conhecia a pessoa certa.
Eu fui muito do Joãozinho quando pequeno. Tive poucos amigos (os quais eu cultivo até hoje). Mas nem tudo está perdido. Dia 15 terei minha festa de 10 anos do colégio. Pretendo reaver contato com a maioria dos colegas (também não vou sair distribuindo cartões pra todos né? hehe). Essa é uma grande maneira de começar o seu network de contatos.
A grande maioria da geração pré-internet foi criada de uma forma que está totalmente ultrapassada nos dias de hoje... onde a comunicação quase nunca era trabalhada corretamente. Os comunicativos eram tidos como os "Ricardões". E quem aqui nunca teve raiva/inveja/ódio de algum colega "Ricardão"?
Abraços!
A cultura do esforço
Li um trecho no livro "Obrigado pela informação que você não me deu" que me fez pensar e reavaliar algumas atitudes não apenas minhas, mas das pessoas da minha volta, no meu trabalho.
Para ilustrar isso, vou contextualizar em uma fábula (baixou o Max Gehringer! hehe).
Anos 80.
Joãozinho era um rapaz muito estudioso no colégio. Daqueles que tirava 10 sempre. Mesmo quando não merecia. Ele dedicava pelo menos duas horas do seu precioso dia de criança para estudar, além das outra cinco horas de colégio que ele tinha.
Ricardão era o oposto de seu colega Joãozinho. Passava, é verdade, mas quase sempre em recuperação e com a nota mínima. Ia ao colégio (quando ia) e dedicava no máximo quinze minutos por semana para estudar.
Se o professor de história dava um trabalho para pesquisar sobre a Revolução Farroupilha, Joãozinho adorava pedir aos seus pais para levá-lo ao museu, gostava de ir até a biblioteca e, se conseguisse convencer, pedir para até um centro de tradições gaúchas para ouvir as histórias da revolução daqueles que tinham ancestrais envolvidos nas batalhas. Já o Ricardão possivelmente copiava metade do trabalho de um e inventava a outra metade. E entregava, meia-boca, mas entregava.
Se o professor de matemática dava um trabalho extenso sobre progressões aritméticas, Joãozinho varava as noites até resolver todas as questões. Não queria ir para a aula, se não tivesse finalizado o trabalho. Já o Ricardão, chutava os resultados daquelas questões que considerava mais complicada.
Quem vocês acham que possivelmente terá uma carreira mais bem sucedida, na era da informação em que se tornarão empregados?
É uma resposta discutível, mas eu posso garantir que o Ricardão teria mais sucesso.
Por quê?
Pensemos em nós, que estudamos na era pré-internet (quando eu sai do 3º ano a internet engatinhava!) o quanto era difícil obter essas informações de trabalhos. Ir para bibliotecas, pesquisar em enciclopédias, almanaques, etc. Quantas vezes nós não nos sentíamos necessitados em sermos recompensados pelo esforço que tivemos? E quantas vezes não fomos, de fato, recompensados por isso? Ou ninguém nunca ouvi de seu professor algo do tipo "pelo seu esforço, te darei uma nota 10!"?
De certa forma, o Joãozinho foi criado para ter uma cultura em que ele necessitasse de reconhecimento pelo esforço. Então possivelmente ele se tornará aquele funcionário que sempre evidenciará, mesmo que sutilmente, que tal resultado gerou um esforço enorme por parte dele e por parte da equipe.
Se nós assistíssemos uma apresentação do Joãozinho para um cliente ou para seu chefe, provavelmente antes de apresentar os resultados, ele evidenciaria as dificuldades enfrentadas, as lições aprendidas, conflitos...
Levante a mão quem nunca conheceu uma pessoa assim! (eu levantei!)
Agora levante a mão quem nunca fez pelo menos uma vez isso! (... eu levantei!)
É errado querer ser conhecido pelo esforço? Claro que não.
Mas daí eu faço o inverso. Se coloque na posição de um cliente ou de seu chefe. Para você, interessa saber o quanto de esforço árduo a equipe dedicou ao projeto? Ou será mais interessante ver o resultado? Você, como chefe, aguentaria toda uma "contextualização" até chegar ao resultado de fato? E se você for um cliente cujo o tempo é o bem mais precioso?
O imediatismo em que o mundo se tornou (a necessidade de informações rápidas e de qualidade) agora preza por RESULTADOS. Você pode até evidenciar o seu esforço, mas faça isso em uma conversa informal... não em uma apresentação ao seu superior ou cliente.
E o Ricardão? Por nunca ter sido afetado muito pela cultura do esforço, provavelmente amadurecerá e com certeza terá muito mais chances de ser uma pessoa focada em resultados. E seus chefes o amarão por isso. Ele se tornará o porta-voz e elo principal da diretoria. Estou exagerando?
Enfim, infelizmente todos aqueles que estudaram na era "pré-internet" acabaram adquirindo (uns mais, outros menos) essa cultura do esforço, onde acabamos nos tornando dependentes deste reconhecimento por parte dos demais. É uma herança muito ruim que tivemos e que devemos lutar para mudar.
Mas e nos dias de hoje, se um aluno para obter dados sobre a Revolução Farroupilha? Digita www.google.com e toda informação estará ao seu dispôr.
Que tipo de perfil estaremos produzindo com isso? Não sou sociólogo, mas poderia apostar que o resultado será na cultura do EXCESSO de informação. Como a informação se tornará abundante, os alunos começarão a achar que o reconhecimento se dará pelo maior número de páginas.
Já imaginaram o inferno que será, se eles levarem isso para o mundo empresarial? Ao invés do tempo perdido para apresentar o esforço obtido, teremos dados redundantes e informações totalmente desnecessárias sendo transmitidas e gerando muito, mas muito ruido para quem está nos assistindo.
Ufa! Eu pensei nisso hoje e quis compartilhar com vocês. É um assunto que eu considero crítico (qualidade da informação), pois nós, como gerentes de projetos, trabalhamos em 90% do tempo com comunicação. E se utilizarmos este tempo com comunicação ineficaz?
E você? Já passou por alguma situação na "cultura do esforço"? Comente aí!
Grande abraço
Para ilustrar isso, vou contextualizar em uma fábula (baixou o Max Gehringer! hehe).
Anos 80.
Joãozinho era um rapaz muito estudioso no colégio. Daqueles que tirava 10 sempre. Mesmo quando não merecia. Ele dedicava pelo menos duas horas do seu precioso dia de criança para estudar, além das outra cinco horas de colégio que ele tinha.
Ricardão era o oposto de seu colega Joãozinho. Passava, é verdade, mas quase sempre em recuperação e com a nota mínima. Ia ao colégio (quando ia) e dedicava no máximo quinze minutos por semana para estudar.
Se o professor de história dava um trabalho para pesquisar sobre a Revolução Farroupilha, Joãozinho adorava pedir aos seus pais para levá-lo ao museu, gostava de ir até a biblioteca e, se conseguisse convencer, pedir para até um centro de tradições gaúchas para ouvir as histórias da revolução daqueles que tinham ancestrais envolvidos nas batalhas. Já o Ricardão possivelmente copiava metade do trabalho de um e inventava a outra metade. E entregava, meia-boca, mas entregava.
Se o professor de matemática dava um trabalho extenso sobre progressões aritméticas, Joãozinho varava as noites até resolver todas as questões. Não queria ir para a aula, se não tivesse finalizado o trabalho. Já o Ricardão, chutava os resultados daquelas questões que considerava mais complicada.
Quem vocês acham que possivelmente terá uma carreira mais bem sucedida, na era da informação em que se tornarão empregados?
É uma resposta discutível, mas eu posso garantir que o Ricardão teria mais sucesso.
Por quê?
Pensemos em nós, que estudamos na era pré-internet (quando eu sai do 3º ano a internet engatinhava!) o quanto era difícil obter essas informações de trabalhos. Ir para bibliotecas, pesquisar em enciclopédias, almanaques, etc. Quantas vezes nós não nos sentíamos necessitados em sermos recompensados pelo esforço que tivemos? E quantas vezes não fomos, de fato, recompensados por isso? Ou ninguém nunca ouvi de seu professor algo do tipo "pelo seu esforço, te darei uma nota 10!"?
De certa forma, o Joãozinho foi criado para ter uma cultura em que ele necessitasse de reconhecimento pelo esforço. Então possivelmente ele se tornará aquele funcionário que sempre evidenciará, mesmo que sutilmente, que tal resultado gerou um esforço enorme por parte dele e por parte da equipe.
Se nós assistíssemos uma apresentação do Joãozinho para um cliente ou para seu chefe, provavelmente antes de apresentar os resultados, ele evidenciaria as dificuldades enfrentadas, as lições aprendidas, conflitos...
Levante a mão quem nunca conheceu uma pessoa assim! (eu levantei!)
Agora levante a mão quem nunca fez pelo menos uma vez isso! (... eu levantei!)
É errado querer ser conhecido pelo esforço? Claro que não.
Mas daí eu faço o inverso. Se coloque na posição de um cliente ou de seu chefe. Para você, interessa saber o quanto de esforço árduo a equipe dedicou ao projeto? Ou será mais interessante ver o resultado? Você, como chefe, aguentaria toda uma "contextualização" até chegar ao resultado de fato? E se você for um cliente cujo o tempo é o bem mais precioso?
O imediatismo em que o mundo se tornou (a necessidade de informações rápidas e de qualidade) agora preza por RESULTADOS. Você pode até evidenciar o seu esforço, mas faça isso em uma conversa informal... não em uma apresentação ao seu superior ou cliente.
E o Ricardão? Por nunca ter sido afetado muito pela cultura do esforço, provavelmente amadurecerá e com certeza terá muito mais chances de ser uma pessoa focada em resultados. E seus chefes o amarão por isso. Ele se tornará o porta-voz e elo principal da diretoria. Estou exagerando?
Enfim, infelizmente todos aqueles que estudaram na era "pré-internet" acabaram adquirindo (uns mais, outros menos) essa cultura do esforço, onde acabamos nos tornando dependentes deste reconhecimento por parte dos demais. É uma herança muito ruim que tivemos e que devemos lutar para mudar.
Mas e nos dias de hoje, se um aluno para obter dados sobre a Revolução Farroupilha? Digita www.google.com e toda informação estará ao seu dispôr.
Que tipo de perfil estaremos produzindo com isso? Não sou sociólogo, mas poderia apostar que o resultado será na cultura do EXCESSO de informação. Como a informação se tornará abundante, os alunos começarão a achar que o reconhecimento se dará pelo maior número de páginas.
Já imaginaram o inferno que será, se eles levarem isso para o mundo empresarial? Ao invés do tempo perdido para apresentar o esforço obtido, teremos dados redundantes e informações totalmente desnecessárias sendo transmitidas e gerando muito, mas muito ruido para quem está nos assistindo.
Ufa! Eu pensei nisso hoje e quis compartilhar com vocês. É um assunto que eu considero crítico (qualidade da informação), pois nós, como gerentes de projetos, trabalhamos em 90% do tempo com comunicação. E se utilizarmos este tempo com comunicação ineficaz?
E você? Já passou por alguma situação na "cultura do esforço"? Comente aí!
Grande abraço
quarta-feira, 5 de dezembro de 2007
Segundo dia... duas tarefas vencidas!
Nós estipulamos que as primeiras tarefas seriam padronizadas como todas tendo DOIS dias de duração.
Portanto, hoje conseguimos matar duas tarefas (quatro dias!). O pessoal estava bem empolgado hoje... acho que assimilaram bem o papel.
Uma pena que um deles não pôde ir, então a equipe "delta 2" acabou ficando prejudicada (não mataram nenhuma tarefa ainda). Mas como eles mexerão só com software, não é tão problemático.
---------------------------
Hoje estive lendo a respeito de "agile patterns" (padrões de agilidade) para software. É algo bem interessante, mas que demanda bastante tempo de assimilação e leitura. Acho que vou ter que assimilar mais além...
Portanto, hoje conseguimos matar duas tarefas (quatro dias!). O pessoal estava bem empolgado hoje... acho que assimilaram bem o papel.
Uma pena que um deles não pôde ir, então a equipe "delta 2" acabou ficando prejudicada (não mataram nenhuma tarefa ainda). Mas como eles mexerão só com software, não é tão problemático.
---------------------------
Hoje estive lendo a respeito de "agile patterns" (padrões de agilidade) para software. É algo bem interessante, mas que demanda bastante tempo de assimilação e leitura. Acho que vou ter que assimilar mais além...
terça-feira, 4 de dezembro de 2007
Ready ,set, GO!!
Hoje demos início ao nosso primeiro sprint.
Acredito que já começamos atrasados, mas tudo bem. O primeiro nem sempre é bom...
Somamos 16 story points para uma equipe (2 funcionalidades) e 21 story points para outra equipe (1 funcionalidade).
As equipes são Delta 1 (2 funcionalidades) e Delta 2 (1 funcionalidade).
Basicamente a D1 trabalha no software/hardware, e a D2 faz toda a parte gráfica, em OpenGL.
Nossa dashboard ficou dividida em duas partes (uma para cada equipe) com o trio TODO/DOING/DONE, mais uma área para "atividades não planejadas" e um gráfico do sprint burndown para cada (dias de trabalho restantes x dias do sprint).
Ficou similar ao dashboard que eu apresentei recentemente aqui.
Vamos ver o que teremos ao final deste sprint... estou bem curioso! hehe
Abraços!
Acredito que já começamos atrasados, mas tudo bem. O primeiro nem sempre é bom...
Somamos 16 story points para uma equipe (2 funcionalidades) e 21 story points para outra equipe (1 funcionalidade).
As equipes são Delta 1 (2 funcionalidades) e Delta 2 (1 funcionalidade).
Basicamente a D1 trabalha no software/hardware, e a D2 faz toda a parte gráfica, em OpenGL.
Nossa dashboard ficou dividida em duas partes (uma para cada equipe) com o trio TODO/DOING/DONE, mais uma área para "atividades não planejadas" e um gráfico do sprint burndown para cada (dias de trabalho restantes x dias do sprint).
Ficou similar ao dashboard que eu apresentei recentemente aqui.
Vamos ver o que teremos ao final deste sprint... estou bem curioso! hehe
Abraços!
segunda-feira, 3 de dezembro de 2007
Sugestão de livro: "Obrigado pela informação que você NÃO me deu"
Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br
Pessoal,
comecei a ler este livro e achei muito interessante. O autor aborda a questão da necessidade da simplicidade e objetividade na informação que transita nas organizações. Questione-se: quantas vezes você saiu de uma reunião sem ao menos saber o que foi dito? Ou quantas vezes você assistiu àquela apresentação de PowerPoint com um livro inteiro em um slide, ou pior, uma apresentação de uma hora com 80 slides pela frente?
O autor, especialista no assunto, propõe diversas reflexões sobre a forma de trabalharmos melhor com a informação. É um livro cheio de passagens em que a informação foi bem/mal utilizada, e suas consequências.
Estou mantendo contato com o autor para ele ser um entrevistado para o (quase abandonado) podcast do blog. Calma, o podcast volta ainda essa semana ;)
Abraços!
Pessoal,
comecei a ler este livro e achei muito interessante. O autor aborda a questão da necessidade da simplicidade e objetividade na informação que transita nas organizações. Questione-se: quantas vezes você saiu de uma reunião sem ao menos saber o que foi dito? Ou quantas vezes você assistiu àquela apresentação de PowerPoint com um livro inteiro em um slide, ou pior, uma apresentação de uma hora com 80 slides pela frente?
O autor, especialista no assunto, propõe diversas reflexões sobre a forma de trabalharmos melhor com a informação. É um livro cheio de passagens em que a informação foi bem/mal utilizada, e suas consequências.
Estou mantendo contato com o autor para ele ser um entrevistado para o (quase abandonado) podcast do blog. Calma, o podcast volta ainda essa semana ;)
Abraços!
sábado, 1 de dezembro de 2007
Dinâmica para vivenciar SCRUM
Salve pessoas!
Durante o meu curso de SCRUM vivenciamos algumas dinâmicas interessantes para entendermos alguns conceitos da metodologia. Em linhas gerais, vivenciamos três dinâmicas: uma para tentarmos gerenciar o caos, uma para trabalharmos com estimativas e teamwork e a última para aplicarmos de vez os conceitos do SCRUM.
Baseado nesta experiência resolvi adaptar algumas dinâmicas e criar uma em que principalmente conceitos de "melhoria continua", "processos empíricos", "estimativas" e "teamwork" fossem vivenciados. De quebra, eles puderam notar como um processo de melhoria continua sofre pouca interferência de mudanças (seja de escopo, seja de outras variáveis).
Se você quiser acompanhar este post, sugiro que baixe a dinâmica e acompanhe enquanto você lê este post. Baixe a dinâmica neste link.
O nome da dinâmica se chama "FÁBRICA DE AVIÕES".
Você irá precisar de:
- De 150 a 200 folhas de papel (A4). Podem ser de rascunho (aliás, devem!). Mas um dos lados deve ser branco.
- Duas canetas (uma para cada time).
- Duas caixas para guardar os aviões prontos (uma para cada).
- Saco de lixo (para juntar tudo e doar para algum papeleiro!).
Divida sua turma em dois grupos de forma aleatória. Você precisa, para que fique tudo "redondo" que as duas equipes possuam o mesmo número de pessoas. Caso isso não seja possível, deixe uma com um a mais mesmo... isso pode acabar até mesmo não sendo uma vantagem...
Uma das equipes pode se chamar "Airbusão" e a outra "Boing-boing". É a sugestão que eu dou :)
Desenhe então, a seguinte tabela em um quadro branco:
Complete o formato até o sétimo sprint (eu tentei fazer mais do que isso e realmente o pessoal começa a cansar).
Em seguida, desenhe um gráfico com o eixo X representando o número do sprint e o eixo Y representando a estimativa de cada sprint. Este gráfico será muito útil para a sua turma notar de fato como a experiência (processos empíricos) tornam nossas estimativas mais corretas.
Aliás, você pode citar, antes de começar, que uma pesquisa recente apontou que os erros em estimativas em projetos de software estão na margem de -25% até 300%. Comente sobre isso, para que o impacto ao final da dinâmica seja muito boa!
Ok, com os times montados, a tabela e o gráfico prontos para serem preenchidos, comece a ler a dinâmica (você pode excluir os slides TODO que estão expressos na dinâmica).
Eu não pretendo repetir o que está escrito no arquivo PPT. Mas se possível tente criar um clima teatral enquanto lê o contexto... isso ajuda a tornar a dinâmica mais divertida.
Leia rapidamente os slides 1 e 2.
No slide 3, sobre as regras, explique o seguinte:
- Os ciclos de desenvolvimento (sprints) irão durar 2 minutos. E eles terão depois 1 minuto para reavaliar seus processos e dar uma nova estimativa de produção.
- O tempo DEVE ser respeitado por todos. Lembre-os que é uma dinâmica para eles vivenciarem o SCRUM e não uma competição que valha alguma coisa.
- Se o tempo encerrar com algum avião em produção, o mesmo pode ser utilizado para o próximo sprint.
- Eles podem se organizar da forma que quiserem, DESDE QUE o mesmo avião passe pelas mãos de todos. Ou seja, NÃO PODE CADA UM FAZER O SEU! A idéia é que eles trabalhem como se fosse uma linha de montagem.
- Os aviões devem respeitar os critérios de aceitação que o cliente exigir.
Leia então os slides 4 e 5, que explicam o contexto (dois países rivais lutando para dominar o espaço aéreo). Um dos países aborda os dois grupos e pedem uma estimativa de quantos aviões eles conseguem produzir em DOIS minutos. Dê a eles 1 minuto para responder.
Obviamente agora eles irão perguntar: "Tá, mas como é o avião?". Finja que o ditador do país que solicitou isso está muito ocupado e não pode responder. Ele apenas quer uma estimativa.
O segredo aqui é que eles vivenciem a estimativa de uma incerteza. Eles tem que dar uma quantidade baseada no puro "achômetro". Não há escopo, só uma idéia (avião de papel).
Possivelmente as estimativas serão altas (no meu caso foram 20 e 15). Se você conseguir isso, você pode ter certeza que o resultado final será perfeito! Caso não consiga, não se preocupe. Você pode mostrar depois como as estimativas melhoraram com o tempo. Mas valores altos no começo apenas ilustram aquela margem dos -25-300% :)
Feito isso, marque os valores citados na coluna "Estimativa inicial".
Leia então os slides 7 e 8. A idéia é que eles produzam seus aviões seguindo aquele escopo do slide 8. Aqui começa a parte divertida. Eles terão 2 minutos para produzir um protótipo com aquelas informações. Na minha aplicação os dois aviões foram COMPLETAMENTE diferentes um do outro, o que foi mais divertido ainda!
Ao final da prototipação, coloque o slide 9 e fale para cada um do grupo apresentar seu avião ao outro grupo. Pegue então os aviões e avalie usando o seguinte critério:
- Veja se existem 6 janelas em cada lado. Caso contrário critique dizendo que você queria DOZE lugares, nem mais, nem menos.
- Veja se existe uma cabine em cada lado. Caso não, pergunte como o piloto irá guiar ou então como irá olhar para um dos lados.
- Veja se há o logotipo da "meia-lua e estrela) nas duas asas e nos dois lados, no final do avião.
- Veja se o pessoal fez o teste para ver se ele voa, ou se fez só na hora da apresentação. Comente que você esperava que o produto fosse apresentado já testado.
- E aqui o grande pega ratão: duvido que alguém coloque PORTAS no avião! Questione como seus passageiros irão entrar no avião!
Em seguida, mostre o slide 10 e mostre qual era a idéia do cliente. Anuncie qual é a empresa vencedora e diga que ela representará a "Zarábia do Sul". Comente que aquele avião que está no slide 10 é que deve ser produzido a partir de agora.
Leia os slides 11 e 12 que apenas mostra que a "Zarábia do Norte" irá contratar a outra empresa para começar a disputa pelo domínio do espaço aéreo. E que agora eles tem 1 minuto para discutir como será o processo de produção e com base naquele produto pedido, eles devem dar uma estimativa para produção.
Anote no "I" do "1º sprint" e leia o slide 13. Comece a produção!
Agora até o 3º sprint você irá anotar no "R" o resultado final de cada sprint das empresas. E em seguida dará 1 minuto para eles se replanejarem e darem nova estimativa.
No 4º sprint, anuncie que ocorreu um evento inesperado! Leia o slide 14 "Espionagem". Pegue duas pessoas de cada time (procure pegar aqueles mais extrovertidos ou mais produtivos) e troque eles de time. O resultado é bem divertido, com um brincando que não deve revelar a produção de cada um dos times. Eles então devem ter 1 minuto para se readequar a situação nova e dar nova estimativa.
Anote novamente na coluna do 4º sprint a estimativa e o real produzido.
No 5º sprint (ou se você preferir deixar para mais além - embora eu não recomende para não ficar cansativo), avise que outro evento ocorreu. E que ele é catastrófico.
Mude para o slide 15 "GUERRA". Leia o slide 16 e em seguida apresente o slide 17 com as mudanças solicitadas para a produção de aviões de guerra (aqui é a mudança de escopo, devido a necessidade).
Então agora o 5º, 6º e 7º sprint se sucedem dessa forma.
Ao final do 7º sprint, leia o slide 19 e enfatize que somente os aviões de guerra é que valerão para anunciar o vencedor!
Agora normalmente irá se suceder alguma comemoração, brincadeira ou algo similar. No meu caso, eles ficaram brincando de guerra de aviões um com os outros - inclusive meus chefes! Eu não recomendo isso, pois eles podem se machucar.
Tente reorganizar o pessoal e passe os slides seguintes, item por item. E discuta o que aconteceu durante a dinâmica. Note como eles aceitarão de fato que com a experiência dos processos, eles conseguiram atingir e as vezes até superar as estimativas. E que elas cada vez ficavam mais corretas.
Note que a mudança de escopo e a "espionagem" afetou pouco a produção real (embora eles geralmente devam baixar a estimativa quando ocorrem estes eventos).
Por fim, mostre com o gráfico como de fato eles puderam tornar o processo não só uma melhoria continua, mas também como com as lições aprendidas alimentando as discussões, as estimativas se tornaram cada vez mais exatas.
Ufa! Comigo a dinâmica foi um sucesso. Todos adoraram e todas as perguntas que eles tinham sobre SCRUM, eles puderam vivenciar de fato. Note que o SCRUM é basicamente a aplicação do ciclo PDCA na nossa vida, onde nós planejamos, fazemos, checamos e depois aplicamos as correções necessárias para tudo começar de novo.
Espero que tenham gostado. E se vocês aplicarem a dinâmica, por favor, postem aqui nos comentários!
Baixe a dinâmica em PPT aqui.
Um grande abraço
Durante o meu curso de SCRUM vivenciamos algumas dinâmicas interessantes para entendermos alguns conceitos da metodologia. Em linhas gerais, vivenciamos três dinâmicas: uma para tentarmos gerenciar o caos, uma para trabalharmos com estimativas e teamwork e a última para aplicarmos de vez os conceitos do SCRUM.
Baseado nesta experiência resolvi adaptar algumas dinâmicas e criar uma em que principalmente conceitos de "melhoria continua", "processos empíricos", "estimativas" e "teamwork" fossem vivenciados. De quebra, eles puderam notar como um processo de melhoria continua sofre pouca interferência de mudanças (seja de escopo, seja de outras variáveis).
Se você quiser acompanhar este post, sugiro que baixe a dinâmica e acompanhe enquanto você lê este post. Baixe a dinâmica neste link.
O nome da dinâmica se chama "FÁBRICA DE AVIÕES".
Você irá precisar de:
- De 150 a 200 folhas de papel (A4). Podem ser de rascunho (aliás, devem!). Mas um dos lados deve ser branco.
- Duas canetas (uma para cada time).
- Duas caixas para guardar os aviões prontos (uma para cada).
- Saco de lixo (para juntar tudo e doar para algum papeleiro!).
Divida sua turma em dois grupos de forma aleatória. Você precisa, para que fique tudo "redondo" que as duas equipes possuam o mesmo número de pessoas. Caso isso não seja possível, deixe uma com um a mais mesmo... isso pode acabar até mesmo não sendo uma vantagem...
Uma das equipes pode se chamar "Airbusão" e a outra "Boing-boing". É a sugestão que eu dou :)
Desenhe então, a seguinte tabela em um quadro branco:
Complete o formato até o sétimo sprint (eu tentei fazer mais do que isso e realmente o pessoal começa a cansar).Em seguida, desenhe um gráfico com o eixo X representando o número do sprint e o eixo Y representando a estimativa de cada sprint. Este gráfico será muito útil para a sua turma notar de fato como a experiência (processos empíricos) tornam nossas estimativas mais corretas.
Aliás, você pode citar, antes de começar, que uma pesquisa recente apontou que os erros em estimativas em projetos de software estão na margem de -25% até 300%. Comente sobre isso, para que o impacto ao final da dinâmica seja muito boa!
Ok, com os times montados, a tabela e o gráfico prontos para serem preenchidos, comece a ler a dinâmica (você pode excluir os slides TODO que estão expressos na dinâmica).
Eu não pretendo repetir o que está escrito no arquivo PPT. Mas se possível tente criar um clima teatral enquanto lê o contexto... isso ajuda a tornar a dinâmica mais divertida.
Leia rapidamente os slides 1 e 2.
No slide 3, sobre as regras, explique o seguinte:
- Os ciclos de desenvolvimento (sprints) irão durar 2 minutos. E eles terão depois 1 minuto para reavaliar seus processos e dar uma nova estimativa de produção.
- O tempo DEVE ser respeitado por todos. Lembre-os que é uma dinâmica para eles vivenciarem o SCRUM e não uma competição que valha alguma coisa.
- Se o tempo encerrar com algum avião em produção, o mesmo pode ser utilizado para o próximo sprint.
- Eles podem se organizar da forma que quiserem, DESDE QUE o mesmo avião passe pelas mãos de todos. Ou seja, NÃO PODE CADA UM FAZER O SEU! A idéia é que eles trabalhem como se fosse uma linha de montagem.
- Os aviões devem respeitar os critérios de aceitação que o cliente exigir.
Leia então os slides 4 e 5, que explicam o contexto (dois países rivais lutando para dominar o espaço aéreo). Um dos países aborda os dois grupos e pedem uma estimativa de quantos aviões eles conseguem produzir em DOIS minutos. Dê a eles 1 minuto para responder.
Obviamente agora eles irão perguntar: "Tá, mas como é o avião?". Finja que o ditador do país que solicitou isso está muito ocupado e não pode responder. Ele apenas quer uma estimativa.
O segredo aqui é que eles vivenciem a estimativa de uma incerteza. Eles tem que dar uma quantidade baseada no puro "achômetro". Não há escopo, só uma idéia (avião de papel).
Possivelmente as estimativas serão altas (no meu caso foram 20 e 15). Se você conseguir isso, você pode ter certeza que o resultado final será perfeito! Caso não consiga, não se preocupe. Você pode mostrar depois como as estimativas melhoraram com o tempo. Mas valores altos no começo apenas ilustram aquela margem dos -25-300% :)
Feito isso, marque os valores citados na coluna "Estimativa inicial".
Leia então os slides 7 e 8. A idéia é que eles produzam seus aviões seguindo aquele escopo do slide 8. Aqui começa a parte divertida. Eles terão 2 minutos para produzir um protótipo com aquelas informações. Na minha aplicação os dois aviões foram COMPLETAMENTE diferentes um do outro, o que foi mais divertido ainda!
Ao final da prototipação, coloque o slide 9 e fale para cada um do grupo apresentar seu avião ao outro grupo. Pegue então os aviões e avalie usando o seguinte critério:
- Veja se existem 6 janelas em cada lado. Caso contrário critique dizendo que você queria DOZE lugares, nem mais, nem menos.
- Veja se existe uma cabine em cada lado. Caso não, pergunte como o piloto irá guiar ou então como irá olhar para um dos lados.
- Veja se há o logotipo da "meia-lua e estrela) nas duas asas e nos dois lados, no final do avião.
- Veja se o pessoal fez o teste para ver se ele voa, ou se fez só na hora da apresentação. Comente que você esperava que o produto fosse apresentado já testado.
- E aqui o grande pega ratão: duvido que alguém coloque PORTAS no avião! Questione como seus passageiros irão entrar no avião!
Em seguida, mostre o slide 10 e mostre qual era a idéia do cliente. Anuncie qual é a empresa vencedora e diga que ela representará a "Zarábia do Sul". Comente que aquele avião que está no slide 10 é que deve ser produzido a partir de agora.
Leia os slides 11 e 12 que apenas mostra que a "Zarábia do Norte" irá contratar a outra empresa para começar a disputa pelo domínio do espaço aéreo. E que agora eles tem 1 minuto para discutir como será o processo de produção e com base naquele produto pedido, eles devem dar uma estimativa para produção.
Anote no "I" do "1º sprint" e leia o slide 13. Comece a produção!
Agora até o 3º sprint você irá anotar no "R" o resultado final de cada sprint das empresas. E em seguida dará 1 minuto para eles se replanejarem e darem nova estimativa.
No 4º sprint, anuncie que ocorreu um evento inesperado! Leia o slide 14 "Espionagem". Pegue duas pessoas de cada time (procure pegar aqueles mais extrovertidos ou mais produtivos) e troque eles de time. O resultado é bem divertido, com um brincando que não deve revelar a produção de cada um dos times. Eles então devem ter 1 minuto para se readequar a situação nova e dar nova estimativa.
Anote novamente na coluna do 4º sprint a estimativa e o real produzido.
No 5º sprint (ou se você preferir deixar para mais além - embora eu não recomende para não ficar cansativo), avise que outro evento ocorreu. E que ele é catastrófico.
Mude para o slide 15 "GUERRA". Leia o slide 16 e em seguida apresente o slide 17 com as mudanças solicitadas para a produção de aviões de guerra (aqui é a mudança de escopo, devido a necessidade).
Então agora o 5º, 6º e 7º sprint se sucedem dessa forma.
Ao final do 7º sprint, leia o slide 19 e enfatize que somente os aviões de guerra é que valerão para anunciar o vencedor!
Agora normalmente irá se suceder alguma comemoração, brincadeira ou algo similar. No meu caso, eles ficaram brincando de guerra de aviões um com os outros - inclusive meus chefes! Eu não recomendo isso, pois eles podem se machucar.
Tente reorganizar o pessoal e passe os slides seguintes, item por item. E discuta o que aconteceu durante a dinâmica. Note como eles aceitarão de fato que com a experiência dos processos, eles conseguiram atingir e as vezes até superar as estimativas. E que elas cada vez ficavam mais corretas.
Note que a mudança de escopo e a "espionagem" afetou pouco a produção real (embora eles geralmente devam baixar a estimativa quando ocorrem estes eventos).
Por fim, mostre com o gráfico como de fato eles puderam tornar o processo não só uma melhoria continua, mas também como com as lições aprendidas alimentando as discussões, as estimativas se tornaram cada vez mais exatas.
Ufa! Comigo a dinâmica foi um sucesso. Todos adoraram e todas as perguntas que eles tinham sobre SCRUM, eles puderam vivenciar de fato. Note que o SCRUM é basicamente a aplicação do ciclo PDCA na nossa vida, onde nós planejamos, fazemos, checamos e depois aplicamos as correções necessárias para tudo começar de novo.
Espero que tenham gostado. E se vocês aplicarem a dinâmica, por favor, postem aqui nos comentários!
Baixe a dinâmica em PPT aqui.
Um grande abraço
Assinar:
Postagens (Atom)
Postagens
