AULA 4 GESTÃO DE PROJETOS TECNOLÓGICOS COMPLEMENTO

Prévia do material em texto

1/5 
 
1.1. Objetivos estabelecidos 
 
Este é um dos aspectos mais importantes, pois é a partir deles que detalharemos o 
planejamento do projeto para atingir os objetivos estabelecidos. Ele também é 
importante para a revisão pós-implementação, pois é necessário verificar depois 
que o projeto for entregue se os objetivos de fato, foram alcançados. 
 
 Os objetivos descrevem o que se espera alcançar com o projeto; 
 Devem estar alinhados com os objetivos do negócio; 
 Deve seguir a regra SMART: 
 
Specific (específico): Precisamos deixar claro o quê, quando, onde e como a 
situação mudará; 
Measurable (mensurável): Capazes de mensurar os alvos e os benefícios; 
Attainable (alcançável): Quando traçamos um objetivo esta condição deve 
existir; 
Realistic (realista): Deve-se refletir sobre as mudanças no negócio, fazer 
sentido; 
Timely (limitado no tempo): Qual a duração do projeto? 
 
EXEMPLO: Desenvolver um novo aplicativo para um Centro de Operações de 
Manutenção de Equipamentos que permita o acionamento dos técnicos em 
campo, para reduzir o tempo de atendimento de falhas, em 40%, até dezembro 
de 2012. 
 
1.2. Estabelecendo as fases (entregáveis) 
 
 É qualquer saída produzida como resultado da execução do projeto: As 
entregas estão normalmente relacionadas aos objetivos, se um objetivo não 
possui uma entrega relacionada, é melhor que o mesmo seja revisto; 
 Pode ser um item, produto ou artefato (documentos produzidos durante o 
projeto, exemplo, uma especificação técnica); 
 O entregável é definido no início do projeto e será verificado no fim de cada 
fase ou do projeto; 
 É requisitado/aprovado por alguma parte interessada; 
 Acabam tornando-se marcos e são utilizados para controlar o andamento do 
projeto; 
 Favorece o gerenciamento por objetivos e o comprometimento da equipe 
com o que deve ser entregue. 
 
Se as entregas estão ocorrendo nos prazos determinados, dentro do escopo, 
então, significa que o projeto está caminhando bem. 
 
 
 
 
 
 
 
 
 
 
 
 
 
2/5 
 
 
EXEMPLO: 
Produto Final: Podem ser componentes do produto, estudo de viabilidade, 
documentação técnica, plano do projeto e seus componentes. 
 
 
 
 
 
 
 
 
 
 
 
 
 
1.3. Premissas/Hipóteses 
 
Existe, na prática, alguma confusão entre premissas e restrições. Premissas são 
hipóteses: 
 
 São fatores assumidos como verdadeiros para o projeto, sem a necessidade 
de prova; 
 São condicionantes para a execução do projeto, conforme o planejado; 
 A premissa precisa ser específica, exata e clara; 
 As premissas precisam ser validadas pelas partes interessadas e resguardam 
o gerente do projeto. 
 
EXEMPLOS: 
 O engenheiro de produção deverá estar disponível no dia 1º de março 
para iniciar o levantamento dos requisitos; 
 O cliente disponibilizará, até o dia 1º de junho, toda a infraestrutura 
necessária para que a equipe do projeto comece a trabalhar; 
 Três motoristas da organização estarão disponíveis em tempo integral 
para permitir o deslocamento de pessoal pelas áreas. 
 
As pessoas que fazem a leitura do termo de abertura precisam identificar o que um 
gerente de projetos estará pensando, então, é importante que estas hipóteses 
estejam declaradas ou estar na declaração do escopo que será visto logo adiante. 
 
Pode ocorrer o caso em que as partes interessadas não concordem com as 
premissas, mas o objetivo é justamente expor as premissas para que sejam 
discutidas e negociadas. 
 
ENTREGÁVEIS
PLANEJAMENTO PRODUÇÃO
CONCEITO DESENHO EXECUÇÃO FINALIZAÇÃO
ENTREGÁVEIS
PLANEJAMENTO PRODUÇÃO
CONCEITO DESENHO EXECUÇÃO FINALIZAÇÃO
 
 
 
 
 
 
 
3/5 
 
 
As hipóteses, normalmente, estão associadas a elementos de tempo, custo, 
qualidade e recursos a serem utilizados no projeto. 
 
Também não podemos confundir hipóteses com eventos de riscos, no entanto, 
podem servir de entradas para o gerenciamento de riscos, pois a não realização de 
alguma hipótese pode ser uma ameaça para a realização de uma das fases do 
projeto. 
 
1.4. Restrições 
 
 São fatores concretos que limitam as ações do projeto; 
 Normalmente, estão relacionados à tríplice restrição. 
 
 
 
Uma alteração, incluindo uma melhoria, necessitará aumentar o tempo do 
projeto para que tais melhorias possam ser incluídas no escopo, então, isto 
faz com que o custo do projeto aumente. 
 
Se um cliente pede para que o produto seja entregue mais rápido teremos 
que reduzir o escopo, pois o tempo que ele quer agora é diferente, menor 
que o anterior. 
 
Uma solução é ter mais dinheiro para contratar mais gente para a entrega, 
no tempo que o cliente quer. 
 
E se o cliente quer pagar mais barato? O que pode ser feito? 
 
Reduz-se o escopo se considerando os reflexos desta ação, ou então o 
cliente terá que esperar mais tempo que o desejado, ficará insatisfeito. 
 
 
 
 
 
 
 
 
4/5 
 
 
Exemplos de restrições: 
 
 O projeto deve ser conduzido com o sistema de nota fiscal atual 
funcionando (típica situação de trocar o pneu com o carro andando!); 
 O projeto deve ser entregue, obrigatoriamente, no dia 15/07/2012; 
 A verba disponível para este projeto é de R$ 100.000,00 (limitação de 
custo). 
 
As restrições, então, são elementos que afetam as opções do projeto. 
 
1.5. Priorizando restrições 
 
Aprendemos que as restrições são baseadas no escopo, significando aquilo que será 
desenvolvido no projeto e, indiretamente, relacionado com os requisitos da 
qualidade. As restrições também são baseadas em datas de entrega e custos. 
 
Na vida real, o que o cliente quer é que o produto do projeto seja muito bom, 
barato e feito em tempo recorde. Acontece que, muitas vezes, o projeto já nasce 
atrasado e o gerente do projeto ainda é obrigado a manter os prazos iniciais. 
 
É preciso que se entenda que ninguém faz milagre, nem o relógio trabalha de 
graça! Comprar um sapato de alta qualidade, bonito e barato?! Será muito difícil, 
escolha então duas destas características... você deve conseguir! 
 
Se o cliente quiser um produto bom, completo, de qualidade, então, a variável 
escopo exigirá que se leve mais tempo e custe mais caro este projeto. 
 
Se o cliente quer que a entrega seja rápida, então o produto terá que ter um 
escopo menor, menos recursos aplicados, poucas funções ou então terá que pagar 
mais caro devido ao custo de horas extras, por exemplo. 
 
Se o cliente quer um projeto barato, o produto sairá muito simples ou, ao menos, o 
tempo de entrega deverá ser um pouco maior. 
 
 
 
 
 
 
 
 
5/5 
 
 
 
 
 
É importante, então, que se converse com as partes interessadas, por exemplo, 
clientes e patrocinadores, para se identificar as restrições do projeto e tentar 
balancear estas informações. Muitas das vezes, temos que abrir mão de um aspecto 
em função de outro, é o que se chama de Trade-off. 
 
Nesta análise, é possível que se gere uma matriz de prioridades, ou seja, o que é 
mais importante para o projeto? Veja a tabela: O tempo, por exemplo, é prioridade 
1. 
 
 
 
1.6. Restrições do projeto x Requisitos do produto 
 
 Não confunda as restrições do projeto com os requisitos do produto; 
 Os requisitos do produto não entram como restrições para o projeto. 
 
EXEMPLOS DE REQUISITOS DE PRODUTO: 
 
 O produto deve atender a todas as especificações estabelecidas na norma 
XYZ; 
 O galpão da fábrica deve ter 1000m2 e tubulação para instalar 
dispositivos contra incêndio; 
 O software deve rodar no sistema operacional Linux, em qualquer 
computador, com no mínimo 500 MB de RAM.