Base de Conhecimentos

Documentos de ajuda e orientações ao colaborador do Instituto Modal

Biblioteca DigitalProcesso Modal de Gerenciamento de Projetos (PMGP)Procedimentos ModalPerguntas Frequentes
LIMA-MARQUES, M.; SOUZA, B. C. C. O padrão aberto CIPURSE: White Paper. Brasilia, DF: Instituto Modal de Ciência, Tecnologia e Inovação, 23 set. 2019. Disponível em: <https://zenodo.org/record/5093526>. Acesso em: 12 jul. 2021.
SOUZA, B. C. C. Ambiente Promotor de Inovação (API): White Paper. Brasília: Instituto Modal de Ciência, Tecnologia e Inovação, 14 jul. 2019. Disponível em: <https://doi.org/10.5281/zenodo.3627726>. Acesso em: 25 jan. 2020.
SOUZA, B. C. C. et al. Relatório Técnico: Panorama do Transporte Rodoviário de Cargas no Brasil: Estudos Setoriais. Brasilia, DF: Instituto Modal de Ciência, Tecnologia e Inovação, 26 jun. 2019. Disponível em: <https://zenodo.org/record/5093400>. Acesso em: 12 jul. 2021.
SOUZA, B. C. C. et al. Relatório Técnico: Setor de Tratamento de Água no Brasil: visão geral do mercado: Estudos Setoriais. Brasilia, DF: Instituto Modal de Ciência, Tecnologia e Inovação, 20 maio 2019. Disponível em: <https://zenodo.org/record/5093544>. Acesso em: 12 jul. 2021.
LIMA-MARQUES, M. Sistemas baseados em conhecimento: White Paper. BrasÍlia, DF: Instituto Modal de Ciência, Tecnologia e Inovação, 5 mar. 2019. Disponível em: <https://zenodo.org/record/5093480>. Acesso em: 12 jul. 2021.
SOUZA, B. C. C. Criatividade: a engenharia cognitiva da inovação. 3. ed. Brasília: Clube de Autores, 2019.
LACERDA, F.; LIMA-MARQUES, M.; RESMINI, A. An Information Architecture Framework for the Internet of Things. Philosophy & Technology, 14 dez. 2018.
CARNIELLI, W.; LUIZ MARIANO, H.; MATULOVIC, M. Reconciling First-Order Logic to Algebra. In: CARNIELLI, W.; MALINOWSKI, J. (Eds.). . Contradictions, from Consistency to Inconsistency. Trends in Logic. Cham: Springer International Publishing, 2018. p. 273–305.
CARNIELLI, W.; MALINOWSKI, J. Contradictions, from Consistency to Inconsistency. Cham: Springer International Publishing, 2018.
BEIRA, S. DE C. P. et al. ONTOLOGIA COMO UM ARTEFATO DA ARQUITETURA DA INFORMAÇÃO PARA A REPRESENTAÇÃO DO CONHECIMENTO ORGANIZACIONAL. Perspectivas em Gestão & Conhecimento, v. 7, n. 2, p. 122–159, 22 dez. 2017.
LIMA-MARQUES, M. et al. Relatório Técnico Unificado: Arquitetura da Informação para o Programa Espacial Brasileiro. Brasília, DF: Centro de Pesquisa em Arquitetura da Informação, Universidade de Brasília, 29 nov. 2017. Disponível em: <https://zenodo.org/record/5093590>. Acesso em: 12 jul. 2021.
CARNIELLI, W.; RODRIGUES, A. An epistemic approach to paraconsistency: a logic of evidence and truth. Synthese, 23 nov. 2017.
CARNIELLI, W.; LIMA-MARQUES, M. Society semantics and the logic way to collective intelligence. Journal of Applied Non-Classical Logics, v. 27, n. 3–4, p. 255–268, 2 out. 2017.
LIMA-MARQUES, M.; SOUZA, B. C. C. Registro Civil de Pessoas Naturais. Brasília, DF: INOVA Instituto de Ciência, Tecnologia e Inovação, 12 set. 2017. Disponível em: <https://zenodo.org/record/5093600>. Acesso em: 12 jul. 2021.
LIMA-MARQUES, M. et al. Estudo de impacto da mudança da CNH e do CRLV para cartões inteligentes. BrasÍlia, DF: Centro de Pesquisa em Arquitetura da Informação, Universidade de Brasília, 24 ago. 2017. Disponível em: <https://zenodo.org/record/5093585>. Acesso em: 12 jul. 2021.
COSTA, I. DE M.; LIMA-MARQUES, M. MAIA - Método de Arquitetura da Informação Aplicada. Informação & Informação, v. 22, n. 1, p. 60–87, 19 jun. 2017.
ARAUJO, L. C.; LIMA-MARQUES, M. Configuração da Informação? Informação & Informação, v. 21, n. 3, p. 327–360, 14 abr. 2017.
CARNIELLI, W. A.; PULCINI, G. Cut-elimination and deductive polarization in complementary classical logic. Logic Journal Of The Igpl, v. 25, n. 3, p. 273–282, 10 abr. 2017.
LACERDA, F. et al. Information ecosystems: New paradigm for Information Architecture. Transinformação, v. 29, n. 1, p. 81–90, 2017.
LACERDA, F. et al. Ecossistemas de informação: novo paradigm para a Arquitetura da Informação. Transinformação, v. 29, n. 1, p. 81–90, 2017.
SOUZA, B. C. C. Big data fotográfico e o potencial de recuperação da informação. Revista Photo & Documento, v. 0, n. 2, p. 5, 15 nov. 2016.
BUENO-SOLER, J. et al. Paraconsistent Probabilities: Consistency, Contradictions and Bayes’ Theorem. Entropy, v. 18, n. 9, p. 325, 7 set. 2016.
CARNIELLI, W. To be computable is not the same as to be constructible. Filosofia Unisinos, v. 17, n. 2, p. 244-246–246, 2 ago. 2016.
LIMA-MARQUES, M. et al. Relatório Técnico: Arquitetura da Informação da Gestão de Resíduos Sólidos do Governo Federal: Revisão e Ajustes da AIO 1.0. Brasília, DF: Centro de Pesquisa em Arquitetura da Informação, Universidade de Brasília, 17 jun. 2016. Disponível em: <https://zenodo.org/record/5093606>. Acesso em: 12 jul. 2021.
SOUZA, B. C. C. Projetos CPAI: visão geral 2016/2017. 6o Colóquio de Arquitetura da Informação. Anais... In: 6o COLÓQUIO DE ARQUITETURA DA INFORMAÇÃO. 23 abr. 2016Disponível em: <http://eventos.cpai.unb.br/index.php/6cai2016/6cai2016/paper/view/12>. Acesso em: 27 abr. 2016
SOUZA, B. C. C.; LIMA-MARQUES, M. Fotografia: construção de significado e arquitetura da informação. Revista Photo & Documento, v. 0, n. 1, p. 1–13, 10 abr. 2016.
CARNIELLI, W. A.; LIMA-MARQUES, M. Society semantics and the logic way to collective intelligence. In: CABALAR, P. et al. (Eds.). . Logical reasoning and computation: essays dedicated to Luis Fariñas Del Cerro. 1. ed. Paris: [s.n.]. p. 139–147.
LIMA-MARQUES, M.; CARNIELLI, W. A. Formal aspects of Architecture of Information. In: CABALAR, P. et al. (Eds.). . Logical reasoning and computation: essays dedicated to Luis Fariñas Del Cerro. 1. ed. Paris: [s.n.]. p. 33–42.
LACERDA, F. Arquitetura da Informação Pervasiva: projetos de ecossistemas de informação na internet das coisas. Tese / Thesis—Brasília, DF: Universidade de Brasília, 2 mar. 2016.
CARNIELLI, W.; CONIGLIO, M. E. Paraconsistent set theory by predicating on consistency. Journal of Logic and Computation, v. 26, n. 1, p. 97–116, 2016.
PEREIRA JUNIOR, R. A. Uma proposta de arquitetura genética da informação. Revista Ibero-Americana de Ciência da Informação, v. 9, n. 1, p. 319, 3 dez. 2015.
LACERDA, F.; LIMA-MARQUES, M. Da necessidade de princípios de Arquitetura da Informação para a Internet das Coisas. Perspectivas em Ciência da Informação, v. 20, n. 2, p. 158–171, 30 jun. 2015.
BRELAZ, A. P. Discurso sobre uma fundamentação ontológica da informação. Dissertação (Mestrado em Ciência da Informação)—Brasília, DF: Univesidade de Brasília, 1 jun. 2015.
ALEXANDRE ZAGUETTO; BRUNO LUIGGI MACCHIAVELLO ESPINOZA; MAMEDE LIMA-MARQUES. MidasBrasília, 22 abr. 2015.
CARNIELLI, W.; MATULOVIC, M. The method of polynomial ring calculus and its potentialities. Theoretical Computer Science, v. 606, p. 42–56, 2015.
PASSOS, R.; MEALHA, Ó.; LIMA-MARQUES, M. Uma discussão sobre o objeto do design da informação. Editora Edgard Blücher, 2015Disponível em: <http://www.proceedings.blucher.com.br/article-details/20278>. Acesso em: 31 maio. 2016
CARNIELLI, W. et al. TOWARDS A PHILOSOPHICAL UNDERSTANDING OF THE LOGICS OF FORMAL INCONSISTENCY. Manuscrito, v. 38, n. 2, p. 155–184, 2015.
SOUZA, B. C. C.; LIMA-MARQUES, M. Relatório-Síntese CPAI 2012-2014. BrasÍlia, DF: Centro de Pesquisa em Arquitetura da Informação, Universidade de Brasília, 2015.
SOUZA, B. C. C.; LIMA-MARQUES, M. 5o CAI - Colóquio de Arquitetura da Informação. Brasília, DF: Centro de Pesquisa em Arquitetura da Informação, Universidade de Brasília, 2015.
AZEVEDO, R. F. DE B. C. Um modelo ontológico do sistema eleitoral brasileiro. Mestrado em Ciência da Informação—Brasília, DF: Universidade de Brasília, Faculdade de Ciência da Informação, 10 dez. 2014.
FERREIRA, E. DE A. Modelo para condução de mapeamento de processo organizacional: uma abordagem BPM com base no MAIA. Dissertação (Mestrado em Ciência da Informação)—BrasÍlia, DF: Universidade de Brasília, Faculdade de Ciência da Informação, 28 fev. 2014.
CARNIELLI, W. et al. ON THE WAY TO A WIDER MODEL THEORY: COMPLETENESS THEOREMS FOR FIRST-ORDER LOGICS OF FORMAL INCONSISTENCY. The Review of Symbolic Logic, v. 7, n. 03, p. 548–578, 2014.
CARNIELLI, W.; MATULOVIC, M. Non-deterministic Semantics in Polynomial Format. Electronic Notes in Theoretical Computer Science, v. 305, p. 19–34, 2014.
LIMA-MARQUES, M. Ciência e inovação tecnológica: caminhos para a modernidade. Tecnologias Aplicadas nas Atividades Fundamentais no Estado. Anais... In: TECNOLOGIAS APLICADAS NAS ATIVIDADES FUNDAMENTAIS NO ESTADO. 2014
MACEDO, F. L. O. DE; LIMA-MARQUES, M. Information Architecture as a discipline. In: RESMINI, A. (Ed.). . Reframing Information Architecture. Human-Computer Interaction. Switzerland: Springer International Publishing, 2014.
PASSOS, R. Design da informação. Doutorado em Desenho Industrial—Portugal: Universidade de Aveiro, 2014.
FERNANDES, G. L. Proposta de fundamentação teórica para o problema do entendimento humano. Dissertação (Mestrado em Ciência da Informação)—Brasília, DF: Universidade de Brasília, Faculdade de Ciência da Informação, 2014.
ALBUQUERQUE, F. A. A. C. DE. Modelo de framework de Arquitetura da Informação baseado em roteiros. Dissertação (Mestrado em Ciência da Informação)—Brasília: Universidade de Brasília, 2014.
FILHO, P. A. DA C. R. Um modelo de arquitetura da informação orientado a serviços. Dissertação (Mestrado em Ciência da Informação)—Brasília: Universidade de Brasília, 2014.
FERNANDES, G. L. Requisitos de Software: uma abordagem epidêmica. In: SEMINÁRIOS DE ARQUITETURA DA INFORMAÇÃO CPAI. , 2014.

Visão Geral

O Processo Modal de Gestão de Projetos – Agile (PMGP-a) é um processo de gerenciamento de projetos composto por ferramentas, modelos e práticas recomendadas que permite que seus usuários sejam mais eficientes e eficazes na entrega do projeto, independentemente do tamanho ou da complexidade.

O conteúdo deste documento é baseado no PMI (Project Management Institutes) Um guia para o Conhecimento em Gerenciamento de Projetos (PMBOK)

A Diretoria Técnica do Instituto Modal criou o PMGP-a para ajudar as equipes de trabalho a realizar suas missões principais por meio da entrega bem-sucedida do projeto. O uso dessas ferramentas e modelos pode ajudar a obter consistência, padronização e sucesso do projeto.

Revisões

VersãoDataDescrição
1.02020.02.22Criação da versão inicial. Elaboração dos primeiros modelos de artefatos.
1.02020.02.27Inclusão de conceitos iniciais. Revisão de artefatos.
1.02020.06.16Inclusão do documento “Protocolo de Entrega”.

Conceitos Iniciais

Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos.

Um projeto é composto de fases ou etapas. Cada fase possui entregas específicas.

Entrega é qualquer resultado concreto — seja produto ou serviço — gerado pelo projeto e que seja verificável e atenda aos critérios de aceitação previamente estabelecidos.

Estrutura analítica do projeto / Work Breakdown Structure (WBS) é a decomposição hierárquica orientada à entrega do trabalho a ser executado pela equipe do projeto para atingir os seus objetivos e criar as entregas necessárias. Ela organiza e define o escopo total do projeto.

Processo de Gestão de Projetos é o conjunto ordenado de etapas, procedimentos, artefatos e metodologia utilizados para gerenciar um ou mais projetos, conforme as diretrizes e modelos de gestão adotados pela empresa.

Modelos de Documentos

Artefato / ModeloDescrição
Justificativa de NegócioO documento Justificativa de Negócio define a necessidade do negócio, juntamente com as informações necessárias, do ponto de vista comercial, para determinar se o projeto vale ou não o investimento necessário. Ele demonstra o alinhamento aos objetivos estratégicos e de negócios e é usado para priorizar o projeto entre outras demandas do projeto.
Termo de Abertura do ProjetoTermo de Abertura do Projeto (ou Carta do Projeto ou Project Charter, em inglês) autoriza oficialmente o projeto e aloca recursos, iniciando oficialmente o trabalho.
Plano de Gerenciamento do ProjetoPlano de Gerenciamento do Projeto define “como” o projeto é executado, monitorado, controlado e fechado.
Cronograma do ProjetoCronograma do Projeto ajuda a planejar e rastrear datas importantes no projeto. O Instituto Modal utiliza o OpenProject ou o GitHub para gerenciar o cronograma do projeto.
Documento de RequisitosDocumento de Requisitos detalha os requisitos específicos do projeto e do produto que devem ser atendidos para satisfazer os objetivos de negócios. Os primeiros levantamentos poderão ser feitos mediante planilha específica, mas imediatamente após o início da execução do projeto todos os requisitos deverão ser transportados para o OpenProject ou para o GitHub, dependendo das características do projeto.
Registro do ProjetoRegistro do Projeto é uma ferramenta que pode ser usada para capturar e rastrear as principais informações do projeto, facilitando o monitoramento e o controle dos detalhes do projeto durante toda a sua vida útil. O Instituto Modal utiliza o OpenProject ou o GitHub para fazer o registro do projeto.
Notas de Reuniões do ProjetoO modelo de Notas de Reuniões do Projeto é usado para documentar e comunicar anotações para todas as reuniões do projeto. Opcionalmente, as anotações podem ser feitas no OpenProject ou o GitHub e vinculadas a fases e/ou tarefas do projeto.
Relatório de AtividadesRelatório de Atividades é utilizado pelos colaboradores do projeto para comunicar periodicamente (a cada sprint ou outro intervalo de tempo definido pelo Gerente do Projeto) a situação das atividades sob sua responsabilidade. O conjunto dos Relatórios de Atividades de todos os colaboradores poderá ser anexado ao Relatório de Status do Projeto.
Relatório de Status do ProjetoRelatório de Status do Projeto (ou Relatório Gerencial) é utilizado para comunicar a integridade geral do projeto à equipe principal e às principais partes interessadas, para manter todos informados sobre o andamento do projeto. O Relatório de Status do Projeto é feito em LaTeX e adaptado para a necessidade de cada cliente.
Ordem de ServiçoOrdem de Serviço(OS) é usada pelo Cliente para formalizar a solicitação de uma demanda adicional a uma tarefa ou fase do projeto sem que isso implique alteração significativa de escopo / cronograma / custos. A OS precisa ser aprovada tanto pelo Cliente quanto pelo Gerente do Projeto.
Solicitação de Mudança no ProjetoSolicitação de Mudança no Projeto (SMP) é usada pelo Cliente e/ou pelo Gerente de Projeto para solicitar uma alteração no escopo, cronograma, custos, marcos e / ou entregas do projeto. A SMP precisa ser aprovada tanto pelo Cliente quanto pelo Gerente do Projeto.
Lições AprendidasO documento Lições Aprendidas é usado para identificar e preservar as lições aprendidas em cada projeto. O objetivo deste documento é ajudar a equipe do projeto a compartilhar o conhecimento obtido com a experiência. Um programa bem-sucedido de lições aprendidas ajudará as equipes de projeto a repetir resultados desejáveis e evitar resultados indesejáveis. Usualmente, o Registro do Projeto é utilizado para colecionar as lições aprendidas e, ao final do projeto, essa coleção é transformada em um arquivo compilado com todas as anotações.
Termo de Encerramento do ProjetoO documento Termo de Encerramento do Projeto formaliza a conclusão do projeto.
Protocolo de EntregaO documento Protocolo de Entrega é utilizado para registrar a movimentação de qualquer tipo de material e/ou documento entre duas pessoas e/ou organizações, comprovando a entrega e o recebimento do material e/ou documento listado.

Conforme a necessidade do projeto, alguns desses artefatos podem ser simplificados ou fundidos em um único documento.

A figura 1 dá uma visão geral das etapas do PMGP-a e de quais documentos são utilizados em cada etapa.

Processo de Gestão

Para projetos gerenciados  de maneira ágil, as etapas do projeto não aderem às fases sequenciais da mesma maneira que uma abordagem em cascata tradicional. Ao contrário de uma abordagem em cascata, uma metodologia ágil se concentra no desenvolvimento e na implantação de soluções o mais rápido possível, fazendo ajustes à medida que o projeto avança.

O PMGP-a recomenda que o início de um projeto siga um processo semelhante a uma metodologia em cascata, em que informações sobre a Justificativa de Negócio são primeiramente compiladas e avaliadas para investir esforço e dinheiro em um projeto.

Uma vez que a visão para um projeto é estabelecida, o resultado final desejado é definido, a análise de custo-benefício foi realizada e a organização determinou que o investimento vale a pena, a execução real do projeto ocorre de maneira incremental / iterativa.

A função de um gerente de projeto em um projeto ágil

Projetos ágeis não apenas seguem um processo ligeiramente diferente de um projeto tradicional (em cascata), mas algumas das funções dentro da equipe do projeto também são um pouco diferentes. Em algumas metodologias ágeis, não há função específica para “Gerente de Projeto”. Em vez disso, termos como Scrum Master são usados, como é o caso na metodologia Scrum. Líder de equipe é outro termo frequentemente usado nas estruturas de equipe do projeto Agile.

Em projetos ágeis, os cronogramas (mais especificamente o conteúdo ou as entregas de um incremento ou “sprints“) são mais fluidos. Com o início de cada novo sprint, a meta e a saída esperada são determinadas pela análise de uma combinação dos requisitos do projeto, também chamados de backlogfeedback do cliente sobre o estado atual do desenvolvimento e qualquer reprioritização dos objetivos, necessidades, requisitos do projeto etc.

Embora seja importante entender os objetivos do projeto geral e ter uma ideia de alto nível em relação à saída de cada sprint, as equipes do projeto devem ser flexíveis e capazes de se adaptar às mudanças nos requisitos e/ou redefinição de prioridade.

Para facilitar essa abordagem, uma pessoa que gerencia esses processos deve ser flexível e pronta para fazer ajustes rapidamente, em vez de se concentrar na adesão a um plano predefinido.

Outros Papéis / Membros da Equipe
  • Cliente: O cliente é o principal interessado de um projeto. Parte das responsabilidades do cliente é ter uma visão do que ele ou ela deseja construir e transmitir essa visão à equipe. Isso é essencial para iniciar com êxito qualquer projeto ágil. Essa pessoa é, em última análise, responsável pela priorização de requisitos / resultados, bem como da redefinição de prioridades de requisitos e resultados ao longo da vida do projeto, especificamente no início de cada novo sprint.
  • Membro da equipe: Essa função é responsável pela criação e entrega das tarefas de um projeto. Isso inclui atividades de pesquisa, modelagem, desenvolvimento, teste e liberação, além de outras.
Iniciando um Projeto

Trata-se da revisão da ideia de negócio e a sua transformação em um projeto formal.

Atividades chave:
  • Identificar o problema que precisa ser resolvido
  • Identificar os benefícios de realizar o projeto, incluindo impactos financeiros, como retorno do investimento
  • Definir os resultados esperados e os principais marcos. No caso de projetos ágeis, é mais importante estimar o número de sprints que podem ser necessários e/ou a duração geral do trabalho, em vez de requisitos detalhados específicos que precisam ser atendidos.
  • Identificar riscos e restrições do projeto
  • Identificar as principais partes interessadas e os recursos necessários
Justificativa de Negócio

O patrocinador do projeto ou o proprietário da empresa é a pessoa mais indicada para preparar esse artefato. Este documento abordará o problema e o resultado esperado, bem como os principais recursos necessários para o projeto. Ele define como o projeto se alinhará aos objetivos da organização.

Termo de Abertura do Projeto

No Termo de Abertura do Projeto deve ser definido o escopo do projeto, bem como criada uma linha do tempo estimada e estabelecido o orçamento do projeto. Em uma abordagem em cascata, este documento é uma elaboração / complemento para a Justificativa de Negócio, mas, em uma abordagem ágil, pode fazer sentido combinar esses dois documentos. O fator importante a ser lembrado é que esses documentos, tradicionalmente resultando em planos relativamente detalhados, devem permanecer em ‘alto nível’. A ênfase deve estar em estabelecer e priorizar requisitos de alto nível (funções do produto que está sendo desenvolvido). Ao iniciar sprints, durante a execução do projeto, esses requisitos / funções serão desenvolvidos e liberados de forma incremental, com base na prioridade. E, essas prioridades podem mudar, e geralmente mudam, ao longo da vida do projeto, para que cada sprint precise de um “pontapé inicial”.

Documento de Requisitos

Este documento fornece um mecanismo para rastrear as entregas do produto / projeto em relação aos requisitos, para garantir que os requisitos de negócios e produtos sejam atendidos. Ao usar uma abordagem ágil, esses requisitos podem assumir a forma de funções de nível superior do produto que está sendo desenvolvido. Os requisitos / especificações detalhados definidos no início do projeto, ao alavancar uma abordagem em cascata, são aprimorados durante os sprints por meio da colaboração entre o cliente, usuários e a equipe de trabalho.

Ao desenvolver requisitos, deve ser considero o uso de imagens e/ou diagramas de processos de negócios e/ou interações do usuário com a solução que está sendo desenvolvida. Quadros de histórias, fluxos de processos e histórias de usuários são técnicas comuns para documentar requisitos em Projetos Agile.

Uma história de usuário é uma ferramenta usada no desenvolvimento de software Agile para capturar uma descrição de um recurso de software sob a perspectiva do usuário final. A história do usuário descreve o tipo de usuário, o que eles querem e por quê. Uma história de usuário ajuda a criar uma descrição simplificada de um requisito.

Execução do Projeto

Na execução, os projetos ágeis adotam uma abordagem incremental / iterativa. Isso significa que partes do produto geral são desenvolvidas e implantadas e, em seguida, a próxima parte do produto geral é desenvolvida e implantada, e assim por diante. É importante que, no início do projeto, o produto mínimo viável seja definido e que o plano de liberação descreva o que cada um dos incrementos (sprints) fornecerá. Durante toda a vida do projeto, o plano de liberação e a saída dos vários sprints são continuamente reavaliados e possivelmente re-priorizados, com base nas necessidades dos negócios e dos clientes.

Atividades chave
  • Reuniões de kickoff do sprint;
  • Verificação diária nas reuniões de equipe, também conhecida como reuniões do Scrum;
  • Coletar / documentar requisitos e produtos não identificados nas etapas anteriores do projeto, para que possam ser incorporados nos próximos sprints;
  • Coletar / documentar lições aprendidas para que futuros sprints possam ser ajustados de acordo.
Registro do Projeto

O Registro do Projeto pode ser usado para rastrear itens de ação, decisões, entregas, riscos, problemas, informações de contato das partes interessadas e muito mais. Este documento / ferramenta pode ser crucial na atividades de iniciação de sprints / Kickoffs.

Notas de Reuniões do Projeto

As notas de reuniões devem ser utilizadas em todas as reuniões do projeto para documentar a agenda da reunião, itens de ação, decisões tomadas, quem participou e para quando foi agendada a próxima reunião.

Relatórios de Status do Projeto

O Relatório de Status do Projeto comunica os principais indicadores de desempenho (KPIs), as principais datas e os principais riscos / problemas relacionados ao projeto, a fim de manter todos os participantes igualmente informados.

Ordem de Serviço (OS)

A Ordem de Serviço (OS) é usada pelo Cliente para formalizar a solicitação de uma demanda adicional a uma tarefa ou fase do projeto sem que isso implique alteração significativa de escopo / cronograma / custos. A OS precisa ser aprovada tanto pelo Cliente quanto pelo Gerente do Projeto.

Solicitação de Mudança do Projeto (SMP)

Este documento deve ser utilizado para documentar as principais mudanças no projeto que afetam o escopo, o cronograma, os custos, a qualidade ou o desempenho e a saúde do projeto. Este formulário não deve ser usado para gerenciar atividades operacionais diárias, monitoramento e controle de projetos, pois isso adicionará uma sobrecarga significativa às atividades de gerenciamento de projetos.

Plano de Gerenciamento do Projeto (opcional)

Este modelo estabelece um plano e estratégia para “como” o projeto será executado. O termo de abertura do projeto define o “quê”, enquanto o plano de gerenciamento do projeto define o “como”.

Encerramento do Projeto

Na fase de encerramento do projeto, os artefatos do projeto são arquivados, as atividades do projeto são concluídas e o projeto passa para o status de “operacional”.

Atividades chave
  • Transição do projeto para “Operacional”
  • Arquivar artefatos do projeto em repositório
  • Documentar as lições aprendidas e realizar a reunião de revisão final do projeto
  • Planejar um post mortem para o projeto
  • Obter aprovação para o fechamento formal do projeto
Lições Aprendidas

O documento Lições Aprendidas deve ser preenchido usando as informações do Registro do Projeto e quaisquer outros artefatos pertinentes ao projeto, bem como o feedback da equipe obtido em qualquer etapa do projeto.

Termo de Encerramento do Projeto

O Termo de Encerramento do Projeto formaliza a confirmação de que todos os objetivos do escopo foram atendidos e os itens necessários foram finalizados. Isso inclui garantir que todas as entregas listadas foram concluídas e a documentação do projeto foi salva no repositório adequado. Este documento também permite formalizar como as ações / questões pendentes devem ser tratadas.

Modelos de Documentos

O Instituto Modal possui um padrão para formato, nomeação e numeração de documentos. Os modelos estão disponíveis exclusivamente para colaboradores.

Formatos de documentos e tipos de arquivos

Em relação ao formato, LaTeX é a opção preferencial, porém há alguns documentos em format Word / Libreoffice para facilitar a troca de arquivos com clientes e parceiros.

Em linhas gerais, recomenda-se a seguinte estratégia para os formatos de documentos:

Documentos de PD&I (relatórios técnicos, white papers, propostas de projetos de inovação etc.): usar obrigatoriamente LaTeX, exceto se exigido outro formato pelo cliente ou publicação.
Documentos administrativos (contratos, acordos etc.): usar formato Word ou, preferencialmente, LibreOffice. Os ofícios são exceção a essa regra, uma vez que são feitos em LaTeX.
Outros documentos: avaliar caso a caso, dando preferência, sempre que possível, a LaTeX.

Padrão de numeração e nomeação de arquivos

Os arquivos e documentos com destino ao público externo seguem um padrão de nomeação e numeração específico, composto por uma string de caracteres e referência a data de criação do documento. O padrão é:

AAAA..MMDD., onde:

  • AAAA: Ano atual (exemplo: 2020)
  • : Sigla do tipo de documento (RT = Relatório Técnico; WP = White Paper; ACT = Acordo Técnico de Cooperação; PROP = Proposta; CTO = Contrato etc.)
  • MM.DD: Mês e Dia em que o documento foi criado (não necessariamente o que ele foi emitido). Exemplo: 04.03
  • : Informação complementar para facilitar a identificação e/ou a diferenciação. Exemplo: sigla do cliente e/ou do projeto, letra ou código complementar caso tenha dois documentos do mesmo tipo no mesmo dia etc.

Esses padrões foram criados para:

  • Evitar erros de numeração, que poderiam ocorrer caso houvesse qualquer tipo de controle sequencial, especialmente dada a natureza relativamente descentralizada que o Instituto Modal adota para a emissão de documentos;
  • Facilitar a criação padronizada de nomes de arquivos, mantendo a simplicidade na identificação rápida do documento (data e tipo);
  • Gerar identificadores únicos para cada documento, de acordo com sua natureza.
Relação dos tipos de documentos
  • ACT: Acordo Técnico de Cooperação
  • ACTEC: Atestado de Capacidade Técnica (emitido pelo Modal)
  • CRT: Certificado (de capacitação ou treinamento)
  • CTO: Contrato
  • INV: Invoice (emitida pelo Modal para transações internacionais – substitui a nota fiscal nesse tipo de transação)
  • NDA: Non-Disclosure Agreement, ou Acordo de Confidencialidade
  • OF: Ofício (emitido pelo Modal)
  • PPI: Plano de Pesquisa Individual
  • PPI: Proposta de Projeto de Inovação
  • PPP: Proposta de Projeto de Pesquisa
  • PPQ: Plano de Pesquisa
  • PROP: Proposta
  • PTRAB: Plano de Trabalho
  • RGER: Relatório Gerencial
  • RST: Relatório de Status do Projeto
  • RT: Relatório Técnico
  • TCOMP: Termo de Compromisso
  • WP: White Paper
Esqueci minha senha! E agora?
Como completo o meu curso e gero o meu certificado?
Perguntas Frequentes sobre LGPD
EnglishFrançaisDeutschItalianoPortuguêsEspañol
Rolar para cima
× Como posso ajudar? Available from 09:00 to 18:00 Available on SundayMondayTuesdayWednesdayThursdayFridaySaturday