UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU AVM FACULDADE INTEGRADA

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.