O manual dos nuncas de Max Gehringer

Estamos de volta!

Achei muito bom o podcast do Max Gehringer sobre gerência de projetos e decidi fazer comentários a respeito (quem sou eu rsrsrsrs).

A história narrada era mais ou menos assim:

Uma empresa com muitos projetos mas a maioria não dava resultados. Certo dia decidiram availar o porquê. Dentre as principais razão estavam:
- As pessoas envolvidas mudavam muito de opnião;
- As pessoas se omitiam;
- As pessoas estavam mais interessadas em discutir com outros membros da equipe.
Diante disso um problema claro de liderança foi identificado, decidiram nomear um lider para cada equipe e elaboraram o manual do nunca.

1. Nunca peça exatamente a mesma coisa para duas pessoas

Isto parece óbvio, mas na prática acaba acontecendo. Duas pessoas podem ter entendimentos diferentes sobre a cerca da mesma atividade e isto pode gerar impasses, ou mesmo a execução incorreta de atividades.

2. Nunca acredite que uma pessoa que estudou mais que a outra sabe mais que a outra

Isto é um dos preconceitos que vez ou outra podemos nos deixar seduzir. Em minha opinião o que o autor quis dizer é: questione sempre se a pessoa escolhida é realmente a melhor opção para realizar aquela tarefa, averigúe, observe o que diz o histórico daquela pessoa.

3. Nunca de uma tarefa urgentíssima para um funcionário que sempre tem tempo livre de para um que esteja super ocupado

Novamente aqui vai a minha visão: desconfie do funcionário que sempre tem tempo livre no tocante ao comprometimento. Pra mim, desconfiar significa estar sempre atento. Neste caso, acredito eu, o comprometimento é que é a palavra chave.

4. Nunca acredite que um problema já atingiu seu ponto Máximo. Tudo sempre pode piorar

Isto pode parecer exagero, mas é bom estar vigilante. Problemas em projetos podem ser um poço sem fundo. Nunca é demais se cercar de medidas para resolver problemas e para monitorar de perto

5. Nunca acredite na opinião de quem não pode tomar a decisão

Aqui não se trata de não ser sincero pura e simplesmente. A questão é: quem não tem o ônus de tomar decisão dá uma opinião “não comprometida com o projeto”, ou seja, não alinhada com os objetivos do projeto. É comum ver gente dando opiniões nas quais eles acreditam ser o melhor tecnicamente, mas não estão alinhados com os objetivos do projeto

6. Nunca delegue coisas que depois só você terá que explicar

Essa é uma das afirmativas que concordo em gênero, número e grau. Esta é bem direta e realmente é NUNCA. Quando se trata de colocar sua pele em jogo você delegaria a responsabilidade? Aquilo que você terá explicar caso dê errado jamais pode ser delegado.

7. Nunca tente convencer se você pode mandar

Esta pra mim é uma das mais controversas. Confesso que me chocou um pouco, pois sou favorável a sempre tentar convencer antes de mandar. Ou seja, usar sempre o convencimento como primeira alternativa. Acredito que isto ajuda a manter a equipe motivada. No entanto, tenho que concordar que mandar deixa as coisas mais rápidas. Para quem pensa assim a questão é saber se você tem ou não o poder de mandar. Já para quem pensa como eu (primeiro tentar o convencimento depois dar ordens) a questão é saber quando já se gastou tempo demais tentando convencer e que a hora é de decisão.

Estimando Prazos para o projeto

Um cuidado que devemos ter é ao estimar prazos ou ao pedir que o façam é que temos que ter em mente que estimativas são aproximações e não uma medida precisa. Esta consciência deve ser tanto da equipe de projeto quanto dos clientes.
Mesmo sabendo que os prazos num projeto são aproximados é natural que as pessoas ao serem indagadas para fornecer tempo para execução de uma tarefa embutam neles uma margem de segurança, uma vez que temos intrinsecamente a idéia de que isto gera um compromisso. Agora imagine que cada pessoa dentro da hierarquia de uma equipe de projeto coloque sua margem de segurança. Tomemos como exemplo uma equipe apenas com dois níveis, desenvolvedores e gerente. O desenvolvedor acha que pode terminar a tarefa em 10h mas, por "segurança" passa para o gerente que deve levar umas 13 h este por sua vez no momento de elaborar o cronograma coloca a tarefa com duração de 15 h. Só aí temos um acréscimo de 50% no tempo da tarefa.
Por esse ponto de vista a maior parte das tarefas de um projeto deveriam terminar ou antes ou muito próxima do prazo. Mas isnto não é o que acontece na maiora dos casos.
Isto ocorre segundo a lei de Parkinson que diz que o trabalho se expande para preencher todo o seu tempo disponível para ser concluído.

Como Evitar?

A técnica do XP de ter o cliente sempre disponível nos ajudou a resolver o primeiro problema, que era fazer o cliente enxergar estimativa como algo aproximado. É claro que não basta ter apenas o cliente por perto, e sim de construir um relacionamento de confiança. Quando uma atividade atrasava o cliente era informado (detalhadamente) através de reuniões periódicas.
Da mesma maneira, evitar a "gordura extra" depende de um bom relacionaemento com a equipe de desenvolvimento. Os desenvolvedores precisam ter tempo razoável para realizar as estimativas e precisam saber que o gerente não os irá "chicotear"caso uma estimativa dada não se confirme. Em todos os nossos encontros para estimar prazos gostava sempre de enfatizar que me passassem o prazo real. É claro que sempre comparava os tempos estimados anteriormente para tarefas semelhantes com os tempos passados para a nova tarefa.
Em resumos os princípios de nossa forma de estimar prazos foram:

• Construir confiança do cliente;
• conscientizar que estimativas são aproximações minimizando as gordurinhas nos prazos;
• sempre fazer a comparação com estimativas anteriores

____________________________________________________________________

Denial of Service- O gerente é um multitarefa por natureza

Não é raro, independente da área de atuação, ser atropelado por um volume grande de atividades, todas aparentemente com a mesma prioridade. No entanto, esta parece ser uma coisa pra lá de rotineira na área de gerência em TI.
Quando iniciei gerenciando projetos vivi na pele essa avalanche de tarefas. O meu primeiro projeto como gerente a quantidade de tarefas era bem superior ao meu número de horas no dia, todas com a máxima urgência. Isto pode facilmente conduzir qualquer gerente novato ao stress, ou melhor, como costumava chamar ao Denial-Of-Service. Isto porque chega a um ponto que se não tomarmos cuidado acabamos por não concluir tarefa alguma a contento. Ou seja, pode-se comprometer bastante o cronograma de um projeto se não soubermos como lidar com uma demanda excessiva.

Como superei

A primeira coisa a se fazer é manter a calma. Falado assim isto parece simples, mas na verdade não é. Como gerente, somos responsáveis pelo bom andamento do projeto e queremos,naturalmente, resolver os problemas da maneira mais rápida possível. Isso pode acabar levando a uma produtividade baixa (pelo menos foi o que aconteceu comigo durante um tempo).
Uma vez calmo, a segunda coisa a fazer é pensar com frieza em qual dos problemas que quando resolvido trará maior ganho num menor espaço de tempo. Ou seja, tempos que priorizar atividades segundo os critérios de retorno para o projeto (levando em conta o tempo para obtê-lo). Trata-se do bom e velho "atacar um problema por vez".
Vale lembrar que é sempre bom considerar que algumas atividades podem ser delegadas. É sempre por fazer-se essa indagação, pois quando iniciamos na atividade de gerência muitas vezes queremos resolver tudo sozinho. Mas isso já é assunto para outro Post.

Até Breve