
Última atualização: 21 de outubro de 2026
A galeria do Quire reúne mais de 20 modelos de gestão de projetos gratuitos, e todos estão listados abaixo com o que contêm e quando recorrer a eles. Escolha pela forma do trabalho: projeto finito, ciclo repetido ou pipeline por etapas. Copie um abrindo-o e escolhendo Duplicar no menu do projeto, o que leva menos de um minuto e traz consigo toda a hierarquia. Depois avalie-o pelo que apaga na primeira semana, porque um modelo é um ponto de partida e não um regulamento.
Há um tipo muito específico de cansaço que vem de construir a mesma estrutura de projeto pela quarta vez.
Já conhece a forma de cor. Arranque, requisitos, design, construção, revisão, lançamento. Sabe mais ou menos quem é responsável por quê e mais ou menos que partes escorregam sempre. E, ainda assim, ali está numa segunda-feira, a olhar para um projeto vazio, a escrever "Arranque" na primeira linha como se fosse uma ideia inédita.
É essa a lacuna que os modelos de gestão de projetos fecham. Não a estratégia, não o raciocínio. Os quarenta minutos a reescrever uma estrutura que já conhece, antes de o trabalho a sério começar.
Por isso, aqui está a biblioteca completa, um modelo de cada vez: todos os modelos da galeria do Quire em agosto de 2026, o que cada um contém de facto e o tipo de trabalho a que serve. Salte para o grupo que corresponde à sua semana.
Modelo de gestão de projetos: uma estrutura de projeto pré-construída que já contém as tarefas, as fases e os campos de que um tipo específico de trabalho precisa, para que o copie em vez de começar num ecrã vazio. Um bom modelo dá-lhe o esqueleto e deixa-lhe o resto.
A galeria do Quire reúne mais de 20 modelos de gestão de projetos gratuitos em cinco grupos: Start Here, Gestão de projetos, Métodos de produtividade, Negócio e operações, e Marketing e criatividade. Cada um chega com as suas tarefas e campos já montados, para que o copie em vez de construir de raiz. Um modelo justifica-se porque uma estrutura escrita apanha os passos que uma pessoa ocupada esquece sem falta.
As provas mais citadas para isso vêm de bem longe da gestão de projetos. Haynes e colegas introduziram uma lista de verificação de segurança cirúrgica com 19 itens em oito hospitais e, num artigo no New England Journal of Medicine em 2009, concluíram que as complicações em internamento caíram de 11,0% para 7,0% e a taxa de mortalidade de 1,5% para 0,8%.
Os mesmos cirurgiões, a mesma competência. Melhor memória para os passos aborrecidos.
Um modelo de projeto é o mesmo truque com muito menos em jogo. Não vai tornar ninguém mais inteligente. Evita que a equipa descubra, na terceira semana, que ninguém montou o passo de revisão.
O que separa um modelo que vale a pena copiar da tralha é ser mais pequeno do que se espera. Um bom modelo dá-lhe o esqueleto e deixa-lhe o resto. Um mau chega com 60 tarefas pré-escritas, metade das quais não se aplicam, e passa mais tempo a apagar do que teria passado a construir.
Para a visita guiada às funcionalidades em vez do catálogo, veja como os modelos do Quire facilitam o arranque de um projeto.
Se preferir ver três destes modelos a serem abertos e trabalhados em vez de ler sobre eles, a sessão abaixo faz exatamente isso, com links por capítulo para saltar para aquele que lhe interessa.
Nesta sessão16:16 Apresentação do modelo Marketing Campaign25:15 Apresentação do modelo Event Planning32:28 Apresentação do modelo Agile and Scrum43:51 Joias escondidas: Pastas inteligentes, Documentos, Gráficos, Tarefas recorrentes, Peekaboo, Rastreamento de tempo
Antes da lista, o atalho. Escolha pela forma do trabalho, não pelo tamanho da equipa, e três formas cobrem quase tudo.
Se o trabalho tem um início e um fim claros, quer um modelo de projeto. Se se repete num ciclo, quer um planeador. E se cada item espera por uma decisão antes de avançar, quer um pipeline.
| Forma do trabalho | Como a reconhece | Por onde começar | A vista que lhe serve |
|---|---|---|---|
| Projeto finito | Um início, um fim, uma data que importa a alguém | Project Starter, Work Breakdown Structure | Cronograma, para saber se as datas se mantêm |
| Ciclo repetido | A mesma forma todas as semanas ou meses, sem data de fim | Weekly Planner, Team Task Management | Calendário, porque a disponibilidade é a restrição |
| Pipeline por etapas | Cada item espera por uma decisão antes de avançar | Design Pipeline, Customer Relationship Pipeline | Board, para ver o que se move e o que está encalhado |
| Método, não um projeto | Quer manter um sistema em vez de entregar algo | GTD, Matriz de Eisenhower, OKRs | Lista, para a árvore completa num só lugar |
Quando dois parecem igualmente certos, fique com o mais pequeno: acrescentar estrutura mais tarde custa alguns minutos, enquanto apagar estrutura de algo dentro do qual as pessoas já trabalham custa uma conversa.
Vale a pena dizer uma coisa com clareza antes de começar a copiar. Um modelo não é uma metodologia. Escolher o modelo Agile Project não torna uma equipa ágil, e escolher OKRs não corrige objetivos em que ninguém acredita. O modelo dá-lhe o andaime; os hábitos continuam a ser seus para construir.
Novo no Quire? Ignore o resto da biblioteca por agora. Estes quatro cobrem a maior parte do que uma equipa precisa no início.

1. Project Starter. Um plano de projeto simples sem nada da configuração: algumas fases, um punhado de tarefas e espaço para as suas. É o modelo mais leve da galeria e é isso mesmo que se pretende, porque é o mais fácil de moldar ao que realmente faz. Escolha este se genuinamente não conseguir decidir, e escolha-o sobretudo se a sua última ferramenta o obrigava a preencher catorze campos antes de poder escrever uma tarefa.
2. Weekly Planner. A sua semana numa única vista, com os dias como estrutura e os seus compromissos por baixo. Bom para trabalho que chega num ritmo em vez de em projetos: uma escala de apoio ao cliente, uma semana de conteúdos, uma cadência de investigação. É também a solução discreta para quem mantém uma lista de afazeres sem qualquer relação com o dia em que está.
3. Meeting Agenda & Action Items. Uma agenda que produz seguimentos com responsável em vez de se evaporar no momento em que a chamada termina. Cada ponto da agenda pode guardar a decisão tomada e as tarefas que gerou, como sub-tarefas aninhadas com colaboradores reais. Se a queixa recorrente da sua equipa é "combinámos algo sobre isto numa reunião, não foi?", comece aqui e não por um modelo de projeto.
4. Team Task Management. Trabalho do dia a dia partilhado, atribuído e visível, sem fingir que é um projeto com prazo. Este é o modelo para equipas cuja necessidade real é "quem está a fazer o quê esta semana", uma pergunta genuinamente diferente de "quando é que isto sai". Combina bem com o Weekly Planner se quiser ver a semana e a carga de trabalho.
Para transformar um dos seus projetos concluídos num ponto de partida reutilizável, veja como criar modelos de projetos e tarefas no Quire.
Para trabalho que tem um início, um fim e, normalmente, uma data que importa a alguém.
5. Agile Project. Sprints com backlog, histórias e passos de revisão já montados, para que uma equipa possa correr o primeiro sprint sem discutir primeiro o quadro.
O que recebe é o fluxo de trabalho do sprint e a sua hierarquia, prontos a usar desde a primeira sessão de planeamento. Existe uma construção passo a passo do quadro Agile se quiser a configuração do sprint em detalhe.
6. Work Breakdown Structure. Um projeto grande dividido em níveis numerados: áreas, depois os componentes dentro de cada uma e, por baixo, os pacotes de trabalho, dimensionados para uma só pessoa ficar responsável.
É o modelo que mostra melhor as tarefas aninhadas, porque uma WBS é uma árvore por definição e o Quire deixa-a continuar a ser uma em vez de a reduzir a uma lista. O exemplo é a remodelação de um edifício, numerada de 1.1.1 a 3.2.5.
7. Issue Log. Uma lista simples de tudo o que a equipa tem pendente, ordenada por prioridade em vez de arrumada por fases. Sem secções, sem aninhamento, três estados: uma lista que é preciso expandir é uma lista que ninguém lê. Cada item tem uma prioridade, uma pessoa em vez de uma equipa e uma Tag para o tipo de trabalho, pelo que um quadro agrupado por colaborador mostra quem leva o quê.
8. Construction Schedule. Fases de obra desde as licenças até às inspeções e à entrega, com as dependências que tornam a construção implacável. Vale a pena abrir mesmo que nunca vá betonar nada: é o modelo mais detalhado da biblioteca e uma boa demonstração de quão fundo o aninhamento pode ir antes de um projeto deixar de ser legível.
9. Resource Management. Uma fila de pedidos para capacidade partilhada: o trabalho chega de algum ponto do negócio, alguém fica responsável e vê-se quem leva o quê e que departamento pediu. O requerente é quem pediu, não quem executa, e passar um pedido de Requested para Approved é o momento em que alguém assume capacidade. Um campo %Progress com faixas de cor e um Current Status separado mantêm a revisão honesta.
10. Product Roadmap. Funcionalidades acompanhadas da ideia até à entrega, agrupadas por versões em vez de despejadas num único backlog. Bom para equipas que precisam de responder a "o que vem a seguir e mais ou menos quando" sem manter um deck de roadmap separado que se desliga das tarefas até à segunda semana.
11. Daily Standup Meeting. Um standup de 15 minutos que funciona ao vivo ou em assíncrono, com um espaço por pessoa e um lugar para registar bloqueios em vez de os mencionar e esquecer. A parte assíncrona importa mais do que parece a equipas distribuídas por fusos horários, onde a reunião é aquilo que deixou de funcionar sem ninguém notar. O guia do standup explica como o correr em assíncrono como deve ser.
12. Sprint Retrospective. Uma retrospetiva com agenda votada, seis estados e itens de ação com responsável e data em vez de morrerem nas notas. As sublistas são a parte que importa, porque acompanham se as ações do sprint anterior aconteceram de facto antes de começar a retrospetiva deste. Como funcionam a votação e as sublistas de arrasto está descrito por inteiro.
13. Risk Register. Riscos pontuados numa matriz 5x5, um responsável para cada, com a mitigação acompanhada como sub-tarefas em vez de uma coluna de boas intenções. A cadência fixa de revisão é o que evita que um registo se torne um documento escrito uma vez durante o planeamento e nunca mais aberto. O guia do registo de riscos mostra como a pontuação 5x5 está montada.
14. RAID Log. Riscos, pressupostos, problemas e dependências num só registo, ordenados por impacto, com os quatro deliberadamente separados. A maioria das equipas confunde um risco com um problema, que é exatamente a distinção que o registo existe para impor: um risco pode acontecer, um problema já aconteceu. O guia do RAID log explica como manter as quatro categorias honestas.
15. Project Charter. Seis secções que aprovam um projeto antes de alguém começar a trabalhar, com dependências na Vista de Cronograma e custo e esforço como campos. As Aprovações integradas tratam da validação, pelo que o charter é uma barreira e não um documento que circula e expira em silêncio. A montagem da barreira de validação está descrita no guia do charter.
16. Communication Plan. Seis fases e uma matriz em Vista de tabela com público, canal e frequência, para que quem ouve o quê seja decidido uma vez em vez de rediscutido a cada atualização. As Aprovações ficam antes do envio.
Vale a pena recorrer a ele no momento em que um projeto tem mais partes interessadas do que quem o gere consegue guardar na cabeça. O guia do plano de comunicação constrói a matriz de públicos coluna a coluna.
17. Product Backlog. Cinco baldes, da entrada à refinação até pronto para desenvolvimento, com bugs e dívida técnica separados e um congelador para as ideias que ninguém quer apagar mas que também ninguém está a fazer. O congelador é a parte honesta, porque a maioria dos backlogs só é uma lista longa por não haver um lugar socialmente aceitável para pôr um talvez.
Três destes têm artigos completos: o que é uma work breakdown structure e como construir uma, um modelo de standup que sobrevive ao contacto com uma equipa real e como preocupar-se com o seu projeto de propósito com um registo de riscos.
O do Product Roadmap é explicado por inteiro, horizonte a horizonte, em planeamento de roadmap de produto em cinco etapas, incluindo a lista de verificação de lançamento de sete pontos que traz consigo.
O mesmo acontece com o do Sprint Retrospective: retrospetivas de sprint que realmente mudam o sprint seguinte mostra para que serve de facto a sua sublista de arrasto.
Sistemas pessoais, pré-construídos, para que aplique o método em vez de passar um fim de semana a montá-lo. O Weekly Planner também está aqui.
18. Getting Things Done (GTD). O ciclo completo de capturar, clarificar, organizar e refletir, com uma caixa de entrada feita para ser esvaziada e listas de próximas ações feitas para serem curtas.
O GTD vive ou morre na revisão semanal, por isso o modelo inclui-a como um compromisso recorrente em vez de a deixar como uma boa ideia sobre a qual leu uma vez. O guia do GTD monta a caixa de entrada e a cadência de revisão.
19. The Eisenhower Matrix. Quatro quadrantes que ordenam o trabalho por urgente contra importante, o que tem menos que ver com a grelha e mais com admitir quanto do primeiro quadrante é autoinfligido. Útil como triagem pontual quando um backlog descarrilou, e útil como hábito se conseguir ser honesto quanto a dar tempo real à coluna "importante, não urgente".
20. Time Blocking. Cada hora do dia com uma função atribuída, para que o calendário reflita intenção em vez de quem o marcou primeiro. Combina melhor com a Vista de Calendário, onde os blocos ficam visíveis contra os compromissos reais. Aviso justo: é o modelo com mais probabilidade de revelar que se comprometeu com cerca de nove horas de trabalho num dia de oito.
21. OKRs. Objetivos com resultados-chave por baixo, estruturados para que os resultados sejam mensuráveis e os objetivos não se multipliquem em silêncio. O aninhamento ajuda aqui: os resultados-chave ficam como sub-tarefas sob o seu objetivo, e o trabalho que os serve fica aninhado sob esses, para que consiga ver se algo está de facto a mover um número. O guia dos OKR mostra como o progresso sobe a partir do trabalho por baixo.
Análises aprofundadas de dois destes: um modelo de OKR que a sua equipa não vai abandonar discretamente no segundo trimestre e a Matriz de Eisenhower para quem sente o dia inteiro como urgente.
Pipelines, dinheiro, aprovações e métricas. O trabalho que faz o negócio funcionar em vez dos projetos.
22. Customer Relationship Pipeline. Um pipeline de vendas que serve também de base de dados de clientes. O separador Lista guarda cada contacto como uma tarefa, com Company, Email, Phone, Source e Lead Temperature no cartão.
A sublista Pipeline mostra os mesmos registos como um quadro, uma coluna por etapa, e arrastar um cartão altera o estado do registo, pelo que as duas vistas nunca se desalinham. O guia do pipeline explica como nomear as etapas.
23. Budget Allocation. Despesa planeada e acompanhada por categoria, com os números ao lado do trabalho que pagam. Os Campos personalizados fazem o trabalho pesado aqui, guardando planeado contra real para que o desvio seja visível sem exportar nada para uma folha de cálculo que depois se torna a verdadeira fonte de verdade.
24. Procurement Approval. Pedidos de compra padronizados com as validações de que precisam, pela ordem certa, para que ninguém tenha de se lembrar de quem aprova o quê acima de que valor. O objetivo deste é menos conversas, não mais processo: o modelo codifica a regra uma vez para que deixe de ser conhecimento oral.
25. KPI Performance Tracker. Um quadro de desempenho de entrega e não um painel de métricas: cada tarefa é pontuada consoante terminou antes da data limite (mais 1 antes, menos 1 depois, menos 2 se ainda estiver aberta e em atraso), e os pontos somam-se por pessoa.
Uma tarefa sem data limite não pontua nada, por isso fique atento. Os gráficos do Documento KPI Performance leem os totais em tempo real, por pessoa, por Tag e por estado.
26. Expense Tracker. Um mês de despesas agrupadas por categoria, cada uma com um orçamento e um somatório que mostra quanto já usou. Cada despesa é uma tarefa com Spending, Date e Payment Method.
Cada linha de categoria tem um Monthly Budget, um Total Spending e uma Visão Geral que divide um pelo outro: 0,94 significa 94% usado. O exemplo é o mês de um inquilino, da renda à Netflix. Leia a Visão Geral semanalmente, não mensalmente.
27. 30-60-90 Day Plan. Os primeiros três meses de uma nova contratação como três fases, acompanhadas na Vista de tabela, com pontos de revisão aos dias 7, 30, 60 e 90. A revisão ao dia 7 é a que a maioria dos planos de integração salta e a que apanha um mau início enquanto ainda é barato corrigi-lo. O guia do 30-60-90 explica o que pertence a cada fase.
28. Strategic Roadmap. Objetivos no topo, iniciativas por baixo, dispostos num cronograma com marcos e responsáveis. É o primo ao nível da empresa do Product Roadmap: a mesma forma, outra altitude, e o modelo a escolher quando a pergunta é o que o negócio está a fazer este ano em vez do que sai na próxima versão. Colocar pontos de controlo trimestrais no cronograma está descrito no guia do roadmap.
O fluxo de aprovação tem a sua própria explicação em o guia do modelo de compras.
Trabalho de campanha e de conteúdos, em que a data é normalmente externa e não negocia.
29. Social Media Planner. Conteúdo planeado, agendado e publicado em vários canais, com cada publicação a levar o seu próprio texto, material e aprovação como sub-tarefas. Resolve aquilo que realmente estraga os calendários de redes sociais: uma publicação é na verdade cinco pequenos trabalhos dependentes e, na maioria das ferramentas, só a data de publicação é visível.
O fluxo de produção por trás deste modelo tem o seu próprio artigo: o fluxo de trabalho de redes sociais, cinco tarefas por trás de cada publicação coloca os prazos da legenda, do material e da aprovação no calendário ao lado de cada data de publicação.
30. Product Launch Checklist. Uma lista de verificação para levar uma nova funcionalidade ao mercado: o briefing com a equipa de produto, a promoção em todos os canais e os resultados depois.
A Promoção tem uma tarefa principal por canal (email, blog, imprensa, anúncios pagos, redes sociais), e os estados vão de To-do, In progress, Validated, Scheduled e Completed, com Postponed para tudo o que fique em pausa. Defina a data real de lançamento e trabalhe a partir daí para trás: a Promoção acontece antes, a Campaign Analytics depois.
31. Design Pipeline. Pedidos de design a passar por entrada, execução, revisão e aprovação, o que evita que o "podes só ajustar isto rapidinho" chegue como mensagem direta e desapareça. A estrutura por etapas é o valor: torna a fila visível, pelo que priorizar passa a ser uma decisão que alguém toma em vez de quem pediu mais recentemente.
O fluxo de trabalho que este modelo executa, desde as seis respostas de que um pedido precisa até ao contador de rondas e ao aprovador único, está descrito no guia do processo de aprovação de design.
32. Marketing Campaign. Uma campanha em todos os canais que toca, em seis fases: estratégia e briefing, produção de conteúdo, revisão e aprovação, semana de lançamento, otimização em curso e a retrospetiva de medição no final.
Essa última fase é a primeira coisa a ser cortada quando um lançamento atrasa, e é por isso que aqui é uma fase e não uma tarefa que alguém devia lembrar-se de fazer. O guia completo está em como lançar uma campanha de marketing, que revela a lista de verificação de sete pontos para o dia do lançamento.
33. Team Brainstorm. Ideias recolhidas num quadro em torno de uma pergunta central, depois agrupadas por tema, priorizadas e com responsáveis. A verdadeira função do modelo é manter as duas metades separadas: gerar sem julgar e depois julgar sem gerar. Misturá-las é a razão pela qual a maioria dos brainstorms produz uma lista longa e nenhuma decisão. O guia do brainstorm explica o agrupamento e a votação depois de as ideias estarem lá.
Copiar leva menos de um minuto e acontece ao nível do projeto, não tarefa a tarefa. Abra o modelo, clique no menu ao lado do título, abra Mais e escolha Duplicar.

Dê um nome à sua cópia, escolha a organização onde ela deve ficar e clique em Criar.
Toda a estrutura vem com ela, o que importa mais do que parece: o valor de um modelo está sobretudo na sua hierarquia, e uma cópia que reduzisse tudo a uma única lista teria descartado justamente a parte que queria.
A sua cópia é sua para desmontar e o modelo original fica limpo para o próximo projeto.
Depois vem a parte que decide se o modelo pega. Apague primeiro. Percorra o que chegou e corte tudo o que não se aplica, antes de acrescentar uma única tarefa sua.
Os modelos são escritos para um caso geral, por isso a primeira edição honesta é sempre uma subtração. Se se der conta de que está a apagar quase tudo, isso é informação útil e não um fracasso: modelo errado, experimente um mais leve.
A seguir, adapte em vez de reconstruir. Aninhe as suas próprias sub-tarefas sob as fases que vieram com o modelo, para que as suas especificidades vivam dentro de uma estrutura que já se aguenta.
Acrescente um ou dois Campos personalizados se o trabalho precisar de uma dimensão que o modelo não adivinhou, como o nome de um cliente ou um estado de aprovação, e resista a acrescentar seis. Defina Marcos nas fronteiras de fase contra as quais realmente reporta.
Depois escolha a vista pela pergunta que está a fazer: Board para o que se move esta semana, Lista para a árvore completa, Cronograma para saber se as datas se mantêm, Calendário quando a disponibilidade das pessoas é a verdadeira restrição. As mesmas tarefas por baixo das quatro.
Quer sentir a diferença em dez minutos? Crie um projeto gratuito, copie o Project Starter para lá, apague o terço que não corresponde ao seu trabalho e acrescente as suas sub-tarefas sob o que sobrar. Terá um plano a funcionar antes do momento em que normalmente teria acabado de nomear as colunas.
Uma nota honesta sobre a biblioteca no seu conjunto. São modelos curados e não um mercado com milhares, o que é uma troca deliberada: menos para explorar, mas também nada para avaliar. Se a necessidade da sua equipa é um quadro muito nicho, é provável que comece no Project Starter e o construa em vez de o encontrar pronto.
Se o que precisa é de um plano sólido e não de uma biblioteca, comece com o modelo de plano de projeto que não se desfaz na segunda semana. Ainda a escolher a ferramenta? Compare primeiro os melhores softwares de gestão de tarefas e gestores de tarefas.
Todos os modelos de gestão de projetos acima existem para eliminar a hora de ecrã em branco no início de um projeto, não para lhe dizer como trabalhar.
Escolha pela forma do trabalho: modelos de projeto para trabalho finito com prazo, planeadores para ciclos repetidos, pipelines para trabalho por etapas em que cada item espera por uma decisão.
Quando dois parecem igualmente bons, fique com o mais leve, porque a estrutura é barata de acrescentar e caríssima de remover depois de as pessoas já estarem a trabalhar dentro dela.
O verdadeiro teste chega na primeira semana e é uma subtração. Um modelo que aparou para servir está a fazer o seu trabalho. Um modelo que manteve inteiro por educação torna-se uma lista de verificação que ninguém termina e ensina discretamente à equipa que o plano do projeto é decoração. Copie-o, corte-o e depois aninhe o seu próprio trabalho dentro do que sobreviver.
Quer dispensar a configuração no seu próximo projeto? Comece grátis em quire.io/signup, copie o Project Starter e apague até chegar a um plano que sirva.
Estruturas de projeto pré-construídas que contêm as tarefas, as fases e os campos de que um tipo de trabalho precisa, para que os copie em vez de começar num ecrã vazio. O Quire disponibiliza mais de 20, agrupados pela função que desempenham. A ideia é dispensar a configuração, não ouvir como deve trabalhar.
Mais de 20 modelos prontos a usar, distribuídos por cinco grupos: um conjunto Start Here, Gestão de projetos, Métodos de produtividade, Negócio e operações, e Marketing e criatividade. Vão de um Project Starter leve a uma construção completa de Construction Schedule, e a biblioteca continua a crescer.
Abra o modelo, clique no menu ao lado do título, depois Mais e depois Duplicar. Dê um nome à sua cópia, escolha a organização onde ela deve ficar e clique em Criar. Leva menos de um minuto, o aninhamento vem com ela e o modelo original fica intacto.
Escolha pela forma do trabalho, não pelo tamanho da equipa. Início e fim claros: Project Starter ou Work Breakdown Structure. Repete-se semanalmente: Weekly Planner ou Team Task Management. Avança por etapas: Design Pipeline ou Customer Relationship Pipeline. Na dúvida, fique com o mais pequeno.
Use um modelo para as partes que são iguais todas as vezes e construa o seu para as partes que são genuinamente suas. Qualquer modelo codifica os pressupostos de outra pessoa, por isso o verdadeiro teste é o que apaga na primeira semana. Se apagar quase tudo, o modelo não era o certo para si.
Eliminam o imposto do ecrã em branco no início de cada projeto. As equipas são mais produtivas no trabalho quando a primeira hora é dedicada ao trabalho e não a reconstruir uma estrutura que alguém já desenhou. No Quire, um modelo copiado mantém as suas sub-tarefas aninhadas e os campos, pelo que adapta um plano real em vez de inventar um sob pressão.