Atualmente, a maioria das grandes organizações já iniciou programas de transformação em resposta a mudanças nos cenários de clientes, competitivos e regulatórios. Se as transformações forem classificadas como ágeis, digitais ou de DevOps, sua premissa fundamental é criar valor estabelecendo ciclos de feedback curtos e frequentes entre produto e clientes, que melhoram significativamente o produto e seu time-to-market.
A tecnologia desempenha um papel crucial na viabilização de uma abordagem mais rápida e flexível. Porém, nossa experiência revela que a tecnologia não recebe a devida atenção na agenda dos executivos. Essa é uma falha grave considerando a importância da tecnologia na realização de transformações digitais bem-sucedidas.
Pode haver muitas razões para essa falha, mas um dos principais responsáveis é a percepção que se tem da tecnologia como uma “coisa de especialista” e a dificuldade que os líderes de TI costumam ter para comunicar assuntos de tecnologia de uma forma engajadora para quem não é de tecnologia. Essa realidade costuma levar a “antipadrões”: soluções ineficazes para problemas. Os antipadrões têm algumas consequências graves e, alguma vezes, fatais para as transformações tecnológicas.
Neste artigo, sintetizamos 10 dos antipadrões de tecnologia mais frequentes que observamos em transformações em mais de 50 grandes organizações. Quantos você reconhece na sua organização?
Escolhas de tecnologia
1. Forçando soluções de tecnologia: Você está escolhendo tecnologia fora do contexto?
Cuidado para as decisões de tecnologia não atraírem atenção do negócio além do custo e uma discussão superficial sobre “escalabilidade/alinhamento estratégico”. Por exemplo, em muitas organizações ouvimos sobre uma abordagem de “microsserviço primeiro”. Embora os microsserviços sejam um componente crítico de muitas jornadas de modernização de TI, eles não se encaixam em todas as circunstâncias.
Em uma grande empresa, os arquitetos da transformação sugeriram uma abordagem que desenvolvesse microsserviços para uma aplicação de cliente. Porém, microsserviços são uma arquitetura fundamentalmente de servidor. Os arquitetos estavam simplesmente respondendo a uma solicitação organizacional para que a empresa se tornasse tecnologicamente moderna. Porém, como a instalação e a gestão de uma aplicação de cliente seriam muito mais complexas devido a uma série de componentes independentes que exigiriam um trabalho conjunto ininterrupto, a abordagem teria resultado em custo e complexidade significativos sem gerar um benefício adicional.
Recomendação
Os líderes precisam levantar a mão e fazer perguntas “bobas” para entender completamente o racional e o suposto benefício das opções recomendadas de tecnologia. No exemplo anterior, algumas perguntas simples de um executivo, começando com “explique microsserviços para mim como se eu tivesse 8 anos”, poderiam ter economizado milhões para a empresa!
2. Adotando a última tecnologia, que ainda não está totalmente madura: Você está adotando novas tecnologias que parecem ser promissoras, mas não têm um histórico comprovado de sucesso?
Com estabilidade e escalabilidade como dois elementos de foco de qualquer área de TI, uma due diligence e uma tomada de decisão muito cuidadosas são necessárias para evitar a adoção de tecnologias que ainda não são maduras. Os líderes devem ter cautela com qualquer recomendação de tecnologia que seja apresentada, principalmente por estar na moda ou por prometer atrair novos talentos.
Um banco líder de mercado lançou um grande redesenho de sua aplicação para clientes usando o último framework front-end web como stack da solução de software. Essa aplicação foi anunciada como uma tecnologia de longo prazo que atrairia novos talentos. O projeto sofreu vários atrasos e o custo estimado foi ultrapassado diversas vezes porque os funcionários não tinham as competências necessárias, exigindo tempo e dinheiro para qualificá-los. Finalmente, o projeto foi entregue depois de 2 anos – 18 meses de atraso.
Outro grande banco decidiu reescrever seus principais sistemas contábeis, que já tinham mais de 20 anos. Embora os sistemas existentes fossem limpos e extensíveis, o banco desejava usar a última tecnologia em data-store. O projeto foi arquivado depois de um investimento de mais de €100 milhões porque a nova tecnologia não era estável e a arquitetura criada para ele tinha várias falhas críticas.
Recomendação
Escolha tecnologias simples e de eficácia comprovada que seus funcionários conheçam.
3. Desenvolvendo sua própria infraestrutura de nuvem sem ter as competências necessárias: Você deixou a segurança e a regulação bloquearem sua adoção de nuvem pública?
As empresas estão buscando aproveitar as novas plataformas e tecnologias de infraestrutura, como orquestradores de contêineres, plataformas sem servidor e soluções de analytics. Esses são componentes complexos de tecnologia que grandes provedores de nuvem estão constantemente evoluindo em termos de competências e redução no ponto de preço, a fim de vencer no mercado.
Se fornecer infraestrutura de nuvem não for seu negócio principal, será impossível combinar os provedores de nuvem com os talentos necessários para desenvolver e gerenciar essas plataformas de forma escalonável, eficiente e segura. Além disso, seus concorrentes (digitais) utilizarão esses provedores para possibilitar que eles operem em um ponto de preço totalmente diferente. Em uma grande empresa de serviços financeiros, identificamos 4 diferentes iniciativas de nuvem privada – infraestrutura convergente, OpenShift, Mesos/Marathon e OpenStack – cada uma buscando atingir escala e competindo por talentos. Após muitos meses, a empresa interrompeu os programas e optou adequadamente por soluções de nuvem pública. Este é apenas um dos mais de 50 exemplos de iniciativas de nuvem privada que não tiveram sucesso, normalmente após investimentos milionários.
Recomendação
Concentre os seus investimentos de IT-for-IT em nuvem pública. Comece adotando apenas um dos grandes provedores de nuvem pública para executar seus trabalhos de aplicações. Não busque uma abordagem multinuvem em primeiro lugar, pois todas as grandes plataformas diferem significativamente em configuração e uso e requerem esforço e investimento desordenados para uma configuração customizada similar. Para ferramentas de TI, utilize soluções SaaS como sistemas de fluxo de trabalho, gerenciamento de código fonte, integração contínua e plataformas de colaboração tanto quanto possível. Para os trabalhos que você precisa manter localmente, utilize padrões de infraestrutura que você conhece e pode operar seguramente em escala.
Roadmap de tecnologia
4. Iniciando programas de substituição de grandes sistemas: Você está se concentrando na substituição de sistemas em vez de melhorar os existentes, buscando mais rapidez e melhor relação custo-benefício?
Projetos de substituição de sistemas são complexos, caros e arriscados por natureza. Eles também tiram o foco da empresa de desenvolver competências centradas no cliente e recursos no curto a médio prazo. Consequentemente, projetos de substituição de grandes sistemas devem ser evitados, a menos que todos os outros caminhos não tenham viabilidade comprovada.
Um grande banco considerou a substituição de um sistema essencial principalmente porque estava utilizando Linux em hardware legado. Porém, muito rapidamente no projeto de substituição o banco percebeu que o sistema existente era imediatamente transferível para novas plataformas, incluindo nuvem pública. Além disso, atualizar o código monolítico original implicaria muito menos custos, esforço e risco que substituir todo o sistema. Consequentemente, após a análise inicial, o banco decidiu chegar à meta do negócio modernizando gradualmente o sistema existente por uma fração do custo estimado de substituição de todo o sistema.
Recomendação
Antes de iniciar uma substituição de grande sistema, faça as seguintes perguntas:
- Você ainda pode melhorar o antigo sistema em vez de substituí-lo?
- Se você puder construir um novo sistema, ele criará valor incremental para os seus clientes conforme ganhe escala ao longo do tempo?
- É possível abandonar gradativamente o antigo sistema?
5. Focando em melhorias de arquitetura e ferramentas sem melhorar o processo e a disciplina de entrega: Você rearquitetou e implementou novas ferramentas, mas se esqueceu de adaptar os processos de entrega?
Uma das maiores fontes de impacto em transformações de tecnologia vem da simplificação do processo de produção, que envolve os passos desde a definição de requisitos para o lançamento de um software e o uso do software com repetição disciplinada pelas equipes. Esse movimento de simplificação requer muita paciência organizacional e dos executivos, pois as equipes impactadas – desenvolvimento de app, operações, segurança, suporte – podem levar semanas ou meses para chegar a uma sincronia perfeita. Mudanças em arquitetura e ferramentas podem ajudar, mas, para serem eficazes, precisam acompanhar as mudanças nas práticas de engenharia, processos e comportamentos. Lançar programas de grandes mudanças de arquitetura e ferramentas costuma exigir esforço mínimo, captura a imaginação dos executivos e do conselho e mostra um avanço. Porém, nossa experiência revela que, sem mudanças em práticas de engenharia, processos e comportamentos, esses programas atingem pouco ou nenhum impacto.
Um grande banco percebeu, depois de muitos anos de investimentos significativos em desenvolvimento, lançamento e ferramentas de colaboração, que não havia melhorado o time-to-market e havia conquistado apenas uma baixa taxa de adoção. Depois de meses de incentivos e provocações da liderança sem qualquer resultado, o banco redirecionou o foco para a forma como as ferramentas promoviam um novo conjunto de práticas de engenharia e colaboração entre as equipes. Esse redirecionamento mostrou como as novas ferramentas podem simplificar o processo de produção. Em uma última verificação, mais de 40% das equipes foram apresentadas às novas ferramentas e houve uma melhoria significativa no time-to-market e na adoção tática de ferramentas. Em um exemplo semelhante, um grande banco europeu acelerou consideravelmente a entrega focando em uma compreensão clara e comum de todos os componentes do processo de entrega, definindo um ritmo rígido de execução e simplificando alguns dos documentos e aprovações necessários para liberar o software para produção.
Recomendação
Para melhorar a velocidade de entrega, comece criando um baseline do processo de produção para identificar pontos fortes e deficiências. Siga esse caminho simplificando o processo e os recursos de entrega e tratando de deficiências relevantes por meio de mudanças na arquitetura e ferramentas, conforme as exigências. Quando o novo processo estiver formalizado, garanta que as equipes adotem um ritmo de repetição disciplinada.
Gestão de tecnologia
6. Focando na produção em vez dos resultados do negócio: Os seus profissionais de tecnologia estão focados na produção em vez do resultado do negócio/tecnologia?
As suas metas de tecnologia são muito...tecnológicas? A área de tecnologia articula claramente e monitora as metas centradas no cliente? Se a resposta para qualquer uma dessas perguntas for pelo menos uma leve pausa para refletir, você deve ir mais a fundo.
Profissionais de tecnologia bem-intencionados, mesmo em organizações centradas no cliente, normalmente falham ao focar em produção de tecnologia. Essa produção é facilmente mensurável, motivadora e bastante “sob controle”. Como exemplos, podem ser mencionadas a quantidade de filtros entregues, as funcionalidades implementadas e os defeitos corrigidos. As métricas de resultados de tecnologia podem ser ótimas, mas, a menos que você esteja medindo o impacto direto da tecnologia nos clientes, elas não são muito relevantes. Em uma grande instituição financeira, o grupo de desenvolvimento de apps focou em 100% de automação de testes como resultado-chave e comemorou o resultado – e o fechamento – quando atingiu esse percentual. Porém, os testes duraram tanto quanto antes e não houve melhoria no tempo em que o produto chega ao cliente.
Recomendação
- Os líderes do negócio e de tecnologia precisam definir uma responsabilidade conjunta pelos resultados:
- Resultados do negócio: uso de seus produtos (número de clientes, uso diário) e satisfação do cliente (pontuações líquidas de promotores, número de solicitações de suporte).
- Resultados de tecnologia: disponibilidade/segurança funcional de seu produto e eficiência do desenvolvimento (frequência de lançamento, trabalho).
- Faça com que os profissionais de tecnologia e do negócio articulem resultados técnicos e comerciais específicos e mensuráveis em vez de produção de tecnologia. A mágica das equipes de produto e multidisciplinares está na compreensão das contrapartidas entre os diferentes resultados de negócio e tecnologia e na capacidade de fazer escolhas conscientes sobre o que priorizar para equilibrar os objetivos de curto prazo com a saúde do produto no longo prazo.
7. Gerenciando TI puramente por custo: Você está sacrificando valor significativo ao superavaliar preço e custo?
Gerenciar TI puramente como um centro de custo é uma mentalidade desatualizada que pode ter consequências danosas, que vão da incapacidade de atrair os talentos certos até o uso desaconselhável de tecnologias e plataformas críticas e caras. Por exemplo, contratar ou terceirizar principalmente em função do preço normalmente resulta na contratação de talentos medianos.
Uma empresa de serviços financeiros pagou a seu provedor diárias a valores baixos e o provedor “recuperou” os descontos trazendo funcionários com pouca experiência e inflacionando estimativas sobre o que seria necessário para entregar certos recursos. O resultado foi um código de qualidade muito baixa e longos tempos de ciclo.
Recomendação
Em vez de gerenciar o TI interno como um centro de custo, considere as seguintes recomendações para decidir como definir e alinhar incentivos de eficiência:
- Agregue competência à discussão sobre o custo dos talentos. Algumas empresas definiram um modelo unificado de competências, englobando iniciantes e especialistas, para engenheiros e provedores. A precificação dos provedores é discutida em termos de “equivalentes iniciantes”, reconhecendo que as diferenças de produtividade entre engenheiros em início de carreira e especialistas são um fator de 8 a 10.
- Crie uma visão real de custo total de propriedade de seus produtos para tomar decisões sensatas com relação às contrapartidas sobre investir em novos recursos, promover automação ou otimizar infraestrutura.
8. Investindo no desenvolvimento de novas plataformas sem envolver o negócio: Seu foco principal é o desenvolvimento da plataforma em vez da adoção da plataforma pelo negócio?
As áreas de TI acertam ao empregar esforços e recursos significativos à construção e implementação de plataformas robustas. Porém, frequentemente o negócio não participa do desenho e do desenvolvimento da plataforma, criando novas plataformas com relevância mínima para o negócio, o que leva a uma baixa adesão.
Um grande banco dos EUA fez um investimento multimilionário em um data lake, a fim de torná-lo o eixo de uma cultura de dados em primeiro lugar. Como um projeto de organização de dados em TI, ele foi elaborado, desenhado e desenvolvido sem engajamento do negócio. O data lake foi entregue com um pequeno atraso. Mais de um ano depois, o banco ainda estava tentando fazer progresso capturando casos de uso que o data lake apoiava. Além da plataforma não utilizada, a área de dados sofreu um significativo turnover de funcionários devido à baixa moral nas equipes. O banco recentemente lançou diversos programas para atualizar o data lake e atender às necessidades do negócio.
Recomendação
Comece e termine a discussão sobre todas as plataformas de tecnologia com o problema de negócio que elas abordarão. Concentre-se totalmente nessa discussão e garanta que todos os stakeholders do negócio e de tecnologia assumam responsabilidade conjunta pela entrega de valor da plataforma ao cliente. Ao construir sua plataforma, busque elaborar casos de uso e, em vez de dedicar tempo desde o início a implementar capacitadores, procure refatorar partes da plataforma quando incorporar mais casos de uso.
Gerenciando profissionais de tecnologia
9. Terceirizando suas principais fontes de receita: Os provedores estão fazendo o trabalho que cria o maior valor para o negócio?
Se o seu conhecimento da principal tecnologia ou propriedade intelectual (PI) é terceirizado (através de acordos de offshoring ou contratação de provedores), existem os riscos de limitar o impacto de qualquer futura transformação e de ter de um grau nocivo de dependência de um terceiro. Pelo fato de a terceirização ter se mostrado uma ferramenta eficaz para reduzir o custo de atividades comoditizadas, alguns líderes expandiram seu escopo em resposta a pressões de custo e terceirizaram subgrupos inteiros ou plataformas críticas. Essa dependência limitou severamente as organizações em escolhas ousadas de estratégia e parceiros, principalmente porque elas têm pouco ou nenhum controle sobre sua própria PI.
Por exemplo, em uma grande seguradora, 90% da área de TI foi terceirizada para diferentes provedores. Durante a transformação, a seguradora percebeu que uma das principais razões da baixa performance é que o conhecimento de seus três principais sistemas se concentrava em três pessoas de provedores diferentes. E, para agravar o cenário, eles nunca se falavam.
Recomendação
Defina limites claros para a terceirização de tecnologias e atividades críticas para o negócio. Se atualmente você está terceirizando fortemente atividades críticas, alinhe com seus pares e o conselho um plano de internalização progressiva.
10. Formando um exército de gerentes em vez de desenvolver uma cultura de engenharia: Você valoriza mais seus gerentes que seus engenheiros?
O crescimento de carreira na maioria das organizações normalmente implica na gestão de pessoas. Gradualmente, os funcionários talentosos que já demonstraram grande compromisso com a tecnologia passam mais tempo gerenciando pessoas e atividades administrativas que exercendo a engenharia. Eles se tornam gerentes em tempo integral. Ao longo do tempo, eles perdem a habilidade de participar de discussões técnicas aprofundadas com suas equipes, liderar resolução de problemas técnicos e inovação e, o mais prejudicial: gerenciar efetivamente a performance da equipe baseando-se em mérito técnico. Consequentemente, as organizações têm um grande grupo de TI que apresenta baixa performance consistentemente e tem pouca responsabilidade e orientação técnica.
Uma grande instituição financeira lançou um programa para reformular seu processo de gestão de performance e identificou que, em média, os gerentes passam menos de uma hora por semana em discussões técnicas com suas equipes. Isso soa familiar?
Recomendação
Dê aos gerentes de tecnologia responsabilidades específicas pela gestão de tecnologia. Incentive uma cultura de especialidade tecnológica para os gerentes por meio de incentivos monetários e não monetários. Para construir uma cultura de engenharia, defina critérios granulares de avaliação de performance para os profissionais de tecnologia dedicados a entrega e expertise.
Identificar e abordar esses desafios requer um esforço orquestrado, com foco e responsabilidade das lideranças do negócio e de tecnologia. Como cada vez mais as organizações lançam e amadurecem suas transformações digitais, os executivos devem analisar qualquer evidência dos antipadrões acima e agir urgentemente para abordá-los. Somente então as transformações tecnológicas poderão evoluir suficientemente para apoiar o resultado triplamente mais comemorado: entrega mais rápida centrada no cliente, crescimento do negócio e funcionários mais satisfeitos.