Home > Gestão

5 passos para fazer a mudança da TI para uma mentalidade de startup

Para empresas que buscam vantagem, a abordagem de uma startup pode cair como uma luva. Mas o caminho para a mudança é desafiador e não é para todos

Terena Bell, da CIO (EUA)

02/05/2019 às 10h33

mulheres empreendedoras startup.jpg
Foto: Shutterstock

Startups e empresas pensam de forma diferente – e por boas razões. Um negócio com dez funcionários pode se mover muito mais rapidamente do que um com 10 mil. As empresas geralmente oferecem suporte a vastas coleções de sistemas legados e possuem uma base de clientes existente para servir. E, embora normalmente tenham mais dinheiro à sua disposição, eles são mal-sucedidos por serem rígidos, menos inovadores e iniciantes para a disrupção.

Assim, na esperança de permanecer competitivo, os stakeholders e os C-Levels pressionam as equipes de TI corporativas a agir como startups. Às vezes a mudança de mentalidade funciona: Phil Wiser, CTO da CBS, transformou seu ex-empregador, Hearst Communications, como CTO de uma empresa para uma mentalidade de startup ao longo de seis anos, diz ele, uma transição que tornou as operações de tecnologia mais lucrativas.

Na empresa de seguros Liberty Mutual, o CIO James McGlennon concorda, dizendo que o pensamento de startup melhora a “automação e otimização de uma perspectiva de eficiência” e ajuda a empresa a se destacar dos seus concorrentes.

Uma mentalidade de startup pode não ser benéfica para todas as organizações. Mas se sua equipe está procurando essa vantagem [de startup], aqui estão vários passos e metodologias importantes dos líderes de TI que fizeram a mudança com sucesso.

Determinar se a mudança é realmente necessária

Frases de efeito como “erre rápido”, “pivô” e “quebre as coisas” fazem as startups parecerem legais, mas isso não significa que as grandes empresas precisam adotá-las. Debbie Barta, vice-presidente sênior de inovação e engajamento de startups da Mastercard Labs, alerta os executivos contra a mudança para o que ela chama de mentalidade “bipolar” de boa startup e empresa ruim: “não se trata de extremos”, ela diz, explicando que existem prós e contras para as grandes e pequenas mentalidades operacionais. Por exemplo, diz Debbie, o fato das corporações estarem mais estabelecidas, as torna melhores para evitar riscos, enquanto as startups são mais habilidosas em “criar tecnologias rápidas e ágeis”.

Na Mastercard Labs, a executiva se esforça para o intermediário satisfeito, identificando “coisas que podemos aprender com startups e a mentalidade e a natureza ágil do que eles fazem”, então executa a ideia através das lentes corporativas mais maduras.

Projetos mais recentes como blockchain, realidade aumentada e internet das coisas (IoT) são “coisas que são talvez mais suposições do que conhecidas”, ela explica, “coisas que são um pouco mais arriscadas, que nos obrigam a estar em um modo rápido mais ágil para testar e aprender”. Então, olhe criticamente para seus projetos para determinar quais precisam de uma reformulação e quais não precisam.

Quando o McGlennon da Liberty Mutual avaliou suas necessidades organizacionais, percebeu que todo o desenvolvimento precisava ser acelerado: “descobrimos que a abordagem geral para a construção de software com as metodologias em cascata e as portas e requisitos de estágio, seguido pelo design, seguido pelo desenvolvimento, seguido por teste, seguido por blah, blah, blah era muito lento”. Como resultado, a Liberty Mutual transferiu 88% de seu trabalho de tecnologia para ágil.

Abrace e espalhe a mudança estrategicamente

É fácil olhar para esses 88% e presumir que a Liberty Mutual simplesmente ainda não mudou seus projetos restantes. A mudança atual, diz McGlennon, levou quatro ou cinco anos. “[Há] o escopo, o desafio de transformar e... essencialmente a requalificação de uma equipe de mais de 5 mil pessoas”, explica, “é uma espécie de batalha e um desafio todos os dias”.

Mas os 12% dos projetos que ainda usam cascata foram deixados dessa maneira intencionalmente. O objetivo final de McGlennon é, eventualmente, ter todas as equipes ágeis, mas, enquanto isso, a Liberty Mutual trabalha com 4 mil a 5 mil aplicativos, muitos dos quais, como servidores herdados, que têm décadas de existência. Esses programas “não se prestam à integração contínua [e] aos pipelines de implantação contínua”, explica ele, e não foram feitos para facilitar a transição. Mas com o software de planejamento de recursos empresariais (ERP) da empresa, tecnologia de recursos humanos e outros sistemas de back office agora sob agilidade, McGlennon afirma: “podemos ver as soluções ganhando vida muito rapidamente.”

Os desenvolvedores restantes da Liberty Mutual continuam trabalhando iterativamente, em esquadrões e em equipes menores e multifuncionais. McGlennon também removeu as barreiras operacionais e de comunicação usadas para separar os grupos de negócios e tecnologia da seguradora. Até mesmo os desenvolvedores que não usam o Agile são solicitados a pensar dessa maneira, concentrando-se em “quais eram as prioridades e [a necessidade] em alterá-las se isso eram o que os dados diziam”, diz McGlennon. “Queríamos ter certeza de que tentamos instrumentar nossa tecnologia para entender o feedback e escalá-lo se funcionasse, ou desligá-lo caso não funcionasse”.

Aqui, vitórias rápidas ajudam a tornar o caso de negócios. “Quando você tem um sistema totalmente desvalorizado em algum lugar e você vai até o presidente desse grupo e diz que precisa expeli-lo e colocá-lo nesse novo sistema, isso exige que eles internalizem o valor dessa mudança em andamento”, diz Wiser da CBS. Os líderes de tecnologia precisam provar que as mudanças de que precisam são inteligentes, não apenas tecnicamente, mas financeiramente. “Qualquer divisão que não queira adotar o que você está trazendo, você pode desenvolver uma razão econômica para não fazê-lo”, acrescenta ele, então esteja preparado para dar-lhes o melhor.

No final, se o caso de negócios não convencer o conjunto de executivos, tente segurança. Segundo Wiser, “uma das maiores ameaças em termos de segurança cibernética são sistemas de software desatualizados”.

Mantenha o foco

Quando as startups dividem o foco, elas morrem. A percepção pública possível é que eles são baseados em capital de risco, com investimentos transbordando, mas apenas 6% realmente recebem financiamento externo. A maioria das startups opera apenas com o dinheiro que ganham. Eles não podem se dar ao luxo de desenvolver vários projetos de uma só vez.

Da mesma forma, diz Wiser, se a tecnologia corporativa tenta fazer demais, ela também irá falhar. Não porque as portas da empresa serão fechadas, mas porque os projetos não receberão o aposta inicial exigida pela alta administração. “A comunicação é fundamental e isso realmente requer foco. Se você entrar e tiver sua lista de 20 grandes objetivos para o ano, você irá fracassar”, diz Wiser. Então, em vez disso, ele recomenda que os executivos de tecnologia “sejam muito sistemáticos, escolhendo uma transformação de cada vez”.

Como conglomerado, Hearst é tão grande que tem 50 CTOs. O papel de Wiser era supervisionar a Hearst Communications, uma divisão somente de tecnologia que desenvolveu projetos, os quais depois foram ‘vendidos’ para as unidades de negócios da Hearst. Embora a busca por blockchain e outras tecnologias barulhentas fossem tentadoras, eles simplesmente não conseguiram fazê-los. Para priorizar, a Wiser dividiu os projetos em uma das quatro categorias: investimento de exploração, observação, protótipo ou fluxo de caixa. Isso permitiu à Hearst ficar de olho na tecnologia que poderia precisar no futuro, mantendo o foco firme.

Construa mais, desenvolva menos

Quando você tem uma grande equipe de tecnologia interna, é tentador apenas criar os aplicativos de que precisa. Afinal, qualquer empresa conhece melhor as suas necessidades, e a personalização interna de software pode impedir o inchaço dos recursos, garantindo que a nova tecnologia atenda às necessidades do negócio. Porém, McGlennon diz que não, porque nem sempre você precisa.

Tome chatbots como exemplo – tecnologia que pode levar meses ou anos para se desenvolver do zero, diz Ashok Kumar, CTO da transformação digital da Verizon. A Verizon passou uma década construindo vários bots, mas as startups não têm dez anos. Para economizar tempo, eles geralmente pegam carona na tecnologia existente. Assim, quando a Liberty Mutual quis criar um único chatbot para as reclamações dos consumidores, os engenheiros usaram os produtos da Amazon Web Services, Lambda, Connect e Lex, para avançar. Hoje, o bot processa mais de 150.000 chamadas de clientes por mês.

Entre com mínimo antes de comprometer demais

‘Construa rápido, falhe rápido’ soa brega, mas é o mantra das startups por um motivo: assim como as empresas menores não podem dividir o foco, elas não têm tempo para construir a coisa errada. Em vez de aperfeiçoar o software antes de lançá-lo, as startups criam produtos viáveis mínimos (MVP). Sua interface de usuário é geralmente complicada, e essas versões elementares não têm sinos nem assobios, mas dão às startups algo para serem lançadas rapidamente, a fim de aprender com a resposta inicial do mercado.

Para engenheiros que estão acostumados a apresentar o chefe com algo perfeito, isso não é fácil. McGlennon aponta: “você está falando sobre mudar drasticamente o comportamento das pessoas e estabelecer novas expectativas para o que está funcionando”, ajustando suas ferramentas diárias, processos e abordagens “e é difícil para todos abraçar todos ao mesmo tempo”.

Para ajudar a equipe a se sentir confortável com a mudança, a Liberty Mutual definiu as expectativas com antecedência, dizendo aos funcionários “que tudo bem se falharmos em coisas diferentes”, conta McGlennon. Mas ele também diz para os líderes tecnológicos esclarecerem as novas expectativas de suas equipes: “começamos a construir software mais cedo – ou seja, quase imediatamente quando começamos a entender o que estamos tentando fazer – e não gastamos meses a fio articulando exatamente o que precisa ser e como ela precisa funcionar”.

Como resultado, a Liberty Mutual construiu uma plataforma de clientes de seguro de motocicleta em 28 dias – um MVP definitivo, de acordo com McGlennon, e uma maneira rápida de determinar se os segurados usariam o produto. “Você precisa ter alguns exemplos”, revela, “carros-chefe que você aponta para ajudar as pessoas a entender como as coisas podem melhorar, além de abraçar a abordagem que eles podem fazer também”.

Afinal, se há mais uma lição para aprender com startups, é que o sucesso gera sucesso.

Tags
Junte-se a nós e receba nossas melhores histórias de tecnologia. Newsletter Newsletter por e-mail