Perguntas e Respostas sobre o livro Book Business Analysis Agility

James e Suzanne Robertson escreveram um livro intitulado Business Analysis Agility - Solve the Real Problem, Deliver Real Value (Agilidade na Análise de Negócios - Resolva o Problema Real, Entregue o Valor Real). No livro, James e Suzanne tratam o fato de que, apesar da adoção de abordagens ágeis, muito tempo, esforço e dinheiro são desperdiçados para construir o produto errado.

Eles exploram os desafios enfrentados na análise de empreendimentos em ambientes ágeis, e abordam alguns dos erros comuns que viram em seu trabalho com organizações em todo o mundo.

O livro é destinado a "qualquer um que tenha interesse em entregar valor real, oferecendo a solução certa para o problema certo".

O livro pode ser comprado aqui e os leitores do InfoQ podem acessar um capítulo de amostra aqui.

James e Suzanne conversaram com a InfoQ sobre o livro.

InfoQ: Por que escreveram este livro, qual é o problema que estão tentando resolver?

James e Suzanne Robertson: Continuamos encontrando uma atitude em que as habilidades de análise de negócios e descoberta de requisitos tornou-se obsoleta nos métodos ágeis. Também continuamos a encontrar equipes ágeis que estavam com dificuldades para fornecer produtos relevantes - principalmente porque não entendiam o verdadeiro problema do negócios do cliente.

Mas vamos analisar isso, muitos clientes não entendem o problema deles. É preciso habilidade e prática para descobrir o problema real. Falhar ao fazer isso, significa que está simplesmente construindo algo que não é realmente relevante. Temos muito software no mundo; não vamos adicionar nada de que não precisamos.

Também o escrevemos para desencorajar a prática de assumir que a primeira solução que vem à mente resolverá o problema. Geralmente, essas soluções assumidas são desenvolvidas sem muita atenção às necessidades de negócios subjacentes. Nós só podemos resolver problemas de negócios se entendermos o problema real antes de construir qualquer coisa. Não há tempo para questionar o problema durante um sprint.

InfoQ: Para quem é o livro - quem deve ler este livro?

James e Suzanne Robertson: Nosso principal alvo são analistas de negócios que trabalham em um ambiente Ágil. Essas pessoas estavam nos perguntando como poderiam usar produtivamente suas habilidades quando a equipe de desenvolvimento estava usando Scrum como um entre outros métodos. Decidimos mostrar como a análise de negócios é conduzida como parte de qualquer processo ágil e como o analista de negócios é parte integrante de qualquer equipe de desenvolvimento.

InfoQ: Vocês argumentam que, apesar da adoção de abordagens ágeis para construir solução errada, ainda assim isso acontece muito. Isso não foi o impedimento para um dos principais impulsionadores por trás de todo o movimento ágil?

James e Suzanne Robertson: Sim, foi. No entanto, os processos ágeis são todos sobre o desenvolvimento do produto. Por exemplo, a maioria dos projetos Scrum começam com um backlog de produto. O problema é que o "produto" neste caso é uma solução. Muito pouco pensamento foi dado ao problema sob a suposição de que a equipe de desenvolvimento, ou o cliente, sabe exatamente qual é o problema. Isto provou ser uma suposição insegura.

InfoQ: Processos ágeis criam um grande ponto de envolvimento constante com o cliente. Isso não resolve a questão de encontrar o problema certo?

James e Suzanne Robertson: É claro que é bom estar envolvido com o cliente. No entanto, não se descobrirá o problema do cliente sentado na frente de uma tela. Tem que se esquecer as soluções do momento e ir ver o trabalho do cliente - chamamos isso de "observação criativa" - e entender o que eles estão tentando alcançar. Esse é um resultado comercial e, até se entender o trabalho do cliente, sua motivação, suas habilidades, provavelmente não o encontrará.

InfoQ: Você diz no livro que "entregar uma solução não é o mesmo que entregar valor" - por que tantas pessoas e organizações entendem isso errado?

James e Suzanne Robertson: Excesso de entusiasmo. A expressão "fluxo constante de valor para o cliente" tornou-se sinônimo de "estamos entregando software regularmente, portanto, isso deve ser valioso".

O software não é valioso, a menos que resolva o problema do cliente e o cliente queira que você o resolva. Sem alguma investigação e compreensão do problema real, não há como dizer se o software fornecido é valioso. Simplesmente porque um usuário diz que é o que ele quer, não o torna valioso para o negócio.

InfoQ: Quais são as principais diferenças entre a análise ágil de negócios e a análise de negócios tradicional?

James e Suzanne Robertson: O analista de negócios ágil (note o pequeno "a") trabalha em sincronia com o proprietário do produto e os clientes. A priorização é a maior parte disso, e o ágil BA não está tentando construir uma especificação completa, mas estudar as partes do problema do cliente que são consideradas as peças de maior valor do quebra-cabeça. Valor aqui significa entregar a maior vantagem.

InfoQ: Quem é responsável por realizar análises de negócios em uma iniciativa ágil?

James e Suzanne Robertson: Todo mundo. Só porque não se tem alguém em sua equipe com o título de "analista de negócios" (por exemplo, o Scrum não prescreve uma função ) não significa que a necessidade de análise de negócios desaparece. É tão importante quanto sempre foi. No entanto, agora isso pode ser feito por pessoas que não são chamadas de analistas de negócios, e podem não pensar em si mesmas como uma.

Independentemente de como o papel é chamado, há uma necessidade de estudar o problema do cliente, o que eles estão precisando alcançar, quais são suas aspirações, o que eles valorizam. Isso é o que os analistas de negócios tradicionais fazem, e deve haver habilidades analíticas dentro da equipe para fazê-lo.

InfoQ: Onde a inovação e a criatividade entram na solução do problema certo?

James e Suzanne Robertson: Em dois lugares: um deles é em identificar o problema. As pessoas não sabem necessariamente qual é o problema delas. Às vezes, eles se fixam em uma solução para o um problema declarado e o perseguem. Às vezes, é necessário criatividade e imaginação para investigar com profundidade suficiente e encontrar o problema subjacente. A segunda necessidade é na inovação - tenha em mente que a inovação é um "pensamento novo" - é encontrar a solução certa para o problema. Normalmente existem diversas soluções corretas, é a mente inovadora que continua a encontrá-las até que um candidato excelente apareça.

Uma das coisas sobre as quais falamos no livro é gerar várias soluções candidatas em forma de esboço. Obviamente, a inovação ajuda muito aqui. Se alguém está resolvendo um problema de forma criativa, provavelmente está questionando o problema ao mesmo tempo. Isso é exatamente o que queremos que aconteça.

Em seguida, fazemos uma série de sondagem seguras para falhas a fim de examinar a solução e, ao mesmo tempo, questionar os clientes se isso está resolvendo o problema, se está produzindo o resultado correto? Está sugerindo que o problema pode ser diferente daquele que esta solução candidata resolve? E esse candidato pode resolver um problema melhor? Um que é mais benéfico para o cliente.

Tudo isso é criativo, e precisa ser feito caso esteja levando a sério a solução do problema de negócios do seu cliente.

InfoQ: Você distingue entre o "espaço do problema" e o "espaço da solução" - por que eles são diferentes?

James e Suzanne Robertson: O espaço do problema é o trabalho que está sendo feito pelo cliente. Digamos, por exemplo, que esteja vendendo ingressos em um sistema de metrô. Então, digamos que examinemos esse espaço problemático por algum tempo e decidamos, com o cliente, que parte de seu problema é mais valiosa, e essa é a parte com a qual decidimos conjuntamente entregar uma solução. Isso pode ser dito, a venda real dos ingressos, e deixamos de lado a parte de relatórios e gerenciamento de tráfego do problema.

Pode acontecer que, quando estamos analisando soluções candidatas, descobrimos que existe um problema que também podemos resolver para o cliente e que não fazia parte do espaço original do problema. Nesse caso, o espaço da solução altera o espaço do problema. Digamos, por exemplo, que descubramos que, em vez de vender um bilhete de cartão inteligente, os viajantes podem usar seus cartões de débito para entrar e sair do sistema de metrô. Isso amplia o espaço do problema em cobrir a comunicação com os emissores de cartões de débito e assim por diante.

Dito isso, geralmente o espaço da solução é o mesmo ou um pouco menor que o espaço do problema.

InfoQ: Muitos de seus conselhos parecem estar por aí sendo usados em "eventos de negócios" para mapear e sequenciar o trabalho - o que é um evento de negócios e por que isso é tão importante?

James e Suzanne Robertson: Trabalhamos em grandes problemas. É claro que existem pequenos esforços de desenvolvimento, mas principalmente um projeto em que qualquer um dos leitores esteja trabalhando vai entregar algo significativo. Isso significa que existe a necessidade de particionar ("dividir com cuidado") o problema em partes menores, adequadas para o estudo.

Um evento de negócios é um acontecimento significativo, geralmente acontece fora do espaço do problema, o que causa uma resposta significativa. Por exemplo, no sistema Metro mencionado acima, um viajante solicitando um bilhete de cartão inteligente é um evento de negócios. Ele veio de fora e o espaço do problema deve responder a ele - pegue o dinheiro, adicione-o ao smart card, emita o cartão, registre a transação e assim por diante.

Ao particionar o problema em eventos de negócios, o analista de negócios pode trabalhar neles um de cada vez. As respostas aos eventos de negócios são discretas - elas não têm conexão funcional com outros eventos de negócios - e, portanto, podem ser estudadas de forma isolada.

A mesma propriedade também permite que o desenvolvimento seja feito, mais ou menos, um evento de negócios de cada vez. A solução para um evento de negócios é uma entrega útil, autônoma (dentro do razoável).

Também fazemos uso de eventos de negócios quando criamos um mapa de história. Ou é possível pensar nisso como construir um backlog de um evento de negócios de cada vez.

InfoQ: Você lista algumas técnicas e ferramentas no livro - quais são algumas delas e porque os profissionais ágeis de análise de negócios precisam usá-las em todas as iniciativas?

James e Suzanne Robertson: Embora falemos de ferramentas e técnicas, somos agnósticos sobre quais deles o analista de negócios usa. Gostamos de pensar que a agilidade inclui a adaptabilidade e que o analista de negócios ágil é capaz de selecionar as ferramentas e técnicas apropriadas no momento. Não pretendo ignorar a questão, mas para nós a agilidade é muito mais do que seguir um método Ágil. Analistas ágeis são capazes de se adaptar à situação e usar o que for adequado a ele e ao cliente.

InfoQ: O que mais poderia nos dizer?

James e Suzanne Robertson: Nós fizemos um vídeo que explica muito do livro. Possui 2 minutos e 30 segundos.

Sobre os autores do livro

James Robertson é analista de negócios, solucionador de problemas, autor, palestrante, instrutor, fotógrafo, designer, coach. Ele iniciou como arquiteto, mas deixou isso para uma carreira em TI e o lado sociológico da tecnologia. Ele deixou a segurança do emprego na Austrália para se mudar e começar sua própria empresa (com sua esposa brilhante) no Reino Unido. Desde então, ele foi co-autor de sete livros, vários cursos, as técnicas e modelos de requisitos Volereque foram adotados por organizações em todo o mundo como seu padrão para coleta, descoberta, comunicação, rastreamento e especificação de necessidades de soluções.

Suzanne Robertson está tendo uma carreira estelar em tecnologia da informação e engenharia de sistemas. Ela é professora, praticante, escritora, instrutora e guia. A Suzanne é pioneira na adaptação de ideias de outros domínios para soluções automatizadas. Ela colaborou em workshops usando especialistas de áreas tão diversas quanto música moderna, visualização e culinária. Idéias desses domínios foram adaptadas para fazer grandes avanços em idéias criativas para domínios que vão do controle de tráfego aéreo ao governo local. Ela é co-autora do best-seller Mastering the Requirements Process, entre outros livros e cursos. Ela é co-criadora das técnicas de requisitos Volere. Ela foi a editora fundadora da coluna Requirements in IEEE Software.