Aos remadores...

Foi realizada uma competição de remo entre a equipe do Japão e a equipe brasileira. 

A competição se inicia, mas o resultado não é favorável para a equipe brasileira. Os brasileiros chegaram com uma hora de atraso em relação aos  japoneses. Indignados, foi realizada uma reunião para averiguar a causada derrota. 


Assim ficou o status report comparando as equipes:

 * Japão:
 1 Chefe de Equipe
 10 Remadores

 * Brasil:
 10 Chefes de Equipe
 1 Remador

Descoberto o grande erro, a equipe brasileira foi remodeladapara uma próxima competição... Porém, perdemos novamente, dessa vez, o nosso atraso foi de 2 horas... 
 
Mais uma vez foi convocada uma reunião para estudo das causas. Segue o status report:

 * Japão :
 1 Chefe de Equipe
 10 Remadores

 * Brasil:
 1 Chefe de Equipe
 3 Coordenadores de Departamento
 6 Assistentes
 1 Remador

Mais uma vez, o erro foi identificado e uma nova equipe foi montada... Tudo foi levado em conta: resizing, downzing, GQT, etc.  Porém,depois de mais uma competçião, o Brasil chegou com 3 horas de atraso... 
Segue o status report:

 * Japão:
 1 Chefe de Equipe
 10 Remadores
 
 * Brasil:
 1 Chefe de Equipe
 1 Gerente de Projeto
 3 Coordenadores de Departamento
 1 Analista de Sistema
 2 Controllers
 1 Auditor Independente
 1 Gerente de Qualidade Total
 1 Remador

Depois de muita discussão, chegaram à seguinte "conclusão definitiva": O problema era o remador que por falta de treinamento e influência do Sindicato, não era capaz de exercer suas atividades com eficiência. 


A solução é terceirizar - econtratar um remador que não seja da folha do clube...

GO HORSE (XGH) - Gestão da Escopo

Fonte: http://aticomoelae.blogspot.com/2011/05/da-serie-go-horse-gestao-da-escopo.html?spref=bl
Os burocratas do PMI inventaram um monte de baboseiras para gerir o escopo do projeto… WBS, declaração do escopo, blá, blá, blá…

O Go Horse não perde tempo com asneiras como essas, pois se preocupa com o fundamental: ganhar a conta do cliente.

Não adianta perder tempo com previsões e futurologia… tem que dizer para o cliente que tudo o que ele quer vai ser entregue no prazo que ele deseja – só assim se ganha a conta. Depois, se dá um jeito pra fazer tudo – basta jogar a bomba no colo da equipe do projeto.

O gerente de projetos Go Horse deve submeter a sua equipe a um estado permanente de terror, de modo que a mesma trabalhe horas extras para cumprir oescopo, não apenas sem reclamar, mas pensando que não faz nada além da obrigação.

Às vésperas da entrega do projeto, após várias madrugadas de trabalho (por parte da equipe, não do gerente, claro), entrega-se o escopo completo, mas nas coxas. Enquanto o cliente testa, o time segue corrigindo os erros que sabe que existem. Perda de tempo zero, sucesso total.

GO HORSE (XGH) - Gestão das Aquisições

Fonte: http://aticomoelae.blogspot.com/2011/05/da-serie-go-horse-gestao-das-aquisicoes.html?spref=bl
Essa é uma área que os chatos do PMI se esforçaram para encher de inutilidades. Papéis, papéis, papéis, documentos inúteis…

O PMBOK propõe um processo burocratizado e custoso para realizar concorrência de fornecedores. Ora, para que tudo isso se um parente ou amigo seu pode fazer o trabalho terceirizado? Quem sabe, se você contratar a empresa de um parente, pode até levar um por fora!

É mais ou menos como fazem os políticos no Brasil: preenchem os cargos em seus gabinetes com suas esposas, filhos e afilhados, afinal de contas, quem pode ser mais confiável do que a família, não é mesmo?

Enquanto o PMI condiciona a decisão de fazer ou contratar um serviço à capacidade da empresa de executá-lo, o Go Horse vai pelo caminho inverso: condiciona a sua capacidade de realização à existência de um amigo que faça o serviço!

GO HORSE (XGH): Gestão da Comunicação

Fonte: http://aticomoelae.blogspot.com/2011/05/da-serie-go-horse-gestao-da-comunicacao.html?spref=bl

A comunicação talvez seja a área de conhecimento que demandou dos burocratas do PMI a maior parcela de criatividade.

Comunicação deveria ser simples: vai lá e fala pro cara o que ele tem que fazer! Mas não: pessoas perderam seu tempo precioso produzindo páginas e páginas com instruções sobre como burocratizar aquilo que a humanidade faz desde os seus primórdios, que é comunicar-se.

Planejamento da comunicação, atas de reunião, relatórios de desempenho, blá, blá, blá… para quê tudo isso se basta passar a informação ao interessado?

O Go Horse acredita em duas ferramentas para comunicação:

- Capacidade de compreensão do ouvinte: para bom entendedor, meia palavra basta. O que dizer de uma palavra inteira? É só falar para o cara o que ele tem que fazer e pronto!

- Poder na estrutura hierárquica: se o ouvinte não faz a tarefa direito porque (diz que) não entendeu, ou que ninguém pediu nada daquilo para ele, basta usar a hierarquia. Palavra de chefe é a verdade, e ponto final. Isso acaba com qualquer ambigüidade.

GO HORSE - eXtreme Go Horse (XGH): origens

link original: http://aticomoelae.blogspot.com/2011/05/da-serie-go-horse-extreme-go-horse-xgh.html

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

"Go Horse" for Project Management

link original: http://aticomoelae.blogspot.com/2011/01/em-tempo-12-go-horse-solucao.html


É comum nas grandes empresas a adoção do conjunto de práticas do PMI para gerencia de seus projetos. O guia PMBOK, ou Project Management Body of Knowledge esta aí na sua versão 4 e detalha, passo a passo, o que deve-se fazer para uma boa gerencia de um projeto. 
O único detalhe... É difícil faze-lo funcionar na nossa realidade!

Todos nós conhecemos e é comum em grandes - pequenas, médias, etc... - empresas a alta taxa de projetos com falha, na TI então... nem se fala.Algumas pesquisas* mostram que mais de 60% não entregam o escopo definido, extrapolam seus custos e não cumprem seus cronogramas. Isso não é nenhuma novidade, mas nem por isso as corporações deixam de criar seus PMOs, desenvolver metodologias e manuais e obrigar suas equipes, quase sempre pouco qualificadas, a formalidade e a exatidão do PMBOK. Inevitavelmente, a união de todos estes fatores levam os projetos ao fracasso ou aquela percepção de que "poderia ter sido melhor"...

Mas... vem que aparece o Go Horse. Esse sim, largamente utilizado nas empresas. O interessante desta 'metodologia' é que na maioria das vezes nem seus executores percebem que a utilizam.
 

Qualidade??? Para o Go Horse, qualidade é simples: tem que fazer direito a porra do trabalho!

Pesquisando... identifiquei que este assunto não é nada novo, escritos antigos e depoimentos de programadores Fortram aposentados mostram que desde a criação do PMI e da Informática como conhecemos, o Go Horse já era utilizado com sucesso. 

Mas meus amigos, o objetivo daqui é somente introduzir o assunto e induzir o estudo. Por isso não vou escrever parágrafos ou mais opiniões sobre o GH. "Realmente Funciona!!!!". 

Histórias de Suporte (IX)

Histórias de Suporte (VIII)

Histórias de Suporte (VII)

Histórias de Suporte (VI)

Histórias de Suporte (V)

Histórias de Suporte (IV)

Histórias de Suporte (III)

Histórias de Suporte (II)

Histórias de Suporte (I)

Fluxograma para resolução de problemas (review)

Sempre que houver algum problema em seu projeto, use e abuse deste fluxograma...

Como contratar um funcionário em 17 passos.

O método consiste em:

1-Colocar todos os candidatos num galpão.

2-Disponibilizar 200 tijolos para cada um.

3-Não dê orientação alguma sobre o que fazer.

4-Tranque-os lá.



Após seis horas, volte e verifique o que fizeram. Segue a análise dos resultados:

1 - Os que contaram os tijolos contrate como contadores.

2 - Os que contaram e em seguida recontaram os tijolos, são auditores.

3 - Os que espalharam os tijolos são engenheiros.

4 - Os que tiverem arrumado os tijolos de maneira muito estranha, difícil de entender, coloque-os no Planejamento, Projeto e Implantação Controle de Produção. (PCP).

5 - Os que estiverem jogando tijolos uns nos outros, coloque-os em Operações.

6 - Os que estiverem dormindo, coloque-os na Segurança.

7 - Aqueles que picaram os tijolos em pedacinhos e estiverem tentando montá-los novamente, devem ir direto à Tecnologia da Informação.

8 - Os que estiverem sentados sem fazer nada ou observando com olhar distante são dos Recursos Humanos.

9 - Os que disserem que fizeram de tudo para diminuir o estoque, mas a concorrência está desleal e será preciso pensar em maiores facilidades, são vendedores natos.

10 - Os que já tiverem saído são gerentes.

11 - Os que estiverem olhando pela janela com o olhar perdido no infinito, são os responsáveis pelo Planejamento Estratégico.

12 - Os que estiverem conversando entre si com as mãos no bolso demonstrando que nem sequer tocaram nos tijolos e jamais fariam isso, cumprimente- os com muito respeito e coloque-os na Diretoria.

13 - os que levantaram um muro e se esconderam atrás, são do departamento de Marketing.

14 - Os que afirmarem não estar vendo tijolo algum na sala, são advogados, encaminhem ao Departamento Jurídico.

15 - Os que reclamarem que os tijolos 'estão uma porcaria, sem identificação, sem padronização e com medidas erradas', coloque na Qualidade.

16 - Os que separaram os tijolos, e, tentaram verificar qual a diferença para colocar os códigos contrate como expedição.

17 - Os que começarem a chamar os demais de 'companheiros’, elimine-os imediatamente antes que criem um sindicato, fiquem poderosos e ocupem a presidência.

********************************************************
Colaboração de Henrique Felisbino

Como funciona o mundo corporativo

Todos os dias, uma formiga chegava cedinho ao escritório e pegava duro no trabalho... A formiga era produtiva e feliz. 


O gerente marimbondo estranhou a formiga trabalhar sem supervisão. Se ela era produtiva sem supervisão, seria ainda mais se fosse supervisionada. E colocou uma barata, que preparava belíssimos relatórios e tinha muita experiência, como supervisora. A primeira preocupação da barata foi a de padronizar o horário de entrada e saída da formiga.

Logo, a barata precisou de uma secretária para ajudar a preparar os relatórios e contratou também uma aranha para organizar os arquivos e controlar as ligações telefônicas.

O marimbondo ficou encantado com os relatórios da barata e pediu também gráficos com indicadores e análise das tendências que eram mostradas em reuniões. A barata, então, contratou uma mosca, e comprou um computador com impressora colorida. 


Logo, a formiga produtiva e feliz, começou a se lamentar de toda aquela movimentação de papéis e reuniões!

O marimbondo concluiu que era o momento de criar a função de gestor para a área onde a formiga produtiva e feliz, trabalhava.

O cargo foi dado a uma cigarra, que mandou colocar carpete no seu escritório e comprar uma cadeira especial... A nova gestora cigarra logo precisou de um computador e de uma assistente: a pulga (sua assistente na empresa anterior), para ajudá-la a preparar um plano estratégico de melhorias e um controle do orçamento para a área onde trabalhava a formiga, que já não cantarolava mais e cada dia se tornava mais chateada.

A cigarra, então, convenceu o gerente marimbondo, que era preciso fazer um estudo de clima. Mas, o marimbondo, ao rever as cifras, se deu conta de que a unidade na qual a formiga trabalhava já não rendia como antes e contratou a coruja, uma prestigiada consultora, muito famosa, para que fizesse um diagnóstico da situação. A coruja permaneceu três meses nos escritórios e emitiu um enorme relatório, com vários volumes que concluía : Há muita gente nesta empresa!!

E adivinha quem o marimbondo mandou demitir? A formiga, claro, porque ela andava muito desmotivada e aborrecida!!!

Dicas para uma boa gestão (VII)

Um fazendeiro resolve colher algumas frutas em sua propriedade, pega um balde vazio e segue rumo às árvores frutíferas. No caminho ao passar por uma lagoa, ouve vozes femininas que provavelmente invadiram suas terras.

Ao se aproximar lentamente, observa várias belas garotas nuas se banhando na lagoa, quando elas percebem a sua presença, nadam até a parte mais profunda da lagoa e gritam:

 - Nós não vamos sair daqui enquanto você não deixar de nos espiar e for embora.

O fazendeiro responde:

- Eu não vim aqui para espiar vocês, eu só vim alimentar os jacarés!

Conclusão:

A criatividade é o que faz a diferença na hora de atingirmos nossos objetivos mais rapidamente.

Dicas para uma boa gestão (VI)

Um corvo está sentado numa árvore o dia inteiro sem fazer nada. Um pequeno coelho vê o corvo e pergunta:

- "Eu posso sentar como você e não fazer nada o dia inteiro?"

O corvo responde, sorrindo:

 - "Claro, porque não?"

O coelho senta no chão embaixo da árvore, e relaxa. De repente uma raposa aparece e come o coelho.

Conclusão:

Para ficar sentado sem fazer nada, você deve estar no topo.