Contexto e decisões da análise

1. Identifica o compromisso que a análise vai apoiar

Receber um projeto em curso não significa que o seu contexto esteja explicado pelo nome da iniciativa. “Modernização de middleware” pode referir-se a reduzir incidentes, permitir uma nova capacidade ou terminar um contrato. Cada propósito leva a perguntas diferentes.

Antes de escolher o próximo pacote de análise, lê o business case aplicável e liga objetivo, âmbito, pressupostos e próxima decisão. Num exemplo fictício, o objetivo aprovado é permitir retirar um serviço legado sem perder a consulta de movimentos históricos.

Uma apresentação comercial destaca maior velocidade de processamento, mas essa melhoria não é condição do compromisso atual. A análise inicial deve esclarecer quem consulta o histórico, que informação precisa e quais dependências impedem a retirada.

A velocidade pode continuar a ser uma oportunidade, sem substituir silenciosamente o propósito aprovado. Produz uma nota curta que identifique a decisão seguinte, a informação necessária e a referência que suporta o contexto. Não é obrigatório repetir o business case inteiro noutro documento; é preciso que a equipa consiga explicar por que razão está a investigar estas perguntas agora.

2. Distingue uma referência aprovada de um pressuposto confirmado

Um business case aprovado pode conter pressupostos que ainda precisam de confirmação. A aprovação autoriza o compromisso definido; não transforma uma previsão sobre o comportamento de um fornecedor em facto observado. Considera uma proposta cujo benefício depende de terminar faturação após retirar a aplicação.

O projeto tem autorização para analisar a migração, mas a nota comercial diz apenas que a data de cessação está por confirmar. Essa dependência deve entrar no trabalho de análise: identificar a condição contratual aplicável, quem a pode confirmar e antes de que decisão é necessária.

Não concluas que toda a iniciativa está cancelada nem apresentes poupança já assegurada. Pode haver trabalho autorizado que não dependa da resposta, como identificar consumidores do histórico. Regista separadamente a referência de contexto, o pressuposto, a evidência disponível e a decisão que ficaria exposta se o pressuposto falhasse.

Esta separação permite preparar informação proporcional ao compromisso. Uma lista genérica de riscos sem ligação à decisão não substitui saber o que falta esclarecer.

3. Revê materialidade antes de repetir trabalho

Nem toda a alteração ao contexto exige recomeçar a análise. No exercício, o produto mantém utilizadores, operações, dados e critérios aprovados; só o nome comercial mudou, e o responsável confirmou que não existem efeitos nas interfaces nem nas obrigações.

A equipa pode conservar a análise aplicável e ajustar referências de apresentação. Noutra situação, o mesmo produto passa de uso interno para utilização por uma entidade externa. Mesmo que a interface gráfica permaneça igual, já não se pode presumir que acesso, suporte, acordo de serviço e propriedade das decisões se mantêm.

Começa por relacionar a alteração com os pressupostos e decisões afetados. A revisão pode preservar partes válidas e abrir investigação apenas nas fronteiras alteradas. Explicita a razão: “Os tipos de movimento e cálculos mantêm-se; falta caracterizar acesso e operação do novo consumidor.”

Não uses o título da alteração como medida de impacto. “Pequena alteração” pode tocar numa condição decisiva, enquanto uma mudança extensa de apresentação pode não alterar a necessidade. A conclusão deve ser sustentada pelo contexto conhecido.

4. Separa benefício, condição de transição e obrigação corrente

O contexto de uma desativação pode conter três afirmações compatíveis: reduzir custos recorrentes, manter capacidade de consulta e operar temporariamente duas soluções. O custo da coexistência não desaparece porque a arquitetura de destino está pronta.

Também não é necessariamente uma falha do business case, se o período e o custo estavam previstos. Para planear a análise, identifica a condição que permite passar de uma fase para outra e os pressupostos usados para estimar o benefício. No exemplo, a cessação de uma licença exige a retirada do último consumidor e uma comunicação num prazo acordado.

O desenho técnico, por si só, não demonstra nenhuma dessas condições. Constrói uma cadeia curta entre capacidade preservada, consumidores que precisam de transitar, condições de retirada e início do benefício. Usa-a para decidir que informação pedir a APS, ao negócio e à função comercial.

Os prazos deste exercício são condições fictícias; consulta as condições reais do projeto antes de as aplicar. A análise ajuda a tornar dependências visíveis, mas não atribui ao analista autoridade contratual ou operacional que não tenha.

5. Escolhe a próxima investigação com uma regra de decisão

Contexto útil permite reconhecer tanto informação em falta como informação suficiente. O sponsor de um exercício autorizou um estudo limitado para saber se a consulta histórica pode funcionar sem manter o motor legado. O estudo termina quando demonstra as três consultas identificadas com os dados e condições acordados; não inclui capacidade de alterar movimentos.

Se as três demonstrações são válidas, insistir em estudar edição de movimentos não é condição para fechar este estudo. Pode ser um pedido futuro, a avaliar pelo processo aplicável. Pelo contrário, um relatório que confirma apenas duas consultas não cumpre a condição definida, mesmo que a terceira tenha poucos utilizadores.

Define a pergunta, a evidência necessária e a regra de paragem antes de alargar atividades. Esta disciplina evita transformar análise numa procura ilimitada de certeza. Também permite declarar limites: terminar o estudo de viabilidade não equivale a aprovar a implementação nem a demonstrar prontidão de produção.

Nomeia exatamente a decisão suportada e conserva as condições que pertencem às fases seguintes.

6. Oficina: reconstrói o contexto antes de planear a retirada

Enunciado fictício: o business case B4 pretende reduzir custo a partir de janeiro, preservando três consultas históricas. Autoriza estudo, sem autorizar ainda a retirada. Uma nota técnica propõe acrescentar edição de movimentos, fora do âmbito aprovado.

O fornecedor confirma que a faturação só cessa no primeiro dia do mês seguinte à retirada do último consumidor, desde que receba aviso com trinta dias de antecedência. O plano pretende retirar o serviço a 20 de dezembro, avisar a 10 de dezembro e começar a poupar em janeiro.

Dois consumidores confirmaram a transição; falta identificar o responsável pelo terceiro. Escreve a pergunta de análise, dois pressupostos expostos e trabalho que pode avançar. Resolução: confirmar a viabilidade das consultas e o caminho de transição de todos os consumidores; dez dias de aviso não cumprem os trinta exigidos, pelo que a poupança em janeiro não está sustentada por esse plano.

Não inventes a data contratual alternativa: é preciso confirmar a regra aplicável a aviso tardio. Identifica o terceiro responsável e prepara evidência das consultas. Mantém edição como proposta separada.

O estudo pode avançar dentro da autorização existente, conservando os impedimentos à retirada e ao benefício previsto.

Ligar benefício a acontecimentos e limites

Exemplo independente: a regra fictícia termina a cobrança no primeiro fecho em que a retirada já tenha ocorrido e tenham passado pelo menos 20 dias após confirmação do aviso. O aviso é confirmado no dia 12; os fechos são 30, 60 e 90. A retirada está garantida entre 35 e 55. Que data suporta o plano? O prazo de aviso só fica cumprido em 32. O fecho 30 falha e o fecho 60 cobre toda a janela de retirada, logo é o primeiro fecho válido em todos esses estados. Não é necessário somar 20 ao dia 55: os dois relógios podem decorrer em paralelo.

Agora a dependência muda e a retirada pode ocorrer até 65. O fecho válido passa a ser 60 se a retirada ocorrer até 60, e 90 se ocorrer depois. Sem probabilidades, não há uma data média demonstrada. O plano deve expor esse intervalo e rever a certeza do benefício, em vez de manter 60 como garantia. No trabalho, liga cada pressuposto à fonte comercial ou operacional e ao acontecimento que inicia a contagem. Esclarece inclusão das fronteiras, eventual rateio e condições ainda desconhecidas. Resumo: uma data técnica e uma redução de faturação só coincidem quando as condições aplicáveis o permitem.

Aplicação guiada: condições para retirar uma dependência

Uma equipa pretende retirar o arquivo Z no dia 40. A consulta corrente tem substituto demonstrado; a consulta de auditoria só foi ensaiada usando Z. Existe também uma obrigação de exportação anual ainda não analisada. Antes de fixar a data, constrói uma matriz com capacidade, consumidor, condição de continuidade, dependência e evidência. Não classifiques as três capacidades como equivalentes só por aparecerem no mesmo menu.

A consulta corrente pode conservar o resultado já demonstrado. A consulta de auditoria mantém uma dependência incompatível com a retirada, e a exportação ainda precisa de análise. Uma solução candidata deve demonstrar os resultados relevantes sem Z ou obter alteração de âmbito por quem tem autoridade. Reproduzir a aparência antiga não é condição suficiente nem necessariamente obrigatória. Regista as condições de falha e os períodos de utilização que precisam de prova.

Agora acrescenta a condição comercial: aviso até ao dia 15 termina pagamentos no dia 40; aviso posterior prolonga-os até 70. Compras só confirma o contrato no dia 17. A previsão de poupança no dia 40 fica sem suporte pelas regras dadas. Mantém custo até 70 como referência, enquanto Compras avalia uma solução autorizada. A análise técnica pode continuar se for útil nos dois ramos e já estiver autorizada. Variante: confirmação no dia 14 permite preparar um aviso atempado, mas não prova que ele foi enviado nem que a retirada técnica é possível. Resumo: planeia capacidades e janelas de decisão separadamente e liga-as antes de prometer retirada e benefício.

Armadilhas comuns

Tratar pressuposto aprovado como facto; substituir o objetivo por uma apresentação recente; reabrir toda a análise sem avaliar impacto; confundir viabilidade com autorização de retirada.