Aqui está uma história rápida. Como analista de negócios, trabalhei em uma editora em Oxford. Estávamos entrevistando, diagramando processos e assim por diante – essa não é a parte interessante. Entretanto, paralelamente, trouxeram consultores de uma pequena empresa em Birmingham, no Reino Unido. Duas ou três pessoas.
O prédio em que trabalhávamos era comprido e estreito e tinha um andar superior vazio. Esses caras chegaram com um enorme rolo de papel pardo, de 2,10 metros de altura. Eles atiraram esse rolo até o chão vazio. Eles então conversaram com as pessoas e perguntaram quais sistemas elas usavam, quais formulários elas preenchiam e assim por diante.
Então eles colaram literalmente tudo naquela folha de papel. Eles imprimiam suas telas ou os formulários que preencheriam, colavam-nos e juntavam-nos com fita preta para que você pudesse ver as ligações.
Quando terminaram, depois de algumas semanas, eles chamaram todos da empresa para cima e disseram: “Pronto!” Todos ficaram maravilhados: “Oh meu Deus, eu preencho isso, depois vai para lá e nada acontece com ele?” ou “Essa parte é exatamente igual àquela, mas feita por duas pessoas diferentes?” e assim por diante.
Foi o melhor presente que os consultores poderiam ter dado à empresa. Valeu a pena US$ 20 mil (ou o que quer que tenha custado), apenas para colar alguns pedaços de papel em uma grande folha de papel pardo? Sim absolutamente. 100%.
O poder da visualização é fantástico e já o vi muitas vezes ao longo dos anos. Falei recentemente com uma start-up que permite mapeamento de processos e painéis de DevOps. Eles me perguntaram o que eu achava do que eles estavam fazendo, principalmente porque (assim me disseram) eu era um pouco cético.
Então, contei a eles a história acima. Na minha experiência, os processos de desenvolvimento de software são notoriamente difíceis de bloquear, apesar de todos os esforços para definir metodologias e estruturas. Podemos entrar nos motivos durante uma bebida, mas o resultado é uma contínua falta de visibilidade. Como diz o ditado, se você não consegue medir, não consegue gerenciar. E o desenvolvimento de software é notoriamente difícil de medir.
Então, o que dizer aos fornecedores de soluções que tentam decifrar o código de visibilidade do processo no espaço DevOps? A questão tem menos a ver com a necessidade, nem com as epifanias que podem ser alcançadas com um pacote de software (ou post-its num quadro branco, ou com um rolo de papel pardo), e mais com a forma de ter sucesso quando, historicamente, muitos têm tentei e tornei-me, com a melhor vontade do mundo, uma solução pontual.
O desafio é duplo. Primeiro, ninguém na organização (não técnica) se preocupa o suficiente com os processos de software para alocar um orçamento para tais ferramentas. Por alguma razão, a empresa ainda pensa que o software funciona sozinho – não pode ser tão difícil de escrever se você tiver boas pessoas, correto? Todo mundo simplesmente presume que são apenas pessoas inteligentes criando coisas.
No entanto, qualquer pessoa que tenha desenvolvido software em qualquer escala sabe em que confusão complicada podemos nos meter sem os controles corretos. Como uma estranha boa notícia, estamos num período de aperto de cintos, onde os CIOs são solicitados a justificar quanto custa a TI – o ditado se estende a: “Se você não pode medir, você não pode ter mais dinheiro”, o que certamente concentra a mente.
Portanto, sim, a procura de eficiência pode ser satisfeita com iniciativas de gastar para poupar, o que, por sua vez, alimenta o interesse em ferramentas de processos de software, categorizadas como gestão de fluxo de valor, análise de desenvolvimento de software ou similares. Ao observar vários fornecedores que procuram resolver um problema complexo de maneiras semelhantes, muitas vezes faço analogias com vários caminhos subindo a mesma montanha – e este espaço não é diferente.
Para seguir um pouco essa analogia, vejo vários fornecedores, em vários estágios de desenvolvimento, subindo diferentes rotas naquela montanha. Isto leva-nos ao segundo desafio: nenhuma organização encontrou ainda um caminho repetível até ao topo.
Todo mundo fica exausto depois de um tempo e começa a desacelerar. No relatório do VSM, temos líderes e desafiantes, titulares e novos participantes, todos abordando o problema à sua maneira. As start-ups chegam ao espaço muitas vezes através de alguma epifania pessoal, o seu momento de “rolo de papel pardo”, por assim dizer.
Eles chegam e sobem a montanha, correm e correm e começam a desacelerar… e eventualmente, com o tempo, eles simplesmente se tornam um recurso na plataforma de outra pessoa. Lembro-me do corredor de montanha campeão mundial espanhol Killian Jornetdas façanhas de – embora todos possamos aspirar a ser como esse atleta, ele é uma exceção, não a norma.
O que fazer em relação a isto? Uma resposta, claro, é não se importar muito. Um fornecedor pode reconhecer que sempre será uma ferramenta tática, a ser utilizada quando as coisas não estiverem indo tão bem. Para o fornecedor, isso resulta em um certo caminho para o mercado – para mudar de analogia, uma ferramenta para os mecânicos que fazem a manutenção do avião, em vez da peça central da cabine.
Uma segunda opção é definir o escopo de acordo com o que é viável, verticalmente em vez de horizontalmente – se você estiver na cabine, faça uma coisa bem em vez de tentar controlar a aeronave inteira. Dessa forma, pode-se definir com mais precisão o público e, por extensão, o valor trazido aos stakeholders.
O que nos leva à terceira opção. Considerar os casos de uso em que a ferramenta pode agregar valor. É muito bom que um grupo menor reconheça a escala de um problema, neste caso; o desenvolvimento de software é complexo e tende ao caos sem as verificações e equilíbrios corretos. Mas é uma grande suposição que outros – detentores de orçamento até ao nível do conselho de administração – chegarão à mesma conclusão sem um rolo gigante de papel pardo para guiar o seu pensamento.
Então, se o desafio é que a maioria não quer resolver o problema, por mais claro que seja para a minoria, então quais são os cenários em que a maioria o vê como importante? Existe outra necessidade que a maioria esteja disposta a deixar para trás? E começar a partir daí, em vez do processo de desenvolvimento e da eficiência de custos?
De volta ao manifesto do DevOps, o Projeto Fênixele próprio baseado em Eli GoldrattNas novelizações das melhores práticas de gerenciamento de projetos, a questão sempre foi sobre os desafios de negócios – atrair clientes para o site, aumentar as vendas, melhorar as cadeias de suprimentos e assim por diante. No entanto, muitas ferramentas e abordagens são introspectivas e focadas na melhoria dos meios e não nos fins.
Todos nós sabemos o quão difícil é construir software, mas veja o Ponto Um: ninguém fora da área de TI se importa tanto. Se não conseguirmos o dinheiro para fazer as melhorias necessárias, isso é uma coisa. E é absolutamente verdade que o problema existe. Mas presumir que as pessoas irão magicamente “entender” que o problema precisa ser resolvido é outra bem diferente.
Então, se as pessoas não se dão ao trabalho de resolvê-lo, que cenário as faria querer resolvê-lo? Muitas vezes, neste ramo, somos forçados a esperar por situações em que o problema se torne uma crise – logo após uma violação de segurança, quando uma auditoria de conformidade se aproxima ou quando um pacote de software está chegando ao fim da vida útil.
Alternativamente, eu adotaria uma abordagem orientada para o design thinking, que mapeia e prioriza os resultados de negócios – isso é aplicável tanto a empresas de usuários finais quanto a fornecedores de soluções. Para as empresas, quais eixos de negócios específicos podem ser mudados por meio de melhorias nos processos de software e em quanto? E para os fornecedores, como é o quadro composto em toda a base de clientes?
Note-se, no entanto, que embora estes cenários possam ser eventos que valham a pena investir dinheiro, não são o fim do jogo – que pode ser descrito pela visão, missão e estratégia de uma empresa. O negócio em si é a montanha – o seu ou o das organizações que você atua como fornecedor. Se você está subindo, pergunte-se primeiro: como é o topo? O que você terá alcançado quando chegar lá?
Se a resposta não puder ser descrita em termos comerciais, será muito menos provável que você chegue. Sem rodeios, realize a reunião inicial de melhoria de processos de software apenas com uma imagem clara das três principais metas de sua empresa para o próximo período e como a melhoria de processos, ferramentas ou qualquer outra coisa os fará acontecer diretamente.
E, como fornecedor, se você deseja apenas levantar capital de investidores e uma saída rápida, eu diria que isso é uma falsa cimeira. Nestes tempos de transformação digital, o desalinhamento entre o fornecimento de tecnologia e os objetivos empresariais é possivelmente a maior causa da ineficiência financeira. Esteja preparado para iniciar a jornada com um mapa para chegar ao topo, se quiser chegar a algum lugar.