Técnicas:
JAD
Técnica aprimorada pela IBM, digo isso pois qualquer pessoa organizada terá uma organização parecida, já vi isso não vida real.
Consiste em dividir responsabilidades: Temos vários papeis que em resumo são: Facilitador, moderador, corpo técnico, digitador, cliente e usuários.
No caso o Facilitador toma posse da reunião e orienta as conversas num caminho produtivo rumo ao objetivo da reunião, sem deixar que o cliente e os usuários guiem a reunião ao nada;
O corpo técnico composto por analista de negócio e técnicos, discutem uma solução com o intuito de bolar algo aderente ao negócio e tecnologicamente viável de modo a não tomar nenhuma decisão e sim analisar as possibilidades;
Digitador faz algo muito sugestivo, digita tudo que está sendo conversado;
Cliente e Usuários: se degladiam para que o sistema não tenha só a visão estratégica dos gerentes(cliente) muito menos seja cheio de macetes e manhãs para poupar o trabalho dos usuários e gerar algo com pouco foco em coisas produtivas;
Moderador: cuida para que as coisas ocorram no tempo planejado;
RUP
Consiste em criar o As Is e depois o To Be. O analista primeiro entende como é o estado atual do negócio, em seguida bola fluxos to be, que demonstram como será o sistema.
Altamente indicado, pois nos momentos em que o to be está sendo discutido é necessário voltar ao roots para se manter aderente ao que é pratica atualmente e de que maneira o software trará melhorias, evita também que pontos da especificação sejam perdidos.
Processos
Neste ponto temos duas vertentes:
Processo baseado na organização industrial;
Tem base no processo industrial onde há entrada, processo e saída, sendo que a analogia pode ser utilizada perfeitamente para um fluxo de informações onde o dado é consumido, um processo é executado com base neles então uma informação é gerada, os processos ficam encadeados porque uma informação de saída alimenta outro processo e assim por diante;
Processo baseado em BPMN;
Neste processo sinto a falta do fluxo da informação, tudo é baseado em processo e não é fácil enxergar como o dado se transforma em informação ao longo do processo. Trás um mecanismo para registrar as regras referentes aos processos;
Seguindo BPM, esta é uma técnica que analisa gargalos, integrações e propõem uma organização melhor do processo de negócio;
Persona
Em resumo, pois sem pouca coisa deste assunto. É uma técnica que se encaixa muito bem em projetos que desenvolve produtos, ex: Iphone, Pacote Office e etc. Não existe um grupo de usuários que tem o domínio de todas os requisitos do software, desta forma o que há a se fazer é definir persona e interpretá-los, vestir o papel e orientar-se seguindo a necessidade de determinadas personas alvo de venda.
Entrevistas
Já vi esta estratégia sendo usada no mundo ERP, onde a empresa domina o negócio, em alguns casos de maneira melhor que o cliente. Neste escopo há duas estratégias onde pode-se combinar a entrevista com perguntas objetivas e abertas. Vejo que é algo muito de experiência, pois o método não te fala que perguntas fazer.
Mesmo assim este é uma ferramenta que com certeza será combinada com as demais técnicas.
Na pratica a teoria é diferente?
Pois é, na minha tentativa de fazer com que os usuários compreendessem um fluxo de informações por processo para que eles falassem na nossa língua, notei que muita gente além de dificuldade de entender o que nos parece óbvio, há a vontade de cada um de passar este conhecimento da forma que o usuário acha melhor, pois também é o objetivo dele que entendamos e porque não entender como ele se organiza afinal pra ele é mais fácil. Neste conflito vejo cada vez mais que várias maneiras de resgatar o conhecimento esbarram na forma de lidar com pessoas e fica claro que o analista de requisitos, analista de negócio ou seja lá como você queira chamar, deve saber lidar com esses conflitos e não adianta, não há processo nem metodologia que explique detalhadamente como fazer isso.
Bom, do que eu vi a principal qualidade é paciência e compreensão, deixar o usuário falar e estar muito atento às palavras-chaves, pois através delas que você conduzirá a conversa. Você está lidando com o que a pessoa faz na vida, é algo importante, você acha que ela vai contar sem enfeitar, sem te mostrar que é a coisa mais importante do mundo, portanto tenha paciência, ouça e não deixe o usuário se perder, seu principal objetivo é guardar as coisas principais. Quais são as coisas principais?
Bom, vai do feeling do Analista, se o molde será materializado em processo, fluxo de informações ou requisitos o correto é direcionar o que a pessoa está falando neste sentido, deixe claro que você precisa estruturar o que o usuário está dizendo de uma maneira que você e que outras pessoas possam entender, peçam para que ela valide sua forma de entendimento e que compartilhe o mesmo entendimento ao olhar para seu fluxo ou para seu requisito.
Eu prefiro de longe um fluxo de atividades e um diagrama de estado para entidades mais importantes. Além disso algo que surtiu um efeito muito bom foi ter em mente um fluxo macro(Diagrama de Contexto da Análise Essencial) para que você saiba de onde partir e onde chegar em uma conversa de detalhamento de processos, o que lhe ajuda a guiar a conversa com seu usuário , ou seja, até onde parar ou até onde continuar.
Objetivo Final
Bom, o objetivo final é construir um software que esteja de acordo com as necessidades do cliente. Nunca podemos deixar isso de lado, pois inserir um milhão de artefatos e criar outros trabalhos distantes do foco principal é inutil, é inutil discutir ideologias e quem está do lado negro ou do lado da luz, são tantos casos e formas de contratação que não há certo e errado, afinal tanta gente abomina o cascatão e o usam tentando usar a pratica da moda e há casos de sucesso, afinal como é que seria que nossa área se manteria, vejo tantos falando mal do cmmi, me digam como a Índia se tornou uma grande potencia.
Acho que ainda falta muita comunicação entre a área de venda e nós desenvolvedores, enquanto ninguém entender que ambas devem estar sob a mesma asa e que os objetivos devem ser compartilhados, desgastes serão fato.
