Plano de projeto de software: o que incluir e exemplo

Um plano de projeto de software precisa resolver um impasse que todo gerente de projetos de tecnologia conhece. O patrocinador quer saber o que vai receber, quando e por quanto. O time de desenvolvimento sabe que boa parte do detalhe só vai aparecer durante a construção e resiste a qualquer documento que finja certeza. Os dois têm razão, e o plano é onde as duas necessidades se encontram.

Um bom plano não tenta prever cada tarefa. Ele fixa o que precisa ser fixo (objetivo, limites do escopo, orçamento, marcos, regras de mudança) e deixa explícito como o resto será decidido ao longo do caminho. Abaixo estão as seções que não podem faltar, a relação entre o plano e as Sprints, um modelo para copiar e um exemplo preenchido.

O que é um plano de projeto de software

É o documento que descreve como o projeto de software será conduzido do início ao encerramento. Ele responde a dez perguntas: por que o projeto existe, o que será entregue, o que não será, como o time vai trabalhar, em que ordem as entregas saem, quem faz o quê, quanto custa, o que pode dar errado, como saberemos que está pronto e como as pessoas serão informadas.

Ele se diferencia de um plano de projeto genérico em alguns pontos próprios do software: a abordagem de desenvolvimento (ágil, preditiva ou híbrida), a estratégia de ambientes e versões, a estratégia de testes, a migração de dados e a implantação em produção. O roteiro para planos de qualquer tipo de projeto, com etapas e um exemplo de evento, está em como fazer um plano de projeto.

As seções que não podem faltar

1. Objetivo e justificativa. O problema que o software resolve e o resultado esperado, com indicador. "Reduzir em X o tempo de atendimento" é objetivo; "desenvolver o sistema" não é.
2. Escopo e exclusões. As entregas principais, com referência à Estrutura Analítica do Projeto (EAP), e uma lista explícita do que fica de fora.
3. Abordagem de desenvolvimento. Ágil, preditiva ou híbrida; duração dos ciclos; ferramentas de gestão; definição de pronto.
4. Entregas e marcos. Versões planejadas e o que cada uma contém em linhas gerais, com datas-alvo para os marcos externos (piloto, lançamento, fim da operação assistida).
5. Equipe e responsabilidades. Papéis, dedicação, quem decide o quê. Em especial, quem prioriza o backlog e quem aprova mudanças de escopo, prazo e custo.
6. Estimativas e orçamento. Base das estimativas, orçamento por entrega ou por período, reserva para incertezas.
7. Riscos. Os principais riscos com probabilidade, impacto, resposta e responsável.
8. Qualidade e testes. Estratégia de testes, ambientes, critérios de aceite, requisitos de desempenho e segurança.
9. Implantação e transição. Migração de dados, treinamento, publicação, plano de retorno e passagem para a sustentação.
10. Comunicação e controle de mudanças. Reuniões, relatórios, painel de indicadores e o caminho de uma solicitação de mudança.

Como o plano convive com as Sprints

O plano de projeto e o planejamento da Sprint trabalham em horizontes diferentes. O plano olha para o projeto inteiro e muda pouco, só por decisão formal. O planejamento da Sprint olha para as próximas semanas e define o que o time vai construir dentro do que o plano estabeleceu.

Uma forma prática de ligar os dois é o plano de versões. Ele fica no plano de projeto e diz, em linhas gerais, o que cada versão deve conter. O backlog detalha os itens de cada versão, e cada Sprint puxa os itens do topo. Quando a velocidade real do time mostra que uma versão não cabe na data, a decisão volta para o nível do plano: cortar escopo, mover a data ou acrescentar capacidade, com aprovação de quem tem autoridade para isso.

Assim, o patrocinador continua tendo marcos e orçamento para acompanhar, e o time continua decidindo o detalhe a cada ciclo.

Modelo de plano de projeto de software para copiar

1. Objetivo e justificativa
   Problema:
   Resultado esperado e indicador:
   Patrocinador:

2. Escopo
   Entregas principais (ver EAP anexa):
   Fora do escopo:

3. Abordagem
   Modelo (ágil, preditivo, híbrido):
   Duração dos ciclos:
   Definição de pronto:

4. Plano de versões e marcos
   Versão / conteúdo principal / data-alvo:

5. Equipe e decisões
   Papel / pessoa / dedicação:
   Quem prioriza o backlog:
   Quem aprova mudanças de prazo e custo:

6. Orçamento
   Base da estimativa:
   Total e distribuição por período:
   Reserva:

7. Riscos principais
   Risco / probabilidade / impacto / resposta / responsável:

8. Qualidade
   Estratégia de testes:
   Ambientes:
   Critérios de aceite do projeto:

9. Implantação
   Migração de dados:
   Treinamento:
   Plano de retorno:
   Passagem para sustentação:

10. Comunicação e mudanças
   Reuniões e relatórios:
   Indicadores acompanhados:
   Fluxo de solicitação de mudança:

Exemplo preenchido: aplicativo de fidelidade

O exemplo continua o projeto fictício usado na EAP de projeto de software: um aplicativo de fidelidade para uma rede de farmácias, com aplicativo para Android e iOS, painel de marketing e integração com o sistema de vendas das lojas. Os números são ilustrativos.

Objetivo: aumentar a frequência de compra dos clientes cadastrados no programa de fidelidade, substituindo o cartão físico atual. Indicador: compras por cliente ativo por mês, comparadas com o programa atual.

Escopo: as oito entregas da EAP (gerenciamento, design, aplicativo, painel, integrações, infraestrutura, qualidade, implantação). Fora do escopo: resgate na loja online, programa para pessoa jurídica, versão para tablet.

Abordagem: híbrida. Sprints de duas semanas para o desenvolvimento; marcos fixos para piloto e lançamento por causa da campanha de marketing já contratada.

Plano de versões:

Decisões: o gerente de produto prioriza o backlog; mudanças que afetem a data do lançamento ou o orçamento passam pelo patrocinador, diretor de marketing da rede.

Riscos principais: atraso da equipe de TI da rede na liberação da integração de vendas (resposta: reunião técnica na primeira semana e marco intermediário de integração em homologação); rejeição do aplicativo nas lojas de aplicativos por pendência de política de privacidade (resposta: revisão jurídica no mês 3); baixa adesão dos operadores de caixa (resposta: treinamento presencial no piloto e material de bolso).

Qualidade: testes automatizados nos serviços de saldo e resgate, testes de integração com as cinco lojas piloto, teste de desempenho simulando o pico de sábado.

Implantação: carga da base atual do programa, piloto de quatro semanas, lançamento em ondas por região, operação assistida de 30 dias e passagem para o time de sustentação.

Comunicação: revisão de Sprint aberta ao marketing; relatório quinzenal ao patrocinador com o painel de indicadores; comitê mensal para decisões de escopo.

O painel de indicadores do projeto pode seguir as camadas de entrega, engenharia e resultado descritas em KPIs de projetos digitais.

Erros comuns no plano de projeto de software

• Plano que é só um cronograma. Sem regras de mudança e sem riscos, o primeiro imprevisto vira crise.
• Detalhe falso. Um cronograma com tarefas diárias para seis meses de desenvolvimento passa uma precisão que ninguém tem.
• Esquecer a implantação. Migração, treinamento e publicação ficam para "depois do desenvolvimento" e consomem as últimas semanas.
• Não dizer quem decide. Quando não está escrito quem prioriza e quem aprova mudanças, todas as decisões sobem para o patrocinador ou não são tomadas.

Monte o plano do seu projeto

Copie o modelo, preencha primeiro as seções 1, 2 e 5 (objetivo, escopo e decisões) e valide com o patrocinador antes de detalhar o resto. Se o projeto for a implantação de um software já pronto num cliente, adapte as seções conforme o roteiro de implementação de software B2B. Para montar o documento com as seções organizadas e exportar para compartilhar, use a ferramenta de plano do projeto da Projeto Diário. E, se você está do lado do produto e quer entender como o plano se conecta às decisões de roadmap, veja o que faz um gerente de produto.