Planejamento, Cronograma e Custos
Termo de abertura de projeto de software: exemplo comentado
O termo de abertura de projeto de software tem os mesmos campos de qualquer termo de abertura, mas falha em lugares diferentes. Em obra ou evento, o problema costuma ser orçamento subestimado. Em software, o mais comum é um objetivo escrito em linguagem técnica ("desenvolver um sistema web"), um escopo que não menciona integrações nem migração de dados e um prazo que não considera quem vai homologar.
O resultado aparece meses depois: o sistema fica pronto, mas ninguém sabe se o projeto teve sucesso, porque o objetivo nunca disse o que deveria mudar no negócio. Ou o patrocinador descobre que a integração com o sistema financeiro, que ele dava como certa, nunca esteve no orçamento.
Abaixo está um termo de abertura completo de um projeto ilustrativo, seguido de comentários sobre cada bloco. O que é o documento e para que ele serve está em termo de abertura do projeto; o modelo genérico em branco está no modelo de termo de abertura. Aqui o foco é o que muda em software.
Formação relacionada
Microsoft Project Professional
Cronogramas confiáveis, linha de base, controle de desvio e relatórios que sustentam decisão de diretoria.
O que pede mais atenção num projeto de software
| Campo do termo | Cuidado específico em software |
|---|---|
| Objetivo | Resultado de negócio medível, não "implantar o sistema" |
| Escopo inicial | Capacidades principais, integrações, migração, sustentação e o que fica fora |
| Marcos | Incluir homologação e entrada em produção, não só "desenvolvimento concluído" |
| Orçamento | Licenças, nuvem e suporte recorrente, além do desenvolvimento |
| Riscos | Requisitos instáveis, dependência de fornecedor, dados pessoais, adoção pelos usuários |
| Partes interessadas | Usuários finais, TI interna, segurança da informação, jurídico, fornecedor |
| Autoridade do gerente | Quem prioriza funcionalidades: o gerente, um dono do produto ou um comitê |
Exemplo de termo de abertura de projeto de software
O exemplo é ilustrativo: uma rede de seis clínicas de fisioterapia contrata um sistema de agendamento online. Os números são fictícios e as contas foram conferidas.
TERMO DE ABERTURA DO PROJETO
Projeto: Agenda Online Versão: 1.0
Patrocinador: diretora de operações Gerente do projeto: coordenador de TI
Dono do produto: gerente de atendimento Data: 18/01/2027
1. JUSTIFICATIVA
Todos os agendamentos são feitos por telefone. As recepcionistas
passam grande parte do turno ao telefone e a taxa de faltas média
da rede foi de 18% em 2026, sem lembrete ao paciente.
2. OBJETIVOS E CRITÉRIOS DE SUCESSO
- Reduzir em 40% as ligações de agendamento nas seis clínicas,
medido 3 meses após a entrada em produção da última clínica.
- Reduzir a taxa de faltas de 18% para 12% no mesmo período.
- Projeto concluído até 31/07/2027 dentro do orçamento autorizado.
3. DESCRIÇÃO E ESCOPO INICIAL
Sistema web, acessível pelo navegador do celular, para o paciente
ver horários, agendar, remarcar e cancelar; lembrete automático;
agenda do dia para a recepção; grade de horários pela coordenação.
Inclui: carga inicial de profissionais e horários, treinamento das
recepcionistas, 30 dias de suporte após a entrada de cada clínica.
Fora do escopo: pagamento online, aplicativo nativo, prontuário
eletrônico, integração com planos de saúde.
4. MARCOS
Termo de abertura aprovado ...................... 18/01/2027
Escopo detalhado e protótipo aprovados ........... 26/02/2027
MVP em produção na clínica piloto ................ 30/04/2027
Sistema em produção nas seis clínicas ............ 30/06/2027
Encerramento e transição para a sustentação ...... 30/07/2027
5. ORÇAMENTO AUTORIZADO
Desenvolvimento (fornecedor, preço fixo por entrega) R$ 180.000
Nuvem e licenças (primeiro ano) ..................... R$ 24.000
Horas da equipe interna ............................. R$ 46.000
Treinamento e materiais ............................. R$ 10.000
Subtotal ............................................ R$ 260.000
Reserva para riscos (10%) ........................... R$ 26.000
Total autorizado .................................... R$ 286.000
6. PREMISSAS E RESTRIÇÕES
Premissas: cada clínica indica uma recepcionista para o piloto;
a coordenação entrega a grade de horários até 26/02/2027.
Restrições: usar a nuvem já contratada pela rede; tratamento de
dados pessoais conforme a política de privacidade da empresa e a LGPD.
7. RISCOS DE ALTO NÍVEL
- Pacientes mais velhos não aderirem ao agendamento online.
- Pedidos de funcionalidades novas durante a construção.
- Atraso do fornecedor na entrega do MVP.
- Exposição de dados de saúde por erro de permissão.
8. PARTES INTERESSADAS PRINCIPAIS
Diretoria, coordenadores e recepcionistas das clínicas,
fisioterapeutas, TI interna, encarregado de dados pessoais,
fornecedor de desenvolvimento.
9. AUTORIDADE DO GERENTE DO PROJETO
Aprova mudanças de até R$ 10.000 ou 5 dias úteis sem afetar marcos.
Acima disso, decide a patrocinadora. A prioridade entre
funcionalidades é definida pelo dono do produto, dentro do escopo.
10. APROVAÇÃO
Patrocinadora: ____________ Gerente do projeto: ____________
Conta do orçamento: 180.000 + 24.000 + 46.000 + 10.000 = 260.000; 10% de 260.000 = 26.000; 260.000 + 26.000 = 286.000.
Comentários sobre o exemplo
Objetivos de negócio, não de tecnologia
"Implantar o sistema de agendamento" seria um objetivo cumprido no dia da entrada em produção, mesmo que nenhum paciente usasse o sistema. Os dois objetivos do exemplo medem o que o patrocinador quer de fato, ligações e faltas, e têm data de medição posterior à entrega. É assim que o termo deixa claro que adoção faz parte do sucesso.
Escopo inicial com o que fica fora
O escopo do termo de abertura é de alto nível: cinco ou seis capacidades, as entregas que não são código e as exclusões. Repare que as exclusões são justamente o que alguém poderia supor incluído num sistema de clínica: pagamento, aplicativo, prontuário. O detalhamento em requisitos funcionais, não funcionais, MVP e critérios de aceite vem depois, e o mesmo projeto aparece desdobrado no artigo sobre escopo de projeto de software.
Marcos que terminam em produção
"Desenvolvimento concluído" não é marco útil para o patrocinador. Os marcos do exemplo terminam em situações verificáveis: protótipo aprovado, sistema em produção no piloto, sistema em produção em todas as clínicas. Também há um marco de transição para a sustentação, porque sistema sem dono depois do projeto vira chamado sem resposta.
Orçamento com o custo recorrente
Projetos de software costumam ser aprovados só com o valor do desenvolvimento. Nuvem, licenças e horas da equipe interna somam, no exemplo, R$ 70.000 dos R$ 260.000 do subtotal, cerca de 27%. Deixá-los de fora não economiza nada, só adia a surpresa. A reserva de 10% é uma escolha ilustrativa; o ideal é calculá-la a partir dos riscos quando o plano estiver detalhado.
Riscos típicos de software
Os quatro riscos do exemplo aparecem em quase todo projeto de sistema: adoção pelos usuários, aumento de escopo, dependência de fornecedor e segurança dos dados. No termo de abertura basta nomeá-los; a análise com probabilidade, impacto e respostas vem no planejamento.
Quem decide o quê
O campo de autoridade é onde projetos de software mais precisam de clareza, porque há três papéis que podem se confundir. O patrocinador decide orçamento e marcos. O gerente do projeto conduz o plano e aprova mudanças pequenas. O dono do produto prioriza funcionalidades dentro do escopo aprovado. Sem essa separação, toda reunião vira negociação de prioridade com quem estiver na sala.
Termo de abertura em projeto ágil de software
O Guia do Scrum não tem um documento chamado termo de abertura, e isso leva algumas equipes a pular essa etapa. O problema é que o Scrum organiza o trabalho do time, mas não autoriza investimento. Alguém precisa dizer quanto a organização aceita gastar, até quando, com qual objetivo e quem é o dono do produto.
Em projetos ágeis, o termo de abertura fica mais curto: objetivo, orçamento ou capacidade do time por período, marcos de negócio, limites e papéis. O detalhe das funcionalidades vai para o backlog. O objetivo de negócio do termo pode ser a origem da meta do produto que orienta o backlog.
Erros comuns no termo de abertura de software
- Termo escrito pelo fornecedor. A proposta comercial descreve o que o fornecedor vai entregar; o termo descreve o que a sua organização quer alcançar. São documentos diferentes.
- Prazo sem homologação. Se a área usuária precisa de três semanas para testar, isso é tempo do projeto.
- Nenhum dono do produto nomeado. As decisões de prioridade acabam com o desenvolvedor ou com quem grita mais alto.
- Sustentação ignorada. Quem corrige erros e atende usuários depois do encerramento precisa estar definido.
A assinatura cabe ao patrocinador, e as variações em projetos com cliente externo ou vários patrocinadores estão em quem assina o termo de abertura do projeto.
Monte o termo de abertura do seu sistema
Use o exemplo como roteiro: escreva primeiro os objetivos de negócio com número e data, depois as exclusões, e só então os marcos e o orçamento com o custo recorrente. O gerador gratuito de termo de abertura da Projeto Diário conduz cada campo e baixa o documento pronto para assinatura. Para seguir do termo ao plano completo, com escopo, cronograma e custos, use o guia de planejamento de projetos.
