Atuar no início dos projetos e Ser Ágil nos atendimentos: Boas práticas da Gestão de Dados Moderna

Introdução:

Cada vez mais, as equipes de TI são cobradas por entregas com menor custo, maiores ganhos de valor agregado ao negócio e melhor qualidade, mas com um tempo de entrega das soluções cada vez menor.  Além disso, sabemos que historicamente as áreas de Administração /Gestão de Dados sofrem com o estereótipo de serem consideradas áreas de gargalo dentro das organizações.

Dando continuidade à série de artigos sobre as boas práticas aplicadas na Gestão de Dados Moderna, comentarei sobre as duas boas práticas que ajudam as áreas de Gestão de Dados acompanharem o ritmo "acelerado" das empresas e também acabar com o mito de que a Gestão de Dados é sinônimo de "gargalo" nas organizações. As práticas que serão abordadas neste artigo são: "atuar no início dos projetos" e "ser ágil nos atendimentos".

<spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif";color:black;background:white'>Prática 2 – Atuar no início dos projetos</spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif";color:black;background:white'>

Atuar no início dos projetos significa atuar de forma proativa, com o propósito de identificar, e/ou mitigar os principais riscos e também eliminar as principais anomalias dos projetos.  O grau de incerteza dos projetos nas fases iniciais é muito maior do que nas fases mais próximas do seu encerramento. Logo, quando o assunto é riscos,sabemos que quanto maiores forem os níveis de incerteza, maiores serão os riscos e suas probabilidades. Se a área de Gestão de Dados tiver uma atuação mais intensa nesta fase, antevendo problemas referentes ao uso dos dados e informações, certamente ajudará a reduzir a incidência de anomalias e diminuir o custo do retrabalho gasto nas correções das mesmas.

Vale ressaltar que a prática de atuar no início dos projetos, não se resume apenas a atuação de Administradores de Dados nas orientações sobre modelagem de dados e/ou avaliações de modelos de dados. A abrangência desta prática é bem mais ampla e pode ser aplicada em todas as funções previstas no framework DAMA-DMBOK®. Podemos citar como exemplos:

Gerenciamento da Arquitetura de Dados:<spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif"'> Definições preliminares da arquitetura empresarial e também da arquitetura de dados corporativa.</spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif"'>

Desenvolvimento de Dados:<spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif"'> Orientações e avaliações preliminares nos modelos de dados produzidos pelas equipes de desenvolvimento/projeto.</spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif"'>

Gerencia de Operações e Database:<spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif"'> Definição de rotinas mais proativas das operações de infraestrutura e administração de banco de dados.</spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif"'>

Gerenciamento de Dados Mestres e Referência:Apoio na identificação, reutilização e governança dos Dados Mestres e Referência das organizações.

Gerenciamento da Qualidade de Dados:<spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif"'> A Gestão de Dados Moderna prega que a qualidade não é controlada e sim planejada. Além disso,Qualidade de Dados não é um projeto e sim um programa, onde a conscientização das pessoas é fundamental para o sucesso. Portanto, a participação da área de Gestão de Dados no planejamento da qualidade dos dados é fundamental. Um bom planejamento interfere diretamente na qualidade dos dados criados na organização, reduzindo a incidência de futuras limpezas e correções nos dados.</spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif"'>

De forma geral, a área de Gestão de Dados deve atuar em todas as fases do ciclo de vida de desenvolvimento de software e também do ciclo de vida dos dados. Vale ressaltar que quanto maior o esforço nas fases iniciais destes ciclos, menor o esforço nas fases finais e de controle dos mesmos.

<spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif";color:black;background:white'>Prática 3 – Ser ágil nos atendimentos</spanstyle='font-size:10.0pt;font-family:"verdana","sans-serif";color:black;background:white'>

Um dos principais fatores de resistência à implantação de áreas de Gestão de Dados nas empresas é o fator tempo. Partes envolvidas diretamente no processo, como as equipes de desenvolvimento /projetos, costumam alegar que os projetos podem atrasar devido ao tempo gasto nas atividades executadas pela equipe de Gestão de Dados sem levar em conta a qualidade agregada ao produto final que essas atividades podem gerar.

Além disso, várias empresas estão adotando métodos de desenvolvimento ágil na construção de software, como Scrum e Kanban,o que aumenta ainda mais a necessidade de agilidade nos atendimentos, sob penada equipe de Gestão de Dados não suportar o ritmo demandado das partes interessadas e não conseguir demonstrar o seu real valor.

Definir um Acordo de Nível de Serviço (SLA– Sevice Level Agreement) curto e objetivo que abrange todas as atividades executadas pela área é fundamental para que a Gestão de Dados não seja encarada como algo extremamente burocrático e ineficaz, ou seja, uma área que está dentro dos processos apenas para atrapalhar sem agregar nenhum valor.

De forma geral, quanto menor o tempo de atendimento da tarefa, menor será a resistência, porém é importante destacar que o SLA deve ser cumprido, acompanhado e seus resultados divulgados periodicamente a todos os envolvidos. De nada adianta uma empresa utilizar um SLA muito curto, se ela não tem capacidade de atender a maioria dos atendimentos dentro dos prazos estipulados.

Mas afinal, como definir as atividades e tempos médios para o SLA? Não existe uma receita de bolo específica para estabelecer um SLA. A quantidade de pessoas, experiência da equipe, capacitação técnica dos envolvidos, ferramental utilizado, características do negócio e aspectos culturais influenciam diretamente no tempo médio de atendimento de cada atividade. Um SLA adotado em uma empresa, nem sempre será o SLA ideal para ser adotado em outra empresa.

Mesmo assim, algumas boas práticas podem ser utilizadas na definição deste SLA. Entre elas podemos citar:

 
• O SLA deve ser divulgado para todos os envolvidos. Divulgar o SLA apenas para a equipe de Gestão de Dados não faz nenhum sentido.
 
• O SLA deve ser aplicado dentro do horário de trabalho padrão da empresa. Ex: 08:00 às 17:00h ou 09:00 às 17:00h
 
• Os tempos de atendimento devem ser dados em horas úteis.
 
• As tarefas mais usuais devem ser classificadas por tamanho/complexidade: Ex: quantidade de entidades/tabelas, modelo novo x alteração pontual em modelo, etc.
 
• As classificações dos tempos de atendimento devem ser simples e facilmente compreendidas por todos. Fórmulas matemáticas que envolvem a contagem de vários tipos de objetos (entidades, atributos, relacionamentos, domínios, etc...) são mais precisas quando o produto está no fim e o solicitante sabe exatamente o que ele quer (o que é raro), porém são extremamente complicadas para quem está solicitando o serviço. Em tempo de planejamento prazos calculados desta forma são inviáveis e até mesmo imprecisos.
 
• Para tarefas de difícil estimativa genérica, deve-se estabelecer um prazo para dar a estimativa final. Ex. Prazo para efetuar tuning em base de dados.
 
• O SLA deve possuir uma meta de cumprimento e também uma meta desafiadora. Ex.: Meta de atendimento de 90% das solicitações dentro do prazo e meta desafiadora de 95%.
 
• Os valores cumpridos também devem ser divulgados. Afinal, se o SLA é curto e a equipe de Gestão de Dados atende a meta de atendimento estabelecida, não há razão para gargalos.

A tabela abaixo mostra um exemplo de SLA:

No próximo artigo, falarei sobre as práticas "Utilizar princípios e ferramentas de qualidade" e "Nunca acomodar".