EAP de projeto de software: exemplo para produto digital

A EAP de desenvolvimento de software costuma ser montada de dois jeitos errados. No primeiro, vira uma cópia das fases do processo (análise, desenvolvimento, testes, implantação), e ninguém consegue dizer o que exatamente será entregue. No segundo, vira uma lista de funcionalidades, e o projeto descobre no fim que esqueceu a infraestrutura, a migração de dados, a publicação nas lojas de aplicativos e o treinamento do atendimento.

A Estrutura Analítica do Projeto (EAP) é a decomposição hierárquica de todo o trabalho do projeto em entregas cada vez menores. Num projeto de software, ela precisa cobrir o produto e tudo o que cerca o produto. O exemplo abaixo mostra uma EAP completa para um aplicativo, com comentários sobre cada nível e a forma de ligá-la ao backlog do time.

O projeto do exemplo

Uma rede fictícia de farmácias quer lançar um aplicativo de fidelidade. O cliente acumula pontos nas compras, consulta o saldo, recebe ofertas personalizadas e resgata descontos no caixa. O projeto inclui o aplicativo para Android e iOS, um painel web para a equipe de marketing configurar campanhas, a integração com o sistema de vendas das lojas e o lançamento para os clientes.

O time tem um gerente de projetos, um gerente de produto, cinco desenvolvedores, um designer e um analista de qualidade. O prazo combinado é de seis meses até o lançamento. Os detalhes são ilustrativos.

A EAP de desenvolvimento de software do aplicativo

O primeiro nível tem as grandes entregas. Repare que funcionalidades, infraestrutura, implantação e gerenciamento aparecem lado a lado.

1. Aplicativo de fidelidade

• 1.1 Gerenciamento do projeto
  • 1.1.1 Termo de abertura e plano do projeto
  • 1.1.2 Relatórios de andamento e reuniões com o patrocinador
  • 1.1.3 Encerramento e lições aprendidas
• 1.2 Experiência e design
  • 1.2.1 Pesquisa com clientes das farmácias
  • 1.2.2 Protótipo navegável validado
  • 1.2.3 Guia visual e componentes de interface
• 1.3 Aplicativo do cliente (Android e iOS)
  • 1.3.1 Cadastro e autenticação
  • 1.3.2 Extrato e saldo de pontos
  • 1.3.3 Ofertas personalizadas
  • 1.3.4 Resgate de desconto com código no caixa
  • 1.3.5 Notificações
• 1.4 Painel de marketing (web)
  • 1.4.1 Cadastro de campanhas e regras de pontuação
  • 1.4.2 Segmentação de clientes
  • 1.4.3 Relatórios de adesão e resgate
• 1.5 Integrações
  • 1.5.1 Integração com o sistema de vendas das lojas
  • 1.5.2 Integração com o serviço de envio de notificações
  • 1.5.3 Carga inicial da base de clientes do programa atual
• 1.6 Infraestrutura e segurança
  • 1.6.1 Ambientes de desenvolvimento, homologação e produção
  • 1.6.2 Monitoramento e alertas
  • 1.6.3 Avaliação de segurança e privacidade de dados
• 1.7 Qualidade
  • 1.7.1 Plano de testes
  • 1.7.2 Testes de integração com as lojas piloto
  • 1.7.3 Testes de desempenho
  • 1.7.4 Homologação com o cliente
• 1.8 Implantação e lançamento
  • 1.8.1 Publicação nas lojas de aplicativos
  • 1.8.2 Treinamento dos operadores de caixa
  • 1.8.3 Piloto em cinco lojas
  • 1.8.4 Material de comunicação do lançamento
  • 1.8.5 Operação assistida no primeiro mês

Comentários sobre a estrutura

Por que gerenciamento do projeto é uma entrega. Planejamento, relatórios e encerramento consomem horas e precisam estar no orçamento. Se não aparecem na EAP, o custo do gerenciamento some da estimativa.

Por que o design está separado do aplicativo. Pesquisa e protótipo acontecem antes da construção e geram entregas verificáveis por si só. Num time que trabalha em ciclos curtos, o design também acompanha cada funcionalidade; o pacote 1.2 cobre a fase inicial e o sistema visual.

Por que integrações e infraestrutura têm galhos próprios. São as entregas que mais costumam ficar fora das primeiras estimativas e que mais atrasam projetos de software. Destacá-las obriga a equipe a estimá-las.

Por que implantação vai além de publicar o aplicativo. Para o cliente final, o aplicativo só funciona se o operador de caixa souber registrar o resgate. Treinamento, piloto e comunicação fazem parte do escopo do projeto, mesmo que não sejam software. A diferença entre o que o produto faz e o trabalho necessário para entregá-lo está em escopo do produto e escopo do projeto.

A regra dos 100%. A soma dos itens de cada nível deve representar todo o trabalho do nível acima, nem mais nem menos. Se algo do projeto não cabe em nenhum galho, falta um galho.

Até onde decompor

O último nível da EAP é o pacote de trabalho: uma entrega pequena o bastante para ser estimada em prazo e custo e ter um responsável. Em software, um bom teste é perguntar se a equipe consegue estimar o pacote com razoável confiança. "1.3 Aplicativo do cliente" não passa nesse teste; "1.3.2 Extrato e saldo de pontos" passa.

Não é preciso descer ao nível de tarefa ("criar tela de extrato", "codificar serviço de saldo"). Esse detalhe pertence ao backlog e ao planejamento de cada ciclo, e muda com frequência.

Um item do dicionário da EAP

O dicionário da EAP descreve cada pacote de trabalho para que não haja dúvida sobre o que está incluído. Exemplo para o pacote 1.3.4:

O campo "fora do escopo" é o que mais evita discussão no aceite.

Como a EAP convive com o backlog do produto

Num time que trabalha com Scrum ou Kanban, a EAP e o backlog não competem. A EAP dá o mapa do escopo inteiro do projeto, útil para o contrato, o orçamento e a comunicação com o patrocinador. O backlog dá a ordem de construção e o detalhe, refinado continuamente.

Na prática, cada pacote de trabalho de funcionalidade vira um épico no backlog, e as histórias de usuário nascem da decomposição desse épico. Os pacotes que não são funcionalidade (treinamento, publicação, operação assistida) também entram no backlog ou num quadro paralelo do projeto, para que não fiquem invisíveis. A montagem das histórias está em como criar seu primeiro backlog de produto.

Quando o escopo muda, por exemplo com a inclusão do resgate na loja online, a mudança é registrada nos dois lugares: como novo pacote na EAP, com impacto em prazo e custo, e como novo épico no backlog.

Da EAP ao plano do projeto

Com a EAP pronta, o restante do planejamento ganha base: o cronograma sequencia os pacotes, as estimativas somam o orçamento, os riscos são associados aos pacotes mais incertos e a matriz de responsabilidades distribui os donos. O documento que reúne tudo isso está descrito em plano de projeto de software. Se você usa o Microsoft Project, a forma de transformar a EAP em tarefas de resumo e marcos está em EAP no MS Project.

Monte a EAP do seu projeto

Pegue o projeto de software que você está planejando e escreva o primeiro nível com as oito entregas do exemplo como ponto de partida: gerenciamento, design, produto, interfaces internas, integrações, infraestrutura, qualidade e implantação. Corte o que não se aplica e acrescente o que falta. Depois, decomponha até os pacotes de trabalho. A ferramenta de EAP da Projeto Diário monta a estrutura em árvore e numera os itens para você, pronta para levar ao plano. Para entender como o gerente de produto e o gerente de projetos dividem as decisões sobre esse escopo, veja o que faz um gerente de produto.