Introdução

Raramente os sistemas farão tudo para todas as pessoas. Mas quando tentamos fazer isso, criamos um sistema inchado e caro.

Para atingir o sucesso, os Analistas de Negócios e os participantes do projeto devem convergir para um claro entendimento e concordar com estes três fatores:

• Problema a ser resolvido
• Restrições impostas à equipe de desenvolvimento (custo, cronograma, recursos, regulamentos, etc.)
• Restrições impostas à solução

O desafio de todos os participantes do projeto é criar uma solução que maximize o valor entregue aos Analistas de Negócios, mesmo que sujeita a restrições. O equilíbrio está em fazer uma análise crítica do custo-benefício entre as características desejadas e as decisões de projeto subseqüentes que definem a arquitetura do sistema.

Descobrir o ponto de equilíbrio é desafiador, evasivo e progressivo, porque o ponto de equilíbrio é dinâmico. Quando os sistemas evoluem, as necessidades dos Analistas de Negócios mudam, aparecem novas oportunidades, os riscos são resolvidos, novos riscos aparecem e a equipe de desenvolvimento descobre novas realidades sobre o sistema. Mudanças surgem em todo o ciclo de desenvolvimento. Os Analistas de Negócios e os membros da equipe devem estar preparados para reavaliar seus compromissos, reduzir expectativas e ajustar o planejamento conforme a evolução do sistema.

Práticas

Conheça a sua audiência

Você não terá como realizar compensações com eficiência se você não souber quem são os Analistas de Negócios e o que eles realmente querem.

Conheça seus Analistas de Negócios. Melhor ainda, trabalhe junto com eles e assegure-se que você tenha entendido as suas necessidades. Comece identificando todos os Analistas de Negócios e então mantenha uma comunicação e colaboração aberta e freqüente entre eles e a equipe de desenvolvimento.

Separe o problema da solução

Com freqüência nos precipitamos ao apresentar uma solução sem a devida compreensão do problema. A final de contas, nós aprendemos a solucionar problemas e não a definir problemas, isso é fácil. No entanto, essa forma de pensar limita o seu entendimento do problema, impõe restrições artificiais e dificulta a análise equilibrada, ou mesmo o conhecimento de quais são as alternativas existentes.

Assegure-se de ter entendido o problema antes de definir a solução. Ao separar claramente o problema (o que os clientes necessitam) da solução (o que o sistema deve fazer), nos ajuda a manter o foco apropriado e facilita acomodar as formas alternativas de resolver o problema.

Crie um entendimento compartilhado do domínio

Especialistas de domínio normalmente possuem limitações técnicas; desenvolvedores, arquitetos e testadores normalmente possuem limitações de domínio; e revisores e outros Analistas de Negócios normalmente possuem limitações de tempo para acompanhar o projeto e aprender sobre o domínio do problema. Como resultado, as pessoas possuem, normalmente, um entendimento pobre ou inconsistente do domínio do problema, o que provoca problemas de comunicação e eleva as chances de entregar algo de pouquíssimo valor aos Analistas de Negócios.

Aumente e compartilhe o entendimento de todos sobre o domínio. Um entendimento conciso e compartilhado do domínio do problema melhora a comunicação e a efetividade do projeto. Comece definindo o problema no documento de Visão. Na medida em que você adquirir novos conhecimentos, capture os principais conceitos e terminologias do domínio no Glossário para assegurar um uso compartilhado consistente da linguagem do domínio.

Use os cenários e os casos de uso para capturar os requisitos

Muitas empresas ainda documentam requisitos como uma lista de declarações, que são algumas vezes chamadas de "lista de desejos". Para os Analistas de Negócios, essas listas são normalmente difíceis de entender porque elas precisam que o usuário final leia e traduza mentalmente a lista em uma visualização de como os requisitos irão interagir no sistema.

Use os cenários e os casos de uso para capturar os requisitos funcionais de forma que facilite a compreensão dos Analistas de Negócios. Os requisitos não-funcionais, tais como desempenho, estabilidade ou usabilidade são importantes e podem ser documentados na Lista de Requisitos, usando as técnicas tradicionais.

Estabeleça e mantenha um acordo sobre prioridades

Tomar decisões erradas sobre o que desenvolver depois pode resultar em desperdício de esforço, em liberação de capacidades que nunca serão usadas ou na identificação de problemas tardiamente no projeto (resultando em atrasos e até no fracasso do projeto).

Priorize os requisitos para implementação trabalhando regulamente com os Analistas de Negócios durante a evolução do produto. Faça escolhas que agreguem valor e reduzam os riscos, enquanto se constrói um sistema que possa evoluir.

Faça compensações para maximizar o valor

A análise de custo-benefício não pode ser realizada independentemente da arquitetura. Os requisitos estabelecem os benefícios do sistema para o Analista de Negócios, enquanto a arquitetura estabelece o custo. O custo de um benefício pode influenciar no valor do benefício percebido pelo Analista de Negócios.

Trabalhe com os Analistas de Negócios e com os membros da equipe para priorizar os requisitos e desenvolver arquiteturas candidatas para implementar estas soluções. Use as arquiteturas candidatas para avaliar o custo dos benefícios. Soluções candidatas são consideradas num nível elevado durante a determinação da viabilidade arquitetural. Diferentes perspectivas arquiteturais podem resultar em diferentes estimativas de custo versus benefícios. A arquitetura candidata que forneça a maior cobertura no menor custo é selecionada para o desenvolvimento futuro.

Gerencie o escopo

As mudanças são inevitáveis. Embora as mudanças apresentem oportunidades para elevar o valor para o Analista de Negócios, mudanças irrestritas resultarão num sistema inchado e deficiente e não atende às necessidades do Analista de Negócios.

Gerencie as mudanças mantendo a concordância dos Analistas de Negócios. Os processos modernos sempre gerenciam mudanças, adaptando-se continuamente às mudanças ocorridas no ambiente e às necessidades dos Analistas de Negócios, avaliando o impacto das mudanças, fazendo análise das alternativas, e repriorizando o trabalho. As expectativas dos Analistas de Negócios e dos desenvolvedores devem ser realistas e alinhadas no ciclo de vida de desenvolvimento.

Saiba quando parar

Excesso de engenharia para construir sistemas não só desperdiça recursos, como também eleva a complexidade do sistema.

Pare de desenvolver o sistema quando a qualidade desejada for atingida. Lembre-se que "A qualidade é a compatibilidade com os requisitos". É isto que dá um sentido de término na prática. Separe o problema da solução, assegurando que a solução realmente resolva o problema. Depois que os requisitos críticos forem implementados e validados, o sistema estará pronto para a aceitação dos Analistas de Negócios.