P3: A Modelagem de Negócios
A modelagem de negócios
Para conhecer tudo o que é importante para o projeto em relação à organização é necessário efetuar a modelagem de negócios. Por modelagem não estou me referindo estritamente a modelos gráficos como organogramas ou UML e BPMN, me refiro a conhecer a empresa a partir de várias visões.
Como no projeto de uma casa, você só o entende de verdade se ver a planta, as vistas, cortes, hidráulico, elétrico, sanitário e memorial descritivo. Não é a casa em si, são representações que se limitam a partes importantes para o projeto, por isso chamamos de modelos.
Em uma organização, essas visões passam pelo planejamento estratégico, pelo organograma e pelos diferentes processos.
-“Kerber, é necessário saber tudo isso para fazer um pequeno projeto?“
Não! Voltando para a analogia da casa, se você for reformar uma parede colocando uma janela pode bastar você mapear aquele cômodo dando especial atenção para os eventuais canos e fios que cruzam as suas paredes.
A arte de definir o que é ou não relevante para a construção do modelo chama-se “capacidade de abstração”. Todo a tem em maior ou menor grau e você a utiliza, por exemplo, quando conta uma anedota para seus amigos sem entediá-los com detalhes irrelevantes como o nome do papagaio.
- “Kerber, odeio essas coisas de planejamento estratégico, objetivos, metas, participação em mercado me dá arrepios. Prefiro J2EE, eu mando e ele obedece.”
Amigo, é melhor você criar gosto ou permanecer no lado da solução. Sabe, nenhum lado é mais importante do que o outro e o trabalho dos diferentes profissionais é complementar e igualmente importante, então prefiro ter você trabalhando comigo como analista de sistemas, arquiteto, ou Srcum Master feliz da vida do que do lado de cá resmungando.
Bom, voltando ao pessoal interessado, no “domínio do problema” – é assim que chamamos o estudo do “quê” deve ser feito, infelizmente existe apenas uma pessoa falando sério sobre modelagem de negócios, eu vou falar dela lá no final adiante.
Da estratégia ao requisito - fazendo sentido
Eu falei na seqüência de “por quês” e em seguida pulei direto para a estratégia da empresa. Vamos ver o que está no meio disso partindo de um requisito que digamos, apareceu na sua mesa em um post-it amarelinho:
“Como um caixa da lanchonete, eu posso digitar os pedidos durante a venda e eles vão aparecer na tela lá atrás para o pessoal da montagem.”
Requisito legal hein? O caixa vai digitando o pedido e ele vai aparecendo bem grande em uma fila de pedidos para o pessoal que monta os hambúrgueres e as batatas fritas. Mas de onde ele surgiu?
Bem, é evidente que este requisito está ligado a um sistema. Esse sistema é utilizado para apoiar o processo de venda da lanchonete. Ele ajuda muito, pois permite que pessoas com diferentes responsabilidades tenham informações em tempo real do que está acontecendo além de possibilitar pagamento através de diferentes meios e de guardar registros para a administração. Show de bola. Ponto para os sistemas de informação.
O processo de venda da lanchonete depende de diversos fatores para que ocorra de forma satisfatória. Os ingredientes devem estar à disposição, o atendente deve saber quem do pessoal que lota o balcão deve ser atendido agora, deve haver troco no caixa, a conta de luz deve ser paga, entre outras inúmeras coisas, e como foco do trabalho do pessoal de “Tecnologia da Informação”, a informação deve correr livremente através da tecnologia.
Essa interdependência entre as diferentes funções se chama “nível operacional”. O sujeito que monta a bandeja sabe que o sujeito das batatas entrega novas batatas a cada três minutos, e esse por sua vez sabe que sempre vai ter batatas novas cortadinhas no pote ao lado.
Essa cadeia de níveis operacionais oferecidos de papel em papel somadas formam o famoso “nível de serviço” da lanchonete, que no final define muito da sua competitividade, principalmente se estiver no ramo de “fast” food.
Nível operacional em inglês é “OLA” e nível de serviço é “SLA”, então a equação é: SLA = OLA + OLA + OLA + OLA…
Já deu para notar que o elo mais fraco da corrente pode detonar com o negócio. Uma laranja (ou OLA) podre estraga o suco.
Mas aquele requisito, de onde veio? Da estratégia, oras!
A alta cúpula da lanchonete descobriu através de pesquisas mercadológicas que se conseguisse diminuir o seu SLA médio de entrega de pedidos em pelo menos 8% conseguiria papar mais 5% do mercado. Parece que uma parte dos clientes da lanchonete trabalha com software e estão sempre com pressa para atender aos prazos de seus projetos.
Alguém, imaginamos que o analista de negócios ou quem o acionou, observando o processo notou que gritar os pedidos traz alguns erros que no final acabam atrasando o SLA médio da lanchonete.
Em suma, a modelagem de negócios tem a ver com a compreensão desse elo que começa na estratégia da empresa e que vem descendo até chegar naquele caso de uso ou estória na sua mesa.
Eu sei, no mundo feliz as coisas seguiriam de cara esse caminho ideal, vindo lá da estratégia até chegar à sua mesa, contudo, como todos aqui somos adultos, achei interessante começar o exemplo com o requisito aparecendo do jeito que ele costuma fazer antes de você começar a organizar o processo.
Requisitos são tinhosos, em empresas bagunçadas como as nossas eles costumam pipocar de todos os lados e você às vezes pega ele lá embaixo, quase como código implementado e segue o caminho acima tentando entender “o porquê” dele.
Pode parecer idealista, mas o caminho lógico é de cima para baixo, removendo um pouco da abstração a cada passo. Esse é o objetivo a se seguir.
Falando em abstrações, eu tirei essa teoria do livro do Cockburn, que trata somente sobre como escrever casos de uso eficazes. Ele definiu diferentes níveis de abstração para os casos de uso sendo que os de baixo sustentam os de cima:
• Nuvem – Lá encima, é o nível de serviço (SLA), o que você entrega para o cliente. Seu fluxo é a interação do cliente com a empresa. Em marketing é “a experiência”.
• Pipa – Mais embaixo, é o nível operacional (OLA), mostra como as coisas acontecem dentro da empresa enquanto ela luta para atender o SLA. Essa parte é conhecida como operações.
• Nível do mar – É a funcionalidade do sistema que apóia o usuário na execução da sua parte do processo. Essa parte é conhecida como “aquele maldito sistema”.
Ainda não vou falar de modelagem de requisitos, mas mesmo que você não utilize casos de uso no seu trabalho, essa lógica ajuda muito a conectar as coisas. Se você é agilista, basta colocar estórias no nível do mar. Acho que dá para fazer um paralelo também usando temas e épicos, mas isso ainda está além da minha atual compreensão “ágil”.
Esse trabalho todo, esse levantamento das motivações dos requisitos tem tudo a ver com uma coisa chamada eficácia.
A eficácia é fazer a coisa certa, nadar na direção correta, é o alinhamento, no nosso caso, o alinhamento do nosso projeto com os objetivos da empresa.
Falando em nadar, eu fiz travessias em águas abertas por um tempo e o pessoal desse ramo sabe que saber nadar bem é só parte da equação, levantar a cabeça e saber onde você está e para onde está indo compensando a correnteza é fundamental. Eu era muito bom em fazer trajetórias curvas. Uma prova de 1600 metros nunca acabava comigo nadando menos de 2000.
Aqui vale uma ressalva. Eu comecei falando em solução e pode ter parecido que tudo isso está limitado ao profissional da organização responsável por definir o problema para que a empresa compre uma solução do mercado.
Na verdade esse pensamento se aplica quando o desenvolvimento é interno ou quando o analista de negócios está no fornecedor tentando entender seu cliente para definir bem o problema que sua empresa vai resolver.
Na verdade (2), o fruto do trabalho nem precisa ser software. Talvez outra solução como remodelar a disposição dos equipamentos na lanchonete possa surtir o mesmo efeito, ou melhor. O analista de negócios está fazendo o seu trabalho também quando descobre alternativas às intervenções no software.
Lá no EAN, por exemplo, nosso foco é entender os clientes dos produtos (hardware e software) que desenvolvemos e vendemos.
Como são milhares de clientes, devemos conhecer a realidade do ramo para criar um modelo de cliente que represente o que há de comum entre eles além de estudarmos todas as demandas particulares.
É comum descobrirmos maneiras criativas dos clientes resolverem ou contornarem seus problemas utilizando, mesmo que temporariamente, a versão atual do produto sem alterações no código.
Não se trata de fazê-los engolir o problema, mas de se encontrar uma solução de contorno enquanto a solução definitiva não sai do backlog (no nosso caso, roadmap).
Copiamos isso do gerenciamento de incidentes do service desk da ITIL que por sua vez deve ter copiado isso da medicina. Vai uma morfina aí?
Bem, até agora falei da eficácia da análise de negócios, a modelagem de negócios. Agora é necessário falar sobre o que traz eficiência ao trabalho, que faz você nadar mais rápido, a engenharia de requisitos.