Concept: Balance competing priorities to maximize stakeholder value

Introdução

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

Assim, os participantes do projeto e stakeholders devem se colaborar para desenvolver uma solução que maximize os benefícios para os stakeholders e atenda as restrições impostas ao projeto. O processo de alcançar este equilíbrio é dinâmico porque tanto os stakeholders quanto os participantes do projeto aprendem mais sobre o sistema, sobre suas prioridades e suas mudanças de restrições.

Para atingirmos o sucesso, stakeholders e 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)
Restrições impostas à solução

Coletivamente, estes três itens representam os requisitos para o desenvolvimento do sistema. O desafio de todos os participantes do projeto é criar uma solução que maximize o seu valor para os stakeholders, mesmo que sujeitos a restrições. O equilíbrio está em fazer uma análise crítica do custo-benefício entre 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. Enquanto os sistemas evoluem, os stakeholders precisam de mudanças, aparecem novas oportunidades, os riscos são resolvidos, novos riscos aparecem, e a equipe de desenvolvimento descobre novas realidades sobre o sistema. Desafios surgem através do ciclo de desenvolvimento. Assim, stakeholders e desenvolvedores devem estar preparados para reavaliar seus compromissos, reduzir expectativas e ajustar o planejamento conforme a evolução do sistema.

Práticas

As próximas seções descrevem as práticas associadas a este princípio.

Conheça a sua audiência

Você não terá como realizar análises de custo-benefício com eficiência se você não souber quem são os stakeholders e o que eles realmente querem.

Assim, conheça seus stakeholders. Melhor ainda, trabalhe junto com eles e assegure-se que você tenha entendido as suas necessidades. Comece identificando todos os stakeholders e então mantenha a comunicação e a 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 nosso entendimento do problema, impõe restrições artificiais e dificulta a análise equilibrada, ou mesmo conhecimento de quais são as alternativas existentes.

Assim, assegure-se que você tenha 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 testers normalmente possuem limitações de domínio; e revisores e outros stakeholders normalmente possuem limitações de tempo para finalizar o projeto e aprender sobre o domínio do problema. Conseqüentemente, 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 liberar algo de pouquíssimo valor aos stakeholders.

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

Use cenários e use cases para capturar os requisitos

Muitas empresas ainda documentos requisitos como uma lista de declarações, que são algumas vezes chamadas de “lista de desejos”. Normalmente, os stakeholders têm dificuldades de entender essa lista, porque eles querem que os usuários finais leiam a lista e mentalmente a traduzam numa visualização de como os requisitos irão interagir com o sistema.

Assim, use cenários e use cases para capturar os requisitos funcionais de forma que facilite a compreensão dos stakeholders. Os requisitos não-funcionais, tais como desempenho, estabilidade e usabilidade são importantes e podem ser documentados nos Requisitos Suplementares, usando técnicas tradicionais.

Estabeleça e mantenha um acordo sobre prioridades

Tomar decisões sobre o que desenvolver depois, com poucas informações, 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 o que resulta em atrasos e até falhas de projeto.

Assim, priorize os requisitos que serão implementados trabalhando regulamente com os stakeholders 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 análises para maximizar o valor

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

Assim, trabalhe com os stakeholders e desenvolvedores para priorizar os requisitos e desenvolver arquiteturas candidatas para implementar as 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.

Gerenciamento do escopo

Mudanças são inevitáveis. Embora as mudanças apresentem oportunidades para elevar o valor para o stakeholder, mudanças irrestritas resultarão num sistema inchado, deficiente e inadequado para atender às necessidades do stakeholder.

Assim, gerencie as mudanças mantendo a concordância dos stakeholders. Os processos modernos sempre gerenciam mudanças, adaptando continuamente as mudanças ocorridas no ambiente e adequando as necessidades dos stakeholders, avaliando o impacto das mudanças, fazendo análise das alternativas, e repriorizando o trabalho. As expectativas dos stakeholders e desenvolvedores devem ser realísticas e alinhadas conforme o ciclo de desenvolvimento.

Saiba quando parar

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

Assim, pare de desenvolver o sistema quando a qualidade desejada for atingida. Lembre-se que “A qualidade está na compatibilidade com os requisitos” [CRO79]. É isto que nos dá um sentido de término para a prática. Separe o problema da solução, assegure que a solução realmente resolve o problema. Depois que os requisitos críticos forem implementados e validados, o sistema estará pronto para a aceitação do stakeholder.