Aceitação da solução desenvolvida

1. Prepara a decisão a partir da solução entregue

A aprovação dos requisitos define uma referência; a aceitação da solução desenvolvida decide sobre aquilo que foi entregue. Prepara a segunda decisão com a versão candidata, o âmbito demonstrado, resultados face aos critérios e lacunas conhecidas.

Uma lista de testes verdes sem ligação ao compromisso pode não responder às perguntas dos stakeholders. Num projeto fictício de substituição de middleware, o decisor precisa de saber se o processamento, recuperação e operação acordados foram demonstrados para a versão proposta.

Resume o que cumpre, o que permanece por resolver e as opções que a autoridade aplicável pode escolher. Inclui a recomendação e a sua razão, evitando obrigar cada decisor a reconstruir todo o histórico técnico. Mantém acesso à evidência detalhada para quem precisar de a examinar.

O analista organiza essa ligação e facilita a decisão; a existência de um pacote bem apresentado não lhe transfere automaticamente autoridade para aceitar a solução.

2. Obtém decisões que cubram as responsabilidades necessárias

Identifica que responsabilidades a aceitação exige no contexto do projeto. Uma confirmação de Negócio sobre o resultado funcional pode não cobrir a obrigação operacional reservada a APS. Inversamente, aprovação operacional não resolve uma divergência sobre o comportamento esperado pelo utilizador.

O pacote deve mostrar quem decide cada matéria e como essas decisões compõem o resultado. Nos exercícios desta aula, a regra é explicitada; num projeto real deve ser confirmada na governação aplicável. Não exijas assinatura de todas as pessoas que contribuíram se a regra designa representantes com autoridade suficiente.

Isso pode atrasar uma decisão já válida sem acrescentar cobertura. Quando um representante está ausente, utiliza a delegação prevista, confirmando âmbito e validade. Uma reunião com muitos participantes não é por si só uma decisão completa.

O que importa é a cobertura das responsabilidades requeridas sobre o mesmo objeto de aceitação.

3. Define o efeito de uma limitação aceite

Uma limitação conhecida pode ter tratamentos diferentes conforme a sua natureza e a autoridade disponível. Se a regra permite aceitar uma discrepância de apresentação, o responsável pode fazê-lo com âmbito, razão, ação e prazo explícitos. Essa decisão não deve ser ampliada para um controlo obrigatório que a mesma regra não permite dispensar.

Também não é correto presumir que qualquer limitação exige rejeitar toda a solução. Apresenta opções dentro dos limites reais: corrigir antes da aceitação, aceitar uma limitação permitida ou adiar a decisão. Esclarece se uma condição precisa de estar cumprida antes da implantação ou se pode ser acompanhada depois.

“Aceite sujeito a recuperação demonstrada” não permite afirmar prontidão enquanto essa demonstração faltar. Regista a condição de forma observável, com responsável pela confirmação. A pressão da janela de manutenção pode justificar reunir rapidamente os decisores, mas não altera sozinha o significado da condição que eles aprovaram.

4. Liga a aceitação à versão que vai avançar

A decisão precisa de identificar a solução abrangida. Se a versão muda depois do sign-off, verifica se a alteração afeta o âmbito, os critérios, a evidência ou as condições da decisão. Nem toda a diferença exige repetir todos os testes; a análise de impacto pode justificar reutilizar evidência válida e confirmar apenas a parte afetada.

Contudo, a etiqueta “patch pequeno” não demonstra equivalência. Num exemplo fictício, R9 foi aceite com uma configuração de filas e recuperação ensaiada. R10 altera a política de repetição dessas filas.

O pacote de R9 não decide automaticamente sobre R10, mesmo que o fornecedor mantenha o nome comercial. Identifica a diferença, obtém a avaliação adequada e encaminha a decisão para a referência atual. Conserva a decisão anterior em vez de mudar retroativamente a versão que ela menciona.

Isso permite compreender o que foi decidido em cada momento e evita que um histórico pareça demonstrar uma avaliação que não ocorreu.

5. Comunica o que pode avançar e o que continua condicionado

Uma solução pode estar aceite e ainda aguardar uma janela de implantação autorizada. O sign-off é uma entrada relevante para avançar, mas outras condições do projeto podem continuar a aplicar-se. Num exercício, Negócio e APS aceitam R9; a autorização operacional permite implantar R9 apenas segunda-feira entre as 22h e as 23h.

Comunica ambos os factos: solução aceite, execução prevista naquela janela. Não transformes a aprovação numa ordem para executar imediatamente, nem descrevas a aceitação como inexistente porque a janela ainda não chegou. Usa estados que preservem estas distinções e indiquem a ação seguinte.

Após implantação, acompanha a medição de valor com os responsáveis definidos. Aceitar comportamento demonstrado não garante a realização de todas as poupanças previstas no business case. A passagem para operação deve tornar claros o resultado da decisão, condições ainda aplicáveis, responsabilidade pelo seguimento e referência utilizada pelo suporte.

6. Oficina: preparar o registo de aceitação

Condições fictícias: R9 demonstrou correspondência integral da população de ensaio e recuperação em 18 minutos face ao limite de 20. Negócio pode aceitar diferenças de apresentação e aceita um rótulo abreviado, com correção futura e responsável.

APS confirma os critérios operacionais. A regra exige estas duas decisões; ambas identificam R9. Uma autorização separada permite implantar R9 segunda-feira entre as 22h e as 23h.

O fornecedor propõe substituir R9 por R10, que altera a repetição após timeout e ainda não foi avaliado. Escreve o estado de cada versão, a ação imediata e a limitação que não deve desaparecer do registo. Resolução: R9 tem aceitação válida nas condições descritas, com rótulo aceite e ação futura; pode preparar-se para a janela autorizada.

R10 precisa de análise da alteração, evidência aplicável e decisão correspondente. Mantém R9 como alternativa disponível se continuar tecnicamente utilizável e dentro da autorização. Não estendas o sign-off ao novo comportamento nem reabras automaticamente todas as decisões sem avaliar o impacto.

Exercício: aceitação, preparação e intervalo viável

Num exemplo independente, a janela é 18:00–19:00. Uma execução pode durar entre 18 e 23 minutos e o plano deve suportar qualquer duração nesse intervalo. Os dados ficam prontos às 18:07; preparar a configuração B demora quatro minutos após essa prontidão.

Negócio e APS aceitaram a mesma versão/configuração B em produção, permitindo início a partir das 18:15. A recuperação cobre 18:05–18:42. A configuração C é mais recente, mas falta a sua aceitação APS.

Antes de consultar a solução, escreve as condições de entrada e calcula todos os inícios possíveis, incluindo extremos. Solução: B tem cobertura de decisão; C não. O início mais cedo de B é max(18:00, 18:07+4, 18:15, 18:05)=18:15.

O mais tarde é min(19:00−23, 18:42−23)=18:19. Logo [18:15,18:19] é o intervalo completo. A duração mínima não determina o último início seguro; às 18:20 uma execução de 23 minutos já ultrapassa a recuperação em um minuto.

Contraprovas: se APS só permitir começar às 18:20, o intervalo fica vazio; se a recuperação for confirmada até às 18:47, o último início passa a 18:24; se os dados só ficarem prontos às 18:16, os quatro minutos de preparação também tornam o intervalo original vazio.

Nenhuma dessas alterações apaga a aceitação anterior: muda a viabilidade atual ou o alcance da proposta. No trabalho, regista versão, configuração, ambiente, responsáveis e condições das decisões, prontidão, duração justificada e intervalos de execução e recuperação.

Confirma se cada condição vale no início ou durante toda a execução; aqui a recuperação tem de cobrir tudo. Calcula primeiro a cobertura das aprovações e depois a interseção temporal. Leva opções admissíveis ao responsável, mantendo separadas proposta, decisão e execução.

Se uma duração máxima não estiver sustentada, não a inventes para obter um intervalo favorável.

Prática guiada: versões, limites e opções de aceitação

Primeiro exercício. V7 foi aceite e V8 altera um campo obrigatório. Negócio assinou explicitamente para ambas as versões; APS assinou V8 condicionada a um canal de recuperação que continua disponível. Os testes do campo alterado ainda não foram feitos. Uma exceção de apresentação permite um rótulo abreviado, mas não dispensa o campo obrigatório. O que falta? Evidência da condição alterada. Nem a existência das assinaturas nem a exceção substituem essa demonstração. Também não é correto inventar uma assinatura de Negócio em falta, pois ela cobre expressamente V8.

Mantém uma tabela com objeto, versão, condição, responsável e evidência. Se o canal desaparecer antes da execução, surgirá outro impedimento, independente do teste pendente. Se o teste do campo passar, resolve a lacuna de evidência sem repor um canal que tenha sido removido. O histórico de V7 permanece como foi observado. A atualização do registo deve acompanhar a alteração concreta, sem apagar tudo nem transferir automaticamente tudo.

Segundo exercício. Uma limitação permitida pode ser aceite agora com custo 2q+3, em unidades previamente tornadas comparáveis; adiar custa 11. A carga q pode estar entre dois e seis, sem probabilidades. Aceitar varia entre sete e 15. As opções empatam em q=4; aceitar custa menos abaixo e adiar custa menos acima. Uma regra explícita de minimizar o pior custo escolheria adiar, mas não torna essa opção mais barata em todos os casos. O decisor pode pedir confirmação da carga ou escolher um critério de decisão; o analista apresenta a consequência dessa escolha.

Resumo: preparar aceitação exige demonstrar condições, respeitar mandatos e explicar consequências. A qualidade do dossier depende de responder à decisão atual, não de acumular ficheiros ou escolher silenciosamente uma preferência pelo decisor.

Armadilhas comuns

Aprovação de requisitos como aceitação da solução; sign-off transferido entre versões; condição em falta como ação concluída; aceitação como execução imediata ou benefício garantido.