Boas práticas para adoção do Policy Based-Management

De que se trata o artigo:

Neste artigo veremos que com um planejamento orientado por algumas perguntas e checklist é possível adotar soluções com Policy Based-Management respondendo necessidades do cenário, de forma que esta não se torne uma “feature órfã”, por permitir melhorias e acompanhar a evolução e mudanças do cenário.

Para que serve:

O planejamento na adoção do Policy Based-Management permite adequar o cenário às normas organização e às boas práticas de disponibilidade, capacidade, continuidade e segurança.

Em que situação o tema útil:

Mesmo que o Policy Based-Management seja uma feature que demande de pouca complexidade, o seu planejamento permitirá melhor entendimento do cenário, de forma que soluções com esta feature atendam adequadamente contratos de SLA, as normas organização e boas práticas de disponibilidade, capacidade, continuidade e segurança, acompanhando até mesmo a evolução do cenário.

Introdução

O Policy Based-Management (PBM) é uma feature introduzida no SQL Server a partir da versão 2008, a qual permite os administradores de banco de dados obterem o controle dos seus ambientes com a aplicação de regras e padrões sobre uma ou várias instâncias do SQL Server, além da possibilidade de reutilizar estas regras e padrões em outros cenários e versões anteriores do SQL Server (2000/2005).

Mas antes de implementar qualquer solução com esta feature, é necessário planejamento e entendimento do cenário, no qual, respostas a perguntas simples “por que, o que, como” poderão ajudar numa adequada implementação desta feature, de forma que as soluções implementadas não venham proporcionar qualquer resultado positivo ao cenário.

Este artigo vem a oferecer um conjunto de boas práticas tanto para o planejamento e adoção do PBM, como para o desenvolvimento de soluções e monitoramento das mesmas, auxiliando a responder as perguntas “por que, o que, como” desta feature.

Para um melhor entendimento, os termos disponibilidade, capacidade, continuidade e segurança utilizados neste artigo seguem algumas releituras do ITIL (Information Technology Infrastructure Library, http://en.wikipedia.org/wiki/ITIL):

Disponibilidade	Disponibilidade é determinada pela confiabilidade, sustentabilidade, funcionalidade do serviço, desempenho e segurança. Normalmente calculada a partir da medição de transações de negócio geradas por um serviço de TI e a indisponibilidade deste serviço.
Capacidade	O máximo de rendimento que um serviço consegue fornecer. Pode ser calculado a partir de medição de um tamanho ou volume (disco), ou esforço de trabalho que o serviço se limita.
Continuidade	Avaliação dos riscos que podem impactar o serviço. Termo normalmente associado com manutenção.
Segurança	Garantia da confidencialidade, integridade e disponibilidade dos dados e informações.

Estes termos se traduzem como os objetivos da administração de banco de dados, assim como de qualquer serviço da área de TI.

No que se refere à estrutura deste artigo, ela se aproxima a algumas de práticas de resolução de problemas, como o PDCA (Plan-Do-Check-Act), adaptadas para adoção de novas soluções, onde o ciclo planejar, implementar e acompanhar (avaliar e analisar), necessitou somente de uma ênfase na estratégica por traz do planejamento, e na segurança, por questões específicas do PBM.

Por quê? Estratégia

As justificativas para adoção de qualquer feature têm que responder muitos porquês, que podem simplesmente evitar que seja implantada qualquer solução, mas respondendo estes porquês, será possível entender a importância desta feature.

Um das justificativas comuns para adoção do PBM é a importância de adequar o cenário às normas organização ou projeto e boas práticas de disponibilidade, capacidade, continuidade e segurança. Lembrando que todos os cenários existem normas, mesmo quando estas não estão documentadas, elas ainda se fazem presentes.

Também é possível encontrar a organização que se baseiam suas normas em contratos de SLA (Service Level Agreement ou Acordo de nível de serviço, http://en.wikipedia.org/wiki/Service_level_agreement), exigindo um mínimo de requisitos (disponibilidade, capacidade, continuidade e segurança) dos serviços prestados aos seus clientes, e por consequência, exigindo dos administradores de bancos de dados, o uso do PBM e outras ferramentas para monitorar várias instâncias do SQL Server e seus bancos de dados.

Quando a adoção do PBM não é justificada por normas, mudanças e problemas da organização, é interessante pensar se boas práticas de disponibilidade, capacidade, continuidade e segurança recomendadas pelo fornecedor, no caso a Microsoft, estão presentes nas normas do ambiente, pois uma simples adoção do PBM pode ser justificado por perguntas simples como:

• O último backup é recente?
• Existe espaço de disco para suficiente para os bancos de dados?

Ou até algumas perguntas um pouco mais complexas:

• Existe alguma configuração que pode estar comprometendo com o desempenho ou segurança do banco de dados e do servidor? Pelo menos, tem certeza que não existe nenhum login configurado de forma a permitir uma senha fraca?
• Existe alguma feature deprecated configurada? Para uma relação destas, é interessante acompanhar: http://msdn.microsoft.com/en-us/library/cc280407.aspx
• Existe alguma stored procedures criadas por usuários cuja nomenclatura ofereça problemas de desempenho? Sim, isso pode ocorrer com stored procedures de nomenclatura sp_*, pois o SQL Server procurará stored procedures com esta nomenclatura primeiramente no banco de dados master e depois no banco de dados na qual elas são executadas, até mesmo podem surgir alguns erros inesperados ou algumas stored procedures não serem encontradas quando executadas.

Estas perguntas podem ajudar a identificar algumas boas práticas, mas se estas boas práticas ainda estão claras, é possível encontrar no site do TechNet e MSDN, uma série de boas práticas, sendo algumas genéricas (segurança, backup…) e outras para cenários específicos (virtualização, BI…), que podem ajudar a identificar quais são úteis para cada cenário. Sempre lembrando que as organizações podem adotar práticas que até mesmo violam ou ignoram as boas práticas e recomendações pelo fornecedor, no caso a Microsoft.

Boas práticas, TechNet:
http://technet.microsoft.com/en-us/sqlserver/bb671430.aspx

Boas práticas, MSDN:
http://msdn.microsoft.com/en-us/sqlserver/bb671432.aspx

Na pasta C:\Program Files\Microsoft SQL Server\110\Tools\Policies (em ambientes x64, C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Policies) existem uma série de arquivos XML que podem ser importados pelo PBM em forma de regras, com a finalidade de validar boas práticas para administração do SQL Server. Uma breve descrição de cada um destes arquivos é possível de ser encontrada no seguinte link:
http://msdn.microsoft.com/en-us/library/cc645723.aspx

O que? Planejamento

Ao se pensar no que será feito, é importante entender o que a feature pode oferecer e por outro lado, avaliar se não existe outra solução que responda de forma mais adequada as necessidades do cenário. Esta avaliação é importante, visto que uma feature como o Policy Based-Management ser passível de ser substituída por consultas, relatórios, jobs e triggers, outras ferramentas ou até mesmo solução de terceiros, mas o tempo, custo, flexibilidade e complexidade de desenvolver uma solução do “zero” ou adotar uma solução de terceiros são pontos a serem levados em consideração, já que muitos dos potenciais desta feature esta na praticidade de adotá-la.

Mas o que esta feature pode fazer? Basicamente, o PBM proporciona soluções de automatização com a finalidade de diminuir o tempo que o administrador de banco de dados deveria se dedicar à manutenção, que pode se estender às regras de configuração no nível de servidores até objetos do banco de dados, como tabelas e índices. O PBM oferece algumas soluções para gerenciar as regras implementadas pelo administrador de banco de dados, que ser monitoradas por meio de agendamento ou por demanda (executada pelo SQL Server Management Studio), gerar alertas ou até mesmo prevenir que as regras sejam violadas por algum usuário.

As regras do PBM são compostas por três estruturas básicas:

• Target Types, estruturas que representam os tipos de objetos manipulados pelo PBM, exemplo: Tables, Views e Databases.
• Management Facets, estruturas que representam grupos de propriedades de determinados Target Types, como por exemplo, Name, Table Options, Database Option e Surface Area, que são utilizadas para criar condições/filtros.
• Condition ou Condições/Filtros, estruturas que representam expressões lógicas por meio das Facets, a fim de aplicar filtros e validações.

As possibilidades de criar regras no PBM não estão limitadas ás suas facets, visto que há a possibilidade de customizações com consultas T-SQL e WMI. Mas é importante levar em consideração que estas customizações demandam de bom senso dos envolvidos, para evitar que sejam desenvolvidas soluções muito complexas ou que interfiram na disponibilidade e segurança do servidor.

No blog oficial de PBM, é possível obter uma relação das facets e os target types que elas manipulam:
http://blogs.msdn.com/b/sqlpbm/archive/2008/05/24/facets.aspx

A partir do momento que se entende o potencial da feature, é possível definir um checklist para determinar a solução a ser desenvolvida:

1. Justificativa: Existem normas ou boas práticas a serem adotadas em relação à disponibilidade, capacidade, continuidade e segurança do SQL Server?
2. Extensão: Qual a extensão destas normas e boas práticas (Servidores, Instâncias, Bancos de dados, Tabelas…)?
3. Ferramenta: Existem facets que atendem estas normas ou boas práticas, ou será necessária customização (comandos T-SQL ou WMI)?
4. Alternativa: Se for necessária uma customização, não existe uma alternativa (uma feature já presente no SQL Server ou feature de terceiros) que não exija esta customização? A atenção a este ponto pode evitar arrependimentos futuros.
5. Correção: O que deverá ser feito quando for encontrada uma situação que entre em desacordo com as regras estabelecidas? Em um segundo passo, defina os responsáveis e o prazo para as ações corretivas.
6. Exceções: Existem exceções? Quais? Cuidado, estas exceções podem se tornar a regra, então se a norma deve ser obedecida, exceções devem ser as mínimas possíveis e bem definidas (por que ela existe e quais os critérios para identificá-la?).

Para entender melhor como responder este checklist, segue abaixo alguns exemplos:

Cenário A:

1. Justificativa	Existe uma norma do projeto Icaro, que determina que todos os objetos do banco de dados utilizem a nomenclatura CamelCase (http://en.wikipedia.org/wiki/CamelCase). Para que esta seja respeitada, os novos objetos somente serão criados obedecendo a nomenclatura CamelCase, e os objetos que ainda não obedecem esta nomenclatura serão identificados pelo PBM a fim de serem corrigidos.
2. Extensão	Todos os objetos do banco de dados
3. Ferramenta	Esta norma está relacionada às facet “Multipart Name” e “Name”, mas será necessário criar uma função para testar se esta nomenclatura é utilizada, para tratar esta norma.
4. Alternativa	É possível criar uma consulta sobre os objetos do banco de dados, mas ainda será necessário criar uma função para testar a nomenclatura e a consulta não permitirá a mesma praticidade do PBM de tratar este problema.
5. Correção	Os objetos que estiverem fora do padrão serão relatados à equipe de desenvolvimento para ajustes.
6. Exceções	Alguns objetos não estão no padrão estabelecido por serem de software de terceiros. Uma relação dos objetos que serão mantidos fora do padrão será armazenada em uma tabela do banco de dados, com a finalidade de desconsidera-las nas regras.

Cenário B:

1. Justificativa	Para que seja utilizada a solução de Log Shipping nos bancos de dados do cliente X, é necessário que os bancos de dados deste cliente estejam configurados como “Recovery Mode” diferente de “Simple”. Desta forma, o PBM será utilizado para identificar os bancos de dados que estejam configurados inadequadamente.
2. Extensão	Os bancos de dados das instâncias X\SQL2008 e X\SQL2008R2
3. Ferramenta	Esta definição esta associada à facet “Database”, propriedade “RecoveryMode”, não sendo necessária customização.
4. Alternativa	É possível criar manualmente esta validação, mas demandará mais tempo.
5. Correção	Encontrar um banco de dados fora do padrão, ajustar imediatamente o “RecoveryMode” para “Bulk-logged”.
6. Exceções	O banco de dados BRCEP é somente leitura e não precisará ser replicado. Uma relação dos objetos que serão mantidos fora do padrão será armazenada em uma tabela do banco de dados, com a finalidade de desconsidera-las nas regras.

Nos cenários apresentados, todos apresentam possibilidades simples de adotar o PBM, e uma das vantagens permitidas por esta feature, é capacidade reutilizar estas regras em outros ambientes quando se fizer necessário, visto que elas podem ser exportadas e importadas por meio de arquivos XML.

Como? Implementação

Na criação de qualquer estrutura no PBM, não pode deixar de lado questões de nomenclatura e uma boa descrição das condições e regras criadas. Cenários robustos podem favorecer até mesmo na criação de regras que validam a nomenclatura e a existência de descrição das regras e condições do PBM, assim como versionamento destas regras.

Infelizmente, não existe uma solução de versionamento nativa para o PBM, mas é possível utilizar SharePoint Server, Visual Studio Team Foundation Server ou outra solução de SVN para manter um histórico dos arquivos XML das regras desenvolvidas.

Quando se pensar nas regras além de uma boa nomenclatura e descrição, é recomendado que estas sejam devidamente categorizadas, para o entendimento do que estas regras estão monitorando (servidor, banco de dados, tabelas, usuários…), saber quem será responsável por estas regras e onde/quando elas são aplicadas (verificações periódicas ou em tempo real, servidores/bancos de dados de clientes, ambientes de produção, de homologação ou de desenvolvimento).

A tabela abaixo, obtida de forma resumida do blog oficial de PBM, é possível identificar as facets que podem ser utilizadas de forma preventiva (de forma a evitar que alguma ação que burle a regra seja executada) ou que sejam “logáveis” quando sofrem alterações:

Facets	Preventiva	Log
Application Role	X	X
Asymmetric Key	X	X
Database Option		X
Database Role	X	X
Endpoint	X	X
Login Options	X	X
Multipart Name	X	X
Resource Pool	X	X
Schema	X	X
Server Configuration		X
Stored Procedure	X	X
Surface Area		X
Table Options	X	X
User Defined Function	X	X
User Options	X	X
View Options	X	X
Workload Group	X	X

A partir dos cenários do tópico anterior e uma análise de como será implantado, é possível detalhar a implementação desta solução a partir de um checklist simples, como demonstrado abaixo:

Cenário A:

Categoria	ProjetoIcaro
Ambientes	Servidor de desenvolvimento
Regras	1: NomenclaraCamelCase1 2: NomenclaraCamelCase2
Descrição da regra	1: Validação preventiva da norma do projeto que determina que todos os objetos do banco de dados utilizem a nomenclatura CamelCase (http://en.wikipedia.org/wiki/CamelCase). 2: Validação periódica (1 vez por semana) da norma do projeto que determina que todos os objetos do banco de dados utilizem a nomenclatura CamelCase (http://en.wikipedia.org/wiki/CamelCase).
Responsáveis	Responsável pela criação e manutenção das regras: João da Silva, DBA da organização. Responsável por orientar as correções e informar exceções das regras: José da Silva, Analista do projeto.
Eventualidade	1: Verificação executada de forma preventiva, por meio da facet “Multipart Name”. 2: Verificação executada de forma periódica, por meio da facet “Name”.
Descrição da implementação	Criada a função dbo.ValidaCamelCase, que permite validar qualquer texto de acordo com a nomenclatura CamelCase. 1: Utilizada a facet Multipart Name, permite execução preventiva, mas possui uma abrangência limitada (Sequence, StoredProcedure, Synonym, Table, UserDefinedFunction, UserDefinedType, View, XmlSchemaCollection). 2: Criada para encontrar objetos fora do padrão já existentes e de forma mais abrangente. Utilizada a facet Name, não permite execução preventiva, mas possui uma abrangência maior que a facet Multipart Name (ApplicationRole, AsymmetricKey, Certificate, DatabaseRole, Default, Index, Rule, Schema, Sequence, SqlAssembly, StoredProcedure, SymmetricKey, Synonym, Table, Trigger, User, UserDefinedFunction, UserDefinedType, View, XmlSchemaCollection).

Cenário B:

Categoria	Manutencao
Ambientes	Servidor de produção
Regras	RequisitosLogShipping
Descrição da regra	Para que seja utilizada a solução de Log Shipping no SQL Server do cliente X, é necessário que os bancos de dados deste cliente estejam configurados como “Recovery Mode” diferente de “Simple”.
Responsáveis	Criação e manutenção das regras, e ajustes que no servidor: José Lins, DBA do cliente X.
Eventualidade	Verificação periódica (1 vez do dia).
Descrição da implementação	Utilizada a facet “Database Option’, para que se necessário seja adaptada para “logar” as alterações.

Segurança

Após a implementação do PBM, algumas questões de segurança devem ser analisadas, visto que com um usuário com acesso indevido para criar/modificar regras e condições do PBM, é possível desde adulterar e burlar regras ou até mesmo criar regras e condições nocivas ao ambiente, dada a possibilidade executar comandos T-SQL por meio do PBM.

Assim, não permita que usuários indevidos se tornem membros da Database Role PolicyAdministratorRole do banco de dados msdb (role que permite a criação e edição de regras e condições do PBM), ou que sejam dadas permissões/senhas indevidas aos logins do PBM (##MS_PolicyEventProcessingLogin##, ##MS_PolicyTsqlExecutionLogin##).

Caso seja necessário executar alguma consulta que o PBM não tenha permissão, dê somente as permissões que se fizerem necessárias ao login ##MS_PolicyTsqlExecutionLogin##, que é o responsável pela execução de consultas T-SQL do PBM.

Acompanhamento

Depois de implantado o PBM, adequadas as questões de segurança, criadas as soluções de regras e condições de acordo com o que foi planejado, estabeleça com os responsáveis pelo ambiente, uma agenda para avaliar os resultados obtidos e identificar/analisar melhorias. Para orientar esta agenda, busque responder algumas perguntas, como:

• Esta solução realmente tem atendido adequadamente o que foi estabelecido e com o cenário atual? Caso não esteja atendendo adequadamente, verifique se a feature realmente respondeu as justificativas de sua implantação, pois o escopo da solução é facilmente esquecido com o tempo.
• A implementação desta feature trouxe algum problema para o cenário? Tanto processualmente e tecnicamente, a implementação do PBM pode criar problemas, como a geração de conflito com a cultura da organização ou complexidade da solução criar gargalos de desempenho ou conflitos com outras soluções.
• As regras e condições são seguidas corretamente? Caso não tenha sido acompanhado este ponto pelo responsável, é possível verificar pelo próprio PBM, alguma views ou até mesmo algumas ferramentas de terceiros (EPM Framework) se as regras e condições implementadas são seguidas corretamente e a evolução destas em determinado período. Se as regras e condições não são seguidas ou não houve correções no cenário, verifique se elas realmente estão de acordo com o cenário atual e se o processo de correção pode ser realizado de acordo com o planejado.
• Existem exceções se tornado regra? Exceções, como informado anteriormente, podem se tornar a regra, então se a norma deve ser obedecida, exceções devem ser as mínimas possíveis.
• Alguma melhoria para o cenário atual? Melhorias também devem responder as mesmas perguntas que definem a implantação da feature (“por que, o que, como”), pois adaptações mal planejadas podem tornar o cenário demasiadamente complexo em comparação ao retorno obtido e esperado, além de gerar problemas técnicos e/ou processuais em muitos casos.
• Alguma melhoria para o cenário futuro? Ao se pensar no cenário futuro, esteja atento ás estratégias da organização ou projeto, pois a escalabilidade na área de TI tem tendências mais reativas do que proativas quando se trata de estratégia, desta forma, metas da organização devem estar ao lado de métricas e metas de TI. Exemplo disso, uma organização que planeja triplicar o número de clientes em um ano, precisa que sua infraestrutura esteva preparada a este mesmo crescimento, como, servidores suportando o triplo dos dados, backups e transações que os atuais.
• Existe alguma solução ou mudança que possa justificar a substituição desta feature? Features também sofrem depreciação, como por exemplo, a feature utilizada na sua solução pode não estar presentes nas próximas versões do SQL Server ou podem surgir features que atendam de forma mais adequada o cenário. Procure deixar de lado um pouco do paternalismo para com as soluções que você e sua equipe implantou, para que se necessário sejam adotadas outras soluções que venha a substituir parcialmente ou completamente a feature atual.

Uma ferramenta muito útil para acompanhar a evolução do PBM é o EPM Framework, disponível gratuitamente no CodePlex (http://epmframework.codeplex.com), que permite relatórios bem úteis do dados históricos e correntes das regras do PBM:

Também é possível criar sua própria solução para acompanhar o PBM, utilizando as views do PBM (http://technet.microsoft.com/en-us/library/bb510742.aspx).

Em relação ao acompanhamento do PBM pela própria Microsoft, apesar de existir algumas sugestões de melhorias relacionadas a esta feature no Microsoft Connect, o CTP1 do SQL Server “Denali” (ou SQL Server 2011) não apresentou resposta a estas sugestões e também não foram divulgadas mudanças nesta feature. Mas pelo grande potencial desta feature, é até difícil pensar em melhorias que podem ser grandemente relevantes para futuras versões.

Conclusão

Este artigo tratou de permitir um entendimento de como por meio de um planejamento orientado por algumas perguntas e checklist, é possível adotar soluções com o a feature PBM, respondendo de forma adequada as necessidades do cenário, devidamente justificada, contando até mesmo com exceções e permitindo que a solução depois implantada não se torne uma feature órfã, por permitir melhorias e acompanhar a evolução e mudanças do cenário.

Com apoio de outras features nativas do SQL Server 2008+, como o Resource Governor e o Management Data Warehouse, é possível rapidamente aumentar o arsenal do administrador de banco de dados, oferecendo maior controle da disponibilidade dos recursos do SQL Server e relatórios para acompanhar da evolução dos cenários, tendo cada vez mais controle sobre o ambiente e recursos para entender como responder de forma adequada questões de disponibilidade, capacidade e continuidade dos cenários. Mas apesar da praticidade de adotar qualquer features, nunca deixe de lado o planejamento antes de adotá-las.

Excessos e descasos na gestão na área de TI

Ao se falar em gestão na área de TI, a temos fundamentada em cinco atividades básicas da administração: Planejamento, Organização, Execução, Controle e Liderança. Mas tanto excessos, como a falta de dedicação em algumas destas atividades, são fatores a prejudicar os resultados que são esperados deste área.

Os principais problemas são visíveis já na atividade de Planejamento, onde são determinadas as ações pelas quais as estratégias da organização serão suportadas ou executadas pela área de TI. O excesso de planejamento neste momento pode estar relacionado ao uso demasiado de tempo para planejar como se dará toda a execução, numa tentativa utópica de planejar tudo o que será feito e prever todos os problemas que podem ocorrer durante a execução, tirando muito da autonomia de quem executará, além do planejamento ter que lidar com problemas tão complexos e dinâmicos que não poderão estar claros neste momento.

Da mesma forma, o descaso no planejamento pode tornar o objetivo da execução algo muito vago e exigir muito da autonomia de pessoas que talvez não estejam aptas para tomar iniciativas ou decisões. Assim, a busca de um equilíbrio no planejamento, permitindo uma visão clara do que é esperado da equipe e além de dar um pouco de autonomia à equipe (de acordo com a maturidade desta), para que esta equipe tenha o poder de planejar a execução das atividades mais específicas e tomar decisões a fim de resolver problemas de pouco impacto que venham a surgir durante a execução.

A atividade de Organização é vítima normalmente do descaso, por não orientar a equipe sobre as responsabilidades de cada elemento e também não definindo as regras que devem ser obedecidas (ex.: como se dará a comunicação com outras áreas da organização, clientes e fornecedores), o que poderá gerar conflitos internos na equipe durante o andamento dos trabalhos, ou conflitos entre a equipe e as outras áreas da organização.

A atividade de Organização permite a equipe entenda suas responsabilidades e as regras para execução das suas atividades. Sendo estas bem definidas, exigirá poucas mudanças durante a execução das atividades, além de suprimir conflitos desnecessários e evitar que determinadas pessoas fiquem sobrecarregadas de atividades.

Se as atividades de Organização e Planejamento não estiverem bem definidas, os problemas serão visíveis na atividade de Execução, resultando em retrabalhos, conflitos, atrasos e não alcançando os resultados esperados pelas suas atividades.

Durante a atividade de Execução, a atividade de Controle permite verificar problemas não esperados ou observar o comportamento e o impacto de problemas previstos, o que possibilita à equipe e ao gestor definir novos planos e se reorganizar a fim de resolver tais ocorrências. Esta atividade requer um pouco de prudência do gestor, pois a falta de controle do que esta acontecendo pode comprometer toda a execução das atividades, e o excesso de controle pode gerar insatisfação por conflitar com a maturidade e a cultura da equipe (hábitos, forma de fazer suas atividades e resolver problemas).

A atividade de Liderança pode sofrer pelo excesso, tornando a figura do gestor mais como um “pai” da equipe, tornando a equipe superdependente do seu gestor. Ou sofrer pelo descaso, onde o gestor não é visto como elemento que merece alguma consideração por parte da equipe ou que visto como uma figura que “só atrapalha, no lugar de ajudar”.

A figura do gestor deve vista de acordo com a maturidade da equipe, na qual deve ser visto como um elemento de auxilio (representante na comunicação com os outros setores da organização, parceiros, clientes e fornecedores) para equipes maduras e que já possuem autonomia, ou como elemento de orientação para que a equipe ainda não madura chegue a desenvolver seus relacionamentos e aos poucos conquistar sua autonomia.

Assim, evitando o excesso ou o descaso com as atividades de gestão na área de TI, será possível alcançar os resultados esperados pela organização, assim como fomentar a maturidade e autonomia da equipe, exigindo do gestor o papel de coordenar a equipe e melhorar os relacionamentos desta com elementos internos e externos da organização.

Rascunho escrito em Setembro de 2011.

A competitividade na busca de uma melhor oportunidade de trabalho

Michael Porter é mundialmente conhecido pelos seus livros e artigos que abordam os temas de Estratégia e Vantagem Competitiva, sendo seu framework das cinco forças para definir a competitividade e a atratividade de determinados mercados, um elemento extremamente importante para o entendimento de como funciona a competitividade do mercado e como agir a fim de sobreviver neste mundo cada vez mais competitivo.

Para relacionar o framework das cinco forças com a gestão de carreira sob a ótica do profissional, é possível identificar como cada uma destas “forças” estão relacionadas à competitividade do mercado na busca de melhores oportunidades de trabalho.

A primeira força, denominada poder de barganha dos fornecedores, que na carreira de um profissional esta relacionada às universidades, centros de treinamento e certificação. Estas universidades e centros de treinamento permitem que o profissional possa adquirir uma formação adequada (matéria-prima) para atuar no mercado, e determinam as exigências e qualificações mínimas para a capacitação dos profissionais.

O poder de barganha das universidades e centros de treinamento e certificação envolve muitas vezes a dificuldade de um profissional desenvolver uma formação que se mostre como um diferencial no mercado, como no caso de graduações, MBAs, mestrados e doutorados em universidades de renome, ou certificações que exijam alto grau de capacitação e experiência.

A segunda força, denominada poder de barganha dos clientes, na gestão de carreiras é possível relacionar aos empregados, que definem requisitos e responsabilidades mínimas para o profissional ser aceito pela empresa, e os benefícios muitas vezes vinculados à escassez da formação e experiência deste profissional.

Dos requisitos, podemos identificar os requisitos essenciais que definem o mínimo que o profissional precisa ter para ocupar determinado cargo (ex.: DBA conhecer SQL, Programador .NET conhecer VB ou C# …) e requisitos complementares e específicos, que diferenciam o que o empregador precisa do profissional para conseguir ocupar o cargo pretendido numa dada empresa, como por exemplo as empresas de atuação internacional exigem profissionais que sabem dois ou mais idiomas, e as empresas que possuem certificações ISO ou CMMI exigem profissionais que tenham experiência em organizações com qualificações semelhantes .

A respeito dos benefícios, estes variam com a escassez e a necessidade do mercado por um profissional com um determinado tipo de formação e experiência, assim como os salários de profissionais de TI que estão hoje acima da média dos profissionais de outras áreas de atuação, devido a atual escassez (lei da oferta e da procura).

A terceira força esta relacionada às ameaças de substitutos, como no caso dos computadores “desktops” que são aos poucos substituídos por tecnologias móveis (notebooks, netbooks, tablets e celulares). No caso dos profissionais, há possibilidade de ser depreciado (ou até mesmo descartado) pelo mercado por não se capacitar e adquirir novas experiências.

Na área de TI é raro ver uma tecnologia ser completamente substituída, pois ao mesmo tempo que surge a necessidade de profissionais que possuem competências em novas tecnologias, também surge a necessidade de profissionais que possuem competências em tecnologias mais antigas, seja para manutenção ou para novas implementações, pois o legado de TI possui uma sobrevida relativamente alta (ex.: COBOL), além de oferecer muitas oportunidades à profissionais que pretendem entrar no mercado.

A quarta força esta relacionada às ameaças de novos entrantes, isso diz respeito na gestão de carreiras à facilidade de profissionais que estão entrando no mercado substituir aqueles já que estavam lá, como por exemplo, os profissionais com baixo nível de capacitação que são substituídos por outros que estão entrando no mercado que já possuem um nível de capacitação equivalente ou requerem salários mais baixos.

A quinta força esta relacionada à competitividade interna do próprio mercado, onde profissionais que possuem capacitações diversas concorrem por melhores empregos, bons empregadores e melhores currículos.

A quinta força pode ser vista sob outra contribuição de Porter, ao analisar como fomentar vantagens competitivas sob a ótica do “custo”, da “diferenciação” e da “especialização”.

Em relação ao “custo” na gestão de carreira, podemos identificar os novos entrantes do mercado como os estagiários e profissionais que conseguem boas oportunidades por exigirem salários relativamente baixos, ou aqueles atuam como consultores ou terceirizados de acordo com as demandas dos empregadores/clientes.

No que tange a “diferenciação”, temos os profissionais que possuem competências dadas como escassas no mercado, como profissionais com experiência e formação que os tornem melhor capacitados que outros.

Sobre a ótica da “especialização”, teremos os profissionais com alto grau de domínio em determinadas tecnologias (ex.: profissionais com certificações MCM, MCA, ITIL Master, OCM) ou que relacionem competências distintas (ex.: gestores de projetos de TI, profissionais de TI que atuam com dados espaciais, desenvolvedores de jogos, analistas de sistemas com formação em engenharia civil ou florestal) se tornando extremamente importantes para determinados ramos do mercado.

Dado este experimento de vincular o conceito de gestão de carreira e ao framework de Porter com a finalidade de definir como se dá a competitividade dos profissionais na busca por melhores colocações no mercado, espero que além do entendimento a respeito do tema, que seja possível ao leitor se identificar no meio deste mundo competitivo e procure através de um bom planejamento de sua carreira uma colocação que permita sua autorrealização.

A arte de combater incêndios

Na época que estive no exército, percebi que era bem comum quando há um incêndio, as pessoas tentando apagar o fogo com extintor de incêndio mirando sobre as chamas, se aproximando demasiadamente do fogo, ou até mesmo indo em direção da fumaça, não sendo capaz de ver nem o que esta tentando apagar, ou utilizando o equipamento errado para apagar aquele tipo de incêndio, piorando a situação ou até mesmo se ferindo.

Pois na urgência de apagar o fogo, não se preocupam em utilizar as ferramentas corretas, se aproximar de forma segura e que permita uma visão adequada da base do fogo para apagar o incêndio com o extintor.

Usando a mesma analogia na área de TI, quando temos problemas nos bancos de dados, sistemas ou servidores, é comum tentar resolver o problema tacando um “balde de água”, sem analisar qual a origem do problema, qual a forma e ferramenta correta para corrigir, verificar as consequências geradas por nossa correção no futuro, piorando muitas vezes a situação, ferindo pessoas, gerando novos indícios de incêndio, ou numa visão menos pessimista, somente apagando o incêndio para acontecer de novo pouco tempo depois.

Planejamento – Evitando incêndios:
A primeira regra para combater incêndios esta em evitar que incêndios ocorram, onde cabem as palavras “preparo”, “prudência”, “fiscalização” e “controle”, visto que é muito comum criar as ditas gambiarras para simplesmente do andamento com os projetos de TI (códigos mal elaborados, análise mal feita, banco de dados mal modelado, regra de negócio mal implementada, testes não realizados, servidor com requisitos inferiores ao necessário, falta de documentação…), e até mesmo falta de preparo da equipe para “o que fazer” e “como fazer” para evitar e agir numa situação crítica. Lembrando que também deve estar preparado para agir em situações que os incêndios podem ocorrer ou até mesmo já possuem data marcada (incêndios planejados).

Análise – Antes de ir ao incêndio:

A segunda regra esta em analisar o incêndio, onde verificamos sua real origem, quais ações devem ser tomadas para extingui o fogo (provisoriamente (corrigindo as consequências) e permanentemente (corrigindo as causas)), analisar os impactos futuros destas ações e comunicar corretamente o que, porque, quando, quem e como devem ser realizadas as ações aos envolvidos.

Organização – Durante e após o incêndio:

Durante o incêndio, se deve agir de forma prudente para não piorar a situação, seguindo corretamente as ações e os processos definidos para extinguir o fogo (usar métodos adequados para a correção, verificar e comunicar problemas não identificados anteriormente, realizar novos testes), comunicar e documentar o que e como foi feito para que os envolvidos (gerentes, desenvolvedores, analistas, suportes…) e as vitimas (fornecedores, clientes…), saibam o que fazer em situações futuras e para evitar novos incêndios.

Comunicação – Em uma situação com muitos focos de incêndio:

Em situações críticas, a priorização adequada das ações e comunicação (antes, durante e depois) é fundamental, para evitar conflitos e agir de forma adequada. Supervisores e coordenadores devem estabeleces uma comunicação clara com a equipe de combate ao incêndio de forma a orientá-los (e não estressá-los indevidamente) e saber o que esta sendo feito, assim como deixar claro aos envolvidos e vítimas sobre o que houve, como e quando estará resolvido.

Referências:

Vídeo:
http://www.youtube.com/watch?v=2hAHe5hOUwY

Imagens:
http://www.destrambelhados.com/wp-content/uploads/2010/01/bombeiro.jpg
http://eletricistaemsaopaulo.files.wordpress.com/2011/03/muita-tomada.jpg

Artigos relacionados:

Alguns mitos sobre o desempenho
https://sqlfromhell.wordpress.com/2011/06/18/alguns-mitos-sobre-o-desempenho

A Gestão da Qualidade na Área de TI
https://sqlfromhell.wordpress.com/2011/06/05/a-gestao-da-qualidade-na-area-de-ti/

Alguns mitos sobre o desempenho

O primeiro mito do desempenho é a ideia de que com mais pessoas é sempre possível fazer mais e/ou mais rápido. Para alguns cenários isso pode ser até válido, por exemplo, um desenvolvedor que realizada uma determinada atividade em x horas, e com dois desenvolvedores, a mesma atividade na metade do tempo. Mas na condição de você ter 10 desenvolvedores em uma única atividade é até possível que a atividade demore muito mais a ser realizada do que por menos desenvolvedores.

Este problema se dá ao fato de existir outras variáveis que influenciam a razão de recurso/tempo/resultado das atividades. Dentre estas variáveis, temos por exemplo, a competência e capacidade de cada um dos envolvidos, a competência do gerente em orientar a equipe, infraestrutura, interação da equipe, padronização dos processos, o fator fatiga/stress (lembrando que pessoas não são máquinas) e até mesmo o fato de uma atividade ter um limite mínimo e máximo de pessoas para ser realizada adequadamente.

O segundo mito é a ideia do desempenho estar relacionado somente com tempo que a atividade é realizada, como no caso, o dev1 realiza uma atividade em 2 horas, o dev2 a mesma atividade em 4 horas, até este momento o dev1 é mais eficiente que o dev2. Mas se a atividade feita pelo dev1 apresentar defeitos nos testes e tiver que ser refeita, a atividade do dev1 poderá custar mais horas, além do desgaste da equipe por apresentar uma atividade defeituosa, isso ainda quer dizer que o dev1 é mais eficiente?

O desempenho esta relacionado realmente à capacidade de realizar atividades ou processos de forma inteligente. Para entender o que seria esta forma inteligente, os inputs para a atividade (como pessoas, custos, tempo, prazo, infraestrutura e pressão) devem ser os mínimos necessários para seus outputs, onde temos os resultados, a qualidade e, satisfação, stress e fatiga dos envolvidos.

Artigos relacionados:

A Gestão da Qualidade na Área de TI:
https://sqlfromhell.wordpress.com/2011/06/05/a-gestao-da-qualidade-na-area-de-ti

A Gestão da Qualidade na Área de TI

Pela minha experiência na área de TI desde 2002 (não oficialmente desde 1998), foram poucas as empresas que conheci realmente comprometidas com a qualidade dos produtos e serviços de TI.

Em relação à área de software, algumas inciativas interessantes eram os chamados testes, estes feitos por pessoas e/ou por sistemas especialistas para este fim. Em relação à área de hardware, era comum verificar se o equipamento estava basicamente funcionando.

Não avaliando o nível de precisão e técnicas destes testes, qual seria o real objetivo deles? Em perguntas a analistas de testes, engenheiros de softwares e gestores, a resposta mais comum que obtive foi identificar problemas (defeitos, erros) para serem corrigidos. Com este tipo de objetivo, o teste só tem a função de encontrar problemas e corrigir antes que vá para “produção”, ignorando cerca de 80 anos de avanços de teorias e técnicas de Gestão da Qualidade.

Por que estaríamos ignorando os avanços da Gestão da Qualidade? Conforme Maximiano, as primeiras iniciativas da área da qualidade existente estavam relacionadas a identificar e tratar defeitos da produção (que antes eram somente vistos quando o produto já estava nas mãos do cliente), ainda nestas primeiras iniciativas, houve a ideia de controle por amostragem, mas todas estas técnicas estavam fadadas a encontrar defeitos.

Com Deming, ainda no inicio da industrialização do Japão do pós-guerra, foram listados 14 princípios para estabelecer a qualidade total, onde teríamos o envolvimento de toda a organização para gerar produtos e serviços com qualidade. Os princípios de Deming eram bem simples, relacionados a necessidade de toda a empresa (vendas, planejamento, fornecedores, operações) assumir a responsabilidade para garantir a qualidade e a cada ciclo.

No ponto de envolvimento de toda a empresa para garantir a qualidade na área de TI, é comum encontrar setores com objetivos distintos na mesma organização, exemplo disso é o setor de vendas vendendo para alcançar suas metas de vendas (esquecendo se a empresa pode realmente fazer o que é esperado pelo cliente pelo preço e prazo estabelecidos), a análise em busca de terminar logo os requisitos, o profissional de infraestrutura e/ou o desenvolvedor (algumas vezes sobrecarregado e sem tempo para se capacitar e melhorar seu trabalho) sofrendo pressão de todos os lados para entregar logo o produto (segundo Deming, o medo e a pressão são pontos que afetam negativamente a qualidade), o analista de testes com o objetivo de identificar erros, quando este profissional existe ou tem tempo hábil para tal.

Com estes objetivos distintos por parte de cada setor da organização não é possível garantir a qualidade, pois temos a falta de envolvimento da empresa com o que realmente é relevante, conforme Feigenbaum, atingir a expectativa do cliente (qualidade), e ao mesmo tempo os interesses econômicos da empresa (pois não vamos vender uma Ferrari pelo preço de um fusca).

Para haver um real envolvimento da empresa com a qualidade, as relações externas da empresa (vendas, análise, pós-vendas) devem estar alinhadas com a produção ou prestação de serviço, para garantir que o que foi vendido seja possível de ser entregue de acordo com as expectativas do cliente (tempo, valor e qualidade).

Com o passar do tempo, outras técnicas e metodologias foram sugeridas para garantir a qualidade, sendo a principal e mais conhecida delas a ISO, onde o foco é o alinhamento dos objetivos da organização e padronização dos processos são pontos essenciais para garantir a qualidade dos serviços e produtos. Na área de TI, temos metodologias mais específicas, como a CMMI e MPS.BR.

Depois do nascimento desta questão da garantia de qualidade, normalmente associada a ‘selos’, como a ISO e CMMI, um modelo de gestão de qualidade que se tornou muito conhecido foi o modelo Toyota, que possui alguns conceitos genéricos utilizáveis também na área de TI, como o ciclo dos ‘5 porquês’, que estabelece que um defeito ou erro deve ser tratado na origem.

Neste clico dos 5 porquês, situações da área de TI podem ser tratadas de forma mais precisa, como o exemplo mais devastador, “o que foi entregue não é o que o cliente pediu” ou “estamos atrasados com a entrega”, onde podemos identificar falhas tanto no desenvolvimento e testes quanto na primeira interação com o cliente com o comercial e a análise, assim no próximo ciclo do processo este erro não acontecerá ou será minimizado seu impacto (melhoria contínua e aprendizado – Kaizen).

Mesmo terminando com um modelo não muito recente de gestão da qualidade, que é o modelo Toyota, é perceptível que há muito conhecimento nestes 80 anos de teorias e técnicas de Gestão da Qualidade, que podem transformar os parâmetros que atuais de qualidade na área de TI.

Estamos com problemas! Mas quem é o culpado?

Na minha infância (sim, eu tive infância), era uma brincadeira comum dizer “Eu corto meu pescoço, mas não digo quem foi…” apontando o dedo para o culpado, mas mesmo quando estamos mais velhos será que ainda “brincamos” desta forma?

A atitude de buscar um culpado pelos problemas é comum na nossa sociedade, mas qual é a utilidade de identificar o culpado? Seria para que o “culpado” explique a causa do problema, a fim de utilizar esta explicação para buscar uma solução, e depois de solucionado, utilizar do conhecimento adquirido para evitar que o problema se repita? Ou simplesmente para se esquivar do problema, amenizando nossa carga de responsabilidade?

Mas porque não resolver o problema? Para esta pergunta temos que conhecer dois pontos comuns do meu, do seu, do nosso egoísmo:

Atitude egoísta número um: “eu sou fruto da minha formação”, logo se eu sou ninguém é culpa do governo, da família, da escola, do trabalho, da religião e outra instituição qualquer ou algum problema que possuo e não posso (ou quero) superar. Esta atitude pode ser denominada “conformismo”, pois é mais fácil se passar de vítima do mundo a sua volta, do que enfrentá-lo! Da atitude de enfrentar o “conformismo” encontramos Homens e Mulheres que mudaram, mudam e mudarão o mundo a sua volta.

Atitude egoísta número dois: “não fui eu que comecei”, logo se meu governo, família, escola, trabalho, religião ou qualquer instituição que julgo fazer parte estão com problemas, eu não farei nada, pois eu não sou culpado. Esta atitude pode ser denominada “individualismo”, pois é fácil deixar o grupo quando grupo esta com problemas, do que ajudar a solucioná-los. Quando deixamos de pensar somente no nosso bem-estar, pensando no bem-estar do grupo, encontramos nosso papel na sociedade, nossa vocação.

Egoísmo é sinônimo de imaturidade, e é muito fácil se conformar com a imaturidade, é só não fazer nada!

Quando nos deparamos com os problemas, ao invés de buscar um culpado para nos esquivar, procuremos a solução destes problemas, e se depois existir um culpado (pessoa que por negligência ou por falta de conhecimento causou o problema ou pessoa mal intencionada), corrija-o para que não aconteça novamente (lembre-se que corrigir não é sinônimo de humilhar).

Não esqueçamos que somos parte de diversas instituições formais e informais (governo, família, escola, trabalho, religião), e mesmo que uma instituição que não façamos parte possua problemas…

“Quando a casa do vizinho está pegando fogo, a minha casa está em perigo.”
Horácio

Carreiras e barreiras, rumo ao crescimento

A carreira de qualquer profissional é marcada por diversas mudanças nas suas competências e carreira, exigindo dele uma dedicação para se atualizar e sempre se especializar na área que atua ou deseja atuar. Mas a atualização e especialização deste profissional encontram algumas barreiras que inibem o crescimento, e muitas vezes estas barreiras são criadas pelas próprias empresas.

Conhecendo as barreiras:

Um das barreiras é dificuldade de determinar sua carreira, tornando o profissional um pouco competente em várias áreas, mas nunca se destacando em nenhuma. No início da formação de qualquer profissional pode ser comum mudanças de funções, áreas e até mesmo de empresas, mas é necessário que ele identifique onde deseja se destacar e lutar por isso, pois a falta de destaque não permite a visibilidade deste profissional nas organizações.

A segundo barreira é a falta de equilíbrio entre as competências interpessoais e técnicas, aqui identificamos os profissionais tecnicamente bons, mas que em alguns aspectos de sua personalidade prejudicam sua própria carreira, até mesmo é encontrado o contrário, como o profissional bem sociável, mas que não tem competências para realizar seu trabalho (algumas vezes se tornando “sanguessuga” das competências alheias).

Falando agora sobre barreiras entre o profissional e empresas, a terceira é caracterizada pelo conflito entre a carreira desejada pelo profissional e a carreira permitida pela organização (ex.: a empresa propõe a gestão de TI, o profissional deseja a arquitetura de software). Esta barreira é um grande motivador para o profissional buscar em outras organizações a realização do seu desejo, pois continuar na mesma organização só será possível seguindo a carreira que lhe é imposta (profissionais que trabalham somente por obrigação, não são elementos saudáveis para a organização, nem mesmo para o próprio profissional). Também há algumas situações na qual o profissional consegue conciliar o seu desejo com a organização que atua, mas este caminho é complicado, pois poderá entrar em conflito com a cultura organizacional.

A quarta barreira é falta de oportunidades para profissionais inexperientes, pois muitos profissionais que atuam em uma determinada área (ex.: desenvolvimento) ou que acabaram de iniciar suas vidas acadêmicas, mas desejam seguir uma segunda área (ex.: gestão de projetos). Pois esta barreia chama “experiência mínima” e “falta de oportunidades de aprendizado” no momento que estiverem buscando uma oportunidade na área que deseja atuar. Esta barreira poderá ser transposta, quando este profissional aproveita as oportunidades de se destacar na área deseja atuar (estágios).

Confrontando barreiras e conciliando desejos:

Empresas que buscam conciliar os desejos de seus profissionais com a oportunidade de crescimento deste na empresa, permitem adquirir a satisfação do seu pessoal, além de desenvolver novas competências. Mas isso não quer dizer que todos aqueles que desejam seguir uma determinada carreira poderão segui-la, visto que existe uma barreira que é caracterizada pelas competências mínimas para atuação na área desejada e outra barreira que determinada pela saturação de uma determinada área de atuação na organização ou no mercado.

A fim de evitar confrontar estas barreiras, muitos profissionais permitem a estagnação de seu sonho, aceitando o que lhe é proposto ou cômodo. Por parte das empresas, a morte destes potenciais tem como resultado a perda da oportunidade de adquirir novas competências e aprimorar as que possuem, e por conseqüência aceitando seu declínio. Mas uma boa comunicação entre a organização e o profissional pode evitar este declínio, mas cabe uma das partes tomar a iniciativa de começar esta comunicação.

Uma forma de evitar o declínio dos profissionais e organizações é a mudança cultural, incentivando a identificação do profissional com a organização e guiá-lo a entender seu papel como colaborador da estratégia organizacional, não iludi-lo, mas torná-lo parte da estratégia.

Impulsionar o profissional para o aprendizado, seja na área de tecnologia, gestão ou simplesmente guiá-los a serem pessoas melhores ou até mesmo cuidar da própria saúde, permitem o nascimento de novas competências, lembrando que é necessário a organização aprender a conciliar os desejos deste profissional com a estratégia organizacional. Com pessoas motivadas por serem parte da estratégia organizacional, a possibilidade de crescimento da organização e das pessoas que a compõe poderá ser imensurável.

“Hoje há um problema: pobre só anda com pobre. As pessoas têm de buscar amigos entusiasmados com o futuro. Se você anda com pessoas que são pessimistas, nunca vai ter nada.” Robert Kiyosaki