Muitos projetos

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

Hoje na hora do almoço encontrei um colega do meu MBA na rua. Ele me perguntou sobre o meu trabalho e eu falei que estava bem puxado, pois estava com oito projetos. Disse que era difícil se aprofundar em alguns, o que eu considero ruim.

Ele então me disse que na empresa dele, ele está com apenas... quarenta. QUARENTA. Como uma pessoa pode gerenciar QUARENTA projetos?

Eu me pergunto as vezes o que essas empresas esperam de um gerente de projetos. Normalmente somos responsáveis por grande parte do projeto, tendo que conhecer cronograma, escopo, garantir qualidade, etc. Fazer isso em um ou dois projetos já é complexo. Imaginem QUARENTA?

O que esperar de situações assim? O gerente de projetos será apenas um "administrador", delegando praticamente tudo para suas equipes. Não vai se aprofundar em praticamente nenhum projeto, manter uma relação mais próxima ao cliente, entender as suas necessidades e garantir que o projeto satisfaça o máximo possível.

Qual seria a capacidade ideal de projetos para um gerente? E qual seria a sua?

Pensar nisso nunca é demais :)

Abraços

Agilistas-san

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

Cena 1:

Daniel Larusso, cansado de ser um cara que apanha de todos, procura Sr. Kesuke Miyagi. Quer aprender Karatê para se defender. O Sr. Miyagi reluta mas aceita.

Cena 2:

Daniel-san chega no primeiro dia achando que vai dar voadoras e chutes mortais. Sr. Kesuke Miyagi o manda polir os carros. Em movimentos circulares. O dia todo.

Cena 3:

Daniel-san chega no segundo dia achando que vai dar voadoras e chutes mortais. Sr. Kesuke Miyagi o manda pintar a cerca. De cima para baixo, com calma. O dia todo.

Cena 4:

Daniel-san chega no terceiro dia achando que vai dar voadoras e chutes mortais. Sr. Kesuke Miyagi o manda varrer o deque de madeira. De um lado para o outro. O dia todo.

Cena 5:

Daniel-san chega no quarto dia puto da cara. Quer aprender Karatê, e não ficar pintando, polindo ou varrendo. Xinga o Sr. Miyagi e diz que é tudo uma bobagem.

Cena 6:

Sr. Miyagi o manda repetir cada um dos movimentos dos três dias. E aplica golpes de Karatê em Daniel-san. Os movimentos de polimento, pintura e varredura, são os mesmos usados na defesa dos golpes. O que parecia inútil, foi o início e a pedra fundamental para Daniel-san aprender, sem saber, Karatê.

Sim, se você percebeu esse é o filme "Karatê Kid".

A famosa cena 6, em vídeo:



Qual a analogia que podemos fazer com agile? Simples.

Quantos "agilistas-san" você conhece? Aqueles que conhecem SCRUM / XP / TDD / LEAN ou qualquer outro processo ou corrente ágil, e resolve implantá-la achando que terá resultados da noite pro dia?

Quantas vezes você já ouviu donos de empresa falarem "Agora faremos SCRUM!" e obrigarem as equipes a praticarem processos ágeis, sem que eles entendam o por quê?

Para ter sucesso com qualquer processo ágil, é preciso trabalhar com calma, ponto a ponto. "Wax on, Wax off", como o Miyagi diz no filme. Entender o processo... diagnosticar problemas... melhorar a comunicação... valorizar as pessoas... fazer sua equipe entender que mudanças vão acontecer... fazê-los perceber porque reuniões diárias, taskboards, etc são benéficas... tentar criar um projeto piloto... enfim.

Se você achar que pode simplesmente implantar agile (ou aprender Karatê) apenas lendo um livro e atropelando tudo, ou você sofrerá uma grande decepção com os processos ágeis (ou levará uma grande surra!).

Agora, toda vez que algum conhecido seu se afobar com processos ágeis, peça para ele assistir ao filme Karatê Kid. Afinal de contas, é um bom divertimento também.

Um grande abraço

A geração que veio para ficar

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

Existem dezenas e dezenas de revistas que abordam o tema da geração Y, a geração de pessoas que está entrando no mercado, desde o início dos anos 2000.

São jovens inquietos, ansiosos, tidos como incapazes de se aprofundarem em assuntos, mas que desenvolveram uma forma totalmente diferente de lidar com problemas e com o dia-a-dia no trabalho.

Nas minhas duas empresas, a antiga e atual, eu tive a oportunidade de trabalhar com essas pessoas e pude notar algumas coisas que gostaria de citar aqui. Só esclarecendo que eu me considero da geração X/Y, ou seja, posso me considerar parte Y e parte X, pois nasci em 1980 a época em que dizem que a geração Y iniciou.

1) A geração Y é ansiosa, sim! É impressionante que, seja num ambiente competitivo (atual) ou num ambiente de menos competitivo (universidade) as pessoas dessa geração são muito ansiosas. Ansiosas por resultados imediatos, ansiosas para pensar, ansiosas para planejar... isso normalmente tende a problemas comuns, como a famosa programação de sistemas via "tentativa e erro" ao invés de parar por alguns minutos e esboçar uma estrutura do que será desenvolvido. Pensar faz bem. Aliás, essa ansiedade a flor da pele me faz pensar que a geração Y tenderá a sofrer de problemas como crise do pânico e ansiedade com uma frequência muito maior. Observem.

2) A geração Y funciona de forma multi-tarefa, e funciona bem! Não adianta, meus amigos. Insistir para uma pessoa dessa geração fazer uma coisa de cada vez é pedir para ter uma pessoa infeliz e improdutiva. Eu me considero até certo ponto um tanto multi-tarefas, mas ainda prefiro tentar me focar em algo. A geração Y consegue falar por mensagem instantânea, ler um texto na internet, ver um vídeo no Youtube e desenvolver um programa AO MESMO TEMPO. E, pasmem: o fazem geralmente com grande qualidade. Já me deparei com desenvolvedores, no meu antigo trabalho, que eu achava que haviam passado o dia inteiro na internet fazendo bobagens, para no final do dia eles me apresentarem o resultado das suas tarefas prontas... e excelentes!

3) A geração Y se motiva e desmotiva com uma velocidade muito maior do que a normal. E é por isso que a grande maioria das empresas está repensando seu planejamento de RH, de forma a garantir que chefes passem a valorizar os bons trabalhos e a corrigir rumos, sem ser rudes demais. Por incrível que pareça, já percebi que a grande maioria das pessoas da geração Y preferem receber um feedback (mesmo que negativo) do que não receber nenhum estímulo.

4) Dinheiro não é tudo para a geração Y. Esse é um dos grandes paradigmas que estão sendo quebrados com essa geração: a visualização de que esses jovens preferem trabalhar em locais onde se sintam valorizados e motivados, do que em locais onde apenas ganhem mais... mas não tenham a valorização que acham que merecem. E aí vem a grande questão: muitos ACHAM que merecem. Neste caso, leia o item 3!

5) A geração Y entra de sola para mudar. Muito devido à ansiedade, os jovens costumam ser bastante inquietos quando a mudanças. Este é um dos principais pontos de conflitos com as demais gerações e é aqui que nós, gerentes e gestores, temos que trabalhar muito bem: ambas as gerações se contrabalançam assim. De um lado, aqueles que normalmente acham que o continuísmo é a melhor solução, e do outro lado, aqueles que acham que a mudança é a solução. Os conflitos e discussões, se bem tratados, levarão a avaliação de diversas situações por ângulos não pensados antes.

Por fim, como tudo na vida, lembre-se: existem os bons e os maus exemplos. A geração Y, com pessoas incapazes, tende a produzir resultados muito ruins... talvez até mais do que com outras gerações. Por outro lado, pessoas responsáveis e tecnicamente capazes serão excelentes exemplares para sua empresa.

Cabe a você conseguir escolher as pessoas certas. Mas tenha a certeza: a geração Y veio para ficar. Jogue conforme as regras do jogo e não contra elas.

Um forte abraço!

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.

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!

Retrospectiva do projeto (lições e prática)

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

Conforme dito, vou passar aqui alguns itens citados na retrospectiva do meu projeto.

A retrospectiva abrangiu o projeto como um todo (2 anos) e infelizmente não pôde contar com todos os envolvidos (faltou o chefe/cliente e um membro da equipe).


Apresentação


O processo da retrospectiva foi realizado em dois momentos. No primeiro momento, uma linha do tempo que abrangia todo o projeto foi desenhada. A partir disso, foram sendo citados os eventos que ocorreram durante o projeto, numa espécie de brainstorming. Estes eventos eram colocados em ordem da data em que aproximadamente ocorreram.

Após este levantamento, alguns eventos foram excluídos por serem “duplicatas” ou então por serem conseqüências de alguns itens citados.

O segundo momento foi a divisão entre o que foi bom e o que não foi legal no projeto, e a classificação de cada um dos eventos nesse quadro comparativo. Para cada evento também eram analisados alguns fatos, como comentários sobre o evento, causas e conseqüências. Alguns eventos também foram discutidos pela equipe, apenas como relembrança.

Ambos os processos foram fotografados para posterior documentação. Este documento apresenta estes eventos classificados em “o que poderia ter sido melhor” e “o que foi bom”, com comentários do autor do documento (Flávio, gerente do projeto). Alguns outros itens foram incluídos pelo gerente posteriormente.

A figura abaixo demonstra a organização da retrospectiva.

Este post pode (e deve) ser usado como referência para futuras tomadas de decisão, sendo um excelente repositório de lições aprendidas na prática. Use-o para refletir se suas decisões e atitudes podem ou não causar os mesmos estragos ou oportunidades aqui descritos.

--------------------------

O que poderia ter sido melhor

• Utilização do conceito Waterfall, como engenharia. A utilização do waterfall (concepção, análise, desenvolvimento e finalização) se mostrou bastante inútil para nosso projeto. Houve uma perda de tempo enorme uma vez que o desenvolvimento já poderia ter sido iniciado muito anteriormente.
• A não utilização do Wiki como ferramenta. A idéia do Wiki como repositório de conhecimento foi muito boa. A ferramenta é fácil de usar e bastante simples. Infelizmente não houve uma cultura (e cobrança) para que o uso fosse disseminado.
• Muito tempo na fase de concepção. Seguindo o modelo Waterfall, a equipe acabou levando muito tempo na fase de concepção. Houve muita desorganização, apesar do documento de concepção ser bem completo (e boa parte estar defasada já).
• Equipe muito grande. Houve muita desorganização no começo. O projeto começou inicialmente com 8 desenvolvedores, um gerente e um coordenador. Ficou evidente que o ideal seria uma equipe com 4 desenvolvedores no máximo (finalizamos com 3).
• Software poderia ter iniciado logo depois da concepção. Perdeu-se muito tempo para modularizar e definir de fato o software embarcado, uma vez que tivemos muito foco no hardware. Posteriormente ficou evidente que pelo menos dois ou três módulos poderiam ter sido iniciados logo após a concepção.
• Utilização do Status Report semanal. O documento, apesar de boa intenção para identificar as tarefas realizadas pela equipe, se mostrou bastante burocrático e ineficaz. Boa parte do resultado que desejava se atingir com ele, poderia ter sido feito com mais reuniões e com a cobrança da gerência.
• Escopo muito solto. Por muito tempo o projeto teve um escopo muito “solto”, ou seja, não se sabia ao certo o que iríamos produzir. Isso custou tempo, foco e afetou a produtividade. Deveria ter havido mais cobrança junto ao cliente para formalizar o escopo.
• Tentativa de utilização de um TCC como hardware do projeto. Perdeu-se algum tempo com a idéia de usar como placa-mãe um trabalho de TCC de alunos. A idéia era muito boa, mas mostrou-se ineficiente (já que os alunos pediram um valor altíssimo pelo projeto).
• Falta de datas (deadlines). Por diversas vezes a equipe sentiu a necessidade de vislumbrar uma data final para a realização de alguma atividade. Faltou cobrança e planejamento, muito devido ao escopo “solto”. Isso acabou levando a equipe a também se comportar de forma mais “solta”.
• Curso extraprojeto com membros da equipe. O curso, além de ser muito ruim – na opinião dos dois – ainda demandou que dois membros da equipe saíssem por alguns dias do projeto para aprenderem sobre uma tecnologia que nada agregaria ao projeto. Além disso, o projeto em que seria usado o que foi aprendido no curso, acabou sendo abandonado.
• Documentação do projeto. Por diversas vezes a equipe foi cobrada para realizar a documentação do projeto. O documento foi desenvolvido, mas sempre foi desaprovado pelo cliente. Infelizmente faltou, por muitas vezes, um norte para que a equipe desenvolvesse o que o cliente queria (lhes foi dito que a documentação deveria permitir que até mesmo uma empregada pudesse montar o sistema). A falta de norte também levou a produção de uma documentação acadêmica e desnecessária, que não agregariam nada ao projeto em si. Perderam-se meses nesta documentação, levando a desmotivação de todos (equipe e cliente). Por diversas vezes a aprovação da documentação ficou pendente por muito tempo, levando todos a questionar se essa documentação era realmente importante.
• Falta de definição de papéis. O coordenador do projeto trabalhou no projeto como coordenador, especialista e cliente. Isso confundiu bastante a equipe e o próprio coordenador, por diversas vezes.
• Coordenador segurou as compras durante o desenvolvimento. Apesar de ter sido uma ótima decisão no início do projeto, a insistência na decisão de só comprar os componentes após a documentação ter sido finalizada acabou atrasando bastante o projeto, uma vez que a documentação foi problemática (conforme citado anteriormente). Alguns módulos e ferramentas poderiam ter sido adquiridos para o início da produção. Essa falta de materiais “tangíveis” do projeto, gerou um pouco de desmotivação no projeto.
• Falta de aproximação do coordenador com a equipe. Por ser o especialista do projeto, poderia ter tido uma participação mais efetiva no projeto, onde algumas coisas poderiam ter sido agilizadas.
• Reuniões sem agenda. Diversas reuniões foram realizadas sem uma agenda para ser seguida, o que levou a falta de foco e decisões.
• Reuniões de acompanhamento e de escopo. Por diversas vezes as reuniões de acompanhamento (onde também eram discutidas algumas idéias de escopo) foram muito problemáticas. Por um período grande, o cliente decidia por uma funcionalidade ou componente, para na outra semana desistir. Ou então sugeria algumas funcionalidades interessantes, mas que fugiriam do real objetivo do projeto (ex: capacete 3D!). A desmotivação de ambas as partes, ao final das reuniões, era visível.
• Mudança da empresa para o laboratório. Essa decisão foi bastante criticada por todos os integrantes da equipe. Na empresa, a equipe mantinha-se mais focada e produtiva. No período ainda estava sendo implantado o SCRUM, o que causou uma grande mudança no projeto. A mudança para o laboratório reduziu muito a concentração, foco, comprometimento e a produtividade da equipe. Isso foi dito pelos próprios.
• Comunicação ineficaz. A comunicação foi sempre um problema no projeto. Diversas decisões eram tomadas sem que os envolvidos tivessem conhecimento. Recursos específicos do projeto eram solicitados para outros projetos, decisões de escopo eram tomadas sem consulta a equipe e gerência, poucos sabiam ao certo o que o outro deveria fazer, papéis e responsabilidades eram incertos. A comunicação foi bastante maximizada com a utilização do SCRUM, isto sendo bastante evidenciado pela equipe.
• Mau uso de alguns recursos. Por diversas vezes ocorreu um mau uso dos recursos do projeto. Financeiramente falando, o projeto poderia ter sido mais bem planejado e executado (algumas compras foram feitas na correria, devido aos prazos). Também ocorreram situações onde recursos do projeto (materiais e humanos) foram usados em outros projetos, com perda de foco e tempo. Além disso, a equipe poderia ter utilizado com mais responsabilidade alguns recursos do projeto, como ocorreu no caso onde o Valter, por acidente, formatou o seu “home” do computador. Não ocorreu uma perda crítica de conhecimento, porém o tempo para restaurar isso foi bastante grande para a situação em que o projeto se encontrava.
• Aumento dos salários como motivação. Isso foi uma lição aprendida na prática, embora pudesse ter sido evitada. O aumento dos salários, que foi usado como questão motivacional, não surtiu o efeito desejado. Em um projeto como o Agritec, o impacto só foi sentido devido ao atraso no cronograma. Porém, deve-se evitar isso. A motivação se dará por diversos outros fatores como técnicas de empowerment, feedback, etc.
• O projeto em segundo plano, em algumas vezes. Por diversas vezes, mesmo com alguns prazos apertados, a equipe decidiu por dar prioridade aos estudos e a questões pessoais em detrimento ao projeto. Isso gerou por um período, um certo mal estar, mas por pelo menos uma vez, um feedback da gerência foi suficiente para a retomada. Porém, o sentimento de que “poderia ter havido maior comprometimento” ficou evidente.

O que foi bom

• O coordenador segurou as compras no início. A decisão de segurar as compras no início do projeto, indo contra a ansiedade da equipe, foi excelente. Diversos componentes solicitados, na época, se mostraram inúteis no projeto, o que seria um gasto desnecessário.
• Saída de alguns membros da equipe. Alguns membros da equipe (não terão os nomes citados) reduziram os conflitos dentro do projeto, o que melhorou o foco e a cumplicidade.
• Mudança do laboratório (antigo) para a empresa. A mudança para a empresa possibilitou a equipe sentar junto. A comunicação melhorou e o comprometimento também, apesar de algumas ressalvas no período “pré-SCRUM”. O ambiente de trabalho melhorou consideravelmente.
• Reunião semanal de pesquisa. Uma reunião semanal, no início do projeto, foi uma idéia válida para alinhar a pesquisa de todos. Infelizmente algumas pessoas não levavam a sério, o que tornava esta reunião apenas uma burocracia. A idéia foi melhorada posteriormente.
• Mudança do foco (não produzir o GPS). A idéia inicial de produzir um GPS felizmente foi abortada. Dificilmente teríamos uma precisão decente para o projeto. A idéia foi abortada logo, o que evitou a perda desnecessária de tempo.
• Produção do documento de concepção. Embora tenha sido detalhado demais, o documento possibilitou naquele momento a consolidação da pesquisa inicial realizada. Além disso, serviu como nivelamento para possíveis novos integrantes. De ruim, apenas o tempo que se levou produzindo o mesmo e também o caráter “completo” que ele possuía, com muitas informações que não seriam aplicáveis com o tempo.
• Feedback aplicado na parte inicial do projeto. Infelizmente por apenas uma vez, o Flávio e o coordenador realizaram um feedback com a equipe. A idéia foi de entrevistar cada membro da equipe para identificar problemas e necessidades que a equipe enfrentava. Foi interessante e útil para identificar conflitos, até então não conhecidos. A idéia de usar o feedback foi elogiada pela equipe.
• Primeira versão do SCRUM. A implantação do SCRUM pelo Flávio teve um impacto extremamente positivo. Ficou muito mais claro para todos quais eram suas responsabilidades, quem estava sub ou super alocado, a comunicação melhorou muito e a freqüência também. A primeira versão do SCRUM foi uma versão adaptada (que não é exatamente como deveria ser o SCRUM) com uma taskboard onde havia nomes (linhas) e situação da tarefa (colunas). Reuniões diárias e retrospectivas foram utilizadas com sucesso (veja abaixo).
• Reuniões diárias. As reuniões diárias foram uma das grandes mudanças que ocorreram para maximizar a comunicação do projeto. Através das três perguntas que cada pessoa da empresa respondia (na 1ª versão, inclusive os não integrantes do projeto) que eram “O que você fez ontem? O que pretende fazer para hoje? Quais seus impedimentos?” possibilitou criar cumplicidade na equipe e também a realidade de todos saberem o que o colega ao lado estaria fazendo. A implantação de um horário fixo para a reunião, no início dos trabalhos, fez com que a freqüência passasse a ser muito maior, evitando o “trabalho em casa”. Foi possível identificar alguns focos de problemas também, que foram resolvidos com o tempo. Além disso, segundo a própria equipe, as reuniões melhoraram a cobrança interna entre eles.
• Descontração no ambiente de trabalho. O “carro-chefe” desse item é o cofrinho em forma de porco, que foi comprado com a idéia de que quem chegasse atrasado nas reuniões pagaria 50 centavos ao porco. O dinheiro, no final do mês, era revertido na compra de comes e bebes para uma confraternização e retrospectiva do projeto (que ocorreu muito pouco, apenas duas vezes). O porco serviu para deixar o ambiente mais leve e divertido, e contribuiu muito para manter a moral da equipe elevada. Deve-se estudar para buscar alternativas!
• Retrospectivas. As primeiras retrospectivas foram importantíssimas para avaliar a situação do projeto, seja em relação ao escopo, cronograma e processos, seja em relação a equipe, comunicação e infra-estrutura. Logo na primeira retrospectiva foi evidenciado que a infra-estrutura da empresa, para a produção do projeto, era quase nula. Faltavam ferramentas e materiais simples (como canetas para o quadro branco). Também foi possível identificar as necessidades das equipes (descontentamentos, por exemplo) às necessidades do projeto, sempre que possível. As retrospectivas, posteriormente, acabaram ERRÔNEAMENTE ficando em segundo plano. Mas a última, que avaliou o projeto e gerou este documento, foi muito bem sucedida.
• Melhora na infra-estrutura. Este era um dos maiores problemas do projeto: a falta de material e ferramentas para a realização de diversas tarefas. Por muito tempo, por exemplo, ocorreu uma improvisação absurda com a utilização de canivete suíço e até moedas, como chave de fenda. A partir da primeira reunião de retrospectiva onde isso ficou evidente, o Flávio solicitou a equipe que levantassem tudo o que precisaria para o projeto. Após a listagem completa, deliberadamente foi com um membro da equipe até uma loja especializada onde comprou todos os itens da lista. De um dia para o outro a empresa possuía ferramentas para o projeto (e outros também). Isso ocorreu por diversas outras vezes. Talvez não tenha sido a forma ideal (pode-se ter gasto a mais em alguns itens – o ideal seria pesquisar preços), mas naquela situação específica a mudança precisava ser rápida. E o resultado foi excelente.
• Visita do pessoal da agricultura (clientes finais). A possibilidade de conversar diretamente com os usuários finais do projeto fez com que fosse possível ter uma visão bem mais próxima da real necessidade do projeto. O escopo foi priorizado e modificado para atender ao máximo as necessidades dos agricultores. Ter uma aproximação junto aos usuários finais é sempre uma excelente idéia para agregar aos projetos. Graças à visita foi possível identificar que as trajetórias retilíneas não poderiam atender as necessidades deles. Essa informação possibilitou a abertura do escopo para trajetórias curvilíneas.
• Visita à Empresa Especializada no assunto. Assim como no caso do pessoal da agricultura, a empresa especializada foi uma grande parceira no projeto, trazendo idéias inovadoras que o produto poderia possuir. A maioria acabou não podendo ser implantada, mas possibilitaram a citação como funcionalidades futuras, dando um caráter inovador ao produto.
• 2ª versão do SCRUM. A implantação da segunda versão do SCRUM, agora mais aderente a prática real, tornou o processo mais auto-suficiente e seguro. Algumas técnicas novas foram aplicadas e garantiram excelentes resultados.
• Planning Poker. Essa foi uma das técnicas que foram utilizadas na 2ª versão do SCRUM. Foi usada apenas uma vez, mas possibilitou a visualização por parte da equipe e do cliente de como os dois pensamentos da complexidade do projeto estavam distantes. A maioria das funcionalidades era tida como “simples” pelo cliente e como “difíceis” pela equipe. Essa técnica auxiliou o cliente a desistir de algumas idéias e funcionalidades para a versão inicial do projeto.
• Finalização do 1º protótipo do painel. A realização deste primeiro protótipo começou a ser definida com a melhora na infra-estrutura do projeto. Foi um grande marco no projeto ter esse protótipo funcionando, pois evidenciou que estávamos no caminho certo e que toda pesquisa não havia sido em vão. A necessidade de ter algo tangível em um projeto ficou claramente exposta aqui. Além disso, possibilitou a realização dos primeiros testes reais.
• Contato com empresas para solução Kalman. O contato com empresas especializadas, em forma de parceria, possibilitou o abandono da idéia de usar a tecnologia de Kalman no projeto o que, segundo os próprios donos da empresa, era inviável devido ao alto custo e complexidade.
• Uso do Doxygen como documentação de software. A utilização do sistema “Doxygen” para documentar o software do projeto foi muito boa. O sistema gera uma documentação com base nas funções e comentários direto no código, o que facilitou muito a manutenção do projeto. Ele também acabou forçando a equipe a comentar muito o código, o que tornou um código que seria bastante complexo em algo um pouco mais “tragável”.
• Mudanças internas no laboratórioA mudança de alguns mestrandos de dentro do laboratório para fora tornou o ambiente um pouco mais favorável à concentração. Infelizmente, segundo a equipe, ainda não está o ideal.
• O sucesso da feira que apresentou o produto. A realização de um evento como marco no projeto, como foi a feira realizada no início de Julho/08 se mostrou como uma excelente forma de motivar o time a atingir o resultado. O bom planejamento que foi realizado para o dia, com a finalização do protótipo físico (para demonstração), a criação de um programa que simulava o projeto, textos e banners informativos e um vídeo demonstrando todo o processo de criação tornou o projeto um dos mais bem planejados e representados na feira, sendo bastante elogiado pelos avaliadores.
• O comprometimento com a deadline, pela equipe. Nos dias finais que antecederam a feira citada acima, a equipe não se preocupou em trabalhar inclusive à noite e sábados e domingos para entregar o projeto funcional. Isso demonstrou uma capacidade de comprometimento da equipe, com o projeto, que deveria ser um exemplo. A decisão de fazer isso partiu da própria equipe. Muito embora por diversas vezes o projeto tenha ficado em segundo plano (devido a situações pessoais e de estudos), essa demonstração de comprometimento demonstrou como um projeto pode deixar de ser apenas trabalho para se tornar parte da realização pessoal de uma equipe.

Conclusão

Apesar de esta retrospectiva ter sido realizada pelo gerente do projeto e por dois membros da equipe, com a ausência do coordenador e de outro membro, ficou demonstrada a importância da realização de uma retrospectiva para analisar o projeto durante um período. Diversas questões problemáticas poderiam ter sido solucionadas se fossem identificadas mais rapidamente. E diversas questões benéficas poderiam ter sido potencializadas se tivessem sido percebidas com mais antecedência.

Para os próximos projetos as retrospectivas devem ser feitas mais frequentemente e, além disso, as lições relevantes devem ser documentadas e divulgadas para as demais equipes. Algumas lições poderão auxiliar a todos a atingirem um padrão de processo, além de evitar erros comuns que já possam ter sido cometidos por outras equipes.

Neste processo de retrospectiva do projeto poderia ter identificado planos de ação para os problemas levantados, mas nessa retrospectiva específica isso não foi utilizado. Porém é importante pensar em planos de ação para evitar que problemas ocorram ou voltem a ocorrer, funcionando como uma espécie de gestão de riscos do projeto.

No final, a equipe que participou da retrospectiva levantou 24 problemas e 27 coisas boas que ocorrem no projeto (algumas não citadas aqui no post do blog).

Brasil x resto do mundo

Um assunto que costuma gerar situações inusitadas (que vão desde engraçadas até trágicas) geralmente está relacionado à diferença cultural entre dois povos. Hoje durante a aula conversei com alguns colegas a respeito e queria citar alguns aqui. Só por curiosidade e para pensarmos como é cada vez mais importante para nós que vivemos em um mundo globalizado e amanhã poderemos estar negociando com outras culturas.

+ Recentemente, troquei alguns emails com uma empresa indiana para tentar fazer uma parceria de outsourcing com eles. Lá pelas tantas, o CEO da empresa me falou: "Flavio, I will send you my picture with my son. Can you send yours?". Aquilo me soou TÃO estranho, que eu confesso que até hoje o indiano deve estar esperando a foto. Não sei ao certo o que isso tem a ver, mas ele mandou a foto dele com o filho... talvez seja um sinal de confiança. Não sei. Mas nós, brasileiros, dificilmente trocamos fotos entre homens!

+ Ainda sobre indianos, soube que certa vez uma executiva indiana esteve no Brasil. Ela gostava muito de fotografar. Lá pelas tantas, ela viu um prédio muito bonito em São Paulo e decidiu fotografar. Sua câmera não pegava todo o prédio, então ela decidiu ir andando pra trás... até chegar no meio da rua e morrer atropelada. Detalhe: na Índia, parar no meio da rua é algo que não costuma ser fatal.

+ Em uma convenção de executivos, um brasileiro e um português conversavam para trocar contatos. O brasileiro então falou: "Qual é o teu telefone?". E o português respondeu animado: "Nokia! E o seu?". O brasileiro então pensou... e deu uma gargalhada. O português fez cara de poucos amigos. Depois de algumas explicações, tudo ficou melhor. Mas o fato é que nós brasileiros temos a mania de querer que os nossos interlocutores ADIVINHEM o que queremos. "Qual é o teu telefone" é um diminuitivo para "Qual é o número do teu telefone". Os portugueses pensam de forma bem objetiva (e óbvia). Todo cuidado é pouco!

+ Certa vez li que um executivo estava em um hotel, em Portugal, e decidiu pedir uma pizza. Ele então pediu uma grande meia calabreza e meia muzzarela. O atendente falou que não havia pizza de muzzarela. "Como não?!?" gritou o brasileiro. Depois de muita briga, o brasileiro decidiu facilitar a vida do português: "Bem, amigo. Me dá então uma pizza inteira de calabreza, só que metade dela SEM calabreza". E o português respondeu: "Ok! Obrigado pela compreensão".

+ Quando você for para o Japão negociar com executivos japoneses, muito cuidado! Um executivo havia ido até lá para negociar com uma grande montadora, em uma viagem de cinco dias. Chegando lá, pretendia iniciar logo a reunião. Os japoneses quiseram fazer um tour pela cidade no primeiro dia. No segundo e terceiro dia, os japoneses mostraram todas as fábricas, passaram por todos setores de produção, mostraram os detalhes das suas empresas. No quarto dia, ofereceram um espetáculo cultural a ele. No quinto e último dia, no retorno para o aeroporto, o executivo japonês indagou o brasileiro: "Então, qual a sua proposta?". Resultado: o brasileiro, cansado e tonto com tanta coisa, acabou fazendo todas as vontades do japonês.

+ O povo alemão costuma ter origens fortes e são normalmente bastante resistente à mudanças. Em uma fábrica alimentícia no RS, um dos supervisores era alemão genuíno. Fazia todo o processo no olho, sabia exatamente a quantidade exata de cada porção. Ainda assim, de vez em quando falhava. A fábrica decidiu instalar uma máquina mais moderna, onde ele simplesmente entraria com o valor da quantidade e só precisava monitorar de tempos em tempos, se tudo estava ok. Para a surpresa da diretoria, descobriram que o alemão continuou fazendo tudo no olhômetro, dizendo que a máquina não era precisa e fazia tudo errado. A fábrica decidiu ouvir o alemão.

+ Um dos cases mais estudados no mundo é a volta por cima da Nissan, empresa japonesa comprada pela Renault, que estava indo para o buraco. Mas graças a um brasileiro, a empresa em 3 anos voltou a ser referência mundial. Uma das primeiras grandes medidas desse brasileiro foi acabar com um dos maiores paradigmas culturais do Japão: o conceito de que todos trabalham na mesma empresa por toda a vida. Para reduzir custos, foi preciso demitir milhares de japoneses e implantar uma mudança de conceito, onde a promoção não ocorreria mais por tempo de cargo, mas sim por resultados. O brasileiro (chamado Carlos Ghosn) enfrentou uma cultura milenar e, após ser visto com desconfiança (e até ódio) por parte dos japoneses, virou uma celebridade na terra do sol nascente.

+ Por fim, uma que não é sobre o mundo coorporativo, mas fala muito sobre a essência e sobre a cultura japonesa. O jogador e atual técnico da seleção Dunga, um dos primeiros brasileiros a ir jogar no incipiente futebol japonês, contou que certa vez o seu time se preparava para fazer a barreira em uma cobrança de falta do time adversário. O juiz marcou a posição da barreira e apitou a cobrança. O Dunga então começou a mandar todos da barreira avançarem, para dificultar a cobrança. E ouviu dos japoneses do próprio time: "Não! Não pode! Não pode!".

Causos de diferenças culturais existem aos montes. E isso mostra como é importante saber pelo menos um pouco em que território estamos pisando.

E você, caro leitor, conhece uma história divertida que envolve diferenças culturais? Conte para nós!

Um abraço

Aprendiz 5 ou Apprentice 6?

Semana passada encerrou no canal People'n'Arts o programa The Apprentice LA, a sexta versão do "Aprendiz" com o Donald Trump. O programa que foi idealizado para o próprio, trouxe candidatos com vasta experiência (inclusive uma bi campeã Olímpica a qual o Trump se derretia sempre que podia) e algumas modificações: na sexta edição, a equipe que perdia uma prova dormia em barracas no pátio de uma mansão. E a equipe vencedora, ficava dentro da mansão. Também, o líder vencedor ficava como líder na próxima tarefa. Foi uma edição inferior em alguns conceitos, em relação à temporada 5, mas que trouxe muitas coisas legais.

Já o Aprendiz 5 - O sócio, traz novamente o Roberto Justus buscando por um sócio. Uma das modificações interessantes aplicadas nessa edição foi a possibilidade da equipe vencedora acompanhar a sala de reuniões. Dessa forma, o Justus garantia que TODOS saberiam o que era esperado por ele.

Criei este post para comparar essas duas edições. Apenas por diversão, mas também para discutir alguns assuntos interessantes sobre gerenciamento e negócios em culturas diferentes (EUA e Brasil).

O PROGRAMA
Falando especificamente do programa, posso dizer sem medo que a edição americana é muito melhor. Seja na edição, seja na proposta. A idéia de ter um "sócio" já é um tanto forçada. É difícil para mim, pelo menos, aceitar que realmente o vencedor do programa será um sócio do Justus... você, caro leitor, escolheria um sócio baseado em um programa de televisão onde se sabe que um tenta passar a perna no outro?! Seria o mesmo que propôr sociedade ao Rafinha, do BBB. O Donald Trump SEMPRE buscou um aprendiz, alguem que iria conduzir uma grande obra dele (geralmente uma construção).

Ainda sobre o programa, em geral, ambas as edições forçam demais em mostrar os prêmios das equipes vencedoras. Ora, quem assiste o programa quer tirar lições sobre os acontecidos, quer se colocar no lugar daquelas pessoas e se imaginar: "o que eu faria?". Então pra mim é extremamente entediante assistir a equipe vencedora com seu prêmio (seja uma viagem para Las Vegas, seja um simples jantar em um restaurante rico). O foco, no meu ver, deveria ser tanto na prova (bastante) como na sala de reunião (onde as lições aprendidas são discutidas).

Por fim, algo que me incomoda MUITO é a chamada do programa. A chamada do programa do Aprendiz americano nós não sabemos ao certo dizer, pois ela é criada pela People'n'Arts (a edição seis, que passou recentemente, foi realizada no ano passado!). Mas quando eu ouvi o Roberto Justus anunciar com tom de suspense "Quem será que eu vou demitir hoje?", me soou novamente falso e até mesmo desrespeitoso. Como se o programa não fosse para ver quem será o sócio dele, mas sim quem será esculachado e demitido.

Ponto para o Trump.

MERCHANDISING
Esse é um dos maiores problemas da edição brasileira: o merchandising descarado. Ocorreram alguns episódios em que o Justus chegou a convidar os participantes para "pegar leve, pois pegar leve é com a Nova Schin". Isso é algo que soa tão falso, mas tão falso, que é impossível não ter uma das duas reações: ou rir ou torcer o nariz. A edição americana também faz algum merchandising, mas na edição 6 nada incomodou. São referências do tipo: "Hoje vocês trabalharão na empresa XYZ, uma das maiores e mais completas dos EUA com mais de 100 filiais e bla bla bla". Ora, é um programa de negócios, então aparecer alguma empresa dessa forma não soa falso. Agora eles pararem uma tarefa para "pegar leve"? Foi terrível!

Ponto para o Trump.

TAREFAS
Aqui há um equilíbrio. Ambas edições tiveram tarefas interessantes e tarefas chatas. Enquanto, porém, a edição americana trata as tarefas de forma BEM objetiva, ou seja, "vence quem vender mais ingressos para o evento", as brasileiras costumam trazer algumas coisas escondidas. Na tarefa do primeiro episódio, foi dito claramente que a equipe teria que vender patos. Mas o que as equipes não se deram conta foi de que além da venda em si, eles teriam que organizar um evento em uma cidade. O objetivo, então, não é tão claro. Acho que isso é interessante e ruim também: interessante pois força as equipes a pensar e serem criativos. Ruim, pois deixa margem para "mal-entendidos", como foi o que aconteceu até agora.

A edição brasileira seria a vencedora, MAS a tarefa em que o Justus colocou eles em um programa de perguntas e respostas, foi constrangedora. A "desculpa" de que o Justus queria alguém com bons conhecimentos gerais não justifica a prova (que novamente foi um merchandising descarado para a Sky). Um dos temas era ESPORTE. Outro era CINEMA. Ora, quem vai escolher um sócio só porque ele sabe quem é a atriz tal ou sabe quem venceu tal Olimpiada? Foi constrangedor também a sala de reuniões desse episódio. Serviu apenas para o Justus desmoralizar a maioria dos candidatos. Essa prova foi tão forçada, destoou tanto das demais, que eu vou ter que dar um empate.

Empate técnico.

EQUIPES/PARTICIPANTES
Nossa. Aqui a edição americana dá de relho. Eu diria que os aprendizes do Justus (os vencedores) iriam penar para irem para a final da edição americana, do Trump. É impressionante o despreparo dos candidatos brasileiros. Eles cometem erros tão básicos, que faz a gente duvidar realmente se eles estão lá por capacidade ou por indicação amiga. A coisa seria de relho mesmo, se fossem comparadas outras edições, pois na edição brasileira já apareceu candidato que "demitiu" o Justus (procurem no Youtube), já apareceu candidatos que na frente das cameras tentou subornar os fiscais! A edição americana não ficou atrás. O primeiro a ser eliminado, nessa temporada, foi eliminado por "ser arrogante". E era demais. Outro falou durante a reunião que era "escória... pau para toda obra", o que irritou o Trump e o demitiu na hora.

Porém, como a comparação é só entre a edição 5 BR e a 6 US, a diferença fica mínima para a edição americana. O candidato mais forte brasileiro, na minha opinião, é também o mais controverso (falo do Henrique). O cara se mostra muito entendido, mas sua personalidade é tão forte que a gente não consegue gostar dele. Já a edição americana teve um dos grupos mais fracos de candidatos. A vencedora (Stefani) era uma executiva que eu contrataria para ser minha chefe, tamanha a desenvoltura e capacidade.

Sendo assim, eu diria que o Trump novamente tem uma leve vantagem.

Ponto para o Trump.

CONSELHEIROS
Acho a coisa parelha aqui. O Justus costuma usar o seu velho amigo Walter Longo. É um conselheiro com posições fortes e corretas. As vezes costuma utilizar, durante as provas, donos das empresas que os participantes fazem a tarefa, ou algum consultor do Sebrae. Já o Trump, além dos donos das empresas, usa seus ex-aprendizes e também seus filhos, Trump Jr. e a ma-ra-vi-lho-sa Ivanka. Se eu fosse injusto, diria que o Trump vence por causa da Ivanka. Além de linda e estonteante, ela é inteligente e muito competente. Fala com a desenvoltura da sucessora do Trump. Mas...

Empate técnico.

OS CHEFÕES
Li o livro do Roberto Justus, "construindo uma vida". Achei muito bom e acho que realmente a vida dele foi sensacional. Não conheço a história do Trump, mas o império que ele construiu (pelo menos 5x maior que o do Justus) não deve ter sido por herança.

No programa, eu não tenho como mentir. O Donald Trump é 100000x melhor do que o Justus, como "chefe" do programa. Ele passa mais confiança, imponência. Ora, até hoje não vi ninguém "demitir" o Trump. O Trump também costuma pressionar, mas nunca vi ele faltar com o respeito com os candidatos. Houve uma tarefa em que ele demitiu a sua "favorita" (Heidi) em que ele achou terrível a tarefa dela. Mas foi enfático dizendo que não havia gostado do trabalho, sem porém esculachar o que ela fez (ela travou na apresentação de forma constrangedora).

O Justus, ao contrário, é muito apresentador. Toda edição ele tem que falar com o público em casa. "Quem eu vou demitir hoje? Quem será que vai me impressionar?". Isso cansa e soa falso. Ele também não transmite a imponência necessária. E, para mim, essa falta de imponência faz com que ele pressione os candidatos de forma desrespeitosa, na maioria das vezes. Já debochou das equipes, quando fizeram um mau trabalho, por exemplo. Enfim, aqui o resultado é óbvio.

Ponto para o Trump.

============================

CONCLUSÃO
A edição americana é muito melhor. Quando deixa a desejar, iguala na edição brasileira. Não que eu seja daqueles que acha que "tudo que vem de fora é melhor". É que, geralmente (e infelizmente) elas realmente são.

Então.....

A volta de Ricardão e Joãozinho

Ricardão e Joãozinho eram dois gerentes de projeto na empresa em que atuavam. Eram colegas de anos, desde a epoca do colégio.

Tinham filosofias diferentes de trabalho, o que sempre fez com que o Ricardão e o Joãozinho tivessem uma percepção totalmente diferente por parte de seus chefes e subordinados. Joãozinho, era extremamente técnico, mas pouco comunicativo. Adorava ficar trancado na sua sala fazendo planos, analisando riscos, enviando emails. Ricardão, ao contrário, quase nunca estava na sua cadeira. Andava de um lado para o outro com a equipe, ria com eles, cobrava quando tinha que cobrar, e ainda sobrava tempo para ele fazer outras coisas (como flertar com a assistente do diretor de RH).

Ricardão e Joãozinho almoçavam juntos e num destes almoços, Joãozinho perguntou ao Ricardão qual era a fórmula do sucesso dele. Por que os projetos dele davam sempre certo e os seus quase sempre ficavam à deriva, com um sucesso apenas "parcial". Ricardão não perdeu tempo:

- Antes de mais nada, Joãozinho, quero que tu me digas quantas vezes tu conversou com sua equipe no último mês.
- Olha, tivemos duas reuniões durante o mês, onde ficamos 3 horas debatendo o que deveríamos fazer. Saímos de lá com prazos definidos, mas não fiquei satisfeito pois meu ponto de vista prevaleceu, sem que eles contestassem.
- E por que tu achas que eles não protestaram?
- Olha, eles falaram tantas bobagens que eu tive que me impôr e provar como eles precisavam usar os riscos, o escopo, o prazo e o custo para chegar a uma conclusão.

Ricardão ajeitou a gravata, tomou um gole de sua Coca-cola Zero e falou:

- Joãozinho, você acha que trabalha em equipe ou a equipe trabalha para você?
- Como assim?
- Você é o gerente de projetos, cara! Tu realmente queres que a tua equipe saibas de riscos, custos e afins?
- Deveriam saber...
- Deveriam, sim! Mas quantas vezes tu apresentou isso para eles, de uma forma clara e sucinta?
- Não entendi!
- Fala sério: pensa que eles já tem preocupações técnicas muito grandes, assim como tu tens as preocupações com prazos, riscos, custos, etc. Porém, eu te garanto que eles sabem muito mais do que acontece no dia-a-dia do projeto do que tu.
- Ahh, isso eu duvido.
- Então vou te fazer uma simples pergunta e quero que tu me responda sinceramente.
- Ok.

Joãozinho se acomodou na cadeira, esperando as perguntas. Nada do que o Ricardão poderia perguntar, o Joãozinho não saberia responder. Ricardão jamais leu o PMBoK, não sabe nem ao certo o conceito de "projeto". Ele, alias, odeia ler. O que ele poderia saber que que o Joãozinho não saberia?

- Joãozinho... qual o nome dos cinco integrantes da tua equipe, os quais tu trabalha há 6 meses neste novo projeto?

Silêncio. Joãozinho engasgou e pronunciou alguns nomes... acertou um, e os demais ele realmente não soube responder.

- Está vendo, meu amigo? Você pode ser extremamente técnico, saber muito mais do que eu, sem dúvida. Mas tu já percebeu que tu não dedica quase nada do teu tempo para tua equipe? Tu quase nunca está disponível? Tu quase nunca conversa na fonte com eles? Será que essa tua idéia de que "eles estão sempre errados" é porque tu não sabe o que acontece no dia-a-dia dos seus projetos? E se eles estiverem certos?
- Bem... nunca havia pensado por essa forma.

Ricardão então resolveu propôr ao Joãozinho um desafio. Que durante uma semana, ele seguisse a seguinte rotina: chegasse no escritório, e por 1 hora ele ficaria no seu computador resolvendo seus problemas com planos, prazos, custos, e afins. Então ele passaria o restante do tempo junto à equipe, se comunicando, conversando e mesmo batendo papo. Joãozinho concordou, apesar de duvidar do resultado.

Uma semana passou.

Ricardão convidou Joãozinho para almoçar.

- Meu amigo, você deixou aquela sua sala muito vazia! Aguentou o tranco? Ela não ficou com saudades de você?
- Ha ha ha... de fato, fiz o que tu pediu.
- E... ?
- Bem, tenho que dar o braço a torcer. Eu tive uma visão completamente diferente do que estava acostumado. Percebi quantos problemas minha equipe tinha. Coisas que eu nem imaginava e que eles me disseram que não se sentiam à vontade de levantar nas reuniões, pois eu não dava abertura. Você acredita que eles trabalhavam com versões "trial" do sistema? Ou então que usavam um alicate como chave de fenda? Não, a pior eu não te contei... eles estavam com dificuldades imensas na definição do documento (sabe como é técnico escrevendo né?). Confesso que eu não parei um minuto!
- Excelente, Joãozinho. Tu aprendeu agora porque a maioria dos projetos falham: a falta de comunicação.
- Eu sei... quando aprendi isso, me pareceu algo tão teórico. Eu imaginava "Ah, é só fazer uma matriz de responsabilidades e todos irão seguí-las". Mas notei que as coisas não são bem assim.
- Exatamente. Eu não sei ao certo o que é uma matriz de atividades...
- Responsabilidades.
- Isso! Mas te confesso que delego todas as coisas técnicas para meus subordinados e procuro sempre mantê-los motivados e satisfeitos com o que fazem. Posso não saber compilar um código, mas te garanto que irei me esforçar para auxiliá-los a resolver o problema.

Joãozinho havia aprendido uma lição importantíssima. A comunicação é a alma de um projeto. Não se dedicar a ela, significa ser um anti-lider. Para liderar, precisamos saber do que nossos funcionários precisam. E romper todas as barreiras para que eles trabalhem satisfeitos e sem qualquer problema. Joãozinho completou:

- E o melhor! Agora não só sei o nome dos meus funcionários, como trato todos pelos seus devidos nomes. Que mudança isso traz!



Na saída do almoço, Nádia, a assistente loira e maravilhosa do diretor passou pelos dois. Ricardão abriu um sorriso.

- Nádia, minha querida. Tudo bem contigo?
- Olá Ricardão!! Está tudo ótimo. Obrigado pelo email que me mandaste hoje, fiquei muito feliz!
- Que isso, minha garota. O seu sorriso é meu combustível até o fim do dia.
- Obrigada! Ah, Joãozinho. À propósito, respondendo ao seu email, eu aceito ir ao cinema. Obrigada pelo convite!

Joãozinho acenou e agradeceu. Enquanto ambos admiravam aquela simpática e linda assistente andar em câmera lenta e com os cabelos ao vento (como naqueles clichês de filmes), Ricardão virou-se para o Joãozinho:

- Mas que diabos foi isso?!
- Ora, meu amigo. Você é um ótimo comunicador! Mas precisa ter uma meta e um deadline para cumprir. Eu apenas segui meu instinto prático.
- Joãozinho... se não fossemos amigos, eu te afogava neste copo de Coca-cola Zero. Mas me diga mais sobre metas e deadlines...

E ambos sairam conversando animadamente. A ligação entre eles era forte, seus inconscientes sabiam que um completava o outro e que muitas lições ainda viriam por vir, por ambas as partes.

Nádia e Joãozinho tiveram uma noite sensacional. Mas este não é o foco da nossa história, certo? ;)

Dicas para comunicação

Como mencionei em um post anterior (o quilométrico!), li um livro sobre "Supercomunicação com neurolinguística". E ali existem duas dicas bem interessantes para facilitar a comunicação, principalmente para o caso de pessoas que não conhecemos (olha aí uma dica importante para começar um networking!).

O autor menciona a necessidade de termos as perguntas certas, e as vezes não sabemos muito bem como nos aproximar. Então ele sugere usar o método FROGS. Que significa perguntar:

F = familia e amigos
R = recreação e lazer
O = ocupação
G = geografia
S = vida social

Olhando isso, vemos como realmente é simples! "Você tem filhos? Você é casado?", "O que você gosta de fazer? Gosta de futebol? Gosta de fotografia?", "Como está o seu trabalho? Como você motiva sua equipe?", "Onde você passou as suas férias? Você já esteve no Rio Grande do Sul?", "Você costuma sair muito? Já foi naquele restaurante tal?".

São perguntas não muito evasivas e não muito particulares. Dá uma margem boa para iniciar uma conversa e identificar pontos em comum. Identificados estes pontos, fica muito mais simples de fluir com a conversa. "Você também é gremista? Que legal! O que achou do jogo ontem?".

Uma frase do autor, em seguida, é bem interessante: "Se você fizer boas perguntas, ouvir com atenção e fornecer alimento emocional à sua conversa, gradualmente ganhará respeito e autoconfiança".

O alimento emocional que o autor menciona pode ser descrito pelo acrônimo AARDVARC (meio chatinho de decorar, admito, mas interessante):

A = apreciação
A = aceitação
R = respeito e reconhecimento
D = desejo
V = valor
A = aprovação
R = reestabelecimento de confiança
C = contratulações, elogios

"Para ser interessante, seja interessado" ele termina o capítulo. O que significa cada um desses itens?

Apreciação: por exemplo, apreciar o fato da outra pessoa estar lhe disponibilizando um tempo para você. Durante a reunião, tentar apreciar o conhecimento dele. O fato aqui é "massagear o ego" da pessoa com a qual você está conversando. Segundo o autor, se você apreciar o seu modo de pensar, o que está dizendo e o seu sentimento, é quase certo que ele mostrará apreciação pela próxima coisa que você disser, dando crédito por ela.

Aceitação: é o combustivel do ser humano. Todos nós precisamos nos sentir aceitos, isso é fato. O desejo de qualquer pessoa é encontrar alguém com que possa se sentir à vontade, você concorda? Aqui não tem grandes dicas. Diz apenas para você aceitar a pessoa com a qual você está conversando.

Reconhecimento/Respeito: Usando a questão da reunião de negócios, você pode em um certo momento expressar que sente um enorme respeito pela maneira como ele está conduzindo o projeto. Você afaga o ego dele de novo, e isso o torna ainda mais confiante em relação a você. O difícil, neste caso, é não parecer um bajulador barato, pois isso tende a apenas piorar as coisas. Honestidade e sinceridade devem valer. Se ele é um péssimo gerente de projetos, tente elogiar alguma atitude dele. "Um grande respeito pela sua atitude na forma como conduziu aquele conflito com seu time".

Desejo: no mundo dos negócios, essa palavra não tem muita aplicação. Mas sabemos que todo ser humano gosta de se sentir desejado (como apreciado). Só cuidado para não expressar o seu desejo por aquela loira da foto, que pode vir a ser a pessoa com a qual você negocia :)

Valor: as pessoas gostam de se sentir úteis e que suas opiniões ou atitudes tem valor. Durante uma reunião, um simples: "A sua opinião sobre este assunto seria de grande valor para mim". Seria como dizer: "Seu que você é inteligente". Ou utilize isso no final da reunião com um "Ótima reunião! Suas opiniões foram valiosas para nós".

Aprovação: somos todos eternas crianças. Portanto, sentimos a necessidade de aprovação o tempo todo. Você deve aprovar as atitudes de seus subordinados, por exemplo, sempre quando convir. Aqui vale aquela regra do "gerente-minuto": flagre seus funcionários fazendo coisas boas e certas, e elogie! Demonstre sua aprovação com isso. E se algo não estiver realmente bom? Use um "Realmente posso perceber que você está se esforçando bastante; está ficando muito bom" e em seguida você pode usar um "MAS" e em seguida sugerir algumas alterações. Isso não é mais correto do que usar um "Não!! Está tudo errado!! Suma da minha frente com isso e refaça!!"?

Restabelecimento da confiança: todos precisam que sua confiança seja restabelecida em um ou outro estágio. Um exemplo bem clássico é aquela pessoa que recém se acidentou com o carro. Ele demora um tempo até ter novamente confiança em fazer aquilo que antes era tão trivial. Por isso, mesmo que você ache que a pessoa que você está dialogando ainda está satisfeito com alguma coisa, busque se informar se realmente está tudo ok. Certifique-se de que ele ainda confia em você da mesma forma.

Congratulação: um elogio sincero geralmente é um dos maiores motivadores nas empresas. Uma dica interessante aqui é personalizar os elogios. Ao invés de elogiar um trabalho realizado, tente elogiar a forma com que a pessoa realizou o trabalho. Dessa forma você está elogiando explicitamente não só o resultado, mas também a pessoa que o realizou.

A dica final que o livro traz é de elogiar sempre com sinceridade. Se você descobrir que o seu cliente tem um interesse em comum com você (um hobby, por exemplo) você pode quebrar o gelo e começar a estabelecer um sentimento de confiança quase que instantâneo. Um exemplo simples: você entra na sala de um cliente e nota que ele tem uma placa de prata com o seu nome, diversas folhas de papel em cima da mesa, um computador notebook de última geração, um quadro onde aparecem sua filha bonita e alguns troféus de campeonatos de boliche.

O que você apreciaria? Eu, particularmente, tentaria os troféus de boliche. Visivelmente é algo que ele gosta de fazer e dedica um bom tempo nisso, ao ponto de participar de campeonatos. De repente ele menciona algo sobre os filhos, e você já emenda dizendo que a filha dele é muito bonita (sem demonstrar excitação, por favor!) e pergunta se tem mais filhos. Aí a conversa já pode entrar na tática FROGS. Você deixou ele falar a respeito de um assunto que com certeza abriu um leque de opções interessantes para vocês dois se conhecerem melhor. E é mais fácil negociar com alguém que se sente mais a vontade, do que negociar com alguém que o olha com desconfiança.

Se você elogiasse seu notebook, fizesse algum comentário sobre a placa de prata ou sobre as folhas de papel (ou pior ainda, falasse da filha diretamente) você seria muito superficial. Imagine o elogio ao notebook. Ele possivelmente falaria que "é uma boa máquina realmente". O que você falaria em seguida? "Onde você comprou"? "Roda GTA4"? Ou quem sabe "Quanto custou"? Todas essas perguntas não acrescentariam nada, não acham?

Enfim. Acho que essas dicas acrescentam bastante no nosso dia-a-dia. Seja com nossos subordinados, seja com nossos chefes, seja com clientes ou mesmo quando quisermos realizar networking com colegas de cursos e afins.

Espero que gostem das dicas!! :)

Um abraço

Relações interpessoais e o gerente de projeto

Todos que estudam gerência de projeto (e aqueles que visitam o meu blog frequentemente) sabem como é importante para um GP a comunicação. A comunicação não apenas verbal, escrita... mas também o que envolve a comunicação, ou seja, as relações interpessoais.

É muito importante que um GP saiba lidar com pessoas. De nada adianta você ser um mestre em redigir emails, mas não consegue se relacionar com seus subordinados ao vivo. Ou aquele GP que é honesto e sincero, mas que não mede o tom de um feedback.

Quando eu digo que pretendo sempre melhorar a minha comunicação, eu considero também essas relações interpessoais como um dos principais focos. Eu não acho que eu seja um exímio comunicador... eu tenho algumas qualidades, mas tenho outros defeitos. E pretendo primeiro minimizar os defeitos para depois potencializar as qualidades. Essa é a minha meta.

Recentemente li um livro (daquelas leituras de 1 hora) chamado "Supercomunicação com neurolinguistica". Ele é um livro do mesmo estilo dos que eu citei em posts anteriores da Você S/A, mas esse é da Gazeta Mercantil. O livro tem alguns conceitos bacanas, mas notei que ele foca bastante para as vendas.

Pensei com meus botões: ora, um GP antes de ser um GP, ele também É um vendedor, não acham? Um GP precisa agir como vendedor, pois precisa vender suas idéias e conceitos, precisa saber agradar seu interlocutor, precisa "fidelizar" seus subordinados e precisa, principalmente, ter pensamento rápido para agir. Após ler o livro, me veio na cabeça a idéia de fazer um curso de vendas... pois acredito que poderá ser útil.

Por que estou escrevendo este post? Fiz essa introdução para descrever a vocês TRÊS casos de mau atendimento que eu tive nos últimos dias. E falar sobre principalmente o impacto negativo que isso teve em mim (como cliente) e a minha opinião do que eu faria no lugar dos "vendedores". Vamos lá.

------------------

Caso 1: Unibanco Arteplex - Sábado de noite - Bomboniere

Levei a minha namorada e a minha sobrinha no cinema. Passamos um final de semana terrível aqui, com um ciclone extratropical deixando a sexta, o sábado e o domingo como dias de caos. Então era esperado que o movimento nos cinemas seria MUITO maior. Mesmo assim fomos. Minha sobrinha resolveu de ultima hora assistir um filme de comédia, o filme começava dentro de 10 minutos.

Para agradá-la, como um bom tio, fui comprar pipoca. A fila era enorme, pra variar. Umas 20 pessoas para a fila do caixa e mais umas 10 esperando a pipoca. E aqui já ficou aparente o erro número um da lojinha: eles tem apenas uma máquina que faz pipoca doce e uma que faz salgada. As pipocas prontas acabaram logo e então tava tudo "on demand". Quando acabava de estourar uma panela, já tinham que colocar outra, pois a fila crescia exponencialmente. Terrível ver que eles tem anos de experiência no local e ainda não conseguiram se organizar para situações de movimento. Sem contar o preço absurdo... mas isso é esperado.

Uns 10 minutos na fila para comprar a pipoca. Quando chegou minha vez, fiz o pedido para um caixa já não muito simpático. "Uma água e uma pipoca média". Ele me atendeu enquanto falava com outras duas atentendes e me deu a nota. Eu vi aquela fila de espera e fiquei meio sem saber o que fazer. Então ele disse: "Senhor, pode esperar mais para lá?". Ok, pelo bem da "organização" fiz isso.

Esperei... os atendentes chamavam por números. "91! 92! 93!". Tentei achar onde estava esse número na minha nota. Nada! As pessoas da fila começaram a ficar impacientes com a demora. As atendentes visivelmente despreparadas tentavam se virar como podiam, mas não demonstravam simpatia em nos atender. "94! 95! 96!" e as pessoas que estavam ATRÁS de mim na fila do caixa começaram a ganhar as pipocas. Eu e outros começamos a protestar. A atendente veio, viu minha nota para ver se era um dos números e me devolveu. E eu continuei esperando. E o filme começando.

Lá pelas tantas chamei uma atendente e perguntei o meu número, expressando minha irritação (embora eu seja daquelas pessoas que não conseguem ser BRAVAS - eu estava já visivelmente irritado). Ela perguntou se eu não tinha dado a nota para uma das atendentes colocar o número lá no caixa. Eu disse que ninguém me falou nada! Então ela me deu um número... atrás da fila de espera. Ou seja, eu fiquei na fila por 30 minutos por NADA. Eu estava furioso, mas já que estava ali queria a pipoca... só de raiva. Outro cliente quis chamar o gerente para reclamar, estava na mesma situação que eu. Uns 5 minutos depois, recebi minha pipoca e minha água. E nenhnum pedido de desculpa. Perdi 25 minutos de filme. Me senti TOTALMENTE lesado.

O que eu faria nessa situação? Primeiro, se eles tinham um processo para seguir (caixa -> marcação do número -> fila -> entrega) porque ninguém foi lá reclamar para o caixa que ele estava fazendo algo errado ou não estava informando corretamente. Como atendente, eu no mínimo me colocaria do lado do cliente. Mesmo que seja um "teatrinho", mas nessas horas o cliente quer ver que tem a razão, quer se sentir menos lesado. Segundo, visto que eu não tinha número e estava na fila, deveria ter sido o PRIMEIRO a receber a pipoca. Uma frase do tipo "Desculpe senhor, você será o primeiro da fila agora na próxima panela, ok?". E por fim, obviamente, um pedido de desculpas ao receber o pedido. Um simples: "Muito obrigado senhor, e desculpe pela demora/confusão/etc". Isso já diminuiria também a raiva. Nada disso foi feito, e a sensação de que eu fui lesado permaneceu. Tanto é que faço questão de dizer que eu NUNCA MAIS compro um chiclete lá nessa lojinha. E estou dizendo para todos que eu conheço não fazerem o mesmo.

------------------

Caso 2: Caixa Econômica Federal - Manhã

Hoje eu fui no banco, mais especificamente na CEF. Eles tem um sistema personalizado de atendimento que é "bonitinho", mas que na prática é apenas um processo que tenta mascarar as filas. A gente chega, dá o nome para uma atendente e vamos nos sentar.

O fato de haver poltronas para sentar, já é interessante. As pessoas ficam mais a vontade e reduz um pouco aquela cena chata de filas e mais filas. Os bancos tem aquela lei que diz que em dias normais o tempo de espera deve ser de no máximo 15 minutos e em dias de exceção, 20 minutos.

O problema da Caixa (e de muitos bancos) é que existem muitos idosos. E eles são geralmente as pessoas que atrasam as filas. Eu ainda estou para ver um banco que crie um caixa exclusivo para idosos, com um atendimento diferenciado e que não influencie no andamento da fila dos demais.

Haviam 5 pessoas na minha frente. Dava pra ver, pois eram poucas. Essas 5 pessoas foram atendidas em uns 10 minutos. Nesse meio tempo, alguns idosos chegaram. E, lógico, passaram na frente pois tem prioridade. Até aí tudo bem. Só que como é um banco público, os idosos chegam quase a todo momento. E eu comecei a notar que fui sendo empurrado para o fim da fila... Os 10 minutos viraram 20. E quando chegou em 30 minutos, eu fiquei bravo. E fui falar com a atendente.

E ela agiu como deveria agir: "Senhor Flávio, o senhor é o próximo a ser chamado, ok?". Aquela irritação minimizou, mesmo sabendo que, novamente, estava sendo lesado, ao menos notei que eles tomaram alguma atitude para reduzir o dano. E realmente eu fui o próximo a ser chamado.

Nesse caso, acho que a atendente agiu muito bem. Ela poderia dar mil explicações do tipo "Mas é que os idosos tem preferência, bla bla bla" o que causaria uma discussão desnecessária sobre "mas eu tenho compromissos e bla bla". Ela simplesmente me colocou como o próximo da fila (não sei se eu realmente era o próximo ou se ela me colocou como próximo) e pronto. A situação estava minimizada.

A solução que eu vejo nisso é fazer uma "escala". Os idosos tem a preferência, mas também podem aguardar alguns minutinhos, ainda mais que lá existem essas poltronas para sentar. Então coloque alguém da fila normal, um idoso, alguém da fila normal, um idoso. E assim as duas filas andam e todos ficam satisfeitos. Não sei se isso é feito, mas me pareceu que não. Mas aqui o dano não foi tão grande. Não sai me sentindo lesado, apesar de ter ficado 35 minutos esperando na fila, quando o certo seriam 15 minutos.

------------------

Caso 3: Revendedora FIAT - Meu rádio que não chega nunca!

Comprei o meu carro, um Palio 2008, com um daqueles rádios integrados no painel cheio de funcionalidades. Paguei caro, mas me foi prometido que o rádio chegaria poucos dias depois do meu carro. A pessoa que me vendeu é um dos melhores vendedores que eu já cruzei.

Acontece que o rádio que era para vir em 5 dias, já está demorando quase um mês. Já liguei 3x para a concessionária para perguntar o que estava acontecendo. Eles sempre falam que "assim que tiverem uma posição, me darão um retorno por telefone". Mas esse retorno não vem nunca. Esse talvez seja o grande erro deles.

Hoje fui pessoalmente lá falar com o meu vendedor. Ele é muito bom mesmo. Pelo telefone, quando liguei, prontamente ele já disse que "há poucos minutos atrás estava cobrando a fábrica". Ele tem as frases que a gente gosta de ouvir, mesmo sabendo que na maioria das vezes são apenas frases prontas. Mas o cliente gosta de saber que o vendedor está do lado dele.

Ao vivo, ele me atendeu e eu falei: "Vim saber do meu rádio! Já vou para o quarto mês e não estou entendendo o por que da demora!". Sentamos na mesa dele, e ele na minha frente já ligou novamente para a fábrica. Falou que o cliente estava na frente dele querendo esganá-lo (falou num tom sério, para dar mais drama) e obteve a resposta que a fábrica enviaria no máximo amanhã, para chegar em uns 3 dias. Saí de lá um pouco decepcionado, pela demora de uma peça. Mas ao menos com uma resposta: a fábrica está vendendo além da capacidade (comercial x produção, de novo) e não está dando conta dos pedidos, ainda mais avulsos.

Apesar de estar chateado, é difícil se sentir lesado quando nós percebemos que o vendedor está realmente fazendo o possível pela gente, está do nosso lado. Ele foi bem transparente comigo, me deu respostas e se mostrou a disposição para me auxiliar. Agiu como deveria agir, o que demonstra que essa concessionária ou contrata muito bem, ou possui bons treinamentos.

------------------

O que aprendemos com esses três casos? As relações interpessoais são claras e evidentes em todos os casos, quando falham e quando funcionam. Nos três casos eu fui lesado (de alguma forma), mas notem que a abordagem dos atendentes/vendedores influenciou muito a minha atitude perante a situação. No caso 1, eu sai lesado e não quero nem passar perto daquela loja. No caso 2, me senti lesado mas a coisa foi minimizada de uma forma simples e direta. No caso 3, me senti lesado, mas o fato do próprio vendedor transparecer que se sente lesado também, acabou por não mudar a imagem que eu fiquei quando comprei: de que fiz um ótimo negócio.

Um gerente de projetos que agir conforme o caso 2 e 3, com todos os stakeholders, será um gerente que atuará com caráter e da forma correta na condução de conflitos. Um GP que optar pelo caso 1, estará fadado ao fracasso. Simples assim.

Para acabar, quero só deixar rapidamente um elogio para uma das lojas onde eu fui melhor atendido até hoje, pelo menos que eu me lembre. É a loja de roupas masculinas (acho que só existe aqui no RS) Tevah.

Entrei na loja e um vendedor já veio solícito me receber. Primeira pergunta: "Qual o seu nome?", e me chamou pelo nome em todo o momento. O gerente também me recebeu, me chamou pelo nome, e demonstrou uma "química" bacana com o vendedor, seja na condução da venda, seja no auxílio da compra. Eles conversam conosco durante a venda, visivelmente não tentam nos empurrar mercadorias (eles sugerem, mas fazem ressalvas). Por fim, ainda chamaram eu e a minha namorada de "casal simpático que merece um desconto". Entrei para comprar uma gravata. Sai com uma gravata, uma camisa e uma meia. E sai feliz e com a sensação de que sempre que precisar de roupas sociais, irei nesta loja apenas!

Eles usaram uma técnica bem simples: agrade o cliente e ele será fiel. Impressionante que existem ainda pessoas que NÃO fazem isso.

Relações interpessoais. Invista nisso. Com certeza você será um gerente de projetos cada vez melhor.

Ufa. Um post quilométrico, mas acho que bem ilustrativo e informativo. Espero que gostem!