Fundamentos de gestão de projetos cobrados em concursos
Em concursos do Judiciário, gestão de projetos costuma ser cobrada como um conjunto de áreas de conhecimento e decisões práticas para entregar um produto/serviço (por exemplo, um módulo de sistema processual) dentro de restrições e com controle. Os temas mais recorrentes são: escopo, prazo, custo, qualidade, riscos, partes interessadas (stakeholders) e comunicação.
Escopo: o que será entregue (e o que não será)
Escopo define entregas, requisitos e limites do trabalho. Em projetos de sistemas, escopo se materializa em funcionalidades, integrações, relatórios, perfis de acesso, regras de negócio e requisitos não funcionais (desempenho, disponibilidade, auditoria).
- Escopo do produto: características do sistema (ex.: “peticionamento eletrônico com anexação de PDFs e validação de assinatura”).
- Escopo do projeto: trabalho necessário para entregar o produto (ex.: análise, desenvolvimento, testes, homologação, migração, treinamento).
- Controle de mudanças: qualquer alteração relevante deve ser avaliada quanto a impacto em prazo/custo/qualidade e aprovada por instância definida (comitê, patrocinador, product owner, conforme o modelo).
Exemplo prático (sistema judicial): no projeto de “Intimações por WhatsApp institucional”, o escopo pode incluir: cadastro de números autorizados, registro de consentimento, trilha de auditoria, integração com gateway oficial e relatórios de entrega. Fora do escopo: atendimento ao usuário final via chatbot (se não previsto).
Prazo: planejamento e controle do cronograma
Prazo é gerenciado por meio de decomposição do trabalho, estimativas e sequenciamento. Em concursos, é comum aparecerem conceitos como atividades, marcos, caminho crítico e folgas.
- Decomposição: quebrar entregas em pacotes menores (ex.: “integração com serviço X”, “tela de consulta”, “testes de carga”).
- Sequenciamento: dependências (ex.: não testar integração antes de ter ambiente e credenciais).
- Marcos: pontos de controle sem duração (ex.: “homologação assinada”).
Armadilha de prova: confundir “atraso em uma atividade” com “atraso no projeto”. Se a atividade tem folga, o projeto pode não atrasar.
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
Custo: orçamento e controle
Custo envolve estimar e controlar despesas (pessoas, licenças, infraestrutura, consultoria, nuvem, treinamento). Em TI no Judiciário, custos podem estar vinculados a contratos, termos de referência e consumo de serviços.
- Estimativa: baseada em histórico, métricas (pontos de função, story points convertidos em capacidade), ou composição de itens (licenças, horas, equipamentos).
- Linha de base de custos: referência aprovada para comparar realizado x planejado.
- Controle: variações exigem análise e ação (replanejar, reduzir escopo, negociar prazo).
Qualidade: conformidade e adequação ao uso
Qualidade em projetos de sistemas envolve tanto processo (como se desenvolve) quanto produto (o que é entregue). Em contexto judicial, requisitos de qualidade frequentemente incluem rastreabilidade, auditoria, segurança, desempenho e disponibilidade.
- Garantia da qualidade (QA): práticas para prevenir defeitos (padrões, revisões, critérios de pronto).
- Controle da qualidade (QC): inspeções e testes para detectar defeitos (testes funcionais, regressão, carga).
- Critérios de aceitação: condições objetivas para aprovar uma entrega (ex.: “registrar log com usuário, data/hora, IP e operação”).
Riscos: identificar, analisar e responder
Risco é um evento incerto que, se ocorrer, afeta objetivos do projeto. Pode ser negativo (ameaça) ou positivo (oportunidade). Provas cobram o ciclo: identificar, analisar (probabilidade/impacto), planejar respostas e monitorar.
- Respostas a ameaças: evitar, mitigar, transferir, aceitar.
- Respostas a oportunidades: explorar, melhorar, compartilhar, aceitar.
Exemplos (sistema judicial):
- Risco: indisponibilidade do serviço externo de assinatura digital na semana de homologação. Resposta: mitigar com janela de testes antecipada e plano de contingência.
- Risco: mudança normativa que altera prazos processuais. Resposta: aceitar com reserva de contingência e mecanismo configurável de regras.
Partes interessadas (stakeholders): influência e expectativas
Stakeholders são pessoas/grupos que afetam ou são afetados pelo projeto. Em sistemas judiciais, exemplos: magistrados, servidores, OAB, Ministério Público, TI, corregedoria, área de segurança, fornecedores, usuários externos.
- Mapeamento: identificar interesse, influência/poder e impacto.
- Engajamento: estratégias por perfil (informar, consultar, envolver, gerir de perto).
- Conflitos comuns: prioridade entre celeridade (prazo) e robustez (qualidade/segurança), ou entre padronização institucional e necessidades locais.
Comunicação: fluxo certo, no momento certo
Comunicação é uma das maiores causas de falha em projetos. Em concursos, costuma aparecer como plano de comunicação, canais, periodicidade e responsabilidades.
- Plano de comunicação: o que comunicar, para quem, quando, como e por quem.
- Relatórios: status (prazo/custo/escopo), riscos, impedimentos, decisões pendentes.
- Gestão de expectativas: alinhar o que será entregue e quando, evitando “surpresas” na homologação.
Modelos preditivos x ágeis: contraste objetivo
Modelo preditivo (tradicional)
No modelo preditivo, busca-se planejar o máximo possível no início, com fases mais definidas e controle forte de mudanças. É comum quando requisitos são estáveis, há necessidade de documentação formal e aprovações sequenciais.
- Forças: previsibilidade, documentação robusta, facilidade de auditoria e contratação por escopo fechado.
- Riscos: baixa flexibilidade para mudanças, feedback tardio do usuário, maior chance de entregar algo “correto no papel” mas inadequado na prática.
Exemplo: implantação de um módulo obrigatório por norma com requisitos bem definidos e prazo legal fixo pode se beneficiar de planejamento preditivo, desde que haja validações intermediárias.
Modelo ágil
No modelo ágil, o trabalho é organizado em ciclos curtos com entregas incrementais, priorizando valor e feedback frequente. Mudanças são esperadas e gerenciadas por priorização contínua.
- Forças: adaptação rápida, validação contínua com usuários, redução de risco de “entrega tardia e inadequada”.
- Riscos: se não houver disciplina, pode haver perda de rastreabilidade, escopo “elástico” e dificuldade de previsão; exige participação ativa do negócio.
Observação de prova: ágil não significa ausência de planejamento ou documentação; significa planejamento iterativo e documentação suficiente para o propósito (incluindo auditoria e conformidade quando necessário).
Scrum: conceitos essenciais cobrados em concursos
Scrum é um framework ágil para desenvolvimento de produtos complexos. Em provas, o foco costuma ser: papéis (accountabilities), eventos e artefatos, além de responsabilidades e objetivos.
Papéis (accountabilities) no Scrum
- Product Owner (PO): maximiza o valor do produto; gerencia e ordena o Product Backlog; define prioridades com base em valor e necessidade; esclarece itens para o time.
- Scrum Master (SM): garante que Scrum seja entendido e aplicado; remove impedimentos; facilita eventos; atua como líder servidor; protege o time de interferências indevidas.
- Developers (Time de Desenvolvimento): profissionais que constroem o incremento; planejam o Sprint Backlog; asseguram qualidade; entregam incremento “pronto” conforme Definition of Done.
Armadilhas comuns:
- PO não é “chefe do time” nem gerente de projeto tradicional; ele prioriza valor e backlog.
- Scrum Master não é “secretário de reunião”; ele atua na melhoria do fluxo e remoção de impedimentos.
- Developers não são apenas programadores; incluem quem for necessário para entregar (testes, análise, UX, etc.).
Eventos do Scrum
- Sprint: ciclo fixo (time-box) em que se cria um incremento de valor.
- Sprint Planning: planejamento do Sprint; define objetivo (Sprint Goal) e seleciona itens para o Sprint Backlog.
- Daily Scrum: inspeção diária do progresso em direção ao Sprint Goal e adaptação do plano.
- Sprint Review: inspeção do incremento com stakeholders e adaptação do Product Backlog.
- Sprint Retrospective: melhoria do processo e acordos de ação para o próximo Sprint.
Artefatos do Scrum
- Product Backlog: lista ordenada do que é necessário no produto (funcionalidades, melhorias, correções).
- Sprint Backlog: itens selecionados para o Sprint + plano para entregá-los.
- Incremento: soma de todos os itens concluídos no Sprint e anteriores, em estado utilizável.
Compromissos associados (cobrança frequente):
- Product Backlog ↔ Product Goal
- Sprint Backlog ↔ Sprint Goal
- Incremento ↔ Definition of Done
Passo a passo prático: aplicando fundamentos em um projeto de sistema judicial
A seguir, um roteiro prático (independente de ser preditivo ou ágil) para estruturar um projeto de desenvolvimento de um módulo, por exemplo: “Painel de Produtividade de Unidades Judiciais”.
1) Definir escopo inicial e limites
- Listar entregas: painéis, filtros, perfis de acesso, exportação, auditoria.
- Definir fora do escopo: BI corporativo completo, integração com sistemas não priorizados.
- Registrar critérios de aceitação: tempos máximos de resposta, trilha de auditoria, consistência de indicadores.
2) Identificar stakeholders e responsabilidades
- Negócio: corregedoria/gestão estratégica (indicadores), secretarias (rotinas), magistrados (uso).
- TI: desenvolvimento, infraestrutura, segurança, dados.
- Externo: eventualmente CNJ (padrões e relatórios).
3) Planejar comunicação
- Reunião quinzenal com área demandante para validação de entregas.
- Status semanal para patrocinador com riscos e decisões pendentes.
- Canal único para dúvidas e registro de decisões (evitar decisões “informais” sem rastreio).
4) Planejar prazo e custo em nível adequado
- Quebrar em entregas menores (módulos/relatórios) e marcos (homologação, produção).
- Estimar esforço e dependências (dados, integrações, ambientes).
- Reservar contingência para riscos (ex.: indisponibilidade de base, mudança de regra).
5) Planejar qualidade e riscos
- Definir Definition of Done (ou critérios equivalentes): testes, revisão, logs, documentação mínima, segurança.
- Montar lista de riscos com probabilidade/impacto e respostas.
- Prever validação com dados reais (anonimizados quando necessário) para evitar indicadores incorretos.
6) Executar e controlar (preditivo ou ágil)
- No preditivo: controlar mudanças via solicitação formal e replanejamento quando necessário.
- No ágil: reordenar backlog com base em feedback e valor, mantendo Sprint Goal protegido.
- Em ambos: monitorar riscos, comunicar desvios e registrar decisões.
Exercícios (estilo concurso) com foco em Scrum e fundamentos
Exercício 1: Identificação de artefatos
Em um projeto para criar o “Módulo de Custas e Guias”, a equipe mantém uma lista priorizada com: “emissão de guia”, “integração bancária”, “relatório de arrecadação”, “correção de bug X”. Essa lista é revisada continuamente conforme feedback da área financeira.
- Pergunta: qual artefato do Scrum descreve melhor essa lista?
- Resposta esperada: Product Backlog.
Exercício 2: Responsabilidades (papéis)
Durante o desenvolvimento do “Portal do Advogado”, surge a necessidade de priorizar entre “recuperação de senha com duplo fator” e “melhoria no filtro de pesquisa de processos”. Alguém precisa decidir a ordem com base em valor e risco.
- Pergunta: no Scrum, quem é responsável por ordenar o backlog e maximizar valor?
- Resposta esperada: Product Owner.
Exercício 3: Eventos do Scrum
Ao final de um ciclo, a equipe demonstra o incremento do “Agendamento de Audiências” para servidores e magistrados, coleta feedback e atualiza prioridades para as próximas entregas.
- Pergunta: qual evento do Scrum descreve essa atividade?
- Resposta esperada: Sprint Review.
Exercício 4: Escopo x prazo x custo (triângulo de restrições)
Um projeto de “Integração com Diário de Justiça” tem prazo legal fixo e orçamento limitado. Durante a execução, é solicitada uma funcionalidade extra de “painel analítico avançado”.
- Pergunta: qual é a decisão mais coerente com gestão de restrições?
- Resposta esperada: avaliar impacto e, mantendo prazo e custo fixos, negociar redução/adiamento de escopo (ou obter aprovação para alterar custo/prazo).
Exercício 5: Riscos e respostas
Risco identificado: “A API do sistema legado pode não suportar o volume de consultas do novo painel em horário de pico”.
- Pergunta: proponha uma resposta de mitigação.
- Resposta esperada: realizar teste de carga antecipado, implementar cache/filas, otimizar consultas, e planejar janela de escalabilidade ou réplica de leitura.
Exercício 6: Comunicação e stakeholders
Em um projeto de “Assinatura em Lote”, a equipe recebe orientações conflitantes: a área de segurança exige logs detalhados; usuários reclamam de lentidão e pedem remover logs.
- Pergunta: qual abordagem de comunicação e gestão de stakeholders é mais adequada?
- Resposta esperada: mapear influência/necessidades, promover alinhamento com decisão registrada, explicitar trade-offs (segurança x desempenho), definir critérios de aceitação e alternativas técnicas (log assíncrono, níveis de auditoria).
Exercício 7: Incremento e Definition of Done
No Sprint, foi implementada a funcionalidade “consulta pública de movimentações”. O código está pronto, mas não há testes, nem revisão, nem validação de requisitos de auditoria.
- Pergunta: isso pode ser considerado um Incremento pronto?
- Resposta esperada: não, se não atende à Definition of Done; incremento deve estar em estado utilizável e com qualidade acordada.
Exercício 8: Cenário híbrido (preditivo + ágil)
Um tribunal exige documentação formal mínima para auditoria e contratação, mas quer entregas incrementais para reduzir risco de retrabalho.
- Pergunta: como combinar sem contradição?
- Resposta esperada: manter artefatos formais essenciais (escopo macro, requisitos rastreáveis, aprovações) e executar desenvolvimento incremental com ciclos curtos, revisões frequentes e controle de mudanças por priorização e registro.
Mini-casos de aplicação em projetos de sistemas judiciais (para fixação)
Caso A: Migração de dados de um sistema legado
- Escopo: quais entidades migrar (processos, partes, movimentações), regras de transformação, validações.
- Prazo: marcos de “carga piloto”, “validação amostral”, “corte para produção”.
- Qualidade: reconciliação de totais, amostragem, trilha de auditoria da migração.
- Riscos: inconsistência de dados, janelas insuficientes, indisponibilidade do legado.
Caso B: Novo serviço de notificação eletrônica
- Stakeholders: unidades judiciais, TI, segurança, usuários externos.
- Comunicação: plano de divulgação, treinamento, canal de suporte, registro de incidentes.
- Ágil (Scrum): backlog com itens como “consentimento”, “comprovante”, “painel de falhas”, priorizados por valor e risco.
Caso C: Relatórios gerenciais para corregedoria
- Escopo: indicadores, fórmulas, fontes de dados, periodicidade.
- Qualidade: consistência com normativos, validação com amostras, performance.
- Risco: divergência de interpretação de indicador; mitigação com critérios de aceitação e validação contínua.
