Showing posts with label Go Horse Process. Show all posts
Showing posts with label Go Horse Process. Show all posts
Saturday, January 09, 2016
Soft Skills
Soft skills, até pouco tempo ignoradas, viraram uma verdadeira modinha no mundo corporativo nos últimos anos. Muito se fala na importância das soft skills e em como desenvolvê-las, o que é um grande desafio, já que primeiro devemos identificar o que elas são.
Idiotices como pesquisas sobre melhores empresas para se trabalhar ganharam muita força ultimamente, dando aos horses a ilusão de que seus empregadores possuem algum dever junto à peonada no que diz respeito a bem estar e condições de trabalho. Dentre os critérios que tais pesquisas inúteis utilizam para qualificar uma empresa como boa ou ruim para se trabalhar está a tal da “meritocracia”, ou “promoção por mérito”. De repente, a peonada começou a se insurgir contra uma das mais antigas práticas Go Horse: a promoção baseada na amizade e confiança.
O horse deve ter em mente que chefe não é pai e promove quem bem entender. Além disso, uma promoção para um cargo de natureza gerencial exclui o promovido do ciclo produtivo, o que faz da promoção por mérito uma grande inconveniência.
Tendo em vista o fato de que as atividades de um gerente se assemelham muito ao trabalho de verdade, porém totalmente alheias à construção do bem ou serviço vendido pela organização, promoções para cargos gerenciais passaram a ser justificados pelas tais “soft skills”. Ou seja, se algum peão ousar contestar uma promoção de alguém que não demonstra, segundo seu julgamento, a qualificação necessária, basta respondê-lo que tal promoção se deu em virtude de soft skills que o recém promovido detém.
Uma soft skill é uma competência ou característica pessoal atrelada à personalidade e que, ao contrário das competências técnicas, não demanda esforço por parte da pessoa que deseja desenvolvê-la. A avaliação de uma soft skill de alguém é vaga e subjetiva, o que torna extremamente fácil a um chefe goHorser justificar a promoção de um amigo incompetente.
Ou seja, soft skills são uma criação de membros goHorsers do Círculo de Confiança que tem como objetivo viabilizar uma fácil justificativa para uma inclusão repentina de um amigo às altas rodas da empresa.
Tal criação se mostrou tão eficiente na obtenção do seu objetivo que, em muitas empresas, ser competente tecnicamente depõe contra o horse. Isso significa que, se desejamos manter um horse competente eternamente na condição de peão, basta rotulá-lo como alguém “essencialmente técnico e sem soft skills”. Hoje é muito comum o fato de horses omitirem suas qualificações técnicas para manterem vivas as suas chances de ascender ao Círculo de Confiança.
Conheça algumas Soft Skills:
Nome Técnico: Sociabilidade
Significado: Vaselina
O que é: capacidade de dar tapinhas nas costas e sorrir para colegas escrotos e sem escrúpulos de quem se possa vir a precisar algum dia.
Nome Técnico: Capacidade de Persuasão
Significado: Manipulação de Otários
O que é: não importa o quão estúpida seja uma ideia, dependendo da convicção com a qual a defendemos, podemos convencer os otários a segui-las.
Nome Técnico: Liderança
Significado: Cenoura na frente do burro
O que é: ninguém faz nada sem receber algo em troca, e são vistos como líderes aqueles que ganham o apoio da massa ludibriando-a com promessas vazias.
O advento das soft skills trouxe a nós, goHorsers, um efeito colateral positivo: tem muito horse que quer crescer através do desenvolvimento desse tipo de competência, ignorando o fato de que as soft skills são usadas para justificar uma promoção DEPOIS que a mesma ocorre, e não antes. Isso gerou um vasto mercado a se explorar: cursos e treinamentos de comunicação, negociação, técnicas de apresentação e outras inutilidades.
Saturday, June 25, 2011
Go Horse (in memorian) - Atas de Reunião
Atas de reunião são instrumentos inúteis e estúpidos, artifícios dos quais os burocratas do PMI dependem para compensar a sua falta de pulso e a incapacidade da equipe.
Um dos argumentos utilizados por aqueles que defendem o uso de atas de reunião é a eliminação da ambiguidade, ou seja, a busca pelo comum entendimento. Tudo aquilo que fora discutido em reunião deve estar claro e acordado entre todas as partes.
Bullshit! Por que perder tempo editando documentos que apenas abrem brechas para que os horses fujam das suas responsabilidades? Atas de reunião são um erro em virtude das seguintes razões:
- Quem precisa de uma ata para que tudo fique claro é burro. Tem que entender tudo o que foi dito em reunião e fazer o maldito trabalho direito.
- Se algum peão quiser contestar algo, vale a palavra do chefe. Argumentos tais como “não foi isso que discutimos na reunião” podem ser facilmente rebatidos com frases de efeito como “cala a boca porque quem manda nessa porra sou eu”. Vale a palavra do chefe, e não uma ata idiota.
Atas são inúteis, o que vale é fazer o trabalho.
Um dos argumentos utilizados por aqueles que defendem o uso de atas de reunião é a eliminação da ambiguidade, ou seja, a busca pelo comum entendimento. Tudo aquilo que fora discutido em reunião deve estar claro e acordado entre todas as partes.
Bullshit! Por que perder tempo editando documentos que apenas abrem brechas para que os horses fujam das suas responsabilidades? Atas de reunião são um erro em virtude das seguintes razões:
- Quem precisa de uma ata para que tudo fique claro é burro. Tem que entender tudo o que foi dito em reunião e fazer o maldito trabalho direito.
- Se algum peão quiser contestar algo, vale a palavra do chefe. Argumentos tais como “não foi isso que discutimos na reunião” podem ser facilmente rebatidos com frases de efeito como “cala a boca porque quem manda nessa porra sou eu”. Vale a palavra do chefe, e não uma ata idiota.
Atas são inúteis, o que vale é fazer o trabalho.
Go Horse (in memorian) - Gestão da Qualidade
“Porra, será que eu tenho que fazer tudo por aqui?”
Quantas vezes o seu gerente, ou mesmo você nesse papel, falou essa frase? Isso é necessário quando a equipe não faz as coisas direito. Os malas do PMI são cheios de frescura quanto à qualidade: planejam, planejam, planejam…
Para o Go Horse, qualidade é simples: tem que fazer direito a porra do trabalho!
Quantas vezes o seu gerente, ou mesmo você nesse papel, falou essa frase? Isso é necessário quando a equipe não faz as coisas direito. Os malas do PMI são cheios de frescura quanto à qualidade: planejam, planejam, planejam…
Para o Go Horse, qualidade é simples: tem que fazer direito a porra do trabalho!
Go Horse (in memorian) - Gestão de RH
O processo burocrático do PMI para gestão dos recursos humanos vai desde criar uma matriz de responsabilidades para o projeto, passando pelo recrutamento de profissionais que preencham as vagas requeridas, até o treinamento dos membros da equipe para que estejam aptos a exercer as suas tarefas.
Tudo isso é muito bonito, mas só funciona na teoria, em um mundo de fantasias. Em Neverland, talvez.
O Go Horse não perde tempo com esse monte de bobagens, pois, ao contrário do PMI, parte das premissas corretas:
- As pessoas são podres: em uma estrutura matricial, gerentes funcionais não liberam os seus recursos mais valiosos para projetos que não digam respeito a (apenas) suas respectivas áreas. Isso porque a preocupação de gerentes funcionais é mostrar resultado aos seus superiores a fim de serem promovidos um dia.
- Diretores executivos não liberam verba a rodo para treinamento: isso impactaria no bônus anual recebido por eles, e comprometeria o valor das diárias das suas viagens de negócios a Las Vegas.
Para o recrutamento de pessoal para um projeto, o Go Horse prega a utilização de apenas uma ferramenta: o sponsor poderoso. O gerente de projetos deve ter costas quentes para que seja apoiado no processo de recrutamento.
Além disso, as posições devem ser preenchidas apenas de acordo com a disponibilidade das pessoas. Fazer um estudo das competências de cada profissional, como sugere o PMI, é pura perda de tempo – um tempo precioso que poderia estar sendo dedicado ao trabalho de verdade.
O PMI diz que a equipe do projeto deve ser desenvolvida e treinada. O Go Horse diz: BULLSHIT! Treinamentos são caros e demandam tempo. Tem que tocar o barco e ir fazendo o trabalho! Se um membro da equipe não possui o conhecimento necessário para a execução das tarefas que lhe serão atribuídas, ele que se vire para estudar e aprender. Como o horário de trabalho deve ser usado para trabalho de verdade, esse aprendizado deve ser realizado FORA do horário. Horas extras que nunca serão pagas, ou seja, a empresa não será onerada. O estado de terror em que o funcionário se encontra não apenas faz com que ele não cobre as horas extras com o auto-estudo, como o faz sentir-se culpado pela sua ignorância.
Está provado: Go Horse é muito mais rápido, efetivo e barato!
Tudo isso é muito bonito, mas só funciona na teoria, em um mundo de fantasias. Em Neverland, talvez.
O Go Horse não perde tempo com esse monte de bobagens, pois, ao contrário do PMI, parte das premissas corretas:
- As pessoas são podres: em uma estrutura matricial, gerentes funcionais não liberam os seus recursos mais valiosos para projetos que não digam respeito a (apenas) suas respectivas áreas. Isso porque a preocupação de gerentes funcionais é mostrar resultado aos seus superiores a fim de serem promovidos um dia.
- Diretores executivos não liberam verba a rodo para treinamento: isso impactaria no bônus anual recebido por eles, e comprometeria o valor das diárias das suas viagens de negócios a Las Vegas.
Para o recrutamento de pessoal para um projeto, o Go Horse prega a utilização de apenas uma ferramenta: o sponsor poderoso. O gerente de projetos deve ter costas quentes para que seja apoiado no processo de recrutamento.
Além disso, as posições devem ser preenchidas apenas de acordo com a disponibilidade das pessoas. Fazer um estudo das competências de cada profissional, como sugere o PMI, é pura perda de tempo – um tempo precioso que poderia estar sendo dedicado ao trabalho de verdade.
O PMI diz que a equipe do projeto deve ser desenvolvida e treinada. O Go Horse diz: BULLSHIT! Treinamentos são caros e demandam tempo. Tem que tocar o barco e ir fazendo o trabalho! Se um membro da equipe não possui o conhecimento necessário para a execução das tarefas que lhe serão atribuídas, ele que se vire para estudar e aprender. Como o horário de trabalho deve ser usado para trabalho de verdade, esse aprendizado deve ser realizado FORA do horário. Horas extras que nunca serão pagas, ou seja, a empresa não será onerada. O estado de terror em que o funcionário se encontra não apenas faz com que ele não cobre as horas extras com o auto-estudo, como o faz sentir-se culpado pela sua ignorância.
Está provado: Go Horse é muito mais rápido, efetivo e barato!
Go Horse (in memorian) - Gestão do Escopo
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 o escopo, 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.
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 o escopo, 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 (in memorian) - Gestão da Comunicação
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.
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 (in memorian) - Gestão dos Riscos
Tá com medinho?
Gerenciar riscos é para os covardes. Ou você acha que o Chuck Norris tem medo de assumir riscos? Winners assumem riscos, losers têm medinho deles.
Não precisa gerenciar os riscos, basta saber em quem pôr a culpa caso algo errado aconteça!
Gerenciar riscos é para os covardes. Ou você acha que o Chuck Norris tem medo de assumir riscos? Winners assumem riscos, losers têm medinho deles.
Não precisa gerenciar os riscos, basta saber em quem pôr a culpa caso algo errado aconteça!
Go Horse (in memorian) - Gestão das Aquisições
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!
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 (in memorian) - Gestão do Tempo
“Quando eu terminar”. Essa foi a resposta que Michelangelo deu ao Papa quando perguntado sobre quando ficaria pronta a pintura do teto da Capela Sistina. Sim, uma das maiores obras da humanidade foi realizada com a utilização do Go horse.
O PMI vem com esse papinho de estimar duração de tarefa. Mas como prever o futuro, não é mesmo? Ora, tem que ir fazendo a tarefa até que ela fique pronta.
No entanto, no papel de gerente, você deve impor um estado de terror em seus subordinados, perguntando constantemente quando a porra da tarefa será concluída. Como você sabe que futurologia não existe, e portanto o seu subordinado vai chutar uma data furada, é nele que você vai pôr a culpa pelo suposto “atraso”!
O PMI vem com esse papinho de estimar duração de tarefa. Mas como prever o futuro, não é mesmo? Ora, tem que ir fazendo a tarefa até que ela fique pronta.
No entanto, no papel de gerente, você deve impor um estado de terror em seus subordinados, perguntando constantemente quando a porra da tarefa será concluída. Como você sabe que futurologia não existe, e portanto o seu subordinado vai chutar uma data furada, é nele que você vai pôr a culpa pelo suposto “atraso”!
Go Horse (in memorian) - Ferramentas Inúteis da Administração – Diagrama de Ishikawa
Os burocratas do PMI e da Qualidade adoram desenhos, gráficos e várias outras inutilidades. Parece que eles sempre precisam de uma figura para entender um problema, e por isso perdem tempo fazendo gráficos ao invés de trabalhar de verdade.
Este post é o primeiro de uma série denominada “Ferramentas Inúteis da Administração”. Abordaremos as mais ridículas ferramentas de que os burocratas precisam para viver, começando pelo Diagrama de Ishikawa ou “Espinha de Peixe”, o qual é exibido na figura abaixo.
A ideia dessa ferramenta é auxiliar os burocratas na identificação das supostamente possíveis causas para um determinado problema. Primeiro, categorizam-se as mesmas para, em seguida, identificá-las. Uma vez que os fatores que podem vir a causar uma não-conformidade são encontrados, ações preventivas são tomadas.
Por que o Go Horse despreza tamanha bobagem?
Primeiro, pelo desperdício de tempo e dinheiro com reuniões inúteis para a identificação de causas que podem nem vir a ocorrer. Pior ainda: desperdício de tempo e dinheiro com ações preventivas. Para que gastar esforço com ações preventivas inúteis antes de o problema ocorrer? É muito mais prático ser reativo se o barco afundar.
Outro motivo pelo qual essa ferramenta não serve para nada é ilustrado abaixo. Para os burocratas do PMI entenderem, criamos um diagrama que ilustra a única possível causa de um problema.
Se o barco afundar, a culpa é do peão que fez o trabalho. É ele o responsável pela qualidade, é ele quem deve resolver o problema. Ao invés de propor que especialistas importantes para a empresa desperdicem tempo em reuniões inúteis de qualidade, o Go Horse prega uma maneira muito mais barata: jogar nas costas do horse a tarefa de resolver o problema após a sua ocorrência.
Certamente seu chefe já lhe disse algo como “quero que você resolva o problema, não importa como”, ou simplesmente “se fode, baixa a cabeça e faz essa merda”. Isso é o mais puro e eficiente Go Horse.
Viva o GHP, a única metodologia capaz de viabilizar o trabalho sem burocracia.
Go Horse (in memorian) - Gestão dos Custos
Os burocratas do PMI inventaram um monte de baboseiras para gerir o custo do projeto. O Go Horse, por outro lado, não perde tempo com asneiras como essas, pois se preocupa com o fundamental: fazer com que o projeto seja aprovado e suportado pela gerência.
Todos sabemos que as empresas não têm capital suficiente para realizar todos os projetos que gostaria. Cabe à gerência, portanto, escolher o projeto em que a empresa irá investir.
Projeto escolhido é projeto de visibilidade, o que traz prestígio. Qualquer gerente de projetos Go Horse que se preze busca prestígio incondicionalmente, e para isso deve estimar como custo total do projeto um valor que convença a gerência a escolher o seu projeto.
Ao longo da execução do projeto, é provável que o seu custo real ultrapasse o estimado. O Go Horse prega a filosofia de seguir trabalhando e pedir dinheiro à gerência à medida que for necessário. Para isso, a ótima metodologia GHP propõe as seguintes ferramentas para obter as verbas extras necessárias:
- Culpar a equipe por um suposto mau desempenho
- Culpar o cliente por sucessivas mudanças
- Enfatizar como o projeto é vital e não pode prescindir de aporte de verbas
- Citar a ocorrência de eventos imprevistos
Ao final do projeto, é provável que o custo final seja superior ao estimado. Mas não se perdeu tempo planejando custos e estimando riscos. Sucesso total, perda de tempo zero, prestígio ao gerente de projetos.
Todos sabemos que as empresas não têm capital suficiente para realizar todos os projetos que gostaria. Cabe à gerência, portanto, escolher o projeto em que a empresa irá investir.
Projeto escolhido é projeto de visibilidade, o que traz prestígio. Qualquer gerente de projetos Go Horse que se preze busca prestígio incondicionalmente, e para isso deve estimar como custo total do projeto um valor que convença a gerência a escolher o seu projeto.
Ao longo da execução do projeto, é provável que o seu custo real ultrapasse o estimado. O Go Horse prega a filosofia de seguir trabalhando e pedir dinheiro à gerência à medida que for necessário. Para isso, a ótima metodologia GHP propõe as seguintes ferramentas para obter as verbas extras necessárias:
- Culpar a equipe por um suposto mau desempenho
- Culpar o cliente por sucessivas mudanças
- Enfatizar como o projeto é vital e não pode prescindir de aporte de verbas
- Citar a ocorrência de eventos imprevistos
Ao final do projeto, é provável que o custo final seja superior ao estimado. Mas não se perdeu tempo planejando custos e estimando riscos. Sucesso total, perda de tempo zero, prestígio ao gerente de projetos.
Go Horse (in memorian) - eXtreme Go Horse (XGH)
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.
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 (in memorian) - FAQ
P: Qual a duração ideal de um ciclo de desenvolvimento usando go horse?
R: O ciclo inicia no começo, e se encerra quando o trabalho termina.
P: Na metodologia que eu uso atualmente, devo escrever documentação. Porém, sempre que há um problema ou duvida, o usuário me liga e pergunta como se faz. O GHP resolve isso?
R: Sim. Há uma extensa bibliografia sobre o assunto, mas o Go Horse recomenda a metodologia RTFM.
P: Quais as principais KPIs para a medição da performance do GHP? Por exemplo, KRPM (Krash Report Per Minute)?
R: KPIs são perda de tempo. Tem é que ir fazendo o trabalho.
P: Já foi considerada a aplicação de LEAN na metodologia GHP? Por exemplo, poderíamos eliminar o Horse, uma vez que não adiciona valor ao cliente?
R: O LEAN é derivado do Go Horse. Na verdade, trata-se da adição de um monte de bullshit ao Go Horse original, resultando em uma metodologia inútil.
Por fim, eliminar aquele simpático cavalinho do logo não é uma opção.
P: Como é feita a atualização de software usando GHP?
R: Atualizando.
P: Sou um gerente de projetos certificado pelo PMI. Por que devo abandonar as práticas propostas pelo PMBOK e adotar o Go Horse?
R: Por um motivo muito simples: em um projeto gerenciado com as práticas do PMI, quem leva a culpa se o projeto dá errado? O gerente. E quem leva os louros se dá certo? A equipe.
O Go Horse prega o não-planejamento, e se não há planejamento não há motivos pelos quais culpar o gerente. Com o Go Horse, tem-se a situação oposta: o gerente leva sozinho os louros da vitória, ao passo que a equipe leva a culpa se o projeto falhar. Não é perfeito?
P: Existe a possibilidade de desenvolver uma carreira promissora como um gerente de projetos Go Horse?
R: Sim! A maioria das organizações usa o Go Horse. Mas cuidado: para ser bem sucedido na carreira, não tente adotar Go Horse em uma organização que aplica o blá blá blá do PMI.
Veja este exemplo REAL: Um certo gerente de uma certa empresa encontrou alguns problemas durante um projeto. Para resolvê-los, aplicou todas as técnicas do Go Horse: Pediu mais verbas ao chefe quando o dinheiro acabou (em torno de 50%), mais prazo (11 meses), enrolou os superiores quanto ao escopo, e entregou o projeto. O que aconteceria com esse gerente em uma empresa dominada pelos malas do PMI? Seria demitido. No entanto, como o Go Horse era a prática adotada pela organização, esse gerente virou diretor!
P: Qual a metodologia mais eficiente? Go Horse ou PMBOK?
R: Ora, essa é fácil: Go Horse, claro! Mais da metade dos projetos gerenciados com as técnicas propostas pelos burocratas do PMI falham – isto porque o PMBOK diz que um projeto só é bem sucedido quando entregue dentro do prazo, cumprindo o escopo e respeitando as restrições orçamentárias.
O Go Horse, por outro lado, é contrário a esse monte de regras. Como a idéia é ir fazendo o projeto – tocar o barco – pedir dinheiro à medida em que é preciso e fazer o escopo que der na telha ao longo do projeto, nunca vai haver falha, já que não se perde tempo com planejamento. Ou seja, para o Go Horse, projeto de sucesso é projeto entregue! Não é fantástico?
P: Existe prova de certificação Go Horse?
R: Hein?
P: O PMI tem o seu código de ética. E o Go Horse?
R: O Go Horse também. Leia “As 48 leis do Poder”, de Robert Greene e Jost Elffers.
P: Como faço para descobrir se minha empresa usa Go Horse?
R: Se você não sabe qual a metodologia utilizada pela sua empresa, então com certeza ela usa Go Horse.
R: O ciclo inicia no começo, e se encerra quando o trabalho termina.
P: Na metodologia que eu uso atualmente, devo escrever documentação. Porém, sempre que há um problema ou duvida, o usuário me liga e pergunta como se faz. O GHP resolve isso?
R: Sim. Há uma extensa bibliografia sobre o assunto, mas o Go Horse recomenda a metodologia RTFM.
P: Quais as principais KPIs para a medição da performance do GHP? Por exemplo, KRPM (Krash Report Per Minute)?
R: KPIs são perda de tempo. Tem é que ir fazendo o trabalho.
P: Já foi considerada a aplicação de LEAN na metodologia GHP? Por exemplo, poderíamos eliminar o Horse, uma vez que não adiciona valor ao cliente?
R: O LEAN é derivado do Go Horse. Na verdade, trata-se da adição de um monte de bullshit ao Go Horse original, resultando em uma metodologia inútil.
Por fim, eliminar aquele simpático cavalinho do logo não é uma opção.
P: Como é feita a atualização de software usando GHP?
R: Atualizando.
P: Sou um gerente de projetos certificado pelo PMI. Por que devo abandonar as práticas propostas pelo PMBOK e adotar o Go Horse?
R: Por um motivo muito simples: em um projeto gerenciado com as práticas do PMI, quem leva a culpa se o projeto dá errado? O gerente. E quem leva os louros se dá certo? A equipe.
O Go Horse prega o não-planejamento, e se não há planejamento não há motivos pelos quais culpar o gerente. Com o Go Horse, tem-se a situação oposta: o gerente leva sozinho os louros da vitória, ao passo que a equipe leva a culpa se o projeto falhar. Não é perfeito?
P: Existe a possibilidade de desenvolver uma carreira promissora como um gerente de projetos Go Horse?
R: Sim! A maioria das organizações usa o Go Horse. Mas cuidado: para ser bem sucedido na carreira, não tente adotar Go Horse em uma organização que aplica o blá blá blá do PMI.
Veja este exemplo REAL: Um certo gerente de uma certa empresa encontrou alguns problemas durante um projeto. Para resolvê-los, aplicou todas as técnicas do Go Horse: Pediu mais verbas ao chefe quando o dinheiro acabou (em torno de 50%), mais prazo (11 meses), enrolou os superiores quanto ao escopo, e entregou o projeto. O que aconteceria com esse gerente em uma empresa dominada pelos malas do PMI? Seria demitido. No entanto, como o Go Horse era a prática adotada pela organização, esse gerente virou diretor!
P: Qual a metodologia mais eficiente? Go Horse ou PMBOK?
R: Ora, essa é fácil: Go Horse, claro! Mais da metade dos projetos gerenciados com as técnicas propostas pelos burocratas do PMI falham – isto porque o PMBOK diz que um projeto só é bem sucedido quando entregue dentro do prazo, cumprindo o escopo e respeitando as restrições orçamentárias.
O Go Horse, por outro lado, é contrário a esse monte de regras. Como a idéia é ir fazendo o projeto – tocar o barco – pedir dinheiro à medida em que é preciso e fazer o escopo que der na telha ao longo do projeto, nunca vai haver falha, já que não se perde tempo com planejamento. Ou seja, para o Go Horse, projeto de sucesso é projeto entregue! Não é fantástico?
P: Existe prova de certificação Go Horse?
R: Hein?
P: O PMI tem o seu código de ética. E o Go Horse?
R: O Go Horse também. Leia “As 48 leis do Poder”, de Robert Greene e Jost Elffers.
P: Como faço para descobrir se minha empresa usa Go Horse?
R: Se você não sabe qual a metodologia utilizada pela sua empresa, então com certeza ela usa Go Horse.
Qualidade Segundo o Go Horse
Fatos Sobre Qualidade
No mundo corporativo, a palavra qualidade é abreviada utilizando-se tão-somente a letra “Q”, e isto vale para os principais idiomas ocidentais. Em inglês, tal letra chama-se “kiú”. No alemão, espanhol e italiano, lê-se “ku”. Seria este carinhoso apelido mera coincidência?
Qualidade é, resumidamente, um baixo número de eventos de não-conformidade. Produtos ou serviços que não seguem suas respectivas especificações têm baixa qualidade. Qualidade é diferente de “grau”: tanto um Gol quanto uma Ferrari podem possuir o mesmo nível de qualidade.
Garantia e Controle de Qualidade
Peço desculpas aos conhecedores do tema, mas devo expor aqui dois conceitos básicos fundamentais para que todos possam compreender este texto: garantia de qualidade e controle de qualidade.
- Garantia de qualidade: é o processo de “melhoria contínua”. Se é processo, nunca termina. Empresas mantêm equipes dedicadas à otimização de processos que visam reduzir o número de produtos que apresentam não-conformidade.
- Controle de qualidade: é a implementação dos processos definidos pela garantia da qualidade. O controle de qualidade é aplicado diretamente ao produto ou serviço desenvolvido.
Qualidade: Go Horse vs. Burocratas
Os burocratas do PMI e de outras metodologias furadas gastam fortunas com qualidade, pois empresas que utilizam tais metodologias adotam como valor o tal “foco no cliente”. Isto é o estado-da-arte do bullshit e da estupidez, uma grande imbecilidade: o correto é focar na grana, nos acionistas, nos diretores e seus respectivos compadres e afilhados. Para isso servem as empresas. Funcionários devem ser constantemente chicoteados a fim de manter o crescente enriquecimento da casta mais alta – o resto é conversa furada.
Comparemos as abordagens do Go Horse e do PMI para um mesmo projeto fictício. A estimativa PMI de custos é mais alta, e uma das razões disso é a necessidade de embutir, no custo do projeto, o dispendioso processo de controle de qualidade. No gráfico abaixo, vemos isso claramente:
Em amarelo, o custo do controle de qualidade
Podemos observar que o Go Horse também requer gasto com controle de qualidade, porém um gasto infinitamente menor. Como isso é possível? Mágica? Não: com Go Horse simplesmente não há equipe de controle de qualidade. Os próprios membros do time de projeto devem ser responsáveis pela qualidade. Além de ser uma abordagem muito mais barata, atribuir a responsabilidade pela qualidade sobre os ombros da equipe do projeto facilita a identificação de culpados caso algo dê errado.
Paralelamente aos custos do projeto, a turma do PMI arca com o custo da garantia de qualidade: um custo que tende ao infinito! O Go Horse não admite tal baboseira, o que torna a diferença de custos entre as duas escolas ainda mais discrepante, conforme podemos observar na figura abaixo:
Em laranja, o custo da garantia de qualidade
Ao analisar o gráfico acima, os burocratas do PMI se regozijam, atingem o êxtase. Eles bradam que, uma vez que Go Horse não possui um processo formal de controle de qualidade, o número de defeitos será infinitamente maior, fazendo com que a empresa sofra as consequências que isso implica. Mas eles estão totalmente enganados, pois com Go Horse existe sim controle de qualidade. A diferença é que ele é feito pelo próprio cliente!
Ao receber o produto ou serviço, o cliente inicia o processo de validação. Ele inevitavelmente encontra erros, defeitos, não-conformidades, e os reporta. O time de projeto Go Horse os resolve. Isso teria de ser feito de qualquer maneira, mas o ônus de testar a entrega é do cliente!
A conclusão disso tudo é que o sucesso só pode ser atingido com Go Horse: com uma cotação mais baixa, ganhamos a conta do cliente, que paga pelo controle de qualidade assim como o faria em um projeto PMI.
Lembre-se, burocrata do PMI: o importante é ganhar a conta!
Em um dia desses encontrei um velho amigo e colega de Gerência de Projetos, cuja identidade não revelarei. Apesar de ser um grande amigo, tenho uma certa restrição quanto a este profissional: ele é um burocrata do PMI. Tomamos um café e trocamos algumas idéias sobre Gerenciamento de Projetos.
Ele me relatava a sua experiência com a utilização das tais “melhores práticas” – dizia como sua gestão era efetiva e como minimizava os custos do projeto através da aplicação do PMBOK. Obviamente eu não comprei aquele monte de baboseiras que ele dizia, e tentei argumentar – em vão – que o Go Horse é mais efetivo não apenas na redução dos custos do projeto, mas como um todo.
Ele me dizia: “Projetos Go Horse geram retrabalho, ou seja, custos imprevistos”. Dizia também: “só acredito se você me mostrar um estudo de caso”. É incrível a obsessão que esse pessoal do PMI tem por papéis, documentos e formalidades.
Tomemos um projeto qualquer como exemplo. Para a estimativa de custos, os burocratas do PMI planejam, planejam, planejam… o Go Horse, ao contrário, faz uma estimativa de custos imediata – leia o estudo Go Horse sobre Gestão de Custos.
A estimativa de custos Go Horse, via de regra, é 20% mais baixa do que uma estimativa PMI. Isso porque, no caso do PMBOK, todo o custo do overhead de planejamento está embutido no custo do projeto – incluindo a burocrática e penosa análise de riscos.
Imagine se as duas estimativas acima competem por uma conta de cliente. Obviamente o fornecedor Go Horse vence, pois ele não perdeu tempo planejando e, consequentemente, não aumentou o custo do projeto por causa disso.
Quando o projeto chega próximo ao seu final, olhamos para trás e percebemos que as coisas não saíram conforme o planejado.
Elas nunca saem, e justamente por isso o Go Horse despreza o planejamento. No caso de um projeto gerenciado com as técnicas burocráticas do PMI, o estouro de orçamento tende a ser menor do que o Go Horse: de 5 a 10%.
Com Go Horse, o estouro de orçamento é bem maior, como podemos observar na figura abaixo. Esse fato leva os malas do PMI ao êxtase. Eles dizem: “Viram como tínhamos razão? Estouraram o orçamento! Expliquem ao cliente agora!”
A questão é que, como disse o meu nobre colega burocrata do PMI, Go Horse gera retrabalho. Em síntese, todo o custo extra que vemos na figura acima é retrabalho. Agora jogamos um balde de água fria nos chatos do PMI. Dizemos a eles: “Leiam o que o Go Horse diz sobre a Gestão do Escopo!”.
Não permitimos que a equipe estoure o prazo – ao contrário, a submetemos a um estado permanente de terror, forçando-a a realizar horas extras. Ou seja, todo o retrabalho que gerou o custo extra representado na figura acima foi realizado através de horas extras.
Agora eu pergunto:
- A sua empresa paga horas extras?
- Existe alguma empresa que pague horas extras de projeto?
- Algum funcionário aceita servir de mártir, sacrificar sua carreira e chances no mercado, apenas para processar a empresa?
Nenhuma empresa esperta paga horas extras. Em um projeto Go Horse, o custo do retrabalho some como mágica!
Está provado: com Go Horse é mais barato!
Ele me relatava a sua experiência com a utilização das tais “melhores práticas” – dizia como sua gestão era efetiva e como minimizava os custos do projeto através da aplicação do PMBOK. Obviamente eu não comprei aquele monte de baboseiras que ele dizia, e tentei argumentar – em vão – que o Go Horse é mais efetivo não apenas na redução dos custos do projeto, mas como um todo.
Ele me dizia: “Projetos Go Horse geram retrabalho, ou seja, custos imprevistos”. Dizia também: “só acredito se você me mostrar um estudo de caso”. É incrível a obsessão que esse pessoal do PMI tem por papéis, documentos e formalidades.
Tomemos um projeto qualquer como exemplo. Para a estimativa de custos, os burocratas do PMI planejam, planejam, planejam… o Go Horse, ao contrário, faz uma estimativa de custos imediata – leia o estudo Go Horse sobre Gestão de Custos.
A estimativa de custos Go Horse, via de regra, é 20% mais baixa do que uma estimativa PMI. Isso porque, no caso do PMBOK, todo o custo do overhead de planejamento está embutido no custo do projeto – incluindo a burocrática e penosa análise de riscos.
Estimativa Go Horse vs. estimativa PMI
Quando o projeto chega próximo ao seu final, olhamos para trás e percebemos que as coisas não saíram conforme o planejado.
Elas nunca saem, e justamente por isso o Go Horse despreza o planejamento. No caso de um projeto gerenciado com as técnicas burocráticas do PMI, o estouro de orçamento tende a ser menor do que o Go Horse: de 5 a 10%.
Estouro de orçamento PMI
Estouro de orçamento Go Horse
Não permitimos que a equipe estoure o prazo – ao contrário, a submetemos a um estado permanente de terror, forçando-a a realizar horas extras. Ou seja, todo o retrabalho que gerou o custo extra representado na figura acima foi realizado através de horas extras.
Agora eu pergunto:
- A sua empresa paga horas extras?
- Existe alguma empresa que pague horas extras de projeto?
- Algum funcionário aceita servir de mártir, sacrificar sua carreira e chances no mercado, apenas para processar a empresa?
Nenhuma empresa esperta paga horas extras. Em um projeto Go Horse, o custo do retrabalho some como mágica!
Horas extras nunca são pagas!
Subscribe to:
Posts (Atom)