Apagando Incêndios
Deixei a poeira baixar para não cometer julgamentos equivocados. Estou falando do 'caos e pânico' que assustou São Paulo há 10 dias. Minhas opiniões sobre o tema eu já deixei no BlueNoir. Aqui eu quero tratar especificamente da parte que pode ser útil em projetos. Vou falar sobre Gerenciamento de Crises e Riscos e Aprendizagem Organizacional.
Todo projeto está sujeito a crises. E os sentimentos gerados por uma crise são muito ruins: Medo (de perder o emprego, por exemplo), angústia, insegurança. Sensação de que o final chegou, e não é nada feliz. O moral da equipe despenca, e o cliente pode estar raivoso ou simplesmente sem esperança alguma. No ápice de uma crise em um projeto é muito difícil dizer se ele, o projeto, sobreviverá. Acho que na maioria das vezes não. Mas uma virada é sempre possível. Há quem diga que é nessas horas que aparecem os verdadeiros líderes. Parece ser mesmo. Mas como lidar com crises em projetos?
O bom gerente de projetos aprende logo nos seus primeiros dias de coordenação que, "se ele não atacar diretamente os riscos, será atacado por eles"[1]. Manter atualizada uma lista de riscos, diariamente, é uma boa prática inquestionável. Saber o momento de disparar ações que visam a eliminação de um risco, ou a minoração da probabilidade desse acontecer, é algo que se aprende com o tempo. Infelizmente, boa parte de nossas listas se limitam ao óbvio. Ao 'top ten'. E trasmitem a ilusão de que os riscos são isolados.
Raramente uma crise é produto de um único risco mal tratado. Na verdade, uma crise em um projeto é resultado de uma série de ações e omissões. Boa parte previsível através do correto e atento gerenciamento de riscos. Mas, para falar especificamente sobre Gerenciamento de Crises, vamos supor que um fato novo, externo, tenha 'explodido' e gerado uma crise. Que sua combinação com outros fatores levou o projeto para aquele altar que todos miram com pesar: "Que pena. Era um projeto tão bonitinho". Mas o projeto não morreu. É só uma crise. Como debelá-la?
Não Entre em Pânico
A pior coisa que pode acontecer para um projeto em crise é seu líder entrar em pânico. É do líder que será cobrada a primeira opinião, ou melhor, a primeira justificativa. Se ele não tem a resposta, e normalmente ele não a tem nos primeiros momentos de uma crise, a melhor coisa a fazer é ser sincero e pedir um tempinho. Tentar dar respostas rápidas, tipo "está tudo sob controle", no meio do caos que impera, só ajuda a aumentar a confusão e gera mais dúvidas sobre a liderança. É importante aparentar calma, mas não devemos nos esquecer que o excesso de calma, aquele jeitão zen-budista, pode parecer alienação. Algo do tipo "não estou nem aí". E lembrar sempre que mentira tem 'pernas curtas'. Em projetos vivendo um momento de crise as mentiras não tem perna nenhuma.
O líder sempre precisa de um tempo para avaliar todo o contexto. E para conversar com todos os envolvidos. E, depois, precisa de um generoso tempo para analisar e consolidar todas as informações obtidas. Só ou acompanhado de um grupo muito pequeno e realmente relevante. Este é o momento em que o Princípio Calvin[2] deve ser lembrando constantemente: "Não há problema ruim o suficiente que não possa ser piorado com um pouco de culpa". Infelizmente é muito comum que, em momentos de crise, tudo que algumas pessoas buscam são algumas bruxas para queimar. Essas pessoas devem ser evitadas neste momento de reflexão.
Os principais produtos dessa análise são duas pequenas listas: uma com os principais fatores que resultaram na crise; e a segunda com um pequeno plano emergencial, a lista das principais atitudes que serão tomadas no sentido de recolocar o projeto nos trilhos. O principal valor da primeira lista é mostrar para o cliente ou usuário o quão 'dona' da situação a liderança está. Caso o cliente não concorde com os itens da lista, qual a chance dele aceitar o plano emergencial? Tentar esconder algumas causas debaixo do tapete transparente de uma crise é perda de tempo. E mais um motivo para enraivecer ou desanimar o cliente.
E um plano emergencial não deveria ser disparado sem antes ser negociado com o cliente. É crucial que todos os envolvidos saibam quais ações serão disparadas. Se não for para se comprometer com elas, no minímo para não atrapalhar. É fundamental que o líder saiba com quem pode contar. Seja para a execução de algumas 'horinhas extras', seja para enfrentar uma sabatina com usuários alterados. Lá fora costumam chamar de SWAT as equipes montadas para atacar situações de crise. Normalmente, direcionam um pequeno e especializado exército para 'construir e construir', visando tirar atrasos de um cronograma. Uma crise quase sempre é muito mais que um milestone perdido. E o mero reforço no número de dedos codificadores bate de frente com a Lei de Brooks: "Adicionar pessoas a um projeto de software atrasado só adiará a sua entrega". Ainda segundo Fred Brooks, "é como tentar apagar um incêndio com gasolina".
No auge de uma crise as únicas pessoas 'de fora' que podem ser realmente úteis são aquelas que tiveram algum envolvimento prévio com o projeto, membros de um escritório de projetos, arquitetos ou gerentes de negócios. Podem representar a organização contratada. Mas de forma alguma eles devem sobrepor ou questionar alguma decisão do líder atual do projeto. Não em público. 'Queimar' um líder neste momento é fácil. De certa forma, até covarde. Em time de futebol pode até funcionar. Mas raramente é uma decisão que representa ganhos imediatos para um projeto. Muito pelo contrário.
Informação é Calmante
Quanto menos (boa) informação circular, pior será a sensação de crise. Boa informação não significa necessariamente uma Boa Notícia, e sim uma informação fidedigna, formal e oficial. Quando a liderança deixa de falar diretamente com todos os envolvidos, ela abre espaço para todo tipo de boatos e especulações. É vital para o projeto que desde o início da crise a liderança mantenha um fluxo constante e programado de interações com o cliente e com os usuários. E, lógico, com o seu time. Se antes da crise as reuniões eram semanais, agora elas devem ser diárias. Se eram diárias, é recomendável que agora elas ocorram duas, três ou quatro vezes ao dia. Tal programação deveria ser seguida até o projeto retomar seu curso e ritmo naturais.
E não tem ata ou memorando que substitua uma boa conversa 'cara a cara'. O líder também deve evitar mandar 'representantes'. Seria sinal de fraqueza. Assim como é um péssimo sinal a companhia de várias pessoas 'de fora', representantes da organização contratada. Confessam assim uma falta de confiança no líder destacado para o desenvolvimento do projeto.
Mas o que é debatido até quatro vezes por dia com o cliente e com o time? Oras, o andamento do plano emergencial: i) O que deveria ter sido feito?; ii) O que fizemos; iii) O que falta fazer; iv) Quando será feito?; v) Quem fará?. Coisas básicas assim, corriqueiras em qualquer projeto. O ciclo curto de interações visa exclusivamente a aumentar a confiança do cliente, reduzir a pressão e a audiência da 'rádio-peão'. As reuniões devem ser breves e envolver um grupo pequeno de pessoas. Questões pontuais, técnicas por exemplo, devem ser debatidas em outro foro, específico. É crucial que não se desperdice o tempo de ninguém. Portanto, se uma pessoa não tem nada para contribuir em uma reunião, se ela 'entra muda e sai calada', é melhor que ela esteja fazendo outra coisa. Um cafezinho, por exemplo. Ou chá de camomila, mais indicado para momentos de crise.
O Jogo só é Duro quando a Gente é Mole
A frase aí é do ex-técnico do Corinthians, Ademar Braga, pouco antes de ser desclassificado na Libertadores. Independente de seu sucesso, a frase é certeira. Em momentos de crise quase tudo em um projeto passa a ser questionado. O líder, o escopo, a solução técnica, a qualidade dos desenvolvedores. Se tudo é realmente tão ruim, o cliente tem que aceitar que comprou mal pra caramba e fim de papo. Não é o caso na maioria das vezes. Mas, ainda assim, tudo ou quase tudo pode ser questionado. Nesse momento é de suma importância que o líder seja firme, que ele 'fale grosso'. Se começar a aceitar alterações de escopo, na equipe e na solução, ele só estará piorando nossas estatísticas no Chaos Report: o projeto será cancelado.
Muitas vezes a solução de uma crise, ou a majoração da probabilidade de se alcançar os próximos milestones, passa exatamente pela redução do escopo. Para conseguir a aceitação do cliente é fundamental que o líder do projeto seja firme. E, claro, um excelente negociador.
Se uma das origens da crise é o time do projeto, então a Firmeza do líder será testada de forma diferente. A última solução de sua lista deveria ser 'cortar a própria carne'. Quanto tempo um novo integrante levaria para se inteirar do projeto? Até que ponto a troca de seis por meia-dúzia adiantaria? É só (?) uma questão de convivência, de relacionamento? Muitas vezes nos esquecemos que aquilo ali é uma relação profissional. "Brigou no happy-hour e agora não quer mais trabalhar junto com Fulano". Esse tipo de coisa deve ser combatida com veemência pelo líder. E se for uma questão de insuficiência técnica? Se não for algo contornável dentro do projeto, via treinamento ou 'mentoring', aí sim deveria ser providenciada a troca daquele(s) membro(s). Mas o líder deve sempre se preocupar com a preservação do time. Que significa, diretamente, a conservação das experiências vividas até aquele momento. A manutenção do conhecimento adquirido.
Há melhor forma de aprendizado?
Ao término de uma crise, muita gente costuma falar só dos 'traumas'. Realmente podem ser horríveis. Mas cada crise, assim como cada projeto, representa uma oportunidade única de aprendizado. Para todos os envolvidos. De certa forma parece que os traumas ajudam a tornar aquela experiência ainda mais rica. Colocando de outra forma: podemos ficar mais sensíveis aos riscos que levaram àquela situação. Portanto, as chances de 'criarmos' uma crise parecida em um projeto futuro são quase nulas. Isso é aprendizado de verdade.
E é por isso que, quando impedimos que alguém viva tal experiência, limando-o do projeto antes de seu término (ou, pelo menos, do término da crise), estamos abortando uma chance única de aprendizado. Isso afeta diretamente a pessoa, mas prejudica também a organização. Uma organização que, não raro, desloca o coitado do Fulano para outro projeto, outro cliente, (outro presídio?), até que outra crise comece. E começa tudo de novo, sem que ninguém esteja aprendendo nada de novo.
===
Todo projeto está sujeito a crises. E os sentimentos gerados por uma crise são muito ruins: Medo (de perder o emprego, por exemplo), angústia, insegurança. Sensação de que o final chegou, e não é nada feliz. O moral da equipe despenca, e o cliente pode estar raivoso ou simplesmente sem esperança alguma. No ápice de uma crise em um projeto é muito difícil dizer se ele, o projeto, sobreviverá. Acho que na maioria das vezes não. Mas uma virada é sempre possível. Há quem diga que é nessas horas que aparecem os verdadeiros líderes. Parece ser mesmo. Mas como lidar com crises em projetos?
O bom gerente de projetos aprende logo nos seus primeiros dias de coordenação que, "se ele não atacar diretamente os riscos, será atacado por eles"[1]. Manter atualizada uma lista de riscos, diariamente, é uma boa prática inquestionável. Saber o momento de disparar ações que visam a eliminação de um risco, ou a minoração da probabilidade desse acontecer, é algo que se aprende com o tempo. Infelizmente, boa parte de nossas listas se limitam ao óbvio. Ao 'top ten'. E trasmitem a ilusão de que os riscos são isolados.
Raramente uma crise é produto de um único risco mal tratado. Na verdade, uma crise em um projeto é resultado de uma série de ações e omissões. Boa parte previsível através do correto e atento gerenciamento de riscos. Mas, para falar especificamente sobre Gerenciamento de Crises, vamos supor que um fato novo, externo, tenha 'explodido' e gerado uma crise. Que sua combinação com outros fatores levou o projeto para aquele altar que todos miram com pesar: "Que pena. Era um projeto tão bonitinho". Mas o projeto não morreu. É só uma crise. Como debelá-la?
Não Entre em Pânico
A pior coisa que pode acontecer para um projeto em crise é seu líder entrar em pânico. É do líder que será cobrada a primeira opinião, ou melhor, a primeira justificativa. Se ele não tem a resposta, e normalmente ele não a tem nos primeiros momentos de uma crise, a melhor coisa a fazer é ser sincero e pedir um tempinho. Tentar dar respostas rápidas, tipo "está tudo sob controle", no meio do caos que impera, só ajuda a aumentar a confusão e gera mais dúvidas sobre a liderança. É importante aparentar calma, mas não devemos nos esquecer que o excesso de calma, aquele jeitão zen-budista, pode parecer alienação. Algo do tipo "não estou nem aí". E lembrar sempre que mentira tem 'pernas curtas'. Em projetos vivendo um momento de crise as mentiras não tem perna nenhuma.
O líder sempre precisa de um tempo para avaliar todo o contexto. E para conversar com todos os envolvidos. E, depois, precisa de um generoso tempo para analisar e consolidar todas as informações obtidas. Só ou acompanhado de um grupo muito pequeno e realmente relevante. Este é o momento em que o Princípio Calvin[2] deve ser lembrando constantemente: "Não há problema ruim o suficiente que não possa ser piorado com um pouco de culpa". Infelizmente é muito comum que, em momentos de crise, tudo que algumas pessoas buscam são algumas bruxas para queimar. Essas pessoas devem ser evitadas neste momento de reflexão.
Os principais produtos dessa análise são duas pequenas listas: uma com os principais fatores que resultaram na crise; e a segunda com um pequeno plano emergencial, a lista das principais atitudes que serão tomadas no sentido de recolocar o projeto nos trilhos. O principal valor da primeira lista é mostrar para o cliente ou usuário o quão 'dona' da situação a liderança está. Caso o cliente não concorde com os itens da lista, qual a chance dele aceitar o plano emergencial? Tentar esconder algumas causas debaixo do tapete transparente de uma crise é perda de tempo. E mais um motivo para enraivecer ou desanimar o cliente.
E um plano emergencial não deveria ser disparado sem antes ser negociado com o cliente. É crucial que todos os envolvidos saibam quais ações serão disparadas. Se não for para se comprometer com elas, no minímo para não atrapalhar. É fundamental que o líder saiba com quem pode contar. Seja para a execução de algumas 'horinhas extras', seja para enfrentar uma sabatina com usuários alterados. Lá fora costumam chamar de SWAT as equipes montadas para atacar situações de crise. Normalmente, direcionam um pequeno e especializado exército para 'construir e construir', visando tirar atrasos de um cronograma. Uma crise quase sempre é muito mais que um milestone perdido. E o mero reforço no número de dedos codificadores bate de frente com a Lei de Brooks: "Adicionar pessoas a um projeto de software atrasado só adiará a sua entrega". Ainda segundo Fred Brooks, "é como tentar apagar um incêndio com gasolina".
No auge de uma crise as únicas pessoas 'de fora' que podem ser realmente úteis são aquelas que tiveram algum envolvimento prévio com o projeto, membros de um escritório de projetos, arquitetos ou gerentes de negócios. Podem representar a organização contratada. Mas de forma alguma eles devem sobrepor ou questionar alguma decisão do líder atual do projeto. Não em público. 'Queimar' um líder neste momento é fácil. De certa forma, até covarde. Em time de futebol pode até funcionar. Mas raramente é uma decisão que representa ganhos imediatos para um projeto. Muito pelo contrário.
Informação é Calmante
Quanto menos (boa) informação circular, pior será a sensação de crise. Boa informação não significa necessariamente uma Boa Notícia, e sim uma informação fidedigna, formal e oficial. Quando a liderança deixa de falar diretamente com todos os envolvidos, ela abre espaço para todo tipo de boatos e especulações. É vital para o projeto que desde o início da crise a liderança mantenha um fluxo constante e programado de interações com o cliente e com os usuários. E, lógico, com o seu time. Se antes da crise as reuniões eram semanais, agora elas devem ser diárias. Se eram diárias, é recomendável que agora elas ocorram duas, três ou quatro vezes ao dia. Tal programação deveria ser seguida até o projeto retomar seu curso e ritmo naturais.
E não tem ata ou memorando que substitua uma boa conversa 'cara a cara'. O líder também deve evitar mandar 'representantes'. Seria sinal de fraqueza. Assim como é um péssimo sinal a companhia de várias pessoas 'de fora', representantes da organização contratada. Confessam assim uma falta de confiança no líder destacado para o desenvolvimento do projeto.
Mas o que é debatido até quatro vezes por dia com o cliente e com o time? Oras, o andamento do plano emergencial: i) O que deveria ter sido feito?; ii) O que fizemos; iii) O que falta fazer; iv) Quando será feito?; v) Quem fará?. Coisas básicas assim, corriqueiras em qualquer projeto. O ciclo curto de interações visa exclusivamente a aumentar a confiança do cliente, reduzir a pressão e a audiência da 'rádio-peão'. As reuniões devem ser breves e envolver um grupo pequeno de pessoas. Questões pontuais, técnicas por exemplo, devem ser debatidas em outro foro, específico. É crucial que não se desperdice o tempo de ninguém. Portanto, se uma pessoa não tem nada para contribuir em uma reunião, se ela 'entra muda e sai calada', é melhor que ela esteja fazendo outra coisa. Um cafezinho, por exemplo. Ou chá de camomila, mais indicado para momentos de crise.
O Jogo só é Duro quando a Gente é Mole
A frase aí é do ex-técnico do Corinthians, Ademar Braga, pouco antes de ser desclassificado na Libertadores. Independente de seu sucesso, a frase é certeira. Em momentos de crise quase tudo em um projeto passa a ser questionado. O líder, o escopo, a solução técnica, a qualidade dos desenvolvedores. Se tudo é realmente tão ruim, o cliente tem que aceitar que comprou mal pra caramba e fim de papo. Não é o caso na maioria das vezes. Mas, ainda assim, tudo ou quase tudo pode ser questionado. Nesse momento é de suma importância que o líder seja firme, que ele 'fale grosso'. Se começar a aceitar alterações de escopo, na equipe e na solução, ele só estará piorando nossas estatísticas no Chaos Report: o projeto será cancelado.
Muitas vezes a solução de uma crise, ou a majoração da probabilidade de se alcançar os próximos milestones, passa exatamente pela redução do escopo. Para conseguir a aceitação do cliente é fundamental que o líder do projeto seja firme. E, claro, um excelente negociador.
Se uma das origens da crise é o time do projeto, então a Firmeza do líder será testada de forma diferente. A última solução de sua lista deveria ser 'cortar a própria carne'. Quanto tempo um novo integrante levaria para se inteirar do projeto? Até que ponto a troca de seis por meia-dúzia adiantaria? É só (?) uma questão de convivência, de relacionamento? Muitas vezes nos esquecemos que aquilo ali é uma relação profissional. "Brigou no happy-hour e agora não quer mais trabalhar junto com Fulano". Esse tipo de coisa deve ser combatida com veemência pelo líder. E se for uma questão de insuficiência técnica? Se não for algo contornável dentro do projeto, via treinamento ou 'mentoring', aí sim deveria ser providenciada a troca daquele(s) membro(s). Mas o líder deve sempre se preocupar com a preservação do time. Que significa, diretamente, a conservação das experiências vividas até aquele momento. A manutenção do conhecimento adquirido.
Há melhor forma de aprendizado?
Ao término de uma crise, muita gente costuma falar só dos 'traumas'. Realmente podem ser horríveis. Mas cada crise, assim como cada projeto, representa uma oportunidade única de aprendizado. Para todos os envolvidos. De certa forma parece que os traumas ajudam a tornar aquela experiência ainda mais rica. Colocando de outra forma: podemos ficar mais sensíveis aos riscos que levaram àquela situação. Portanto, as chances de 'criarmos' uma crise parecida em um projeto futuro são quase nulas. Isso é aprendizado de verdade.
E é por isso que, quando impedimos que alguém viva tal experiência, limando-o do projeto antes de seu término (ou, pelo menos, do término da crise), estamos abortando uma chance única de aprendizado. Isso afeta diretamente a pessoa, mas prejudica também a organização. Uma organização que, não raro, desloca o coitado do Fulano para outro projeto, outro cliente, (outro presídio?), até que outra crise comece. E começa tudo de novo, sem que ninguém esteja aprendendo nada de novo.
===
- Grady Booch, em "Object Solutions"
Addison-Wesley - 1996 - Bill Waterson, em uma tirinha do "Calvin"
quarta-feira, 24 de maio de 2006 |
Assine o finito
Lista completa no del.icio.us
Realmente as pessoas tendem a querer "tirar o delas da reta", isso é um erro, pois é importante cada componente do projeto ter comprometimento focando sucesso e principalmente ter um pensamento sistemico da real importancia do valor de sua contribuição.
Algumas coisas que não concordo:
Lei de Brooks: "Adicionar pessoas a um projeto de software atrasado só adiará a sua entrega".
Temos que ter cuidado com essa frase, para não generalizar, essas "leis" não devem ser seguidas como uma receita de bolo.
"O Jogo só é Duro quando a Gente é Mole".
Não significa que se a pessoa ser um lider nato, não terá grandes e dificeis obstaculos a enfrentar. Todo lider está sujeito a participar de um "jogo duro", pois ele não tem controle de todas as coisas externas, e nem por isso significa que ele seja incompetente, desinformado, "mole", etc.
"Nesse momento é de suma importância que o líder seja firme, que ele 'fale grosso'."
É importante ser firme, mas deve tomar muito cuidado, respeitar opiniões e principalmente não demonstrar força, prepotencia, arrogancia, tomar cuidado para não IMPOR e ponto final, pois isso desmotiva o time, e isso compromete definitivamente um projeto, digo por experiencia propria. Ele tem que ser firme, mas com "jeitinho", se for a questão de resolver problemas de relacionamento entre membros da equipe, ele deve ser capaz de resolver sim, sentar com as pessoas envolvidas e assumir o chapeu de "psicologo", e fechar o desentendimento com chave de ouro, fortalecendo a amizade, sentimento de equipe e principalmente a UNIÃO, mesmo que para isso tenha que vestir o chapeu de "psicologo".
É importante não sair cortando membros da equipe de uma forma tão firme, pois isso pode levar o membro a frustração e cair de produtividade na proxima tarefa que ele estiver envolvido, é importante fazer o remanejamento de forma discreta e com cuidado.
No mais, otimo artigo!
Deiverson
Deiverson,
sobre a "Lei de Brooks": já fiz vários comentários sobre ela (surrupiando um guia do Scott Berkun) em meu artigo anterior. Eles estão nesta parte do (longo) artigo: http://finito-log.blogspot.com/2006/03/entre-o-relgio-e-bola-de-cristal.html
A frase do Ademar é forte, né? Acho que até complicou um pouco mais o estado psicológico dos jogadores. Mas, entenda os seguinte: se o Líder titubear demais, ceder demais (sendo 'mole'), ele estará tornando o jogo do projeto muito mais 'duro'. Talvez se não tiver o 'só' a frase fique mais aceitável, não? Afinal, todo projeto é jogo duro. Por isso são tão legais.
Sobre o 'falar grosso'. Agora é questão de BOM SENSO, o que vc chamou de 'jeitinho'. Não gosto do termo. Remete ao 'jeitinho brasileiro', gambiarrinhas e afins.
Firmeza pode, em determinados momentos, ser confundida com arrogância? Infelizmente sim. E só o tempo, a comprovação da correção de algumas decisões, é que eliminarão a impressão ruim.
Quanto a "não sair cortando membros da equipe de uma forma tão firme", meu artigo reforça exatamente isso: a importância da manutenção e preservação do time. Acho crucial, em todos os aspectos. Tanto no momento do projeto (e da crise), quanto para o futuro da organização.
Grato pelos comentários. Abraços,
Paulo