A imagem de um mago branco sozinho em uma torre alta e sombria, rodeada em sua base por um exército de orcs (na verdade Uruk-hais, para evitar desentendimentos de ordem nerd) pilhando florestas, acendendo fogueiras e esquentando caldeiras para construir armas de guerra, foi materializada em nossas mentes durante a famosa trilogia Senhor dos Anéis, lançada durante os três primeiros anos do nosso milênio corrente. E nós torcíamos, o tempo todo, para que aquele mago perdesse a guerra que estava para acontecer, muito devido à sua prepotência e descaso pela realidade ao seu redor – a natureza, as pessoas e a sociedade que ali existia.
Quase ao mesmo tempo (fevereiro de 2001), por coincidência, em um resort de esqui em Utah, aconteciam as primeiras reuniões que resultaram no documento mais influente da cultura corporativa tecnológica de todos os tempos – o manifesto ágil. Estranhamente, esses dois eventos que parecem tão desconexos, tinham um fator psicológico comum: uma acirrada luta para remover pessoas poderosas e prepotentes de suas torres e trazê-las para a realidade ao seu redor. Durante a década anterior, “gurus” das mais diversas metodologias de processos (p.ex., RUP) , dominaram o mercado de produção de software, frequentemente criando um abismo entre os usuários, os programadores e os “arquitetos” do produto de software. O resultado disso tudo foram pilhas de documentação de projetos que nunca foram implementados ou pior, que foram implementados, mas resolvendo o problema errado. Desde então se criou a denominação “ivory tower software architect” (ou no nosso exemplo simplesmente “Saruman”) para se referir àqueles profissionais que tentam projetar sistemas de maneira distante do código e das tarefas de desenvolvimento do dia a dia.
Mas ora, foi apenas criar um documento de manifesto (a ironia é grande aqui) que todos os problemas se resolveram? Claro que não. O que a nova cultura trazia era uma mudança abrupta de foco da utilização dos recursos (neste caso dinheiro convertido em horas de pessoas especilalizadas), do processo para as pessoas, do planejamento minucioso e inflexível para a resposta às mudanças, de documentação detalhada para um produto funcional. E esta mudança de foco levou anos, em algumas indústrias ainda não se consolidou e em outras ainda nem começou de verdade. Mas, em geral, mesmo as empresas mais conservadoras têm procurado adotar estes “lemas”, com medo de que a sobrecarga de processos torne sua existência insustentável.
Mas, em geral, mesmo as empresas mais conservadoras têm procurado adotar estes “lemas”, com medo de que a sobrecarga de processos torne sua existência insustentável.
Neste contexto de guerra cultural dentro de organizações tecnológicas é que nasce a disciplina de análise de dados. Os novos analistas de dados ou, ultimamente, cientistas de dados, imersos nestes ambientes, buscaram entre as disciplinas e métodos pré existentes maneiras melhores de realizar suas atividades e atingir seus objetivos. Era inevitável a influência tanto da incipiente cultura ágil quanto das metodologias mais tradicionais na abordagem da criação de soluções de análise de dados. E assim foi criada a “análise de requisitos de dados”, em uma clara alusão à tradicional “análise de requisitos de software”.
É importante, neste momento, para que não pareçamos intransigentes, argumentar que existem infindáveis tipos de indústrias, empresas, formadas por pessoas com contextos variáveis, e que em cada um destes casos possamos nos beneficiar de um tipo ou outro de abordagem na construção de um produto de análise de dados. Trocando em miúdos, não afirmamos que uma “análise de requisitos de dados” seja uma atividade sem valor per se, mas que é extremamente limitada a alguns casos e contextos específicos. Também é importante lembrar que o tempo e budget para um projeto é limitado. Escolher as atividades a serem ou não realizadas dentro e um projeto pode ser a diferença entre o sucesso e o fracasso.
Alguns problemas neste tipo de abordagem clássica saltam aos olhos, e tem um parentesco com os problemas nas análises de requisitos tradicionais em software, ou mais geralmente de abordagens top-down. O primeiro e mais importante deles, é que muitas vezes não existem requisitos, estes são incompletos ou estão errados. De maneira prática, descrições de desejos
genéricos das pessoas envolvidas são comuns: “gostaria de acessar todas as operações da empresa”, mas não raramente esses desejos não são detalhadas o suficiente para definir requisitos de um sistema de dados. Também podemos chamar estes desejos de requisitos de alto nível e eles tem uma utilidade bem limitada. A abordagem ágil neste caso seria prototipar e construir rapidamente provas de conceito funcionais, buscando soluções que agreguem valor na direção dos desejos do usuário. No caso, explorar necessidades reais práticas dos consumidores de dados e colocá-las para funcionar o mais rápido possível. Com o uso destas, os consumidores de dados saberão melhor o que necessitam, o ciclo se repete e a evolução do sistema acontece organicamente.
Outra falha comum descrita no processo de análise de requisitos de dados é nos basearmos nas documentações dos sistemas que contém as informações. A única fonte totalmente confiável de informação sobre um determinado sistema é seu código, e no caso de dados, poderíamos adicionar à esta definição os sistemas de banco de dados utilizados. Consultar somente (ou até primariamente) as documentações pode gerar uma séries de surpresas ruins na implementação de um sistema, quando se descobre que as documentações já não refletem o estado dos sistemas que se deseja consultar.
É possível utilizar o processo de análise de requisitos de dados como um guia, porém é preciso tomar cuidado e lembrar que os entregáveis reais do projeto não são documentos, mas sim produtos de dados funcionando e agregando valor aos consumidores de dados.