Análise de Negócios

Gostei desse "negócio", mas por onde começar?

Engenharia de Requisitos


Em software, o requisito é o problema que o desenvolvedor terá que resolver. O requisito deve ser comunicado de forma clara sendo que o bom requisito é “factível”, “priorizado”, “testável” e por fim “necessário” (eficácia herdada da modelagem de negócios).

Você alcança isso através da engenharia de requisitos.

Se você é do ramo de TI imagino que depois de ler aquelas informações que coloquei na parte sobre modelagem de negócios ao ver esse título deu uma suspirada e se sentiu mais em casa. Isso é normal, requisitos incomodam você há vários anos, mas pelo menos eles são conhecidos. (Isso cheira à síndrome de Estocolmo).

Vou estimar (chute) que 90% das pessoas que procuram a análise de negócios o fazem devido a problemas e experiências traumáticas envolvendo requisitos, muitas delas envolvendo projetos no estilo cascata, nos quais a engenharia de requisitos mal executada é completamente devastadora.

Como grande parte, e posso dizer a melhor parte, do trabalho do analista de negócios é expressada na forma de requisitos, sim, o problema é nosso.

Existe uma série de práticas para se trabalhar com engenharia de requisitos. Vou ser sincero, apesar deles fazerem parte da minha vida há tempos, parece que cada dia descubro algo novo sobre como descobri-los, desenvolvê-los e principalmente comunicá-los.

Solução de um, problema de outro

Aqui chamo a atenção novamente para os domínios do problema e da solução. Essa divisão gera muita confusão, pois dá a impressão de que o analista de negócios não soluciona nada, pois ele se expressa em requisitos que são na verdade o problema que o desenvolvimento vai ter que resolver.

Aqui uso a minha frase preferida: “A solução do negócio é o problema do sistema.”

Ou seja, o analista de negócios trabalha para solucionar problemas de negócio, contudo, as suas soluções costumam gerar problemas para o lado do sistema que precisa ser criado ou adaptado.

O basicão da engenharia de requisitos

O “basicão” da engenharia de requisitos cai nessas categorias que se assemelham ao trabalho de um detetive:

  • Descobri-los
  • Entrevistas (descobre quem sabe e pergunta)
  • Observação passiva (fica olhando o pessoal trabalhar)
  • Observação ativa (põe a mão na massa)
  • Pesquisa documental (raramente existe algo bem documentado, mas você pode descobrir algo importante se fuçar bem)
  • Engenharia reversa (analisar a aplicação rodando, fuçar no código-fonte e no banco de dados)
  • Desenvolve-los
  • Rabiscar, rabiscar, rabiscar
  • Prototipar
  • Discutir
  • Simular
  • Comunica-los
  • Conversas
  • Texto
  • Casos de uso
  • Estórias
  • Texto livre (o sistema deve...)
  • Modelos
  • UML
  • Diagrama de entidades
  • Máquina de estados
  • Diagrama de atividades
  • Diagrama de objetos
  • Workshops

 

Bem, essa lista é bem básica e traz apenas o que eu lembro de cabeça. Se você se amarra nisso, recomendo o BABoK, ele detalha bem cada técnica, ferramenta e fonte de informação. Um trabalho muito mais minucioso do que eu me proponho a fazer nesse texto. Ele é apenas uma conversa, lembra?

Se você trabalha com desenvolvimento pode até pensar agora que isso é tão básico que se fizermos uma boa modelagem de negócios e uma boa engenharia de requisitos (nesses moldes básicos) não há como ter problemas nos projetos. É só empacotar e tocar para o desenvolvimento e ficar esperando o resultado do outro lado, certo? Errado.

No lado da solução temos pessoas que possuem metas próprias, criatividade, conhecimento, motivação e necessidades. Para fazer acontecer é necessário investir em gerenciamento de equipes e engenharia de software sendo que esta começa no requisito não na solução. Então todas as vezes que eu quis trabalhar “eu aqui, eles lá” me dei mal.

Minha intenção era boa, mas ingênua. Eu acreditava que se entregasse os requisitos mastigados para os desenvolvedores eles iriam ficar muito felizes por “não ter que pensar” nessa parte. Me vislumbrava sendo ovacionado por hordas de desenvolvedores felizes.

Entretanto, esse estilo de trabalho não era muito cordial e soava arrogante: “mim desenha, tu executa”. O clima não era bom e aprendi que isso não era a forma certa de trabalhar da pior forma possível quando os desenvolvedores sabotaram um projeto entregando o código mais vagabundo possível.

Foi um lance meio terrorista, mas eu tinha uma boa parcela de culpa nisso. O método deles foi tosco, eu me ressinto por essa irresponsabilidade, mas aprendi. Essa paulada me fez reavaliar as coisas e cheguei a uma ideia que na prática deu bons resultados e que tem a ver com o lado humano das metodologias ágeis, apesar de caber na cascata e em tudo o que existe no meio: “O deliberativo, quem decide e o consultivo, quem opina”.

A ideia é que quando estamos pensando no domínio do problema, no requisito, na solução do problema do negócio, o analista de negócios é o deliberativo. Ele representa o cliente e bate o martelo nessas questões, contudo, o analista de negócios sábio traz o desenvolvedor para perto e aproveita as suas contribuições.

Isso é positivo de duas formas. Na primeira, você faz uso da experiência daquele profissional que pode revolucionar o projeto. Ele(s) pode(m) ter participado de tantos projetos que conhece(m) encrenca só pelo cheiro do requisito. Na segunda forma, você tem o desenvolvedor envolvido no projeto mais cedo (se for cascata) e ele se sente realmente participante e influente no projeto, além do briefing posterior tornar-se quase desnecessário.

No segundo momento temos o domínio da solução, os desenvolvedores encontrando alternativas para atender aos requisitos. Aqui é o domínio deles, eles sabem coisas como, criar as classes de forma que o sistema funcione de forma mais eficiente. Eles sabem que java não vai rodar naquele ambiente. Aqui o desenvolvedor é deliberativo, e o analista de negócios é consultivo. A história se inverte e agora ele conta com o seu conhecimento e experiência e também com o seu envolvimento na equipe. Todos saem ganhando.

Se pegarmos um projeto cascata total, aquele com fases bem separadas já teremos um enorme ganho com essa prática (apesar dela custar horas de desenvolvedor na etapa de definição do escopo e de analista de negócios na etapa de execução).

Essa dinâmica ocorre de forma natural quando o SCRUM é aplicado. As reuniões de planejamento de uma sprint (iteração) fazem com que o responsável por representar o cliente (o Product Owner) e o time de desenvolvimento discutam os requisitos e a solução continuamente, cada um sendo deliberativo ou consultivo ao seu tempo.

Se você trabalha com grandes projetos, recomendo que faça um esforço para diminuir continuamente o tamanho das suas iterações. Os problemas serão detectados mais cedo e a comunicação entre as pessoas será mais frequente e melhor.

Lá encima eu citei alguns artefatos para a comunicação de requisitos. Eu gosto muito de alguns deles e tem horas que parece que só consigo falar da parte estática por meio de diagrama de entidades.

Como eu me sentia confortável me expressando assim, escrevendo casos de uso com maestria acabei ficando tradicionalista, formalista, um verdadeiro poeta parnasiano - também conhecido como “chato”. Comigo era caso de uso ou nada feito, passo a passo, fluxo a fluxo, mas a realidade me fez perceber que o essencial é a comunicação correta dos requisitos e que ela encontra o seu clímax na interação humana apoiada por um pedaço de papel ou um quadro branco.

Isso foi ocorrendo na prática quando vi projetos nos quais os requisitos eram comunicados em forma de frases com textos adicionais anexos andaram melhor do que aqueles que tinham documentos “parrudos”, mas interação humana fraca. Eu incomodei um bocado os agilistas até essa ficha cair.

Ainda existe quem pense que diminuir a quantidade de documentação é diminuir a quantidade de trabalho realizado, contudo, trata-se de redirecionar o esforço para algo que traz mais resultado, a comunicação entre as pessoas.

O papel é uma das formas de comunicação mais limitadas existentes. No papel não temos gestos, expressões visuais, tons de voz e outras mensagens que enriquecem a interação. A única vantagem que o papel possui em relação à interação pessoal se chama “stickness”. Stickness quer dizer que o papel fica. Ele sobrevive ao tempo e as pessoas. Um documento permanece inalterado depois de dez anos, já a memória fica fraca, se confunde.

A resposta para a pergunta “o quanto eu devo documentar?” é “documente apenas aquilo que precisa de stickness”, não mais, nem menos.

Lembro que o meu preconceito (ou seria ceticismo?) com as metodologias ágeis era tamanho que eu cheguei a cunhar a frase “Nem todo agilista é vagabundo, mas todo o vagabundo é agilista”. Na verdade, o pior lugar para um vagabundo tentar se esconder é em um ambiente de entregas constantes e interação pessoal intensa.

Voltando aos domínios

Este esquemático abaixo mostra bem a divisão entre os domínios quando conversamos a respeito de desenvolvimento de software:

Domínio do problema Domínio da soluçăo
Requisito Especificaçăo
Usuário Sistema
Analista de negócios deliberativo Desenvolvedor deliberativo
O que e porque fazer Como fazer e porque fazer assim