UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO “LATO … · O presente trabalho será baseado no...
61
UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO “LATO SENSU” AVM FACULDADE INTEGRADA METODOLOGIAS DE GESTÃO DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO (TI) – ESTUDO DE CASO NA PETROBRAS Por: Cley Piter da Silva Orientador Prof. Luiz Cláudio Rio de Janeiro 2012
Transcript of UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO “LATO … · O presente trabalho será baseado no...
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
AVM FACULDADE INTEGRADA
METODOLOGIAS DE GESTÃO DE PROJETOS DE
TECNOLOGIA DA INFORMAÇÃO (TI) – ESTUDO DE CASO NA
PETROBRAS
Por: Cley Piter da Silva
Orientador
Prof. Luiz Cláudio
Rio de Janeiro
2012
2
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
AVM FACULDADE INTEGRADA
METODOLOGIAS DE GESTÃO DE PROJETOS DE
TECNOLOGIA DA INFORMAÇÃO (TI) – ESTUDO DE CASO NA
PETROBRAS
Apresentação de monografia à AVM Faculdade
Integrada como requisito parcial para obtenção do
grau de especialista em Engenharia da Produção.
Por: Cley Piter da Silva
3
AGRADECIMENTOS
À Deus, professores, familiares,
amigos e parentes
4
DEDICATÓRIA
Dedica-se a DEUS, minha família e
amigos
5
RESUMO
Tecnologia da Informação e Gerenciamento de projetos são os assuntos
da atualidade, assuntos estes recorrentes do mundo moderno e globalizado,
onde se procura cada vez mais desenvolver e ofertar produtos e serviços
oferecidos com a finalidade atender as expectativas dos clientes e exigências
do mercado.
Com o objetivo de atender esta demanda as empresas de tecnologia se
organizam e preparam atender as diversas necessidades do cliente, porém o
foco desta trabalho não é tratar especificamente das inovações tecnológicas e
ofertas de produtos e serviços, mas tratar da necessidade das empresas se
organizarem de forma estruturada e, quem sabe projetizada.
Este trabalho tem como objeto de estudo a empresa “Petrobras”, e a
apresentação de alguns de seus principais padrões de gerenciamento de
projetos de tecnologia da informação. Neste são descritos os padrões de
Tratamento de demandas de clientes internos, Implementação de soluções de
software, Regras para Classificação da Complexidade de Projetos de Solução
de Software, Implementação Soluções de Infraestrutura de TI, Elaboração de
planejamento de Curto Prazo, Metodologia de Gerenciamento de Projetos de
Tecnologia da Informação (Tradicional) , Metodologia de Gerenciamento de
projetos com (Métodos Ágeis) de Tecnologia da Informação, Monitoramento do
Portfolio de Projetos de Tecnologia da Informação e Revisão de Qualidade de
Projetos de Tecnologia da Informação.
Vale ressaltar que os padrões podem e devem ser utilizados em
conjunto, visto que são complementares e auxiliam a otimização do processo
como um todo. Sugere-se selecionar e aplicar os padrões que mais se
adequem ao processo a ser analisado, para se alcançar os melhores
resultados.
6
METODOLOGIA
O presente trabalho será baseado no estudo de caso das metodologias
de gestão de projetos de tecnologia da informação na empresa Petrobras.
O objetivo deste estudo de caso é destacar a importância da existência
e utilização de metodologias de gerenciamento de projetos de tecnologia da
informação.
Serão abordadas as etapas iniciais, processos, premissas,
responsabilidade e seus principais impactos no gerenciamento de projetos
desta natureza (TI).
As fontes da metodologia e ferramentas serão obtidas por meio dos
padrões de implementação, desenvolvimento, revisão de qualidade,
monitoramento e controle do portfólio de projetos de tecnologia da informação,
site institucional (Intranet), sites especializados e livros.
7
SUMÁRIO
INTRODUÇÃO 08
CAPÍTULO I - Estruturas Organizacional 09
CAPÍTULO II - Projetos de TI na Petrobras 18
CAPÍTULO III – Padrões de Gestão de Projetos 22
CONCLUSÃO 55
BIBLIOGRAFIA CONSULTADA 52
ANEXOS 59
ÍNDICE 60
FOLHA DE AVALIAÇÃO 61
8
INTRODUÇÃO
O mercado de tecnologia da informação é um dos que mais crescem
na atualidade, porém para atender as demandas deste mercado são
necessários alguns requisitos básicos, dentre eles competências técnicas,
criatividade e visão clara de implantação, monitoramento e controle de
projetos.
As instituições que atuam neste seguimento “Tecnologia da
Informação” normalmente tem sua estrutura organizacional atuando de forma
projetizada, ou seja, estrutura por projetos ou frentes de trabalho.
Estas instituições demandam profissionais capacitados e alinhados as
boas práticas de implantação, governança e gestão de projetos, sendo este
último objeto do estudo e desenvolvimento deste trabalho. Inúmeras
instituições, dentre elas a instituição foco do nosso estudo de caso “Petrobras”,
vêm implementando o gerenciamento de projetos para atingir suas metas de
crescimento e expansão, entregar seus resultados de forma eficaz, eficiente e
com efetividade.
O presente trabalho define e descreve as metodologias de
gerenciamento de projetos que são instrumentos que reúnem processos,
artefatos, técnicas e ferramentas.
As definições e diretrizes apresentadas neste documento estão
relacionadas exclusivamente aos processos de gerenciamento de projetos de
Tecnologia da Informação na Petrobras.
Os processos de gerenciamento de projetos da Petrobras e os
processos de realização de produtos e serviços de Tecnologia da Informação
se sobrepõem e interagem ao longo do ciclo de vida do projeto. Por exemplo, o
escopo do projeto não pode ser definido de forma consistente sem que exista
uma compreensão clara dos requisitos técnicos dos produtos ou serviços que
serão desenvolvidos.
9
CAPÍTULO I
ESTRUTURAS ORGANIZACIONAIS
...Estrutura organizacional é a forma como as
empresas se articulam para desenvolver as suas
atividades. Não existe uma estrutura organizacional
acabada e nem perfeita, existe uma estrutura
organizacional que se adapte adequadamente às
mudanças.
A estrutura depende das circunstâncias de cada organização em
determinado momento. Existem variáveis que contribuem para isso: a
sua estratégia, o meio ambiente em que opera, a tecnologia de que dispõe e as
características de seus participantes. “Chandler (1962), ao pesquisar quatro
grandes empresas americanas (DuPont, GM, Standart Oil e Sears) constatou
que as estruturas dessas empresas eram continuamente ajustadas às suas
estratégias e pode demonstrar a intima relação entre a estratégia e a estrutura
organizacional”
Outra condição muito importante: é o ambiente em que a organização
atua e que é caracterizado por três tipos:
§ O ambiente estável, com pequena variação que quando
ocorre é previsível e controlável;
§ O ambiente em transformação, em que as tendências de
mudanças são visíveis e constantes;
§ O ambiente turbulento, em que as mudanças são
velozes, oportunistas e não raras e surpreendentes.
10
Tipos de Estrutura
Estrutura Formal, é uma estrutura que é planejada, é "oficial", o fluxo
de autoridade é descendente, ela é mais estável, é sujeita ao controle da
direção e pode crescer a um tamanho imenso, dependendo da organização.
As estruturas formais são, em outras palavras, a idealização da organização.
Estrutura Informal, é uma estrutura onde são identificadas a interação
social estabelecidas entre as pessoas, desse modo, progride
espontaneamente no momento que as pessoas se reúnem. Traduz as relações
que habitualmente não surgem no organograma. São comportamentos
pessoais e sociais que não são documentados e reconhecidos oficialmente
entre os membros organizacionais, aparecendo inevitavelmente em
decorrência das necessidades pessoais e grupais dos empregados. As
estruturas informais possuem algumas características:
§ Presente nos indivíduos;
§ Sempre existirão;
§ A autoridade flui na maioria das vezes na horizontal;
§ É instável;
§ Não está sujeita a controle, está sujeita aos sentimentos;
§ Líder informal;
§ Desenvolve sistemas e canais de comunicação;
§ Sistema de interação casual e espontâneo;
§ Enfoque voltado para inter-relacionamento pessoal;
§ Não são requeridos nem controlados pela administração;
§ São variáveis, dinâmicos e mudam a sua direção rapidamente;
§ Podem criar satisfação sexual;
§ Nem sempre são na relação.
11
Vantagens da estrutura informal
§ Proporciona maior rapidez no processo.
§ Complementa e estrutura formal.
§ Reduz a carga de comunicação dos chefes.
§ Motiva e integra as pessoas na empresa.
Desvantagens
§ Desconhecimento das chefias.
§ Dificuldade de controle.
§ Possibilidade de atritos entre pessoas
Estruturas organizacionais e sua relação com projetos
De acordo com o PMBOK temos basicamente três tipos de estruturas
organizacionais dentro de uma empresa: a funcional, a matricial e por
projetos. Na maioria das empresas ainda adotam o tipo mais antigo: a
organização funcional, mas a organização funcional impõe importantes
dificuldades e obstáculos no que se refere à condução e a prática do
gerenciamento de projetos. Antes de falar destas dificuldades, vamos entender
melhor o que é cada uma destas estruturas:
Organização funcional
A figura 1 abaixo, temos uma estrutura funcional onde a divisão de
áreas dentro de uma empresa está divida por especialização, ou
seja, funcionários que cuidam de pessoas estarão alocados no setor de RH,
outras que lidam com o faturamento e finanças estarão alocadas na área do
Financeiro e assim por diante. Vemos claramente que cada um dos
funcionários destas áreas são subordinados diretamente aos chefes destas
respectivas áreas.
12
Estrutura Funcional (Fígura 1)
Organização por projetos ou projetizada
A figura 2 abaixo, temos uma estrutura projetizada onde as equipes
são reunidas por projeto. Não temos aqui mais à ideia de gerentes funcionais
ou pessoas alocadas por especialização e sim pessoas alocadas por projeto e
subordinadas ao gerente responsável para um determinado projeto. Esta será
a estrutura foco de nosso trabalho.
Estrutura por Projetos (Fígura 2)
13
Organização por estruturas matriciais ou mistas
A figura 3 abaixo, temos uma estrutura matricial ou mista como o
próprio nome diz, a organização matricial é um meio-termo entre a organização
do tipo funcional e projetizada. Pode-se dizer que o objetivo de estruturas
deste tipo é reunir o melhor dos dois mundos. Depois de uma rápida
explicação de cada um dos tipos de organização, voltamos a falar sobre as
dificuldades em gerenciar um projeto em organização do tipo
funcional. Conforme vimos em uma estrutura deste tipo, os recursos estão
alocados na empresa de acordo com sua especialização.
Como se sabe, um projeto é geralmente composto por atividades
multidisciplinares, envolvendo diversos tipos de conhecimentos como exigência
para a sua execução. O problema em estruturas dos tipos funcionais refere-se
justamente nesta característica multidisciplinar do projeto: Como reunir
recursos de diversas áreas e gerencia-los com proficiência? Isto é
possível em uma estrutura deste tipo? Sim, é possível. Porém não teremos
a mesma eficácia de uma empresa organizada de forma projetizada ou
matricial.
E porque não? Em estruturas funcionais a figura do gerente de
projetos, o responsável pelo projeto tem pouca ou nenhuma autoridade sobre
os recursos do projeto. Nas estruturas funcionais as equipes estão mais
preocupadas com os serviços do dia-a-dia e das atribuições dadas pelo seu
gerente funcional do que o reporte a um questionamento ou uma data cobrada
pelo gerente de projeto, que normalmente possui o mesmo cargo hierárquico
dos recursos. Desta forma, o gerenciamento é muito mais difícil e exige do
gerente de projeto elevada quantidade de horas alocadas no gerenciamento
dos recursos humanos do projeto, comprometendo outras áreas de
conhecimento também importantes do projeto e consequentemente
provocando, na maioria das vezes, o gerenciamento inadequado do projeto
trazendo resultados desagradáveis a este.
14
Estrutura Matricial ou Mista (Fígura 3)
Projetos e Ciclo de Vida
...Projeto é um esforço temporário
empreendido para criar um produto, serviço ou
resultado exclusivo. A sua natureza temporária
indica um início e um término definidos. O término é
alcançado quando os objetivos tiverem sido
atingidos ou quando se concluir que esses objetivos
não serão ou não poderão ser atingidos e o projeto
for encerrado, ou quando o mesmo não for mais
necessário. Temporário não significa
necessariamente de curta duração. Além disso,
geralmente o termo temporário não se aplica ao
produto, serviço ou resultado criado pelo projeto; a
maioria dos projetos é realizada para criar um
resultado duradouro. PMBOK 4ª. Edição (pág.11)
15
O que é gerenciar projetos?
Gerenciar projetos é a aplicação de conhecimento, habilidades,
ferramentas e técnicas às atividades do projeto a fim de atender aos seus
requisitos. O gerenciamento de projetos é realizado através da aplicação e
integração apropriada dos 42 processos agrupados logicamente abrangendo
os 5 (cinco) grupos e podem ser vistos na figura 4. Os 5 (cinco) grupos de
processos são:
§ Iniciação;
§ Planejamento;
§ Execução;
§ Monitoramento e controle;
§ Encerramento.
Processos de Gerenciamento de Projetos (Fígura 4) Gerenciar um projeto inclui:
§ Identificação dos requisitos;
§ Adaptação às diferentes necessidades, preocupações e
expectativas das partes interessadas à medida que o projeto é
planejado e realizado;
§ Balanceamento das restrições conflitantes do projeto que
incluem, mas não se limitam a:
16
§ Escopo;
§ Qualidade;
§ Comunicação
§ Cronograma (prazos);
§ Orçamento;
§ Recursos Humanos;
§ Riscos.
Áreas de Conhecmento em Gerenciamento de Projetos (Fígura 5)
O projeto sofrerá influências das restrições nas quais o gerente
precisará se concentrar. A relação entre esses fatores ocorre de tal forma que
se algum deles mudar, pelo menos um fator provavelmente será afetado. Por
exemplo, se o cronograma for reduzido, muitas vezes o orçamento precisará
ser aumentado para incluir recursos adicionais a fim de realizar a mesma
quantidade de trabalho em menos tempo. Se não for possível um aumento no
orçamento, o escopo ou a qualidade poderá ser reduzido para entregar um
produto em menos tempo com o mesmo orçamento. As partes interessadas no
projeto podem ter ideias divergentes quanto à quais fatores são os mais
importantes, criando um desafio ainda maior. A mudança dos requisitos do
projeto pode criar riscos adicionais. A equipe do projeto deve ser capaz de
17
avaliar a situação e equilibrar as demandas a fim de entregar um projeto bem
sucedido.
Devido ao potencial de mudança, o plano de gerenciamento do projeto
é iterativo e passa por uma elaboração progressiva no decorrer do ciclo de vida
do projeto. A elaboração progressiva envolve melhoria contínua e
detalhamento de um plano conforme informações mais detalhadas e
específicas e estimativas mais exatas tornam-se disponíveis. Isto é, conforme
o projeto evolui, a equipe de gerenciamento poderá gerenciar com um nível
maior de detalhes.
18
CAPÍTULO II
PROJETOS DE TECNOLOGIA DA INFORMAÇÃO NA
PETROBRAS
Este capítulo tem a finalidade de apresentar o que são projetos de
tecnologia da informação para a empresa Petrobras, sua classificação (Projeto
ou Projeto Simples), identificar se existem metodologias de gerenciamento de
projetos de tecnologia da informação existem, quais são estas metodologias e
suas respectivas finalidades.
Projeto de Tecnologia da Informação
Para a empresa objeto de estudo, projetos de Tecnologia da
Informação basicamente estão ligados diretamente às necessidades de
provimento e soluções de infraestrutura (Servidores, Plataformas Tecnológicas,
Telecomunicações, Internet, entre outros) e Soluções de Software
(Desenvolvimento de Sistemas e Aplicativos) com a finalidade de atender as
demandas estratégias, normativas, operacionais e processos de negócios.
Observe a figura 6.
Tipos de projetos de Tecnologia da Informação (Fígura 6)
19
Na Petrobras existem metodologias de Gerenciamento de Projetos?
Sim, existem. Os padrões existem e devem ser aplicados nas diversas
tecnologias, implementações e desenvolvimento ou quando se aplicarem. Os
padrões são classificados em PP (Padrões de Processos), PG (Padrões de
Gerenciamento), PE (Padrões de Execução). No desenvolvimento deste
trabalho não serão abordados todos os padrões de gerenciamento de projetos
de tecnologia da informação, mas sim, os considerados relevantes para
atender os objetivos deste trabalho.
Em destaque os padrões, porém mais adiante serão abordadas suas
respectivas aplicações no contexto de gerenciamento que de projetos.
§ PP-XXX-000Y0 - Tratar Demandas de Clientes
§ PP-XXX-000P8 - Implementar Soluções de Software
§ PE-XXX-000D2 - Regras para Classificação da Complexidade de
Projetos de Solução de Software
§ PP-XXX-000X2 - Implementar Soluções de Infraestrutura de TI
§ PP-XXX-000N3 – Elaborar planejamento de Curto Prazo
§ PG-XXX-000J7 - Metodologia de Gerenciamento de Projetos de
Tecnologia da Informação
§ PG-XXX-000B1 - Metodologia de Gerenciamento de Projetos com
métodos Ágeis de Tecnologia da Informação
§ PE-XXX-000H3 - Monitoramento do Portfolio de Projetos de
Tecnologia da Informação e Telecomunicações
§ PE-XXX-000F5 - Revisão de Qualidade de Projetos de Tecnologia
da Informação e Telecomunicações
As codificações dos padrões deste documento são “fictícias”, por se
tratarem de informações de uso reservado, não serão divulgados números ou
informações que comprometam a segurança da informação.
20
Classificação de Projetos de Tecnologia da Informação
Os projetos podem ser classificados como projetos, projetos simples e
métodos ágeis, suas respectivas premissas, artefatos e processos são
diferenciados. A classificação de um projeto tem por finalidade determinar os
documentos e atividades a serem utilizados no gerenciamento do projeto. A
classificação é de responsabilidade do gerente de projetos e/ou
gerente/coordenador da área responsável pelo desenho, desenvolvimento e
implantação da solução.
Nesta atividade o gerente de projetos em conjunto com o(s)
Responsável (is) pelo(s) produto(s) de software analisa as características da
demanda e, com base nos requisitos de produto levantados ou na lista de
correções, quando aplicável, classifica o projeto seguindo os critérios definidos
nas tabelas de complexidade descritas no padrão “Regras para Classificação
da Complexidade de Projetos de Solução de Software”.
. Para cada metodologia de desenvolvimento de software padronizada
há uma tabela de complexidade que descreve critérios que contribuem para
determinar se um projeto é Projeto ou Projeto Simples. A tabela relativa a um
produto que não utiliza uma das metodologias padronizadas é nomeada como
“sem metodologia".
Quando a solução for composta por mais de um produto, os
Responsável (is) pelo(s) produto(s) de software devem consultar as tabelas de
critérios correspondentes às suas tecnologias de desenvolvimento na escolha
da lista mais adequada para classificar o projeto.
Esta classificação deve ser registrada na própria tabela de
complexidade e armazenada juntamente com os outros documentos do
projeto. Entretanto, se a classificação do projeto for baseada em uma decisão
gerencial, esta deve ser devidamente documentada através de, por exemplo,
ata de reunião, ou e-mail e armazenada, sendo dispensado o preenchimento
da tabela de complexidade.
21
Ciclo de vida dos Projetos de Tecnologia da Informação
O ciclo de vida do gerenciamento do projeto é composto dos seguintes
grupos de processos: iniciação, planejamento, execução, monitoramento e
controle e encerramento. A forma como cada atividade será executada, será
descrita em seu respectivo padrão de gerenciamento de projetos, conforme
padrões a seguir: Observe figura 7
Tipos de projetos de Tecnologia da Informação (Fígura 7)
22
CAPÍTULO III
PADRÕES DE GERENCIAMENTO DE PROJETOS –
ESTUDO DE CASO NA PETROBRAS
Padrões de Gerenciamento de Projetos
Os padrões de gerenciamento de projetos, têm a finalidade de orientar
(o que fazer?), definir responsabilidades e processos (quem e como fazer?),
métricas (quando fazer?) e premissas para monitoramento e controle dos
eventos do projeto.
Padrão PP-XXX-000Y0 - (Tratar Demandas de Clientes)
O processo define as atividades necessárias para identificação das
necessidades e tratamento das demandas de TIC. São descritos os
mecanismos para elaboração da (PAD) Proposta de Atendimento da Demanda
que ao final do processo é encaminhada para validação do cliente.
O padrão define os canais de entrada e formas de tratamento da
demanda, processos de classificação e definição das tecnologias a serem
adotadas (NOTES, JAVA, SAP, outras).
PAD (Proposta de Atendimento da Demanda), e a proposta que
evidencia uma visão macro da solução a ser detalhada posteriormente em um
projeto de implementação. Caracteriza o que a gerência provedora da solução
recomenda para atender e satisfazer os requisitos de negócio especificados
pelo cliente. A elaboração da proposta é iniciada na atividade “Definir Escopo”,
quando o Documento de Escopo começa a ser elaborado e é finalizada na
atividade “Estimar Prazo e Custo”, quando são determinadas faixas de prazo e
custo para o atendimento da demanda. O prazo total para a sua finalização é
de até 30 dias corridos após o início do atendimento. Após a finalização da
estimativa, a demanda com a sua respectiva proposta de atendimento é
23
encaminhada para aprovação, ou no caso de pré-aprovada, para ciência do
cliente.
O padrão orienta quanto às competências, premissas, descrevem e
Apresentam fluxos de tratamento de cada atividade a ser realizada:
§ Papéis e Responsabilidades
§ Envolvidos
§ Eventos
§ Premissas
§ Atividades
ü Identificar necessidade;
ü Analisar necessidade;
ü Apoiar processo integrado;
ü Definir escopo;
ü Verificar possibilidade integração;
ü Elaborar requisitos de negócio;
ü Estimar prazo e custo;
ü Verificar se a demanda está pré-aprovada;
ü Aprovar proposta de atendimento da demanda;
ü Notificar cliente;
ü Verificar se a demanda tratada em portfólio de clientes;
ü Encaminhar para atendimento;
Padrão PP-XXX-000P8 - (Implementar Soluções de Software )
Este padrão descreve como desenvolver novas soluções de software,
realizar manutenções adaptativas, evolutivas ou corretivas planejadas, realizar
a adaptação e implantação de soluções e prover consultorias que demandem
atividades de desenvolvimento de software. O processo Implementar Soluções
de Software descreve as atividades realizadas a partir da aprovação da
demanda até a disponibilização de uma solução de software ou parecer para o
cliente. O processo abrange a execução dos seguintes tipos de serviços:
24
§ Novos desenvolvimentos (criação de novo software ou
componentes integrantes de software);
§ Manutenções evolutivas, adaptativas e corretivas planejadas
(intervenção em um software existente, acrescentando ou
alterando requisitos, ou corrigindo código);
§ Adaptação e implantação de soluções (intervenção em uma
solução necessária para a sua implantação na Infraestrutura
padrão ou somente implantação na Infraestrutura padrão para
futura manutenção);
§ Consultorias com desenvolvimento (estudos de viabilidade
técnica ou desenvolvimento de protótipos que não geram solução
em produção).
O padrão orienta quanto às competências, premissas, descrevem e
Apresentam fluxos de tratamento de cada atividade a ser realizada:
§ Papéis e Responsabilidades
§ Envolvidos
§ Eventos
§ Premissas
§ Atividades
ü Iniciar atendimento da demanda;
ü Iniciar Projeto;
ü Levantar requisitos;
ü Analisar problemas para correção;
ü Avaliar viabilidade para infraestrutura;
ü Classificar projeto de Software;
ü Planejar projeto de Software;
ü Planejar Solução de Software;
ü Solicitar aprovação do plano de projeto;
ü Controlar projeto;
25
ü Detalhar iteração;
ü Gerenciar Configuração de Software;
ü Construir Solução de Software;
ü Especificar requisitos de produto;
ü Projetar Software;
ü Administrar dados;
ü Implementar Software;
ü Realizar Inspeção;
ü Projetar testes;
ü Executar testes;
ü Homologar software;
ü Solicitar implantação do Software;
ü Estabilizar Software;
ü Encerrar projeto;
Padrão PE-XXX-000D2 - (Regras para Classificação da
Complexidade de Projetos de Solução de Software)
Este padrão tem a finalidade de definir o procedimento para
avaliação da complexidade dos projetos de soluções de software na
gerência de tecnologia da informação. Este padrão deve ser utilizado
durante a atividade Classificar Projeto no processo implementar Soluções
de Software;
O Responsável Técnico pela Solução deve identificar a metodologia
de desenvolvimento utilizada no projeto da solução de software;
De acordo com a tecnologia a ser utilizada, deve-se acessar o
documento correspondente na seção de anexos deste padrão com os
critérios de classificação da complexidade;
Caso não tenha sido escolhida uma das tecnologias padronizadas,
deve-se utilizar os critérios de classificação para aplicações sem
26
metodologia;
Para cada critério apresentado, devem-se identificar os valores que
satisfazem as características do projeto;
Deve-se interpretar a totalidade dos critérios, identificando assim, a
complexidade do projeto de solução de software. A classificação pode
remeter a um Projeto ou a um Projeto Simples, conforme definição da
Metodologia de Gerenciamento de Projetos de Tecnologia da Informação.
O padrão orienta quanto às competências, premissas, descrevem e
Apresentam fluxos de tratamento de cada atividade a ser realizada:
§ Papéis e Responsabilidades
§ Descrição
§ Planilhas com critérios de classificação da complexidade;
PP-XXX-000X2 - Implementar Soluções de Infraestrutura de TI
Este padrão tem a finalidade de definir o procedimento para
Realizar projeto de implementação e disponibilização de soluções de
infraestrutura de TI, de acordo com requerimentos do Cliente ou de áreas
de negócio, tais como: Novo serviço de infraestrutura; Melhoria operacional;
Infraestrutura para suporte a soluções de negócio e Integração de novas
unidades.
Uma demanda de Infraestrutura de TI, tem a finalidade de atender a
um conjunto de requisitos de negócio de clientes ou uma oportunidade de TI
adequadamente delineada, e caracterizada por um escopo definido
(requisitos e riscos para o negócio), benefícios esperados, macro estimativa
de prazo e custo para atendimento, e eventuais condicionantes (premissas,
fatores críticos de sucesso, restrições etc.).
O padrão orienta quanto às competências, premissas, descrevem e
Apresentam fluxos de tratamento de cada atividade a ser realizada:
§ Papéis e Responsabilidades
27
§ Descrição
§ Fluxogramas de processo
§ Atividades
ü Analisar demanda;
ü Designar Responsável Técnico pela Solução;
ü Classificar projeto de infraestrutura;
ü Descrever solução;
ü Elaborar desenho da solução;
ü Tratar necessidades adicionais do projeto;
ü Aprovar alternativa de solução;
ü Elaborar plano do projeto;
ü Elaborar plano de testes;
ü Calcular custo da implantação e manutenção da
solução;
ü Identificar necessidades de aquisição;
ü Consolidar plano de gerenciamento de projeto;
ü Aprovar plano de gerenciamento de projeto;
ü Preparar construção de solução técnica;
ü Executar atividades não técnicas do projeto;
ü Testar solução de infraestrutura de TI;
ü Realizar piloto da solução de infraestrutura de TI;
ü Preparar disponibilização da solução em produção;
ü Realizar atividades para disponibilizar solução em
produção;
ü Coordenar a execução das atividades para disponibilizar
solução em produção;
ü Formalizar aceite do projeto;
ü Controlar projeto;
ü Concluir projeto;
28
PP-XXX-000N3 - Elaborar planejamento de Curto Prazo
Este padrão tem a finalidade de descrever o processo de
planejamento de curto prazo, alinhado à Focalização Estratégica da
gerência de tecnologia da informação, composto por atividades
orçamentárias, atividades de avaliação tecnológica, de planejamento de
projetos e ações por cada gerência e pelo planejamento do
desenvolvimento de recursos humanos.
Focalização Estratégia é a tradução do Plano Estratégico da
Petrobras, dos direcionadores da Diretoria de Serviços e dos Planos de
Negócios dos Clientes para a realidade da gerência de tecnologia da
informação, com base em análise de cenários e nas tendências do mercado
de TI e Telecom. Define todas as orientações de âmbito estratégico para a
atuação da gerência de tecnologia da informação, incluindo imperativos,
objetivos, indicadores, metas e iniciativas estratégicas. Os indicadores e
iniciativas estratégicas devem ser desdobrados em programas, projetos e
ações táticas visando o desenvolvimento dos mesmos. O padrão orienta
quanto às competências, premissas, descrevem e Apresentam fluxos de
tratamento de cada atividade a ser realizada:
§ Papéis e Responsabilidades
§ Envolvidos
§ Eventos
§ Premissas
§ Atividades
ü Elaborar orientações para planejamento Anual de
Negócios (PAN);
ü Indicar planejadores de custos de pessoal (homem
hora);
ü Realizar planejamento de custos de pessoal (homem
hora);
ü Avaliar sistemas existentes;
29
ü Elaborar modelo do plano de trabalho;
ü Consolidar avaliação de sistemas;
ü Levantar necessidades que não sejam projetos para
clientes;
ü Programar necessidades e capacidades no sistema
corporativo (SAP);
ü Consolidar planejamento orçamentário;
ü Enviar plano de trabalho preenchido com informações
do planejamento anual de negócios (PAN);
ü Elaborar plano de trabalho das gerências;
ü Consolidar plano tático da gerência de tecnologia da
informação;
ü Verificar viabilidade do plano tático da gerência de
tecnologia da informação;
ü Ratificar plano tático da gerência de tecnologia da
informação;
ü Formalizar plano tático da gerência de tecnologia da
informação;
ü Realizar planejamento do desenvolvimento de RH;
PG-XXX-000J7 - Metodologia de Gerenciamento de Projetos de Tecnologia
da Informação
O objetivo desse documento é estabelecer as definições e diretrizes
da Metodologia de Gerenciamento de Projetos de Tecnologia da
Informação. A abrangência deste padrão restringe-se aos projetos que
utilizam metodologia de gerenciamento de projetos tradicional, exclui-se
deste os projetos de métodos ágeis.
As definições e diretrizes apresentadas neste padrão estão
relacionadas exclusivamente com os processos de gerenciamento de
projetos da gerência de tecnologia da informação. Entretanto, os processos
30
de realização de produtos e serviços, que estão associados aos diferentes
tipos de projetos, também precisam ser considerados dentro do Plano de
Gerenciamento do Projeto.
Todos os documentos/registros definidos nesta metodologia
auxiliam no desenvolvimento do projeto e geram uma base de
conhecimento que contribui para o gerenciamento de projetos de TI na
Petrobras.
Por esse motivo foi definido um conjunto mínimo de
documentos/registros cuja utilização é obrigatória para Projetos e Projetos
Simples, são indispensáveis na condução de um projeto. Os demais há
uma forte recomendação para sua utilização.
Tipos de projetos de Tecnologia da Informação (Fígura 8)
Projetos
Artefatos de projetos de Tecnologia da Informação (Fígura 9)
31
Para projetos simples há uma redução na quantidade de
documentos/registros obrigatórios e uma simplificação no conteúdo do
Plano de Gerenciamento do Projeto
Projetos Simples
Artefatos de projetos simples de Tecnologia da Informação (Fígura 9)
O padrão orienta quanto às competências, premissas, descrevem e
Apresentam fluxos de tratamento de cada atividade a ser realizada:
§ Papéis e Responsabilidades
§ Envolvidos
§ Premissas
§ Atividades
ü Iniciação do projeto;
§ Designar responsável pelo projeto;
§ Classificar projeto.
32
Processo de Iniciação de Projetos de Tecnologia da Informação Fígura 10)
ü Planejamento do projeto;
§ Constituir equipe de planejamento do projeto;
§ Elaborar declaração de escopo do projeto;
§ Elaborar estrutura analítica do projeto;
§ Constituir equipe de execução do projeto;
§ Elaborar cronograma do projeto;
§ Detalhar orçamento do projeto;
§ Definir critérios de aceitação;
§ Elaborar plano de comunicação;
§ Elaborar matriz de responsabilidades;
§ Elaborar plano de riscos;
§ Elaborar plano de aquisições;
§ Solicitar validação do plano de GP;
§ Obter aprovação do plano de GP.
33
Processo de planejamento de Projetos de Tecnologia da Informação (Fígura 11)
ü Execução do projeto;
§ Iniciar execução do projeto;
§ Gerenciar Execução dos Trabalhos do Projeto;
§ Distribuir informações do projeto.
34
Processo de Execução de Projetos de Tecnologia da Informação (Fígura 13)
ü Monitoramento e controle do projeto;
§ Acompanhar desempenho do projeto;
§ Gerenciar solicitações de mudança do projeto;
§ Monitorar e controlar qualidade do projeto;
§ Monitorar e controlar riscos do projeto;
§ Monitorar e controlar Aquisições do projeto;
§ Obter aceitação das entregas do projeto;
§ Registrar lições aprendidas.
35
Processo de Controle de Projetos de Tecnologia da Informação (Fígura 14)
ü Encerramento do projeto;
§ Obter aceitação final;
§ Documentar lições aprendidas;
§ Encerrar o projeto
Processo de Encerramento Projetos de Tecnologia da Informação (Fígura 15)
36
PG-XXX-000B1 - Metodologia de Gerenciamento de Projetos com métodos
Ágeis de Tecnologia da Informação
O objetivo deste documento é estabelecer as definições e diretrizes
da Metodologia de Gerenciamento de Projetos com Métodos Ágeis para
implementação de soluções de software na gerência de tecnologia da
Informação.
Este padrão de gerenciamento de projetos descreve as atividades
relacionadas à condução de um projeto, apoiando a coordenação das
funções dos Times e a gestão dos fatores externos ao projeto. Ele foca o
método Scrum, que é fundamentado na teoria de controle de processos
empíricos e emprega uma abordagem iterativa e incremental para otimizar a
previsibilidade e controlar os riscos.
O Scrum utiliza o conceito de projetos de escopo flexível, que se
baseia na premissa de que existe baixa previsibilidade sobre o que será
feito no software, dentro dos limites de prazo e custo pré-aprovados.
Métodos ágeis referem-se a um grupo de metodologias de
desenvolvimento de software com base no desenvolvimento iterativo, no
qual os requisitos e as soluções evoluem através da colaboração entre
equipes auto organizadas e multifuncionais.
A figura a seguir representa de forma macro o fluxo de trabalho
desta metodologia de gerenciamento de projetos.
Processo de Projetos com Métodos Ágeis Tecnologia da Informação (Fígura 16)
Os projetos de métodos ágeis possuem as seguintes características:
37
Projeto de escopo flexível - Projeto que se baseia na premissa de
que existe baixa previsibilidade sobre o que será feito no software, mesmo
que seja possível haver previsibilidade em relação aos gastos e ao tempo
de desenvolvimento. O cliente inclui, exclui e altera funcionalidades
repriorizando-as periodicamente, de modo que as mais valiosas sejam
implementadas dentro do custo e prazo aprovados.
Quadro de acompanhamento da Sprint - Conjunto de informações
visuais que podem estar em um quadro próximo ao Time. Em geral é
composto de colunas que indicam os estados de desenvolvimento de um
item do backlog da Sprint além de outras informações como o gráfico de
acompanhamento da Sprint, impedimentos e itens não planejados.
Release - Conjunto de Sprint, funcionalidades ou marcos contidos
no projeto.
Sprint - São eventos com duração fixa (time-box). Cada Sprint
consiste na reunião de planejamento da Sprint, o trabalho de
desenvolvimento, a demonstração do produto de software e a retrospectiva.
As Sprint ocorrem uma após a outra, sem intervalos entre elas.
Superior imediato - Trata-se do(s) superior(es) imediato(s) da área
técnica executora do projeto.
Teste automatizado – Uso de software para controlar a execução
de testes de software, através da comparação dos resultados esperados
com os resultados reais.
Time - Designa somente o grupo de pessoas que trabalham para
transformar o backlog do produto em incrementos de funcionalidades do
software. O Scrum Master pode ser parte do Time, se executar tarefas
como membro. No Time não estão incluídas as pessoas que representam
as interfaces externas.
Time auto organizado - O Time tem a responsabilidade de definir a
maneira de transformar o backlog do produto em incrementos de
funcionalidades entregáveis. A atribuição das tarefas é feita pelo próprio
Time.
38
Time multidisciplinar - Time que possui todas as habilidades e o
conhecimento necessários para criar um incremento no trabalho.
Velocidade - Capacidade de produção do Time em uma Sprint.
Contexto para adoção desta Metodologia
Para a utilização desta metodologia, devem ser atendidas as seguintes
condições:
§ O projeto deve ser dividido em sprints, com no mínimo duas;
§ O Time deve conter no máximo 9 integrantes; e
§ As sprints devem ter a duração entre uma e quatro semanas.
Para que a aplicação desta metodologia possa atingir os resultados
esperados, recomenda-se que:
§ Os envolvidos estejam alinhados com os valores e princípios
descritos no Manifesto Ágil e com os pilares do Scrum;
§ Para exercer o papel de Scrum Master, o profissional tenha
recebido capacitação. Além disso, possua experiência anterior
com Scrum ou receba coaching de um Scrum Master mais
experiente;
§ O Product Owner e o Time tenham participado da
apresentação de nivelamento;
§ O cliente e as interfaces externas estejam cientes de que o
projeto será conduzido com metodologia ágil de gerenciamento
de projeto e suas respectivas atuações neste contexto;
§ O cliente participe das reuniões de demonstração do produto
de software para discutir o andamento do projeto ao menos uma
vez por mês;
§ Sejam utilizados testes de software automatizados;
39
§ Os membros do Time tenham dedicação integral ao projeto.
Caso não seja possível, que as pessoas permaneçam no projeto
do início ao fim de uma Sprint que seja avaliado o risco de não
haver a dedicação do Time ao projeto.
O padrão orienta quanto às competências, e diferente dos projetos
que utilizam metodologia tradicional de gerenciamento de projetos, tem
premissas e métricas específicas para as atividades a serem realizadas:
§ Papéis e Responsabilidades
§ Envolvidos
§ Premissas
§ Artefatos do Scrum
§ Backlog do Produto
§ Backlog da Sprint
§ Gráfico de Burndown da Sprint
Gráfico de Burndown da Sprint de Projeto Métodos Ágeis - TI (Fígura 17)
40
§ Gráfico de Burnup do Produto
Gráfico de Burnup do produto de Projeto Métodos Ágeis - TI (Fígura 18)
§ Práticas e Reuniões do Scrum
ü Reunião de planejamento da Realease;
ü Reunião de planejamento da Sprint;
ü Reunião Diária;
ü Demonstração do produto de software;
ü Retrospectiva;
§ Acompanhamento gerencial do projeto;
§ Replanejamento do projeto;
§ Encerramento do projeto;
§ Relacionamento com interfaces externas;
ü Infraestrutura;
ü Banco de Dados;
ü Inspeção / Teste / Gerência/ Configuração / Design /
Apoio ao usuário;
ü Integração com outros sistemas;
41
PE-XXX-000H3 - Monitoramento do Portfolio de Projetos de Tecnologia da
Informação e Telecomunicações
O objetivo deste padrão é estabelecer um modelo de
Monitoramento do Portfólio de Projetos de Tecnologia da Informação para
projetos que utilizam a Metodologia de Gerenciamento de Projetos
tradicional e com Métodos Ágeis.
O Monitoramento do Portfólio de Projetos de tecnologia da
informação abrange projetos que utilizam a Metodologia de Gerenciamento
de Projetos (tradicional) e projetos que utilizam Metodologia de
Gerenciamento de Projetos com Métodos Ágeis, padronizando o
procedimento e uniformizando as informações da situação dos projetos para
os diversos níveis gerenciais.
O Monitoramento do Portfólio de Projetos considera, para efeito de
acompanhamento, todos os projetos planejados para o ano (status: não
iniciado, andamento, concluído, suspenso e cancelado) devidamente
segmentados como: Prioritários (PR), que são os projetos selecionados
pelo Gerente Executivo para acompanhamento; Gerenciais (G1), que são
os projetos selecionados pelos gerentes de 1º nível para acompanhamento;
e Projetos da Tecnologia da Informação (PTIC), que é o conjunto dos
projetos do Plano Tático.
O Monitoramento utiliza os seguintes indicadores: desvio percentual
de prazo, desvio percentual de custo e desvio percentual de homem hora
(HH) como base para a análise de saúde do projeto tradicional e satisfação
quanto ao andamento do projeto, desvio percentual de custo e desvio
percentual de HH como base para a análise de saúde do projeto com
métodos ágeis.
Os indicadores de saúde (andamento) dos projetos são gerados a
partir dos seguintes relatórios:
42
Relatório de Acompanhamento de Projetos (RAP): Relatório com
informações referente a um projeto, que contém:
§ Indicadores, entregáveis, principais atividades e pontos de
atenção de responsabilidade do responsável pelo projeto para
projetos tradicionais,
§ Indicadores, satisfação quanto ao andamento do projeto e
pontos de atenção de responsabilidade do responsável pelo
projeto para projetos com métodos ágeis.
Relatório Consolidado de Projetos (RCP): Relatório consolidado
dos projetos do Plano de Trabalho da área, que contém:
§ Relação de projetos, os indicadores dos projetos, o segmento
dos projetos e a visão dos Projetos sob responsabilidade do
Escritório de Gerenciamento de Projetos local e estratégico.
Relatório Gerencial de Projetos (RGP): Relatório consolidado dos
projetos do Plano de Trabalho da área, que contém:
§ Descrição doe projeto, EAP, entregáveis e os pontos de
atenção de responsabilidade do responsável pelo projeto para
projetos tradicionais;
§ A descrição do projeto e os pontos de atenção de
responsabilidade do responsável pelo projeto para projetos com
métodos ágeis.
Relatório Gerencial de Cliente (RCLI): Relatório com informações
referentes a um projeto destinado aos clientes da gerência de tecnologia da
informação que contém:
§ Informações sobre o projeto, a situação do projeto, a avaliação
do projeto e o acompanhamento do projeto, sob
responsabilidade do responsável pelo projeto.
O padrão orienta quanto às competências, premissas, descrevem e
43
apresentam fluxos de tratamento de cada atividade a ser realizada:
§ Papéis e Responsabilidades
§ Envolvidos
§ Premissas
§ Indicadores de Projetos
§ Análise de Projetos
ü Desvio percentual padrão;
ü Desvio percentual de custos;
ü Desvio percentual de homem hora (HH);
Semáforo com os desvios de indicadores - (Fígura 19)
Indicadores de Desvios - (Fígura 20)
§ Satisfação quanto ao Andamento do Projeto
§ Situação geral do projeto
§ Pontos de atenção
§ Análise consolidada
§ Local e tempo de armazenamento
§ Método de descarte de documentos
44
PE-XXX-000F5 - Revisão de Qualidade de Projetos de Tecnologia da
Informação e Telecomunicações
O objetivo deste documento é estabelecer as definições e
procedimentos para a condução das Revisões de Qualidade de Projetos de
Tecnologia da Informação.
Revisão de Qualidade de Projeto (RQP), é um evento periódico que
visa auxiliar o responsável pelo projeto na verificação e na garantia da
qualidade de um projeto específico, segundo os padrões determinados pela
Metodologia de Gerenciamento de Projetos de Tecnologia da Informação e
as melhores práticas de Gerenciamento de Projetos citadas no PMBOK do
Project Management Institute (PMI).
A revisão da qualidade provê um segundo nível de controle dos
projetos, sob a ótica de um revisor independente. Ele permite uma visão
imparcial do progresso do projeto, nos seus aspectos de escopo, custo e
prazo, das ações de gerenciamento de riscos e comunicação e da
satisfação do cliente. O revisor independente deve fazer parte do Escritório
de Projetos Estratégico ou do Escritório de Projetos Local e não deve ter
envolvimento direto com o projeto.
A revisão de qualidade deve ser aplicada a todos os projetos
prioritários. Adicionalmente, o Escritório de Gerenciamento de Projeto
(EGP) da área e a Gerência poderão eleger outros projetos que serão
objeto da revisão de qualidade no ano, tais como projetos gerenciais cujos
indicadores estejam comprometidos como por exemplo, grande atraso no
prazo do projeto.
A revisão da qualidade deve envolver entrevistas com o responsável
pelo projeto e o preparo do relatório final da revisão da qualidade.
A duração das entrevistas e do preparo do relatório deve ser
proporcional ao tamanho e à complexidade do projeto, assim como sua
45
periodicidade. Informação suficiente deve ser coletada para dar subsídio à
geração do relatório final, incluindo uma avaliação geral do projeto e as
ações preventivas / corretivas que devem ser tomadas, se for o caso.
É importante lembrar que o relatório final da revisão da qualidade
não substitui o Relatório de Acompanhamento de Projeto (RAP) elaborado
mensalmente, mas sim o complementa.
O objetivo final da revisão da qualidade é aumentar a taxa de
sucesso dos projetos, visando alcançar ou superar as expectativas do
cliente, o que deve ser perseguido por todos os escritórios de projetos.
Objetivos
Os principais objetivos das revisões de qualidade de projetos são os
seguintes:
§ Verificar e garantir a utilização correta da Metodologia de
Gerenciamento de Projetos de Tecnologia da Informação;
§ Verificar e garantir a geração e a conformidade dos principais
produtos de cada fase do projeto, de acordo com a Metodologia de
Gerenciamento de Projetos de Tecnologia da Informação;
§ Assegurar que o projeto esteja sendo conduzido com um efetivo
gerenciamento dos riscos, com a identificação e tratamento dos
riscos e oportunidades do projeto;
§ Assegurar que o projeto esteja sendo conduzido com um efetivo
gerenciamento das comunicações, com o uso adequado do plano
de comunicações do projeto;
§ Assegurar que as políticas estabelecidas pela Companhia sejam
seguidas;
§ Verificar a situação dos principais indicadores adotados para
medir a evolução dos projetos em relação ao que foi planejado;
§ Promover o relacionamento entre a equipe do projeto e o cliente;
§ Propor ações preventivas e corretivas que possam melhorar e
garantir a qualidade do projeto, como suporte à atuação do
responsável pelo projeto;
46
§ Confirmar a implantação de ações preventivas e corretivas.
Itens de Acompanhamento
A revisão da qualidade cobre diversos aspectos do projeto, como
gerencial, técnico, financeiro, com o foco na qualidade do projeto, no
gerenciamento de riscos e das comunicações. Ela determina, através do
exame dos relatórios do projeto, sua documentação e das entrevistas com o
responsável pelo projeto e com a equipe de projeto, se o projeto está
atendendo aos seus objetivos e, caso contrário, que ações devem ser tomadas
para que o projeto volte ao curso planejado.
Os itens de acompanhamento representam aspectos do projeto que
devem ser analisados pelo revisor e são utilizados para a pontuação do
projeto. São eles:
§ Atendimento de ações preventivas e corretivas propostas;
§ Aspectos financeiros;
§ Consistência e nível de gerenciamento dos riscos;
§ Consistência e nível de gerenciamento de stakeholders;
§ Controle de mudanças;
§ Critérios de aceitação de acordo com o Cliente;
§ Nível de atualização do Plano de Gerenciamento do Projeto;
§ Entregáveis do projeto.
Sistemática da Revisão de Qualidade
As Revisões de Qualidade do Projeto (RQP) poderão ser realizadas
em ciclos de três etapas, conduzidas por um revisor conforme a seguir.
§ Primeira Etapa: Revisão da Documentação Atualizada
A primeira etapa envolve a pesquisa da documentação
atualizada do projeto pelo EGP da área ou local no repositório oficial de
Tecnologia da Informação e Telecomunicações. O revisor será um integrante
47
do EGP da área ou local que irá analisar a documentação do projeto de acordo
com os itens descritos no item 6.3 deste documento.
§ Segunda Etapa: Reuniões de Revisão de Qualidade do Projeto
A segunda etapa consiste na realização de uma reunião para discutir
itens de não conformidade identificados pelo revisor, esclarecer dúvidas deste
e apresentar as ações preventivas e corretivas eventualmente propostas.
Essas reuniões obedecerão a uma agenda prévia elaborada pelo EGP
da área ou local. Cada reunião contará com a participação do revisor
previamente designado da equipe do EGP, o responsável pelo projeto e o
coordenador de projetos ou programa, quando aplicável. Quando necessário
envolver também o cliente, outros membros selecionados da Equipe do Projeto
ou qualquer outro interessado no projeto, cuja presença o revisor achar
necessária.
O revisor poderá determinar a necessidade ou não da participação do
cliente numa determinada revisão com o objetivo de verificar o andamento do
projeto sob a ótica do cliente, bem como registrar seu grau de satisfação,
sendo que, em alguns casos, ele poderá agendar reuniões apenas com a
participação do cliente e sem a participação do responsável pelo projeto.
§ Terceira Etapa: Classificação de Desempenho do Projeto
Para se obter a classificação de desempenho do projeto, é necessário
atribuir uma nota a cada item revisado e calcular a pontuação do projeto.
A atribuição das notas é realizada pelo revisor após a reunião de
revisão de qualidade. O revisor utiliza as questões do Checklist para avaliar
cada item. A nota atribuída determina o nível de conformidade do item revisado
segundo critérios apresentados a seguir.
48
Observação: - Na próxima reunião de revisão este item deve ser levado em
consideração e o relator deve buscar as evidências que indiquem que as ações
recomendadas no relatório anterior foram atendidas (atas, emails, artefatos
entre outros).
Observações:
- Note que as questões do Checklist relativas aos aspectos
financeiros do projeto compreendem: questões obrigatórias, cuja resposta
somente pode ser afirmativa ou negativa; e questões onde é admissível a
resposta não se aplica. As questões marcadas como "não se aplica" são
expurgadas do cálculo de conformidade.
- Para as áreas que têm projetos e não apontam horas nos
mesmos, este item inteiro será considerado como não aplicável.
49
Observação:
- É fortemente recomendado que o projeto possua um Plano de
Riscos, nestes casos as questões do Checklist serão respondidas e o nível de
conformidade será calculado conforme os percentuais acima descritos. Caso
não haja Plano de Riscos, o item inteiro deverá ficar com status "não se
aplica".
Observação:
- É fortemente recomendado que o projeto possua um Plano de
Comunicação, nestes casos as questões do Checklist serão respondidas e o
nível de conformidade será calculado conforme os percentuais acima
descritos. Caso não haja Plano de Comunicação, o item inteiro deverá ficar
com status "não se aplica".
- Atualmente não existem artefatos específicos para os itens
"cargo” e função dos “stakeholders" e comprometimento, envolvimento e
importância dos stakeholders chave do projeto. Para estes dois sub itens a
evidência da análise está relacionada a documentos anexados com estas
informações.
50
Observação:
- Caso não tenham havido solicitações de mudanças no período
analisado, o item inteiro deverá ficar com status “não se aplica".
Observação:
- Para o sub item "Os termos de aceitação (TAE intermediário ou
final) refletem estes critérios" a resposta poderá ser "não se aplica" caso não
tenham ocorrido entregas no período.
Observação:
51
- Para os sub itens relacionados à Matriz de Responsabilidade,
Plano de Comunicação e Plano de Aquisição, a resposta poderá ser "não se
aplica" caso o projeto não possua estes itens.
Observação:
- Caso não tenha havido entregas no período analisado, o item
inteiro deverá ficar com status "não se aplica".
A pontuação do projeto corresponde ao somatório das notas
recebidas em cada item de controle.
Pontuação do Projeto = Notas
A classificação de desempenho é atribuída conforme a tabela
abaixo e pode alterar a periodicidade dos ciclos de revisões conforme
detalhado no item Periodicidade dos Ciclos de Revisão que está descrito mais
adiante nesse documento.
§ Desempenho Técnico - O relator deve descrever os principais
pontos relativos ao desempenho técnico do projeto, tais como:
ü As boas práticas estão sendo empregadas?
ü Quais fatores estão impactando negativamente ou
positivamente os indicadores de desempenho do projeto?
§ Observações do Cliente - O relator deve registrar os principais
pontos observados pelo cliente.
52
§ Avaliação Geral - O relator deve registrar a avaliação geral do
projeto. O relator leva em consideração na análise a visão
completa : situação dos indicadores, atendimento às ações
corretivas, tratamento das recomendações anteriores(caso
aplicável), atualização do PGP, controle de mudanças, entregáveis.
entre outros.
§ Comentários Adicionais - O relator deve registrar os
comentários adicionais relativos à verificação (observações,
ressalvas e pendências).
§ Recomendações - O relator deve registrar as recomendações
realizadas durante a revisão de qualidade. Para cada
recomendação irá preencher a descrição da recomendação, o
prazo para atendimento, o responsável (nome/chave) e os itens de
ação relativos à recomendação. O responsável pelo projeto deverá
notificar o relator quando da realização da recomendação para que
o relator atualize a data de realização da recomendação.
Revisor da Qualidade
O Escritório de Gerenciamento de Projetos (EGP) será responsável
pela indicação dos revisores de cada projeto, levando em consideração a
experiência a ser agregada durante as revisões e buscando complementar ou
apoiar o responsável pelo projeto. Desta forma, a experiência técnica do
revisor poderá ser distinta da experiência do responsável pelo projeto.
Para maximizar os benefícios da revisão, deverá ser designado um
revisor fixo por projeto, que, em conjunto com o responsável pelo projeto,
poderá trocar experiências ao longo da vida do projeto, buscando atingir o
sucesso do mesmo, como um integrante da equipe, através de uma maior
interação e comprometimento.
53
Cabe ao revisor, elaborar um Relatório de Revisão de Qualidade do
Projeto, segundo o modelo descrito neste documento, o qual deverá ser
validado por todos os participantes da reunião de revisão. Após essa
validação, o relatório deverá ser encaminhado para o EGP e distribuído para
todos os participantes da reunião e aos demais interessados do projeto,
conforme estabelecido no Plano de Comunicação. Uma cópia deste relatório
deverá ser enviado para a gerência de tecnologia da Informação.
§ Periodicidade dos Ciclos de Revisão
A periodicidade dos ciclos de revisão do projeto pode ser
trimestral, bimestral, mensal ou quinzenal, com base na duração e
na última classificação de desempenho do projeto.
Observação: Caso a área julgue necessário que as revisões de
qualidade sejam realizadas em períodos menores que o indicado acima, ela
poderá determinar esta periodicidade, desde que seja inferior ao determinado
por este padrão.
§ Relatório
O relatório da revisão da qualidade deve incluir, além dos
indicadores, uma avaliação geral e opinião do revisor sobre as
questões do projeto. O reporte dos itens levantados, das
conclusões e das recomendações deve ser feito em tempo hábil;
54
em até 5 (cinco) dias para os projetos amarelos e vermelhos e em
até 10 (dez) dias para os projetos verdes. Os resultados do
relatório devem ser discutidos e avaliados pelo representante do
escritório de projetos e pelo responsável pelo projeto. O relatório
também deverá ser encaminhado aos principais interessados dos
projetos de forma a comunicar o status atual do projeto e para que
as ações necessárias sejam tomadas, se for o caso.
55
CONCLUSÃO
Diante do presente estudo foi observado que com os constantes
avanços e inovações tecnológicas, o mercado demanda profissionais com
qualificação adequada para atuarem em diversas situações no âmbito de
gerenciamento de projetos de tecnologia da informação (TI). Evidencia-se é
indispensável para as empresas rever seus processos de gestão, metodologias
aplicadas e ferramentas relacionadas ao gerenciamento efetivo e eficaz de
projetos.
Na instituição objeto deste estudo de caso (Petrobras), a maior
empresa do pais que possui destaque internacional, utiliza a metodologia de
gerenciamento de projetos, segundo PMBOK do Project Management Institute
(PMI), adequando seus processos de tecnologia da informação as práticas,
processos e ferramentas para atingir seus objetivos operacionais e
estratégicos.
Desta forma ao desenvolver este trabalho foi verificado que a
instituição objeto de estudo desenvolvera diversas metodologias e práticas
para gerenciamento efetivo e eficaz de seus projetos de tecnologia da
informação (TI), inclusive mais de uma, já que em várias situações são
complementares. Porém, cabe ressaltar que a obtenção de resultados mais
eficazes e com maior probabilidade de êxito, estão relacionadas não só a
ferramenta em si, mas sua aplicabilidade, sendo então sugerida uma criteriosa
seleção e aplicação das metodologias e ferramentas para gerenciamento dos
projetos.
As metodologias existentes não são garantia de bons resultados nos
indicadores dos projetos, mas oferecem parâmetros e orientações para que os
responsáveis pelos projetos “Gerentes de Projetos”, entendam e tenham
direcionamentos para aturam em conformidade com boas práticas sugeridas
por estas metodologias.
56
BIBLIOGRAFIA CONSULTADA
Introdução
§ http://www.servidor.gov.br/noticias/noticias12/arq_down/publicacao_slti_mgp-sisp_versao_1.pdf
Tipos de Estruturas organizacionais e sua relação com projetos
§ http://brainstormdeti.wordpress.com/2010/06/08/estruturas-organizacionais-e-projetos/
Estrutura Organizacional (Formal e Informal)
§ http://pt.wikipedia.org/wiki/Estrutura_organizacional
Conceito de Projetos
PMBOK – 4ª. Edição em Português - 2008 – Pág. 11 2008 Project Management Institute, Inc. Todos os direitos reservados. Ciclo de vida de Gerenciamento de Projetos
§ http://www.google.com.br/imgres?q=ciclo+de+vida+de+um+projeto&um=1&hl=pt-BR&sa=N&biw=1280&bih=667&tbm=isch&tbnid=tpR5rAAl0K4esM:&imgrefurl=http://www.mhavila.com.br/topicos/gestao/pmbok.html&docid=hd9BpEdtEBySCM&imgurl=http://www.mhavila.com.br/topicos/gestao/img/pmbok_grupos_processos.png&w=480&h=340&ei=NzJhUOO3JPDW0gH8koDwBA&zoom=1&iact=rc&dur=360&sig=114134149232901187739&page=2&tbnh=135&tbnw=191&start=15&ndsp=20&ved=1t:429,r:15,s:15,i:172&tx=130&ty=74
Áreas de conhecimento de gerenciamento de projetos (figura)
§ http://paulocmattos.wordpress.com/2010/07/20/as-areas-de-conhecimento-em-gerenciamento-de-projetos/
PP-XXX-000Y0 - Tratar Demandas de Clientes
§ Sistema de Padronização eletrônica do Sistema Petrobras, (SINPEP) – Intranet corporativo
57
PP-XXX-000P8 - Implementar Soluções de Software
§ Sistema de Padronização eletrônica do Sistema Petrobras, (SINPEP) – Intranet corporativo
PE-XXX-000D2 - Regras para Classificação da Complexidade de Projetos de
Solução de Software
§ Sistema de Padronização eletrônica do Sistema Petrobras, (SINPEP) – Intranet corporativo
PP-XXX-000X2 - Implementar Soluções de Infraestrutura de TI
§ Sistema de Padronização eletrônica do Sistema Petrobras, (SINPEP) – Intranet corporativo
PP-XXX-000N3 - Elaborar planejamento de Curto Prazo
§ Sistema de Padronização eletrônica do Sistema Petrobras, (SINPEP) – Intranet corporativo
PG-XXX-000J7 - Metodologia de Gerenciamento de Projetos de Tecnologia da
Informação
§ Sistema de Padronização eletrônica do Sistema Petrobras, (SINPEP) – Intranet corporativo
PG-XXX-000B1 - Metodologia de Gerenciamento de Projetos com métodos
Ágeis de Tecnologia da Informação
§ Sistema de Padronização eletrônica do Sistema Petrobras, (SINPEP) – Intranet
PE-XXX-000H3 - Monitoramento do Portfolio de Projetos de Tecnologia da
Informação e Telecomunicações
§ Sistema de Padronização eletrônica do Sistema Petrobras, (SINPEP) – Intranet corporativo
PE-XXX-000F5 - Revisão de Qualidade de Projetos de Tecnologia da
Informação e Telecomunicações
§ Sistema de Padronização eletrônica do Sistema Petrobras, (SINPEP) – Intranet corporativo
58
ANEXOS
Índice de anexos
Anexo 1 >> Formulário de Classificação de Complexidade de Projetos
59
ANEXO 1
Formulário de Classificação de Complexidade de Projetos
.
60
ÍNDICE
FOLHA DE ROSTO 02
AGRADECIMENTO 03
DEDICATÓRIA 04
RESUMO 05
METODOLOGIA 06
SUMÁRIO 07
INTRODUÇÃO 08
CAPÍTULO I - Estruturas Organizacional 09
CAPÍTULO II - Projetos de TI na Petrobras 18
CAPÍTULO III – Padrões de Gestão de Projetos 22
CONCLUSÃO 55
BIBLIOGRAFIA CONSULTADA 52
ANEXOS 59
ÍNDICE 60
FOLHA DE AVALIAÇÃO 61
61
FOLHA DE AVALIAÇÃO
