Baixe o app para aproveitar ainda mais
Prévia do material em texto
Gestão de Tecnologia da Informação Responsável pelo Conteúdo: Prof. Ms. Artur Marques Revisão Textual: Profa. Ms. Magnólia Gonçalves Mangolini Governança e Projetos em TI Material teórico Governança e Projetos em TI Nessa unidade falaremos, de forma introdutória, da importância do gerenciamento de projetos na área de TI, focada no framework, proposto pelo PMBOK®, não concentrado em desenvolvimento de sistemas. Para isso, podemos utilizar métodos ágeis e alguns outros associados a CMMI e ao próprio PMBOK®, estamos nos referindo especificamente em infraestrutura e outros tipos de projetos que ocorrem em Gestão de Tecnologia de Informação. Também abordaremos o framework ITIL, muito utilizado em TI para realizar a gestão de serviços visando à prestação de um serviço melhor ao usuário e atendimento das áreas da empresa que precisam de suporte. Atuam também em incidentes e problemas. Trata-se, atualmente, do framework mais utilizado para este fim, no Brasil e no mundo. Veremos introdutoriamente os livros que cuidam de gestão de suporte e serviços. Enfatizo a leitura do material deste módulo de forma atenta e, após isso, você precisa realizar os exercícios propostos. Atenção Para um bom aproveitamento do curso, leia o material teórico atentamente antes de realizar as atividades. É importante também respeitar os prazos estabelecidos no cronograma. Silva Filho (2006) versa que, até certo ponto, é natural àqueles que desenvolvem novos sistemas iniciarem suas atividades de desenvolvimento antes mesmo que eles entendam o que tem de ser feito, ou seja, antes mesmo que saiba qual é o problema a ser solucionado. O resultado desse tipo de atitude é e tem sido o insucesso de projetos. Para trabalharmos e gerirmos um projeto, devemos trabalhar longamente no entendimento do trabalho a ser feito e nas entregas esperadas, caso contrário, não saberemos onde temos que chegar e isso é o grande causador de fracassos e problemas com clientes internos e externos a organização e também é a causa mais comum da inserção de erros logo cedo no desenvolvimento que custarão muito caro quando forem descobertos. Isso acontece infelizmente porque há pouca preocupação do profissional de tecnologia da informação com a Gestão, principalmente dos insumos humanos e materiais necessários para o correto aproveitamento e cumprimento dos objetivos do projeto. Problemas culturais e baixa capacitação dos colaboradores são outros problemas que recrudescem o resultado ruim dos projetos em tecnologia da informação. Renner (2008), citando Ricardo Viana Vargas do PMI board, diz que apesar do Brasil ter um número limitado de profissionais certificados em práticas de gerenciamento de projetos, cerca de cinco mil, e da América Latina responder por apenas 4% do total mundial, a realidade é muito diferente em outras partes do globo. Grande parte dos profissionais certificados no Brasil atua preponderantemente na área de tecnologia da informação, setor que tem maior carência e necessidade desse tipo de profissional devido à complexidade dos projetos que são realizados e a criticidade empresarial que representam nos dias de hoje. As organizações no mercado globalizado em que vivemos realizam seus objetivos estratégicos através de projetos. Neles estão contidas as doses de inovação investidas para produzir produtos e serviços diferenciados que garantirão a sobrevivência das empresas na economia moderna e hiper competitiva a qual vivemos. Vamos conhecer um pouco sobre as melhores práticas que têm transformado em sucesso os projetos das organizações em todo o mundo. Contextualização Fundamentos de Gestão de Projetos O conceito moderno sobre gerência de projetos nasceu nos Estados Unidos, no final da década de 50 e início da década de 60, motivado, entre outras coisas, pelo projeto Apollo que levaria o homem à Lua. Todavia, as aplicações iniciais das melhores práticas foram aplicadas para se realizar a análise de sistemas computacionais e a implementação de empreendimentos físicos, como construções complexas e bens de consumo. A gestão de projetos fornece conceitos e melhores práticas para que sejam enfrentadas as mudanças e riscos impostos pelo dia a dia da globalização e a necessidade de lançar produtos e serviços em tempos cada vez menores, com cada vez mais qualidade e valor agregado. Além disso, a gestão de projetos oferece ferramentas e técnicas para lidar com essas mudanças. O responsável pela execução e gerenciamento dessas mudanças se chama gerente de projetos. De acordo com o PMBOK (2008) “um projeto é um empreendimento único que deve apresentar um começo e um fim claramente definidos e que, conduzido por pessoas, possa atingir seus objetivos respeitando os parâmetros de prazo, custo e qualidade”. O que caracteriza de forma mais marcante um projeto são as categorias de entregas que ele pode proporcionar, como por exemplo: • Produtos: produto ou objeto produzido, quantificável, podendo ser final ou intermediário. • Serviços: são itens de capacidade, funções de negócio para produção, armazenagem ou logística, desenhos ou melhorias em processos, inovação em uma abordagem de sistemas, entre outros. • Resultados: relatórios, pareceres, documentos, resultados finais. Por exemplo, criação de algo inovador que gere uma documentação de patente, um projeto de pesquisa exploratória que desenvolve ciência. Subprojetos: em vários casos um projeto precisa ser dividido em partes devido a sua grande complexidade ou característica de produção, isso auxilia em seu gerenciamento e controle. Essas partes, que foram divididas, chamamos de subprojetos. Elas são muito específicas e podem ser feitas por terceiros ou por equipes dedicadas. O mais importante é que o subprojeto tratado isoladamente não faz sentido, ele precisa estar agregado ao projeto principal. Imagine que a arquitetura e modelagem do banco de dados para uma aplicação específica em tempo real seja tratada como subprojeto, ela não tem sentido em ser desenvolvida se não houver o projeto de software que tratará estas informações em tempo Material Teórico real, ou seja, não há outra utilidade para essa modelagem que não seja servir esse software, ela não serve para outro software. • Programas: usamos esse termo para designar quando vários projetos estão concentrados em um conjunto de melhoramentos e táticas comuns. O mais importante é que eles podem ter vida própria, além do projeto principal. Por exemplo, vamos fazer um avião, uma das partes é a turbina, ela faz parte do programa do avião, ou seja, a turbina pode ser desenvolvida para esse avião que será construído, mas pode ser usada por outros projetos de aviões diferentes que possam utilizar o mesmo propulsor. Gerenciamento de projetos: conforme definição do PMBOK (2008) é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto, cuja finalidade é atender aos seus requisitos. Isso inclui, mas não se esgota em: • Identificar as necessidades do projeto; • Estabelecer objetivos claros, mensuráveis e alcançáveis; • Balancear, distribuir e resolver demandas conflitantes que envolvam entre outras áreas de conhecimento: riscos, qualidade, escopo, tempo, comunicação e custo; • Adaptar as especificações e abordagens, dos diferentes planos, preocupações e expectativas dos stakeholders (partes interessadas) que na versão 5 do PMBOK é uma área de conhecimento nova. Conforme Schmitz(2005, 16), as áreas de conhecimento do PMBOK são 9 e possuem os seguintes propósitos: • Escopo: A Gerência de Escopo assegura que o projeto inclua todo o trabalho necessário, e tão somente o necessário, para complementar de forma bem sucedida o mesmo. Define e controla o que está e o que não está incluído no projeto. A principal ferramenta é a Estrutura Analítica do Projeto – EAP (em inglês, WBS – Work Breakdown Structure), que identifica e decompõe os principais elementos do projeto. • Tempo: Seus processos consideram a definição de atividades e seu sequenciamento (identificação de relacionamentos de dependência entre elas), estimativas de recursos e duração, desenvolvimento do cronograma e seu controle. Os processos da gerência de tempo são executados em paralelo com a gerência de custos, uma vez que a duração de uma atividade depende diretamente da quantidade de recursos alocados para a mesma. • Custo: Contempla os custos dos recursos necessários a implantação das atividades. Ela inclui os processos necessários para assegurar que o projeto será concluído dentro do orçamento aprovado. Seus processos são a estimativa e orçamento dos custos e seu controle. As principais técnicas e ferramentas utilizadas são: avaliação especializada de consultores, estimativas por analogia de outros projetos, estimativas por desagregação de custos (botton-up) ou modelos paramétricos. • Qualidade: Garantir que o projeto irá satisfazer as necessidades para as quais ele foi empreendido. A preocupação com qualidade deve ser estendida também para os fornecedores de insumos do projeto, devendo ficar claro que as referências de qualidade da organização devem ser seguidas nos projetos. • Risco: propõe a identificação, análise e resposta aos riscos do projeto, considerando riscos internos e externos. Os processos contemplam a identificação, qualificação e quantificação dos riscos, desenvolvimento e controle de respostas, e monitoramento. A abordagem geralmente utilizada é a análise dos resultados que devem ser evitados e a monitoração de suas causas por meio do estabelecimento de gatilhos de aviso. • Comunicação: Garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação final das informações sobre o projeto de forma oportuna e adequada. Previne interpretações errôneas e garante que a informação correta esteja disponível para quem dela necessite. • RH: Contempla os processos requeridos para possibilitar o uso mais efetivo das pessoas envolvidas no projeto. Os principais tópicos a serem destacados são: liderança, negociação, comunicação, delegação, motivação, formação de equipes, gerência de conflitos, treinamento, avaliação de desempenho, recrutamento e manutenção das relações de trabalho. • Aquisição: Inclui os processos necessários para a obtenção de bens e serviços externos a organização executora, para a realização do trabalho. Possui as seguintes necessidades: preparação das aquisições e contratações, obtenção de propostas, seleção de fornecedores, administração e encerramento dos contratos. • Integração: Compreende a coordenação entre os diversos elementos do projeto, através de processos, ferramentas e técnicas. É executada durante todo o projeto, paralelamente as demais gerências, integrando seus resultados no Plano do Projeto. Grupo de processos: trata-se dos macroprocessos existentes durante o ciclo de vida de um projeto e serve para demonstrar, determinar e atuar sobre documentos, relatórios, atuações, papéis e fases esperadas para saber como está à situação do projeto e quais esforços estão consumindo os recursos. Essas fases são: • Iniciação: Determina a existência do projeto, são documentos e atividades de autorização e início. Por exemplo: contrato assinado, designação do gerente de projeto, termo de abertura do projeto. • Planejamento: Cria e depura os objetivos do projeto, cria documentos estruturados de planejamento de ação necessários para atingir as metas e o escopo do projeto. • Execução: trata da junção de recursos humanos e materiais para a execução do projeto, é o fazer, conforme estabelecido na fase de planejamento. • Monitoramento e controle: estabelece medidas para controle de desempenho e previsão identificando variações contra o plano estabelecido para que possam ser tomadas medidas proativas e reativas sob as situações encontradas. • Encerramento: constitui os elementos de finalização do projeto, entre outros a parte operacional, entregas, termos de aceite, termos de homologação e também a parte administrativa, como por exemplo, ordem de emissão de nota fiscal final, encerramento de contrato, entre outros. Figura 1: Grupo de Processos do PMBOK para Gestão de Processos. Fonte: http://professorprojeto.blogspot.com.br/2011/04/mapas-mentais-pmbok.html Então podemos perceber que cabe ao GP e a equipe determinar quais processos são os adequados e o grau de exigibilidade de cada processo para cada empresa e para cada projeto em específico. Escopo Conforme Ricardi (2005), Escopo possui os seguintes componentes: • Do produto: é aquilo que vai ser entregue como resultado do projeto, ou seja, um produto, serviço ou qualquer outro resultado específico. • Do projeto: é o conjunto das atividades que precisam ser realizadas para entregar o escopo do produto. • Requisitos: representam as características de algo que será entregue ou executado. Portanto podemos ter, em uma visão macro, requisitos de produto e requisitos de projeto. Uma das melhores formas de detalhar o escopo do projeto e do produto é através do detalhamento de requisitos associados. Através deles você consegue aumentar a precisão em documentar as necessidades e desejos dos envolvidos (partes interessadas) no projeto. Devem atender as seguintes características: o Necessário: ele é essencial para o bom funcionamento da entrega ou do projeto. Se não estiver presente, caracteriza uma deficiência; o Completo: não exige complementos para ser atingido ou atendido, ou então está relacionado a outros requisitos que o complementam e esta relação está explícita e é de conhecimento e aprovada por todos quem interessa; o Consistente: não contradiz outros requisitos ou outros aspectos relacionados ao projeto; o Não ambíguo: evita interpretação ambígua; o Conciso: define uma única coisa que deve ser feita e só a coisa que deve ser feita; o Isento de implementação: define o que deve ser feito ou atendido, e não como ocorrerá; o Factível: é passível de ser atingido durante a execução do projeto, por um custo dentro dos limites orçados, no prazo necessário e com os recursos disponíveis; o Verificável: pode ser quantificado de forma a ter o seu atendimento verificado através de testes ou inspeções. • Componentes: um documento de escopo bem definido deverá conter em sua composição pelo menos: o Critérios de aceitação o Objetivos o Premissas o Restrições Sua constituição é feita dos seguintes processos e atividades: Entradas • Termo de abertura do projeto Fornece a base para iniciar o detalhamento dos requisitos, pois contém a descrição do produto e alguns requisitos em alto nível. • Registro das partes interessadas Serve de referência para identificar quais as partes interessadas que poderão fornecer detalhes e definição a respeito dos requisitos necessários. Ferramentas e Técnicas • Entrevistas Utiliza conversas diretas com as partes interessadas, individualmente, no formato de perguntas e respostas, que deverão ser registradas e aprovadas pelos entrevistados. • Dinâmicas de grupo Reúnem especialistas e partes interessadas pré-qualificadas, com o objetivo de levantar expectativas e atitudes relacionadas ao escopo do produto e/ou ao escopodo projeto. • Oficinas Reúnem partes interessadas de diversas áreas e/ou funções, com o objetivo de definir rapidamente requisitos que atendam a todos, reconciliando diferenças entre os diversos requisitos associados. Técnica recomendada para levantamento de funcionalidades complexas e que envolvem muitos interessados. Exemplos: JAD (Joint Application Design) e QFD (Desdobramento da Função de Qualidade). • Técnicas de criatividade em grupo Brainstorming A criatividade não é repreendida, e todos podem sugerir e opinar a respeito. Técnica de grupo nominal Amplia a técnica de Brainstorming incluindo um processo de votação. A técnica DELPHI São elaborados questionários que são submetidos, de forma anônima, a especialista no assunto. Estes deverão responder a um facilitador que repetirá o envio aos envolvidos, em ciclos de perguntas e respostas, até coletar todos os requisitos necessários. Mapas mentais Diagramas com estrutura de itens e subitens, assuntos e descrições, que denotam linha de raciocínio semelhante ao cérebro humano. Diagrama de afinidade Organiza grande quantidade de ideias agrupando para revisão e análise. • Técnicas de tomada de decisão em grupo Avalia múltiplas alternativas com o objetivo de resolver ações futuras. Gera, classifica e prioriza os requisitos do produto. Inclui os seguintes métodos: Unanimidade Maioria Pluralidade Ditatura • Questionários e pesquisas Utilizados quando existe um universo muito grande de candidatos a entrevistas, e não há tempo hábil para conversas individuais. • Observações Acompanhamento e observação dos profissionais em seu ambiente de trabalho, onde a probabilidade de esquecimento de requisitos importantes é minimizada, e o entendimento das necessidades fica facilitado. • Protótipos Validação de modelo funcional do produto anterior à sua construção. Permite ao cliente visualizar e em algumas situações manipular o produto de forma simulada. Saídas • Documentação dos requisitos Algumas organizações têm ferramentas específicas que permitem a documentação e o gerenciamento dos requisitos do projeto e do produto. Descreve como os requisitos individuais irão atender às necessidades de negócio do projeto, e pode ser apresentada em forma de listas categorizadas, priorizadas e associadas a outras informações importantes e necessárias para o projeto. • Plano de gerenciamento dos requisitos Define como os requisitos serão levantados, analisados, documentados e gerenciados durante todo o ciclo de vida do projeto. Não menospreze a importância deste plano, por ele ser um plano auxiliar. Sem uma definição consistente relacionada a este assunto, o projeto pode tomar um rumo de descontrole e falta de objetividade, e as consequências serão imprevisíveis. • Matriz de rastreabilidade dos requisitos Associa os requisitos aos objetivos de negócio e aos objetivos do projeto. Ainda, consolida os requisitos criando referência com outros requisitos e com as entregas do projeto. • EAP: trata-se de Estrutura hierárquica que decompõe as entregas do projeto e os pacotes de trabalho associados. Será utilizada como base para estimar e controlar escopo, custos e cronograma. • Dicionário da EAP: Fornece o detalhamento dos componentes da EAP. Segundo o Guia PMBOK, poderá conter as seguintes informações (inclua ou retire aquelas que considerar necessário): o Código de identificador da conta o Descrição do trabalho necessário o Organização ou pessoa responsável pela execução o Lista de marcos do cronograma o Atividades do cronograma associadas o Recursos necessários o Estimativa de custos o Requisitos de qualidade o Critérios de aceitação (da entrega, que pode conter os critérios dos requisitos associados, e mais algum que tenha a ver diretamente com a entrega. Exemplo: esta entrega deverá ser validada pelo Diretor Fulano de Tal) o Referência técnica o Informações do contrato o • Linha de base do escopo: Componente do plano de gerenciamento do projeto é composta pelos documentos: o Declaração de escopo do projeto o EAP o Dicionário da EAP Figura 2: exemplo EAP para um sistema de informação Fonte: http://www.gtics.com.br/wa_files/GRUPO-04_EAP_v1_3.png Id. Pacote de Trabalho Descrição 1.1 Análise da situação atual Levantamentos dos pontos críticos e oportunidades de melhoria, suas causas e consequências. Este pacote realizou o estudo necessário para a definição da estratégia a ser seguida: terceirizar ou desenvolver solução própria 1.2 Alocação da equipe Designação de funcionários para o projeto. Definição da função de cada membro e disponibilidade de tempo exigida. Definição de cada membro da equipe, por pacote de trabalho. 1.3 Elaboração do Plano de Projeto Define como o projeto será executado, quais são os recursos, financeiros e humanos alocados. 2.1 Estudo e mapeamento do fluxo de trabalho para procedimento de leilão eletrônico Analisar e realizar um mapeamento de um fluxo de trabalho padrão para leilão eletrônico a todos os cartórios. Figura 3: exemplo de um dicionário de EAP Fonte: http://desenv.tjms.jus.br/confluence/pages/viewpage.action?pageId=5505070 Tempo Para o PMBOK® (2008:112), “o Gerenciamento do Tempo do Projeto inclui os processos necessários para gerenciar o término pontual do projeto”. Marques et ali (2011) apontam e comentam os seguintes processo e atividades necessários para a gestão do tempo no projeto, incluindo o diagrama de rede e o cálculo DO CAMINHO Crítico envolvendo a técnica CPM – Critical Path Method a saber: • Definir as atividades: Trata-se da identificação das ações que precisam ser feitas para produzir as entregas do projeto. Para tanto precisamos, após identificá-las, criar a EAP – Estrutura Analítica do Projeto - que serve para identificar as entregas no nível mais baixo da estrutura, a qual chamamos de pacote de trabalho. Uma vez levantada junto às áreas uma lista de atividades que serão realizadas, passamos a criação da EAP e inserimos seus tempos. Porém, para iniciarmos, precisamos conhecer algumas técnicas para definir essas atividades. • Decomposição: trata-se de subdividirmos os pacotes de trabalho em atividades que, de acordo com o PMBOK®, são mais gerenciáveis, de forma que o trabalho e as entregas estejam definidos até o nível de pacote de trabalho. Este nível é o mais baixo na EAP antes do Deliverable e é onde o custo e o cronograma podem ter uma estimativa mais confiável. Decompor envolve algumas atividades como: o Identificar as entregas relacionadas à estruturação e organização da EAP. o Quebrar os níveis mais elevados da EAP ampliando a granularidade, ou seja, detalhando para níveis mais baixos. o Atribuir os códigos de identificação (taxonomia) aos itens da EAP. • Lista das atividades: segundo as melhores práticas do PMBOK® (2009:118), a lista das atividades é uma lista abrangente que inclui todas as atividades necessárias no projeto. Inclui o identificador e uma descrição do escopo do trabalho de cada atividade em detalhe suficiente para assegurar que os membros da equipe entendam qual trabalho precisa ser executado. • Lista dos marcos: o marcos é datas chave no projeto e servem para designar ou identificar um evento significativo e importante no projeto. Podendo ser uma entrega, uma reunião ou uma homologação, início ou encerramento. • Sequenciar as atividades: Considera que as principais atividadesde um projeto devem ser executadas levando-se em consideração a ordem e os desdobramentos das atividades que compõem os pacotes de trabalho e as entregas da EAP. Para o PMBOK® (2009:119), sequenciar as atividades “é processo de identificação e documentação dos relacionamentos entre as atividades do projeto”. Essas são sequenciadas usando relações lógicas (atividade predecessora e sucessora). Sequenciamento permite que todas as partes interessadas no projeto possam visualizar o trabalho a se realizar até a finalização do projeto. O Gerente de Projetos deverá possuir em suas mãos como entradas para a execução das atividades de sequenciamento: o Lista das atividades; o Atributos das atividades; o Lista dos marcos; o Declaração do escopo do projeto; o Ativos de processos organizacionais. • Método do diagrama de precedência (MDP): constrói o diagrama de rede do projeto através do uso de diversos nós que objetivam representar as atividades, e setas são utilizadas para que os nós fiquem ligados, mostrando suas dependências. Esta técnica é chamada de Atividade nos Nós, a maioria dos sistemas que apoiam o gerenciamento de projetos é baseada nela. O PMBOK® (2009:120) determina quatro tipos de dependências: o Término para Início (TI) - o início da atividade sucessora depende do término da atividade predecessora. o Término para Término (TT) - o término da atividade sucessora depende do término da atividade predecessora. o Início para Início (II) - o início da atividade sucessora depende do início da atividade predecessora. o Início para Término (IT) - o término da atividade sucessora depende do início da atividade predecessora. Figura 4: Exemplo de diagrama de precedência MDP Fonte: http://arquivos.unama.br Existem três tipos de determinação que podemos utilizar: o Dependências obrigatórias: conforme o PMBOK® (2008:120), são aquelas exigidas contratualmente ou inerentes à natureza do trabalho. A equipe do projeto define quais dependências são obrigatórias durante o processo de sequenciamento das atividades. Geralmente envolvem limitações físicas, tais como num projeto de construção onde é impossível erguer a superestrutura antes que a fundação tenha sido concluída, ou num projeto de componentes eletrônicos, onde um protótipo tem que ser construído antes de ser testado. o Dependências arbitradas: normalmente são estabelecidas baseadas no conhecimento das melhores práticas numa área de aplicação específica ou em algum aspecto particular do projeto onde uma sequência específica é desejada, mesmo que haja outras sequências possíveis ou aceitáveis. Existe a necessidade de documentação dessa dependência para evitar problemas de comunicação e para justificativa do caminho escolhido. o Dependências externas: o gerente do projeto ou sua equipe definem quais dependências são externas durante o processo de sequenciamento das atividades. Isso envolve uma relação entre as atividades do projeto e as não pertencentes ao mesmo. Aplicação de antecipações e esperas: PMBOK® (2009) determina que uma antecipação permita um aceleramento da atividade sucessora. Por exemplo, num projeto para construir um novo edifício de escritórios, o paisagismo poderia ser agendado para começar duas semanas antes do término agendado dos itens da lista. Isso seria mostrado como um término para início com uma antecipação de duas semanas. Uma espera direciona um retardo na atividade sucessora. Por exemplo, uma equipe de redação técnica pode iniciar a edição do rascunho de um grande documento quinze dias após ter começado a escrevê-lo. Isso poderia ser mostrado como um início para início com uma espera de quinze dias. O uso de antecipações e esperas não deve substituir a lógica de desenvolvimento do cronograma. As atividades e suas premissas relacionadas devem ser documentadas. Uma antecipação permite um aceleramento da atividade sucessora. • Modelos de diagrama de rede de cronograma: são utilizados para agilizar a preparação da rede de atividades e normalmente estão em repositórios de conhecimento nas organizações para esta finalidade. Podem conter todo projeto ou partes ou até mesmo fragmentos. Segundo o PMBOK® (2009:121): (...) os modelos de sub-redes são especialmente úteis quando um projeto inclui várias entregas idênticas ou quase idênticas, tais como andares num alto prédio de escritórios, testes clínicos num projeto de pesquisa farmacêutico, módulos de programas de codificação num projeto de software, ou a fase inicial de um projeto de desenvolvimento. • Estimar os Recursos da Atividade: As melhores práticas do PMBOK® rezam que, para estimar os recursos de uma atividade envolvemos os tipos e quantidades de material, pessoas, equipamentos ou suprimentos que serão necessários para realizar cada atividade da EAP. Estimar os recursos para uma atividade está intimamente ligado com o processo de estimativa de custos, sendo que podemos nos apropriar das mesmas técnicas que utilizamos nessa área da gestão de projetos. Dois exemplos práticos impostos pelo PMBOK® (2009:122) demonstra o grande grau de sinergia entre esses processos: o Uma equipe de um projeto de construção precisará estar familiarizada com as legislações de construção locais. Geralmente, tal conhecimento está facilmente disponível em fornecedores locais. Contudo, se o serviço de mão de obra local carece de experiência em técnicas de construção incomuns ou especializadas, o custo adicional de um consultor pode ser a maneira mais efetiva de assegurar o conhecimento das legislações de construção locais. o Uma equipe de planejamento automotivo precisará estar familiarizada com as mais recentes técnicas de montagem automatizada. O conhecimento necessário pode ser obtido através da contratação de um consultor, do envio de um projetista a um seminário de robótica, ou da inclusão de alguém da produção como um membro da equipe do projeto. • Estimar as Durações da Atividade: segundo o PMBOK® (2008), é o processo de estimativa do número de períodos de trabalho que serão necessários para terminar as atividades específicas com os recursos estimados. o A estimativa das durações das atividades utiliza informações sobre as atividades do escopo do projeto, tipos de recursos necessários, quantidades estimadas de recursos e calendários de recursos. As entradas para as estimativas de duração da atividade se originam da pessoa ou grupo na equipe do projeto que está mais familiarizado com a natureza do trabalho na atividade específica. A estimativa da duração é elaborada progressivamente e o processo considera a qualidade e a disponibilidade dos dados de entrada (PMBOK®, 2009:125). Estimar a duração de uma atividade requer que a quantidade do esforço e recursos necessários sejam aplicados para finalizar a atividade. Dessa forma, estes elementos são utilizados para gerar o número de mês/dias/horas de trabalhos necessários para a finalização da atividade. A duração decorre do esforço requerido para completar o trabalho relativo a uma atividade do projeto, e ajustar esse esforço levando em conta com os seguintes fatores: o A quantidade de recursos que irão realizar o trabalho e o grau de eficiência desses recursos. o O calendário de disponibilidade dos recursos (isto é se eles estão disponíveis a 100% ou numa outra qualquer percentagem inferior de tempo). o Os períodos específicos de inatividade (fins de semana, feriados e férias contratuais). o Número normal de horas diárias de trabalho. Para estimarmos a duração, podemos utilizar um mapeamento mediante o uso de um fluxo como nos exemplos abaixo: Figura 5: Fluxo para concluirmos a atividade para estabelecer a duração das atividades no projeto. Fonte: http://ricardosatin.blogspot.com/2009/12/estimativa-de-duracao-de-atividades.html• Desenvolver o Cronograma: Conforme o PMBOK® (2009:129), desenvolver o cronograma é o “processo de análise de sequências das atividades, suas durações, recursos necessários e restrições do cronograma visando criar o cronograma do projeto. A entrada das atividades, durações e recursos na ferramenta de elaboração de cronograma gera um cronograma com datas planejadas para completar as atividades do projeto” (PMBOK®. 2009. P.129). Importante citar no processo de construção do cronograma, tratar-se de um elemento dinâmico e ativo de forma que a sua revisão e a manutenção são necessárias para mantê-lo em concordância à realidade e deve ser executada durante todo o projeto à medida que o trabalho avança, pois o plano de gerenciamento muda e a natureza dos eventos de riscos, custos e recursos humanos evolui. Para podermos desenvolver o cronograma, precisamos estar munidos dos seguintes documentos de projeto, que chamaremos aqui de entradas do processo Desenvolver o Cronograma: o Lista das atividades o Atributos das atividades o Diagramas de rede do cronograma do projeto o Requisitos dos recursos da atividade o Calendários dos recursos o Estimativas da duração da atividade o Declaração do escopo do projeto o Fatores ambientais da empresa o Ativos de processos organizacionais. • Análise da rede do cronograma: os diagramas de rede são amostras esquemáticas das atividades do cronograma do projeto e as suas relações lógicas, também chamadas de dependências. • Método do caminho crítico: calcula as datas hipotéticas de início e término mais cedo e início e término mais tarde, em todas as atividades, sem considerar quaisquer limitações de recursos, executando uma análise dos caminhos de ida e de volta através da rede do cronograma. De acordo com o PMBOK® (2009), as datas resultantes de início e término mais cedo e início e término mais tarde não são necessariamente o cronograma do projeto, mas sim uma indicação dos períodos de tempo dentro dos quais a atividade poderia ser agendada, dadas as durações do projeto, relações lógicas, antecipações, esperas e outras restrições conhecidas. O PMBOK® (2009:132) determina que os caminhos críticos tenham uma folga total igual à zero ou negativa e as atividades do cronograma que estão no caminho crítico são chamadas ― atividades críticas. Um caminho crítico é normalmente caracterizado por uma folga total igual à zero no caminho crítico. Redes podem ter múltiplos caminhos quase críticos. Ajustes às durações da atividade, relações lógicas, antecipações e esperas e outras restrições do cronograma podem ser necessários para produzir caminhos com folga total zero ou negativa. Uma vez que a folga total para um caminho da rede tenha sido calculada, a folga livre, isto é, a quantidade de tempo que uma atividade pode ser atrasada sem atrasar a data de início mais cedo de qualquer atividade imediatamente sucessora dentro do caminho crítico, pode também ser determinada. Figura 06: Caminho crítico em um projeto (em vermelho) Fonte: http://teccrono.com.br/plan-desenvolvimento.html • Compressão do Cronograma: conforme PMBOK® (2009), serve para encurtar o cronograma do projeto sem mudar o escopo do mesmo, para respeitar as restrições do cronograma, datas impostas ou outros objetivos do cronograma, as técnicas de compressão do cronograma incluem: o Compressão. Exemplos de compressão poderiam incluir a aprovação de horas extras, recursos adicionais ou o pagamento para a aceleração da entrega das atividades no caminho crítico. A compressão funciona somente para as atividades onde recursos adicionais encurtarão a sua duração. A compressão nem sempre produz uma alternativa viável e pode resultar num maior risco e/ou custo. o Paralelismo. Uma técnica de compressão do cronograma na qual fases ou atividades normalmente executadas em sequência são executadas em paralelo. Um exemplo é a construção da fundação de um prédio antes que todos os desenhos arquitetônicos tenham sido terminados. O paralelismo pode resultar na repetição de trabalho e aumento de risco. O paralelismo funciona somente se as atividades podem ser sobrepostas para encurtar a duração. Figura 06: Compressão Fonte: http://teccrono.com.br/ Figura 07: Paralelismo Fonte: http://teccrono.com.br/ • Saídas do processo para criar o cronograma: o Cronograma do projeto: o cronograma do projeto inclui pelo menos uma data de início e de término planejadas para cada atividade. o Gráficos de marcos: esses gráficos assemelham-se aos gráficos de barras, porém identificam somente o início ou término agendado para as entregas mais importantes e interfaces externas chaves. o Gráfico de barras: esses gráficos, onde as barras representam as atividades, mostra as datas de início e término da atividade, assim como as durações esperadas. o Diagramas de rede do cronograma do projeto: esses diagramas, com informações sobre as datas das atividades, normalmente mostra tanto a lógica da rede do projeto como suas atividades do seu caminho crítico. o Linha de base do cronograma: uma linha de base do cronograma é uma versão específica do cronograma do projeto desenvolvido a partir da análise de rede do mesmo. o Dados do cronograma: os dados de apoio do cronograma para compor o cronograma do projeto incluem pelo menos os marcos, as atividades, os atributos das atividades e a documentação de todas as premissas e restrições identificadas. o Por último, o PMBOK® (2009:139) depois consultar o especialista, reza que para manter os documentos em dia é preciso. o Requisitos dos recursos das atividades. O nivelamento dos recursos pode ter um efeito significativo nas estimativas preliminares dos tipos e quantidades de recursos necessários. Se a análise do nivelamento de recursos muda os requisitos dos recursos do projeto, então os mesmos são atualizados. o Atributos das atividades. Os atributos das atividades são atualizados para incluir quaisquer requisitos de recursos revisados ou quaisquer outras revisões geradas pelo processo Desenvolver o Cronograma. o Calendário. O calendário para cada projeto pode usar diferentes unidades como base para Desenvolver o Cronograma do projeto. o Registro dos riscos. O registro dos riscos pode precisar ser atualizado para refletir oportunidades ou ameaças percebidas através das premissas de agendamento. • Controlar o Cronograma: E o processo de monitoramento do andamento do projeto para atualização do seu progresso e gerenciamento das mudanças feitas na linha de base do cronograma. Conforme o PMBOK® (2009: 136), o controle do cronograma está relacionado a: o Determinação da situação atual do cronograma do projeto; o Influência nos fatores que criam mudanças no cronograma; o Determinação de que o cronograma do projeto mudou; o Gerenciamento das mudanças reais conforme ocorrem. Fundamentos de Governança com ITIL Como estamos constantemente frisando em nossos estudos, a TI tem ganhado peso e importância nas organizações, seus desafios também aumentaram em proporção semelhante; abaixo citamos alguns: • Ajustar os serviços de TI com as necessidades e metas atuais e futuras dos negócios da empresa. • Aumento da complexidade no ambiente de TI. • Os negócios estão cada vez mais dependentes de TI. • Minimização de riscos e custos. • Melhores justificativas para o ROI - retorno sobre os investimentos em TI. • Mais leis e regulamentos com exigência de conformidade imediata. • Zelo sobre a segurança das Informações. Os negócios empresariais, buscam melhorias e otimizações com maior frequência e possuem metas audaciosas para reduzir riscos e custos, por isso foram pensados diversos frameworks com a intenção de melhorar processos e práticas.Vamos falar especificamente de ITIL - IT Infrastructure Lybrary, composta pelas melhores práticas para Gerenciamento de Serviços de TI. Foi introduzida pelo Governo Britânico em 1980 e se tornou padrão no mercado em 1990. É uma biblioteca composta de 5 livros. Não é uma metodologia, mas sim um conjunto de melhores práticas adotadas por diversas empresas em várias partes do mundo. Estas melhores práticas pretendem: • Inspirar a melhoria dos processos de TI; • Estabelecer metas e nortear o futuro mostrando que outras empresas já lograram êxito; • Orientar e sugerir para que servem os processos e práticas; • Propor e motivas a adoção destes processos e práticas. Conforme Pinheiro (2006,13), os livros que compõem a biblioteca de melhores práticas ITIL são: • Suporte a Serviços: descreve os processos associados ao suporte do dia-a-dia e atividades de manutenção associadas com a provisão de Serviços de TI. • Entrega de Serviços: cobre os processos necessários para o planejamento e entrega de Serviços de TI com qualidade e se preocupa ao longo do tempo com o aperfeiçoamento desta qualidade. • ICT - Gerenciamento da Infraestrutura: cobre todos os aspectos do Gerenciamento da Infraestrutura como a identificação dos requisitos do negócio, testes, instalação, entrega, e otimização das operações normais dos componentes que fazem parte dos Serviços de TI. • Planejamento para Implementação do Gerenciamento de Serviços: examina questões e tarefas envolvidas no planejamento, implementação e aperfeiçoamento dos processos do Gerenciamento de Serviços dentro de uma organização. Também foca em questões relacionadas à Cultura e Mudança Organizacional. • Gerenciamento de Aplicações: descreve como gerenciar as aplicações a partir das necessidades iniciais dos negócios, passando por todos os estágios do ciclo de vida de uma aplicação, incluindo até a sua saída do ambiente de produção (quando o sistema é aposentado). Este processo dá ênfase em assegurar que os projetos de TI e as estratégias estejam corretamente alinhados com o ciclo de vida da aplicação, assegurando que o negócio consiga obter o retorno do valor investido. • Perspectiva de Negócio: fornece um conselho e guia para ajudar o pessoal de TI a entender como eles podem contribuir para os objetivos do negócio e como suas funções e serviços podem estar mais bem alinhados e aproveitados para maximizar sua contribuição para a organização. • Gerenciamento da Segurança: detalha o processo de planejamento e gerenciamento da segurança da informação e Serviços de TI, incluindo todos os aspectos associados com a reação da segurança dos incidentes. Também inclui uma avaliação e gerenciamento dos riscos e vulnerabilidade, e implementação de custos justificáveis para a implementação de contra-recursos (estratégia de segurança). Figura 1: ITIL e seus livros Fonte:Service Suport OGC Para esta nossa disciplina, vamos estudar apenas os dois primeiros. Conforme o livro de Services Suport do ITIL, o relacionamento entre os processos está descrito na imagem abaixo. Figura 2: relacionamento entre processos do Service Suport – ITIL Fonte: livro ITIL-SS Figura 2: conforme figura do livro sobre Entrega de serviços do Service Suport – ITIL e seus relacionamentos Fonte: livro ITIL-ES Possíveis ganhos ou economias com ITIL: • Redução do custo total em até 48% - Gartner • 6-8% de redução de custos operacionais. $ 125 milhões de economia (10% do budget). Procter e Gamble • Aumento da satisfação do cliente • Aumento de resolução de incidentes de 5% para 30% com o uso de uma base de conhecimento - IS Organizations • Redução de 50% no tempo médio de resolução. Redução de 30% no tempo para realizar novas mudanças. Redução de 50% dos recursos – • Utility Provider Dentre os diversos motivos para de adotar uma estratégia de serviços em ITIL, destaco: • Incrementar a qualidade no serviço, com um suporte mais confiável em T.I. • Uma percepção e vivência da segurança e confiança da continuidade nos serviços de TI. • Percepção da capacidade atual mais visível e transparente a todos. • Fornecimento de informações gerenciais para acompanhamento de desempenho, possibilitando traçar melhorias. • Equipe de TI mais motivada: conhecendo a carga de trabalho é possível gerenciar melhor as expectativas. • Maior satisfação para os clientes e usuários, entregando o serviço com mais qualidade e rapidez. • (Em alguns casos) Redução de custos: a partir do melhor planejamento e controle dos processos internos é possível otimizar os custos operacionais. • Maior agilidade e segurança para realizar as mudanças propostas pelo negócio. Com processos definidos e controlados é mais fácil implementar várias mudanças simultaneamente. O conceito de serviço em T.I. deve ser entendido como sendo um conjunto de objetos relacionados, aprovisionados para suporte a um ou mais processo de negócios. Diferentemente de processo, em serviços é sempre o usuário que interage. A definição de processo em ITIL é a reunião de atividades que são interdependentes e inter-relacionadas com uma meta específica. Como componentes mais notáveis pode-se citar: entradas de dados, informações, produtos, que transformam os recursos necessários nos objetivos previstos. Figura: exemplo de processo Fonte: Pinheiro (2006, 18) Visando a melhor prestação de serviços em TI, ITIL separa em dois os atores da prestação de serviços, a saber: Cliente: é quem paga pelos serviços. Caso TI seja uma área interna, os clientes podem ser as unidades de negócios ou departamentos da empresa; caso TI seja um terceiro, prestador de serviços, os clientes serão, então, as próprias empresas que o terceiro atenderá. Usuário: é quem utiliza os serviços de TI quotidianamente. Segundo Pinheiro (2006,25), a implementação de uma central de serviços ITIL tem por objetivos: • Funcionar como o ponto central de contato (SPOC – Single Point of Contact) entre os usuários e departamento de TI. A Central de serviços funciona como o 1º. Nível de suporte aos usuários. • Restaurar os serviços sempre que possível. A equipe de suporte deve estar equipada com ferramentas e informações, tais como Erros Conhecidos, Base de Conhecimento, para que possa oferecer soluções o mais rápido possível. • Prover suporte com qualidade para atender os objetivos do negócio. É necessário que a equipe esteja bem treinada para ter conhecimento de todos os serviços que serão fornecidos e entender o impacto que eles têm para o negócio. • Gerenciar todos os incidentes até o seu encerramento. A central de serviço será responsável pelo processo de Gerenciamento de Incidentes, e será responsável pelo tratamento de todos os incidentes. É de responsabilidade também da Central de Serviços monitorar o cumprimento dos acordos estabelecidos nas ANS (SLA- Acordos de Níveis de Serviços). • Dar suporte a mudanças, fornecendo comunicação aos usuários sobre o agendamento de mudanças. • Aumentar a satisfação do usuário, provendo suporte com maior qualidade, estando sempre de prontidão para o atendimento, buscando solucionar os incidentes de forma mais rápida. • Maximizar a disponibilidade do serviço. Suas atividades principais dizem respeito a: • Receber e gravar TODAS as chamadas dos usuários. • Gravar e acompanhar incidentes e reclamações. • Prover uma avaliação inicial dos incidentes. • Monitorar / escalar incidentes por ANS - Acordo de Nível de Serviço (SLA em inglês). • Comunicar mudanças planejadas nos níveis de serviço. • Encerrar os incidentes com confirmação. • Manter os usuários informados sobre o progresso de suas requisições. • Produzir relatórios de gerenciamento. • Coordenaros grupos de suporte de 2º e 3º nível. • Prover informações gerenciais. • Identificar necessidades de treinamento dos usuários. • Contribuir na identificação de problemas. Para o ITIL, existem 3 tipos de central de serviço, conforme Bom (2007, 38): • Central de Atendimento (Call Center), atende grandes volumes, utiliza o telefone. • Central de Suporte (Help Desk), o foco é não perder nenhuma requisição - seja abandonada ou não atendida, sua meta é resolver e coordenar incidentes servindo como interface. • Central de Serviços (Service Desk), mais abrangente, inclui os processos de negócio de forma integrada não ficando apenas em incidentes, resolve problemas e dúvidas. Figura: Central de Serviços Local – esquema Fonte: Pinheiro (2006,24) Como toda implementação, pode-se criar barreiras ao sucesso da implementação da central de serviços, dentre elas o Service Delivery (2000, 48) expõem: • Usuários não ligarem para Central de Serviços, mas tentarem buscar uma solução diretamente com uma pessoa que conhece, ou que a ajudou da última vez. • A equipe técnica não estar preparada para atender as necessidades do negócio ou usuários. • Nem todas as partes estão informadas sobre os serviços fornecidos e os níveis de serviços acordados, resultando em frustração por parte dos usuários. A central de serviços atua sobre duas frentes, a primeira é a gestão de incidentes, a segunda gestão de problemas. Entende-se que a gestão de incidentes tem como alvo restaurar os serviços o mais rápido possível com o mínimo de interrupção, minimizando os impactos negativos nas áreas de negócio. Para Pinheiro (2006) e o livro ITIL intitulado Service Delivery (2000), o Processo de Gerenciamento de Incidentes tem como objetivos: • Resolver os incidentes o mais rápido possível, restabelecendo o serviço normal dentro do prazo acordado. • Manter a comunicação dos status dos incidentes aos usuários. • Escalonar os incidentes para os grupos de atendimento para que seja cumprido o prazo de resolução. • Fazer avaliação dos incidentes e as possíveis causas informando ao processo de Gerenciamento de Problemas. Quanto ao gerenciamento de problemas, sua principal tarefa é mitigar a interrupção nos serviços de TI, organizando os recursos disponíveis resolvendo o problema conforme as necessidades do negócio, tentando evitar a recorrência e agindo no sentido de documentar para promover a melhoria continua da disponibilidade e produtividade. De acordo com o Livro ITIL Service Delivery (2000), leva em conta os seguintes conceitos gerais: • Problema: é a causa desconhecida de um ou mais incidentes • Solução de Contorno: solução não definitiva (em inglês Workaround) • Causa: é um erro em um Item de configuração • Erro Conhecido (Known Error): É um problema cuja causa foi diagnosticada e para qual existe uma solução • Solução: solução definitiva • Gestão de Incidentes X Problemas: foco na Solução rápida x foco na introdução de melhorias confiáveis e robustas na infraestrutura Caso você queira se aprofundar em ITIL e entender mais detalhadamente as funções dos livros de serviços e até poder implementar algumas práticas no lugar que você trabalha, sugiro a leitura desta apostila de fundamentos em gerenciamento usando ITIL. Disponível em: http://pt.scribd.com/doc/88136757/10/Fundamentos-em-Gerenciamento-de- Servicos-de-TI Outro material interessante já focado na versão 3 do ITIL é este, disponível em: http://www.slideshare.net/blogdufraga/apostila-itilv3conceitos Existe, disponível nesse link http://www.mp.go.gov.br/portalweb/hp/12/docs/apresentacao_gp.pdf, um material muito bom sobre um resumo de gestão de projetos para que você possa conhecer essa área que cresce a cada dia em nosso país e que tem falta crônica de mão de obra. Para uma leitura mais aprofundada na aplicação do gerenciamento de projetos em tecnologia da informação, eu recomendo a leitura do artigo intitulado “Aplicabilidade dos Escritórios de Projetos de TI nas organizações públicas e privadas”. Este fala um pouco das dificuldades em se implementar um escritório de projetos voltado para TI. Disponível em: http://www.upis.br/posgraduacao/revista_integracao/projetos_ti%20.pdf Material Complementar Depois de ler o material e informar-se sobre o assunto, vamos pôr em prática esses conhecimentos nas atividades! Bom trabalho! BON, Jan Von. Foundations of IT Service Management, based on ITIL. Lunteren - Holanda: Van Haren Publishing. 2005. JUNIOR MARQUES, Artur Ubaldo; MARQUES, Daniela Gonçalves de Moraes. Gerenciamento do Tempo em Projetos. EAD – Universidade Cruzeiro do Sul, 2011. PINHEIRO, Flávio R. Fundamentos em gerenciamento de serviços de TI baseados em ITIL. 2006. Disponível em: http://pt.scribd.com/doc/32939973/ Apostila-ITIL. Acessado em: 22 jul. 2012. PMI® – Project Management Institute. Guia PMBOK®. Um Guia do Conhecimento em Gerenciamento de Projetos. 4ªEd.. PMI®. 2008. RICARDI, André Luis Fonseca. Gerenciamento do Escopo do Projeto. EAD – Universidade Cruzeiro do Sul. 2011. SCHMITZ, Leandro Costa. Gerência de Projetos: Histórico, Contextualização, Principais Conceitos e Relações. UDESC/ESAG. 2005. THE STATIONARY OFFICE. Service Delivery. Inglaterra: Londres. 2000 Referências _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ __________________________________________________________________________________________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ Anotações
Compartilhar