Pressa x Velocidade

Já se tornou comum ouvir fazer uma pergunta despretensiosa do tipo "Como está?" e receber a resposta, em movimento, pois não há tempo, "Tá corrido!".

Seja dentro do seu convívio profissional ou fora dele, a grande maioria está passando pela mesma situação, onde a pressão por resultados distorce a visão do que é pressa e o que é velocidade e quais suas consequências para o indivíduo, para o projeto, para a instituição, ou seja, para todos os envolvidos.

A velocidade é um quesito bastante discutido no mundo ágil, que mede o poder para entrega de uma equipe em pontos, e toda a sequência de atividades leva em conta essa taxa. O quanto posso assumir de responsabilidade para as próximas semanas? Consulte a velocidade da equipe. Qual a próxima release do projeto? Mesma resposta anterior.

Note que existe uma grande diferença entre a velocidade calculada e a pressão desmedida.

É com base nesse tema que pensei e discuti com outras pessoas quais as causas dessa pressa disfarçada de velocidade. Quais são as consequências dessa naturalidade de uma situação negativa e pretensiosamente quais seriam as ações para evitar esse quadro?

INT. ESCRITÓRIO, ÁREA DO CAFÉ - MANHÃ

Ferris Bueller avista da sua mesa Patrick Bateman apanhando COPOS descartáveis para a primeira dose de cafeína matinal.
Ferris levanta-se e vai ao encontro do colega de trabalho levando o STATUS REPORT de um projeto.

FERRIS

Manuseia as folhas de papel do RELATÓRIO.

   Tudo certo para entregar as camisetas até o final da semana?

PATRICK

Nervoso, coloca o COPO de café que queima sua MÃO sobre o BALCÃO de granito.

   Como assim? A entrega vai acontecer dentro do cronograma, ou seja, em 15 dias.

FERRIS

   Não pode! O evento foi antecipado pelos patrocinadores. Vai acontecer sábado.
Ferris desvia o olhar enquanto caminha em direção ao bebedouro.

Você leitor, nunca passou por uma mudança de planos no seu projeto? Este é o primeiro item da lista de causas para a pressa. No caso acima, a mudança de planos partiu do cliente, que por algum motivo alterou a data do evento, antecipando todas as entregas necessárias. Primeiro é inevitável intervir no livre arbítrio do cliente, seja ele interno ou externo, mas nesse caso é necessário se resguardar de contratempos. Um contrato bem descrito delimitando o escopo e o não escopo, bem como as restrições de projetos e datas poderiam ajudar a garantir a tranquilidade e qualidade da entrega.

Para essas situações, a capacidade de negociação de um Gerente de Projetos é bem vinda. Escopo e Preço são quesitos a serem discutidos entre cliente e fornecedor, uma vez que o item Prazo, neste caso não é negociável.

Contudo, gostaria de chamar a atenção para uma questão que deve ficar clara: o impacto na pressa no quesito Qualidade. É válido um fornecedor comprometer sua imagem entregando um produto de baixa qualidade para satisfazer mudanças de planos?

EXT. PRAÇA XV DE NOVEMBRO, CENTRO DE FLORIPA - TARDE

Walter Sochalk e Juno MacGuff caminham em direção ao escritório.

WALTER

   Como está o andamento do relatório que te pedi hoje pela manhã?

JUNO

Olhando séria para o seu chefe, rebate.
   Estava finalizando todos os relatórios previstos para a semana. As compras já foram realizadas e o cliente pediu a você esse relatório há duas semanas atrás. Se atrasarmos mais uma semana perderemos a conta.
Suspira, e lembra da hierarquia.
   Ok, qual dos projetos devo me dedicar?

WALTER

   Os dois!

Trabalho paralelo é uma atividade muito questionável, mas que perdura nas organizações, na falsa ideia de que serão entregues mais produtos. Com o objetivo de paralelizar os projetos, permitindo à equipe o foco necessário para uma entrega ágil e de qualidade, o Gerente de Projetos deve renegociar os prazos com os clientes, tendo como base de negociação o ROI de cada um dos projetos e seguir o Planejamento Estratégico da sua empresa.

INT. SALA DE REUNIÕES - INÍCIO DA TARDE

Frank Drebin reune sua equipe para expor uma nova situação do projeto. Na reunião está presente o funcionário falastrão Daniel Plainview.

FRANK

Folheando um E-MAIL do cliente impresso recebido antes do almoço.
   Pessoal, convoquei essa reunião para mostrar a vocês uma nova ideia do cliente. Essa funcionalidade deve estar presente na nossa próxima entrega.

DANIEL

Inquieto na CADEIRA confortável da sala, questiona.
   Frank, o prazo é curto, estamos no meio da Sprint, cabe inserir uma nova funcionalidade nessa altura do campeonato? Pela regra a Sprint deveria ser cancelada!

FRANK

   Daniel, devemos fazer o nosso melhor para atender o principal cliente da empresa.

A grande parte dos problemas dos projetos consiste na definição do escopo. Um escopo mal definido certamente trará problemas semelhantes a situação supracitada. Para tentar minimizar esse tipo de problema, o projeto deve ter um documento de Definição Formal do Escopo, que deve estar de acordo entre todos os envolvidos.

A participação de componentes experientes, um analista de sistemas sênior, para a coleta de requisitos também é um fator importante. No entanto, em uma situação de mudança, que deve ser recebida, cabe mais uma vez a negociação do que é escopo do projeto e reavaliar as próximas entregas - o que sai para a nova demanda entrar. E uma dica: estamos dispostos a ajudar o cliente, mas não podemos quebrar nosso fluxo de trabalho para adequar a um problema de escopo, inserir itens no meio de uma Sprint, por exemplo (Scrum).

Outras causas que acredito ser próprias para apressar o projeto:

A insegurança de um componente da equipe. Insegurança pela sua situação na empresa, a garantia de emprego, fusões, novos desafios ou novo cargo, são situações que ajudam na pressa desse indivíduo. Cabe ao Gerente, Scrum Master, Coordenador da equipe, ou seja lá quem estiver no comando ter a sensibilidade de observar indicativos de que isso esteja acontecendo e tratá-la de imediato. Investir nesse funcionário, apresentar a realidade da situação, dar o feedback frequentemente pode auxiliar a evitar a insegurança.

Problema técnico de um dos envolvidos na equipe de produção. Primeiro é importante ter esses indicadores de qualidade e produtividade, justamente para tratar essas situações. Acredito que para esses casos, o responsável pela equipe deve seguir uma ordem de ações: dar mais tempo para a execução das tarefas; ser o coaching desse indivíduo; proporcionar o treinamento no ponto fraco; planejar a realocação para uma área de maior afinidade; por fim, mas somente em últimos casos, analisar a demissão desse elemento. O problema técnico traz invariavelmente muito retrabalho e o acúmulo de novas tarefas, com isso, quem paga o preço é a qualidade das entregas.

Os prazos impossíveis não devem ser aceitos. Primar pela qualidade das entregas e a maneira que a empresa é conceituada no mercado são pontos primordiais suficientes para não aceitar em hipótese alguma uma entrega impossível. A VocêSA de Março de 2010 mostra uma empresa - IMI - Instituto de Marketing Industrial, que aceita somente seis grandes cliente por ano. Imagine o motivo que leva uma grande empresa de consultoria em gestão colocar como regra uma limitação no número de cliente por ano. Essa é uma postura fantástica frente o mercado capitalista. É uma atitude quase surreal, concorda? Mas muito provavelmente essa empresa tem como objetivo final a qualidade. Nossos avós estavam certos quando recitavam que "a pressa é inimiga da perfeição". Outras alternativas para não ser pego de surpresa é promover o recebimento de projetos de forma organizada e antecipada ou mesmo antever sazonalidades que provoquem um crescimento nas demandas.

Um prejuízo tão grande que um prazo impossível imposto pelo cliente é um prazo mal mensurado pela equipe. Como em muitas oportunidades o acordo já foi firmado, a equipe absorve o erro e cria um ambiente pouco propício para a criatividade e o bom andamento dos trabalhos. E eis que começa a correria! Para esses casos, capacitar a equipe, ter a ajuda de um colaborador com experiência e realizar uma reunião de brainstorm sobre o projeto podem ajudar no cálculo mais acertado de prazo.

Após toda a reflexão e algumas ideias sobre o culto a pressa, algumas coisas devem ficar como perguntas para um momento de correria em seu projeto:

• Estou ciente que essa urgência poderá acarretar problemas de qualidade nas entregas?
• Estou disposto a colocar em jogo a imagem da empresa para atender essa demanda?
• Minha equipe responderá positivamente a essa pressão inesperada?
• Terei capacidade de prover aos meus funcionários um ambiente confortável e que permita o bom relacionamento e a criatividade mesmo no atendimento de uma urgência?

E lembre-se que dizer não também é sinal de profissionalismo.

Abraços.

Referências:

CORREA, F. (Março 2010). O mal do culto à urgência. VOCÊSA.

Nomes dos personagens inspirados em filmes:

Daniel Plainview (Daniel Day-Lewis - Sangue Negro)
Ferris Bueller (Matthew Broderick - Curtindo a vida adoidado)
Frank Drebin (Leslie Nielsen – Corra Que a Polícia Vem Aí!)
Juno MacGuff (Ellen Page – Juno)

Plano Semanal

O terceiro hábito citado por Covey em seu livro 7 Hábitos das Pessoas Altamente Eficazes tem um título bastante sugestivo: Primeiro o mais importante.

Passamos os dias pulando entre os quadrantes de importância e urgência (imagem abaixo), mas nunca paramos para calcular em quais tarefas o esforço deveria ser aplicado. Sou uma pessoa do papel, que precisa elencar as metas semanais para que quando efetivadas rabiscá-las e seguir em frente, e alcançar o próximo objetivo. Isso me permite manter claro o foco e onde minhas atenções devem se direcionar. Por esse motivo uso o Plano Semanal. 

Antes, é preciso compreender a diferença entre Ungência e Importância.

É dita urgente uma atividade que requer atenção imediata. É quando o "fogo está pegando" e você pode ajudar a apagá-lo.

Por outro lado, o importante vai ao encontro da metas, da missão e dos valores. Em uma perspectiva pessoal seriam ações que o deixa mais perto de alcançar um plano de carreira, por exemplo. Corporativamente, poderia citar os planos de ação para alcançar os objetivos estratégicos do Balanced Scorecard da Empresa.

Agora você pode me perguntar: simples assim? A resposta é não. Nunca é simples. Seguir um plano nunca é tranquilo. O seu desafio é buscar reduzir os incêndios para limitar o máximo de suas atenções no que traz resultado, o Importante.

A construção da integridade pessoal advém do cumprimento de compromissos assumidos, seja na sua vida pessoal ou profissional.

Baseado em uma proposta apresentada no livro 7 Hábitos, disponibilizo aqui uma planilha denominada de Plano Semanal. O preenchimento semanal (domingo a noite é um ótimo momento para isso) deve seguir alguns passos, conforme segue:

• Papéis: o nosso tempo é dividido entre diferentes funções sociais ou papéis. Amigo, Marido, Gerente de Equipe, Filho. Segundo Barbosa e Cerbasi, aqui deve haver o máximo de equilíbrio entre os papéis. Pois assim que surge uma atividade urgente para resolver, geralmente o tempo dedicado a papéis prazerosos é eliminado. Errado, não? Mas essa é uma realidade.
• Projeto: quando utilizado na vida profissional esse item parece fazer mais sentido. Mas você pode sim traçar projetos pessoais, como Graduação, Mestrado ou a Reforma da Casa. Esse item é opcional e que foi inserido por mim por uma necessidade pessoal.
• Atividades: são as ações que você deve realizar dentro dos diferentes papéis tendo sempre a meta como parâmetro mais importante. Atender o importante, reservando algum tempo para emergências.
• Prioridades do Dia: particularmente, nas Prioridades do Dia, aponto apenas a numeração das atividades, para deixar a planilha mais leve e eliminar a sensação de estar superestimando o tempo.

O que é interessante é que a medida em que as semanas passam, você vai adaptando a planilha de forma que atenda as suas necessidades. Além disso, é importante salientar que o Plano Semanal é vivo, portanto pode e deve ser trabalhado durante a semana.

Lembre-se que o plano deve sempre atender a meta e quanto maior o número de ações para isso, mais eficazes seremos. Em resumo, devemos diminuir gradativamente o número de tarefas que não atendam a meta.

Ao final de cada semana você pode mensurar o percentual de tarefas agendadas que foram finalizadas, gerando um ranking pessoal, ou até mesmo um desafio semanal de alcançar determinado valor.

Fica aí a dica!

Abraço.

Referências:

CERBASI, G., & BARBOSA, C. (2009). Mais tempo, mais dinheiro. Thomas Nelson Brasil.
COVEY, S. (2008). Os 7 hábitos das pessoas altamente eficazes. Franklin Covey.

Planejamento de Reuniões

Tenho um amigo que adora reuniões, apesar de comentar comigo que as vezes são improdutivas ou longas demais. A sensação depois de um dia inteiro de reuniões pode ser de frustração ou a impressão de que não produziu o que poderia ter produzido.

Para evitar o mau uso do tempo é preciso em primeiro lugar identificar a necessidade da reunião. Caso a reunião seja inevitável passamos para o seu planejamento.

O planejamento de uma reunião deve prever os seguintes quesitos: objetivo, resultado, tempo, participantes, agenda e infra-estrutura.

Caso você seja o facilitador da reunião, o primeiro item que precisa ser definido é o objetivo da reunião. Esse quesito é fácil e importante para que os participantes se preparem para o tema que será discutido.

Em seguida, preciso antecipar o resultado da reunião. Qual é a minha meta para essa reunião? Ao final da reunião a meta deve ter sido alcançada.

A definição do tempo é primordial para dar foco, manter o objetivo e a agenda da reunião, além de evitar que a reunião se alongue indefinidamente, comprometendo o planejamento diário. O ideal para uma reunião é uma duração entre 45 e 60 minutos.

Devido ao tempo e dependendo do tema, será necessário estudar bem a lista de participantes da reunião. Logicamente o número de pessoas pode comprometer o tempo e até mesmo a qualidade da reunião. "O excesso de gente impede de ver as pessoas" - Mário Quintana tinha razão, no nosso contexto o excesso tira o foco das peças importantes para a resolução do problema e que mereceriam maior atenção. Autores afirmam que o número ideal é de 6 participantes.

Durante a reunião, uma informação que ajudará a manter o ritmo e garantir o atendimento do resultado é a agenda da reunião. Você define o cronograma de informações a serem discutidas, e pode até atribuir o tempo de discussão para cada item, a fim de manter o bom andamento da reunião.

Por fim, garanta que a estrutura esteja disponível para a reunião. O levantamento das necessidades de infra-estrutura e verificação antes do início da reunião evita contratempos de última hora.

Espero que essas dicas simples possam ajudá-lo a tornar sua reunião mais produtiva.

Abraço.

Liderança Coercitiva

Um questionamento de amigos sobre qual o melhor estilo de liderança me motivou a realizar um breve estudo sobre o assunto. Para alguns não existe tipo de liderança. Existe o certo e os demais, errados.

E a minha resposta é que não existe o tipo de liderança certo. A liderança depende do contexto, da situação da equipe, do projeto e também da empresa.

De acordo com GAUDENCIO existem seis tipos de liderança: Coercitivo, Autoritário, Afiliativo, Democrático, Marcador de Ritmo e Treinador. Nesse post comentarei sobre o primeiro e controverso estilo de liderança - Coercitivo.

Gosto de assistir a programas de culinária como o de inglês Jamie Oliver e do Gordon Ramsey, World Class Chef e apresentador do programa que no Brasil é transmitido pelo GNT denominado Kitchen Nightmares (http://gnt.globo.com/Kitchen-Nightmares/index.shtml). Pelo nome do programa podemos ter uma ideia do nível de coerção.

O programa é um reality show de restaurantes a beira da falência, onde Ramsey entra em cena e tem uma semana para revolucionar o estabelecimento e os próprios donos, cozinheiros, garçons, ou seja, é um verdadeiro pesadelo para os envolvidos.

Invariavelmente o restaurante está em situação crítica, com equipe desmotivada e desacreditada. Ramsey tem a missão de virar a mesa.

Nesse cenário caótico o apresentador literalmente transforma o restaurante. Por vezes uma reforma no ambiente é realizada onde cores e mobiliário são mudados. Em outras oportunidades o menu é alterado, chegando a ser alterada a proposta de atividade do próprio restaurante, de fast food para churrascaria, para se ter uma ideia.

Mas toda essa mudança é leve frente a pressão psicológica realizada por Ramsey em toda a equipe do restaurante. Com autocontrole, iniciativa e foco nos resultados, o apresentador é estilo do "Faça o que eu mando", típico do líder coercitivo, o que elimina que novas ideias sejam apresentadas pelo simples fato de que elas não serão implementadas. GOLEMAN afirma que nesses casos os colaboradores se tornam "incapazes de agir por sua própria iniciativa, eles perdem o senso de domínio e sentem pouca responsabilidade pelo seu desempenho".

Intimidação e diminuição da auto-estima da equipe provocam com certa frequencia deserções de funcionários do restaurante. Mas o resultado não seria satisfatório se o chef tivesse essa postura durante todo o período de incubação dentro do restaurante. Gordon toma cuidado, porém bastante eventual, de levantar o moral do grupo ou dar elogios, o que quase sempre ocorrem no final do programa. Até lá, os envolvidos devem aturar o chef coercitivo.

Apesar de considerado um estilo que leva as piores notas quanto aos efeitos sobre os resultados e o clima organizacional [GOLEMAN], GAUDENCIO defende que há aplicações para a liderança coercitiva: crise, caos, funcionários problemáticos, virada de mesa são situações que a atuação da coerção traz benefícios.

No entanto, a liderança coercitiva deve ser usada com parcimônia, em um período curto de tempo, pois caso contrário o estilo insensível desse líder abate a moral e a motivação da equipe.

Particularmente não gostaria de fazer parte de uma equipe liderado coercitivamente. Logicamente que equipes maduras em situação normal das atividades não justificam esse tipo de liderança, porém, Ramsey comprova que em determinados casos o estilo funciona.

O programa vale a pena!

Abraço.

Referência:

GOLEMAN, Daniel. Liderança com inteligência emocional. Disponível na Internet em: http://www.mettodo.com.br/pdf/Lideran%E7a%20com%20a%20Intelig%EAncia%20Emocional.pdf. Acessado em 2010.

GAUDENCIO, Paulo. Superdicas para se tornar um verdadeiro líder.

Imagem: Diego de Los Campos: unumeno boristefa. Disponível na Internet em: http://deloscampos.multiply.com/photos/album/30/unumeno_boristefa#photo=3.jpg. Acessado em 2010.

Recuperação do Projeto Problema

Projeto Problema é quando temos uma diferença que ultrapassa os limites aceitáveis entre o que foi planejado e a situação atual.

Assim, identificado o problema, uma análise de viabilidade aponta para dois caminhos: término ou continuidade do projeto. Este será o tema abordado nesse post.

Optando-se por continuar o projeto o primeiro passo é tirar o estigma de projeto problema e transformá-lo em um projeto de sucesso. Fácil? Nunca é fácil! Tirar um projeto do caminho para o fracasso e trazê-lo de volta aos trilhos é um processo bastante desgastante para todos os interessados, principalmente para a equipe e Gerente de Projetos.

Um re-planejamento é obrigatório, uma vez que não será possível manter o plano original na expectativa de alcançar a meta. Será necessária uma intervenção diferenciada para esse tipo de projeto, onde é necessário reavaliar a tripla restrição: Custo, Prazo e Escopo.

Lamentavelmente, ao menos um dos itens da tripla restrição irá pagar a conta para recuperação do projeto. Cabe entender o que é mais importante para o cliente dentro da tripla restrição.

Nesse momento, o Gerente de Projetos deve negociar junto ao Patrocinador e os envolvidos o plano de recuperação que utiliza umas das seguintes alternativas ou variações das mesmas:

1. Manutenção do Escopo com variação do Custo e do Prazo;
2. Manutenção do Custo com variação do Prazo e do Escopo;
3. Manutenção do Prazo com variação do Escopo e do Custo;
4. Variação do Escopo, Custo e Prazo.

Como nota, a quarta edição do PMBOK trata de forma diferente as restrições. As restrições do guia para a nova versão são: Escopo, Qualidade, Cronograma (antigo Prazo), Orçamento (antigo Custo), Recursos e Risco.

Um breve comentário pessoal sobre a alteração do PMBOK: a análise da tripla restrição é propícia em momentos de readequação do planejamento, para corrigir o andamento de um projeto. Não vejo a negociação dos riscos junto ao cliente. Pense na redução da qualidade de um projeto? É possível? Quais seriam os impactos dessa decisão para o projeto?

As seis restrições são requisitos gerenciáveis no projeto, onde devem estar focadas as atenções do Gerente de Projeto, assim como as áreas de conhecimento.

Outras técnicas para estimular o projeto, segundo MEADOWS, em ordem de eficácia:

12. Manipulação de parâmetros, números ou constantes: o acréscimo no número de programadores para aumentar a velocidade de desenvolvimento é um exemplo. Apesar de não alterar o sistema, é utilizado, por vezes de forma eficiente, para otimizar o andamento do projeto.

11. Tamanho do buffer: buffer ou inventário consiste em requisitos não implementados, ou parcialmente desenvolvidos, e deixam o projeto pesado, aumentam a complexidade e dificultam atualização e manutenção do sistema.

10. Fluxo e estrutura de estoques: de acordo com MEADOWS, esse item desfila entre os de menor impacto não pela sua eficácia, mas sim pela dificuldade e custo de implementação, sempre associada a uma profunda mudança no processo. VALE comenta sobre a adoção de práticas ágeis, que proporcionam a mudança bastante satisfatória nesse sentido, como a utilização do kanban para acompanhar o fluxo do inventário.

9. Tempos de resposta às mudanças: em geral, os tempos de resposta são difíceis de atuar, segundo MEADOWS, "as coisas levam o tempo que elas levam", mas se identificado um processo que pode ser otimizado, todo sistema terá grandes mudanças. É a historinha da Teoria das Restrições do Goldratt no livro A Meta.

8. A força dos ciclos de feedback negativo: daqui para diante os pontos de alavancagem deixam de tratar questões ditas físicas para tratar as questões de informação e controle. A força do feedback negativo é composto de monitoramento, controle e ações de correção. Inúmeras técnicas podem ser aplicadas para proporcionar o feedback negativo, afim de estabilizar o projeto que saiu do seu fluxo normal. O Scrum utiliza reuniões para acompanhar e traçar ações - diárias, de review e de retrospectiva.

7. O ganho em torno de condução ciclos de feedbacks positivos: são ciclos de auto-reforço que tem como essência ser a fonte de crescimento do processo. Segundo VALE, "é a potencialização do aparecimento de um determinado evento pelo simples fato de ele existir". Esse evento pode ser bom ou ruim. Como exemplo de um evento ruim, posso citar o desenvolvimento de sistemas com muito erros, e quanto mais problemas um sistema possuir, maior o tempo dedicado para correção, dificultando a manutenção e reduzindo o tempo para aumentar a qualidade da implementação. Utilizar-se de um evento, seja ele negativo ou positivo, é outro ponto de alavancagem.

6. Estrutura do fluxo de informações: consiste em proporcionar a fluidez das informações dentro da equipe de projeto e todos os envolvidos. Proporcionar clareza nos processos e principalmente difundir as informações, pois todo o conceito sobre esse ponto de alavancagem consiste na comunicação. As práticas ágeis promovem a comunicação como elemento norteador das ações, começando pelo próprio kanban. No entanto, a comunicação não é exclusividade ágil. O PMBOK trata como uma das áreas dentro do Gerenciamento da Comunicação.

5. Regras do sistema: consiste no escopo do projeto. Segundo MEADOWS, "se você quer entender profundamente um mau funcionamento do sistema, atente para as regras e quem detém o poder sobre elas".

4. O poder da auto-organização: a habilidade para se auto-organizar frente às alterações no ambiente. Consiste na mais poderosa forma de resiliência. Um sistema auto-organizável, também denominado auto-gerenciável, é um fluxo consciente que não só busca o atendimento das metas, mas também está preparado para atuar proativamente de forma a corrigir o caminho sem a necessidade de intervenção superior. Muitos discorrem negativamente sobre essa ideia. Particularmente acredito em uma equipe auto-gerenciável, pois já fiz parte dessa equipe, e considero, apesar do senso comum afirmar o oposto, que não há relação direta com a maturidade da equipe. A liderança e o coach nesse assunto são essenciais.

3. As metas do sistema: as definições de metas claras e alcançáveis norteiam a equipe de desenvolvimento assim como auxilia os envolvidos no momento de sua validação. O Scrum utiliza bem esse ponto de alavancagem, onde cada Sprint recebe uma meta, que deve ser perseguida pela equipe e posteriormente validada na reunião de review pelos stakeholders.

2. Paradigmas: paradigmas são pré-conceitos. A proposta desse ponto de alavancagem é justamente desafiá-las. A mudança pode acontecer de diversas formas - dentro do modelo de gestão, metodologia de desenvolvimento, arquitetura, testes, ou seja, em qualquer área do processo. Fiz parte de uma equipe que abraçou uma nova metodologia, o Scrum. Essa mudança de paradigma alterou desde a motivação da equipe até o nosso conceito junto aos clientes. O potencial da mudança de paradigma é gigantesco, mas só não é maior do que o próximo item.

1. Transcendência de paradigmas: mais do que desafiá-lo, esse ponto de alavancagem nos abre uma nova perspectiva - a de não abraçar nenhum paradigma. Evitar o fanatismo, reconhecer que não há verdade absoluta e que processos melhores e mais eficazes podem surgir da união de duas propostas ditas antagônicas ou até mesmo da proposição de uma terceira via totalmente nova e revolucionária. O cruzamento entre a agilidade e o formalismo é um exemplo disso, no qual defendo no meu primeiro post (http://tinyurl.com/yjuvbrs).

O assunto Projetos Problemáticos é imenso, cabe uma boa leitura nas referências apontadas abaixo. Um próximo post poderia ser perfeitamente sobre Lições Aprendidas, tema que caberia perfeitamente na sequencia dessa trilogia que virou seriado.

Abraços

Referências

ESI International. The rapid assessment and recovery of troubled projects. Disponível na Internet em http://www.projectsmart.co.uk/docs/rapid-assessment-and-recovery-of-troubled-projects.pdf. Atualizado em 2007. Acessado em 2010.

VARGAS, Ricardo. Identificando e recuperando projetos problemáticos: como resgatar seu projeto do fracasso. Disponível na Internet em:http://www.ricardo-vargas.com/wp-content/uploads/downloads/ricardo_vargas_identifying_recovering_troubled_projects_pt.pdf. Atualizado em 2006. Acessado em 2010.

MEADOWS, Donella. Leverage Points - Places to Intervene in a System. Disponível na Internet em: http://www.sustainabilityinstitute.org/pubs/Leverage_Points.pdf. Atualizado em 1999. Acessado em 2010.

VALE, Alisson. Projetos Ágeis e os 12 Pontos de Alavancagem Sistêmica. Disponível na Internet em: http://www.alissonvale.com/englishblog/post/Projetos-Ageis-e-os-12-Pontos-de-Alavancagem-Sistemica.aspx. Atualizado em 2008. Acessado em 2010.

Imagem: Diego de Los Campos. Disponível na Internet em: http://deloscampos.multiply.com/photos/album/87/desenhos#photo=1

Término do Projeto Problema

Dando continuidade ao post "Projeto Problema", o Gerente do Projeto, o Patrocinador e os envolvidos decidiram por cancelar o projeto. Isso acontece pois em alguns casos a recuperação do projeto é irrecuperável ou inviável. Irrecuperável quando não importa o esforço dedicado para correção da rota, o resultado será o fracasso, geralmente envolve escopo. Inviável quando o esforço alocado não justifica o retorno, nesses casos o tempo e o custo são  justificativas frequentes. Ambos fadados ao fracasso.

No entanto, precisaremos de argumentos para avaliar o término de um projeto. Algumas razões para o cancelamento de um projeto, onde a recuperação é impossível [ESI]:

• O benefício do negócio não pode mais ser entregue;
• Não há suporte político;
• Inexistência do Patrocinador;
• Alteração do negócio;
• Mudanças significativas na tecnologia;
• Quebra de contrato;
• Disputa judicial;
• Mudança de mercado.

Podemos citar também a inviabilidade financeira de trazer um projeto a beira do fracasso para os trilhos. É uma decisão de perder o investimento realizado até o momento para salvar a quantia, que invariavelmente será alta, para a recuperação do projeto.

Verificada a necessidade de término do projeto, a decisão deve estar pautada sobre quatro opções de finalização:

• Adição: acontece quando o projeto problema passa a ser parte de um projeto maior, para onde são destinados o trabalho e os recursos;
• Absorção: é semelhante ao de Adição, porém somente os trabalhos são absorvidos pelo projeto maior. Infra e recursos são liberados para outro projeto;
• Inanição: é o método controverso e impiedoso, onde recursos são eliminados do projeto aos poucos, retirando o alimento de um projeto já enfraquecido, o que literalmente mata projeto de fome;
• Extinção: é o termino imediato do projeto, com o natural redirecionamento dos recursos.

Uma pesquisa nos Estados Unidos apontou as causas mais comuns para o término de um projeto, e não é surpresa que mais de 50% dessas causas é com relação ao escopo, conforme segue [PAIVA]:

• 30% alterações das necessidades do negócio;
• 23% o projeto não entregou o que era prometido;
• 14% o projeto deixou de ser uma prioridade;
• 13% estouro do orçamento;
• 07% não suportava a estratégia de negócios;
• 04% atrasos excessivos.

O próximo post finaliza a trilogia dos projetos problema com a decisão de seguir em frente com o projeto.

Abraços.


Referências

ESI International. The rapid assessment and recovery of troubled projects. Disponível na Internet em http://www.projectsmart.co.uk/docs/rapid-assessment-and-recovery-of-troubled-projects.pdf. Atualizado em 2007. Acessado em 2010.

VARGAS, Ricardo. Identificando e recuperando projetos problemáticos: como resgatar seu projeto do fracasso. Disponível na Internet em  http://www.ricardo-vargas.com/wp-content/uploads/downloads/ricardo_vargas_identifying_recovering_troubled_projects_pt.pdf. Atualizado em 2006. Acessado em 2010.

PAIVA, Luiz. Principais Causas de Cancelamento de Projetos.  Disponível na Internet em: http://ogerente.com/stakeholder/2008/08/28/principais-causas-de-cancelamento-de-projetos/. Atualizado em 2008. Acessado em 2010.

Imagem: Diego de Los Campos: Postura de ausência ou teletransportação (plano físico). Usualmente praticada nos dias de boa ondulação.Disponível na Internet em: http://deloscampos.multiply.com/photos/album/31/31#photo=7.jpg

Projeto Problema

Guias de boas práticas em gerenciamento de projetos, como o PMBOK, apresentam uma realidade um tanto fantasiosa do plano perfeito, que não existe na prática. Quem nunca ouviu "para um projeto dar errado, basta nada fazer", segundo Ricardo Vargas. Basta apenas não assumir o leme quando o barco estiver indo para a direção errada.

Mas afinal, como podemos definir um projeto problema? Aparentemente é fácil de definir na teoria, onde torna-se perceptível um projeto problemático "quando temos uma diferença que ultrapassa os limites aceitáveis entre o que foi planejado e a situação atual".

Durante o projeto será preciso monitorar constantemente sinais de disfunção nos stakeholders, recursos, escopo, riscos, escopo e prazo. Esse monitoramento ajuda ao Gerente identificar possíveis problemas no projeto, entre elas, é possível citar, segundo [ESI]:

• Os envolvidos não tem a certeza quando o projeto será finalizado: uma equipe inexperiente e a falta de recursos [WU], são algumas causas dessa indecisão quanto a entrega do produto;
• O produto do projeto apresenta muitos erros: uma equipe inexperiente e testes funcionais inadequados [WU]. Testes de segurança e desempenho ausentes ou inadequados são outras causas do número de erros no projeto (trazendo para TI). Em casos de entregas com erros vale uma análise um pouco mais fria, pois muitas horas de trabalho, as mudanças de escopo emergenciais, a pressão e o próprio treinamento da equipe podem colaborar para essas entregas problemáticas. Nem sempre a culpa é exclusivamente da equipe;
• Realização de horas extras pelo time: clássico! Horas intermináveis de trabalho extra, seja para cobrir alterações de escopo na última hora, ou para correção de erros, é um fator muito subestimado de problema no planejamento do projeto, que pode acontecer por diversos motivos, sendo um deles a inadequação do patrocinador [WU];
• A gerência perde o controle sobre o progresso ou o status preciso do projeto: a indefinição do escopo ou até mesmo do não-escopo são causas para essa sensação. Aqui entra o Gerente com auxílio da equipe para fechar o projeto junto ao cliente. Formalizar o escopo? O mundo ágil não vê com bons olhos, mas apesar de ser um fã do Agile, esse ponto é bastante polêmico, vale outro post;
• Perda de confiança do cliente sobre o time de desenvolvimento: frequentes atrasos, entregas erráticas, imprecisão quanto a entrega, são fatores que descredenciam a equipe do projeto;
• A equipe é defensiva sobre o progresso do projeto: desacreditada e como citado abaixo, por vezes com a moral baixa, a equipe se torna reativa e defensiva quanto ao andamento do projeto. Por vezes descredita a manutenção do escopo, o que limita a visão do fim que a equipe tem sobre o projeto, fator desmotivador. Bola de neve;
• A relação entre o time de desenvolvimento e os demais envolvidos estão tensas e por vezes desgastadas: erros constantes e atraso por um lado, alteração constante de escopo pelo outro lado acirram os ânimos dos envolvidos. O Gerente deve tomar medidas diplomáticas para resolução desse problema e por vezes, em uma atitude mais radical, isolar a equipe de desenvolvimento, procurando manter o ambiente apropriado para o trabalho;
• O projeto está a beira do cancelamento: quando o próprio patrocinador já questiona a continuidade do projeto é um fator mais do que necessário para desencadear boa parte dos itens citados acima. Por vezes, e iremos ver em posts futuros, o cancelamento é a saída mais plausível a ser tomada, por outras, prejudica o andamento de um projeto já errático. O Sponsor é aquele que acredita e deposita a confiança nos envolvidos. Fala do projeto com entusiasmo e o abraça como se fosse a um sonho pessoal. Isso é inspirador e contagia a equipe;
• A moral o time está abalada e demasiadamente baixa: erros + insatisfação + pressão interna por vezes inevitável + projeto a beira do cancelamento. É uma fórmula bastante depreciativa e certamente abala qualquer equipe. Trazê-la de volta ao rumo certo é tarefa complicada e quase impossível em curto prazo;
• O cliente ameaça tomar medidas legais: projetos com contratos SLA, por exemplo, prevêem a ação judicial em caso de erros por pontos de função, por exemplo, que quando acionados, trazem intranquilidade e aumenta a pressão sobre a equipe de projeto. É um claro indicador de problemas no projeto.

Outros fatores citados por VARGAS, que identificam um projeto problema são:

• Ausência dos envolvidos no projeto: quem define o negócio? Onde está o Product Owner? Essa ausência compromete o produto do projeto, que poderá não atender ao negócio. Uma situação contrária, onde temos dois ou mais Product Onwer é também um problema ao projeto e o seu escopo. Uma fórmula que invariavelmente funciona é de um PO que centraliza ideias dos envolvidos;
• A escassez de recursos: esse é um dos grandes problemas do Gerente de Projetos, lidar com recursos limitados ou concorrentes entre projetos. A arte do gerenciamento de projetos é mensurar o tempo para esses casos, e ainda atender a expectativa dos envolvidos. É uma arte, inegavelmente;
• A saída voluntária de pessoas: aumento da pressão, a insatisfação, a não percepção de valor, a sensação de que aquela obra não é dele, como diria Mario Cortella, desmotiva o indivíduo;
• Indefinição entre as partes do que é ou não escopo: ausência de uma definição formal do escopo e não-escopo. Tarefa do Gerente (note que existe um mix entre termos do Agile e do gerenciamento de projetos tradicional, característica de alguém que flerta com os dois mundos);
• Os impactos dos riscos são maiores: projetos com problemas no escopo, tempo e/ou custo costumam reagir aos riscos de forma anormal, portanto, o planejamento de riscos deve prever uma reação aos riscos mais pessimista que em projetos em situação regular;
• Aumento da informalidade: a documentação do projeto é negligenciada por falta de tempo, diminuindo a confiabilidade desses documentos. É uma atitude desesperada que pode acarretar problemas futuros, principalmente em projetos com alterações frequentes no escopo, sem o controle das mudanças.

Após a identificação de um projeto problema o Gerente tem ao menos dois caminhos: corrigir o rumo ou terminar o projeto, afim de evitar ou minimizar a exaustão dos participantes, a redução da moral e da auto-estima da equipe, a potencialização da sensação de falta de controle, que são o reflexo de um projeto problema.

Nos próximos posts comento sobre essas duas escolhas: cancelar ou tocar em frente? Eis a questão.

Referências:

EIS Internacional. The rapid assessment and recovery of troubled projects. Disponível na Internet em http://www.projectsmart.co.uk/docs/rapid-assessment-and-recovery-of-troubled-projects.pdf. Atualizado em 2007. Acessado em 2010.

WU, Jonathan. Top 10 warning signs of a troubled BI project. Disponível na Internet em http://www.information-management.com/news/2707-1.html. Atualizado em 2000. Acessado em 2010.

VARGAS, Ricardo. Identificando e recuperando projetos problemáticos: como resgatar seu projeto do fracasso. Disponível na Internet em http://www.ricardo-vargas.com/wp-content/uploads/downloads/ricardo_vargas_identifying_recovering_troubled_projects_pt.pdf. Atualizado em 2006. Acessado em 2010.

Agile e PMBOK

    Como primeiro post, apresento uma pequena parte do artigo de conclusão da pós em Gerenciamento de Projetos, que teve como título "A Mudança em Projetos de Software". Apesar de bastante discutido, gostaria de opinar sobre esse controverso tema.

Incertezas e as consequentes mudanças no projeto são inerentes em projetos de desenvolvimento de software. Esse é um dos motivos para o surgimento das metodologias ágeis, como o Scrum, onde segundo Scott Ambler , "times de desenvolvimento de software abraçam as mudanças, aceitam a ideia de que os requisitos serão desenvolvidos durante o projeto".

Muito se ouve sobre a inadequação do formalismo do PMBOK para atender demandas de software. Por vezes, a justificativa é de que o uso de todos os 42 processos oferecidos pelo PMBOK (quarta edição). Que é robusto demais para ambientes de software. O PMBOK é um conjunto de melhores práticas, e segundo Ricardo Vargas, em mais de cem projetos trabalhados, ele nunca utilizou todos os processos idealizados pelo PMI.

Existe um grande muro de mitos criado sobre a afirmação que os dois mundos supracitados não convergem, que são incompatíveis. No entanto, diversas práticas são bastante semelhantes entre Metodologias Ágeis e o PMBOK. O ciclo de vida do PMBOK se assemelha em muito com as iterações do Scrum; ou ainda a Elaboração Progressiva do Agile segue exatamente a mesma ideia do Planejamento em Ondas Sucessivas do PMBOK.

Contudo, erra quem afirma que uma terceira via não existe. A união das melhores práticas das metodologias com o objetivo de gerar resultado. A convergência deve acontecer em busca da meta. E é com base nessa união, na tentativa de mitigar números tão absurdos de insucessos em projetos de software, absorvendo e promovendo mudanças, que deve-se quebrar paradigmas e mesclar ideias.

No Manifesto Ágil, Beck (2008) preconiza: "Software em Funcionamento mais que documentação abrangente". Conforme o próprio manifesto, existe valor na documentação, no entanto, a maior atenção é dada ao software em funcionamento. Além disso, "Responder a mudanças mais que seguir um plano", mostra que para dar suporte às mudanças devemos estar preparados para elas, ou seja, a mudança deve estar presente no planejamento.

Início

Foi dado início a uma das metas pessoais para 2010: "blogar".

Senti falta de um meio para guardar e trocar ideias sobre temas do meu cotidiano, como Gerenciamento de Projetos, Liderança, Tecnologia, Cinema e Literatura. Essas foram as principais motivações.

Espero que seja útil para você e que proporcione boas discussões para a construção de um conteúdo com valor.

Seja bem vindo e volte sempre.