Desligue os sistemas. O que sobra da sua empresa?

Um dos livros mais fodas que já li sobre tecnologia foi O Projeto Fênix.

Para quem não conhece, ele é um romance sobre uma empresa com um projeto de TI atrasado, sistemas quebrando, conflitos entre áreas e uma operação inteira tentando sobreviver ao caos.

É ficção.

Mas qualquer pessoa que já trabalhou em uma empresa com software reconhece boa parte dos personagens.

O desenvolvedor que recebe uma urgência sem contexto.

A operação que promete algo para o cliente antes de consultar tecnologia.

O executivo que enxerga TI apenas como custo.

E o time que passa o dia apagando incêndios, mas continua sendo cobrado por não entregar os projetos importantes.

A grande ideia que ficou comigo foi simples:

TI não é uma área que dá suporte ao negócio. Em muitas empresas, TI é o próprio negócio.

Se o sistema parar

Pense em quantas empresas continuam funcionando se seus sistemas pararem.

Uma loja sem o sistema de pagamentos ainda vende?

Uma transportadora sem rastreamento ainda opera?

Uma empresa de serviços sem seus dados consegue saber quais projetos dão lucro?

Um banco sem software ainda é um banco?

Mesmo negócios que não se consideram empresas de tecnologia dependem dela para vender, operar, decidir e atender clientes.

Ainda assim, muita empresa continua tratando tecnologia como a área que deve aparecer depois que todas as decisões já foram tomadas.

O comercial promete.

A operação desenha o processo.

A diretoria define a data.

Depois alguém chama a TI e pergunta:

“Dá para entregar até sexta?”

Quando a resposta é não, a tecnologia passa a ser vista como o obstáculo.

Só que o problema começou muito antes.

Começou quando uma decisão de negócio que dependia de software foi tomada sem envolver quem entende do sistema.

O custo de tratar TI como suporte

Quando tecnologia é suporte, ela recebe pedidos.

Quando tecnologia faz parte do negócio, ela participa das decisões.

A diferença parece pequena, mas muda tudo.

O time deixa de receber apenas uma lista de funcionalidades e começa a entender qual resultado a empresa precisa produzir.

Em vez de perguntar “quando essa tela fica pronta?”, a conversa passa a incluir o problema do cliente, o impacto financeiro e os riscos daquela escolha.

Isso também muda a forma de medir o trabalho.

Quantidade de chamados fechados não mede valor.

Número de funcionalidades entregues também não.

Uma equipe pode entregar dezenas de coisas e continuar sem resolver o problema que impede a empresa de crescer.

O Projeto Fênix não é sobre ferramenta

Muita gente lê sobre DevOps e pensa em pipeline, container, automação ou alguma ferramenta nova.

O livro mostra outra coisa.

DevOps é, antes de tudo, uma forma de melhorar o fluxo de trabalho entre tecnologia e negócio.

É perceber onde o trabalho está travado.

É reduzir tarefas não planejadas.

É impedir que toda urgência interrompa aquilo que realmente importa.

É criar uma forma de entregar mudança sem transformar cada implantação em um evento traumático.

A ferramenta ajuda.

Mas instalar uma ferramenta não corrige uma empresa que toma decisões ruins.

O gargalo não fica só na TI

Outra ideia importante do livro é que o desempenho do sistema inteiro depende de seus gargalos.

Se todas as entregas precisam passar por uma única pessoa, a capacidade da empresa é limitada por ela.

Se o time desenvolve rápido, mas demora semanas para conseguir colocar algo em produção, o desenvolvimento rápido não adianta muita coisa.

Se a empresa lança funcionalidades, mas ninguém mede se os clientes realmente as usam, está apenas aumentando o sistema sem saber se aumentou o valor.

O gargalo pode aparecer na infraestrutura, no processo de aprovação ou na forma como as decisões são tomadas.

Por isso, o problema de TI raramente pertence apenas à TI.

Tecnologia precisa participar da estratégia

Quanto mais trabalho com software, mais estranho acho quando uma empresa separa estratégia de negócio e estratégia de tecnologia.

Se a experiência do cliente acontece em um sistema, decidir sobre esse sistema é decidir sobre o negócio.

Se os dados orientam preço, margem e investimento, a arquitetura desses dados é uma decisão empresarial.

Se uma integração determina quanto tempo a operação leva para atender alguém, essa integração afeta diretamente o resultado.

O CTO, o tech lead e os engenheiros não deveriam participar apenas depois que a empresa escolheu o caminho.

Eles precisam ajudar a escolher o caminho.

Não porque tecnologia deve mandar no negócio.

Porque o negócio já depende de tecnologia, mesmo quando ainda não percebeu.

Uma pergunta simples

Existe uma pergunta que ajuda a entender se a empresa realmente trata tecnologia como parte do negócio:

Quando uma decisão estratégica é tomada, alguém da tecnologia participa antes ou recebe um chamado depois?

Se a tecnologia aparece apenas depois, ela provavelmente ainda é tratada como suporte.

E esse modelo funciona até o dia em que o sistema deixa de acompanhar o crescimento da empresa.

Nesse momento, aquilo que parecia uma área de apoio se revela como o principal limite da operação.

A dobra

O Projeto Fênix é um romance sobre TI e DevOps.

Mas a mensagem vai muito além de tecnologia.

Uma empresa é um sistema.

As áreas dependem umas das outras. Uma decisão local pode criar um problema em todo o fluxo.

Tecnologia não existe apenas para implementar pedidos.

Ela ajuda a definir o que é possível, quais riscos estamos assumindo e como uma ideia pode se transformar em resultado.

Se a sua empresa não consegue vender, operar ou decidir quando os sistemas param, a TI não está dando suporte ao negócio.

A TI é o negócio.

E essa foi mais uma dobra de: parar de tratar como suporte aquilo que sustenta a empresa.

Nos vemos na próxima quinta, às 10:10.

Referência

O Projeto Fênix: um romance sobre TI, DevOps e como ajudar seu negócio a vencer

Gene Kim, Kevin Behr e George Spafford