quarta-feira, 7 de março de 2007

Escopo



Não, não é um ectoplasma. Foi coisa da aula de hoje, mesmo.


Essa imagem, que foi cuidadosamente digitalizada utilizando métodos avançados do Paint Enterprise Edition, mostra um modelo básico de como o Analista de Negócios define um escopo para desenvolvimento de uma solução.

Na prática, é uma imagem que todo mundo que fez um sistema na vida já presenciou: o cliente (stakeholder, interessado, o cara que paga, enfim...) tem um problema de tamanho X - a área vermelha. O Analista de Negócio vai lá e vê que não é bem assim, e sugere que o escopo da solução seja a área azul. A área vermelha que não será implementada tende a ser o requisito sem importância ou sem tempo/recurso para ser desenvolvido.

Em contrapartida, como o Analista é uma pessoa boazinha, propõe coisas "a mais" a serem implementadas. Algumas melhorias não imaginadas pelo cliente. Claro que provavelmente serão melhorias que de certa forma já devem estar prontas lá na fábrica de software, e facilmente anexadas ao produto, senão não faria sentido.

Apesar de simples, existem algumas armadilhas aí. Quando é definido o que fica "fora", provavelmente alguém ou alguéns no cliente vai ficar insatisfeito, é é muito importante saber quem são esses alguéns, e o quão insatisfeitos eles vão ficar. Por outro lado, não se deve oferecer facilidades a mais sem a certeza de que isso não vai gerar custos que não serão cobertos.


Nenhum comentário: