O Gerente precisa entender bem de programação??

Esta pergunta foi feita num comentário do último post. É uma pergunta recorrente, mas que sempre rende muita discussão.
Não acredito que para ser um bom gerente de TI precise necessariamente ser um expert em programação. Diga-se de passagem, esta idéia se aplica não só a TI mas a outros ramos também.
Um gerente que não tenha conhecimentos avançados de informática pode conduzir um projeto na área de TI. Claro que para isso terá que se apoiar (confiar) em membros do time que possuam conhecimento para realizar determinadas atividades (que exigem conhecimento técnico específico). Aí é onde residem algumas das habilidades requeridas para um bom Gerente: identificar as potencialidades de sua equipe, fazer com que estes potenciais sejam aproveitados de maneira mais eficaz, por exemplo.
A um dito popular na área que diz: o importante não é saber mas sim, saber o telefone de quem sabe.

Não estou aqui desprezando o conhecimento adquirido ao longo de uma vida por muitos gerentes. Muitos deles constroem uma carreira passando por programação, passando por análise e se tornam gerentes. Acredito que o conhecimento em programação, análise, arquitetura, etc. ajuda muito ao gerente a exercer seu papel. Pra começar o gerente falará a mesma língua diminuindo assim a chance de haver mal entendidos (comunicação não é tudo, mas é 100%.).
Conhecendo programação, por exemplo, o gerente poderá, caso deseje, contestar determinados prazos dados por seus desenvolvedores. Questionar também a solução apresentada. Aqui cabe um alerta: Há que se ter muito cuidado para não investir muito tempo em tarefas que não são suas enquanto gerente. Ou seja, o Gerente gerencia, o programador programa e assim por diante.
Outra vantagem é que o conhecimento técnico ajudará a tomar a decisão de quem confiar para delegar atividades importantes.


Até Breve

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.

Tomada de decisão

Tomada de decisão, eis aqui uma coisa com a qual, se já não estamos habituados, teremos dificuldade ao entrar na área de gerência. Acontece que no cotidiano lidamos com tomada de decisão, mas nem sempre utilizamos técnicas para fazê-lo. Na realidade na maioria dos casos tomamos decisões de forma empírica ou simplesmente nos deixamos levar. Quando se está à frente de um projeto isto não pode ocorrer.
Outro fator que está presente em um projeto e que geralmente é inimigo da boa tomada de decisão é o tempo. O gerente novato pode se sentir bastante inseguro para tomar alguma decisão de impacto para o projeto. Ou mesmo pode levar tempo demasiado para reagir o que significa atraso para o projeto.

A tomada de decisão geralmente está associada a um risco para o projeto. Ou melhor, a tomada de decisão consiste em adotar a alternativa que representa menor risco para o projeto. Ou ainda, tomada de decisão visa sempre minimizar os riscos (negativos) de um projeto.

O PMBOK estabelece um área para a gerência de riscos e para ela quatro processos:

1. Identificação dos riscos;
2. Quantificação dos riscos;
3. Desenvolvimento das respostas e
   
4. Controle das respostas
   

Na minha opinião, o processo com maior grau de dificuldade é a quantificação dos riscos pois se soubéssemos quantificar exatamente cada risco, ficaria mais fácil combatê-los e optar pela resposta correta. O problema é que essa análise apesar de poder ser quantitativa geralmente tem seu maior peso no aspecto qualitativo. Ou seja, geralmente não temos números exatos pra decidir.

Como Evitar

Alguém disse uma certa vez (acho que foi Maquiável, não estou bem certo) que: "A decisão lastreia-se na informação, mas brota da sabedoria". Daí podemos dizer que para tomar decisão é necessário informação, boa informação e da maneira mas rápida que pudermos obter. Porém só a informação não basta tem que haver sabedoria o que nos tempos de hoje chamamos de experiência. Sim, acho que só com o tempo e o aprendizado é que se aprimora a tomada de decisão.
Em termos práticos, caso são possua a informação suficiente, procure-a, consulte quem saiba (a boa e velha opinião do especialista). Se dispuser de tempo, investigue através de protótipos (spike solutions, por exemplo). Outra técnica que ajuda é a da árvore de decisão.
Há também algumas ferramentas disponíveis para quantificar e analisar riscos:

• @Risk - www.palisade.com
  
• Risk+ -www.projectgear .com
• Primavera´s Mont Carlo - www.primavera.com

É preciso ter em mente algumas coisas :

• Nunca despreze toda e qualquer informação que possa ser útil
• Documente sempre o porquê de se tomar determinada decisão
  
• Controle se a resposta ao risco (decisão tomada) está sendo satisfatória
• Não tenha vergonha de voltar atrás caso perceba que tomou alguma decisão errada (antes tarde do que nunca)
• Uma decisão rápida vale mais do que uma indefinição muito longa
• Não chore o leite derramado, se tomou a decisão errada trate de aprender com ela, isto é faz parte do processo de ganhar experiência.
  

Boa sorte e mãos a obra. Até Breve!
____________________________________________________________________

Comunicação- Parte II-Reuniões

Dada a importância que tem está área decidir me aprofundar mais um pouco em alguns detalhes. Neste post tratarei da comunicação interna seus problemas e alternativas para contorná-los.
Uma boa prática mas que se não for bem aplicada toma um tempo enorme num projeto são as reuniões com as equipes e com os clientes. Essas reuniões quando não são bem planejadas e conduzidas tendem a se tornar longas e enfadonhas. Uma tentativa que fizemos foi o de fazer reuniões a cada 15 dias (nossa iteração) nessas reuniões eram repassados todas a metas atingidas, o problemas, as soluções encontradas dentre outras informações. O problema com está abordagem foi que além de acumular muitos assuntos alguns problemas descobertos no início da iteração esperavam até o fim para serem resolvidos.

Como superei?

De início as reuniões passaram a ser semanais, depois passaram a ser diárias mas ainda sem um planejamento. Isso mesmo, por menores que sejam as reuniões, elas precisam acontecer com o mínimo de planejamento. Para isso recorremos ao SCRUM que define as seguintes regras para as reuniões diárias : (tradução nossa)

• Devem ser diárias;
• Devem acontecer no mesmo local e no mesmo horário todos os dias;
• Não devem durar mais de 30 minutos (no nosso caso adotamos 15 min com 5 min de tolerância); Uma dica neste caso é usar o celular para alarmar a cada cinco minutos.
  
• O SCRUM master é apontado (no nosso caso o próprio gerente do projeto)
• o Scrum Master é responsável por perguntar a todos da equipe
• O que você fez desde a última reunião?
• Quais foram as dificuldades na execução de sua tarefa?
• O que você pretende fazer de agora até a próxima reunião?
• A conversa só é permitida para responder as 3 perguntas acima;
• Reuniões podem ser estabelecidas para logo após essa reunião; (geralmente estas reuniões servem para que alguns membros da equipe possam debater mais detalhadamente sobre problemas e/ou soluções)
• O Scrum master é responsável por tomar decisões imediatas para romover impedimentos a resolução de problemas;

Vale ressaltar que é preciso de muita disciplina para que estas regras sejam seguidas. A atitude do gerente nestas reuniões é decisiva, muitas vezes sendo um pouco chato.
É preciso evitar que estas reuniões se tornem encontros para colocar a conversa em dia, fazer lanches, conversar sobre futebol, fim de semana, etc. (armadilhas scrum)

Mesmo com as reuniões diárias outras reuniões eram necessárias e as vezes mais longas. Nestes encontros algumas regras gerais foram aplicadas:

• Fazer reuniões apenas quando necessário;
• Comunicação com antecedência da pauta da reunião e inclusive di tempo de duração;
• Tempo de duração não superior a 2 horas;
• O número de participantes deve ser tão enxuto quanto possível;
• Toda reunião deve ter no mínimo um relator/secretário e um gerente
  
• Reuniões devem sair com todo lists e definições;
• Caso ache necessário elabore ata (prática, resumida, apenas com o essenncial); Template de ata de reunião
  

Até a próxima !