Seja Ágil com Scrum (Parte 2) – Ainda no eXtreme Go Horse ?

Em Gestão Ágil por Jonathan Maia

Após a disponibilização do material completo do curso Seja Ágil com Scrum, nesta segunda postagem sobre o assunto, falaremos um pouco sobre gerenciamento de projetos.

Sejamos sinceros: quem nunca iniciou a execução de atividades pessoais ou mesmo projetos profissionais de uma maneira totalmente desordenada, sem nenhum tipo de planejamento ou gerenciamento, que atire a primeira pedra! Muitos de nós já executamos o famoso XGH – eXtreme Go Horse (em tradução literal, Vai Cavalo Extremo), muito bem definido através do Go Horse Process.

Você já deve ter visto esta cena em um filme: o que acontece quando alguém dá um tapinha em um cavalo ? Sai em disparada, como louco, sem rumo definido. Por incrível que pareça, em alguns momentos, mais parecemos cavalos descontrolados que humanos racionais.

Seguem alguns dos princípios definidos no Go Horse Process:

  • Pensou, não é XGH;
  • Existem 3 formas de resolver um problema: a correta, a errada e a XGH, que é igual à errada, só que mais rápida;
  • XGH é totalmente reativo;
  • XGH não tem prazo;
  • Quanto mais XGH você faz, mais precisará fazer;
  • Até surgir um pouco de ordem, XGH não é perigoso.

Identifica algum dos princípios em algo que já executou ? Já fez a famosa gambiarra ? Nunca viu em um projeto um daqueles XGHs de grande porte, quase manga um larga ? Por que o XGH é tão difundido ?

Curso Introdução à produção de Games
A zona de conforto é um lugar maravilhoso ... Pena que nada cresce lá!

Zona de conforto – Créditos: Jonathan Maia (Alpes Austríacos)

Por duas vezes tive a oportunidade de ver neve em minha vida. É incrível como as únicas formas de vida observáveis são os seres humanos. Sem vegetações, sem animais, cenários lindos, mas mortos! E é exatamente o que acontece quando estamos em nossa zona de conforto. Não há crescimento, não há melhoria, embora tudo esteja, aparentemente, lindo.

O XGH é amplamente utilizado pois é cômodo: custa menos (a primeira vista), é mais rápido (com menos qualidade), demanda menos esforço de aprendizado e análise. Em 935 a.c., o famoso rei Salomão, conhecido por sua admirável sabedoria , já dizia:

“Se o machado está cego e sua lâmina não foi afiada, é preciso golpear com mais força; agir com sabedoria assegura o sucesso” Ec 10:10

De acordo com o Guia PMBOK©, organizado pelo instituto PMI©e principal base de conhecimentos sobre gestão de projetos, temos que:

“Gerenciamento de projetos é a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do projeto para atender aos seus requisitos”

Algumas das motivações para utilizarmos gerenciamento de projetos são:

  • Obter o compromisso das partes interessadas (stakeholders);
  • Ter comunicações eficientes;
  • Obter recursos necessários;
  • Alcançar resultados almejados;
  • Trazer satisfação às partes interessadas;

O Guia PMBOK©, em sua quinta edição, possui 47 processos de gerenciamento de projetos, organizados em grupos de processos e áreas de conhecimento. Embora não seja o escopo desta postagem, as figuras a seguir exibem os grupos de processos e as áreas de conhecimento do PMBOK©.

Grupos de processo do PMBOK©

Grupos de processo do PMBOK©

Áreas de Conhecimento do PMBOK©

Áreas de Conhecimento do PMBOK©

Ok, cara pálida, quer dizer que agora, com o Guia PMBOK©, podemos sair do XGH e ter sucesso em todos projetos pois estaremos gerenciando-os adequadamente através dos 47 processos? Mais uma vez, recorreremos à sabedoria de nossos antepassados. No século XVIII, o rei Frederico II da Prússia, conhecido por suas vitórias militares, disse:

“Aquele que tudo defende, nada defende”

O gerenciamento de projetos baseado no Guia PMBOK©, costumeiramente chamado de gerenciamento tradicional de projetos, possui algumas características (C) enraizadas que também trazem problemas (P) aos projetos. Seguem algumas delas.

Característica: Planos e cronograma são detalhados no início do projeto através de documentos, gráficos e diagramas
Problema: Quantos diagramas de Gantt elaborados no início do projeto e corretos você já viu ?
Problema: Pessoas são contratadas apenas para elaborar ou atualizar artefatos de gerenciamento;
Problema: Há frustração porque planos antecipados, rotineiramente, não se concretizam;
Problema: Artefatos enormes que não serão lidos por ninguém são produzidos (sem significado);
Problema: Por vezes, artefatos tornam-se mais importantes que produtos.

Característica: Especificação detalhada e antecipada dos requisitos. BRUF (Big Requirements Up Front)
Problema: É muito difícil detalhar requisitos adequadamente no início dos projetos;
Problema: Em geral, como o cliente só pode pedir uma vez, no início do projeto, pede mais requisitos que os necessários (custos excessivos para clientes).

Característica: Mudanças durante o projeto são caras
Problema: Embora o PMBoK possua o processo “Controle Integrado de Mudanças” e aceite mudanças durante a execução, mudanças em projetos com planejamento prévio excessivo são mais caras;

Antes de prosseguir, gostaria de fazer um esclarecimento. Em minha humilde opinião, o gerenciamento tradicional de projetos e o Guia do PMBOK© continuam sendo fontes de conhecimentos riquíssimas. Fiz
um curso de contratações de TI com um auditor do TCU e uma frase que ficou gravada em minha memória foi:

“Quanto maiores os riscos, maiores deverão ser os controles”

Controle de riscos

Controle de riscos

Mesmo em projetos ágeis, o Guia PMBOK© pode atuar como uma fonte de conhecimentos e técnicas a serem aplicados de acordo com os riscos envolvidos (ele é um guia, não uma metodologia). Não acredita ? Olhe o que o Guia Scrum diz em sua conclusão:

“Scrum existe somente na sua totalidade, funcionando bem como um container para outras técnicas, metodologias e práticas

Como isso dito, o grande entrave é que o gerenciamento tradicional é naturalmente “pesado” e os problemas decorrentes de sua utilização são realmente impactantes. Assim, saímos do nada, carinhosamente chamado de Go Horse, e partimos para o muito, chamado de gerenciamento tradicional.

Não seria interessante uma abordagem intermediária ? Nem tanto, nem tão pouco ? É nesse cenário onde o gerenciamento ágil de projetos nasce, com o propósito maior de sanar alguns dos problemas do gerenciamento tradicional, mantendo os benefícios do gerenciamento de projetos.

Acesse as próximas postagens:
História da Agilidade e do Scrum – Seja Ágil com Scrum – Parte 3

 Por favor, curta e compartilhe nossas páginas nas redes sociais para ajudar a manter o Blog.

Um forte abraço e até mais.

That’s all!

Olá, sou Jonathan Maia, marido, pai, apaixonado por tecnologia, gestão e produtividade. Atuo na gestão e desenvolvimento de sistemas de informação como analista de TI do TRT Ceará (servidor público federal).

Possuo as certificações em gerenciamento de projetos Project Management Professional (PMP) e Professional Scrum Master I (PSM I), além de especialização em gerenciamento de projetos de TI (2011) e bacharelado em ciências da computação pela UFC (2008). Também sou desenvolvedor Full Stack e possuo experiência em diversas arquiteturas / plataformas.

Fui aprovado e nomeado nos concursos públicos do TJ-CE, Dataprev, Serpro e TRT Ceará, assumindo nos três últimos. Já tive experiências profissionais em redes metropolitanas de alta velocidade (GigaFOR/RNP), business intelligence, desenvolvimento de sistemas e gestão de projetos (tradicionais e ágeis).

Como adepto da gestão ágil, desenvolvi o Organizador Ágil, um método ágil, simples e leve que auxilia no aumento da produtividade e organização pessoal, familiar ou profissional. Também mantenho o Blog Eu na TI.

Deixe uma resposta