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:

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:

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:

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).