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

A maioria das organizações muda seus sistemas do mesmo jeito. Alguém defende a necessidade de um projeto. Um orçamento é aprovado, uma equipe é montada, um fornecedor é escolhido e uma data de entrada em produção vai para o calendário. A equipe trabalha duro, o sistema entra no ar e o projeto é encerrado. As pessoas que entendiam o trabalho seguem para outras coisas.

Depois, a organização continua mudando. Uma nova linha de produtos exige uma nova etapa de aprovação. Uma regulamentação muda o que precisa ser registrado. Duas equipes se fundem, mas suas planilhas não. Nada disso espera pelo próximo projeto e, ainda assim, a capacidade de responder foi embora com o anterior.

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

Por que o modelo de projeto continua decepcionando

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

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

• O conhecimento se dispersa. Os motivos por trás do desenho, os casos especiais que a equipe descobriu, as concessões que foram feitas: quase tudo isso vivia em pessoas e reuniões. Quando a equipe se desfaz, a organização fica com o sistema, mas perde o entendimento sobre ele.
• As pequenas mudanças se acumulam. Cada pedido é pequeno demais para justificar um novo projeto, então fica esperando. Enquanto isso, as pessoas contornam a falta com uma planilha, uma mensagem ou uma checagem manual.
• O sistema se afasta do trabalho. Mês após mês, o jeito como a organização realmente opera se distancia do jeito como o sistema espera que ela opere. O projeto seguinte começa, então, redescobrindo o que o anterior já sabia.

Nada disso é culpa de alguém. É o que o modelo produz.

Como é uma função

As organizações já sabem lidar com um trabalho que nunca termina. O financeiro não fecha as contas uma vez e se dissolve. O jurídico não para de revisar contratos depois do primeiro. Essas são funções: responsabilidades permanentes, conduzidas por pessoas que ficam, com memória do que veio antes e uma capacidade estável para lidar com o que vem depois.

A transformação pode funcionar do mesmo jeito. Tratá-la como uma função significa algumas coisas concretas.

• Alguém é responsável de forma contínua. Existe um responsável nomeado, que responde por como os sistemas da organização evoluem, e não só pela próxima iniciativa.
• A capacidade é estável. Em vez de montar uma equipe 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 registrados onde a próxima pessoa possa encontrá-los. Ninguém precisa reconstruir por que o fluxo de aprovação funciona do jeito que funciona.
• A mudança é contínua. O ciclo de entender uma necessidade, moldar uma resposta, construí-la, verificá-la, implantá-la e fazê-la evoluir se repete muitas vezes, no 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 organogramas do que com hábitos. Pela nossa experiência, a mudança aparece em três lugares.

De entregas para capacidade

Um projeto é descrito pelo que vai entregar. Uma função é descrita pelo que consegue assumir. A pergunta passa de “quanto vai custar construir isto” para “em que a nossa capacidade deve trabalhar agora”. Isso permite resolver as pequenas coisas que nunca justificaram um projeto e mudar de direção sem abrir um novo processo de compra.

Da passagem de bastão para a continuidade

No modelo de projeto, o momento mais arriscado é a passagem de bastão: 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 equipe conduz o trabalho da primeira conversa até a operação, e de volta. O que ela não consegue eliminar, ela registra.

De grandes entregas para evolução constante

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

O que isso pede dos líderes

Uma função não dispensa gestão. Ela pede que os líderes 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 continue proporcional à ambição. Terceiro, como as prioridades são escolhidas, porque uma capacidade que pode assumir qualquer coisa vai ser chamada a assumir tudo.

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

Onde a Croo entra

Criamos a Croo em torno dessa ideia. Seu Croo é uma equipe 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, de processos de negócio e arquitetura a engenharia de software, finanças e governança. A Factory dá a essa equipe uma memória compartilhada e um sistema de produção, para que cada mudança se apoie na anterior em vez de começar do zero.

A relação funciona com uma capacidade contínua, e não com uma 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 conduz continuamente, sem precisar construir um departamento inteiro próprio.

Os projetos continuarão tendo seu lugar. Algumas mudanças são grandes o bastante 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 mudando. Sua capacidade de mudar deveria ficar.