Do agile ao estabelecimento de uma estratégia de nuvem, essas "melhores práticas do setor" certamente diminuirão suas chances de sucesso na TI
O que faz as organizações de TI falharem? Muitas vezes, é a adoção do que é descrito como “melhores práticas do setor” por pessoas que deveriam saber mais, mas não sabem, provavelmente porque nunca tiveram que fazer o trabalho.
Desde estabelecer clientes internos até instituir estornos e insistir no ROI, muitos desses conselhos parecem plausíveis quando vistos a 15.000 metros ou mais. No entanto, arranhe a superfície e você começará a descobrir que essas receitas infalíveis para o sucesso de TI costumam ser fórmulas para o fracasso.
Leia também: 10 tendências para 2021 e como os CIOs podem se manter à frente
Procurando falhar? Certifique-se de que todos em TI digam a todos fora de TI: “Você é meu cliente. Meu trabalho é superar suas expectativas” (ou, pior, “meu trabalho é fazer você feliz”).
Funcionários fora de TI não são clientes de TI. Eles são colegas de TI, com quem a TI colabora como iguais, se algo de bom acontecer para a empresa como um todo.
Legitimar a ideia de clientes internos coloca a TI em uma posição subserviente, em que todos na área de TI têm que deixar seus colegas felizes, quer isso faça sentido para o negócio ou não, muito menos se incentiva os clientes reais da empresa a comprar mais produtos e serviços.
Quer causar algum dano? Estabeleça acordos de nível de serviço formais (SLAs, na sigla em inglês para Service Level Agreement), insista que seus “clientes internos” os assinem e trate esses SLAs como contratos.
E se você realmente quer que a TI falhe, discuta se você cumpriu seus SLAs toda vez que um “cliente interno” (essa palavra novamente) sugere que a TI não está fazendo o que eles precisam fazer. É uma ótima maneira de manter relacionamentos à distância.
Se você preferir o sucesso, então se lembrará de que os relacionamentos exigem confiança, que a confiança não acontece a menos que você reconheça os colegas como pessoas reais, que se eles gostarem de você, trabalharão com você para consertar o que quer que dê errado, e que o propósito dos contratos não é definir relacionamentos – é definir o que acontece quando não há confiança e algo dá muito errado.
Você os conhece. Os clássicos têm frases de efeito como “Deu branco na tela”, “Deixe-me ver se entendi – você está tendo uma queda de energia e não consegue entender por que seu PC não inicializa” e “eu disse a ele para tentar reverter o plugue de sua impressora … e era um plugue de três pinos (risada)!”
Ria quando outros membros da equipe de TI contarem a eles, especialmente quando eles têm nomes anexados. Ou se você quiser garantir uma falha de TI, conte você mesmo. Dessa forma, vai se espalhar que nem você nem qualquer outra pessoa em TI tem qualquer respeito por outra pessoa.
Isso ajudará a causa.
Leia também: 11 princípios de TI da velha escola que ainda governam
Esta é uma ótima maneira de desencorajar o uso de tecnologia da informação: estornos do instituto. E não apenas quaisquer estornos – aqueles cuidadosamente calculados que geram faturas detalhando cada categoria de despesas que cada centro de custo incorreu, de ciclos de CPU a armazenamento SAN e NAS (separe-os, é claro), horas de desenvolvedor e suporte técnico chamadas, cobradas em incrementos de 10 minutos.
Nada incentiva mais a colaboração do que discutir sobre a exatidão das contas que determinam qual bolso corporativo deve segurar o dinheiro.
Quer ter certeza de que projetos críticos não sejam financiados? Insista em que o processo de governança de TI requer um retorno financeiro claro e tangível do investimento. Fazer isso praticamente garante um declínio para a obsolescência, enquanto a tecnologia que ajuda os departamentos de negócios a fornecer melhores resultados mais rapidamente não é financiada e os projetos que ajudam a aumentar a satisfação do cliente – aumentando as vendas e reduzindo o custo das vendas, mas não de maneiras que a TI pode provar – são desprezados no escritório da esquina, junto com quem os propôs.
Quer uma fórmula para disfunções de negócios/ TI? Defina projetos em termos de entrega de software para que o trabalho de TI seja feito quando o software atender aos requisitos e às especificações.
Dessa forma, quando a gerência de negócios reclama que o software não faz o que eles precisam fazer, você está em uma posição perfeita para argumentar que ele faz exatamente o que deveria fazer, porque atende às especificações, não é? E se isso falhar e o projeto não atender aos requisitos, você pode argumentar que os requisitos estavam errados. E de quem é a culpa? Os gerentes de negócios que os aprovaram, é claro.
Ou você pode fazer o que funciona: começando com a forma como você nomeia seus projetos, defina cada um em termos de resultado comercial (“aumente a eficácia das vendas”), não software (“implemente Salesforce.com”).
É bem conhecido nos círculos de gerenciamento de projetos que todo projeto deve ter um patrocinador comercial ou tem poucas chances de sucesso. Mas quer garantir que um projeto fracasse? Atribua um.
Patrocinadores – patrocinadores reais, não patrocinadores apenas no nome – querem que seu projeto tenha sucesso no fundo de suas entranhas, estão dispostos a assumir riscos se necessário para garantir que seus projetos tenham sucesso e colocar seus nomes e reputações alinhados em relação aos benefícios comerciais de seus projetos. Acha que alguém que foi designado para ser um patrocinador fará essas coisas? Nem eu.
Esta é uma maneira maravilhosa de garantir falha de TI – estabelecer uma estratégia de computação em nuvem. Dessa forma, você pode assumir a conclusão. Você sabe que precisa estar na nuvem, então o objetivo da estratégia é fazer acontecer.
Faça o que fizer, não pense mais amplamente do que isso. Não considere uma arquitetura técnica gerenciada, definida em termos de serviços. Afinal, fazer isso pode levar você a acreditar que os serviços são o que você precisa e que a nuvem pode ser uma forma de provisionar alguns deles.
É uma regra antiga: a forma segue a função. Os serviços são as funções. A nuvem é uma forma que alguns de seus serviços necessários podem assumir. Evite pensar assim, a menos que queira que a TI tenha sucesso. Então é obrigatório.
As metodologias agiles têm muito a seu favor. Um pré-requisito para o sucesso é um alto nível de envolvimento informal do usuário, de modo que as correções de curso sejam frequentes e pequenas, os desenvolvedores vejam o progresso todos os dias e o teste de aceitação do usuário seja uma ocorrência diária.
Offshore tem uma coisa a seu favor: um custo de mão de obra por hora mais baixo. O que não tem a seu favor é qualquer possibilidade de alto nível de envolvimento informal do usuário do qual o Agile depende. Combine uma diferença de 12 fusos horários, barreiras de idioma, um abismo cultural e interações limitadas ao que pode ser tratado com a conferência pela Web, e o Agile é bastante desafiador.
É possível fazer funcionar, mas não é para os fracos de coração, e certamente não é para as organizações de TI que são novatas em Agile.
Quer adotar o Agile? Quer ir Offshore? Escolha um.
O próximo passo para uma falha infalível de TI é insistir que todos façam várias tarefas ao mesmo tempo. Afinal, é uma habilidade altamente desejável, certo? O que realmente significa é reduzir a produtividade e a qualidade enquanto aumenta o estresse na tentativa de fazer mais.
Sempre que você ficar tentado a pedir a alguém que pare o que está fazendo para trabalhar em outra coisa, lembre-se: humanos não fazem multitarefa. O melhor que podem fazer é ir e voltar de uma tarefa para outra. Cada vez que o fazem, perdem tempo trocando as engrenagens mentais e, quanto mais concentração uma tarefa requer, mais tempo perdem quando necessário.
Quer que a TI tenha sucesso? Deixe as pessoas terminarem o que estão fazendo antes de passar para outra coisa.
A TI nunca tem equipe suficiente para lidar com tudo que todos desejam, então faz sentido fazer tudo o que puder para entregar de qualquer maneira, lançando muitos projetos e movendo funcionários entre eles.
Isto é, se você quiser que todos os projetos demorem muito mais, custem muito mais e entreguem resultados abaixo do padrão.
Se você deseja que a TI desenvolva uma boa reputação, estabeleça esta regra: todo projeto que for lançado terá uma equipe completa, com “equipe completa”, o que significa que o projeto nunca vai esperar que um membro da equipe esteja disponível para trabalhar nele.
Faça isso e todos os projetos terminarão antes que qualquer um deles tenha terminado, caso você tenha continuado a fazer malabarismos com todos eles.
Não há dúvida de que, quando os departamentos de negócios desenvolvem sua própria TI, coisas ruins podem acontecer. Esse pode parecer um argumento convincente, mas conta apenas um terço da história. O segundo terço: os departamentos de negócios se envolvem em esforços DIY porque a TI não tem equipe suficiente para resolver os (geralmente) problemas de pequenas empresas que a shadow IT assume. O que coloca a TI na posição incômoda de forçar os departamentos de negócios a fazer tudo no Excel, mesmo quando alternativas superiores estão disponíveis.
Esse é o segundo terço. O terceiro? Boa sorte ao tentar eliminar a shadow IT. É terrivelmente difícil até mesmo identificar o uso comercial de aplicativos baseados em nuvem.
A última e melhor maneira de garantir uma falha de TI é dizer não ou sim, independentemente da solicitação. Diga não e você prejudicará seus relacionamentos. Diga sim, e você estará fazendo promessas que não pode cumprir porque você e todos os outros já têm todo o seu tempo totalmente contabilizado.
A resposta certa se você quiser ter sucesso é: “podemos fazer isso. Aqui está o que será necessário”.
Existe uma regra inviolável de gerenciamento de solicitações, seja a solicitação uma mudança de escopo do projeto, um aprimoramento de software ou o fornecimento de um laptop para alguém que não está programado para receber um: nada é gratuito.
Não diga não. Não diga sim. Explique o que você terá que fazer para atender às solicitações. O que se segue será uma conversa em vez de uma discussão.
Muito melhor.
