Sunscreen

Gerenciamento de Conflitos

Prezados amigos gerentes de projeto, vou escrever sobre um assunto que incomoda todo gestor de projetos: a gerência de conflitos. Todo bom gerente de projetos tem ciência que todo projeto inevitavelmente tem sempre mudança e conflitos pois envolve seres humanos. Nós somos seres inquietos e sempre insatisfeitos além de sermos sempre muito competitivos. Além disso tudo é impossível unir no mesmo time pessoas com a mesma opinião. Desta forma devemos esperar, como foi dito acima, alguns conflitos entre os stakeholders envolvidos no projeto.

Descrevo algumas boas técnicas e procedimentos que podem ajudar a resolver os conflitos. O gerente de projetos deve:

• estudar o problema existente e coletar toda informação disponível;
• desenvolver uma abordagem ou metodologia;
• conhecer bem a organização e seus membros;
• ouvir e entender antes de tomar alguma decisão ou avaliação;
• esclarecer a origem do conflito;
• entender os sentimentos dos envolvidos;
• sugerir procedimentos para resolver as diferenças;
• manter o relacionamento e o clima entre as partes envolvidas na dispulta do conflito;
• ser um facilitador no processo de comunicação;
• principalmente, buscar as soluções.

Formas para agir diante de conflitos

Existem 5 formas para agir diante dos conflitos:

1. Colaboração
   
2. Comprometimento
3. Acomodação
   
4. Imposição
5. Evitar o conflito

Na colaboração, as partes envolvidas são convidadas a participar de uma reunião face-a-face porém preparadas para trabalhar em conjunto numa solução comum. Nesta abordagem o foco tem de ser a resolução do problema e não na competição sobre a solução. Um processo de identificação da causa do conflito através do diagrama e do estudo de Ishikawa (diagrama de causa e efeito) se faz bastante interessante. Este método deverá ser usado nas seguintes situações:

• quando existe confiança;
• quando a idéia é reduzir custos;
• quando ambas as partes tem skills complementares;
• quando as duas partes querem buscar uma solução que seja boa para ambos ("win-win");
• quando o objetivo final é o mesmo e os desejam aprender algo novo.

No comprometimento, o que acontece é a barganha aonde ambas as partes saem com algum grau de satisfação, porém nem sempre totalmente satisfatória. Não se tem todas as necessidades atingidas porem o conflito é resolvido. Comprometimento deve ser usado:

• quando a outra parte é teoricamente mas forte que a sua parte;
• quando se deseja manter o relacionamento com a outra parte;
• quando você não tem certeza se está certo;
• para evitar a impressão de intransigente.

Na acomodação, a abordagem é a tentativa de reduzir as emoções que existem em um conflito, isto é realizado enfatizando as áreas de acordo em detrimento as em desacordo. No dito popular é como "colocar panos quentes" no conflito. Você concorda com alguns pontos e mostra que não está necessariamente em desacordo com os outros colocando "panos quentes" nos mesmos. Não obrigatoriamente a acomodação resolve o conflito mas tenta convencer as partes envolvidas em manter a negociação porque a solução pode ser possível.  Acomodação pode ser usada nas seguintes situações:

• para atingir um objetivo global;
• para criar uma obrigação de uma negociação posterior;
• para manter a harmonia;
• quando busca alguma solução que seja adequada;
• para criar um clima de boa vontade;
• para ganhar tempo.

Na imposição, uma das partes impõe a sua vontade para as outras. Normalmente acontece quando a resolução do conflito não ocorre nos níveis hierárquicos mais baixos e o "issue" é escalado para níveis superiores que tomam uma decisão definitiva e que normalmente atende apenas a uma parte do conflito. A imposição pode ser usada:

• quando se tem certeza que está certo;
• quando existe uma situação sem saída negociável;
• quando princípios estão em jogo;
• quando você é mais forte que a outra parte;
• para ganhar poder o status dentro da organização;
• quando o relacionamento não é importante;
• quando uma decisão rápida se faz necessária.

 Evitar o conflito é frequentemente considerado como uma solução temporária. Evita-se a situação fugindo do conflito e adiando a situação, porém o mesmo pode acontecer novamente várias vezes. No dito popular é o famoso "tirar o seu da reta". Evita-se o problema e adia-se a solução, porém o mesmo continua presente e demonstra por parte dos envolvidos a falta de responsabilidade. Evitar o conflito pode ser usado:

• quando você acredita que não vai ganhar o conflito;
• quando o que está em jogo é sem importância;
• quando o que está em jogo é alto, porém não se está preparado ainda para enfrenta-lo;
• para ganhar tempo;
• para enervar o oponente;
• para preservar a neutralidade ou reputação;
• quando acredita-se que o problema será esquecido;

Migrações de Sistemas

Amigos leitores, vou falar um assunto que sempre atormenta muitos gerente de projetos durante sua vida em tecnologia da informação: migração de sistemas.
Eu atuei em alguns processos de migração como mudança de servidor aonde o código é mantido, alterado, compilado e gerado, como foi o caso do CSP, em alta plataforma (mainframe) para Visual Generator (visualgen-baixa plataforma). Outra forte migração foi a alteração de um sistema da base de IMS (base de dados da IBM mais antiga) para DB2 (banco de dados relacional mais atual) ambos em mainframe. O terceiro foi de COBOL Microfocus (cliente-servidor)para COBOL/DB2 no mainframe, aonde o gerente que atuou no projeto na época (eu era coordenador neste período) aceitou o argumento do cliente que seria somente um "copy/paste", isto é, simplesmente copiar e colar sem ter de alterar nada. Doce ilusão!! ... ou melhor AMARGA ILUSÃO!!!!

Vou descrever abaixo algumas sugestões e dicas utilizando estas situações citadas e reais para evitarmos ou pelo menos mitigarmos as situações citadas.


Definição do escopo





Um dos pontos mais importantes, senão o mais importante, é definir o escopo da alteração. Se faz necessário definir o que será feito, pois nunca é somente um "copy/paste" existem sempre módulos obsoletos, novas necessidades e acertos na migração pertinentes a nova linguagem, novo banco de dados ou interfaces com o usuário.
Deve ser levantado, escrito e aprovado pelo usuário este escopo e é importante deixar claro o que vai ficar de fora do escopo da migração. Desta forma o gerente de projeto fica calçado e com provas do que está aprovado para ser feito evitando o "scope creep", que pelo PMI, significa descontrole na definição do escopo causando atraso no projeto, estouro nos custos do mesmo e insatisfação do cliente. Outra prática importante citada no PMBOK é evitar o "gold plating", isto é, fazer aquele algo mais para agradar o cliente. Evite fazer o que não está no escopo pois este "a mais" custo tempo e dinheiro e não foi pedido.
Outro ponto importante não é considerar somente o escopo do projeto em termos de lógica de programação ou requerimentos solicitados pelo cliente mas também definição de requerimentos físicos como banco de dados, servidores, volume de dados, taxa de crescimento de dados, incompatibilidade de banco de dados ou sistemas operacionais e por ai vai.
Obviamente existem várias outras questões a serem abordadas. E tudo precisa ser feito aqui nesta fase de definição de escopo, que é onde o custo ainda é mínimo e o impacto, se acontecer algo errado, será menor.

Plano de Riscos



Durante a fase de definição de escopo e levantamento dos requerimentos acima é importante iniciar em paralelo o levantamento dos riscos do projeto. Devem ser levantados os riscos de cada requerimento, das alterações e suas possíveis consequências. Alguns riscos que podem surgir:

• falta de um especialista nas ferramentas existentes;
• usuário não tem a definição clara de suas necessidades;
• falta de um usuário dedicado ao projeto em suas fases críticas (por exemplo, levantamento e testes);
• falta de um estudo de viabilidade do projeto;
• objetivos não estão claros;
• time de projeto desconhece o sistema ou ferramentas;

Importante entender o que é risco: ele representa o impacto de um problema caso ele vai a acontecer em um projeto versus a probabilidade do mesmo acontecer.
Os riscos devem ser definidos, qualificados, quantificados e definidos os planos para mitiga-los (antes para evitar que ocorra) e para contingencia-los (caso ocorra, o que deve ser feito).
Toda dependência externa do projeto deve gerar um risco, por exemplo a dependência de um fornecedor externo ao projeto.
Falarei sobre riscos em detalhes em outra oportunidade.

Planejamento da Migração



Faça todo o planejamento necessário para a migração, GASTE TEMPO PLANEJANDO. Evite sair executando. Documente os acordos, busque aprovação dos requerimentos, crie um cronograma, planilha de custos, plano de qualidade, plano de configuração, plano de mudanças, plano de comunicação e plano de recursos humanos. Crie um database estruturado aonde vai manter estes dados, de preferência uma ferramenta já consagrada e execute backup diários dos mesmos.
Em outros posts entrarei em maiores detalhes mas abaixo falo de alguns essenciais e mais específicos para a migração.

Plano de configuração

Deve ser bem controlada a configuração dos módulos que serão alterados, para isso um plano específico para migração deve ser criado com bastante critério, evitando passar para produção módulos incorretos. Utilizar algo como um software próprio, como o Rational Clearcase ou em caso contrário uma planilha. Neste caso deve ter um responsável como o coordenador do projeto (Team Leader) ou um analista de configuração.
Segue abaixo um modelo que já utilizei e serviu perfeitamente:

• criar uma versão inicial como 1.0.0, que é a copia do atual em produção
• a partir deste criar versões em ambiente de teste da migração como 1.0.1, 1.0.2...
  
• caso exista algum alteração em produção a mesma deve refletir no ambiente de teste da migração e sua versão passaria a ser 1.2.0
• a partir deste criar versões em ambiente de teste da migração como 1.2.1, 1.2.2...
• quando for passar para produção a verrsão de migração para produção teremos a versão 2.0.0

Cada módulo deve ser controlado e versionado. Devem ser mantidas as versões com final zero durante todo o projeto e se possivel algumas versões intermediárias.
Este é apenas um exemplo. Cada gerente pode criar seu modelo mas ele DEVE EXISTIR E SER BEM CONTROLADO pro um ÚNICO RESPONSÁVEL.


Plano de mudanças

Deve existir um plano claro de mudanças bem estabelecido e aceito pelos integrantes do time do projeto, usuário e principalmente pelo "sponsor", isto é, patrocinador do projeto.
Qualquer mudança no projeto deve ser analisada, avaliada, planejada e aprovada pelo "sponsor" ou pelo ele deve estar ciente da mesma. Todos os planos precisam ser refeitos e os impactos mensurados. Não deve ser aceito aquele famoso: "só vai alterar uma linha!!!"

Faça Backup

FAÇA BACKUP ! FAÇA BACKUP ! FAÇA BACKUP ! Sempre tenha um backup em mãos. Isto pode salvar muitas vidas. É sério !

Antes de começar o procedimento, faça cópia de tudo. TUDO MESMO ! Banco de dados, pasta dos aplicativos, executáveis, TUDO ! De preferência em duas cópias, porque backup é mestre pra não funcionar quando você mais precisa dele.

E não adianta comprar um CDzinho vagabundo na esquina. Ouça: NÃO ECONOMIZE neste ponto ! Os dados que você pode perder são de valores incalculáveis.

E não vale também fazer backup e guardar dentro da própria máquina. Os motivos eu não preciso nem explicar.

Crie uma base de testes

Não faça a migração em plena base oficial (ambiente de produção). Então, simule tudo em um ambiente o mais fiel possível do real. Se for um ERP, Crie um banco de dados de teste, use os executáveis que estão em produção. Assim você terá como corrigir alguns erros que irão ocorrer na sua migração oficial, antes mesmo que ela ocorra, diminuindo assim o tempo em que a empresa ficará sem utilizar o sistema.

Devem ser feitos os casos de teste e plano de testes bem claros. Os Casos de testes devem ser feitos pelo analista e pelo cliente em parceria, pois o cliente tem ciência das funcionalidades e o analista os detalhes do código e da base de dados. O Plano de Teste deve detalhar quais testes serão necessários, quem são os responsáveis envolvidos e suas datas.

Devem ser feitos 4 tipos de testes:

1. testes unitários, aonde o programador após a terminar o código faz testes básicos porém consistentes, evitando erros definidos nos requerimentos, de ambiente, de banco de dados e por ai vai;
2. testes de sistemas, aonde é feito os testes dos módulos completos;
3. testes integrados são os famosos "end-to-end", envolvendo todos os módulos do projeto;
4. testes de usuário, aonde somente neste momento o usuário é envolvido para testar as funcionalidades a serem implantadas e também devem ser "end-to-end"

Deve ser gerado um log de defeitos encontrados e corrigidos e caso exiga alguma alteração no escopo do projeto, a mesma deve ser submetida a Gestão de Mudanças.

Aceite pelo usuário

O aceite pelo usuário deve ser formal. Após obter o aceite busque o aceite do "sponsor" e certifique para eles que os mesmos são os responsáveis pelo sistema. Somente com este aceite você pode passar para produção.

Passagem para produção

A passagem para produção deve ser feita com muita cautela e se possível em várias ondas, por exemplo, primeiro a criação do banco de dados e carga do dados, segundo rotinas de backup e outras menos essenciais, terceiro módulos on-line. Deve ser separado para o projeto um período de tempo para a estabilização do projeto em produção. Durante este período sempre existe algum stress pois ai estamos trabalhando no mundo real e o cliente precisa naquele momento que o sistema agora em produção esteja funcionando corretamente.
Após estar tudo certo busque o aceite final do projeto com o sponsor e repasse o projeto para o time de manutenção oficialmente, isto é, de forma formal.
Projeto terminado, é a hora de gerar as lições aprendidas e as métricas, ambos coletados em tempo de execução do mesmo. É tempo também das atividades de fechamento de contratos e liberação dos recursos.

Boa sorte e bons projetos!!!

Vejam o link abaixo sobre generalistas X especialistas muito interessante para carreira de gerente de projetos.
Acompanhem o video e deixem suas impressões.
http://idealtv.uol.com.br/midiacenter/Generalistas-X-Especialistas-226b2a77c7f8540f8e2a22c03a775d33-776

Algumas considerações antes de seguirmos em frente

Gostaria de colocar algumas considerações antes de entrarmos nos próximos processos de gerenciamento de projetos que fogem um pouco da estrutura consagrada do PMI, porém muito aplicada por mim em projetos CMMI aonde a prática levou a adaptação das boas práticas do PMI dentro do modelo CMMI.

Pelo PMI, na inicialização são executados somente os processos de desenvolvimento do Project Charter e a Declaração do Escopo Inicial, porém no dia-a-dia estes dois documentos são insuficientes para uma análise executiva de GO/NO GO do projeto, isto é, se o projeto será aprovado pelo Sponsor, Gerente Sênior de Projeto e outros stakeholders diretamente ligados a aprovação do projeto.

Desta forma incluo algumas etapas da fase de Planejamento na fase de construção da Proposta.

Veja a seguir algumas etapas importantes:

1. para a fase de Inicialização, é importante o Gerente de Projeto gerar os seguintes documentos para planejamento e controle desta fase: Cronograma, Planilha de Custo, Plano inicial de Configuração, Plano inicial de Qualidade, Plano inicial de Comunicação e ter um database aonde esta documentação será armazenada com segurança.
2. após gerar os documentos deve ser executada uma inspeção dos mesmos que serão entregues ao cliente para evitar possíveis defeitos nos mesmos ("peer-review"), falaremos deste processo mais a frente.
3. Após gerar os documentos de requerimento e ter aprovação do cliente deste requerimentos, sugiro gerar os seguintes artefatos do projeto, além dos citados anteriomente: Plano de Recursos Humanos, Infra-estrutura e Recursos Computacionais Críticos, Plano de Riscos, rever o WBS do projeto, Cronograma, Sumário de Estimativas, Plano de Testes inicial, Plano de Dependências Externas.

Acredito que com esses artefatos em mãos o gerente de projetos terá como gerar um Project Charter mais completo.

Falaremos sobre cada um destes documentos e processos mais a frente.