12 supostas boas práticas a evitar nas TIC

Considerar os outros departamentos como clientes internos, instituir um sistema de encargos e cobrança e insistir na exigência de ROI, são algumas práticas criticadas por Robert Wilson, autor e consultor na NTT Data Services.

Robert Lewis, consultor na NTT Data

O que leva os departamentos de TI a falharem? Muitas vezes, é a adopção de designadas “boas práticas da indústria” por pessoas que deveriam saber melhor, mas não. Provavelmente porque nunca tiveram que realizar o trabalho em questão.

Desde considerar os outros departamentos como clientes internos, até a instituição de um sistema de encargos e cobrança, até insistir na ideia de ROI, muitos desses pareceres são plausíveis quando são vistos a partir dos 50 mil pés ou mais de “altitude”. Aos raspar-se a camada superficial,, no entanto, começa-se a descobrir que essas receitas de sucesso infalível para as TI são muitas vezes fórmulas para falhar.

Dizer a todos os departamentos internos que são clientes

Está a procurar falhar? Certifique-se de que todos no departamento de TI digam aos outros: “Você é meu cliente. O meu trabalho é superar as suas expectativas (ou, pior, “fazer você feliz “).

Os trabalhadores externos ao departamento de TI não são clientes deste. Eles são colegas dos técnicos de TI, com quem estes colaboram como iguais, se alguma coisa de positivo acontecer para a empresa como um todo.

Legitimar a ideia de clientes internos coloca o departamento de TI numa posição de subserviência, onde todos os profissionais da TI têm de deixar os outros trabalhadores satisfeitos, fazendo sentido ou não para o negócio ou se promove a venda dos produtos e serviços da organização.

Estabelecer SLA e usá-los como contratos

Quer infligir algum dano? Então estabeleça acordos de nível de serviço formal (SLA, sigla em inglês), insista que os seus “clientes internos” os assinem e use esses protocolos como contratos.

E se realmente quer que a equipa de TI falhe, entre em discussões sobre se cumpre os SLA sempre que um “cliente interno” sugere que o departamento de TI não está a fazer o necessário. É uma óptima maneira de manter relacionamentos distanciados.

Se preferir o sucesso, lembre-se de que as relações requerem confiança, e que esta não surge, a menos que reconheça os colegas como pessoas reais, que se gostarem dos técnicos e gestores de TI, trabalharão para corrigir o que está mal, e que o objectivo dos contratos não é definir relacionamentos ‒ é definir o que acontece quando não há confiança e algo está errado.

Conte piadas sobre utilizadores menos informados

Você conhece-as. As mais clássicas têm  remates do género como: “Deixe-me tentar perceber: há uma quebra de electricidade e não consegue perceber a razão pela qual o desktop não funciona!?”

Não deixe de rir quando outros membros da equipa de TI troçam de colegas referindo o nome das pessoas em causa. Ou se você quiser garantir mesmo que o departamento falha, refira você mesmo os nomes. Dessa forma, fica-se a saber que nem você nem qualquer outra pessoa nas TI tem algum respeito por outra pessoa.

Instituir um sistema interno de cobranças

Aqui está uma óptima maneira de desencorajar o uso das TI: instituir um sistema de cobranças pelo das mesmas. E com pormenor: com custos cuidadosamente calculados que geram facturas detalhando cada categoria de despesa que no qual cada centro de custo incorre, envolvendo ciclos de CPU, armazenamento de SAN e NAS (convém separá-los, é claro!), horas de programação, chamadas ao help desk, facturadas em incrementos de 10 minutos.

Nada incentiva mais a colaboração, como discutir sobre a precisão das contas que determinam em que bolso corporativo deve residir o dinheiro.

Insista na exigência de haver ROI

Quer garantir que projectos críticos não sejam financiados? Insista que o processo de governo de TI requer sempre um retorno de investimento (ROI, sigla em inglês) claro, tangível e financeiro.

Fazer isso praticamente garante um deslizamento para a obsolescência, enquanto a tecnologia que ajuda os departamentos de negócios a oferecer melhores resultados mais rapidamente, fica sem financiamento. E os projectos que ajudam a impulsionar a satisfação do cliente ‒ aumentando as vendas e ao mesmo tempo reduzindo o custo de vendas – juntamente com quem os propôs, são alvo de troça no canto do escritório.

“Delegue” a responsabilidade sobre projectos

Quer uma fórmula para a disfunção entre negócio e TI? Defina projectos em termos de entrega de software para que o trabalho de TI seja feito quando o software corresponda aos requisitos e especificações.

Dessa forma, quando o gestor de negócios se queixar de que o software não faz o que é necessário, você está na posição perfeita para argumentar que a tecnologia faz exactamente o que é suposto fazer, porque afinal ele corresponde às especificações, não é? E se isso não funcionar, e o projecto não satisfazer os requisitos, então pode argumentar que os requisitos estavam errados. E de quem é a culpa? Dos gestores de negócio que concordaram com os requisitos, é claro!

Ou, pode fazer o que funciona mesmo: partindo da forma como designa os projectos, defina-os todos em termos de resultado comercial (“aumentar a eficácia das vendas”, por exemplo), e não ligados ao software (“implementar o Salesforce.com”, por exemplo).

Associar patrocinadores a projectos

É bem conhecido nos círculos de gestão de projectos que cada um deve ter o patrocínio do negócio ou haverá poucas possibilidades de ter sucesso. Mas quer garantir que um projecto falha? Atribua-lhe um patrocinador.

Os verdadeiros patrocinadores ‒ não os “patrocinadores só em nome” ‒ desejam que o projecto tenha sucesso “com as entranhas”. Estão dispostos a correr riscos, se necessário, para garantir que os seus projectos sejam bem-sucedidos e colocam os seus nomes e reputação em jogo face aos benefícios comerciais das iniciativas. Pensa que alguém designado como patrocinador fará isso? Eu também não.

Estabelecer uma estratégia para cloud computing

Aqui está uma forma maravilhosa de garantir o fracasso do departamento de TI ‒ estabelecer uma estratégia de cloud computing. Sabe que é preciso usar a cloud, por isso o objetivo da estratégia é fazer com que isso aconteça.

Faça o que fizer, não pense mais do que isso sobre o assunto. Não considere ter uma arquitectura técnica gerida, definida em termos de serviços. Afinal, fazer isso pode levá-lo a acreditar que os serviços são o que precisa e a cloud pode ser uma forma de provisionar alguns deles.

É uma regra antiga: o formulário segue a função. Os serviços são as funções. A cloud é uma forma que alguns dos serviços que necessita podem assumir. Evite pensar dessa maneira, a menos que pretenda o sucesso do departamento de TI. Então passa a ser obrigatório.

Adopte metodologias ágeis e faça offshoring ao mesmo tempo

As metodologias ágeis têm muitos argumentos a favor. Um pré-requisito para o sucesso é um alto grau de envolvimento informal do utilizador para que as correcções nos projectos sejam frequentes e pequenas.

Os programadores vêem o progresso todos os dias e os testes sobre a aceitação pelo utilizador ocorrem diariamente. O offshoring tem outra solução para isso: um custo horário inferior do trabalho.

O que não tem é qualquer possibilidade de haver alto grau de envolvimento informal, da qual as metodologias Agile dependem, com o utilizador.

Combine a diferença horária, barreiras linguísticas, um abismo cultural e a limitação de interacções ao que pode ser tratado por videoconferência e as Agile tornam-se bastante desafiantes. É possível fazer o método funcionar, mas não é para os mais fracos de coração. E certamente não é para as organizações de TI inexperientes em Agile.

Quer adoptar Agile? Quer usar offshoring? Opte por um.

Interromper interrupções com interrupções

O próximo passo para garantir falhas das TI é insistir que todos os profissionais entrem modo de multi-tarefa. Afinal, é uma aptidão altamente desejável, certo? Mas isso realmente significa reduzir a produtividade e a qualidade, aumentando o stress na tentativa de fazer mais.

Sempre que tentar pedir a alguém para parar o que está fazer, de maneira a trabalhar noutra coisa, lembre-se: os seres humanos não forma feitos para o modo multi-tarefa. O melhor que podem fazer é ir e voltar de uma tarefa para outra.

De todas as vezes que o fazem, perdem tempo a “meter outra mudança mental”, e quanto mais concentração exige uma tarefa, mais tempo eles desperdiçam ao fazer essa alteração.

Quer que o departamento de TI tenha sucesso? Deixe as pessoas terminarem o que estão a fazer antes de passarem a outra coisa.

Lance múltiplos projectos confiando no modo multi-tarefa

Nunca há funcionários no departamento de TI para executar tudo o que todos querem, por isso faz sentido fazer tudo o que puder para entregar aquilo que se pretende de qualquer maneira, lançando muitos projectos e mudando profissionais de uns para os outros.

Mas só se quiser que todos os projectos demorem muito tempo, custem muito mais e entreguem resultados medianos.

Se pretende que o departamento desenvolva uma boa reputação, estabeleça esta regra: todos os projectos que lançar terão uma equipa completa, e isto quer dizer que nunca ficará à espera de um dos profissionais se tornem disponíveis para trabalhar nele.

Dizer não ou sim, independentemente do pedido

A última e melhor maneira de garantir falhas de TI é dizer não ou sim, não importa o pedido. Diga não e danifique as suas relações dentro da empresa. Diga sim, e está a fazer promessas que não poderá cumprir porque você e todos os outros já têm todo seu tempo totalmente ocupado.

A resposta certa, se você quer ter sucesso, é: “Podemos fazer isso, aqui está o que será necessário…”.

Existe uma regra inviolável na gestão de solicitações, seja o pedido de mudança de âmbito do projecto, uma melhoria de software ou o fornecimento de um laptop a quem não é suposto receber: nada é gratuito.

Não diga não. Não diga sim. Explique o que tem de fazer para satisfazer os pedidos. Seguir-se-á uma conversa e não uma discussão.

* Em 2001, Robert. Lewis fundou a IT Catalysts, uma consultora especializada em mudança de negócios, eficácia organizacional de TI e integração de TI e negócio. É autor de vários livros que abordam os referidos temas.




Deixe um comentário

O seu email não será publicado