Uma fase de descoberta paga deve terminar com decisões e não apenas com documentos: o que construir primeiro e o que deixar de fora, os principais riscos e como foram testados, uma estimativa apresentada como intervalo com os seus pressupostos, e uma primeira etapa pronta a arrancar. Avalie-a com um único teste: seria possível levar os resultados a outra equipa e começar a construir sem recomeçar do zero?
A fase de descoberta serve para tomar as grandes decisões enquanto são baratas
A fase de descoberta, também chamada enquadramento ou inception, é uma fase curta e paga antes da construção de um software. A sua função é eliminar a incerteza que torna as estimativas pouco fiáveis e fechar as grandes decisões enquanto ainda é barato mudá-las. Mudar uma decisão no papel custa uma conversa; mudá-la depois de o código estar escrito custa retrabalho.
As primeiras estimativas de software são largas, e só se estreitam à medida que as decisões eliminam incerteza, um efeito muitas vezes chamado cone da incerteza. As reuniões, por si só, não as estreitam. A fase de descoberta compensa quando força essas decisões: o que o produto tem de fazer primeiro, que restrições são fixas e que riscos técnicos são reais.
Combinar o que vai receber antes de a fase começar
Compre a fase de descoberta como qualquer outro entregável: duração fixa, preço fixo, pessoas identificadas e uma lista escrita de resultados. Se um parceiro não consegue dizer o que o cliente terá nas mãos no fim, a fase pode derivar para workshops sem fim. Um conjunto completo de resultados cobre normalmente o seguinte.
- Uma definição do problema: quem são os utilizadores, de que precisam e como se vai medir o sucesso
- O âmbito da primeira versão: o que entra, o que fica de fora e o que é adiado
- Os percursos de utilizador principais, esboçados ou prototipados onde houver incerteza
- Um esboço de arquitetura: componentes principais, integrações, dados e alojamento, com as opções consideradas
- Um registo de riscos que ordena o que pode fazer falhar o projeto, e como cada risco será tratado
- Uma estimativa em intervalo com os seus pressupostos, e uma primeira etapa com critérios de aceitação
- Um registo de decisões que indica o que foi decidido, por quem e porquê
Procurar decisões, não uma pilha de documentos
Um relatório de descoberta pode ser longo e não decidir nada. Leia-o à procura de compromissos: que funcionalidades entram na primeira versão e quais não entram, que escolhas de tecnologia e de alojamento foram feitas, que integrações são necessárias, e que perguntas continuam em aberto, cada uma com um responsável e uma data.
Um sinal útil é aquilo que o parceiro desaconselhou. Se o âmbito for maior no fim do que no início e nada tiver sido cortado, a fase de descoberta provavelmente registou a lista de desejos do cliente em vez de a pôr à prova. Por vezes a conclusão certa é comprar um produto existente, construir menos ou não construir de todo, e uma boa fase de descoberta di-lo.
Os pressupostos mais arriscados devem ser testados, não apenas listados
Cada projeto assenta em alguns pressupostos que mudariam tudo se estivessem errados: uma API externa que não suporta a operação necessária, dados mais desarrumados do que o previsto, um objetivo de desempenho que o desenho escolhido não consegue atingir, ou utilizadores que não vão mudar a forma como trabalham.
Peça ao parceiro que identifique esses pressupostos cedo e que teste os piores durante a fase de descoberta, com um spike técnico, um protótipo clicável ou uma sessão de trabalho com as pessoas que operam o sistema em causa. Um risco testado é informação. Um risco apenas posto por escrito continua a ser um palpite.
Uma estimativa honesta é um intervalo acompanhado dos seus pressupostos
Um número único no fim da fase de descoberta esconde a incerteza que resta. Peça um intervalo para a primeira versão, decomposto pelos componentes principais, com os pressupostos que o fariam subir ou descer. Por exemplo: a estimativa pressupõe que a API do prestador de pagamentos já suporta reembolsos parciais; se não suportar, acrescenta-se o trabalho de integração indicado à parte.
Pergunte que partes da estimativa são firmes e quais continuam incertas, e como o modelo comercial vai tratar cada uma. As partes firmes podem ter preço fixo; as incertas precisam de um orçamento e de um momento em que se volta a decidir. A primeira etapa deve estar especificada com detalhe suficiente para poder ser entregue a preço fixo.
Manter uma porta de saída em cada passo
A fase de descoberta é também o momento mais barato para sair. Garanta que tudo o que produz pertence ao cliente, dos documentos e diagramas aos protótipos e ao código, e que os resultados são escritos para qualquer equipa competente e não apenas para o parceiro que os redigiu. Deve ficar livre para construir com esse parceiro, entregar os resultados a outra equipa, construir internamente ou parar.
Leve a mesma ideia para o plano que se segue: uma primeira etapa com critérios de aceitação, depois um ponto de decisão em que é possível continuar, mudar de rumo ou terminar a colaboração. É assim que começamos os projetos na SDK Enterprises: um âmbito escrito, uma primeira etapa fixa e os engenheiros identificados pelo nome, para que o cliente veja o plano antes de se comprometer com um orçamento maior. Quando só precisa de aconselhamento, recebe uma resposta escrita com que a sua equipa pode avançar, quer construa connosco quer não.
Seis perguntas que mostram se a fase de descoberta valeu o que custou
Quando a fase terminar, confronte os resultados com estas perguntas. Se a maioria das respostas for sim, o dinheiro comprou clareza. Se a maioria for não, pagou workshops.
- Outra equipa conseguiria começar a construir a partir destes resultados sem repetir a fase de descoberta?
- O parceiro falou com os utilizadores e com as pessoas que operam os sistemas envolvidos, e não apenas com o patrocinador?
- Os pressupostos mais arriscados foram testados, com os resultados por escrito?
- A estimativa é um intervalo com pressupostos claros e não um número único?
- Houve algo cortado, adiado ou posto em causa?
- A primeira etapa está especificada com detalhe suficiente para ser aceite ou recusada?
Pontos essenciais
- Comprar a fase de descoberta com duração fixa, preço fixo, pessoas identificadas e uma lista escrita de resultados.
- Avaliar os resultados pelas decisões que contêm, incluindo o que foi cortado ou desaconselhado.
- Os pressupostos mais arriscados devem ser testados durante a fase de descoberta, e não apenas listados num registo de riscos.
- Esperar uma estimativa em intervalo com pressupostos, e uma primeira etapa especificada com detalhe suficiente para ter preço.
- Ficar com a propriedade de todos os resultados, para poder construir com esse parceiro, com outra equipa ou não construir de todo.
Perguntas frequentes
A fase de descoberta deve ser paga, ou um parceiro pode fazê-la de graça?
O enquadramento gratuito faz parte da venda, por isso fica-se pelo que cabe numa proposta. Pagar a fase de descoberta compra tempo para ler o código, falar com os utilizadores e testar riscos, e resultados que pertencem ao cliente. Mantenha a fase curta e com preço fixo, para que o compromisso seja pequeno.
Quanto tempo deve durar uma fase de descoberta?
O suficiente para responder às perguntas que impedem uma estimativa fiável, e não mais. Combine a duração à partida com base na dimensão do produto e no número de sistemas envolvidos, e termine com uma decisão sobre a primeira etapa em vez de um prolongamento da fase.
E se a fase de descoberta mostrar que não vale a pena construir o projeto?
Então cumpriu a sua função ao menor custo possível. Uma boa fase de descoberta pode concluir que é melhor comprar um produto existente, construir uma primeira versão mais pequena ou parar, e as conclusões ficam com o cliente em qualquer dos casos.