DBAs vs Developers vs Clients

Esta semana vou comentar sobre 2 artigos que eu recomendo. Quando li eles tive aquela sensação de "eu sempre quis dizer isto".

Os artigos não são muito técnicos, aconselho tanto para DBAs, quanto para desenvolvedores, programadores, arquitetos de sistemas, gerentes/coordenadores de TI, etc.

Trata-se do artigo "Crossing the Chasm Between Developers and DBAs", escrito por Mike Cuppett, (em português: Cruzando o abismo entre Desenvolvedores e DBAs).

Ele aborda o quão problemática a visão estreita do problema e a guerra de egos pode se tornar do ponto de vista de quem realmente importa, que é o cliente.

E o fundador do Pythian Group, Paul Vallée, cita esta questão de egos em seu artigo "The seven deadly habits of a DBA... and how to cure them" (em português: Os sete hábitos mortais de um DBA... e como curá-los). Que é uma leitura recomendadíssima para DBAs e gerentes de times de DBAs. Ele explica muito bem a questão do artigo anterior e como o ponto de vista mais aberto é importante neste caso. Faço aqui uma tradução do hábito 5:

"Habit #5. O JOGO DA CULPA: Não olhe para mim, é culpa do desenvolvedor que este SQL esteja em produção

Alguns DBAs tem uma real mentalidade de 'nós contra eles' quando se trata de desenvolvedores e suas organizações. Eles não se veem como facilitadores ajudando os desenvolvedores a desenvolverem código de qualidade, do ponto de vista de banco de dados, mas se veem como guardiões que previnem que código de baixa qualidade entre em produção. Isto pode parecer como uma questão de semântica, mas um relacionamento conflituoso entre desenvolvedores e DBAs resulta em uma falta de iniciativa do desenvolvedor e uma lentidão significativa nos ciclos de release"

Já presenciei colegas DBAs sendo solicitados para atividades de análise de performance e para que ajudassem na melhoria do tempo de resposta de algumas consultas, e estes prontamente responderam "nós não fazemos isto, esta fora do nosso escopo". Deixando as questões de 'custo vs escopo' de lado, eu até acho que em muitos casos este tipo de atitude seja devido a falta de conhecimento sobre performance e até mesmo o medo de aprender, mas estas também são barreiras que devem ser vencidas por qualquer técnico.

E eu diria que este hábito de "nós contra eles" é terrível para qualquer profissional, seja DBA ou análista de sistemas, ou storage, ou backup, ou network, etc.

E para casos de empresas que trabalham com "Outsourcing Services"? As coisas se complicam ainda mais quando temos diversos fornecedores. A muito tempo já venho me perguntando como resolver a situação neste ultimo caso? Como coordenar os trabalhos, e conflitos, das diferentes empresas suportando um mesmo ambiente? 

É claro que é fator chave todos os envolvidos serem dotados de muita paciência e habilitade de comunicação. Mas nada supera a necessidade de haver uma curiosidade natural por resolução de problemas, que é o que nos motiva e cria esta ânsia de não descansar enquanto o problema estiver resolvido.



Concluíndo, acho que estes dois artigos são do tipo que deveriamos ler periódicamente, para nos políciar contra os vícios sociais no trabalho.