+Requisitos do Negócio | Exemplos

No artigo anterior vimos conceitos básicos sobre requisitos do negócio. Hoje veremos alguns exemplos.

Na introdução desta série foi apresentado o caso da empresa ACME que servirá como base para todos os exemplos¹. Ele é repetido abaixo, de forma melhor estruturada:

  • Perspectiva Financeira:
    • Aumentar faturamento em 30%. Prazo: 2 anos
  • Perspectiva Clientes:
    • Aumentar base de clientes
  • Perspectiva Processos:
    • Tornar as visitas mais eficientes
      • Reduzir tempo de duração de uma visita
      • Aumentar número de visitas (de 15 para 24/dia)
    • Tornar as visitas mais eficazes
      • Aumentar número de negócios fechados
      • Aumentar valor médio das vendas
  • Perspectiva Aprendizado e Desenvolvimento
    • Como tornar as visitas de vendas mais eficazes?
    • Como tornar as visitas mais eficientes?

Quanto luxo!, você diria. Afinal, quantas empresas você conhece que apresentam suas necessidades na forma de um Balanced Scorecard (BSc)? Minha intenção com o exemplo acima é outra. É mostrar que esta ferramenta pode compor o cinto de utilidades de um analista mesmo em organizações que não fazem uso dela. Além de relativamente simples, o BSc é útil na busca pela verdadeira raiz de um problema (ou real motivação de um projeto). Acompanhe o diálogo abaixo :

S: Precisamos de um sistema que torne nosso processo de vendas mais eficiente e mais eficaz.

A: Por favor, defina eficácia.

S: Número de negócios fechados, principalmente. Mas também miramos um aumento no valor médio das vendas.

A: E o que significa um processo de vendas mais eficiente?

S: Seria um que possibilitasse um número maior de visitas. Trabalhamos com a possibilidade de um aumento de aproximadamente 50%. Menos tempo seria gasto em cada cliente e mais clientes seriam visitados.

A: Quantas visitas cada vendedor realiza hoje?

S: Mais ou menos quinze. Acreditamos que um bom sistema viabilize o aumento para cerca de vinte e quatro visitas.

A: Resultando em mais visitas aos mesmos clientes ou em novos clientes?

S: Em novos clientes, claro! Hoje não atendemos parte considerável das zonas norte e oeste. E para lá que precisamos crescer.

A: Aumento que pode ou deve se refletir no faturamento, certo?

S: Claro! Nossa intenção é um ganho de 30% em um prazo de dois anos.

O diálogo acima tenta ilustrar a lógica de construção de um BSc. Ele se desenvolve em ordem inversa e o analista tenta chegar na grande motivação para o projeto (no caso, um aumento de 30% no faturamento). Existem ferramentas de uso mais genérico que têm o mesmo objetivo. Uma das mais conhecidas se chama 5 Whys e  foi inventada na Toyota. O nome vem da sugestão de que são necessários, em média, 5 “porquês” para que se alcance a raiz de um problema.

Vejamos agora como esse papo poderia se desenrolar com a aplicação das questões sugeridas no capítulo anterior:

A: Qual ou quais problemas você precisa resolver?

S: Precisamos tornar nossas visitas de vendas mais rápidas e mais eficazes. Ou seja, preciso que meus vendedores façam um número maior de visitas por dia e também que vendam mais em cada cliente.

A: O que vocês estão buscando? (Qual a motivação para solução destes problemas?)

S: Acreditamos que podemos atender um número bem maior de clientes. Hoje praticamente não atuamos nos bairros um pouco mais afastados das zonas norte e oeste. Se nossos vendedores forem mais produtivos, então poderemos cobrir uma área bem maior.

A: Uma base maior de clientes pode significar mais faturamento…

S: Nossa meta é aumentar o faturamento em 30%.

A: Não bastaria contratar mais vendedores? (Qual solução está fora de cogitação? Por quê?)

S: Não, por favor, não! Você já gerenciou vendedores? Sabe o quanto é difícil? Isso também significaria comprar e administrar mais carros e mais celulares… Definitivamente, não pretendemos aumentar o número de vendedores. O que nós queremos, isso sim, é que eles sejam mais produtivos.

A: Mesmo com esse trânsito caótico?

S: É aí que vocês entram, não? Afinal, tecnologia é inventada para tornar nossas vidas menos ordinárias, certo?

Não há uma estratégia ou formato de entrevista melhor ou pior. Nos dois exemplos acima conseguimos resultados semelhantes (e furos idem!). O importante é que haja uma estratégia e que o entrevistador sempre busque pela motivação principal de um projeto. Porque, no final das contas, um projeto só será considerado um sucesso se este grande requisito – o fato motivador – for plenamente atendido.

E o que fazer se o fato motivador aparecer de imediato, logo na primeira resposta do solicitante? Percorremos o caminho natural do BSc, tentando entender como a empresa espera alcançar o objetivo colocado. Recomendo a lógica do BSc porque ela permite a cobertura das questões mais relevantes. Veja:

  • Perspectiva Financeira: Quanto a empresa espera ganhar (ou economizar) com isso?
  • Perspectiva dos Clientes: O que os clientes receberão de diferente? Ou estamos falando de novos clientes?
  • Perspectiva dos Processos: O que deve ser mudado no trabalho atual de forma a atender novos clientes ou levar coisas novas para os clientes atuais?
  • Perspectiva do Aprendizado e Desenvolvimento: o que devemos aprender e desenvolver de forma a mudar nossa forma de trabalho (nossos processos)?

Como colocado no início desta série, é nesta última perspectiva que representamos os novos projetos. “Desenvolver um sistema de automação da força de vendas” é uma possível resposta que apareceria ali. É o momento em que normalmente nós de TI somos envolvidos. Insisto: não faremos um bom trabalho se não buscarmos a motivação verdadeira. Ninguém pede um sistema por pedir. Bom, pelo menos ninguém em sã consciência e com boas intenções.

Nada de Duplos, Triplos ou Infinitos Sentidos

Se ambiguidade é nociva para qualquer tipo de requisito, para os requisitos de negócio ela pode ser fatal. Os exemplos acima estão repletos de solicitações ambíguas: Aumentar a base de clientes de quanto para quanto? Quanto tempo dura uma visita? E qual seria o tempo aceitável? Qual é o valor médio das vendas atuais? E qual seria o valor ideal?

A boa notícia é que este tipo de ambiguidade é fácil de matar. Com base em números correntes, que nem precisam ser muito precisos, os representantes do negócio podem projetar suas necessidades e desejos. Por exemplo: se uma visita leva em média 20 minutos (quando bem sucedida, ou seja, quando resulta no fechamento de uma venda), é factível supor uma visita com duração de 15 minutos?

Temos em mãos um exemplo que prova de maneira inequívoca o valor da modelagem de negócios. É incrível, mas até hoje recebo profissionais que dizem “eu não faço modelagem. Meu trabalho começa nos requisitos”. Por não entender a simples operação ilustrada ao lado, seguem produzindo requisitos de qualidade questionável, para dizer o mínimo. Vamos lá: ao subtrair a situação atual (as is) do modelo projetado (to be) obtemos os requisitos. Conta boba e óbvia, não? Então por que ela ainda causa tanta surpresa?

Um velho e bom fluxograma pode mostrar com razoável precisão como um vendedor gasta 20 minutos em cada visita de venda. Dados o número de vendedores (20) e a variabilidade do processo (o processo pode mudar dependendo do perfil do cliente), o analista deveria optar pela observação direta como método de estudo. Ele acompanharia 4 ou 5 vendedores munido de um cronômetro e de algo que lhe permita rabiscar diagramas e notas.

Cronômetro? Rabiscos? Fluxogramas?!? Minhas caras e meus caros: se essas ferramentas resistem, ainda que com nomes (BPMN) e formatos (BPMN!) mais modernos e bonitinhos, é porque não inventamos nada melhor. E se este trabalho lembra muito o trabalho dos extintos analistas de organização e métodos não é mera coincidência. É pura necessidade!

Nosso caso específico apresenta como um dos maiores desafios o ganho de produtividade dos vendedores. Além da grana, será necessário medir o tempo gasto em todos os processos relacionados. E a medição in loco é a melhor maneira de eliminar ambiguidades e falsas suposições.

Aliás, vale a pena destacar que os métodos de observação estão ganhando espaço novamente. Trabalhos como Subject to Change (Peter Merholz et al – O’Reilly, 2008) e Change by Design (Tim Brown – Harper Business, 2009) ilustram a criticidade desses métodos para o desenho de sistemas e produtos. Fabrício Teixeira², também das áreas de UX (User eXperience) e design, escreveu sobre isso recentemente. Gerald Weinberg já apresentava sugestões bastante parecidas no distante 1990, no livro Redefinindo a Análise e o Projeto de Sistemas (McGraw-Hill).

Agregando Perspectivas

Poucos projetos podem ser piores do que aqueles originados de uma única cabeça. Um projeto saudável considera a perspectiva de diversas pessoas. No entanto, como nos ensinam Gause e Weinberg³, “cada novo ponto de vista produzirá um novo desajuste”. Porque interpretações e requisitos conflitantes surgirão. Porque novos desejos, necessidades e restrições serão manifestados. Ainda assim, devemos buscar (o quanto antes!) por novas perspectivas.

Imaginem um dos vendedores da ACME, o Gracindo, entrando na conversa:

V: O Dilermando (gerente entrevistado anteriormente) acha que somos preguiçosos, né? Mas ele já foi pra rua comigo e viu como é duro o nosso trabalho.

A: Não é isso. Ele acredita, e nós também, que é possível aumentar a produtividade de vocês vendedores. E, pense só, sua comissão pode aumentar em até 50%!

V: Será? Sei não. Talvez eles mudem a política. Já ouvi falar em premiação dos mais produtivos e coisa e tal…

A: Mas a premiação de uns não significará a penalização dos outros. Questão de meritocracia. Sejamos mais objetivos: Gracindo, o que te impede de visitar mais clientes?

V: Tirando os congestionamentos? A lenga-lenga de alguns clientes. Nossa venda tem que ser feita na hora. Conferimos o estoque de um cliente e sugerimos a reposição. Tem uns poucos que são bem rápidos, aceitam nossa sugestão e pronto. Mas tem outros… até parece que estão decidindo uma compra de milhões de reais. Pensam, pensam, pensam… e no fim, na maioria das vezes, acabam alterando muito pouco as quantidades que sugerimos.

A: E sobre a possibilidade de vender mais nos clientes atuais, você acredita nela?

V: Nem um pouco. A menos que a gente atualize e aumente nossa carteira de produtos.

O diálogo acima não ilustra apenas a resistência do Gracindo, que é comum e natural. Ele também está questionando a viabilidade de um dos requisitos de negócio apresentados (aumentar o valor médio das vendas). Seu ponto de vista será considerado? O que o Dilermando pensa sobre isso? E os outros vendedores?

Outro ponto que merece toda a atenção: Gracindo teme por mudanças (nunca cogitadas oficialmente) em regras de negócio que tratam do cálculo das comissões. De onde veio essa informação/fofoca? E o que há de verdadeiro nela?

Novos pontos de vista = novos desajustes.

Testes e Dúvidas

Cada evento de aprendizado e desenvolvimento de requisitos deve ser imediatamente seguido de uma bateria de testes. Desta forma caçamos ambiguidades, contradições e dúvidas. Relaciono abaixo dúvidas que criei e ainda não consigo resolver:

  • O aumento de 30% dos lucros é factível?
  • Esta meta esconderia outro problema?
  • Se a ACME pretende aumentar o número de clientes atendidos através do aumento da produtividade dos vendedores, então por que ela buscaria também um aumento do valor médio das vendas? Seria este último requisito uma “forçada” de barra? Se sim, qual o objetivo?
  • Gracindo nos leva a crer que Dilermando desconfia dos vendedores. Eles seriam “preguiçosos”? Dilermando pretende fiscalizá-los de alguma maneira? O controle e o papo sobre “meritocracia” (não confirmado) seriam formas de motivação extrínseca e forçada?
  • Ou Dilermando quer apenas o bem de todos e a felicidade geral da nação? Que tipo de pressão ele sofre? É ele o real demandante do projeto ou a coisa veio “de cima”?

Artigos mais curtos!, prometeu este que vos escreve. E agora empurra-lhes pouco mais de 2000 palavras. Peço desculpas, mas não vi muito sentido em entregar a história acima em pedaços. E as redundâncias (e eventuais contradições) têm fins didáticos.

Farei o possível para manter o padrão de um artigo com exemplos seguindo um de conteúdo teórico. Sendo assim, o próximo capítulo retoma a teoria. E leva o papo para longe: precisamos conversar sobre Informação, Ferramentas Sociais e… Conversas! Espero não espantá-la(o). Inté!

 

Notas

  1. Acho que nunca um caso foi tão sugado. Como o inteligente gerador de artigos relacionados mostra abaixo, a história que ilustra esta série não é inédita. Já apareceu aqui e em diversos treinamentos que apresentei como “O Caso do Seu Moreira”. Se finalmente resolvi encerrar a história (com exemplos!) é porque estou em vias de aposentá-la. Os treinamentos que lanço no próximo mês, inclusive o {FAN} 2013, contarão um novo caso.
  2. Não tem muito tempo que comecei a acompanhar o trabalho do Fabrício. Não perco um post, mesmo quando é de caráter mais técnico. Várias leituras, particularmente das rápidas entrevistas que ele faz com outros profissionais da área, sempre me jogam no mesmo lugar: por que a comunidade de AN é tão diferente? Por que nossos papos parecem um tanto mais pobres e repetitivos? Não é desprezível a sobreposição entre as macrodisciplinas AN e UX. Por isso a diferença entre comunidades e profissionais me parece ainda mais gritante e incômoda.
  3. Seus Olhos Estão Abertos? – Donald C. Gause e Gerald M. Weinberg (Makron Books, 1992).

 

Comentários

6 respostas a “+Requisitos do Negócio | Exemplos”

  1. Avatar de Flavio

    Grande PV, sempre com as provocações úteis.

    Esse trecho do artigo me lembrou as minhas aulas de OSM (Organização, Sistemas e Métodos):

    […]analistas de organização e métodos[…]

    Fiz alguns cursos de BPM e BPMN e como diriamos em Minas; “cá pra nóis”: Esses caras são os mesmos de 20 anos atrás, só que de termo, sem prancheta e com metodologias recicladas.

    Sobre o artigo:

    Essa importância da modelagem é sem dúvidas é uma ótima abordagem, e acho que todo consultor honesto deveria fazer algo do tipo antes de sair aceitando qualquer tipo de trabalho por aí.

    Sobre as visões de cada um, acho que dispersão de expectativas é algo que eu vejo como muito comum; e a proposta de agregação de perspectivas pra mim é uma boa novidade.

    Abraços!

    1. Avatar de pv
      pv

      Fala Flavio!

      Como coloquei no artigo, a “coincidência” com análise de O&M é uma necessidade. Só espero que a gente entenda porque essa função foi extinta e evite os mesmos erros. Pelo andar da carruagem, tenho cá minhas dúvidas…

      BPM ainda não disse a que veio, né? Esta é a minha impressão. Ou tá agarrada em caixinhas ou perdida em teorias. Se se limitar a replicar o papo O&M (em nível baixinho) não provará nunca o seu valor. Já escrevi sobre isso aqui antes, sobre a inexistência de organizações orientadas a processos. Não creio na viabilidade da proposta BPM em nenhum cenário diferente.

      Sobre modelagem: não é, pelo menos não era para ser, uma “abordagem”. É, em minha opinião, a única forma de ver e justificar a disciplina Modelagem de Negócios.

      Acho que ainda não cheguei na “proposta de agregação de perspectivas”, mas se você já a anteviu, tanto melhor.

      Forte abraço! Muito obrigado pela participação.

      Paulo Vasconcellos

  2. Avatar de Jean
    Jean

    Fala Paulo

    Ainda em tempo e pondo a leitura em dia. Este artigo foi perfeita sintese do que você havia falando a tempos. Os exemplos estão ótimos. Parabéns.

    Sobre esta questão das dúvidas que você citou no final do artigo. Não vejo grandes chances de um AN descobrir explicitamente o que está por trás dos requisitos de negócio.

    Seria ele o melhor responsável por questionar as metas que guiarão um projeto? Vejo ele em um modo “read-only”.

    PORÉM, quando ele começa a trabalhar com as diversas perspectivas do projeto, ele começa a entender o jogo de forças que envolvem o projeto e PODE descobrir as reais motivações dos objetivos de negócio. Mas não vejo isto como regra.

    (Falando em poder: Você conhece o livro “Jogos Políticos nas Empresas”? Fui recomendado a ler.)

    Abraço!

    1. Avatar de pv
      pv

      Fala Jean!

      Como você pediu exemplos por aqui, estava sentindo falta de sua participação.

      Sua colocação sobre aqueles últimos questionamentos pode nos levar longe. Existem duas visões bastante antagônicas que pululam por aí (explicitamente aí, em Sampa). Uma delas diz que o AN é estratégico, mora lá em cima e leva esse tipo de papo na boa. Outra, implantada em diversas empresas, tem o AN como reles tirador de pedidos que, se entendi bem, faz o que você chamou de ‘read only’.

      Em minha visão, este cara é operacional. Não mora lá cima. Por outro lado, não vejo como ele pode fazer bem seu serviço se não fizer questionamentos como aqueles que encerram o artigo. Se não ele, quem?

      Se ele deixar para descobrir algumas verdades DURANTE o projeto, pode ser tarde demais…

      Não, não conheço o livro.

      Obrigado pela participação. Abraços!

      Paulo Vasconcellos

      ps: Como você gostou deste exemplo, acha que eu deveria seguir com esta história?

  3. Avatar de Jean
    Jean

    Pensando neste cara que mora “lá em cima”, talvez ele tenha outro nome. Não tenho visto nas empresas que visito este AN lá de cima.

    Fico pensando mesmo no AN oriundo de TI ou da área de projetos (eles chamam assim) questionando a meta a ser atingida com aquela iniciativa de projeto. Como ele poderá justificar o questionamento sem acesso às informações da área de negócio que foram responsáveis pela geração da demanda…

    Mas vamos pensar que ele foi corajoso e desafiou e conseguiu as informações…E viu que não é factível…

    O que você imagina que ele faria numa situação destas? Não ficou claro o que você imagina que ele faria com esta informação.

    (A série é ótima pra quem tá querendo exercitar conceitos!)

    1. Avatar de pv
      pv

      Jean,

      Que fique claro: também nunca vi um AN que mora “lá em cima”. Como escrevi, esta é a visão de algumas pessoas da área. Evidentemente, não implantada.

      Como ele justifica o questionamento? Caramba, é função dele! E não é ou, melhor dizendo, não deveria ser uma questão de coragem.

      Se um AN descobre que um projeto não é viável ou factível, é sua obrigação fazer a organização saber disso. Se via gerente de projetos, gerente da área ou mesmo de um representante da área demandante, isso depende da estrutura. Sinceramente, é coisa que deveria fazer parte do Código de Ética da profissão.

      Será que eu tenho coragem de manter dois exemplos durante a série? Vou pensar no caso.

      Muito obrigado. Abraços!

      Paulo Vasconcellos

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *