Sessões de captura de requisitos de cliente potencial
O arquiteto de soluções normalmente lidera as sessões de captura de requisitos. O objetivo dessas sessões é desenvolver as necessidades de alto nível para transformá-las em requisitos implementáveis. Se o mesmo arquiteto de soluções estiver envolvido durante a fase de pré-vendas, talvez ele já entenda as necessidades do cliente e os fatores de sucesso. Caso contrário, o arquiteto de soluções deve garantir que esteja bem informado antes da primeira sessão. Essas informações devem ser usadas para conduzir a discussão com os participantes.
À medida que ganhar mais experiência ao realizar as reuniões, você adotará uma metodologia preferencial. Esteja preparado para mudar de acordo com as necessidades de qualquer projeto ou cliente específico. Chegue às sessões com um plano, modelos e resultados desejados; no entanto, evite ser rígido a ponto de impedir a conversa, a criatividade e as soluções.
Como é um requisito
A maneira como um projeto documenta uma necessidade pode ser específica para uma metodologia escolhida. No entanto, em todos os casos, os requisitos devem capturar quem, o que e por quê. Esses parâmetros podem ser capturados em histórias de usuários ou podem ser requisitos de itens de linha, mas deve ser possível testá-los e atribuir a responsabilidade por eles. Um bom requisito leva em conta os seguintes fatores:
Quem precisa do requisito
Do que o cliente precisa
Por que o cliente faz algo
Requisitos ou histórias mais amplos precisam ser divididos em partes gerenciáveis. Metodologias diferentes usam termos distintos para essas partes; por exemplo, as abordagens ágeis normalmente as chamam de épicos. Independentemente do nome, o arquiteto de soluções precisa garantir que esse processo aconteça.
Priorização
Cada projeto tem uma quantidade limitada de tempo e recursos que podem ser aplicados para implementar os requisitos. O arquiteto de soluções, junto com a equipe do projeto e, frequentemente, o cliente, precisa priorizar a lista de requisitos e pendências.
Como os projetos de aplicativos de negócios se prestam bem a implantações incrementais, as equipes geralmente priorizam um MVP (produto mínimo viável). Um MVP identifica os requisitos que precisam ser concluídos para entrar em operação inicialmente. Em seguida, os itens restantes ocorrem em futuras iterações ou sprints.
O arquiteto de soluções deve usar os principais objetivos de negócios identificados para avaliar os requisitos. Deve ser dada prioridade aos requisitos que ajudam a cumprir os objetivos. Essa abordagem também poderá ajudar a identificar uma desconexão com os objetivos principais se você identificar um requisito que é claramente importante, mas não ajuda a atingir os objetivos principais.
Viabilidade
O arquiteto de soluções deve avaliar os requisitos para garantir que sejam viáveis. Procure requisitos que, embora atraentes, não podem ser alcançados por vários motivos, como aqueles que exigem:
Dados que você não tem.
Atualizações de outros sistemas que não são possíveis no prazo.
Uma boa pergunta que o arquiteto de soluções pode fazer a si mesmo: "Há algo que possa impedir que esses requisitos sejam cumpridos?"
Gerenciar participantes
As expectativas devem ser definidas antes das sessões para garantir que as pessoas certas participem. Você deve garantir que tenha pessoas experientes que entendam as áreas-alvo. A realização de várias sessões menores e mais curtas pode ser uma opção mais direcionada e produtiva. Convidar pessoas diferentes para lidar com as diversas partes de um processo é valioso porque ajuda a obter uma visão completa de como cada parte do processo funciona. Frequentemente, essa abordagem evitará que você tenha que fazer o acompanhamento para entender o funcionamento de algo.
Pode ser útil convidar a gerência para participar, pois frequentemente você obtém informações mais decisivas. No entanto, lembre-se de que a presença de um gerente sênior pode afetar a disposição da equipe dele em participar. Em muitos casos, a equipe participará menos e deixará que o gerente responda para evitar erros. Se achar que esse cenário está acontecendo de forma negativa, talvez você tenha que lidar com ele fazendo o acompanhamento separadamente ou pedindo ao gerente que não compareça a todas as sessões.
Trabalho prévio antes das sessões
Antes da sessão, o arquiteto de soluções deve tentar obter o máximo de informações possível sobre a solução atual e seus processos. Essas informações podem ser estudadas com antecedência para formular perguntas que podem ser usadas para manter a discussão em andamento. A preparação também pode ajudar os participantes a reunir documentos e exemplos que eles podem levar para as sessões.
Além disso, lembre-se de reunir o que a equipe de pré-vendas coletou. Evite fazer com que os clientes recomecem e repitam as mesmas informações que já foram discutidas. Determine se foram feitas gravações de demonstrações para ajudá-lo a se informar.
Concentre-se na clareza dos requisitos
Frequentemente, a declaração de requisito inicial de um usuário de negócios não é o requisito real. O arquiteto de soluções precisa investigar para orientar o usuário ou deve se comunicar com outras pessoas a fim de chegar ao requisito real. O arquiteto de soluções deve aprender a perguntar "Por quê?" sem perturbar o usuário ou fazer parecer
que o usuário é inapto a fazer seu trabalho. A verdadeira razão para as perguntas é entender o problema central para que a melhor solução possa ser projetada.
Preparar perguntas comuns com antecedência pode ajudá-lo a extrair informações:
Você consegue transcorrer um dia desse processo?
Quem mais está envolvido nesse processo?
De onde vêm as informações?
Você pode me ajudar a entender por que esse processo é necessário?
Se começar com perguntas abertas para chegar aos requisitos e necessidades reais, você poderá trabalhar em uma pergunta do tipo sim ou não para confirmar seu entendimento. O exemplo a seguir é um diálogo simples entre um SA (arquiteto de soluções) e usuários de negócios:
Usuário: precisamos de um relatório impresso de todas as transações expiradas nos últimos 30 dias.
SA : quem usa o relatório?
Usuário: ele é usado pelos gerentes.
SA: gerente, como vocês usam o relatório? Precisa ser um relatório, ou o verdadeira pedido é simplesmente para ver as transações expiradas do último mês?
Gerente: só conferimos o relatório uma vez por mês, então, estaria bem assim.
SA: o que vocês procuram ao examinar os dados?
Gerente: procuramos qualquer transação que tenha sido superior a 50 mil dólares e fazemos uma análise mais aprofundada sobre elas.
SA: então, seria útil se o sistema apresentasse apenas transações expiradas acima de 50 mil dólares para análise?
Gerente: sim, isso seria ótimo.
Requisito revisado: os gerentes precisam analisar mensalmente as transações expiradas acima de 50 mil dólares.
Se o arquiteto de soluções não tivesse feito perguntas suficientes, a equipe teria criado um relatório em papel. Sempre pergunte "Por quê?" e chegar a um ponto em que você sente que realmente entende a necessidade.
Resolver requisitos conflitantes
Muitas vezes, diferentes usuários de negócios criam requisitos conflitantes. É fundamental que o cliente tenha alguém que seja decisivo. O arquiteto de soluções pode guiar os participantes para chegar a uma conclusão, propondo ideias e acordos; no entanto, ele não deve se envolver na política corporativa.
Defenda sua perspectiva
Um arquiteto de soluções precisa ser capaz de promover os requisitos de maneira respeitosa. Parte dessa responsabilidade é ser capaz de comunicar claramente a visão da solução que você criou e ajudar o cliente a enter como ela ajuda a atingir seus objetivos. Os arquitetos de soluções iniciantes costumam ter problemas nesse estágio por parecerem condescendentes. Ao promover sua visão para o cliente, evite desprezar as ideias dele.
Exercício: planeje suas sessões de registro de requisitos
Examine as equipes do Woodgrove Bank. Determine quais dessas equipes você agruparia para a coleta de requisitos. Decida quais equipes você não agruparia para a coleta de requisitos. Explique por que você tomaria essas decisões.