Vou contar uma história usando Scrum, para simplificar. Mas se você conseguir imaginar um projeto Waterfall que dê certo, pode aplicar a mesma história, pois o resultado seria o mesmo.

No começo tudo são flores: o cliente e a equipe constroem o backlog do produto. Neste caso, uma prosaica solução de análise multidimensional, OLAP.

A equipe trabalha duro, sempre em contato com o cliente, e no final da primeira sprint conseguem demonstrar a ferramenta, instalada e funcionando, e uma estrela simples: uma fato com uma métrica de quantidade, e a dimensão Cliente. O usuário consegue, por exemplo, contar a quantidade de clientes por cidade ou estado. “Beleza, mas você vai me dar mais coisas, né?” pergunta o ansioso usuário final. Claro, reassegura-mo-lo, vai ter a sua estrela completa no final da próxima iteração.

Ao final dessa primeira demonstração o PO (Product Owner) e a equipe se reúnem para planejar a segunda sprint. O planejamento praticamente endossa o backlog anterior, com pequenas mudanças pontuais e inconsequentes. A segunda sprint começa, evolui bem e termina em ordem. Nova apresentação é feita para o cliente, agora com a primeira estrela completa. O cliente decide colocar o sistema em produção, mesmo faltando mais duas estrelas, previstas para a próxima iteração.

A apresentação ocorreu de manhã, e a retrospectiva à tarde. No dia seguinte o PO vem para o planejamento da próxima sprint.

É quando a porca torce o rabo.

Pensando Bem…

“… e este”, conclui o Scrum Master, “é o backlog atual.Acredito que vamos manter as mesmas demandas, não? Com isso nós vamos completar a primeira release do OLAP no final deste mês, daqui a duas sprints.”

O cliente olha no fundo dos olhos do SM e diz “Sabe, depois da apresentação ontem, eu voltei e pedi ao Sr. BI que me deixasse testar um pouco mais o sistema.” O Scrum Master olha para o Sr. BI, que olha de volta, inocentemente. “Ele deixou?”, pergunta o SM. Sim, ele havia deixado, e até respondeu algumas perguntas, tanto que ele se atrasou para o começo da retrospectiva. “E você achou algum problema? Quer cancelar a entrada em produção desta estrela?”

– “Não, claro que não. É que, pensando bem… Acho que as próximas estrelas não são bem o que eu preciso.”

Paciente e diligentemente, o Scrum Master e a equipe escutam as novidades, debatem para entender e ajustam o backlog.

Veja: estamos começando a terceira sprint. Da primeira para segunda, tudo certo. No final da segunda o usuário conseguiu usar o produto por umas poucas horas e, antes de começar a terceira ele pediu uma mudança. Tudo dentro do bem-comportado processo do Scrum e, até aí, nada demais.

Sprint 3

E assim a Sprint 3 começou. Como das outras vezes, a equipe buscava o PO para tirar dúvidas e manter o trabalho alinhado com o backlog, mas parece que os selvagens tempos das Cascatas insinuavam-se pelas frestas: o cliente tentou mudar o backlog quase todas as vezes!!

Não era intencional, claro, afinal o cliente sabe que sabotar a equipe de desenvolvimento causa só uma vítima – ele mesmo. Não, muito ao contrário. Ele queria evitar que a equipe entregasse algo pouco valioso. Por isso o cliente sempre estava preocupado em mostrar como, a partir da Estrela 1, que ele estava usando desde sua entrega no final da Sprint 2, ele havia descoberto que a Estrela 2 (e a 3 também) trariam uma dimensão incorreta. O grão dessas duas novas estrelas servia, para a análise que ele achava que precisava fazer, mas não serviriam para a análise que ele descobriu que precisa fazer.

Esse é um problema grave: havia um desalinhamento fundamental entre o backlog prometido no início da Sprint 3 e a realidade do cliente. Quando o cliente começou a usar a Estrela 1, ele começou a “entender” os dados, o negócio e percebeu que havia feito pressuposições, e que essas agora mostravam-se incorretas.

Cuidado Com o Que Deseja…

… por que você pode conseguir.

A maior marca de um projeto de BI de sucesso é o seu aparente fracasso.

Por quê? Porque um projeto de sucesso gera novas perguntas, que geram novas demandas de dados, que faz parecer que o projeto está sempre no início! Mas não! Ele deu tão certo que o cliente avançou e aprendeu – gerou Inteligência do Negócio a partir dos dados.

É nesse caminho que ia nossa história: assim que o cliente começou a usar os dados de uma entrega de sucesso, a compreensão do problema mudou. É uma consequência natural de se aprender mais: novos conhecimentos desafiam nossas antigas visões e percepções. Ainda que isso aconteça em projetos de outros tipos de sistemas, em soluções de Inteligência de Negócios essa dinâmica gera consequências complicadas.

Por exemplo, aonde vai nossa história? Como ela termina? Assim.

O Scrum Master sacou o problema e decidiu convocar um fim abrupto para a Sprint 3. O cliente sentou novamente com a equipe e refizeram o backlog. A Sprint 4 começou e seguiu sem problemas. A demonstração ao final conseguiu recuperar o moral da equipe – estavam de novo na crista da onda, entregando valor para o cliente! Yeah! Touchdown!

Começaram a Sprint 4, que agora ia incluir novas dimensões e estrelas para aumentar a comunidade de usuários. O PO agora eram duas pessoas: o primeiro cliente e um novo usuário do outro departamento. Montaram um backlog para as próximas três sprints e planejaram a Sprint 5. Enquanto isso o novo cliente passou a usar as estrelas que já haviam sido entregues.

E adivinhe o que aconteceu? Isso mesmo: ele percebeu que havia entendido algumas coisas incorretamente. De novo a equipe não conseguia andar na sprint porque o novo cliente não colaborava. Mas desta vez a recusa era hostil!

“Vocês atenderam o outro direitinho! Porque não querem fazer o que eu preciso? Isso que nós combinamos não estava certo! Agora eu percebo isso, e não adianta continuar, eu não vou usar o que vocês estão fazendo!”

Conclusão

Preciso continuar a história? A Sprint 5 foi abortada – de novo – e a sprint 6 e 7 replanejadas. A Sprint 6 saiu redondinha, mas o sucesso deixou uma sensação de desconforto ao invés de alívio. A Sprint 7 foi abortada, virou 8, que deu certo etc. etc. etc.

Estou montando esse cenário na melhor das situações, com equipe funcional e capaz, Scrum Master habilidoso, clientes inteligentes etc. Imagine uma empresa que desenvolva em Waterfall, com feudos departamentais disputando acesso e posse dos dados, usuários mal-preparados ou obtusos…

E esse é um problema ainda mais insidioso porque eu nunca vi ninguém percebê-lo. Por um tempo achei que eu estava viajando! A história acima tem um ritmo acelerado, e talvez a velocidade normal de um projeto seja um impecilho para identificar essa situação. Projetos de BI têm a bagunça da redefinição de requisitos como normal, como consequência da indecisão do cliente. Ainda que haja um nível de indecisão, não acredito que seja esse o responsável por fazer o projeto parecer retroceder periodicamente.

Se você não se identificou com a história, pense um pouco e tente se lembrar: algum de seus clientes parece estar sempre aguardando a próxima versão? Tem algum cliente que sempre volta pedindo alguma mudança? Um novo relatório, uma mudança na dimensão, outra agregação para a mesma métrica? Será que ele não está mudando os requisitos por que está aprendendo?

Da próxima vez que alguém reclamar que o projeto de BI está patinando, erga as orelhas: o projeto pode estar sendo vítima do próprio sucesso!

Até a próxima!


P.S.: eu não sei como lidar com isso. Eu ainda não consegui pegar um caso destes acontecendo claramente, e mesmo que tivesse pego, não sei se saberia o que fazer. Intuitivamente eu diria que precisamos deixar o cliente com o sistema a sós por algum tempo – uma semana? um mês? – antes de planeja a próxima etapa de desenvolvimento, mas duvido que algum cliente toparia isso…

8 comentários sobre “Cruel Sucesso

  1. Grande Fábio, achei instigante teu texto, rico em possibilidades! Por um lado, o ajuste de rumo é bem-vindo, como dissestes, o cliente inicia um projeto com um grande estoque de pressupostos e irá ajustá-los conforme histórias de valor forem entregues e possibilite validá-las e assim ampliar sua consciência sobre o todo. Mas, concordo que no contexto BI isto potencializa-se pelas características inerentes a estas soluções de apoio a decisão utilizando grandes massas e diferentes fontes de dados, com múltiplos ETL’s, construídos baseados em percepções gerenciais. Ao ler teu texto, identifiquei com projetos de inovação, P&D, startups, empreendedorismo, pois estes projeto são regido por um ciclo de definição e validação onde ficam explícitos os riscos e investimentos necessários a este viés. Se o cliente, equipe e stakeholders tiverem a correta percepção desta característica intrínseca ao projeto, a fluidez gerará menor desconforto a todos e provavelmente gerará maior valor com menor empenho. Talvez valha a pena investir mais em prototipação, simulações e técnicas colaborativas, como usamos em projetos de inovação (Lean Startup, Validation Canvas, Empathy Canvas, value Proposition Canvas). Talvez possas idealizar novos conceitos e dinãmicas para “BI Dojos” como meio de mockagem e validação antecipada dos pressupostos atribuídos aos cubos e suas dimensões. Excelente texto, com múltiplas possibilidades, talvez a solução seja mudar o paradigma usado pelos envolvidos. [ ]

    1. Salve, Kotick! Obrigado pelo comentário.

      Eu penso de maneira semelhante. Mas olhe que legal! O comentário da Mel colocou uma coisa que me fez pensar: “Concordo contigo que aparentemente o ideal é deixar que o cliente aprenda a trabalhar os dados que têm a disposição”. Daí o Eduardo colocou que ele não se recorda dessa experiência – o oposto da Mel! – mas que trabalha sempre com sistemas transacionais.

      Porquê?

      Oras, sistemas transacionais são o que são. Batemos o olho na tela e sabemos se é aquilo que queríamos ou não. A demonstração deixa claro como o sistema funciona, e imediatamente conseguimos avaliar se era o que queríamos ou não. Bom, projetos de BI tem dois lados: a interface e os dados. Enquanto que a demonstração de projetos de BI, tal qual de sistemas transacionais, imediatamente validam a interface, os dados entregues não são validados no mesmo momento! Simplesmente não dá para olhar uma demo OLAP e validar os dados na mesma velocidade! A ferramenta é feita de elementos gráficos, cores, a mecânica de uso etc. etc. etc., mas os dados possuem relações que não podem ser inferidas imediatamente!

      Graças aos comentários do André e da Mel, e em resposta à suas idéias, acredito que a solução passe por estender o período de demonstração da entrega de projetos de BI. Por exemplo, dar uma semana entre a demo e o planejamento da sprint seguinte.

      O que você, Kotick, acha? E vocês, André e Mel e os outros leitores?


      P.S.: Kotick, viu que eu pus minha foto como sugeriu? ;-)

      1. Não sei se entendi bem, se a sprint é de 2 semanas, após a review e retrô abriria uma semana para validação e grooming … é isso. Já ouvi falar de equipes que fazem algo parecido, mas como nunca tive essa necessidade não sei dizer o quanto é produtivo ou não. Se fizer, compartilha aqui ;o)

      2. Isso mesmo. Grooming, é? Não sei bem se seria um “aparar de pontas”. Acho que está mais para uma longa retrospectiva mesmo. Quando é tudo mais ou menos visual, é fácil. Mas quando a demonstração real ocorre na cabeça do cliente, não dá para ajudar muito e aí só o tempo para deixar a percepção atuar na avaliação.

        Pode ficar tranquilo, se eu fizer você será o primeiro a saber. E meus leitores logo em seguida! ;-)

        (O Kotick dá apoio na empresa em que eu trabalho, e por isso ele provavelmente vai saber antes de vocês. ;-) )

  2. Oi Fábio, parabéns pelo post !
    Trabalhei em alguns projetos com scrum, olha tem um tempinho … Não era com BI.
    E sempre tinha backlogs e tal, mas sempre conseguíamos terminar o incremento. Confesso que não me recordo de tal situação.
    Será que é devido ao fato que sistemas transacionais ou os módulos que trabalhei são mais comportados ?
    E isso, talvez, sugira alguma adaptação de scrum para BI ? Assim como fazem para contagem de ponto de função ?

    1. Obrigado, Eduardo. O Scrum era só pano de fundo, para simplificar a história e deixar bem marcado o “ponto de quebra” – aquele momento em que o cliente volta aos requisitos e refaz tudo. Eu experimentei isso apenas em projetos Waterfall mesmo, como a Ferrer disse no outro comentário.

      Agora, perto de BI, definitivamente, os projetos de sistemas transacionais são bem-comportados. Imagino que seja porque o processo que o sistema automatiza, normalmente, já é parte da vida do cliente de alguma forma. Já soluções de BI são coisas mais esotéricas, cujo análogo mais frequente é a boa e velha planilha Excel.

  3. Oi Fábio, sempre curto seus posts! Parabéns e obrigada por compartilhar sua visão e experiência sobre esse mundo que é o BI.
    Não só me identifico com o cenário acima, como o vivo todos os dias. Sinceramente, nunca trabalhei em projetos que utilizaram SCRUM, mas sim Waterfall. Nem preciso dizer o retrabalho que nos dá fazer qualquer alteração nesse cenário. Concordo contigo que aparentemente o ideal é deixar que o cliente aprenda a trabalhar os dados que têm a disposição, mas também to pra ver algum deles que concorde com isso, rs.
    Abs.

    1. Obrigado, Mel (é esse seu nome?)! É um prazer compartilhar, e mais ainda saber que ajudo. Como eu comentei com o Eduardo, eu vivi isso apenas em projetos Waterfall mesmo, como você. Eu usei o Scrum na história para evitar a impressão que a quebra causada pela revisão era algo normal do processo. Hmm… Sabe, relendo seu comentário me veio uma outra idéia. Hmmm…. !!!

      De fato, o cliente sempre acha que falta algo, e nunca está satisfeito com o que tem à mão! ;-)

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s