Escopo além do caminho feliz

O primeiro escopo de uma aplicação quase sempre conta uma história em que tudo dá certo. A pessoa se cadastra, faz o pedido, o gestor aprova, o pedido é entregue. Essa sequência tem nome entre quem desenvolve: caminho feliz.

É um bom ponto de partida, desde que o escopo não pare nele. Um escopo só com o caminho feliz é um mapa sem os desvios: parece suficiente até alguém precisar sair da rota, e isso acontece logo nos primeiros dias de uso.

O que fica fora do caminho feliz

Pense em um aplicativo de pedidos. O caminho feliz cabe em quatro telas. Agora considere o que acontece em uma semana comum:

• O cliente escolheu o produto errado e quer trocar depois de confirmar.
• O gestor aprovou e percebeu que o valor estava incorreto.
• A internet caiu no meio do pagamento.
• A pessoa fechou o aplicativo com o formulário pela metade.
• O mesmo pedido foi enviado duas vezes.
• O responsável pela aprovação está de férias.

Nenhuma dessas situações é rara. Cada uma pede uma decisão sobre como o produto se comporta. Se a decisão não foi tomada no escopo, ela vai ser tomada por quem estiver programando naquele dia, com a informação que tiver, ou vai aparecer como defeito depois da entrega.

Três perguntas para cada ação importante

Não é preciso prever tudo. Para cada ação que muda alguma coisa (criar, enviar, aprovar, pagar, excluir), três perguntas cobrem a maior parte dos casos.

Dá para desfazer? Até quando? Um pedido pode ser cancelado antes da aprovação, depois dela, depois do envio? Quem pode cancelar em cada momento? Há ações que não devem ser desfeitas, e isso também precisa estar escrito.

O que acontece com o que já foi feito? Se o pedido é cancelado, o estoque volta? O pagamento é estornado, e por quem? As pessoas que foram avisadas da aprovação são avisadas do cancelamento? O registro some ou fica marcado como cancelado?

Como a pessoa retoma? Se o processo foi interrompido, por queda de conexão ou porque ela saiu para atender o telefone, o que encontra ao voltar? O formulário preenchido, um rascunho salvo ou a tela inicial?

As respostas raramente são difíceis. O que falta, em geral, é alguém fazer as perguntas enquanto ainda é barato responder.

Por que isso muda o tamanho do projeto

Cada resposta tem um custo. "O pedido pode ser editado depois de aprovado" parece uma frase simples e pode significar guardar histórico de versões, reenviar para aprovação e avisar quem já tinha visto a versão anterior.

Com as situações à vista, dá para decidir com consciência. Algumas entram na primeira versão porque acontecem todo dia. Outras podem ser resolvidas por fora no começo, com alguém do suporte corrigindo manualmente, e automatizadas depois. Outras a empresa decide não permitir. As três saídas são válidas, desde que alguém tenha escolhido.

O que encarece um projeto é descobrir essas situações com a aplicação pronta, quando mudar o comportamento significa mexer no que já foi construído.

Quem deve participar dessa conversa

Quem conhece os desvios é quem vive o processo hoje. A pessoa que atende o telefone sabe quais pedidos voltam, e o financeiro, o que acontece quando um pagamento falha. Vale chamar também o gestor, que aprova algumas coisas sem olhar e confere outras duas vezes.

Uma forma prática é escolher uma tarefa concreta de um usuário real e percorrê-la em voz alta, parando a cada passo para perguntar: e se der errado aqui?

O escopo depois dessa conversa

O documento que sai dali tem, para cada funcionalidade, o caminho principal e as exceções que a primeira versão vai tratar, e registra o que ficou para depois, para ninguém achar que foi esquecido. Com isso, a estimativa de quem desenvolve leva em conta as exceções.

Na Jornada, o desenvolvimento de aplicações sob medida começa pelas necessidades de quem vai usar o produto, e a consultoria de escopo e arquitetura faz parte dos serviços. Se você tem um projeto no papel, conte o que precisa construir, com as exceções que ele precisa atender.