Viso pra qu?

GustavoGrillo | Sep 9 2012 |

inShare7

Minha disciplina predileta na engenharia de software sempre foi a de Requisitos. Conhecida por vrios nomes como Gesto de Requisitos, Engenharia de Requisitos e, s vezes, Requerimentos (argh!), essa disciplina representa o ponto onde as coisas podem comear a dar certo ou a dar muito errado. Em Requisitos encontramos uma entidade (ou artefato, ou documento) que transcende metodologias, algo que comum a projetos cascata, projetos baseados no RUP, em Scrum, XP, Agility@Scale e num punhado de outros processos de desenvolvimento: o Viso. Esse ilustre artefato parece permear qualquer projeto de desenvolvimento de software. Figurinha carimbada em inmeros sites, manuais de processo e diretrios de templates na rede. Porm, o que tenho visto em toda a minha carreira que, apesar de ser famoso, ele um grande incompreendido. Quem escreve o Viso? A rea de negcio? O analista de requisitos? O gerente de projeto? O desenvolvedor? Ou um grupo que combine alguns desses papis? Antes de definir quem o responsvel por ele precisamos entender para que ele serve, onde ele usado e, principalmente, quem o usa. O Viso o grande acordo do projeto. Ele deve, em primeiro lugar, ser entendido por todos os envolvidos no projeto. Disso podemos tirar alguns erros comuns:

Viso com dez pginas: o executivo no l; Viso com definies tcnicas demais: a rea de negcio no l; Viso em linguagem de negcio que no explica na prtica o que o Viso com diversos diagramas e explicaes detalhadas de todos os

projeto faz: desenvolvedor no l; requisitos, funcionais e no-funcionais: ningum l. O Viso tem que responder, da forma mais concisa possvel, algumas perguntas:

Qual o problema que este projeto vai resolver? Que tipo de benefcio ele vai trazer? Para quem? Como? Que tipo de funcionalidades o produto final deve prover? Quais os padres, plataformas, exigncias legais e restries em Existe alguma relao deste projeto/produto com outros

geral se aplicam a este projeto? projetos/produtos que valha a pena ser mencionada?

O Viso tem que compartilhar e unificar o que todos entendem sobre o produto. Ele deve ser amplo, mas no restringir a criatividade nas etapas posteriores do desenvolvimento. Isso significa que o Viso no deve ter definies de como as coisas devem ser feitas, apenas o que deve ser feito. Deve ser o mais curto e conciso possvel. Ou seja, depois que ele estiver pronto, resuma-o em pelo menos um tero. Existem vrias maneiras de se elaborar um Viso, mas as melhores emergem da colaborao entre diversos pontos de vista. Agregar diferentes opinies o melhor comeo para criar algo que seja entendido por um pblico amplo. Sempre que voc estiver escrevendo um Viso, ou parte dele, faa o exerccio de pensar em como cada um dos envolvidos no projeto vai interpretar aquilo que voc escrever. No um exerccio muito comum para ns de TI, mas toda comunicao, para ser eficaz, deve levar em conta no s a mensagem que transmitida e o meio (documento word, email, chat, ligao telefnica, etc) onde ela trafega, mas tambm o repertrio, linguagem e contexto de quem recebe essa mensagem. O Viso um dos principais instrumentos de comunicao do projeto, por isso importante que ele seja escrito de forma adequada. Para terminar, uma palavra sobre formato. Durante todo o texto eu usei o termo Viso e no Documento de Viso por uma questo de cuidado, ou trauma pessoal. Quando falamos em um documento de Viso, a primeira imagem que nos vem a cabea um documento word, talvez com algumas instrues de preenchimento em azul itlico. Na verdade, o Viso pode ser um documento word, um post-it colado na parede, uma parte de algum outro artefato ou um texto armazenado em uma ferramenta de ALM (a melhor opo, na minha opinio). Esse cuidado semntico apenas parte da minha luta para dissociar o conceito de artefato do conceito de documento num processador de textos. Boas Vises.