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 !

Comunicação- Parte I

Essa foi umas das áreas de gerência de projeto que mais negligenciei no início. Confesso que não dei muita importância (participar de reuniões, conversar com os envolvidos ? Isso não é trabalhar, pensava eu).Isto aconteceu logo num projeto no qual parte dos envolvidos estava em locais geograficamente distantes. Como dizia o velho guerreiro: "Quem não se comunica se trumbica".
O resultado vocês já podem imaginar: a falta de comunicação ou a má qualidade da mesma tende a bagunçar muito projeto. Os sintomas são muitos, dentre os quais vivi alguns:

• retrabalho- quando a comunicação falha fatalmente uma tarefa tem que ser corrigida, ou seja, refeita;
• Erros no projeto- se a falha não for percebida a entrega do projeto poderá conter falhas
• Desvios de escopo- se descobertos em tempo acarretam em elevação de custos, insatisfação, alterações de prazo. Caso sejam descobertos tardiamente, as conseqüências são bem mais danosas;

Uma pesquisa da empresa norte-americana de treinamento Vital Smarts aponta que por causa da falta de comunicação 82% estouram os prazos e 79% não conseguem atender as especificações de qualidade. Mais info.
Acredito que quanto maior o número de envolvidos no projeto e quão maior for a distância entre eles mais tempo o gerente terá que dedicar a esta área. Em nossa experiência a comunicação era dividida basicamente em três categorias de acordo com os envolvidos: superiores, clientes, parceiros (externos a equipe) e colaboradores (interna a equipe).

Como superei?

Felizmente esta foi uma necessidade tão forte que rapidamente percebemos a importância de nos comunicarmos bem. Tivemos dar uma pequena pausa, recorrer a literatura (PMBOK e algumas práticas de gerência de projetos ágeis) elaborar um plano de comunicação e passar a segui-lo e reavaliá-lo constantemente. A seguir algumas das principais práticas/técnicas que utilizamos:

• Reuniões diárias com a equipe (Segundo SCRUM);
• Escuta ativa;
• Criação e divulgação da forma de comunicação;
• Fazer e divulgar lista de contato dos envolvidos;
• Construir e manter site do projeto (com mínimo de overhead sobre o projeto em si);
• Uso teleconferências;
• O cliente como parte da equipe (prática abraçada pelo XP)

O assunto comunicação é vasto e certamente voltarei a falar dele detalhando um pouco mais

Até breve!

Delegar tarefas

Uma das armadilhas com a qual me deparei durante o primeiro projeto como gerente foi a de tentar fazer de um tudo. Isto mesmo, no início tive dificuldade de me afastar do desenvolvimento em si. Acredito que isso acontecia parte por conta da equipe reduzida que tínhamos e parte pela inércia, ou seja, estava habituado a desenvolver (codificação, projeto e análise) "fiz isso durante muito tempo em minha carreira, era o que eu sabia fazer melhor".
Este problema atrapalhou o bom andamento do projeto durante alguns meses. Foi duro até eu aprender a delegar tarefas. Pode parecer óbvio, afinal de contas a distribuição de tarefas é uma das atribuições básicas do gerente de projeto. Pois bem, não que fizesse isso todos os dias, mas constantemente me pegava fazendo tarefas que deveria confiar a alguém.

Como superei?

Bem, neste caso acho que a gerência a qual eu estava subordinado contribuiu para isso, insistindo, orientando e cobrando que eu exercesse minhas atividades de gerência. A pessoa que controlava o meu trabalho constantemente me cobrava por cronogramas, status do projeto etc. sendo assim tinha cada vez mais que delegar atividades para poder me dedicar as tarefas de gerente.
Outro componente foi o tempo, a prática das atividades de gerência me fez perceber a importância de distribuir responsabilidades.

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

O Início - A Mudança- O mito de que o gerente não faz nada

Como primeira postagem, escolhi voltar um pouco no tempo e lembrar da primeira vez que fui escolhido para gerenciar um projeto. Eu que sempre gostei de desenvolver (codificar e fazer análise) por força da circunstância me vi obrigado a gerenciar um projeto de software.
Como preparação, alguns cursos (PMBOK) e uma boa dose de pesquisa na Web me foram indispensáveis.
A seguir comentarei sobre as primeiras dificuldades (desafios), começando pelo que chamo de

O mito de que o gerente não faz nada.


Como desenvolvedores tendemos a acreditar que nós fazemos todo o trabalho e por conta disso sofremos a maior pressão quase todo o tempo. Quando passamos de desenvolvedor para gerente um dos sentimentos preponderantes (geralmente ao final do dia) é o de que não produzimos nada, ou seja, nenhum código "brotando de nossas mãos". A sensação é estranha e é preciso de certo esforço e tempo para convencer-se que o seu trabalho "tem algum valor".
Acredito eu que pela natureza distinta dos trabalhos (Desenvolvedor X Gerente) acabamos com a sensação de improdutividade. Isto é, ao invés de ver, aos poucos o código ganhando vida, agora temos que participar de um número bem maior de reuniões, resolver problemas de relacionamento na equipe (picuinhas), cobrar prazos, atualizar cronogramas etc. Raros não foram os dias em que me via como um mero resolvedor de "probleminhas".

Como superei?
Bom, para superar está terrível sensação três fatores foram essenciais:

• passar a enxergar as novas atividades como desafio;
• saber que um bom gerente tem como uma de suas funções servir a sua equipe para que se possa atingir um fim;
• tempo;
  

O gerente noviço precisa se comprometer com as suas novas tarefas e acreditar que elas são importantes para o bom andamento dos trabalhos, por isso enxerga-las como desafio ajuda muito.
Se ver como um servidor de sua equipe é um dos pontos chaves, ou seja, como gerentes acabamos nos importando mais com o bem estar geral de nossa equipe do que com o nosso, passamos a ver qualquer obstáculo ao bom andamento das atividades como nosso inimigo.
O tempo, ou seja, a experiência faz com que se "tome gosto" pelas atividades de gerência. De outra forma podemos dizer que se os dois primeiros fatores forem observados é questão de tempo para que a sensação desagradável de improdutividade desapareça.


E aí? Alguém mais já passou por algo parecido?

Boas vindas

Oi pessoal,

Como boa parte dos profissionais que trabalham com gerência de informática comecei como programador , passei a analista , depois gerente de projeto e hoje ocupo um cargo de gerência de sistemas. Bem como grande parte das pessoas, eu NÃO nasci gerente e estou tendo que me adaptar.

Decidi criar este blog no intuito de compartilhar idéias para os que passam ou ainda vão passar por situações parecidas na área de gerência de TI, bem como pessoas interessadas no assunto. Abordaremos, principalmente, relatos de casos vividos, problemas e suas soluções. Sintam-se à vontade fazer críticas e compartilhar opiniões.

Espero que ajude.