Prompts Gestão de Projetos

Redige a nota de enquadramento do projeto [nome do projeto] para a [empresa]. Objetivo do projeto: [objetivo]. Patrocinador (Sponsor): [responsável]. Equipa: [composição]. Orçamento: [orçamento]. Prazo previsto: [data]. Motivação do projeto: [contexto].

Estrutura: contexto e problema a resolver (3 linhas), objetivo formulado de forma mensurável, âmbito incluído, âmbito explicitamente EXCLUÍDO (tão detalhado quanto o incluído, para evitar desvios), entregáveis com critérios de aceitação, marcos (milestones) datados, funções e responsabilidades (quem decide, quem executa, quem é consultado, quem é informado), riscos identificados com plano de mitigação para cada um ([riscos já previstos]), pressupostos e dependências.

Formula cada secção para que qualquer eventual desacordo surja AGORA, na revisão, e não a meio do projeto. Termina com as 3 questões críticas a decidir em comité antes do lançamento.

Transforma as minhas notas brutas de reunião numa ata estruturada. Reunião: [assunto da reunião] de [data], participantes: [participantes]. Aqui estão as minhas notas: [notes brutes, mesmo que desordenadas].

Formato de saída: decisões tomadas (formuladas sem ambiguidade, indicando quem decidiu), ações (tabela: ação, responsável, prazo; se faltar algum destes três nas minhas notas, marca como "A DEFINIR" em vez de inventar), pontos discutidos sem decisão (máximo 2 linhas cada), pontos adiados com a data da próxima discussão.

Regras: máximo uma página, sem reformulações que alterem o sentido do que foi dito, evitar linguagem diplomática que dilua as decisões (expressões como "ficou acordado avançar no tema" são proibidas). Termina com a lista de pontos "A DEFINIR" para enviar aos participantes para validação.

Divide o seguinte projeto em lotes de trabalho e constrói o seu cronograma. Projeto: [descrição do projeto e entregável final]. Prazo: [data]. Equipa disponível: [pessoas e disponibilidade, ex: 2 pessoas a meio tempo]. Restrições conhecidas: [restrições: validação do cliente, dependência de fornecedor, período de férias].

Procede da seguinte forma: divide em lotes de trabalho onde cada um produz um entregável verificável (evita lotes de "coordenação"), decompõe cada lote em tarefas de 0,5 a 3 dias, identifica as dependências entre tarefas e o caminho crítico, coloca uma margem explícita nas tarefas incertas em vez de uma margem oculta em todo o lado.

Entrega: a lista estruturada lotes → tarefas com estimativas, o cronograma semanal com os marcos de validação, o caminho crítico em destaque e as 3 tarefas a iniciar imediatamente por condicionarem o resto. Sinaliza se o prazo [data] é inviável com a equipa descrita, com base em números, em vez de comprimir silenciosamente as estimativas.

Redige o flash report semanal do projeto [nome do projeto] destinado ao [destinatários, ex: comité de acompanhamento]. Dados da semana: progresso [o que foi feito vs previsto], dificuldades [problemas encontrados], riscos em evolução [riscos], orçamento consumido [consumido vs previsto], decisões esperadas [decisões bloqueantes pendentes e desde quando].

Formato rigoroso de uma página: estado do projeto (verde/amarelo/vermelho) com UMA frase que justifique a cor, 3 factos marcantes da semana, progresso vs plano (uma linha por lote ativo), riscos e pontos críticos (apenas o que mudou desde a semana passada), decisões esperadas com o nome do decisor e o impacto do atraso, prioridades da semana seguinte.

Regras: um projeto nunca volta a verde sem explicar o que resolveu o problema; um ponto amarelo duas semanas seguidas torna-se vermelho; as decisões pendentes devem citar a data do pedido inicial.

Prepara a animação de uma retrospetiva para o projeto [nome do projeto], que terminou agora [resultado: no prazo, com atraso de X, cancelado]. Participantes: [participantes e funções]. Duração: [duração, ex: 1h30]. Factos relevantes: [o que correu bem ou mal, eventuais tensões].

Entrega: o roteiro cronometrado (abertura que define a regra "procuramos causas, não culpados", recolha individual antes da discussão coletiva para evitar o efeito de conformidade, discussão dos pontos principais, decisões), as perguntas exatas a fazer para ir além das generalidades ("em que momento exato soubemos que o prazo ia derrapar? o que nos impediu de o dizer?"), e a técnica para abordar [tema sensível eventual] sem que se torne um julgamento.

Formato de saída das lições aprendidas: cada aprendizagem torna-se uma regra acionável para o próximo projeto ("de agora em diante nós..."), com um responsável pela sua implementação. Máximo 5 regras: acima disso, nada será aplicado.

Assume o papel de um gestor de projetos sénior. Ajuda-me a construir o estudo de viabilidade do projeto [nome do projeto] equacionado pela [empresa]. Problema ou oportunidade na origem: [contexto]. Benefícios esperados: [benefícios esperados]. Orçamento máximo admissível: [montante]. Alternativas conhecidas: [alternativas, incluindo não fazer nada].

Estrutura o dossier em 6 partes: problema a resolver e custo da inação, opções possíveis (incluindo o status quo) com vantagens e desvantagens, estimativa aproximada de custos e prazos por opção em intervalos alargados, benefícios esperados ligados a indicadores mensuráveis, riscos principais de cada opção, recomendação fundamentada.

Restrições: cada benefício deve estar associado a um indicador verificável, caso contrário, classifica-o como "aposta não mensurável". Formula 5 critérios de decisão Go/No-Go que o comité possa validar. Termina com a lista de informações em falta que fragilizam o estudo e quem as deve fornecer.

Redige um Project Charter de uma página para um pequeno projeto que não justifica uma nota de enquadramento completa. Projeto: [descrição em 2 frases]. Requerente: [requerente]. Pessoas envolvidas: [pessoas e tempo disponível]. Prazo pretendido: [data]. Orçamento eventual: [montante ou nenhum].

Formato imposto, máximo uma página: objetivo numa frase mensurável, entregável final e como reconhecemos que está concluído, o que está excluído do âmbito (mínimo 3 linhas, é a secção mais útil), quem decide em caso de arbitragem, marcos (máximo 3), o risco principal e a sua mitigação.

Restrições: sem jargão técnico de gestão de projetos, frases que um leigo compreenda à primeira leitura. Se as minhas informações de entrada não permitirem preencher uma rubrica, escreve "A CLARIFICAR com [pessoa]" em vez de inventar. Termine com as 2 perguntas a fazer ao requerente antes de começar.

Estou a iniciar o projeto [nome do projeto] para a [empresa] e preciso de fazer o levantamento de requisitos antes de fechar o âmbito. Pessoas a entrevistar: [lista de perfis, ex: direção, utilizadores operacionais, suporte, IT]. O que o projeto deve produzir: [entregável previsto]. Tempo disponível por entrevista: [duração].

Prepara para cada perfil um guião de entrevista adaptado: 8 a 10 perguntas abertas, da mais geral à mais específica, distinguindo perguntas sobre o funcionamento atual (dificuldades, soluções improvisadas, volumes) de perguntas sobre a necessidade futura. Adiciona para cada perfil as 2 perguntas "armadilha" que fazem emergir necessidades não expressas, por exemplo: "o que faz quando a ferramenta atual não é suficiente?".

Restrições: banir perguntas que sugiram a resposta e aquelas de sim ou não. Fornece também a estrutura de síntese para consolidar as entrevistas: necessidades expressas, necessidades deduzidas, contradições entre perfis a arbitrar e citações marcantes.

Transforma estas necessidades brutas em User Stories acionáveis por uma equipa de execução. Projeto: [nome e descrição curta]. Utilizadores envolvidos: [perfis de utilizadores]. Necessidades expressas: [lista de necessidades, mesmo que vagas].

Para cada necessidade, produz: a User Story no formato "Enquanto [perfil], eu quero [ação] para que [benefício]", 3 a 5 critérios de aceitação formulados de forma binária (verificável por sim ou não, nada de "rápido" ou "intuitivo" sem métrica), e as perguntas a fazer ao requerente se a necessidade for demasiado vaga para ser dividida.

Restrições: uma story deve ser realizável em poucos dias, caso contrário propõe a sua divisão em stories menores. Sinaliza necessidades que não o são (soluções disfarçadas de necessidades) e reformula-as. Apresenta o resultado em tabela: story, critérios de aceitação, tamanho estimado (S/M/L), perguntas abertas. Termina com a lista de dependências entre stories.

Ajuda-me a priorizar o backlog do projeto [nome do projeto]. Itens pendentes: [lista de pedidos com uma frase de descrição cada]. Capacidade da equipa: [capacidade, ex: 15 dias-homem por mês]. Objetivo prioritário do trimestre: [objetivo]. Requerentes com maior pressão: [contexto político eventual].

Avalia cada item em dois eixos: valor (contributo para o objetivo do trimestre, número de utilizadores afetados, custo do problema não resolvido) e esforço estimado em tamanho relativo. Classifica em 4 categorias: fazer agora (alto valor, baixo esforço), planear (alto valor, alto esforço), preenchimento (baixo valor, baixo esforço), recusar ou adiar explicitamente (baixo valor, alto esforço).

Restrições: a pressão do requerente não é um critério de valor, mas lista à parte as recusas que exigirão uma mensagem de explicação. Produz a classificação em tabela com a justificação numa frase por linha, depois redige as 3 mensagens de recusa mais delicadas, curtas e factuais.

Constrói o roadmap dos próximos 2 trimestres para [produto ou projeto] da [empresa]. Objetivos do ano: [objetivos]. Iniciativas candidatas: [lista de iniciativas previstas]. Capacidade da equipa: [tamanho e disponibilidade]. Compromissos já assumidos: [compromissos com clientes ou internos não negociáveis].

Organiza o roadmap por trimestre, formulando cada linha como um resultado esperado, não como uma funcionalidade ("reduzir o tempo de resposta" em vez de "desenvolver módulo X"). Para cada trimestre: 2 ou 3 iniciativas no máximo, o resultado visado, o indicador de sucesso e as dependências.

Restrições: mantém 20% de capacidade não alocada para imprevistos e indica isso explicitamente. Lista o que está voluntariamente ausente e porquê, para evitar perguntas do tipo "e porque não o X?". Fornece duas versões: uma detalhada para a equipa e uma em 5 linhas para a direção. Sinaliza iniciativas cujo valor é demasiado vago para serem incluídas.

Ajuda-me a estimar o esforço do projeto [nome do projeto]. Conteúdo: [lista de lotes ou tarefas]. Equipa: [perfis e experiência]. Histórico disponível: [projetos comparáveis realizados e duração real, se conhecidos].

Para cada lote: uma estimativa em intervalo (otimista, provável, pessimista) em vez de um número único, os pressupostos que sustentam a estimativa (o que tem de ser verdade para que se cumpra) e o fator que levaria ao cenário pessimista.

Restrições: quando existir histórico de projetos comparáveis, confronta a estimativa com a duração real observada e explica o desvio. Adiciona sistematicamente esforços esquecidos: correções após testes, coordenação, aprendizagem, ausências previstas. Apresenta o total em 3 cenários com a variação percentual entre otimista e pessimista. Se a diferença duplicar, indica que informações reduziriam a incerteza antes de assumir um número.

Constrói o orçamento completo do projeto [nome do projeto] da [empresa]. Esforço interno previsto: [dias-homem por perfil e custo diário se conhecido]. Compras e serviços externos: [lista]. Duração: [duração]. Verba validada: [montante].

Produz primeiro o orçamento por rubrica: custos internos valorizados, serviços externos, licenças e ferramentas, custos fixos e uma provisão para imprevistos justificando a percentagem segundo a incerteza. Verifica a coerência com a verba validada e sinaliza qualquer excesso logo na fase de construção.

Constrói depois o sistema de seguimento mensal: tabela consumido vs orçamento por rubrica, esforço restante reestimado (não apenas o que falta gastar), projeção final e 2 níveis de alerta que ativem uma comunicação ao sponsor. Termina com os 3 desvios orçamentais mais comuns neste tipo de projeto e como detetá-los cedo.

Estabelece o registo de riscos do projeto [nome do projeto]. Contexto: [descrição do projeto, prazo, desafios]. Riscos já previstos: [riscos identificados]. Dependências externas: [fornecedores, outras equipas, validações pendentes].

Completa a minha lista com riscos típicos deste tipo de projeto, procurando em 4 famílias: humanos (saídas, sobrecarga, falta de competência), técnicos, organizacionais (decisões lentas, aumento de âmbito), externos. Para cada risco: descrição concreta do impacto, probabilidade (baixa/média/alta), impacto (baixo/médio/alto), criticidade resultante, sinal de alerta observável, ação de prevenção, plano de contingência se o risco ocorrer, responsável pela monitorização.

Restrições: formula cada risco como um evento ("o fornecedor entrega com um mês de atraso"), nunca como um tema vago ("prazos"). Ordena por criticidade decrescente e limita o registo aos 10 riscos que realmente merecem acompanhamento. Define o ritual de revisão: frequência e perguntas a fazer.

Mapeia os stakeholders (partes interessadas) do projeto [nome do projeto] na [empresa]. Intervenientes identificados: [lista de pessoas ou entidades]. O que o projeto muda para cada um: [impactos previstos]. Apoios e resistências já percebidos: [contexto].

Posiciona cada interveniente em dois eixos: influência no projeto (pode bloquear, acelerar ou neutro) e adesão atual (apoia, neutro, resistente). Para cada interveniente influente: o que tem a ganhar ou perder, a sua objeção provável formulada com as suas próprias palavras e a ação de envolvimento adequada (envolvimento nas decisões, informação regular, reunião individual antes de anúncios).

Restrições: não confundir o organigrama com a influência real, sinaliza atores sem cargo mas com opinião de peso. Produz o plano de envolvimento em tabela: ator, posição atual, posição necessária para o sucesso, ações, responsável, prazo. Termina com os 2 atores a contactar prioritariamente esta semana e porquê.

Cria o plano de comunicação do projeto [nome do projeto]. Públicos envolvidos: [públicos, ex: sponsor, equipa, utilizadores afetados, outros departamentos]. Duração do projeto: [duração]. Momentos chave conhecidos: [marcos, lançamentos, anúncios]. Canais disponíveis: [canais: reunião, email, intranet, Teams/Slack].

Para cada público, define: o que precisa de saber (e apenas isso), a frequência, o canal, o formato (2 linhas, uma página, reunião) e quem produz a mensagem. Distingue a comunicação recorrente (progresso) da comunicação de eventos (lançamento, incidente, conclusão).

Restrições: cada comunicação deve responder à pergunta do destinatário "o que é que isto muda para mim?", caso contrário, elimina-a. Prepara a mensagem de lançamento e a mensagem de entrada em produção. Apresenta o plano em tabela sintética, depois lista os 3 erros de comunicação mais comuns neste tipo de projeto e como este plano os evita.

Constrói a matriz RACI do projeto [nome do projeto]. Atividades principais: [lista de grandes atividades ou entregáveis]. Intervenientes: [pessoas ou funções envolvidas]. Tensões ou dúvidas já observadas: [contexto, ex: duas pessoas acham que decidem o mesmo tema].

Para cada atividade, atribui as funções: R (Responsible - executa), A (Accountable - decide e presta contas, apenas um por linha), C (Consulted - consultado antes), I (Informed - informado depois). Explica numa linha cada atribuição menos óbvia.

Restrições de qualidade: nunca dois A numa linha, nenhuma linha sem R, sinalizar atores C em quase todas as linhas (gargalo de consulta) e atores sem qualquer função (a retirar ou reposicionar). Apresenta a matriz em tabela, lista as 3 linhas com maior potencial de conflito com recomendações para as proteger e as questões a decidir em equipa antes de divulgar a matriz.

Prepara a reunião de lançamento do projeto [nome do projeto]. Participantes: [participantes e funções]. Duração: [duração, ex: 1h]. Estado do enquadramento: [nota de enquadramento validada ou em curso]. Pontos sensíveis: [tensões, ceticismo, histórico de projetos falhados no tema].

Entrega: o roteiro cronometrado (porquê este projeto agora, resultado final concreto, o que está fora do âmbito, quem faz o quê, marcos, regras de funcionamento da equipa, perguntas), as 3 mensagens que cada participante deve reter ao sair e a forma de abordar [ponto sensível] sem prejudicar a reunião nem o evitar.

Restrições: o kick-off não é uma reunião informativa unidirecional, prevê 2 momentos de participação (identificação de riscos rápida, ronda de restrições individuais). Fornece o convite com a agenda e o que cada um deve preparar, e a lista do que deve estar validado ANTES do kick-off para não lançar um projeto vago.

Prepara o próximo Comité de Pilotagem (COPIL) do projeto [nome do projeto]. Participantes: [membros do COPIL]. Duração: [duração]. Situação do projeto: [progresso, dificuldades, orçamento]. Decisões necessárias: [decisões esperadas com opções]. Temas que podem monopolizar a discussão: [temas sensíveis].

Constrói a agenda focada nas decisões, não no progresso: cada decisão esperada torna-se um ponto com tempo alocado, as opções preparadas (2 ou 3, com vantagens, desvantagens e recomendação) e o que acontece se a decisão for adiada. O progresso trata-se em 10 minutos com base num documento enviado previamente.

Fornece: a agenda cronometrada, a formulação exata de cada pedido de decisão, a técnica para cortar cordialmente digressões sobre [tema sensível] e o modelo de ata de decisões para enviar em 24h. Termina com a lista do que devo enviar aos participantes 48h antes.

Estrutura a apresentação do Comité de Pilotagem do projeto [nome do projeto]. Dados do mês: progresso [realizado vs previsto], orçamento [consumido vs orçamento], riscos [evolução], decisões esperadas [lista], factos marcantes [eventos do mês].

Produz a estrutura slide a slide, máximo 10 slides: síntese num slide (estado, mensagem principal, decisões esperadas), progresso por lote com desvio vs plano, trajetória orçamental, riscos com alteração de pontuação, foco no ponto crítico do mês com opções e recomendação, decisões solicitadas (um slide por decisão), próximos passos.

Para cada slide: o título formulado como uma mensagem ("Lote 2 recupera atraso", não "Progresso Lote 2"), conteúdo em 5 pontos máximo e o que dizer oralmente que não está no slide. Restrições: sem slides de contexto que o COPIL já conhece, números arredondados e comparados (vs plano, vs mês passado), detalhe em anexo. Termina com o teste: se o COPIL só ler o slide 1, tem o essencial?

Implementa o circuito de gestão de pedidos de alteração (Change Requests) do projeto [nome do projeto]. Contexto: [origem dos pedidos, ex: o cliente adiciona pedidos constantemente, a direção muda de ideias]. Instâncias existentes: [reuniões e comités]. Margem disponível: [margem de prazo e orçamento restante].

Define: o formulário mínimo de pedido (descrição, requerente, justificação, urgência real), as 4 perguntas de análise sistemática (impacto prazo, impacto orçamento, impacto noutros lotes, o que acontece se não fizermos), quem decide conforme o impacto (propõe limites de valor) e como registar as decisões num log de alterações.

Redige também as 3 respostas tipo: pedido aceite com impacto anunciado, pedido adiado para versão posterior, pedido recusado com justificação. Restrições: o circuito deve caber em meia página para ser aplicado, e nenhum pedido deve ser aceite verbalmente sem passar pelo registo. Termina com a forma de apresentar este circuito ao requerente mais insistente sem criar conflito.

Ajuda-me a preparar a renegociação de um prazo inviável. Projeto: [nome do projeto]. Prazo solicitado: [data]. A minha convicção: é necessário [duração realista] porque [razões: esforço estimado, dependências, equipa disponível]. Sponsor: [perfil do sponsor e o que valoriza]. Motivo da data: [porque foi definida esta data, se souber].

Constrói: a demonstração factual do desvio (esforço vs capacidade, em números simples), depois 3 opções honestas: cumprir a data reduzindo o âmbito (dizer o que fica de fora), manter o âmbito adiando a data, reforçar meios com o custo e limites dessa opção (uma pessoa nova não produz logo na primeira semana).

Restrições: nunca dizer "é impossível" sem alternativa, nunca aceitar em reunião um compromisso não quantificado. Prepara a resposta às 3 objeções prováveis, incluindo "desenrasquem-se" e "logo se vê". Formato: uma página de argumentário mais tabela de 3 opções com consequências comparadas.

Constrói o plano de recuperação do projeto [nome do projeto], com atraso de [duração do atraso] para um prazo a [data]. Causas identificadas: [causas do atraso]. Trabalho restante: [lotes ou tarefas com estimativas]. Equipa: [composição e disponibilidade]. Margens de manobra: [orçamento adicional, âmbito negociável ou não].

Começa por validar o diagnóstico: o atraso vem de estimativas baixas, aumento de âmbito, recursos desviados ou bloqueios externos? A resposta muda o plano. Depois, constrói a recuperação com base em alavancas reais: redução de âmbito, reordenamento para paralelizar, eliminação de tarefas inúteis, reforço focado apenas no caminho crítico.

Restrições: proibido recuperar "comprimindo" estimativas sem justificação, proibido eliminar tempos de testes. Entrega: o novo cronograma com data fiável, o que foi sacrificado, as 2 condições para o plano resultar e a mensagem ao sponsor que assume o atraso sem o ocultar.

Prepara a escalada de um bloqueio no projeto [nome do projeto]. Bloqueio: [descrição, ex: decisão pendente, recurso não alocado, conflito entre departamentos]. Desde: [data]. O que já tentei: [diligências feitas]. Destinatário da escalada: [pessoa e nível]. Pessoas envolvidas no bloqueio: [intervenientes e sensibilidades].

Redige a mensagem de escalada: resumo do bloqueio em 3 linhas factuais e datadas, consequências concretas do status quo quantificadas (dias perdidos, custo, marcos ameaçados), as 2 ou 3 opções de desbloqueio com a minha recomendação, a decisão pedida e para quando.

Restrições: sem ataques pessoais, os factos e datas falam por si; o destinatário deve poder decidir lendo apenas esta mensagem, sem reunião. Prepara a versão curta oral de 60 segundos e a mensagem de informação às pessoas envolvidas para que não sejam apanhadas de surpresa.

Organiza o seguimento das ações do projeto [nome do projeto] entre reuniões. Situação atual: [problema, ex: as ações decididas em reunião ficam a meio, os lembretes parecem perseguição]. Ritmo das reuniões: [frequência]. Ferramentas: [folha de cálculo, software de tarefas, email].

Propõe um sistema completo: formato do registo de ações (ação com verbo e entregável, responsável único, prazo, estado), ritual de atualização (quem, quando, quanto tempo), e mecânica de lembretes graduais: aviso automático a D-2, mensagem individual factual no prazo, menção em reunião apenas ao segundo incumprimento.

Redige os modelos de mensagens de lembrete nos 3 níveis, curtos e sem tom de censura. Restrições: uma ação sem prazo ou sem responsável único é recusada na origem; o registo não deve exceder o que a equipa consegue absorver. Termina com a forma de apresentar o sistema à equipa para ser visto como uma ajuda.

Concebe o dashboard do projeto [nome do projeto]. Natureza do projeto: [tipo e entregável]. Duração: [duração]. Pontos sensíveis a vigiar: [desafios, ex: prazo apertado, orçamento limitado, qualidade crítica]. Dados disponíveis: [fontes: software de tickets, folhas de horas, orçamento].

Seleciona 6 a 8 indicadores no máximo, em 3 blocos: progresso (realizado vs previsto em entregáveis concluídos, não em percentagem declarativa), saúde (ações em atraso, decisões pendentes e antiguidade, riscos a subir), recursos (consumido vs orçamento, carga da equipa).

Para cada indicador: definição, fonte, frequência e limite de alerta. Restrições: banir indicadores declarativos inviáveis ("80% feito") a favor do binário concluído/não concluído; cada indicador deve ativar uma ação quando passa a vermelho. Descreve a leitura semanal em 15 minutos: ordem de leitura, perguntas a fazer e quando escalar além da equipa.

Redige o relatório mensal do projeto [nome do projeto] para [destinatários, ex: conselho de administração]. Dados do mês: realizações [o que foi entregue], desvios [atrasos ou excessos], orçamento [consumido vs previsto], riscos [evolução], decisões tomadas [lista], alertas [pontos críticos].

Formato imposto, uma página: trajetória global em 2 frases (o projeto cumprirá data e orçamento, sim ou não, e o que mudou este mês), realizações do mês em 3 pontos ligados aos marcos, desvios com causa e tratamento (sem desvios órfãos), orçamento numa linha com projeção final, alertas para a direção com pedido explícito.

Restrições: a direção lê muitos relatórios, nada de autopromoção ou palha; cada alerta deve resultar num pedido preciso (arbitragem, meio, decisão). Desvios e más notícias primeiro, não enterrados no fim da página.

Ajuda-me a arbitrar recursos entre projetos concorrentes. Projetos em curso: [lista com prazos, desafios e progresso]. Recursos partilhados: [pessoas em vários projetos e alocação atual]. Conflito atual: [descrição do conflito]. Quem decide: [instância ou pessoa].

Constrói primeiro a fotografia real: quem trabalha em quê, em percentagem real e não teórica, e onde estão as pessoas com carga superior a 100%. Depois, propõe uma grelha de arbitragem com critérios explícitos: valor para o negócio, custo do atraso de cada projeto, irreversibilidade (janela de oportunidade), compromisso externo assumido.

Aplica a grelha ao conflito e produz 2 cenários de alocação com o que cada projeto ganha e perde, e a data de fim resultante. Restrições: proibido resolver o conflito sobrecarregando pessoas ou prometendo meios-tempos em 3 projetos; o cenário escolhido deve ser comunicável aos gestores de projeto "perdedores" com justificação sólida.

Prepara o planeamento do próximo sprint da equipa [equipa] no projeto [nome do projeto]. Duração: [duração]. Capacidade: [pessoas, ausências, tempo fora do sprint: suporte, reuniões]. Backlog priorizado: [itens candidatos com estimativa]. Restos do sprint anterior: [itens não concluídos].

Estrutura a sessão: cálculo da capacidade real (tempo disponível menos recorrentes e imprevistos), formulação do objetivo do sprint numa frase (resultado, não lista de tarefas), seleção de itens até ao limite da capacidade começando pelos restos do anterior, verificação coletiva de que cada item é compreendido e definido para começar.

Restrições: recusar itens sem critérios de aceitação; se o pedido exceder a capacidade, a resposta é escolher itens, nunca aceitar o excesso em silêncio. Entrega o roteiro da sessão, o objetivo do sprint e os 3 sinais durante o sprint de que o compromisso está em risco.

Prepara a animação da retrospetiva de sprint da equipa [equipa]. Duração: [ex: 45 min]. Ambiente atual: [contexto, ex: ritual cansado, tensão recente, equipa nova]. Temas do momento: [eventos do sprint]. Ações de retros anteriores: [estado real].

Entrega: roteiro cronometrado começando pelo balanço das ações anteriores (uma retro cujas ações nunca são feitas morre depressa), um formato de animação adaptado ao [ambiente atual], perguntas de aprofundamento e método de seleção: máximo 2 ações de melhoria, escolhidas pela equipa, com responsável e prazo no próximo sprint.

Restrições: nada de ações tipo "comunicar melhor", cada ação descreve uma mudança observável; temas fora do controlo da equipa (hierarquia, organização) são anotados para escalada, não ruminados. Propõe 2 formatos alternativos para as próximas sessões.

Enquadra o ponto diário (Daily) da equipa [equipa] no projeto [nome do projeto]. Situação atual: [problema, ex: dura 30 minutos, é um relatório ao chefe, pessoas desligam]. Tamanho da equipa: [número]. Modo de trabalho: [presencial, remoto, híbrido].

Propõe o formato ideal: duração máxima, hora fixa e foco na coordenação: o que terminei ontem, o que bloqueia ou pode bloquear, o que preciso dos outros. O que não é coordenação (debates técnicos, resolução de problemas) é anotado para tratar depois apenas com os interessados.

Fornece: regras de animação para evitar o relatório ao chefe (equipa fala entre si, rotação de facilitador), frase para cortar digressões, adaptações para [modo de trabalho] e 3 sinais de que o daily é inútil com a correção. Termina com a mensagem de anúncio do novo formato à equipa.

Ajuda a equipa [equipa] a definir a sua Definition of Done (DoD) para o projeto [nome do projeto]. Tipo de entregáveis: [natureza, ex: software, manuais, estudos]. Problemas observados: [sintomas, ex: itens dados como feitos que reabrem, qualidade desigual, testes que descobrem falhas básicas].

Constrói a DoD em 3 níveis: o que torna um item "concluído" (critérios verificáveis: revisto por pares, testado, documentado, validado por quem), o que é explicitamente excluído para ser realista, e as exceções admitidas com regra para as registar.

Restrições: máximo 8 critérios, todos de sim ou não, nenhum que a equipa não possa cumprir com os meios atuais. Entrega também: método para adoção em workshop, regra de aplicação a trabalhos em curso e ritual de revisão após algumas semanas.

Organiza os testes de aceitação (UAT) do projeto [nome do projeto]. Entregável a testar: [descrição]. Testadores: [perfis e disponibilidade]. Duração: [duração]. Critérios de aceitação: [definidos antes ou nenhum].

Constrói: o plano de testes com casos organizados por jornada de utilizador real (não por ecrã), cada caso com dados de entrada, ação e resultado esperado; priorização (bloqueante, importante, cosmético); regra de classificação de anomalias com exemplos para evitar debates; circuito de correção e reteste.

Entrega a estrutura da Ata de Aceitação: o que foi testado, anomalias por nível, decisão (aceite, aceite com reservas datadas, recusado) e assinaturas. Restrições: testes sem dados reais não provam nada, indica como preparar a massa de dados; as reservas devem ter responsável e prazo, senão tornam-se definitivas.

Prepara o plano de entrada em produção de [entregável] para o projeto [nome do projeto]. Data: [date]. Utilizadores afetados: [quem e quantos]. Janela de intervenção: [ex: fim de semana, noite]. Intervenientes: [pessoas e funções]. Rollback possível: [sim/não/parcial e como].

Constrói: checklist pré-lançamento (pré-requisitos, validações, comunicação, backups, disponibilidade), roteiro hora a hora com responsável por etapa e critério de sucesso, pontos de decisão Go/No-Go (quem decide e critérios), plano de rollback (sinais de ativação e execução) e monitorização pós-lançamento.

Restrições: cada etapa tem critério de sucesso verificável; o rollback deve ser tão detalhado quanto o lançamento, pois é executado sob stress. Termina com a mensagem aos utilizadores antes e depois do lançamento.

Organiza a continuidade de negócio durante a migração de [sistema antigo] para [sistema novo] na [empresa]. Duração da transição: [duração]. Atividades críticas: [atividades]. Equipas: [equipas]. Período de risco: [ex: fecho contabilístico, pico sazonal].

Trata as questões críticas: qual o sistema que faz fé para cada dado, como evitar ou organizar a dupla introdução de dados, quem trata operações iniciadas no antigo e findas no novo, e como congelar dados no corte final.

Entrega: tabela de atividades críticas com modo de funcionamento na transição, regras de "quem faz fé", dispositivo de suporte reforçado e os 3 cenários de incidente mais prováveis com a conduta a seguir.

Prepara o encerramento do projeto [nome do projeto], aceite a [data]. Elementos: [fornecedores, orçamento, documentação, equipa]. Reservas pendentes: [reservas de testes].

Constrói a checklist: vertente contratual (pagamento a fornecedores, fecho de acessos), financeira (parar imputações, balanço real vs orçamento), documental (arquivo, o que deve ser consultável daqui a 2 anos), humana (reafetação da equipa, agradecimentos), transferência (quem assume a exploração e suporte).

Restrições: distingue o que bloqueia o fecho do que pode ser feito depois; fixa uma data de fecho firme. Entrega a estrutura do balanço final em uma página: números chave, sucessos, desvios e localização das lições aprendidas.

Organiza a transição do projeto [nome do projeto] entre [gestor cessante] e [gestor entrante]. Contexto: [razão e pré-aviso]. Estado: [progresso, pontos quentes, marcos]. Tempo de transição: [duração].

Constrói o dossier focando no que não está escrito: histórico de decisões e porquês, compromissos verbais, sensibilidades políticas, riscos vigiados mas não formalizados, estado real de cada lote além do reporting oficial.

Organiza a transição: reuniões de apresentação (sponsor, cliente, equipa), ordem de temas por urgência e mensagem de anúncio. Restrições: a transição verifica-se com perguntas que o entrante deve saber responder sozinho no fim; o que não foi transmitido é listado com contacto de recurso.

Prepara a integração de [novo elemento, perfil] no projeto [nome do projeto] a [data]. Estado: [progresso]. Função: [missões]. Tempo da equipa para apoio: [limitação].

Constrói o percurso das 2 primeiras semanas: kit de leitura essencial (enquadramento, último flash report, riscos, glossário), 4 reuniões com pessoas chave, uma primeira tarefa útil e delimitada logo na primeira semana, e um mentor com ponto diário de 10 minutos.

Restrições: evitar 15 reuniões passivas, aprende-se a produzir; explicitar o que ninguém diz: tensões, temas proibidos, circuitos reais de decisão. Entrega o planeamento, lista de leitura e perguntas para validar a integração ao 15º dia.

Ajuda-me a gerir um conflito na equipa do projeto [nome do projeto]. Contexto: [factos entre as duas pessoas, sem julgamento]. Impacto: [retenção de info, reuniões tensas, atrasos]. O meu papel: [gestor de projeto, com ou sem hierarquia]. Histórico: [duração, tentativas feitas].

Propõe 3 tempos: entrevistas individuais (perguntas para entender versões sem tomar partido, evitar ser juiz), reunião comum (regras de abertura, focar em factos, acordar 2 ou 3 regras de funcionamento), seguimento (verificar se o acordo cumpre sem vigiar ostensivamente).

Restrições: manter papel de gestor de projeto, temas de RH/hierarquia são encaminhados; ninguém deve ser culpabilizado perante a equipa. Indica sinais que exigem escalada imediata.

Ajuda-me a confrontar um fornecedor com falhas no projeto [nome do projeto]. Fornecedor: [empresa e serviço]. Falhas: [factos datados: atrasos, má qualidade, troca de interlocutor]. Contrato: [entregáveis, prazos, penalidades]. Dependência: [quão substituível é].

Constrói a gradação: primeiro o ponto de situação (dossier factual de desvios, reunião exigindo plano de recuperação datado), depois seguimento apertado (marcos curtos, critérios de saída de crise, atas escritas), finalmente preparação de alternativa se falhar.

Restrições: formalizar tudo por escrito após conversas; ser factual e contratual, sem ameaças vazias. Entrega: dossier de desvios, email de convocatória, roteiro da reunião e critérios para rescisão.

Redige o Caderno de Encargos para consulta ao mercado sobre [objeto, ex: novo site, software, serviço] para a [empresa]. Necessidade: [problema a resolver]. Contexto: [existente, restrições]. Orçamento indicativo: [intervalo ou omitido]. Calendário: [prazos].

Estrutura: apresentação da empresa, problema e objetivos em resultados esperados (descrever o quê, não o como), âmbito e exclusões, restrições não negociáveis (técnicas, RGPD, prazos), entregáveis, critérios de seleção e ponderação, processo de consulta e formato de resposta.

Restrições: cada requisito deve ser testável; distinguir obrigatórios de desejáveis. Termina com 5 perguntas para a fase de apresentação que revelem se o fornecedor percebeu o desafio.

Constrói a grelha de comparação de propostas para [objeto]. Propostas: [número e resumo: preço, prazo, abordagem]. Prioridades: [ex: cumprir prazos, suporte, custo total]. Sinais percebidos: [impressões, ex: preço muito baixo, resposta genérica].

Constrói a grelha: critérios por famílias (compreensão, abordagem, equipa real, preço total incluindo ocultos, referências, contrato), ponderação e escala de nota descritiva para limitar subjetividade.

Aplica a grelha e sinaliza: desvios de preço (preço baixo esconde falta de âmbito?), meios prometidos vs reais, custos recorrentes. Entrega quadro comparativo, perguntas de clarificação e recomendação em 5 linhas.

Constrói o plano de gestão da mudança para [projeto] na [empresa]. Populações afetadas: [grupos e o que muda]. Receios: [resistências]. Calendário: [datas]. Meios: [tempo, orçamento, influenciadores].

Para cada grupo: o que muda no dia a dia (ganhos E perdas), nível de apoio necessário (info, formação, apoio próximo) e mensagem chave do ponto de vista deles.

Estrutura: Antes (anúncio, rede de embaixadores internos, formação), Durante (apoio reforçado, correção rápida de problemas), Depois (medir uso real, tratar resistências). Restrições: nada de "comunicar mais" sem dizer o quê; cada ação com dono e data. Entrega plano em tabela.

Concebe o plano de formação para o lançamento de [ferramenta/processo] na [empresa]. Utilizadores: [perfis, número, literacia digital, local]. O que devem saber fazer: [tarefas]. Restrições: [disponibilidade, orçamento, prazo].

Constrói por perfil: 5 a 10 ações críticas (não a lista exaustiva de botões), formato (sessão curta, tutorial, apoio no posto), duração e suporte (folhas de ajuda rápidas). Planeia perto do lançamento. Mede sucesso pelo uso real e volume de tickets no suporte, não pela presença. Entrega plano em tabela e lista de suportes priorizada.

Incidente grave no projeto [nome do projeto]: [natureza, ex: falha no lançamento, perda de dados, paragem de serviço]. Impactos: [quem e como]. Estado: [o que sabemos e ignoramos]. Públicos: [direção, equipas, clientes].

Redige a sequência: primeiro aviso rápido (o que sabemos, o que fazemos, quando damos novidades), pontos de situação no ritmo prometido e mensagem de resolução com medidas preventivas. Adapta por público: direção quer impacto/decisão, utilizadores querem saber como trabalhar, clientes querem saber se estão protegidos. Sem especular causas nem culpar ninguém.

Ajuda a equipa [equipa] da [empresa] a redigir OKRs para o [trimestre]. Prioridades da empresa: [prioridades]. Trabalho recorrente: [atividades]. Iniciativas: [ideias]. Equipa: [tamanho].

Produz 2 ou 3 Objetivos: inspiradores e concretos, ligados à empresa. Para cada um, 2 a 4 Key Results: mensuráveis (valor inicial/alvo), focados em resultados e não tarefas ("reduzir erro de X para Y", não "fazer relatório Z"). O dia a dia não é OKR. Entrega OKRs, questões para workshop e ritual de seguimento.

Prepara a revisão de OKRs da equipa [equipa]. OKRs passados: [resultados]. Contexto: [imprevistos]. Participantes: [quem]. Duração: [tempo].

Estrutura: pontuação honesta (não medido = não atingido), análise de desvios (execução vs ambição vs externo), decisões para o futuro. Sem justificações longas, focar nos números. Entrega roteiro, grelha de nota, perguntas de análise e síntese pós-revisão.

Prepara o post-mortem do incidente [descrição] de [data] no projeto [nome]. Cronologia: [eventos]. Pessoas: [quem]. Clima: [contexto].

Estrutura: cronologia factual coletiva, análise de causas além do erro individual (por que o sistema permitiu o erro?), o que funcionou e ações preventivas. Regra: procuramos falhas no sistema, não culpados. Máximo 5 ações com dono. Entrega estrutura do documento e roteiro da reunião.

Ajuda a transformar lições de [equipa/empresa] em standards. Material: [fontes]. Problema: [erros repetidos].

Agrupa por tema, identifica recorrências, transforma em regras acionáveis ("no início de cada projeto, fazemos X") e define onde vivem (checklists, templates). Máximo 10 regras com dono. Entrega regras, suporte de integração e mensagem à equipa.

Prepara o projeto [nome] para auditoria de [auditor] a [data]. Âmbito: [o quê]. Estado real: [forças/fraquezas]. Enjeu: [o que está em jogo].

Organiza: dossier de referência (enquadramento, decisões, riscos, atas, orçamento), lista de faltas a suprir, perguntas prováveis e posição honesta sobre pontos fracos (reconhecer e apresentar plano). Sem maquilhar documentos. Entrega checklist, perguntas/respostas e plano de preparação.