Quem ler esse título vai achar que eu enlouquecí depois do “O que matou o RUP pode matar o Agile“, mas o objetivo desse post é mais uma vez falar sobre mindset. Eu vejo que a grande dificuldade em entender práticas e metodologias vem de conflitos de mindset. Vou escrever mais sobre isso aqui no blog, pois vejo que combater prática contra prática ou metodologia contra metodologia é muito pouco produtivo. Os mindsets explicam tudo, apesar de ser bastante empírico escrever sobre isso. É dificil escrever sobre mind-set de maneira prática e útil sem descambar para um blá-blá-blá poético e filosófico.
Nesse artigo vou comentar sobre a polêmica que o José Papo criou primeiramente no seu Twitter. Não satisfeito postou também na Scrum-Brasil. Segue o link para a animada discussão “Scrum e PMBOK – determinadas incompatibilidades filosóficas”:
http://br.groups.yahoo.com/group/scrum-brasil/message/4810
A discussão estava indo como sempre vai: uns defendendo, outros criticando, até que passou pela questão “certificação”. Hoje existem muitos PMPs que também são CSM, e vejo que isso é bem natural – quem tem um mindset que busca certificações é esperado que colecione-as. O Luiz Aguiar postou algo interessante, falando que agilistas de verdade não ligam para certificações. Isso é interessante para esse artigo, pois, vou falar aqui que muitos que gerenciam projetos de verdade a lá PMBOK também não ligam…
No ano de 2008 eu decidí investir através da Aspercom numa parceria para fazer um produto: um software para gestão de projetos de engenharia focado em DPC (design-procurement-construction). O projeto envolvia a área de engenharia, compras, financeiro, gestão de projetos e canteiro de obras. Para os desenvolvedores de plantão nós usamos Java, Seam, JBpm, Domain-Driven Design, Scrum e XP.
A Aspercom tenta ao máximo seguir o Manifesto Ágil que diz: “We are uncovering better ways of developing software by doing it and helping others do it.” Me é estranho uma empresa que treina em Agile não se envolver em projetos. Por isso tivemos aqui a experiência do projeto DDWorks e do RailsRumble. Esse projeto de 2008 foi um outro exemplo com muito aprendizado.
Nosso cliente inicial neste projeto era uma grande empresa de engenharia especializada em fornos de siderurgia (aqueles fornos que custam milhões de dólares). O pouco de contato que tive com esses engenheiros stakeholders me mostrou uma visão completamente diferente do PMBOK que é tão mal aplicado na nossa área de TI. Só para começar, meu primeiro choque é que um projeto de um forno de siderúrgia é um investimento que pode chegar fácil a 100 milhões de dólares, então, não se trata desses nossos projetinhos de software que raramente ultrapassam 6 dígitos.
Só para passar a magnitude das coisas, um projeto de engenharia de um forno tem fases e muitas vezes ocorre um overlap. Não é um projeto em cascata. Basicamente o design é fazer desenhos, plantas e mapas, mas não só isso: o engenheiro deve fazer uma lista de material contendo tudo que é necessário para montar o forno. Esse trabalho pode envolver até uns 30 engenheiros num único projeto. Há desenhos topográficos, esquemáticos, detalhes e etc… O cliente também tem uma equipe de engenheiros própria que verificará a conformidade do projeto as suas instalações. Talvez essa parte do projeto seja algo parecido com desenvolvimento de software – é algo criativo e requer profundos conhecimentos técnicos. Quando expliquei o Scrum para o cliente ele até cogitou usá-lo para essa fase de engenharia. Mas as semelhanças param por aí…
Com as listas de materiais elaboradas e aprovadas o próximo passo é comprar (procurement). Para isso, é necessário negociar, importar, ter certificados de capacidade de fornecedores, pensar em logística, prazos e muito mais. Você vai precisar de algumas dezenas de compradores para gerenciar equipes de fornecedores, pensar em lead-times, lidar com importadoras, engolir as maracutaias no porto de Santos e mais uma dezena de coisas que pode dar errado: desde uma espessura de tubo inconforme de uma empresa de Jundiaí até motores falsificados que estão vindo da China. Associado a todo processo de compra existem métodos de inspeção para garantir que contratos sejam cumpridos nos rigores da qualidade exigida pelo projeto, que se mal feito pessoas podem até morrer.
Com o material chegando no canteiro de obras é necessário gerenciar almoxarifados e organizar equipes de montagem e de ensaios (testes). Nesse ponto crucial do projeto, além de lidar com possíveis problemas entre pessoas, falhas de planejamento e falta de materiais críticos (uma abracadeira de 15 dólares pode gerar um atraso de muitos dias e milhares de dólares) um gerente de projetos ainda tem lidar com problemas como a chuva e orgãos ambientais e governamentais.
Nesses últimos 3 parágrafos acho que escreví menos de 10% dos problemas que um projeto DPC (design-procurement-construction) tem. Ainda faltaria falar mais centenas de outros problemas como a taxa do dólar, o preço do aço no mercado internacional, a burocracia brasileira, o roubo de peças do almoxarifado, as falhas de comunicação e muitos outros. Estamos falando de um projeto de milhões de dólares que pode envolver 7 regiões do globo, mais de 80 empresas e seguramente mais de 1.000 pessoas (consegue imaginar uma daily metting?).
Eu sempre critiquei muito o PMBOK em muitas ocasiões, mas o problema era o mind-set. Eu digo aqui em alto e bom som que para um projeto de engenharia como esses a melhor ferramenta é o PMBOK sem sombra de dúvidas. Nesse tipo de projeto controle de terceiros, WBS, plano de comunicação, gerencia de riscos e muito do que não faz sentido para software faz todo sentido. O cara que gerencia tudo isso tem que ser bom e faz sentido ter uma pessoa como foco central no projeto. Nesse ambiente o mindset PMBOK faz sentido. O tempo que estive inserido nesse mundo um gerente de projetos muito bom em DPC chegava a ganhar mais de 20 mil reais fácil-fácil. Esses são os caras que estão gerenciando construção de oleodutos, plataformas de petróleo, linhas de produção contínuas de aço e muitos outros desafios emocionantes. Eu vejo a aplicabilidade do Scrum como nula neste tipo de projeto e quero cases que me provem o contrário.
Voltando ao assunto do Luiz Aguiar, o que achei bastante interessante é que gerentes de projeto muito bons em DPC não eram PMPs, não davam palestras por aí, não tinham certificações nas assinaturas de email, mas sabiam MUITO BEM o PMBOK, pois viviam suas práticas todos os dias. Eles gerenciavam milhões a bilhões de reais e tinham uma grande responsabilidade. Esse é um ambiente onde só se consegue gerenciar com muito conhecimento e acúmulo de experiência. Isso certificação nenhuma dá.
Eu concordo que o mindset da gestão em projetos de software é bem diferente dessa realidade e não dá para misturar as duas coisas.A gestão de projetos de software é simples. Muito mais simples. Simples ao ponto de se questionar a necessidade de um GP para equipes sêniores. O PMBOK, como conjunto de conhecimentos para gestão de projetos é um “super-set” grande demais para projetos de software, o que pode confundir muito, mas pode ser dimuído (ele sofre o mesmo que o RUP). Apesar de se tratar de mindsets diferentes é impossível negar que as práticas são semelhantes. No nosso treinamento Scrum eu simplesmente não consigo deixar de citar que há semelhanças e diferenças marcantes, mas as semelhanças estão lá. O Scrum roda dentro de um ciclo PDCA, é a equipe que estima, existe controle de escopo e prazo. Tudo está lá, mas um pouco diferente do PMBOK.
PMBOK serve para software? Digo para vocês que se eu estiver num projeto onde equipes apartadas ou fornecedores estão desenvolvendo partes completamente diferentes do projeto – como acontece num projeto de equipamentos que envolve construção de hardware e software específicos (um projeto incomum) – é bem provável que eu irá usar muitas práticas do PMBOK.
Eu concordo com o Uncle Bob quando ele fala que se você deixar programadores sozinhos lidando com os problemas do desenvolvimento e manutenção de software naturalmente eles vão começar a buscar práticas do Extreme Programming. Eu arrisco dizer aqui que bons (e espertos) gerentes de projeto PMBOK lidando com problemas de gestão no desenvolvimento de software também naturalmente se apegariam as práticas do Scrum.
O que não é admissível na minha opinião é poluir a gestão de um projeto usando inadvertidamente práticas PMBOK by the Book, o que infelizmente é comum no mind-set de gerentes de projeto megalomaníacos. Por isso muitas vezes a comunidade ágil tem asco do PMI. Como sempre, a culpa não é do PMBOK, mas do mindset poluído.
Você já gerenciou projetos multi-sites, multi-equipes, multi-fornecedores e multi-milionários? Não? Então pode voltar para o seu Scrum.
Boa! eu nunca fui contra o PMBOK.. na verdade eu reconheco o seu valor, o problema é mesmo a forma das pessoas aplicarem as metodologias! Pegam um livro.. uma pratica aprende e quer aplicar como regra numero 1 sem nem saber se faz sentido ou não para o seu objetivo final!!
Pô, tinha que pisar na última linha?! Milhonário nem eu quero ser! =)
Cara, excelente! É isso aí! Só acho que é simples demais para tanta gente insistir em não entender. Devemos estar errados! =)
Abraço!
Rodrigo,
Concordo plenamente com o que você disse. O problema como sempre está nas pessoas que sempre procuram uma solução única pra tudo. Acham que SCRUM serve pra tudo assim como tem os que acham que PMBOK serve pra tudo e por ai vai. Mais uma vez precisamos ver a ferramenta certa para o problema, seja ela qual for.
Abraços,
Emerson
A culpa é do mind-set de quem aplica a brincadeira. Assim como ocorre no Unified Process e é assim também com Metodologias Ágeis.
Um amigo PMP já há longa data comenta que hoje ser PMP não indica experiência e qualidade na gestão de projetos, como alias é com qualquer outra certificação. Mesmo no caso da certificação de PMP onde a pessoa precisa apresentar horas de experiência na gestão de projetos, nada é garantido.
Eu fiz um workshop recentemente para gerentes de projeto ou pessoas envolvidas com atividade de gestão, apresentando as Metodologias Ágeis.
Na parte final do workshop fiquei falando como as áreas de conhecimento do PMBOK aparecem dentro das Metodologias Ágeis, e elas aparecem mesmo!
Agora, é tudo uma questão de como você aplica. Você pode criar um monstro por exemplo, para mostrar como a área de conhecimento de qualidade pode ser mapeada em um projeto. Ou pode usar o que usamos para garantir a qualidade de um software usando extreme programming e pronto!
Parabéns pelo artigo! Excelente!
Abs,
Dimtiri
Sensacional artigo, concordo plenamente com você quanto ao uso do PMBoK.
Trabalho com TI e projetos WEB há 10 anos e no final desse ano finalizo minha pós em gestão de projetos com ênfase no PMBoK, e lá com certeza essa é a visão, PMBoK é pra projetos GIGANTES.
Nosso dia-a-dia não necessita de tantos processos, nosso dia-a-dia necessita muito e muito de COMUNICAÇÃO.
Abraço
Bom como sempre. Mas desculpe a impertinência pois tenho uma restrição: porque tanto mind set pra cá, mind set pra lá? Tipo do termo que tem tradução clara em português e não precisa ser usado em inglês. #prontoFalei
Eu também não gosto de extrangeirismos, mas as alternativas que temos são:
mentalidade, hábitos mentais, atividades mentais, atitude mental
Eu optei em usar esse extrangeirismo para realmente chamar a atenção e nomear um conceito. Se eu usar atitude mental, que seria a melhor tradução, o conceito perderia força. Infelizmente aqui no Brasil um conceito com nome em inglês é mais forte.
(eu sei que nem todo mundo vai concordar comigo)
Para quem não é da área fica difícil ler um artigo com tantas expressões técnicas de uso exclusivo, sem um glossário que as traduza para o leitor comum. A menos que tal artigo seja para ficar restrito, sem a intenção de abrangência a outras áreas. Li o artigo só para medir o quanto estou defasado da linguagem usada em TI. Desconfiei que o assunto me interessava, mas passei voando alto sem ter certeza do que se tratava. Contudo, percebi muita coisa interessante na área de projetos e seus gerenciamentos. Mas vejam o trecho: “Hoje existem muitos PMPs que também são CSM, e vejo que isso é bem natural – quem tem um mindset que busca certificações é esperado que colecione-as”. Claro que é mais fácil escrever um artigo para quem é da área, mas não seria muito melhor escrever para ampliar o interesse de mais leitores? Graças ao comentário de Luca Bastos sobre mindset pude entender melhor o artigo todo.
Ah, em tempo, sou de outra geração etária e minha área é a Psicologia. Descobri que tem a ver com “mindset”.
Me incomoda um pouco essa questão de mind-set também. Mas não especificamente com o Yoshima, e sim com o mercado que implanta essa terminologia goela abaixo sem tanta necessidade. Uma tradução que gosto de utilizar para mindset é “pensamento vigente”. Como a filosofia que é adotada para aquele momento, naquela situação.
Nivaldo, o artigo é para gestão de projetos de TI. Este blog é só para profissionais da área. Obrigado pelo comentário.
Sugestão:
mindset = modelo mental (a lá Senge).
Rodrigo, parabéns pelo texto foi muito elucidativo. Estou prestes a gerenciar um projeto baseado nas metodologias Ágeis (neste caso Scrum) e por ser PMP estava entrando em conflito algumas coisas que estava tomando o conhecimento. Você concluiu muito bem o texto ficando a seguinte mensagem: Nós Gerentes de Projetos temos que ter a visão de qual metodologia iremos adotar para a gestão de nossos projetos, pois com certeza isto será fator de sucesso ou fracasso.
Ola
Pensando no que vc diz a respeito do Scrum aplicado a um projeto desse porte, percebo que existe, em tese, um espaço diferente de possibilidades do que quando comparado a um projeto de software. Os métodos empiricos de estimativa, por exemplo, são mais condizentes com um grande sistema, que leva dezenas ou centenas de desenvolvedores, do que com um projeto complexo, que envolve N areas e equipes distribuidas porém com foco e metodo muito bem definidos. Pensando assim Scrum parece ineficiente mesmo.
Todavia, vejo nas metodologias ageis uma forma de diminuir o ruido entre o que o cliente quer e o que cada integrante do time entendeu que é para fazer, sem falar que uma parte do software que existe por ai evoluir de uma forma que nem sempre é possivel prever, ainda mais com releases curtos e entregas constantes onde o uso do sistema induz a necessidade por outras features, por exemplo. Acho que existem projetos dessa natureza fora do mundo do software mas com escala de tempo diferente. Talvez projetar uma nova pistola semi-automatica possa ser feita com Scrum (o que é mais importante: controlar o coice ou mira laser?), mas uma usina nuclear não.
Rodrigo, parabéns pelo Blog, leio sempre que possível…
Matou a pau Everton, penso igualzinho…
“Boa! eu nunca fui contra o PMBOK.. na verdade eu reconheco o seu valor, o problema é mesmo a forma das pessoas aplicarem as metodologias! Pegam um livro.. uma pratica aprende e quer aplicar como regra numero 1 sem nem saber se faz sentido ou não para o seu objetivo final!!”
Prezadissimo Rodrigo,
Havia guardado tua URL em meus favoritos por mera casualidade (EAD, certificações e tal). Quando fui limpar, resolvi dar mais uma olhada, e caí nesse artigo. Rapaz, que lavada! Meus parabéns!
Sou engenheiro por formação, mas trabalho com TI. Tive oportunidade de gerenciar projetos de automação industrial em petroquímica, onde utilizei, sem saber, e precisava mesmo, tudo e mais alguma coisa do PMBOK. Já gerenciei também projetos de desenvolvimento em TI, menores, como você mencionou. Só que não sou certificado! Aí pega, porque tudo quanto é site de recrutamento só mostra vagas com essa demanda, e como eu, alem de “muito velho” (tenho 58 anos, mas me sinto com 30), não tenho certificação …. danço! Minha experiência pouco vale, como tenho notado, parece que vale mais a certificação! É a forma em detrimento do conteúdo. Tempos bicudos esses!
Aproveitando a oportunidade, quero sugerir o que me pareceu a melhor tradução para “mindset”: paradigma. Palavrinha usada com cuidado, e só em certos círculos principalmente acadêmicos de discussão, mas é exatamente ela!
Eu achei legal a sua colocação. Eu vivo muito isso. Pego projetos em situações diferentes. Muitos deles em crises e preciso agregar outras práticas para guiar as entregas!
Concordo, também, com a sua colocação do autor. Acrescento que o PMbok tem um pequeno parágrafo que diz que nem todas as “práticas” divulgadas no Pmbok devem ser aplicadas em todos os projetos. O que acontece é que muitos PMP´s e mesmo Escritórios internos de projetos começam a criar suas “metodologias” dentro da empresa que de uma certa forma engessam e/ou burocratizam. Este fato dificultou/a a aceitabilidade das “melhores práticas” por parte dos verdadeiros gerentes que na sua grande maioria, não são PMP´s. Li pouco sobre o SCRUM mas veja grandes relações diretas com as melhores práticas do PMBOK e acredito que antes de criarmos uma “metodologia” interna devemos verificar qual a metodologia “reinante”. Gradativamente incorporamos algumas das práticas onde acharmos que são necessárias de forma a melhorar nossos ativos de processos.
Com relação ao mercado acredito que está cada vez mais exigente e não temos modificá-lo.
Olá,
Caí de paraquedas neste blog ! Não sou da área de TI!
Bem, na minha opinião, as práticas do PMBOK podem ser utilizadas em qualquer tamanho de projeto, pois cabe ao gerente de projetos adequá-las à dimensão do mesmo.
O PMBOK possui 47 processos !
Dependendo do projeto, podemos usar 20 processos, ou 15 !!!!
Ex: o projeto possui aquisições? Se não, já são 6 processos a menos ! E assim, para todas as áreas de conhecimento !
Isto não quer dizer que vamos eliminar determinada área de conhecimento por completo, mas sim criar atalhos eliminando alguns passos !
Abraços
Nelson