Category: Enterprise Strategy*


O que faz com que bons líderes sejam excelentes?


Por Stephen Orban, Head of Enterprise Strategy

“É a falta de clareza que gera caos e frustração. Essas emoções são um veneno para qualquer objetivo existente”. –
Steve Maraboli

Líderes lideram de muitas maneiras diferentes. Alguns pelo medo, outros pelo exemplo, pelo carisma ou por meio de outras pessoas. E embora cada o estilo de cada líder seja um pouco diferente, a experiência me ensinou que algo nunca muda: é mais provável que as pessoas sigam alguém que elas compreendem.

As pessoas acreditam naquilo que são capazes de compreender. Quando se trata de gerenciamento de mudanças, as pessoas tipicamente se voltam para aquilo que estão acostumadas ( o status quo ) quando não’ entendem a direção na qual estão sendo orientadas. Os líderes podem resolver esse dilema fornecendo direções claras e concisas. A habilidade de fornecer clareza quanto aos objetivos é o que separa os grandes líderes dos bons.

Recentemente, escrevi que os executivos de tecnologia de hoje devem considerar-se diretores de gerenciamento de alterações (CCMOTM) ao liderarem a jornada para a nuvem em suas organizações. Além de gerenciar a fusão entre os negócios e a tecnologia, o CCMO também é responsável por fornecer clareza quanto aos objetivos. Isso significa ser capaz de articular a sua estratégia, saber como a sua equipe se encaixa nessa estratégia, onde há e onde não há flexibilidade, manter-se determinado e manter-se paciente.

(more…)

Responsabilidade do CIO atual de mesclar os negócios com a tecnologia

Por Stephen Orban, Head of Enterprise Strategy

 

Na minha última publicação, afirmei que o executivo de tecnologia de hoje precisa desempenhar a função de Chief Change Management Officer (CCMO™ – Diretor de gerenciamento de mudanças) para liderar sua organização durante a Jornada da nuvem corporativa. Esta publicação explora o primeiro dos três temas associados a essa responsabilidade: mesclar os negócios com a tecnologia (gerenciamento total). Os outros dois, esclarecer os objetivos (gerenciamento descendente) e criar novas (quebrando realmente) regras (execução de gerenciamento), serão explorados em minhas próximas publicações.

“Start with the end in mind.” — Stephen R. Covey

Hoje mais do que nunca, os executivos bem-sucedidos de tecnologia devem ajudar seus parceiros executivos a entender como a tecnologia se adapta —  ou melhor ainda, alavanca  —  seus negócios. Ao proporcionar esse conhecimento à organização, seus pares executivos saberão que você tem o comando sobre os objetivos comerciais da organização e é um membro fundamental da equipe executiva.

(more…)

O executivo de TI de hoje é um diretor de gerenciamento de mudanças



Por Stephen Orban, Head of Enterprise Strategy

 

Ao liderar suas organizações na jornada para a nuvem, percebi que há três áreas em que os executivos de TI concentram suas energias. Neste post, ofereço uma visão geral de cada uma e, nas semanas seguintes, falarei sobre elas mais detalhadamente.

Lembre-se de que a jornada é um processo iterativo e que leva tempo. Não se trata apenas de mudar a tecnologia da sua organização ,  mas sim de mudar a maneira como o seu departamento de TI fornece tecnologia e agrega valor comercial. A mudança de tecnologia e o novo modelo de negócios que a nuvem traz oferecem uma oportunidade para que você reveja as funções de trabalho, as finanças, a metodologia de desenvolvimento de produtos e muito mais em toda a sua organização. Essa é uma oportunidade única na sua carreira: a de ser o executivo de TI que impulsionará a transformação para a melhoria do negócio, sejam as suas motivações comerciais financeiras, competitivas ou ambas. Isso significa que é você quem vai determinar o que serve ou não e criar o ambiente mais adequado ao seu negócio.

(more…)

Dois motivos pelos quais o suporte ao cliente é imprescindível para DevOps empresariais

Por Stephen Orban, Head of Enterprise Strategy

Conforme descrevi na minha introdução a esta série de DevOps, o serviço ao cliente é um dos três princípios que eu animo as organizações a levar em consideração ao implementar uma cultura de DevOps.

O mundo de hoje está cheio de soluções de tecnologia. Existe uma miríade de opções disponíveis para todos nós, para preencher praticamente qualquer necessidade. Para aqueles de nós que fornecem soluções de tecnologia, fazer bons negócios não significa apenas fornecer um grande produto, mas também proporcionar um excelente serviço ao cliente. Quanto melhor é o serviço ao cliente, menos provável será que seus clientes busquem soluções de concorrentes.

No sentido mais tradicional, os clientes são as pessoas que compram seus produtos e serviços, como os compradores na Amazon.com ou as empresas que usam AWS.

Dentro da TI de uma empresa, geralmente, seu cliente é alguém com quem você trabalha. Um stakeholder interno poderia ser qualquer pessoa na organização que confia nas diversas tecnologias para que o trabalho dela possa ser feito. Às vezes estão em outro departamento (marketing, vendas, etc.) e às vezes são outros tecnologistas.

Quem consome os produtos e serviços de uma organização de DevOps interna? É claro que a resposta depende, mas muitas vezes serão desenvolvedores de aplicativos e outras equipes de tecnologia na empresa, tendo em vista que geralmente o desenvolvimento mais rápido de produtos é o principal motivador para implementar DevOps centralizados em primeiro lugar. Uma equipe centralizada que colabora e atende nos departamentos será capaz de prever melhor as necessidades e fornecer melhor serviço ao cliente do que alguém que só se preocupa com os desafios que enfrenta, isoladamente.

Existem pelo menos dois motivos para manter o serviço ao cliente em primeiro lugar na sua organização:

(more…)

DevOps empresariais: por que você deve executar o que cria

Por Stephen Orban, Head of Enterprise Strategy

“Você constrói, você executa” – Werner Vogels

É uma cena que todos conhecem: você está passando tempo com a sua família e de repente o telefone rouba sua atenção. A temida campainha avisa de uma falha de SEV1. Seu aplicativo — aquele que sofre sempre de falta de memória e que é “consertado” pela área de Operações reiniciando-0 — está acabando com os recursos do servidor nos minutos que fica online. O aplicativo está realmente inutilizável O pessoal de Operações não está equipado para fazer muito mais além de reiniciar ou fazer uma reversão, mas a última cópia boa já é de alguns meses atrás. Quem sabe tudo o que mudou desde então. Corrigir essa falha depende de você, que está quilômetros de distância do escritório e do seu computador.

Incidentes como este são mais do que comuns em um modelo de TI empresarial tradicional, onde o Desenvolvimento e Operações estão cada um em um lado do muro. Mas isto não precisa ser assim. DevOps não serve só para startups. Também pode ser usado por grandes corporações. Do mesmo modo que a automatização e o atendimento ao cliente, “executar o que você constrói” pode ser um princípio efetivo para melhorar aquilo que a TI de empresas faz usando um modelo de DevOps.

Em uma situação tradicional, os desenvolvedores arquitetam e criam uma solução que depois é passada para Operações. Às vezes, eles são gentis o suficiente para fornecer certa orientação sobre como tratar com questões de produção e às vezes têm pouco ou nenhum conhecimento do ambiente de produção com o qual começar. Quando essas equipes continuam sendo entidades separadas, cada um deles tem pouca informação de como a outra trabalha e o que ela precisa. Muitas vezes, as equipes de Operações têm manuais de execução, SOPs (Procedimentos operacionais padrão) ou algum outro mecanismo para abordar questões conforme elas surgem na produção. Elas podem ser bastante efetivas quando você precisa de uma correção rápida, mas quando as causas raiz não são identificadas e abordadas, é como usar um chiclete para tampar um buraco num barco. Provavelmente, você termina afundando.

(more…)

Está pensando em DevOps na sua empresa?

Por Stephen Orban, Head of Enterprise Strategy

DevOps é um termo relativamente novo para um conceito que, acredito, já existe há muito tempo. Neste momento, é amplamente aceito como uma cultura em algumas organizações, uma confluência entre equipes antes isoladas que juntas podem produzir resultados mais rápidos, mais frequentes e mais confiáveis.

Tive o privilégio de iniciar a minha carreira em uma cultura de DevOps antes do termo se tornar tendência. Quando me tornei um desenvolvedor na Bloomberg em 2001, a empresa já era conhecida por sua busca incansável por um melhor tempo de entrada no mercado, ciclos de desenvolvimento iterativos e desenvolvedores no controle das operações contínuas dos sistemas que eles fornecem. Não levou muito tempo para que os novos desenvolvedores descobrissem a sensação de solucionar problemas de um sistema às 4 da manhã (quando abria o mercado de Londres). Percebi que essas experiências em altas horas serviam como uma grande motivação para tornar os seus sistemas mais robustos.

Os DevOps podem ser intuitivamente óbvios para startups, já que negócios menores podem lidar com eles com relativa facilidade. Porém, para organizações maiores, com quantidades significativas de débito técnico, arquiteturas monolíticas e práticas de negócios avessas a riscos, a tarefa pode ser intimidadora.

(more…)