A transformação é uma função, não um projeto

A maioria das organizações muda os seus sistemas da mesma forma. Alguém defende a necessidade de um projeto. É aprovado um orçamento, forma-se uma equipa, escolhe-se um fornecedor e marca-se no calendário uma data de entrada em produção. A equipa trabalha arduamente, o sistema entra em funcionamento e o projeto é encerrado. As pessoas que compreendiam o trabalho passam a outras coisas.

Depois, a organização continua a mudar. Uma nova linha de produtos exige uma nova etapa de aprovação. Uma regulamentação altera o que tem de ser registado. Duas equipas fundem-se, mas as suas folhas de cálculo não. Nada disto espera pelo próximo projeto e, ainda assim, a capacidade de responder foi-se embora com o anterior.

É este o padrão por trás de boa parte da frustração com a tecnologia. O problema raramente é o último projeto ter falhado. É o modelo de projeto tratar a mudança como um acontecimento, quando, para a maioria das organizações, a mudança é uma condição permanente.

Porque é que o modelo de projeto continua a desiludir

O modelo de projeto foi pensado para trabalhos com um início e um fim claros: construir um armazém, mudar de escritório, instalar uma máquina. Essas coisas ficam concluídas quando ficam concluídas. O software que faz funcionar uma operação nunca fica concluído nesse sentido. Está no meio do trabalho, e o trabalho não para.

Quando um sistema é entregue como projeto, costumam acontecer três coisas depois de o projeto ser encerrado.

• O conhecimento dispersa-se. Os motivos por trás do desenho, os casos especiais que a equipa descobriu, as cedências que foram feitas: quase tudo isso vivia em pessoas e reuniões. Quando a equipa se desfaz, a organização fica com o sistema, mas perde a compreensão que tinha dele.
• As pequenas alterações acumulam-se. Cada pedido é demasiado pequeno para justificar um novo projeto, por isso fica à espera. Entretanto, as pessoas contornam a falta com uma folha de cálculo, uma mensagem ou uma verificação manual.
• O sistema afasta-se do trabalho. Mês após mês, a forma como a organização opera realmente distancia-se da forma como o sistema espera que ela opere. O projeto seguinte começa, então, por redescobrir o que o anterior já sabia.

Nada disto é culpa de ninguém. É o que o modelo produz.

Como é uma função

As organizações já sabem lidar com um trabalho que nunca termina. A área financeira não fecha as contas uma vez para depois se dissolver. O departamento jurídico não deixa de rever contratos depois do primeiro. São funções: responsabilidades permanentes, asseguradas por pessoas que ficam, com memória do que veio antes e uma capacidade estável para lidar com o que vem a seguir.

A transformação pode funcionar da mesma forma. Tratá-la como uma função significa algumas coisas concretas.

• Alguém é responsável de forma contínua. Existe um responsável identificado, que responde pela forma como os sistemas da organização evoluem, e não apenas pela próxima iniciativa.
• A capacidade é estável. Em vez de formar uma equipa para cada projeto e desfazê-la depois, existe uma capacidade contínua que passa de uma necessidade para a seguinte à medida que as prioridades mudam.
• A memória é preservada. Decisões, contexto e restrições ficam registados onde a próxima pessoa os possa encontrar. Ninguém tem de reconstruir porque é que o circuito de aprovação funciona da forma como funciona.
• A mudança é contínua. O ciclo de compreender uma necessidade, moldar uma resposta, construí-la, verificá-la, implementá-la e fazê-la evoluir repete-se muitas vezes, ao ritmo de que a organização precisa.

Três mudanças na prática

Passar de projetos para uma função tem menos a ver com organigramas do que com hábitos. Pela nossa experiência, a mudança nota-se em três lugares.

Das entregas à capacidade

Um projeto descreve-se pelo que vai entregar. Uma função descreve-se pelo que consegue assumir. A pergunta passa de «quanto vai custar construir isto» para «em que deve a nossa capacidade trabalhar agora». Isso permite resolver as pequenas coisas que nunca justificaram um projeto e mudar de direção sem abrir um novo concurso.

Da passagem de testemunho à continuidade

No modelo de projeto, o momento de maior risco é a passagem de testemunho: de quem desenhou o sistema para quem o opera, ou de um fornecedor para o seguinte. Uma função elimina a maioria dessas passagens, porque a mesma equipa conduz o trabalho desde a primeira conversa até à operação, e de volta. O que não consegue eliminar, regista.

Das grandes entregas à evolução constante

Quando a mudança sai cara para começar, as organizações acumulam-na e entregam-na em grandes lotes. Os grandes lotes são mais difíceis de testar, mais difíceis de explicar e mais difíceis de reverter. Uma função permanente consegue fazer alterações em passos menores, cada um compreendido, verificado e explicado às pessoas que afeta.

O que isto pede aos líderes

Uma função não dispensa gestão. Pede aos líderes que decidam algumas coisas de forma deliberada.

Primeiro, quem é responsável pela evolução dos sistemas da organização e como essa pessoa é apoiada. Segundo, como a capacidade contínua é definida e revista, para que se mantenha proporcional à ambição. Terceiro, como são escolhidas as prioridades, porque a uma capacidade que pode assumir qualquer coisa vai ser pedido que assuma tudo.

Pede também um tipo particular de paciência. Os benefícios de uma função são cumulativos. Vêm do conhecimento que fica, de problemas resolvidos enquanto ainda são pequenos e de sistemas que continuam a corresponder ao trabalho. São mais fáceis de ver ao longo de um ano do que de um trimestre.

Onde entra a Croo

Criámos a Croo em torno desta ideia. O seu Croo é uma equipa que fica ao lado da organização: uma pessoa na sala que conhece a sua operação e, por trás dela, as disciplinas que o trabalho exige, dos processos de negócio e da arquitetura à engenharia de software, às finanças e à governação. A Factory dá a essa equipa uma memória partilhada e um sistema de produção, para que cada alteração assente na anterior em vez de começar do zero.

A relação assenta numa capacidade contínua, e não numa sequência de projetos. Não é uma licença de software nem um trabalho pontual. É uma forma de fazer da transformação algo que a organização assegura continuamente, sem ter de construir um departamento inteiro próprio.

Os projetos continuarão a ter o seu lugar. Algumas mudanças são suficientemente grandes para merecer um nome, um plano e uma data. Mas, quando o projeto termina, a função não deveria terminar. A organização vai continuar a mudar. A sua capacidade de mudar deveria ficar.