Enquete deste mês

Olhem que curioso. A enquete deste mês, aqui do blog, foi uma espécie de auto-reflexão de cada visitante.

Notem que tivemos (neste momento em que escrevo) 34 participantes.

44% (15 pessoas) deles estão empregados e DESCONTENTES!

Infelizmente é difícil de inferir sobre o motivo disso. Mas será que é devido a cultura da empresa? Relacionamento no trabalho? Falta de desafios? Subvalorização? Salário baixo?

Confesso que fiquei curioso... mas ao mesmo tempo espero que essa simples enquete (e mesmo o blog) sirva para estes colegas refletirem um pouco mais. Será que não vale a pena trocar de emprego, e sair da zona de conforto? Será que não vale a pena aparecer um pouco mais na empresa, ser mais visto para ser valorizado? Será que esse descontentamento não tem um pouco de nós mesmos?

Enfim, leia este post, em que eu reflito um pouco sobre isso também :)

Um grande abraço e ótimo final de semana.

Curso de dicção, oratória e desnibição

Finalmente irei fazer o curso! Neste final de semana :)

Ao final do curso, eu vou ver se consigo publicar o vídeo do "antes" e "depois". E daí os meus leitores que tirem as suas conclusões se vale ou não a pena investir num curso de comunicação ;)

Abraços

Ok, eu me rendo!

Já que ninguém falou nada, eu me rendo sozinho.

Como eu posso falar de "administração contemporânea" e continuar chamando minha equipe de "funcionários"?

O hype agora é COLABORADORES :)

Portanto, me corrijam se virem isso de novo ok??

Abraços

Prova PMP com questão maluca!

Recebi este email da lista da empresa onde eu fiz o curso de PMP (quando eu aprendi mais sobre o PMBoK). Quem escreve é o Mauro Sotille. Olhem que maluquice o que o PMI fez...

Pessoal,

O debate hoje nos fóruns de discussão sobre a certificação PMP é uma pergunta que tem caído no exame PMP, sobre um tema que praticamente ninguém tinha ouvido falar: BIPERT Float (Flutuação BIPERT).

A primeira resposta é que BIPERT seria simplesmente um erro tipográfico no exame. Posteriormente, começamos a receber relatos que realmente existiria uma flutuação BIPERT e que isto estaria caindo no exame.

Um aluno que fez o exame em 31 de Julho viu esta questão. Foi apresentado um diagrama de rede (PDM – atividade no nó), com aproximadamente 25 atividades e se solicitou encontrar uma atividade BIPERT!!!

Outro aluno fez a prova em 09 de Junho e caiu a mesma questão: Um diagrama atividade-no-nó perguntando qual dos 4 nodos tinha uma “flutuação BIPERT”

Assim começou uma procura louca, a nível mundial, nos inúmeros fóruns de debate, sobre o que seria a flutuação BIPERT.

Vejam o desalento do Andrew Stellman, autor dos livros “Head First” (muito bons, por sinal (http://www.amazon.com/Head-First-PMP-Brain-Friendly-Professional/dp/0596102348 ) : “ Ilooked through the various project management textbooks that I have, and I couldn't find a single reference to anything called "bipert". It doesn't appear anywhere in the PMBOK(r) Guide. There's nothing about it in Wikipedia. It may be an important project management concept that none of us have heard of. If so, I'm not sure how to learn about it. (Every PMP exam has 25 questions that don't count towards the score -- they're experimental questions used by PMI to gauge the exam. I wonder if the bipert question was one of these. I suspect that if you see bipert on the exam, there's a good chance that particular question won't count towards your score... but that is just a guess on my part.) I have no idea how you'd apply that to project management, and I'm surprised it ended up in a question on the PMP exam. If I were taking the exam today and had to know about BIPERT, I'd get that question wrong.”

O que é Flutuação BIPERT?

A resposta certa parece ser que seria a de indicar a atividade com links em ambas as direções.

Até agora há somente um artigo, entitulado "Workload Modeling for Parallel Processing Systems" (escrito em 1995 por Gabriele Kotsis para sua tese de Doutorado – Universidade de Viena), com referências a Bipert. Até 30 de Junho este era o único documento a fazer referência a este termo. A referência a BIPERT pode ser encontrada somente na bibliográfica da tese de 201 páginas. Isto é o que está escrito:

"BIBLIOGRAPHY

P. H. Cubaud. “Evaluation of Parallel Programs Completion Time using Bilogic PERT Networks.” Tech. Rep. 91-7, EHEI, Ecole des Hautes Etudes en Informatique, 45, rue des Saints-Peres, 75006 Paris France, September 1991. In this article a bilogic extension of PERT networks (called BIPERT) is proposed as a suitable model for parallel programs. An example of modeling a parallel wave equation algorithm using GERT networks described in SLAM can be found in [Sinz 93] In [Cuba 91] a bilogic extension of PERT networks (called BIPERT) is proposed as a suitable model for parallel programs. In a BIPERT network, ingoing and outgoing links may either be inclusive (IN) or exclusive (EX), thus allowing to represent amongst parallelism also conditional branches and alternative parallelism, but also dead ends (if a node spawns several inclusive outgoing links, which are collected later on in an exclusive ingoing). Graphs containing such dead constructs are prohibited and called unlegal. A network where all nodes are IN/IN or EX/EX types, belongs to the class of series_parallel graphs, where exact analytic solution techniques are feasible. All other networks are to be solved using simulation or approximation techniques.

“Em uma rede BIPERT, os links de entrada (ingoing) e saída (outgoing) podem ser inclusivos ou exclusivos, desse modo permitindo a representação de paralelismo e de ramos condicionais ....”; ou seja, BIPERT é um tipo de PERT booleano: verdadeiro/falso : vai acontecer ou não este evento.. Assim seria muito difícil calcular a solução analítica exata.

As questões que começaram então a ser feitas:

Porque este termo entrou em um exame PMP?

Resposta: Mistério. Um termo obscuro e não utilizado, que não está no PMBOK.

É parte das 25 questões de teste?

Resposta: Não sabemos

Este tópico tem alguma importância, de modo que o candidato deva aprende-lo?

Resposta: BIPERT não é uma técnica de análise de diagrama de rede e, de qualquer modo, está ultrapassado devido ao uso de ferramentas e técnicas mais modernas de simulação

Este tópico vai estar no PMBOK 4a Edição?
Resposta: Este tópico não está no PMBOK 4a Edição. PERT somente é referenciado no que diz respeito às estimativas de 3 pontos.

Nós (e o mundo), vamos continuar procurando pela resposta correta: Por enquanto a mais certa parece que seria a de indicar a atividade com links em ambas as direções.

Isto É ed. 2024 (Capa do Michael Phelps)

A IstoÉ da semana passada (esta que é descrita no tópico) traz uma reportagem na página 64 muito interessante e que vale a pena ser lida por todos nós, principalmente aqueles que lideram ou lidam com pessoas.

O título é "Você é o que você fala" e traz algumas dicas para ser ouvido e compreendido num mundo em que cada palavra conta.

Na verdade o texto fala sobre neurolinguistica, uma corrente que muitas pessoas tem restrições. Eu já li um livro curto sobre o assunto e posso dizer que achei bem interessante.

Vamos ao que interessa: a reportagem traz algumas dicas interessantes sobre como mudar a sua forma de se comunicar. Uma simples mudança de palavras já modifica completamente o contexto e a mensagem que estamos passando. Um exemplo simples que a reportagem traz é trocar o "eu acho" por "penso que". Quem nunca recebeu um olhar de desaprovação e desconfiança quando lhe foi solicitado para emitir alguma opinião e a nossa resposta foi "eu acho que até o fim da semana está pronto"? E se você trocasse por "penso que até o fim da semana teremos isto pronto"? Não soa melhor? Sim! Pelo simples fato que "achar" tende a demonstrar incerteza e "pensar" sugere uma elaboração.

Existem na reportagem outros exemplos... vale a pena dar uma olhada.

Só vale ressaltar uma coisa: lembre-se que a comunicação não vive só de palavras. Entonação da voz, expressão corporal... tudo isso passa mais a mensagem do que palavras. Logo se você falar "penso que até o fim da semana teremos o sistema pronto" mas mantiver aquele rosto com a testa franzida, olhar perdido pra cima e algum cacoete como coçar a cabeça, de nada vai adiantar :)

Nós, quando lidamos com pessoas, percepções e expectativas, precisamos MUITO passar confiança no que fazemos. Eu estou buscando mudar bastante isso. Nessa semana, por exemplo, o meu chefe me perguntou do sistema abaixo, se até sexta-feira teríamos ele pronto. Eu falei "Olha, acho que sim". ÓBVIO que o resultado foi que o meu chefe me olhou com aquela cara de "ih, não vai ficar pronto". Vendo a "pataquada" que eu havia cometido, tentei consertar com um "... depende do que tu queres pronto!". Não foi a melhor resposta possível, mas ajudou a minimizar o estrago! Mas de qualquer forma, como você pode ler no post anterior, não só entregamos o sistema como encantamos os meus chefes ;)

Fica a sugestão da reportagem. Comunicar-se bem é algo que devemos estar sempre buscando. Não acham?

Abração e bom domingo.

Sexta-feira, o dia do "yes!"

Nesta última sexta-feira aconteceu uma coisa que eu merecia (sem falsa modéstia).

Vocês que acompanham o blog sabem que eu sempre costumo expressar minhas opiniões sobre comunicação, liderança, gestão, etc. Porém, sabem também o quanto eu tenho de problemas no trabalho, devido a falta de uma cultura de projetos, principalmente.

O que estava acontecendo então? Eu me sentia aquele cara que sabe tudo na teoria, mas que nunca consegue colocar as coisas em prática. É um sentimento muito ruim, desmotivador, inclusive.

Desde que eu assumi esse "projeto" (já que me foi jogado no colo para eu "resolver") eu tive um pequeno desacerto com o meu chefe, vi meus antigos funcionários cairem fora, recebi um novo funcionário (indicação de outro chefe) e tive diversos problemas com os requisitos do projeto.

Eu estava crente que seria mais um projeto que iria para o lixo, sem chance alguma de sucesso, qualquer que fosse o meu esforço. Eu me senti como se estivesse numa competição do "Aprendiz" em que o Trump ou o Justus me jogam para a arena com uma espada de madeira para lutar com uma dezena de gladiadores e leões. Embora a analogia seja meio pobre, posso dizer que mostra o sentimento de impotência que eu estava sentindo.

Porém, algo me motivou. Inicialmente eu comecei a pensar que de nada adiantaria eu ficar em cima do muro, fazendo apenas o necessário para depois dizer "eu avisei que não ia dar certo". Eu precisava encarar isso como um desafio e fazer o que fosse possível para resolver a situação. Junto a isso, e que foi um daqueles suplementos alimentares na minha motivação, o fato do novo funcionário ser um jovem de excelente competência técnica, me mostrou que SIM eu posso obter ótimos resultados tendo uma equipe razoável e um desafio pela frente.

Nesta sexta-feira os meus dois chefes me solicitaram para ver o projeto, onde estávamos, o que havíamos feito, etc. E o que eu apresentei a eles, não apenas solucionou os problemas propostos como ainda consegui ir além.

Desenvolvemos em uma semana: um software para o celular (a melhor solução possível para um problema crítico deste projeto - que envolve um processo específico), dois sistemas de relatórios via web (para demonstrar o que podemos manipular em nível de dados), além de uma pesquisa sobre os processos envolvidos, com soluções propostas e vantagens e desvantagens. Tudo isso em um Powerpoint para ser apresentado ao cliente. O que eu fiz, basicamente, foi tentar orientar essa "demanda" em um projeto. E espero fazer isso após a reunião com o cliente.

A reação dos meus dois chefes foi daquelas de deixar qualquer subordinado animado. Eles sairam felizes! A sensação foi de que superamos as expectativas deles. Lógico que a expectativa deles também não era muito alta, pois eles sabem o histórico ali do laboratório... mas ainda assim foi uma das únicas vezes que eu vi os meus chefes realmente satisfeitos com o que viram (de cabeça, eu lembro da vez que apresentamos o antigo projeto na feira, que o meu chefe ficou muito feliz também, mas apenas um deles... o outro não estava envolvido).

Enfim, a sexta-feira foi a recompensa que eu há muito estava buscando. O resultado da minha superação em atingir um resultado e superá-lo, inclusive. Fui gerente de projetos, analista, desenvolvedor e DBA (analista de banco de dados). Não é o que eu quero que se repita - e irei deixar isso claro futuramente - mas o esforço valeu a pena.

Por pior que seja o nosso ambiente de trabalho (o meu é ruim apenas na questão organizacional, vale ressaltar) nós sempre temos um objetivo em comum: encantar nosso cliente. Seja ele o cara que compra o seu produto ou mesmo o cara que paga o seu salário. Nada melhor do que atingir isso.

A lição que dá pra tirar disso é: se você está desmotivado, busque motivação. Se você quer passar uma mensagem, a melhor forma de fazer isso é motivado, atingindo um bom resultado... e depois apresentar uma forma alternativa de superar aquilo. Nenhum chefe vai dar atenção a alguém que falha (para depois dizer "eu avisei") e se demonstra desmotivado. Porém, se você tiver os holofotes por algo bom que tenha feito, sua mensagem será potencializada. Tenha a certeza disso.

Sexta-feira: o dia em que eu esperei por um bom tempo chegou. E o seu? Lute para que ele chegue o mais cedo possível.

Apresentação: Essência de Gerenciamento de Projetos

Prezados,

conforme eu havia prometido, aqui está o pdf com a apresentação que eu fiz na turma de gerenciamento de projetos, na turma de graduação da PUCRS, no dia 19/08.

Foi muito legal a apresentação. A receptividade da turma foi excelente. Eu estourei bastante o tempo e ainda assim notei muita gente interessada na palestra. Essa é a força de trazer "cases" e situações para nossas palestras, além de ser um pouco teatral também :)

Também consegui trazer uma visão "agilista" de gerenciamento de projetos, sem ser radical ou aparentar fazer "lavagem cerebral". Acho que essa abordagem também foi bastante eficiente.

Faça o download aqui

Ah, e sempre reforço que no icone do menu direito (seção de downloads) você pode baixar as outras apresentações além dos podcasts, videos, documentos, artigos, etc. Faça bom proveito.

Revista MundoPM Ago/Set 08

Eu assinei por um bom tempo essa revista. Mas o excesso de artigos extremamente técnicos e fora da minha área específica (TI) fizeram eu optar por não renovar a assinatura. Os artigos possuem uma linguagem bastante técnica e alguns são intragáveis. Costumava ler um ou dois artigos, no máximo.

Porém, a edição deste mês (ago/set) possui três artigos BEM interessantes!

O primeiro trata sobre o novo processo do PMBOK, "Coletar requisitos". E ali traz algumas informações bacanas (técnicas e ferramentas, principalmente). Vale a pena dar uma olhada.

O melhor de tudo, porém, é que a edição possui DOIS artigos sobre processos ágeis.

O primeiro artigo, de autoria de Otávio Ritter dos Santos, é excelente. Além de abordar os processos ágeis de uma forma bem abrangente ele ainda apresenta todos os métodos na forma das disciplinas do PMBOK (custos, integração, escopo, etc). Se você pretendia convencer alguém a experimentar métodos ágeis, esse artigo vai ajudar muito. Principalmente o pessoal familiarizado com o PMBOK.

O segundo artigo, de autores internacionais, fala mais especificamente do SCRUM, abordando algumas questões de equipe. Bastante interessante a leitura também.

Enfim, comprem essa edição. Eu recomendo. Seja você de TI ou outros :)

Um abraço

Semana pesada

Devem ter percebido que eu não tive quase tempo para postar aqui. Pois é, essa semana foi bastante corrida.

Afora o trabalho, onde tínhamos um prazo pra hoje (que acabou sendo estendido devido a impossibilidade de reunião com o cliente), ainda fiz uma palestra para a graduação (disciplina de gerência de projetos - falando sobre a essência de projetos) e também um trabalho no meu MBA!

Quero ver se hoje, sem falta, eu publico aqui o material dessa palestra.

Como eu disse no post anterior, é impressionante a mudança que se tem no andamento do projeto quando se atua com as pessoas certas. Estamos desenvolvendo um software... com uma pessoa de software! Pode parecer óbvio, mas lá no trabalho isso era encarado como "Ah, os outros tiveram uma disciplina de programação, como é que não conseguem fazer algo direito?!".

O grande erro, na minha opinião, é que estamos fazendo protótipos. De novo. Devido ao tempo, à falta de comunicação com o cliente (o meu chefe fala que ele sabe tudo o que precisa... mas alguém acredita?)... então novamente estamos perdendo recursos (tempo e dinheiro) fazendo algo que será apenas para mostrar a idéia para o cliente e não algo já com valor.

Eu estou tentando mudar isso, mas é complicado.

Trabalhando com gente competente!

Nossa, como faz diferença trabalhar com gente competente.

Sexta-feira eu havia pedido para o novo funcionário para realizar um módulo do sistema. Eu tava acostumado a esperar uma semana para ver resultados... mas o cara terminou HOJE!! Levei um susto hehe

Enfim, valorizar as competências tem que ser a primeira coisa a ser feita, em uma empresa. Seja grande ou pequena.

Desculpem pelo post rápido, mas estou meio na corrida!

Abraços

Porque eu escrevo este blog

Por causa do Rogério:

Bom Flavio,

se vc deseja um feedback, aqui vai o meu:
como disse em outro comentário que fizacho o seu blog muito legal, pois vc cita coisas que acontecem no dia a dia de cada um de nos que trabalhamos com tecnologia, e muitas vezes nos faz parar e pensar: "putz, igual ao que acontece aqui comigo!". Comigo me leva a refletir como tenho que melhorar muito ainda, seja profissionalmente ou na vida pessoal mesmo.
Levar na cabeça é normal, embora muitas vezes nós não estamos preparados para lidar com determinadas situações, por mais que nos esforcemos estudando sobre determinado assunto e como reagir a ele.
So posso te desejar boa sorte e que vc consiga ajudar a empresa onde trabalha a melhorar a sua forma de pensar o trabalho e o ramo de mercado que atuam, para que ela possa crescer cada vez mais.

Do Cesar:

Muito, muito, muito bom mesmo! Flavio, vou repercutir este teu post lá no i-scrum.ning.com e botar um link permanente para o teu blog, pode ser? Abraços!

Da Yanina:

Oi,Flávio. Eu sou Yanina, uma argentina que por acaso caiu no seu blog há um tempo e gostou bastante por duas razões: a primeira, meu namorado é gerente de prójetos de uma pequena empresa de desenvolvimento de software aqui em Buenos Aires e foi muito engraçado ler os mesmos problemas que ele tem todos os dias...a segunda razão, e peço desculpas pelo atrevimento,é que eu estou lecionando português nessa e em outra empresa que trabalha para o Brasil e estou utilizando alguns dos teus posts para todo tipo de exercícios...

Talvez não tenha nada a ver, mas estava me sentindo em falta utilizando o teu blog sem te avisar...

Qualquer dúvida, ou se você tem problemas com que eu continue "roubando" os teus posts, é só avisar...

abraços... yan

Da Fabiana:

Essa figura passa com exatidão a diferença entre uma e outra.

Muito show o blog estou sempre passando por aki e lendo os materiais.

Parabéns Flávio!

Do Wili:

Grande Flávio!
Já leu o livro "Seja Assertivo!"?
É de um pouco disso que você tá precisando (todos nós precisamos).
Dá uma lida e depois me fala.

Abraço
Willi

E de tantos outros leitores que deixam sempre o seu feedback aqui. Seja para acrescentar, corrigir, discordar, concordar, observar, refletir... enfim.

Um grande abraço aos leitores e comentaristas :)

E se você lê o blog, não hesite de deixar um alô com alguma experiência sua. Quero ver esse post bater o recorde de comentários. Será que conseguimos?

Vou deixar este post até domingo :)

Quero que VOCÊ, leitor, se apresente e conte algum fato que ocorreu com você recentemente. Vamos lá, duas frases. Não custa nada!

Abraços!

Dia desorganizado!

Eu não sei qual é a impressão que eu passo para os meus leitores aqui. Muitas vezes escrevo algumas coisas como desabafo ou como alguma observação pessoal sobre trabalho e afins. Não sei se alguém possa pensar "pô, esse cara sabe das coisas!". Espero que não! :)

Na verdade eu sou um gerente de projetos que está no seu terceiro ano de projetos. Levei muito na cabeça para aprender e continuo levando e aprendendo. Mas procuro transformar esses hematomas em lições para não cometer o mesmo erro. A idéia do blog, em si, era demonstrar que você, caro leitor, não está sozinho neste mundo. Existe também um gerente de projetos como você, que também erra. E muito!

Hoje por exemplo. Era um dia em que começava no trabalho um novo funcionário.

O meu chefe me avisou disso na quinta-feira passada. Ontem eu recepcionei ele, conversei MUITO brevemente e acertamos algumas coisas burocráticas (horario, valores, etc). Ele é um rapaz bastante "cru", será sua primeira experiência profissional. Mas senti fé nele, parece ser bastante interessado. Inclusive comentei com ele que para mim a atitude costuma ser mais importante que o simples conhecimento. Marcamos que ele começaria hoje.

Então... para começar cheguei atrasado no trabalho. Ele ficou 15 minutos meio perdido lá no trabalho, sem saber o que fazer. Levei ele na sala de reuniões para explicar o projeto, mas expliquei de uma forma tão apressada que nem eu mesmo entendi os meus raciocínios! Depois fui colocá-lo em uma estação de trabalho e então eu simplesmente percebi que não tinha planejado NADA para ele fazer. NADA! Ficou uma situação bem cômica, eu pensando: "Ahm... tu podes fazer.... vamos ver....". Pedi então para ele buscar a respeito de um programa que iremos utilizar.

Depois aproveitei que um dos envolvidos no projeto estava no laboratório e pedi para ele explicar como funcionava o banco de dados do sistema. Ao invés de ajudar, acho que confundi mais ainda o novato!

Em seguida chegou um dos outros envolvidos no projeto. Pedi para eles se alinharem. Mas foi tudo meio "engembrado". Não sei ao certo o que os dois conversaram.

Pra completar, estive em reunião e não consegui ver o que ele fez até o fim do dia. Enfim, não quero nem imaginar a imagem que ele teve do seu primeiro dia de trabalho: um gerente de projetos atrapalhado, um bando de doidos como colegas, um projeto impossível.

Enfim, foi um dia que deu TUDO errado!

Amanhã espero tentar apagar um pouco essa sensação terrível que ele deve ter sentido hoje. Ou talvez nem sentiu, já que nunca teve outra experiência profissional. Bom, vamos ver amanhã...

O que se pode concluir? Leia o meu blog, se divirta e reflita sobre o que eu escrevo. Faça o que eu digo, mas não faça o que eu faço, já diria o ditado. Mas não tire o que eu digo aqui como "verdade" ou "fundamentação". Jamais! :)

Um grande abraço

Choque cultural e falta de identidade...

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Sexta-feira perdi dois ex-funcionários meus. Motivo? Eles diziam que não queriam seguir o rítmo que estava sendo impondo e muito menos ficar trabalhando em projetos "batata assada".

Um projeto estilo "batata assada", como eu chamo, é aquele projeto em que a diretoria te aloca sem te dar nenhuma explicação maior (faz uma reunião explicando o que é o projeto, o que deve ser entregue) e te dá um prazo "para ontem". Outras características: não temos poder para definir escopo, prazo, equipes e muito menos planejamento. Tudo é inferido pela diretoria: eles acham que somos capazes, eles acham que a equipe porque trabalhou no projeto A vai aprender o projeto ABC em dois minutos, etc.

O rítmo de trabalho que está sendo imposto é o comum de algumas empresas. Cobrança por resultados, desenvolvimento de produtos ao invés de protótipos e pesquisas, padronização de alguns comportamentos, "comando & controle", mais horas trabalhadas, etc.

Agora vamos analisar. Considerando que estamos em um grupo de pesquisa, normalmente em projetos de pesquisa (mesmo que alguns envolvam empresas), com pessoas com mentalidade de pesquisa e num ambiente onde não existe perspectivas de crescimento profissional, como é que a diretoria realmente quer comprometimento do pessoal simplesmente fazendo as mudanças descerem goela abaixo?

Eu não tenho a menor dúvida do que irá acontecer: assim como meus ex-funcionários sairam, outros vão se dar conta e sair fora. Entre receber X reais em um grupo de pesquisa e X reais em uma empresa, para onde vocês acham que as pessoas boas e inteligentes vão preferir ir?

É uma pena. Mas ao que parece a diretoria não está pensando estrategicamente. Muitas coisas poderiam ser feitas para tornar o grupo de pesquisa um centro de excelência. Mas dessa forma... acho difícil.

Abraços

Correções de links

Acabo de descobrir que alguns links para download (principalmente os mais antigos, como os do podcast) estão quebrados. Estou corrigindo todos, mas peço aos leitores que se identificarem algum problema, postem comentários avisando ok? :)

Abraços!

Dinâmica: fábrica de aviões versão 2.0

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Pessoal, com atraso estou publicando para vocês a dinâmica da fábrica de aviões que apliquei na turma de "Especialização em gerenciamento de projetos" na PUCRS. A idéia da dinâmica é vivenciar os conceitos do SCRUM, de forma prática, facilitando a visualização dos benefícios. Usamos bastante o conceito PDCA e processos empíricos, que são algumas das bases do SCRUM.

Esta dinâmica foi desenvolvida com base na primeira versão, só que agora ela se tornou mais "ágil" e divertida. Por quê? Inseri algumas novas variáveis e situações que tornam ela mais aderente ao que desejamos passar, ou seja, o conceito do SCRUM.

Para acompanhar este post, é legal você primeiro baixá-la no link abaixo.

Baixar a dinâmica (PDF)
Baixar a tabela em excel (XLS)
Baixar as fichas de responsabilidades (PPT)

Qual a essência da dinâmica? Criar uma linha de produção de aviões de papel que segue uma regra bem simples: a folha de papel começa numa ponta e "termina" avião na outra ponta. Na dinâmica que eu apliquei, foram 3 equipes com 7 membros cada. Se você tiver mais gente envolvida, tente manter no máximo 4 equipes com os membros necessários. Assim você consegue fazer o papel de Product Owner, avaliando o que foi produzido. Crie nomes do alfabeto grego para as equipes (no meu caso foram Sigma, Omega e Gama. Você já verão o por quê disso.

Avise as equipes que a forma como eles se organizarão para fazer a engenharia é com eles. Se quiserem ficar de pé, organizar as mesas em círculos, etc. é problema deles. DESDE QUE o produto comece numa ponta e acabe na outra. Além disso, a outra restrição é que não pode haver estocagem de material, ou seja, cada grupo só pode pegar mais 10 folhas quando a última folha entrar em produção. Isso existe só para tornar o processo mais difícil e para dar trabalho ao Scrum Master, na hora dos sprints :)

A estrutura da dinâmica é simples: as equipes tem três minutos para discutir o processo (retospectiva e planejamento) e ao final do tempo passam a estimativa de produção. Depois elas tem três minutos para produzir o que prometeram, conforme as definições do escopo solicitadas. E assim por diante (ciclo PDCA).

Neste primeiro momento, os papéis não existem ainda. O cliente fictício é a Força Aérea. É informado que a organização quer um novo avião e entrou em contato com as empresas deles. Então a organização quer saber das equipes quantos aviões eles produzem em três minutos. E eles tem UM minuto para dar a estimativa.

Isso mesmo, curto e grosso assim. Qual a idéia por trás? Quantas vezes nossos clientes e chefes chegam para nós: "Quanto tempo a gente entrega um sistema de cadastro e relatórios para o cliente XYZ?". "Bem... depende, como é o escopo?". "Escopo? É um sistema de cadastro e relatórios!! Quanto tempo?". Notaram a semelhança? É exatamente essa. Dar uma estimativa de algo que não se tem a menor idéia. No fim da dinâmica, na retrospectiva, isso serve para avaliar como as estimativas melhoram quando a equipe trabalha e conhece sua capacidade.

Enquanto as equipes fazem as estimativas, abra a planilha Excel para fazer o controle do "previsto / realizado". E marque ali assim que eles derem as estimativas.

Continuando, passe para eles que a Força Aérea gostou das estimativas. E vai abrir concorrência. Agora, a organização passou o escopo do avião. Com base no escopo, as equipes terão 3 minutos para produzir um protótipo. O escopo é bem simples:

- O avião deve possuir 12 janelas
- Deve possuir uma cabine
- Deve possuir o logotipo da empresa que está produzindo, nas asas e na cauda (o logotipo tem que ser o símbolo do Sigma, Gama, Omega - aqui é outra pegadinha!)

Note que não é dito "que tipo de avião" deve ser produzido. A idéia é mesmo que as equipes quebrem a cara na hora de apresentar o protótipo. Esse é o momento mais divertido da dinâmica. Se as equipes perguntarem algo mais sobre o escopo, diga que você não sabe... a organização não passou mais informações.

Cuidado para não passar o próximo slide, onde tem o projeto que a Força Aérea quer. Esse slide é para depois das apresentações!!

Após a produção, peça para um de cada equipe vir até a frente e apresentar o avião. No final, faça o teste do vôo. Não esqueça de solicitar os aplausos para cada apresentação :)

Depois das apresentações, passe o feedback de cada avião. Compare os protótipos com a idéia do que o cliente queria (o slide que mostra isso). Uma coisa que quase nenhuma equipe coloca é PORTA. Pergunte: "Como o pessoal vai entrar no avião???". Se eles reclamarem que isso não foi dito no escopo, fale: "Mas precisava dizer?!". Aqui é a velha demonstração das expectativas do cliente versus produção. :)

Pronto. Agora eles já sabem o que deve ser produzido. Então as linhas de produção vão começar. Diga que eles terão 3 minutos para avaliar a engenharia que irão utilizar para o processo e ao final, passarão a estimativa de produção. Eles deverão produzir os aviões criteriosamente conforme o escopo passado. Aqueles que, ao final dos três minutos do sprint, não estiverem de acordo (faltou uma janelinha, faltou o logotipo correto, etc) não contam como finalizados, mas podem voltar para a linha de produção para serem finalizados. Essa regra é importante e segue os princípios do SCRUM.

Antes de começar, porém, é preciso definir os papéis. Utilize as fichas que estão ali em cima para download (imprima mais fichas "membro da equipe"). Diga que você irá passar para cada um dos membros das equipes uma ficha contendo o papel deles na equipe. Invente que as equipes serão multi-funcionais e cada um terá um papel para desempenhar. Diga que eles devem ler a ficha e atuar conforme está escrito ali e não devem comentar com ninguém quais são suas atribuições.

Por que dessa cena toda? Porque os papéis nas equipes são: SCRUM MASTER (não pode produzir, deve cuidar do time, avaliar o processo, remover impedimentos e buscar matéria-prima), MEMBRO DO TIME (produzirá o produto e avaliará o processo) e ... ELO FRACO.

Cada equipe tem UM Scrum Master e UM Elo Fraco (se você quiser colocar dois por equipe, dependendo do tamanho, é uma idéia interessante também). O Elo Fraco tem como função principal ser exatamente a pessoa que atrasa o processo todo. Aquele cara descompromissado, que destoa dos demais. É o gargalo do time. Mas ele participará do time como se quisesse melhorar o processo (dará sugestões, etc), mas na produção será sempre o gargalo. Ele tem que ser um bom ator e não pode deixar ninguém saber que ele está atuando assim, dai a importância de deixar claro que ninguém pode ler a ficha do outro (se possível, recolha as fichas após eles lerem).

Sabendo disso, diga que o SCRUM MASTER deverá sair da linha de produção e ficar de pé, auxiliando o time nas suas funções. Ele, lógico, pode dizer o que pode ou não fazer.

Feito isso, as regras estão expostas, o escopo é sabido e os papéis e responsabilidades são conhecidos. Dê o start para que eles comecem a planejar o processo e ao final passar a estimativa.

Uma sugestão que causa um efeito psicológico bacana: Durante esses períodos de planejamento, controle o tempo e passe para eles quanto tempo falta para encerrar. Mas nos sprints não avise o tempo, só diga quando encerrou. A idéia é que o Scrum Master ou a equipe percebam que eles que tem que controlar o tempo.

Ao final do planejamento, eles começam os sprints de 3 minutos. Repita daí o processo de "planejamento/estimativa 3 minutos" e "sprint 3 minutos". São três sprints (um número ideal para ninguém cansar ou encher o saco!).

Quando as equipes passarem as estimativas, marque na planilha Excel, na coluna "previsto". Quando você fizer a contagem dos produtos finalizados (que devem estar totalmente de acordo com o escopo) marque na outra coluna "realizado". Assim até acabarem os sprints.

Ao final do terceiro sprint, veja qual foi a equipe vencedora (a que entregou o maior número de produtos). Entregue algum prêmio, como uma caixa de "Bis" para motivá-los :)

Encerrada a dinâmica, avalie com o pessoal como foi o processo. Revele os papéis "obscuros" que existiam nas equipes (os elos fracos) e questione se a equipe havia percebido isso e se tomaram alguma atitude para contornar o problema. Avalie a questão do protótipo versus expectativa do cliente... a questão do trabalho em equipe... a identificação do limite de produção da equipe... o desafio de superar esse limite... a questão do empowerment (onde os membros da equipe avaliavam o processo e tinham poder de sugerir mudanças)... os benefícios da inspeção e adaptação com base na experiência... e encerre comentando a idéia de usar sprints de trabalho.

Faça a pergunta que contém no slide: "Seria melhor entregar todos os aviões em 10 minutos ou % deles a cada 3 minutos?". Dificilmente alguém dirá que o ideal será a primeira opção. Lembre da teoria do estudante (deixar tudo para a última hora), a motivação que será alta nos primeiros minutos e depois cairá com o tempo (afetando a produção).

Antes de terminar, abra a segunda aba da planilha Excel, onde tem o gráfico baseado nas estimativas passadas. Demonstre que o primeiro ponto representa a estimativa quando eles não sabiam NADA do que tinha que ser feito (quando a Força Aérea pediu estimativa sem passar nada). As outras estimativas já foram com base na experiência e no conhecimento do escopo. Possivelmente você terá um gráfico que começa mais alto ou baixo e que depois tende a ficar parecido com uma reta, estabilizando. A idéia é que a gente erra nas estimativas iniciais em +400% e -20%, normalmente. E com o tempo, conhecendo o escopo e nossos limites de produção, as estimativas tendem a ser mais próximas à realidade e tendem a estabilizar. Comente que se houvessem novas sprints, o gráfico se estabilizaria de vez, cabendo à equipe e ao Scrum Master a idéia de tentar encontrar soluções para superar aos poucos estes limites.

Por exemplo, se as equipes produzissem 15 aviões no máximo, o que eles teriam que fazer para otimizar o processo para produzirem 17-18? E assim sucessivamente, quando conseguissem atingir os resultados.

Por fim conclua, demonstrando que eles vivenciaram a essência do SCRUM, ou seja, um ciclo PDCA onde eles planejaram o que fariam, realizavam as tarefas, checavam e avaliavam o processo e por fim tomavam decisões de mudança com base nisso, para alimentar o planejamento.

Termine desafiando: "E se usássemos isso na produção de um software?". Aí é discussão para não acabar mais :)

Ufa! Apesar deste texto longo, eu tenho certeza que você conseguirá aplicar essa dinâmica com o mesmo sucesso que eu tive ao aplicar na turma de especialização em gerenciamento de projetos, na PUCRS. Ali foi muito bacana. Os momentos mais divertidos foram na prototipação e durante os sprints (tive a sorte de escolher bem quem seriam os elos fracos - que foram excelentes atores!).

Ao final da dinâmica, todos entenderam a essência do SCRUM. A mensagem foi passada com total sucesso e tenho a certeza que abriu um novo horizonte para aqueles que não conheciam essas práticas.

Use essa dinâmica como um reforço para passar a mensagem do SCRUM ou mesmo para vender a idéia para sua diretoria. Apesar do pretexto bobo (criar aviões de papel) tenha a certeza de que ao final todos vão ficar bastante satisfeitos com o resultado.

Peço encarecidamente que, quem for aplicar a dinâmica, me envie um email contando como foi a experiência :)

Um grande abraço e façam bom uso!

Decisões nem sempre populares...

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Hoje tive que tomar uma decisão nada popular para a equipe. Sabendo que o projeto em que estávamos estava encerrado (pelo menos na minha visão) e que a equipe ficaria o mês de julho ociosa... e sabendo ainda que o projeto não tem mais verba, tive que tomar a decisão que considerei mais justa para a empresa e para a equipe: fazer o pagamento dos salários de meio mês de trabalho.

O problema: a equipe acabou sabendo disso HOJE quando recebeu.

Por quê? Simplesmente o meu chefe não se decidia. Eu tentava falar com ele pedindo uma decisão, e ele não respondia objetivamente. Então hoje abracei a idéia e tomei a atitude que considerei a melhor, dadas as circunstâncias.

A equipe não recebeu bem a notícia, claro. Mas tratei de conversar com eles e explicar os motivos da minha decisão e assumir a decisão como sendo minha. Notei que isso, apesar do impacto negativo da atitude, melhorou um pouco a percepção deles... uma vez que joguei em pratos limpos com eles.

O segundo problema: eles vão trabalhar este mês em outro projeto... e vão receber como? Isso é outra história. Que possivelmente será bem enrolada também.

Enfim, lá vou eu falar a palavrinha mágica que originou este problema todo: COMUNICAÇÃO. Sempre.

Dinâmica 2.0

Pessoal, ainda hoje eu publico pra vocês a dinâmica "Fábrica de aviões 2.0" que é uma versão bem melhor da dinâmica que eu havia criado anteriormente, para vivenciar SCRUM.

Introduzi algumas variáveis e situações bacanas, que tornam a dinâmica mais "ágil" e divertida.

Vão gostar :)

Abraços

Just a "perfect" day...

Hoje foi mais um daqueles dias típicos de uma pequena empresa e (des)organização.

Ontem mobilizei novamente a equipe do meu projeto, pois o meu chefe disse que queria finalizar o projeto com os testes no trator (do nosso protótipo) sendo aprovados. Então mobilizei a equipe para que eles estudassem o que precisaríamos para completar o projeto. Em paralelo, tive uma bomba para resolver: os pagamentos. Nosso projeto de pesquisa está sem verbas. Logo, o pagamento sairá do bolso da empresa. Prevendo isso, eu desmobilizei a equipe fazendo-a trabalhar apenas 15 dias. Assim negociei com os meus chefes do pagamento apenas destes 15 dias, reduzindo o impacto do custo no bolso deles.

Hoje, eu estava trabalhando no planejamento dos próximos 15 dias de projeto, até o teste no trator. Recém havia enviado um email para o meu chefe, e o meu outro chefe passou na minha mesa e falou: "Flávio, preciso falar contigo e com a tua equipe". Ok, fui até o laboratório e chamei a todos. Fomos para a sala de reunião.

Qual foi a pauta da reunião?

- Vocês foram alocados para outro projeto, que está crítico e precisamos finalizá-lo.

Foi aquele "hã??" geral na equipe. Mas a reunião seguiu com a explicação do tal projeto. 60% de software e uns 40% de hardware. O engraçado é que a minha equipe atual é composta de estudantes de ENGENHARIA da computação, ou seja, software não é a praia deles. Mas durante a reunião o nosso chefe teimava em abordar mais os aspectos de software e também lembrava que "eles já haviam mexido com GPS e então teriam um aprendizado rapidíssimo, de 15 minutos, no projeto".

Um parênteses: eu acho sensacional esse conceito que meus chefes tem, e que é muito comum por aí. Se nós trabalhamos com uma tecnologia em algum projeto, isso nos torna especialistas em qualquer projeto que envolva a mesma tecnologia. Ou seja, a equipe trabalhou com GPS para auxilio de guia de um trator... e agora vai aprender rapidíssimo tudo o que envolve o projeto de GPS para rastreamento de veículos (inclusive com banco de dados e interface gráfica). É aquela mesma história que a gente que cursou informática sofre quando alguém vem e pergunta algo como "tu sabes fazer um índice no Word? Não??? Pô, mas o que vocês fazem nessa faculdade??!".

Ao final da reunião, como de praxe, este nosso chefe definiu que espera resultados já para a próxima sexta-feira. Resultados e decisões "triviais", que envolvem variáveis complexas. Afora o exagero na exigência, toda equipe admitiu que é melhor trabalhar com este chefe, pois ao menos ele é bem objetivo :)

Enfim, até as 15h eu estava planejando um projeto com a equipe. Às 15h05 já estávamos alocado, sem mais nem menos, em outro projeto. E a importância dos testes no trator, que teríamos que fazer? Bem... inexplicavelmente virou secundário.

Uma pequena empresa normalmente possui um ambiente propício para a comunicação, pois é relativamente simples (pouca gente, processos informais, etc). Mas é impressionante a tendência que as pessoas tem de complicar. A previsibilidade é ZERO no meu trabalho. As decisões são tomadas e apenas nos informadas quando a batata já assou. Daí eles jogam no nosso colo e falam "é para ontem!". Mas falar de comunicação lá no meu trabalho é bater na mesma tecla, sempre... infelizmente.

Abraços

Comunicação x Percepção

Este blog não é mais atualizado. Veja o novo blog em: www.agileway.com.br

Existem diversas formas de passar uma mensagem. Podemos ser tendenciosos ou não. Um bom líder precisa garantir que a mensagem esteja sendo passada da forma correta, sem que haja má interpretação. Já pensou se você quisesse fazer um elogio e o seu subordinado entendesse como uma crítica?

Eu vinha há algum tempo pensando em criar uma forma de mostrar a questão da percepção de uma forma prática. Tive uma idéia de modificar o trailer de um filme mudando totalmente o contexto (uma comédia para um filme de terror, por exemplo). Mas eu as vezes esqueço que, na era da internet e da informação, quando nós pensamos em uma coisa, outros 100.000 já estão colocando em prática.

Vejam os dois exemplos abaixo. Uma versão do trailer original e uma versão "modificada" por... gente com muito tempo livre :)

E se vocês procuravam uma forma de mostrar a importância entre a mensagem e a percepção que ela gera, vocês tem abaixo.

Peguei dois filmes, os excelentes "Rain Man" (um drama) e "O iluminado" (um terror sensacional).

RAIN MAN ORIGINAL


RAIN MAN TERROR


O ILUMINADO ORIGINAL (trailer meia-boca já que é quase impossível achar o original!)


O ILUMINADO COMEDIA ROMANTICA