O mundo dos projetos em TI

Técnicas para uma boa negociação – Parte 2

22/08/10

Escrito por Paulo Ladeira em Ferramentas e técnicas

Dando continuidade ao post anterior (Técnicas para uma boa negociação – Parte 1), vou comentar algumas outras técnicas abordadas na disciplina cursada e de suma importância para atingir os objetivos desejados em uma negociação.
Apesar do que muita gente pensa, para ter sucesso em uma negociação, não basta apenas ser um bom negociador durante esta. É preciso ter realizado um planejamento correto para a negociação. Muitas ações devem ser feitas antes de tal para evitar decisões erradas durante. Uma frase de Abraham Lincoln reflete bem a importância do planejamento: “Se tivesse 9 horas para cortar uma árvore, passaria 6 horas afiando meu machado.”. Logo, a seguir, veremos algumas técnicas importantes, tanto antes, quanto durante a negociação.

BATNA:
A técnica BATNA (Best Alternative To a Negotiated Agreement, também conhecida em português de MAANA, Melhor Alternativa À Negociação de um Acordo) realizada na fase de planejamento da negociação, consiste em, dada as possíveis alternativas ao acordo, deve ser levantada toda possível consequência de cada alternativa e com base nesta, decidir qual a melhor alternativa, que será o seu BATNA.
É importante, caso tenha acesso as informações necessárias e verídicas, avaliar o BATNA da outra parte envolvida na negociação buscando anteceder as suas possíveis ações estratégica.

ZAP:
Sigla para “Zona de acordo possível”, ZAP trata-se do intervalo de valores que, caso a negociação seja efetuada neste valor, ambos sairão satisfeitos. Para encontrar esta “zona” é necessário levantar o seu valor de reserva para a negociação e o valor de reserva da outra parte envolvida. Estes valores irão determinar as extremidades da ZAP.
Por exemplo, em uma negociação de imóvel, sabemos que o vendedor não irá aceitar menos que 200 mil e o comprador aceita pagar até 230 mil pelo apartamento. Logo, temos uma zona de acordo possível entre os 200 mil e o 230 mil.

ZAP - Zona de acordo possível

Após realizar uma análise sobre a zona de acordo possível deve ser avaliado se é conveniente apresentar uma primeira proposta ou ouvir a primeira proposta. Este conceito esta relacionado à nossa próxima técnica.

Ancoragem:
O processo de ancoragem trata-se dos valores iniciais lançados em uma negociação que funcionam como âncoras e afetam o resultado final da negociação. Estudos mostram que os valores acordados ao final de uma negociação são mais afetados pelas ofertas iniciais do que as várias concessões realizadas durante a mesmo.
Caso no seu planejamento você decida ancorar a negociação, e, ao sugerir o seu preço a outra parte começar a questionar este valor, fique satisfeito. Significa que a outra parte aceitou a sua ancoragem e a partir dali você deve trocar concessões para chegar um acordo que possivelmente será bom para você (a não ser que tenha ancorado errado).
Porém, caso a outra parte que ancore primeiro, algumas alternativas possíveis para fugir desta “armadilha” são:

Após ouvir o valor da outra parte, desvie o foco sobre a quantia, quebre o assunto e tente retomar mais adiante. Isto não significa fingir que não ouviu, é apenas uma forma de não aceitar a ancoragem da outra parte. Caso a outra parte não esteja preparada o suficiente para a negociação, com o tempo, ela irá começar a propor novos valores ou você poderá mudar o jogo e propor um novo valor baseado em raciocínio lógico;
Desqualificar a âncora utilizando do bom humor, afirmando sobre um possível engano, mostrando que os números estão fora da realidade e deixando clara a possibilidade de um não acordo;
Ofereça um tempo para a outra parte para refazer a proposta apresentada;
E se nenhuma das anteriores funcionar, pague na mesma moeda. Faça a sua ancoragem (Última opção. Não é recomendado, uma vez que a possibilidade de não acordo cresce com esta).

Concessões:
Realizar uma concessão nada mais é do que rever a posição em que se encontra e sustenta a um tempo, buscando chegar ao acordo. Não existe negociação sem concessão. Por isto, é importante ressaltar alguns pontos referentes a esta técnica:

Programe-se anteriormente para pode realizar concessões;
Nunca dê uma concessão sem justificar e sem receber outra em troca. Consequentemente, não dê duas concessões seguidas. Isto significa que você cedeu uma de graça;
Tente não ser o primeiro a ceder e faça com que a outra parte “lute” para conseguir sua concessão;
Ser generoso não significa que irá “tocar o coração” da outra parte;
Uma concessão pode ser revista e você pode revogar a decisão tomada.

Comportamento humano:
Como negociação é um processo de tomada de decisão que envolve mais de uma parte interessada, você sempre dependerá da outra parte para chegar ao acordo. Logo, é extremamente importante entender o comportamento ideal em uma negociação, tanto da sua parte, como da outra envolvida. Logo, alguns pontos são importantes ressaltarmos e termos uma atenção em especial:

Pessoas contêm emoções, interesses pessoais e valores diferentes do seu e pouco previsíveis. Suas decisões estão mais vinculadas as razões pessoais do que as razões da empresa;
A emoção afeta consideravelmente a negociação, onde ao sentirmos injustiçados a tendência é buscarmos punir a outra parte (mesmo que não seja racionalmente correto). Logo, raramente compensa tentar desestabilizar a outra parte;
O conceito de justiça varia de acordo com o lado que você se encontra;
A percepção das partes envolvidas pode ser diferente e tender a posições opostas.

Oposição à Fidel: “A situação em Cuba está tão ruim que até as universitárias estão virando prostitutas”.
Resposta de Fidel Castro: “Nada disso! A situação é tão boa que até as prostitutas são universitárias”.

Finalizando, técnicas de negociação são interessantes, pois, apesar de comprovado o resultado ao utilizar estas, por estarmos negociando com pessoas, não obrigatoriamente estas trarão o resultado esperado. E é ai que surge o grande negociador, que sabe utilizar as técnicas certas, no momento certo, dado o ser humano que se encontra do outro lado da negociação.
Bem pessoal, é isto. Espero que tenha conseguido repassar para vocês um pouco do conceito de negociação que tive contato. Até o próximo post.

ancoragem, batna, concessão, negociação, negociação empresarial, técnicas de negociação, zap

Técnicas para uma boa negociação – Parte 1

04/08/10

Escrito por Paulo Ladeira em Ferramentas e técnicas

Nenhum comentário

Recentemente cursei uma disciplina muito interessante na pós-graduação que estou fazendo e, por isto, resolvi trazer alguns pontos para o blog. Esta disciplina abordou de forma ampla os conceitos relacionados a uma boa negociação. Apesar de saber da importância de todos os pontos vistos o que mais me chamou a atenção e que me motivou a escrever este post foram as técnicas de negociação apresentadas, onde foram abordados conceitos simples, de fácil aplicação no dia a dia e que muitas vezes trazem resultados consideráveis.
Irei dividir o assunto em duas partes: na primeira parte irei explicar o conceito de negociação e explorar algumas variáveis importantes neste processo e, na segunda parte, irei abordar outras técnicas de negociação.
Antes de ir mais afundo nas técnicas, vamos alinhar o conceito de negociação. Negociar não é impor nada. Negociar trata-se de qualquer processo de decisão que envolva mais de uma pessoa, onde se busca obter um resultado melhor do que se não tivesse negociado. Em outras palavras, negociar pode ser visto como o processo de convencer pessoas/organizações a ceder o que desejamos.

Dado o conceito de negociação, começamos a visualizar algumas variáveis que podem ser utilizadas neste processo. Algumas delas iremos discutir abaixo:

PODER
Dado o poder que uma pessoa detém na negociação em questão é possível chegar a resultados melhores do que caso não existisse tal. Algumas características importantes do poder:

Devemos buscar sempre aumentar o nosso poder e reduzir o poder do outro, principalmente em negociação de competição;
Tende a mudar durante o processo de negociação, podendo aumentar ou diminuir;
Pode muitas vezes não ser verdade, dependendo apenas da percepção da outra parte envolvida;
Não é possível mensurar;
Sempre é limitado.

RISCO
Negociar é um processo continuo de correr risco. Para isto, para aumentar a eficiência da sua negociação é sempre bom ser racional para correr os riscos, tendo estes calculados, sabendo diferenciar coragem do bom senso, sabendo os impactos de ambas as partes caso o objetivo da negociação não seja atingido e não se deixar levar por emoções.

INFORMAÇÃO
Ter o maior número de informações possíveis para o processo em questão é de extrema importância para o sucesso da negociação. Logo, antes de começar qualquer fase de negociação recomenda-se aprofundar-se ao máximo o assunto, realizando levantamentos como, quais os poderes o outro detém ou qual a tradição em negociação da outra parte.

Fonte: Blog do Amarildo

Já durante o processo de negociação, deve-se buscar “sugar” o máximo de informações possíveis da outra parte, utilizando de algumas técnicas como: ouvir o máximo possível, perceber informações ocultas e comunicação não verbal, etc. Para estes pontos, existe um livro disponível para download gratuito na internet chamado “O corpo fala” de Pierre Weil & Roland Tompakow.

TEMPO
Muitas vezes, buscando chegar a acordos o mais rápido possível, negociadores tendem a ter pressa no processo de negociação e, com isto, tomar decisões equivocadas. Buscando evitar este tipo de decisão é sempre bom ter em mente que, na grande maioria das vezes, os prazos são negociáveis e a paciência compensa. Logo, podemos fazer alguns levantamentos baseado na variável tempo como, quais tipos de prazo as partes estão envolvidas, identificar as táticas do outro, etc.

Apesar de apresentadas separadamente, na prática as 3 variáveis aqui vistas (Poder, Informação e Tempo) são aplicadas simultaneamente onde costuma-se utilizar do tempo para obter informações buscando aumentar a sua fonte de poder.

Resumindo…
Para se tornar um bom negociador:

Aproveite o tempo que lhe é dado;
Esteja preparado para correr riscos;
Conheça as diversas fontes de poder de ambas as partes, lembrando que estas podem mudar durante o processo;
Seja mais ouvinte;
Seja criativo.

A parte 1 deste post é isto. No próximo post irei abordar técnicas como BATNA, Ancoragem, ZAP, e os efeitos dos comportamentos humanos no processo de negociação. Até lá.

informação, negociação, negociação empresarial, poder, risco, técnicas de negociação

Indicadores de custo e prazo utilizados na gestão de projetos

17/07/10

Escrito por Paulo Ladeira em Ferramentas e técnicas

2 comentários

É cada vez mais comum nas organizações atuais, principalmente as que trabalham exclusivamente com projetos, a necessidade de adotarem indicadores nos projetos executados nesta. Estes indicadores buscam embasar os gerentes dos projetos e a diretoria da empresa a estabelecerem metas estratégicas, acompanharem a execução, entre outros.

Cada empresa contém os seus indicadores e estes são definidos utilizando vários fatores, como, o nível da maturidade de cada empresa e a forma de como esta é estruturada (projetizada, matricial ou funcional). Muito vinculado à maturidade da empresa, é comum vermos indicadores sendo definidos nas fases de planejamento do projeto, e avaliados nas fases de encerramento do mesmo (quando são avaliados). Porém, nenhum acompanhamento é realizado durante a execução do projeto. Com isto, esses indicadores servirão apenas para classificar como foi o projeto e ficar como lição aprendida para os próximos, não servindo para acompanhar o andamento do projeto e traçar ações para recuperá-lo, caso necessário.

Neste artigo, irei abordar dois indicadores bastante utilizados para monitorar o andamento do projeto com relação a custo e a cronograma/prazo, CPI (Cost Performance Index) e SPI (Schedule Performance Index), respectivamente. Estes indicadores servem para monitorar o projeto como um todo, ou apenas uma entrega da WBS.

Antes de entrar na definição de cada indicador, e podermos calcular os seus respectivos valores, necessitamos de ter em mãos outras informações do projeto, que são:

Valor planejado (PV – Planned Value) – Custo planejado do projeto, relacionado à linha de base de custo do projeto.

Valor agregado (EV – Earned Value) – Trata-se do custo planejado do projeto para o trabalho executado até o momento. Ou seja, é o valor dos serviços realmente executados até o momento.

Exemplo: Caso tenha planejado de entregar 4 paredes iguais, sendo o custo para construção de cada parede ser de 1000 reais e eu entreguei até o momento duas paredes e meia, o valor agregado do meu projeto neste momento é de 2500 reais, independente do custo que eu tive para fazer estas 2,5 paredes.

O valor agregado de cada projeto trata-se de uma saída da EVA (Earned Value Analysis), recentemente substituída por EVM (Earned Value Management) pelo PMI para evitar a confusão do conceito EVA®, referência a Economic Value-added.

Custo real (AC – Actual Cost) – Custo total do trabalho até o momento.

Variação de prazo (SV – Schedule Variance) – É a diferença entre o valor agregado até o momento (EV) e o valor planejado (PV).

SV = EV – PV

Variação de custo (CV – Cost Variance) – É a diferença entre o valor agregado (EV) e o custo real (AC).

CV = EV – AC

Pronto, com base nestas informações, já conseguimos calcular os indicadores CPI e SPI, aqui abordados.

CPI (Cost Performance Index) – Trata-se do valor agregado do projeto(EV) divido pelo custo real(AC) do mesmo, ambos até o momento do cálculo.

CPI = EV/ AC

Obs: Por se tratar de um indicador de custo, a variável valor planejado (PV) não é levada em consideração, pois não importa se estamos dentro do planejado, importa somente o quanto gastamos até o momento para o já construído.

Analisando a fórmula acima mencionada, podemos tirar 3 cenários:

CPI > 1, ou seja, o valor agregado até o momento é maior do que o custo real gasto para este. Logo, o projeto encontra-se em um cenário favorável em relação a custo (Famosa “gordurinha”);
CPI = 1, ou seja, o valor agregado até o momento é exatamente igual ao custo gasto para tal. Apesar de difícil de acontecer, neste momento, apesar do projeto estar rigorosamente dentro do esperado, uma atenção especial deve ser dado a este, pois qualquer desvio daqui para frente pode levar ao “prejuízo” no projeto;
CPI < 1, ou seja, agregou-se menos até o momento do que gastou. Este é o pior cenário dentre os três para um projeto estar. Neste momento deve-se buscar ações para recuperar o prejuízo do projeto, tentando gastar menos para as próximas implementações do projeto;

Voltando ao exemplo acima, das 4 paredes, se no momento em que já entreguei 2,5 paredes (EV = 2500 reais) eu gastei 2000 reais (AC), logo o CPI do meu projeto é de 1,25, o que significa que para cada 1 real realmente gasto no projeto estou agregando 1,25 reais em funcionalidade.

Por outro lado, se até o momento gastei 3000 reais (AC) para as mesmas 2,5 paredes (EV = 2500), meu CPI é de 0,83, o que significa que para cada 1 real realmente gasto no projeto, só estou agregando 83 centavos em “resultado”.

SPI (Schedule Performance Index) – Trata-se do valor agregado até o momento dividido pelo valor planejado até o momento.

SPI = EV/ PV

Obs: Por se tratar de um indicador de cronograma, a variável custo atual (AC) não é levada em consideração, pois não importa o tanto que gastamos até o momento.

Analisando a fórmula do SPI, também chegamos aos mesmos cenários do CPI:

SPI > 1, ou seja, o valor agregado até o momento é maior do que o valor planejado para este momento. Logo, o projeto encontra-se em um cenário favorável em relação a cronograma/prazo (Famosa “gordurinha”);
SPI = 1, ou seja, o valor agregado até o momento é exatamente igual ao valor planejado para este momento. Apesar de difícil de acontecer, neste momento, apesar do projeto estar rigorosamente dentro do esperado, uma atenção especial deve ser dado a este, pois qualquer desvio daqui para frente pode levar ao atraso no projeto;
SPI < 1, ou seja, agregou-se menos até o momento do que estava planejado. Neste momento deve-se buscar ações para recuperar o tempo perdido do projeto, tentando agregar mais funcionalidades em menos tempo;

Para o mesmo exemplo acima, se no momento da medição eu tinha planejado entregar 2 paredes, meu SPI está em 1,25, logo produzi até o momento 25% a mais do planejado.

Entretanto, se no momento da medição tinha planejado entregar 3 paredes, meu SPI é 0,83, logo, estou 17% atrasado em relação ao planejado.

Uma consideração importante entre o CPI e SPI, é que o CPI é válido de ser utilizado durante todo o projeto, inclusive após o término do projeto. Já o SPI ele começa a perder valor quando o prazo de finalização planejado do projeto é ultrapassado, e o projeto ainda não está finalizado. Neste momento o valor planejado se mantém constante (100% do projeto), ocasionando em caso realizarmos uma medição hoje e detectarmos que agregamos certa quantidade de valor ao projeto e daqui dois meses realizarmos outra medição, e detectarmos o mesmo valor agregado, chegamos a um mesmo SPI, um pouco inconsistente para um indicador de prazo, não acha?

Outro momento que o SPI não tem muita utilidade é após o término do projeto. Independente do tempo gasto durante o projeto, se você entregou o 100% planejado seu SPI ao término do projeto é sempre 1, mesmo que o tempo gasto foi o dobro do planejado.

Pronto é isto… Agora que você já sabe como calcular estes dois indicadores, você pode controlar o custo e o prazo do seu projeto, usar a combinação destes para definir ações (Ex: Caso esteja com o CPI maior que 1 e o SPI menor que 1, pode tomar alguma decisão como aumentar a equipe para recuperar o prazo perdido apesar de ter um custo maior) e até criar metas na sua empresa com base nestes.

Até o próximo post…

cpi, cronograma, custo, Earned Value, escopo, gestão de projetos, indicador, Orientar e gerenciar a execução do projeto, prazo, spi, valor agregado

FEEDBACK construtivo: Por que é tão difícil aplicar?

29/05/10

Escrito por Paulo Ladeira em Ferramentas e técnicas

7 comentários

Já faz algum tempo que esta palavrinha invadiu os cotidianos das organizações, onde todos sabem do que se trata (Alguns tem até decorada uma definição para esta), reconhecem os benefícios gerados com a utilização deste, porém, na prática, não o aplica.

Minha intenção com este post é discutir um pouco sobre isto. Levantar os motivos da não aplicação desta ferramenta, os prejuízos gerados e as minhas sugestões sobre o que pode ser feito para melhorar um pouco mais a freqüência de aplicação do feedback.

Primeiramente, vamos alinhar algumas premissas: Feedback não é somente elogiar. Muito menos somente “dar broncas”. Não deve existir somente do gerente para os seus “subordinados”.

Vários são os momentos em que os gerentes e coordenadores de equipe justificam uma falha no andamento do projeto na sua equipe. E, também é comum, vermos membros da equipe criticando a gestão do projeto pelo motivo do fracasso de uma ação ou da sua insatisfação com aquela empresa/projeto. Porém, quantas vezes você chegou para a outra pessoa e falou com esta o que não concordava e o que poderia ser melhorado? Quantas vezes você chamou uma pessoa para elogiar o seu trabalho? Quando pergunto quantas vezes, não aceito respostas relacionados a programas pré-determinados dentro da empresa, pois para mim, nestes momentos você não fez mais do que a sua obrigação . Isto não deveria ser obrigatório, e sim ser parte da rotina (este ponto será discutido melhor mais abaixo). Como criticar alguém ou negar uma promoção se em momento algum você chegou para esta pessoa e mostrou o que está indo certo, o que está errado, e junto retomar o caminho correto?

É comum nos depararmos com algumas pessoas alegando que estão trabalhando mais de 10 horas por dia para cobrir a irresponsabilidade dos outros membros de sua equipe, porém nunca tentaram entender o motivo disto estar acontecendo. Falta empatia nas pessoas. Pessoas criticam as outras, porém não se colocam no lugar desta. É comum também termos pessoas trocando de empresas, pois esta não atendeu as suas expectativas (turnover) sendo que ambos os lados envolvidos não alinharam as expectativas. Principalmente para os que lideram equipes, lembre-se a sua equipe é a sua responsabilidade (no sucesso ou no fracasso).

OBS: Reunião de status report com toda a equipe não é um feedback.

Ok. É fato que hoje não é aplicado da melhor forma, mas, por quê? Abaixo vou listar alguns pontos que vejo poder ser lapidados para melhorarmos isto:

Falta de conhecimento sobre o outro: onde as pessoas não têm informação suficiente sobre o outro e com medo de questionar algum ponto erradamente, acabam evitando o feedback. Vejo que realmente se você não detêm conhecimento sobre o outro, procure conhecê-lo primeiro e depois sim dar um feedback. Vai ser mais construtivo. Mas não deixe de fazer por causa disto.

Falta de preparo dos envolvidos: onde a pessoa que vai dar o feedback não sabe fazê-lo e a pessoa que vai receber não sabe recebê-lo. Isto é muito comum. A pessoa que está dando o feedback com medo de ofender a outra pessoa se limita a elogiá-la sempre (Depois vai assustar com o pedido de aumento desta). Novamente, feedback não é somente elogios. Se uma coisa está errada, ela deve ser destacada como ponto de melhoria e juntos estabelecerem parâmetros para corrigir isto. É comum também o ouvinte ver o feedback somente como crítica e ficar com “raiva” do outro (quando era para agradecer).

Falta de abertura: pessoas têm perfis diferentes e por isto devem ser abordadas de formas diferentes. Cabe a você, como líder da sua equipe, estudar o perfil de cada um e adaptar a forma de feedback a esta pessoa. Uma pessoa ser “fechada” não é uma característica ruim e não deve ser visto como uma barreira. Coloque-se no lugar desta (empatia) e estabeleça a melhor forma de abordagem.

Importância do feedback ficar somente na teoria: pessoas sabem da importância, porém, entre realizar uma atividade que está em seu nome (criar um cronograma, desenvolver uma funcionalidade, etc.) e dar um feedback, optam por fazer aquilo que será cobrado. Muito por isto, é comum vermos em empresas programas de feedback que obrigam as pessoas a “conversarem”. Neste ponto, não vejo errado por parte de a empresa passar a cobrar o feedback (apesar de isto ser um reflexo do perfil que ela mesmo escolheu). Porém, isto deve ocorrer somente no início. Isto não deve ser eternamente cobrado. Deve passar a fazer parte do dia-a-dia dos membros da organização. Outro ponto questionável também, é a constante sobrecarga dos profissionais em uma empresa não o deixando realizar ações “não previstas” como o feedback.

Pensamento individualista: pessoas se preocupando somente com as suas atividades e deixando claro que a outra parte é responsabilidade do outro. Para projetos em TI isto não existe. Todos estão dentro de uma mesma equipe e devem sempre buscar os objetivos coletivos acima dos objetivos pessoais. Não entenda que não podem existir objetivos pessoais. Pode, porém os da equipe devem ser dados prioridades.

Lembrem-se, um feedback mal dado pode gerar efeitos contrários aos benefícios esperados, verificando que se perdeu uma grande oportunidade de ficar calado . Logo, não se deve obrigar um feedback sem antes preparar a sua equipe para realizá-lo. Podemos chegar ao final, onde todos deram os seus “feedbacks” e não atingirmos os objetivos esperados e vermos que devíamos ter preparado os envolvidos antes. Porém, não são por estes motivos que devemos evitá-los. O benefício de um feedback bem dado e recebido (feedback construtivo) trata-se de um grande diferencial, tanto a nível pessoal como a nível organizacional.

Procure criar a cultura de FEEDBACK na sua equipe. Não será um processo fácil, mas com certeza será um processo proveitoso para todos.

Bom, estes são os pontos que vejo. O que acham? Contribuam com novas questões.

Abraços e até o próximo post.

barreiras de comunicação, comunicação, feedback, gestão de projetos

Orientar e gerenciar a execução do projeto

29/05/10

Escrito por Paulo Ladeira em Gestão de projetos

Nenhum comentário

Dando continuidade ao estudo para certificação, iremos dar continuidade aos processos existentes no PMBOK dentro da gestão da Integração do projeto. Neste post, irei falar sobre o processo “Orientar e gerenciar a execução do projeto”.

Este processo trata-se da realização do trabalho definido no plano de gerenciamento do projeto, saída do processo anterior, buscando atingir os objetivos do projeto. Algumas atividades deste processo:

Executar as atividades do projeto;
Construir os entregáveis do projeto;
Implementar os padrões e os métodos planejados no plano de gerenciamento do projeto;
Disponibilizar informações sobre o projeto como: cronograma, custo, progresso da qualidade, etc.;
Emitir solicitações de mudanças para serem avaliadas dentro do processo “Realizar o controle integrado de mudanças”;
Gerenciar as diversas interfases do projeto, técnicas e organizacionais;
Implementar as mudanças aprovadas, podendo ser uma ação corretiva (buscando que o desempenho futuro esperado do projeto fique de acordo com o plano de gerenciamento do projeto), preventiva (buscando reduzir a probabilidade de consequências negativas ao projeto) e reparo de defeito (buscando corrigir um defeito encontrado em algum componente do projeto).

Entradas do processo:

Plano de gerenciamento do projeto;
Solicitações de mudanças aprovadas, saída do processo “Realizar o controle integrado de mudanças”, devem ser priorizadas e executadas;
Fatores ambientais da empresa (já visto anteriormente);
Ativos de processos organizacionais (já visto anteriormente).

Ferramentas e técnicas utilizadas para Orientar e gerenciar a execução do projeto:

Opinião especializada, onde dado as entradas o especialista utiliza de seus conhecimentos para orientar e gerenciar a execução do plano de gerenciamento do projeto. Normalmente, esta expertise pode ser designada a alguns papéis como: gerente do projeto, PMO, consultores, outras unidades, etc;
Sistema de informações do gerenciamento de projetos, oriundo da entrada “Fatores ambientais da empresa”, disponibilizando uma (ou várias) ferramenta automatizada que podem auxiliar na execução e gerenciamento do projeto.

Saídas desse processo:

Entregas, tratam-se de qualquer “pedaço do projeto” que deve ser produzido para concluir um processo, uma fase ou um projeto;
Informações sobre o desempenho do trabalho, rotineiramente coletadas que geram base para análise de desempenho como: situação das entregas, cronograma e custos;
Solicitações de mudanças, que visam modificar políticas, procedimentos, escopo, custo, cronograma, etc.. Estas mudanças podem ser corretivas, preventivas, reparo de defeito (já vistas acima) ou atualizações (Mudanças em documentações controladas pela organização);
Atualizações do plano de gerenciamento do projeto, incluindo as diversas áreas de conhecimento;
Atualizações dos documentos do projeto, como o registro de riscos do projeto.

CAPM, gestão de projetos, Integração, Orientar e gerenciar a execução do projeto, processos

Desenvolver o plano de gerenciamento do projeto

29/05/10

Escrito por Paulo Ladeira em Gestão de projetos

1 comentário

Dando continuidade ao estudo para certificação, iremos dar continuidade aos processos existentes no PMBOK dentro da gestão da Integração do projeto. Neste post, irei falar sobre o processo “Desenvolver o plano de gerenciamento do projeto”.

OBS: No PMBOK 3º edição, antes deste processo, existia outro processo chamado de “Desenvolver a declaração do escopo preliminar”. Porém, no PMBOK 4º edição, este processo foi retirado (ou “deslocado”, uma vez que a maioria das suas atividades agora está dentro do processo “Desenvolver o termo de abertura”).

Este processo tem como finalidade documentar todas as ações necessárias para definir, preparar, integrar e coordenar todos os planos oriundos das áreas auxiliares existentes no projeto. Por isto, será visto a frente que este processo tem como entrada os diversos planos criados nas outras áreas de conhecimento. Alguns exemplos de planos auxiliares:

Plano de gerenciamento de escopo;
Plano de gerenciamento do cronograma;
Plano de gerenciamento dos recursos humanos.

Este processo também define como o mesmo será executado, monitorado, controlado e encerrado.

O plano de gerenciamento do projeto depois de criado é constantemente atualizado por um processo visto posteriormente chamado “Realizar o controle integrado de mudanças” que contém como saídas atualizações no plano de gerenciamento do projeto.

Este processo tem como entradas:

O termo de abertura do projeto visto no post anterior (link);
As saídas dos processos de planejamentos das outras áreas de conhecimento (escopo, prazo, custo, qualidade, recursos humanos, comunicação, riscos e aquisições), além das suas linhas de bases para as áreas que se aplicam;
Fatores ambientais da empresa como, sistema de gerenciamento de projetos, infraestrutura, diretrizes para contratação de recursos humanos, etc.;
Ativos de processos organizacionais como, modelo de plano de gerenciamento de projetos, que pode afetar na execução do processo em questão.

A única ferramenta e técnica utilizada para desenvolver o plano de gerenciamento de projeto é:

Opinião especializada, utilizada de forma a adequar os processos em busca de atender às necessidades do projeto, determinar recursos necessários e os níveis necessários destes, definir níveis de configuração e de controle, etc.

Saídas geradas no processo:

Plano de gerenciamento do projeto, integrando e consolidando todos os planos de gerenciamento auxiliares (outras 8 áreas de conhecimento) e as linhas de base existentes. Neste plano terá definido alguns itens como: ciclo de vida selecionado para o projeto, forma de execução do trabalho, plano de gerenciamento de mudanças, plano de gerenciamento de configuração, entre outros.

CAPM, gestão de projetos, Integração, plano de gerenciamento de projetos, PMBok, PMI, processos

Utilizando SCRUM por um longo período

27/05/10

Escrito por Paulo Ladeira em Ferramentas e técnicas

Nenhum comentário

Olá a todos.

Cada dia mais o SCRUM, framework iterativo e incremental para desenvolvimento ágil e gerenciamento do projeto (vou aqui chamar de metodologia. Desculpem aqueles que não concordarem com o nome dado), está presente nas empresas de desenvolvimento de software. É comum entrarmos em uma empresa e logo visualizarmos os quadros cheios de post-its coloridos.

Esta crescente também tem sido apoiada pelos próprios clientes, onde é cada vez mais comum o cliente que já trabalhou com algum projeto que tenha utilizado esta metodologia (Mesmo que não seja de forma fiel ao que o SCRUM prega, e não é o foco deste post discutir se neste caso trata-se de SCRUM ou não J) solicitar que sejam utilizados alguns artefatos do SCRUM.

Como toda metodologia, apresenta pontos positivos e pontos negativos. E, também não é o objetivo deste post discutir o que é melhor, SCRUM, RUP ou outra forma qualquer. Queria aqui, apenas dar um relato sobre a utilização do SCRUM em produtos.

No último treinamento de SCRUM que fiz, um dos ouvintes declarou a seguinte frase que me marcou: “Sei não. Vejo que para projetos grandes o SCRUM não vai funcionar. A equipe vai se perder durante o decorrer deste.”.

Hoje trabalhamos no desenvolvimento de um produto, onde temos vários clientes utilizando-o, e necessitando de frequentes personalizações.

Por não termos um escopo fechado (mudanças surgem a todo o momento) e o produto ser bastante estável, onde a grande maioria das solicitações são evoluções do produto e não serem críticas, tornou-se possível aplicarmos o SCRUM neste “projeto” (Coloquei projetos entre aspas pois não temos uma data de término prevista. Como, de acordo com a definição do PMBOK, projeto é todo esforço com data de início e término prevista que visa construir um produto único, este pode não ser considerado um projeto).

Como a grande maioria dos projetos que utilizam SCRUM, tivemos que fazer uma adaptação. Pelo fato de termos vários clientes, tornou-se inviável termos um único representante do cliente para assumir o papel do PO. Logo, foi preciso alocar um membro da empresa para centralizar as necessidades dos vários clientes e então realizar o seu papel.

A cada sprint encerrada, vejo o quanto que o framework é útil e o passar do tempo só agrega ainda mais valor, confirmando os benefícios que o SRUM prega. Estamos finalizando a 18º sprint e hoje, os processos hoje são inerentes as pessoas. Ocorre de forma prática e sem percebermos.

Como toda mudança, no início demandou um pouco mais de rigor, principalmente por parte do SM. Porém, com o tempo, está ficando comprovado (pelo menos para mim) que o fato de ser um projeto longo só tem aumentado a eficiência do SCRUM e a segurança de todos os envolvidos com esta metodologia.

“Pequeno” relato da utilização do SCRUM durante um período longo que está dando certo, contrariando algumas opiniões.

Abraços e até o próximo post.

Utilizando SCRUM em produtos