Gestão de Projetos e Contratações de TI no DETRAN

Gestão de projetos aplicada ao contexto do DETRAN

Na prática do DETRAN, gestão de projetos é o conjunto de processos e artefatos usados para planejar, executar e controlar entregas (ex.: implantação de um módulo, evolução de um serviço digital, migração de infraestrutura, contratação de fábrica de software), garantindo previsibilidade de prazo, custo, qualidade e conformidade. Quando há contratação de TI, a gestão de projetos precisa “conversar” com a gestão contratual: o que será entregue deve estar especificado, mensurável, testável e fiscalizável.

Este capítulo foca em práticas de execução e controle: termo de abertura, escopo, cronograma, riscos, comunicação e aceitação, conectando cada item à contratação e fiscalização (especificação técnica, critérios de aceite, níveis de serviço e gestão do fornecedor).

Termo de Abertura (TAP): autorização e alinhamento inicial

O que é e por que importa

O Termo de Abertura do Projeto (TAP) formaliza a existência do projeto, define objetivos, justificativa, patrocinador, gerente do projeto, premissas, restrições e critérios de sucesso. Em ambiente público, o TAP ajuda a reduzir disputas de escopo e sustenta decisões de priorização e alocação de recursos.

Passo a passo prático

• Defina o problema e o objetivo mensurável: ex.: “reduzir tempo médio de atendimento do serviço X em 30%” ou “habilitar integração com sistema Y até data Z”.
• Delimite o produto/entrega: o que será entregue ao final (módulo, serviço, relatório, migração, etc.).
• Identifique stakeholders: áreas demandantes, TI, jurídico, compras, controle interno, fornecedor (se houver).
• Registre premissas e restrições: ex.: janela de implantação, dependência de órgão externo, orçamento, regras de homologação.
• Defina critérios de sucesso: indicadores e evidências (ex.: aceite formal, métricas de desempenho, disponibilidade, aderência a SLA).

Template textual (TAP)

TERMO DE ABERTURA DO PROJETO (TAP) 1. Identificação Projeto: [nome] Unidade demandante: [área] Patrocinador: [nome/cargo] Gerente do Projeto: [nome] 2. Objetivo (SMART) [objetivo mensurável e prazo] 3. Justificativa [benefício público, conformidade, eficiência] 4. Escopo em alto nível (entregas) [lista de entregas] 5. Fora do escopo [itens explicitamente excluídos] 6. Premissas [lista] 7. Restrições [lista] 8. Stakeholders-chave [lista e papel] 9. Critérios de sucesso e evidências [ex.: termo de aceite, relatórios, métricas] 10. Riscos iniciais [top 5] 11. Aprovações [assinaturas/registro]

Escopo: especificação técnica e controle de mudanças

Conceito aplicado

Escopo é a definição do que será entregue e do trabalho necessário para entregar. Em contratações de TI, o escopo precisa ser traduzido em especificação técnica e itens verificáveis, reduzindo subjetividade na fiscalização. O controle de mudanças evita “escopo elástico” (crescimento informal de demandas) que compromete prazo e custo.

Como estruturar o escopo para contratação e fiscalização

• Entregas (deliverables) claras: cada entrega deve ter descrição, formato, responsável e evidência de conclusão.
• Requisitos verificáveis: evitar termos vagos (“interface moderna”); preferir critérios mensuráveis (“compatível com navegadores A/B”, “tempo de resposta < X”).
• Critérios de aceite por entrega: condições objetivas para aceitação (testes, documentos, evidências).
• Rastreabilidade: cada item do escopo deve mapear para um item contratual (ordem de serviço, item de catálogo, marco).

Passo a passo prático (EAP + Dicionário de Entregas)

• Liste entregas principais (nível 1): ex.: “MVP do serviço”, “Integração”, “Treinamento”, “Implantação”.
• Decomponha em entregas menores (nível 2/3): ex.: “Tela A”, “API B”, “Relatório C”, “Scripts de deploy”.
• Crie o dicionário: para cada entrega, descreva conteúdo, padrão, critérios de aceite, evidências e dependências.
• Defina processo de mudança: como solicitar, analisar impacto, aprovar e registrar (comitê, GP, fiscal).

Checklist de escopo fiscalizável

• Entregas descritas com formato e evidência (ex.: repositório, pacote, documento).
• Critérios de aceite objetivos por entrega.
• Dependências explícitas (internas e externas).
• Itens fora do escopo registrados.
• Processo de mudança definido (quem aprova e como registra).

Cronograma: marcos, dependências e gestão de prazos

Conceito aplicado

Cronograma é a organização temporal do trabalho e das entregas. Em contratação, o cronograma deve estar alinhado a marcos de pagamento e a eventos de fiscalização (reuniões, entregas parciais, homologação). Prazos precisam considerar dependências institucionais (aprovações, janelas de implantação, validações).

Continue em nosso aplicativo

Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.

ou continue lendo abaixo...

Baixar o aplicativo

Passo a passo prático (cronograma orientado a marcos)

• Defina marcos contratuais: início, entregas parciais, homologação, implantação, encerramento.
• Mapeie dependências: ex.: “homologação depende de ambiente disponível”, “integração depende de credenciais”.
• Estime duração por pacote de trabalho (da EAP) e identifique caminho crítico.
• Inclua buffers: para riscos previsíveis (aprovação, ajustes de homologação).
• Amarre a governança: reuniões quinzenais, checkpoints, relatórios.

Template textual (marcos)

CRONOGRAMA (MARCO / DATA / CRITÉRIO) M0 Kickoff: [data] Evidência: ata de reunião + plano de trabalho aprovado M1 Entrega Parcial 1: [data] Evidência: pacote entregue + relatório de testes unitários M2 Homologação: [data] Evidência: execução do plano de testes de aceite + registro de não conformidades M3 Implantação: [data] Evidência: checklist de implantação + validação pós-implantação M4 Aceite final: [data] Evidência: termo de aceite + relatório de SLA inicial

Gestão de riscos: matriz, respostas e monitoramento

Conceito aplicado

Risco é um evento incerto que, se ocorrer, afeta objetivos do projeto. Em contratações, riscos típicos envolvem ambiguidade de escopo, dependências externas, qualidade insuficiente, atrasos, indisponibilidade de equipe do órgão para homologação e falhas de fornecedor. A matriz de riscos orienta ações preventivas e define responsáveis.

Passo a passo prático (matriz de riscos)

• Identifique riscos: com base em entregas, dependências, restrições e histórico.
• Classifique probabilidade e impacto: escala 1 a 5.
• Calcule severidade: P x I e priorize.
• Defina resposta: evitar, mitigar, transferir, aceitar.
• Defina dono do risco: órgão ou fornecedor.
• Defina gatilhos e plano de contingência: sinais de que o risco está se materializando e o que fazer.
• Monitore periodicamente: em reuniões de status e relatórios.

Estudo de caso 1: Matriz de riscos para contratação de evolução de serviço digital

Cenário: contratação para evoluir um serviço digital com entrega em 90 dias, incluindo integração com sistema externo e implantação em produção.

MATRIZ DE RISCOS (EXEMPLO) Escala: Probabilidade (P) 1-5 | Impacto (I) 1-5 | Severidade = P*I ID | Risco | Causa | P | I | Sev | Resposta | Ação preventiva | Contingência | Dono | Gatilho R1 | Atraso por dependência de credenciais externas | Órgão externo demora liberar acesso | 4 | 4 | 16 | Mitigar | Solicitar credenciais no D0; acompanhar semanalmente | Replanejar integração; usar mock temporário | Órgão | 10 dias sem resposta R2 | Escopo ambíguo gera retrabalho | Especificação incompleta | 3 | 5 | 15 | Evitar | Refinar critérios de aceite; validar com fiscal e área demandante | Abrir mudança formal com impacto | Órgão | Divergência em homologação R3 | Entrega com baixa qualidade | Testes insuficientes do fornecedor | 3 | 4 | 12 | Mitigar | Exigir evidências de testes; gate de qualidade por entrega | Rejeitar entrega; aplicar plano de correção | Fornecedor | Taxa alta de defeitos na homologação R4 | Indisponibilidade de usuários para homologação | Agenda da área demandante | 4 | 3 | 12 | Mitigar | Reservar janelas; nomear homologadores substitutos | Estender homologação e ajustar marcos | Órgão | Homologação sem quórum R5 | Falha na implantação | Checklist incompleto / janela curta | 2 | 5 | 10 | Mitigar | Plano de implantação; ensaio em ambiente de pré-produção | Rollback e reimplantação | Fornecedor | Erros no ensaio

Estudo de caso 2: Matriz de riscos para contratação com SLA (suporte e sustentação)

Cenário: contratação de sustentação com níveis de serviço para atendimento e correção.

MATRIZ DE RISCOS (SLA) ID | Risco | P | I | Resposta | Ação preventiva | Evidência de fiscalização R6 | Descumprimento de tempo de resposta | 3 | 4 | Mitigar | Definir SLA por severidade; ferramenta de chamados; penalidades | Relatório mensal de SLA + amostra de tickets R7 | Classificação incorreta de severidade | 4 | 3 | Mitigar | Critérios objetivos; auditoria por amostragem | Revisão de tickets e reclassificação R8 | Rotatividade da equipe do fornecedor | 3 | 3 | Mitigar | Exigir plano de transição e documentação mínima | Registro de handover + atualização de base de conhecimento

Comunicação: ritos, registros e transparência

Conceito aplicado

Comunicação em projeto é a definição de quem precisa saber o quê, quando e em qual formato. Em contratação, comunicação estruturada reduz conflitos e cria trilha de auditoria: atas, relatórios, ordens de serviço, registros de aceite e não conformidades.

Passo a passo prático (plano de comunicação)

• Mapeie públicos: patrocinador, demandante, TI, fiscal/gestor do contrato, fornecedor.
• Defina cadência: daily/semanais (técnico), quinzenais (status), mensais (SLA).
• Defina artefatos: ata, relatório de status, registro de riscos, registro de mudanças, relatório de SLA.
• Defina canal e responsável: e-mail institucional, sistema de chamados, repositório oficial, ferramenta de gestão.
• Defina padrão de escalonamento: quando e para quem escalar impedimentos.

Template textual (plano de comunicação)

PLANO DE COMUNICAÇÃO Evento | Público | Frequência | Canal | Responsável | Saída Reunião de acompanhamento | Fiscal + fornecedor + TI | Semanal | Videoconf/Presencial | GP/Fiscal | Ata + lista de ações Status executivo | Patrocinador | Quinzenal | E-mail | GP | Relatório 1 página Gestão de riscos | Time do projeto | Quinzenal | Reunião | GP | Riscos atualizados Homologação | Homologadores + fornecedor | Conforme cronograma | Ambiente de testes | Fiscal | Registro de evidências e defeitos SLA | Gestor do contrato | Mensal | Relatório | Fornecedor | Painel de indicadores

Aceitação: critérios de aceite, plano de testes e evidências

Conceito aplicado

Aceitação é a verificação formal de que a entrega atende ao que foi especificado. Em contratação, critérios de aceite e plano de testes são fundamentais para permitir: (1) aceitar e pagar corretamente, (2) rejeitar entregas com base objetiva, (3) registrar não conformidades e prazos de correção.

Como definir critérios de aceite (práticos e mensuráveis)

• Funcionais: casos de uso/cenários aprovados, regras de negócio atendidas.
• Não funcionais: desempenho, disponibilidade, compatibilidade, acessibilidade (quando aplicável), logs e auditoria.
• Operacionais: manual/roteiro de operação, checklist de implantação, plano de rollback.
• Qualidade de entrega: documentação mínima, versionamento, evidências de testes.

Plano de Testes de Aceitação (UAT/aceite contratual): passo a passo

• Defina escopo do aceite: quais entregas entram na rodada de aceite.
• Defina ambiente: dados de teste, acessos, integrações simuladas quando necessário.
• Defina papéis: executor (homologador), apoio técnico, responsável por registrar evidências, responsável por aprovar.
• Escreva casos de teste: pré-condições, passos, resultado esperado, evidência requerida.
• Defina critérios de aprovação: ex.: “0 defeitos críticos/altos abertos; médios com plano de correção aceito”.
• Execute e registre evidências: prints, logs, relatórios, IDs de chamados.
• Consolide não conformidades: severidade, prazo de correção, reteste.
• Formalize aceite: termo de aceite parcial/final com anexos.

Estudo de caso: Plano de testes de aceitação de uma entrega contratada

Cenário: entrega contratada de um novo módulo de agendamento interno com integração a um serviço externo e geração de comprovante.

PLANO DE TESTES DE ACEITAÇÃO (EXEMPLO) 1. Objetivo Validar a entrega do Módulo de Agendamento v1 conforme especificação e critérios de aceite. 2. Escopo do teste - Cadastro e manutenção de agendas - Agendamento e cancelamento - Integração (consulta de disponibilidade) - Emissão de comprovante 3. Ambiente - Homologação: URL [..] - Base de dados: massa de teste [..] - Integração: endpoint homolog [..] / mock [..] 4. Papéis - Homologador: [nome/área] - Fiscal técnico: [nome] - Fornecedor (apoio): [nome] 5. Critérios de aprovação - 0 defeitos Críticos/Altos abertos - Até 3 defeitos Médios, com correção em até X dias - Evidências anexadas para 100% dos casos executados 6. Casos de teste (amostra) CT-01: Criar agenda Pré: usuário com perfil gestor Passos: acessar menu; criar agenda com horários; salvar Esperado: agenda criada e listada Evidência: print + registro no log CT-02: Consultar disponibilidade (integração) Pré: agenda existente Passos: solicitar disponibilidade; validar retorno Esperado: horários retornam conforme regra Evidência: print + log de requisição CT-03: Agendar atendimento Pré: agenda disponível Passos: selecionar horário; confirmar Esperado: agendamento criado; status confirmado Evidência: print + ID do agendamento CT-04: Cancelar agendamento Pré: agendamento existente Passos: cancelar; confirmar Esperado: status cancelado; horário liberado Evidência: print + log CT-05: Emitir comprovante Pré: agendamento confirmado Passos: emitir comprovante Esperado: PDF gerado com dados corretos Evidência: arquivo PDF anexado 7. Registro de defeitos - Ferramenta: [..] - Campos mínimos: ID, severidade, passos, evidência, versão, responsável, prazo 8. Termo de aceite - Aceite parcial/final condicionado ao atendimento dos critérios acima

Níveis de serviço (SLA) e gestão do fornecedor: do contrato à fiscalização

Como conectar projeto e contrato

Quando a entrega envolve operação/sustentação, o projeto deve prever desde o início como o fornecedor será medido e como o órgão fiscalizará. SLA é um conjunto de metas mensuráveis (tempo de resposta, tempo de solução, disponibilidade, etc.) com método de medição e consequências (glosas, penalidades, planos de melhoria).

Boas práticas para especificar SLA de forma fiscalizável

• Definir catálogo de serviços: o que está coberto (incidentes, requisições, mudanças, plantão).
• Definir severidades objetivas: critérios claros para crítico/alto/médio/baixo.
• Definir métricas e fórmula: como medir tempo de resposta/solução, janela de atendimento, exclusões.
• Definir evidências: relatórios mensais, amostragem de tickets, logs.
• Definir governança: reuniões mensais de SLA, plano de ação para desvios.

Template textual (tabela de SLA)

TABELA DE SLA (EXEMPLO) Severidade | Definição objetiva | Tempo de resposta | Tempo de solução | Janela | Evidência S1 Crítico | Serviço indisponível para todos | 15 min | 4 h | 24x7 | Relatório + logs + ticket S2 Alto | Função essencial indisponível para muitos | 30 min | 8 h | 8x5 | Tickets + amostragem S3 Médio | Impacto moderado, workaround existe | 4 h | 3 dias | 8x5 | Tickets S4 Baixo | Dúvida/ajuste sem impacto relevante | 1 dia | 10 dias | 8x5 | Tickets

Fiscalização do fornecedor: rotinas e evidências

• Reuniões de acompanhamento: revisar entregas, riscos, pendências, mudanças.
• Inspeção de entregáveis: verificar conformidade com especificação e critérios de aceite.
• Gestão de não conformidades: registrar, classificar, definir prazo e reteste.
• Gestão de desempenho: indicadores de prazo, qualidade (defeitos), retrabalho, SLA.
• Gestão de pagamentos por aceite: pagamento condicionado a evidências e aceite formal.

Modelos de artefatos (checklists e templates) para uso imediato

Checklist de kickoff com fornecedor

• Escopo e entregas revisados e entendidos por ambas as partes.
• Cronograma de marcos validado (incluindo homologação e implantação).
• Responsáveis nomeados: GP, fiscal, pontos focais, homologadores.
• Canais oficiais definidos (registro de demandas, chamados, evidências).
• Regras de mudança e aprovação acordadas.
• Riscos iniciais registrados e donos definidos.
• Critérios de aceite e plano de testes acordados.

Template textual (registro de mudanças)

REGISTRO DE MUDANÇA ID: [..] Data: [..] Solicitante: [..] Descrição da mudança: [..] Justificativa: [..] Impacto no escopo: [..] Impacto no prazo: [..] Impacto no custo: [..] Impacto em riscos: [..] Alternativas avaliadas: [..] Decisão: [Aprovada/Rejeitada] Aprovadores: [..] Plano de implementação: [..]

Template textual (ata de reunião de acompanhamento)

ATA DE REUNIÃO - ACOMPANHAMENTO Data/Hora: [..] Participantes: [..] 1. Status das entregas - Entrega X: [em dia/atraso] evidência: [..] - Entrega Y: [..] 2. Riscos e impedimentos - Risco R1: ação: [..] responsável: [..] prazo: [..] 3. Mudanças - Solicitação MC-01: [..] decisão: [..] 4. Pendências - P1: [..] responsável: [..] prazo: [..] 5. Próximos passos e data da próxima reunião

Checklist de aceite de entrega (por marco)

• Entregáveis previstos no marco foram entregues (lista e links/IDs).
• Critérios de aceite atendidos (marcar item a item).
• Evidências anexadas (prints, logs, relatórios, arquivos).
• Plano de testes executado e resultados registrados.
• Não conformidades registradas com severidade e prazo.
• Documentação mínima entregue (manual/roteiro/checklist).
• Termo de aceite parcial/final preparado e assinado.

Template textual (termo de aceite)

TERMO DE ACEITE (PARCIAL/FINAL) Projeto/Contrato: [..] Entrega/Marco: [..] Data: [..] Itens aceitos: [lista] Evidências: [links/IDs/anexos] Não conformidades pendentes (se houver): [ID, severidade, prazo] Declaração: A entrega atende aos critérios de aceite definidos, exceto pelos itens pendentes acima (quando aplicável). Responsável pelo aceite (Órgão): [nome/cargo] Fiscal técnico: [nome] Representante do fornecedor: [nome]