Dicas para ajudar você a gerenciar a competição de propriedades dos projetos

Imagine que você está gerenciando o Projeto A e o Projeto B, e as prioridades da organização mudam. Agora o Projeto B tem que ser entregue dois meses antes do previsto, e o projeto A ainda tem que ser mantido dentro do cronograma.

Talvez uma legislação aprovada recentemente traga impactos ao seu projeto, ou, talvez, quando o projeto for fechado, você e todos os membros da equipe são designados para outros projetos e a reunião de lições aprendidas torna-se uma baixa prioridade.

Estes poucos exemplos demonstram o desafio que você enfrenta quando gerencia múltiplas prioridades. Uma Competição por recursos, riscos e mudança nas prioridades da empresa são elementos comuns aos projetos e exigem que o Gerente de Projeto manipule prioridades, as vezes contraditórias, das partes interessadas e das organizações.

Considerações sobre a Gestão de Prioridades concorrentes

Independentemente do estilo ou experiência, existema ações que podem lhe ajudar a otimizar as suas chances de sucesso quando seus projetos estão competindo por recursos. A medida que você ganha experiência, essas considerações são absorvidas naturalmente.

• Não entre em pânico. Dependendo do seu nível de experiência, o pânico pode ser a sua reação emocional quando confrontado com um desafio durante a execução de um projeto. Tire algum tempo para reunir todos os fatos e dados sobre a situação. Será mais provável que você encontre uma solução viável.
• Não perca seu foco. Revise seu termo de abertura e documentos, escopo e objetivos, assim você terá uma base para avançar com confiança, mesmo que seu escopo do projeto ou a data de entrega possa ter mudado.
• Não deixe o seu ego ficar no caminho. Se o projeto está em risco de ser cancelado ou colocado em segundo plano, não tome isso como pessoal. Isso faz parte do trabalho e de trabalhar para uma organização. Orgulhe-se do que você tem feito e em ser um membro da equipe. Outras oportunidades virão ao seu momento.
• Lembre-se do todo. Avalie a situação de uma organização, bem como a perspectiva do projeto. Isso irá ajudá-lo a chegar a soluções que estão no melhor interesse da organização, enquanto move o projeto adiante.
• Lembre-se das suas histórias de sucesso e das dos outros membros do time. Isso irá ajudá-lo a construir a confiança, auxiliando, assim, você a encontrar uma solução viável para o seu desafio atual.
• Utilize seus próprios processos para o projeto e programa. Confie na sua governança, controle de mudanças e processos de gestão de risco. Estas são as suas ferramentas e sistema de controle, os que são estratégicos para o êxito de qualquer projeto.
• Comunique-se, comunique-se, comunique-se. As partes interessadas e da administração devem ser parte da solução e devem estar informadas sobre o resultado. Siga as linhas formais de comunicação, conforme descrito no seu plano de comunicação e as linhas informais de comunicação, para garantir uma solução no tempo certo e sucesso do projeto.

Autora: Lynn Wendt, PMP, PgMP

Fonte: PMI.org

ITIL Gerenciamento de Problemas: A versão de TI de CSI

Em ITIL (Information Technology Infrastructure Library), o processo que é mais exigente em termos de alcançar o sucesso de entrega é de gerenciamento de problemas. O resultado deste processo não é simples como alguns dos outros que eu tenho discutido até agora. As atividades realizadas aqui envolvem a investigar o problema na mão, encontrar o culpado e meting uma decisão para resolver o problema.

Isso soa muito como o Crime Scene Investigation (CSI) revela que vemos na televisão, que envolve muita investigação, seguindo as pistas e precisão pino apontando o responsável. Meu favorito pessoal é a versão de Miami.

O perito que vemos na televisão é encenado e na versão real da investigação forense leva vários dias e meses para alcançar o sucesso razoável. Os temas são pessoas reais, evidências deixadas para trás durante o ato informação de fundo, e conexões. Em TI forma de CSI – gerenciamento de problemas, as investigações são muito semelhantes. Trata-se de investigar e sondar os técnicos envolvidos, estudando os arquivos de log e da história da infra-estrutura em causa e da análise minuciosa da arquitetura para os possíveis problemas relacionados. Você não sente gestão problema poderia ser divertido? Definitivamente, eu comecei minha carreira fazendo gestão de problemas pelo caminho.

O que é considerado um problema?

“Problema” é uma linguagem comum para as pessoas em toda as profissões e as sociedades. Em TI, é preciso ter cuidado quando usamos este termo como ele carrega muito peso. Um “problema” em ITIL refere-se a um incidente do qual não sabemos a causa raiz ou ainda uma questão que é de natureza repetitiva, sem solução à vista.

A definição oficial, conforme definido pelo ITIL é:

A causa raiz desconhecida de um ou mais incidentes existentes ou potenciais. Problemas podem às vezes ser identificado por causa de vários incidentes que apresentam sintomas comuns. Problemas também podem ser identificados a partir de um único incidente significativo, indicativo de um único erro, para que a causa é desconhecida. Ocasionalmente, problemas serão identificados bem antes de qualquer incidente relacionado ocorrer.

Vamos dar um exemplo. Você está usando o MS Outlook 2007 e quando você tenta abri-lo, o Windows gera uma mensagem de erro e, aparentemente, você não pode abrir o aplicativo. Bem, este é um incidente. O técnico olha para o seu sistema e não pode identificar o culpado e decide desinstalar e reinstalar o software, não vá. A questão ressurge, mesmo depois de reinstalar. Neste caso, a causa é desconhecida e, portanto, o Outlook 2007 problema pode ser denominado como um problema.

O técnico aumenta o problema para o próximo nível de suporte. Quanto maior o técnico qualificado olha para o seu sistema, lê-se através de várias páginas de documentação, refere-se a bases de conhecimento e encontra a solução para o problema. Ele imediatamente vai para o registro e muda um parâmetro que estava em conflito com o MS Outlook 2007, e voila que corrige o problema. O incidente foi resolvido e agora o problema, cuja causa raiz é estabelecido, torna-se um erro conhecido.

Solução alternativa temporária e permanente

Soluções Temporária e Permanente soluções são as duas variedades de correções de encontrar no mundo da TI. Enquanto ambos não podem e não existem mutuamente, elas são usadas em justaposição, mas não simultaneamente.

Uma solução temporária é uma correção que é fornecida a um problema na mão, mas a correção fornecida não é permanente. Se o MS Word no seu PC não está funcionando, o download do Open Office e, em vez de usá-lo é uma solução, mas é em nenhum sentido, a solução é óptima. Entretanto, se você seguiu em frente e reparou MS Word utilizando as técnicas de resolução de problemas necessárias e interposição do recurso de volta à vida, que poderia ser mais ou menos, ser considerada uma solução permanente.

Observe que quando você teve seu reparo provisório no local, você pode começar o trabalho feito, mas não exatamente da maneira / significa que se destina. Ela serviu apenas o propósito de obter-lhe através de momento. Quando você optou por uma solução permanente, você não precisa mais de uma solução temporária, embora possa ainda existir no sistema.

Uma solução temporária é geralmente uma saída de gerenciamento de incidentes, enquanto solução permanente é sempre o objetivo do gerenciamento de problemas, embora eu não iria no registro indicando que tudo o que sai da gestão do problema é de natureza permanente.

Análise de Causa Raiz (RCA)

O Root Cause Analysis (RCA) é um documento / relatório que é resultado de gerenciamento de problemas. O objetivo deste documento é estabelecer a causa raiz do problema e encontrar uma solução permanente.

A RCA típicas listas com os detalhes do problema, tais como a natureza da interrupção, prazo, as regiões afetadas, entre outros fatos. Além disso, teria uma seção inteira dedicada à descoberta da causa e as medidas tomadas para resolvê-lo. Finalmente, uma medida preventiva para garantir a questão não aconteça novamente é recomendado.

Aqui estão algumas amostras RCA .

Para encontrar a causa de um problema, existem várias técnicas de problema de gestão em vigor. O mais simples e, possivelmente, a técnica mais comumente utilizada é a 5 por análise. Basta fazer a pergunta ‘por que’ cinco vezes consecutivas. Deixe-me ilustrar com um exemplo.

Vamos dizer que o teclado que é conectado ao seu PC não está funcionando. Aqui estão as perguntas e as respostas que eu colocaria para chegar a causa raiz.

1. Porque é que o teclado está funcionando? Windows 7 não reconhecê-lo.
2. Por que o Windows 7 não reconhece o teclado? Driver é corrupto.
3. Porque é que o driver corrompido? Maggie tentou instalar o seu teclado sem fio no PC. Ela instalou os drivers do teclado sem fio para este PC.

Aqui você vai. Driver conflito é a causa raiz desse problema. Você realmente não tem que ir até perguntando “porquê” cinco vezes. Faça isso quantas vezes for possível obter uma resposta lógica e utilizável. Geralmente você vai chegar à causa raiz na quinta porquê.

Funções de Gerenciamento de Problemas

Existem basicamente duas funções na indústria de TI para as pessoas que trabalham com gerenciamento de problemas. Um gerente problema é quem está no comando de todo o processo final de gerenciamento de problemas até o fim. Ele toma posse de todos os problemas que vêm em e é sua a responsabilidade de entregar RCAs no tempo. Um problema de relatórios coordenador de um gerente de problema. Um coordenador, basicamente, coordenadas entre as diferentes equipes técnicas para obter as informações necessárias para desenvolver a RCA e executa tarefas de controle de documentos, juntamente com rastreamento e monitoramento de problemas em aberto.

Na indústria de TI, cargo de gerente de problema é considerado um dos melhores papéis de contribuinte individual. Um especialista em ITIL, que conhece os processos muito profundamente quem está confiada esta tarefa. Eu trabalhei como coordenador problema inicialmente e depois como gerente de alguns anos atrás, ea experiência tem catapultou-me em uma posição mais elevada hoje. O trabalho era duro, e não para o trabalho que eu tinha que fazer, mas para as expectativas que eu precisava para gerir. No meu papel de presente, eu tenho quatro gerentes problema de comunicação dentro de mim, e eu olhar para eles para fornecer a perícia técnica é necessária para gerenciar a minha entrega. Digo isto para sublinhar a importância dos gestores problema em uma organização. Se seu gerente de problema é bom, sua empresa pode certamente dar um suspiro de alívio.

Conclusão

Tudo o que eu mencionei neste post é talvez uma pequena fração do problema da área de gestão do conhecimento. O campo é tão vasto, que nenhum livro que eu li até agora cobre completamente. É o mais definitivamente dar-lhe a satisfação de fazer algo completamente novo a cada dia, e mantém os seus sentidos à distância, observando por pistas que você desrosqueie os mistérios por trás da infraestrutura de TI.

Sua empresa sabe o custo da TI?

Com um melhor entendimento das despesas, é possível acalmar executivos com avançados conhecimentos. Muito mais do que com a apresentação de custo final.

Por anos, as áreas de TI lutaram com a definição exata dos custos individuais de serviços e aplicativos. Agora, com orçamentos apertados e demandas por corte de custos, os CIOs ajustam o foco em custos isolados.

Essa necessidade por definir os custos específicos deu origem a uma série de software para gestão financeira que auxilia CIOs a definir o real custo dos elementos da estrutura. A presença das soluções em nuvem, seja em armazenamento ou no fornecimento de software e/ou infraestrutura, ajuda a aumentar a pressão sobre a folha da TI.

“No passado, não tínhamos muita noção sobre os custos e era melhor assim, para não causar alarde entre os acionistas”, diz Barbara Gomolski, diretora vice-presidente do instituto de pesquisas Gartner. “Agora, se não pudermos apresentar a toque de caixa esses custos, damos o direito aos acionistas de irem ao mercado e comentar sobre o preço de determinadas soluções.”

Barbara faz diversas considerações sobre essa realidade. “Com um melhor entendimento das despesas, as áreas de TI podem acalmar executivos com avançados conhecimentos técnicos que querem saber mais do que simplesmente o custo final dos desktops”, por exemplo.

A gestão atual quer saber quanto custa manter um colaborador online quando em deslocamento e quer esses dados com detalhes. Ela irá perguntar sobre modelos de custo e quais soluções estão incluídas. Será apenas o hardware sem as tarifas de conexão e/ou manutenção?”, diz.

Investimentos com fundamento

Em geral, essa mudança de comportamento é positiva para todo o segmento de TI. “Significa que as TIs estão, finalmente, acordando”, comemora Barbara. “Ajuda as áreas de TI a definir se devem ou não insistir em determinadas tecnologias e se existem soluções com baixo aproveitamento ou que possam ser otimizadas”, afirma a executiva. Todavia, chegar a uma planilha de custos detalhada em TI não é coisa fácil de fazer.

Iniciantes no segmento de gestão de TI devem prestar atenção em técnicas de composição de orçamentos e em planejamento. Ajustar orçamentos em pleno andamento também deve passar a ser uma atividade corriqueira. Nesse quesito, aliás, existem diversas soluções que as áreas de TI vão adorar usar.

“Quando um CIO diz ao gerente de armazenamento online que esse deve projetar a demanda por espaço para o próximo semestre, esse profissional irá imediatamente se voltar a um programa que resolva tal cálculo”, afirma o presidente e CEO da Digital FUEL, Yisrael Dancziger.

As ferramentas desenvolvidas para consolidar as métricas financeiras da TI exercem várias funções, entre elas está o ajuste orçamentário, projeção de custos e gestão de fornecedores. Elas existem no mercado desde 2000, mas, imaturas, só ganharam em importância agora. “No estágio atual de desenvolvimento”, diz Barbara.  “Essas ferramentas oferecem um panorama mais consistente”, completa.

Opulência de planilhas

Em várias organizações, software de gestão financeira para TI são um substituto para a gama de planilhas que circulava na empresa. Os programas fazem o trabalho pesado de recolher os custos e outros detalhes das bases de aplicativos – estejam esses em formato estruturado ou não. Relatórios padronizados transformam o processo de confrontar custos com reais benefícios.

Bem configuradas e alimentadas com as informações necessárias, as planilhas conseguem, inclusive, projetar diferenças do custo em situações hipotéticas como em estudos de substituição das máquinas Windows por sistemas Linux com suporte 24/7 e devolver dados sobre o desempenho x investimento por hora de disponibilidade. Tais dados auxiliam a TI a construir melhores relatórios de custos e a conferir transparência aos processos.

“A questão vai além de simples informações sobre custos”, adiciona Jeff Day, diretor de marketing da Apptio. “Trata-se de construir um orçamento, realizar projeções e de otimizar os investimentos. É, literalmente, colocar as mãos na massa para ajudar o CIO a gerir a TI.”

As soluções de gestão financeira para as áreas de TI também auxiliam os usuários a identificar segmentos em que podem reduzir os custos, descobrir servidores que poderiam rodar de forma consolidada em outro sistema ou candidatos à virtualização; revelar a propensão de determinados aplicativos a serem aposentados e dados prontos para armazenamento em dispositivos de backup e sinalizar contratos em fase de expiração e a necessidade de renovar esses acordos.

http://computerworld.uol.com.br/gestao/2011/01/28/sua-empresa-sabe-o-custo-da-ti/

Gestão de Serviços de TIC

A gestão de serviços de TIC é um conjunto de disciplinas que oferece o serviço certo a um custo certo, dentro de níveis de qualidade e prazos que atendam as expectativas dos negócios. Gestão de Serviços é uma área emergente e mal entendida por muitas pessoas. Os líderes de TI sentem  a pressão para melhorar significativamente o desempenho do serviço, mas enfrentam uma quantidade surpreendente de informações conflitantes e incompletas. O nível de maturidade de TIC define a contribuição da organização para a empresa. Essa contribuição começa em oferecer apenas ferramentas de produtividade até a gestão da TIC como um negócio. Podemos categorizar os serviços de TIC com: utilidade; otimizado e lucrativo. Com orientação a ser um centro de custo, um provedor de serviços e uma unidade de negócios, respectivamente. Uma organização eficiente de TIC deve implantar modelos para a gestão, tais como Cobit, ITIL, PMI, CMMI e outros. Em empresas que adotaram o modelo de governança corporativa a gestão de serviços de TIC deve atender os requisitos mínimos da gestão de conformidade. O Cobit deve ser o direcionador para a definição das disciplinas que devem ser implantadas, como mostra a figura abaixo.

A importância da implantação conjunta do ITIL com a ISO 20000

O ITIL v3 é uma referência para que as empresas implantem uma estratégia de serviços que envolva gestão da demanda, valores financeiros previstos para os serviços e a inclusão deste pipeline no portfolio. Também abrange um projeto do serviço que considera aspectos importantes como continuidade, capacidade, segurança e níveis de serviços. Na sequência é realizada uma transição do serviços para a produção, incluindo os processos de ativos/configurações de serviços, mudanças, release, testes e avaliação. Quando o serviço está pronto e devidamente aprovado/testado, é realizada uma passagem para a produção. Nesta etapa, processos e funções como service desk, incidentes, eventos e acesso são utilizados. Finalmente é apresentada uma referência para melhoria contínua, considerando algumas práticas recomendadas por Deming.

Estaria tudo certo, não fosse um detalhe. Sendo o ITIL uma referência, como garantir a implantação de forma efetiva e a sua sustentação ao longo do tempo?. O problema da abordagem apresentada é que o ITIL não garante que os processos sejam realmente implementados nos seus requisitos mínimos. Deveria existir em algum local uma determinação do tipo “deve existir um plano de capacidade !!” que pudesse ser avaliada quanto à sua eficácia. Neste aspecto, a ISO 20000 pode complementar o ITIL. O Cobit v4.1, com seus processos de Delivery & Support, atua com propósito semelhante, porém focando em “o que fazer” sob a ótica do ciclo de vida da Governança de TI e não em Gestão da Qualidade de Serviços de TI. Idem para o eSCM que determina “o que fazer” sob a visão do ciclo de vida de Outsourcing. O Cobit v4.1 e o eSCM estão em um nível acima. É preciso arrumar a casa. Para isto existe a ISO 20000 que é um padrão internacional de qualidade, projetado para gerenciamento de serviços de TI (ITSM). Certifica a empresa e tem como base o ITIL v2 (apesar de sua estrutura já contemplar o ITIL v3 nos seus requisitos mínimos e importantes para ITSM). No Brasil temos 05 empresas certificadas e no mundo são mais de 380, lideradas pela Japão (60), Reino Unido (58), India (44), China (37) e Coréia (34).

Bem, estava outro dia lendo uma revista mensal de TI. Notei em uma matéria algumas opiniões de CIOs quanto à Qualidade de Serviços de TI. Eis três afirmações passíveis de debate:

“Na parte de processos internos e de infra-estrutura, desde o ano passado estamos nos adequando às melhores práticas do ITIL. Como a meta é fazer a adoção completa do ITIL, estamos certificando nove funcionários e vamos contratar outros três já certificados. Essa adequação implicará a revisão de processos e da documentação”.

“Na área de governança e arquitetura de TI, nos baseamos nas melhores práticas do Itil e do Cobit, pois precisamos estar em conformidade com a Sarbanes-Oxley. Isso já garante a qualidade das informações e dos processos.”

“Em segurança, seguimos a norma ISO 27001. Já em relação à qualidade dos serviços de TI, temos um scorecard com indicadores como disponibilidades dos sistemas e custos”

Nenhuma crítica maior para as declarações acima, com exceção de que são visões bem restritas de gestão de serviços de TI. Nota-se que o foco maior está em “fazer acontecer” ou “fazer aparecer”, sem um cuidado com o melhor método ou com uma análise. Vejamos um exemplo deste raciocínio. Um CIO ao afirmar que já possui processos ITIL implantados não garante que a implantação está seguindo os requisitos mínimos de qualidade em ITSM. A ISO 20000 é um complemento do ITIL, pois atesta que as melhores práticas em gestão de serviços de TI estão efetivamente implantadas. Garante também que os processos mínimos estão sendo seguidos. O fato de acionar uma entidade externa (ex. BV, DNV ou BSI) para auditoria dos processos de forma contínua e periódica, bem como utilização de avaliações internas (auditoria interna), garante que os processos e a qualidade de serviços de TI estão sendo seguidos. Para garantir a qualidade das avaliações, é importante que sejam conduzidas por pessoas com excelente nível de conhecimento e experiência em ITIL e em Sistemas de Qualidade.

Outro aspecto importante é que a ISO 20000 garante para o ITIL alguns complementos fundamentais, como por exemplo a responsabilidade da alta direção sobre o sistema de qualidade de serviços de TI, competência, treinamento e requisitos de documentação para a execução dos processos. Tudo isto é auditado quanto à sua eficácia. Outro aspecto fundamental é a inclusão dos processos do ciclo PDCA, incluindo auditoria, registros, evidências de não- conformidades e oportunidades de melhorias com suas respectivas ações preventivas e corretivas. Processos importantes de relacionamento com o cliente (incluindo gestão de reclamações) e de gestão de fornecedores são auditados e escalados. Exige-se também um processo de melhoria de serviços com atividades bem definidas, incluindo determinações claras de entradas e saídas.

Finalmente, é recomendável que as empresas e provedores de TI considerem seriamente esta implantação conjunta. Os benefícios serão maiores do que a implantação do ITIL de forma isolada para a Gestão da Qualidade em Serviços de TI. Como dizia Gary Hamel, famoso guru e estrategista: “

“Boa parte do que está mudando simplesmente não é visto de onde você está sentado. Sua visão está obstruída. É preciso levantar-se da cadeira e buscar novos conhecimentos.”

Gary Hamel

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

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

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?

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.