Conduzir o workshop de revisão do blueprint da solução

Concluído

O workshop de revisão do blueprint da solução será facilitado pelo arquiteto de soluções, mas a expectativa é que a equipe de implementação apresente as informações do blueprint da solução. Cada seção da agenda deve ter um responsável da equipe de implementação. No início de cada sessão, o proprietário deve apresentar uma visão geral ou um resumo do escopo e dos planos, incluindo os designs aplicados a esse aspecto da solução. A equipe deve planejar um resumo que dure 25-50% do tempo alocado, mas não mais que isso. O restante do tempo deve ser reservado para perguntas e respostas com o arquiteto de soluções.

A liderança da equipe de implementação deve trabalhar com o arquiteto de soluções antes do workshop para decidir a pauta e o cronograma de cada sessão. Dependendo do estado e da complexidade da solução, seções diferentes podem exigir mais ou menos tempo. Embora o plano base seja conduzir o workshop em oito horas, esse tempo pode ser prolongado até certo ponto para acomodar a implementação.

O gerenciamento de tempo do workshop de revisão do blueprint da solução é fundamental. A prioridade máxima do workshop é cobrir a solução geral e não se aprofundar demasiadamente em uma só sessão. Se as discussões se tornarem muito detalhadas a ponto de colocarem em risco a cobertura de toda a solução, espera-se que o arquiteto de soluções retorne à agenda original e organize a continuação do ponto interrompido em um workshop mais detalhado.

Observação

Em cada sessão, devem ocorrer discussões sobre o escopo e a abordagem. Como parte dessa expectativa, o arquiteto pode fornecer algumas diretrizes diretamente na reunião. No entanto, essas sessões não devem ser sessões de design, mas sim de revisão. Os comentários fornecidos podem alterar o plano ou o design atual, mas o trabalho detalhado nessas áreas será realizado pela equipe de implementação após o workshop.

Resultados da revisão do blueprint da solução

O resultado do workshop de revisão do blueprint da solução é um documento de conclusões. Esse documento é uma resposta às informações fornecidas como preparação para o workshop ou durante o workshop. Essas conclusões geralmente são de três tipos:

  • Declarações – essas conclusões se relacionam a aspectos específicos da solução que o arquiteto de soluções deseja destacar como significativos. Essas declarações são fatores que talvez não representem um risco ou um problema específico, mas que são fundamentais para a solução e devem ser observados, pois terão um impacto significativo se forem alterados. As declarações podem se relacionar a itens específicos do escopo, a aspectos de design da arquitetura de solução ou à técnica ou abordagem de implementação.
  • Riscos – essas conclusões são aspectos da solução ou da abordagem de implementação que constituem um risco e devem ser rastreados no projeto. Essas conclusões podem se relacionar a planos, abordagens ou designs existentes que tenham um potencial observado para resultados negativos. Eles também podem estar relacionados a áreas da solução que ainda não foram adequadamente exploradas e, como tal, representam um risco de acontecimentos inesperados. Essas conclusões serão acompanhadas por uma instrução do que é visto como um risco pelo arquiteto de soluções, juntamente com as etapas de mitigação recomendadas.
  • Problemas – essas conclusões são aspectos da solução ou da abordagem de implementação que afetam negativamente a implementação ou, se não forem corrigidos, terão um impacto negativo no futuro. Essas conclusões serão acompanhadas por uma instrução de qual é ou será o impacto, juntamente com as etapas de resolução recomendadas.

O documento de conclusões será distribuído para as organizações do cliente e do parceiro, e uma reunião de revisão será agendada para avaliar as conclusões em detalhes. O documento será enviado aos líderes da implementação e aos patrocinadores executivos nas duas organizações. Em alguns casos, o documento de conclusões pode ser longo. Se isso acontecer, deverá ser fornecido um resumo executivo realçando as conclusões essenciais e críticas a fim de facilitar seu entendimento pela gerência executiva.

Observação

O resultado do workshop de revisão do blueprint da solução não é um blueprint da solução. A expectativa é que os materiais trazidos para a revisão pela equipe de implementação constituam o blueprint da solução. Esse blueprint deve continuar evoluindo e se expandindo à medida que a implementação progride.

Revisões posteriores do blueprint da solução

Na maioria dos casos, a revisão do blueprint da solução realizada no início da implementação, complementada por workshops aprofundados, é suficiente para a implementação. Ocasionalmente, são necessárias revisões posteriores. Os exemplos a seguir são cenários nos quais pode ser necessário realizar revisões de adicionais do blueprint da solução:

  • Desafios na revisão inicial do blueprint da solução – em casos raros, o workshop de revisão do blueprint da solução não consegue cobrir todas as informações necessárias. Isso pode ser devido a grandes lacunas ou conflitos no entendimento do escopo que precisam ser resolvidos pela equipe de implementação. Outro motivo pode ser a ausência significativa de um design conceitual da solução. Nesses cenários, é importante realizar o primeiro workshop de revisão do blueprint da solução cedo a fim de realçar problemas que precisarão ser resolvidos, mas isso exigirá que o workshop seja repetido.
  • Alteração significativa no escopo – ocasionalmente, uma implementação é afetada por grandes alterações no escopo ou na abordagem devido a diversas circunstâncias possíveis. Essa situação pode incluir alterações por fatores externos, mas também pode estar relacionada a alterações significativas que seguem a análise detalhada dos requisitos. Após alterações desse tipo, fará sentido reavaliar o blueprint da solução.
  • Mudanças organizacionais – periodicamente, as organizações passarão por uma mudança significativa durante a implementação. Eventos como fusões, aquisições ou alienações podem afetar significativamente a arquitetura da solução e pode ser necessário fazer uma nova avaliação.