“Escrito em pedra” é uma expressão comum no mundo do desenvolvimento de produtos digitais, que utilizamos para nos referirmos a políticas e metas que não podem mudar, ou supostamente podem mas que na realidade nunca mudam. Alguns exemplos bem conhecidos de coisas que encaixo na categoria “escrito em pedra”:
Escopo fechado
Já é 2024 e eu tenho confiança que todo mundo lendo isto aqui já entendeu que escopo fechado não existe, afinal o desenvolvimento de um produto digital é um processo essencialmente exploratório. Mas assim como o mundo real faz a gente aprender que não é possível prever todo o escopo de um trabalho de antemão, ele também nos fornece pessoas tomadoras de decisão que não reconhecem essa realidade.
No fim das contas, o escopo previsto inicialmente e o orçamento ficam escritos em pedra, enquanto as descobertas geram intermináveis requisições de mudança ou, em casos catastróficos, precisamos absorvê-las.
Etapas de revisão técnica
Eu quis trazer também um exemplo do nível de operação, e este é um caso clássico. Sempre que adicionamos etapas a um processo, adicionamos também as filas dessas etapas, e se as etapas são obrigatórias (no sentido de que todos os itens de trabalho precisam ser submetidos a tais etapas) as filas também são. Existem produtos de alto risco que realmente precisam disso: se fosse contratado para entregar o sistema que mantém um hospital em funcionamento, eu também adicionaria etapas e políticas para contenção de riscos mesmo que isso deixe o processo mais lento.
O problema é quando se extrapola este pensamento para questões de baixo risco. Um problema específico e localizado pode ser elevado a uma potência onde todos os itens sejam submetidos a uma nova etapa do processo, sacrificando o tempo de entrega por uma suposta contenção de riscos que são totalmente discutíveis ou nem existem.
Mas não são somente decisões que impactam todo o processo que podem estar “escritas em pedra”. Muitas vezes, uma política simples ou um acordo do dia-a-dia podem subir o Monte Sinai e virar o décimo primeiro mandamento. E sobre isso tenho uma história interessante para contar.
O projeto
Era um projeto aparentemente simples: uma migração de um site institucional cujo framework havia sofrido muitas mudanças em sua última versão. Então além da atualização era necessário um esforço para transferir as funcionalidades para os novos padrões. Logo no começo do trabalho, estava todo mundo alinhado com acordos como:
- sistema puxado
- prazo flexível adaptado às descobertas
- simplificação de funcionalidades
entre outras conversas que fazem o começo de um projeto parecer o melhor lugar do mundo para se estar. E como você já deve estar desconfiando, as coisas mudaram. Um detalhe que eu quase não percebi durante o kickoff técnico: o ponto de contato do cliente, que ocupava um cargo da gestão média de título muito conhecido entre nós da agilidade, precisava preencher um documento para a gestão acima dele. Este documento continha basicamente o que estamos acostumados a acordar quando definimos um projeto. Pontos de contato entre os times, links para documentações, qual é o backlog inicial, data para o fim do projeto, etc. Também incluía coisas não tão comuns como nomes de arquiteto e desenvolvedor responsáveis.
De toda forma, até aí não tinha nada de muito estranho, é assim que eu faço também. Mesmo trabalhando com escopo aberto, isso significa que podemos alterar o plano, e para alterar o plano precisamos que o plano exista. Então apesar de parecer tradicional e burocrático, encarei apenas como uma maneira diferente da minha de como elaborar o plano.
E alguém questionou isso?
É claro que questionei as coisas que achei estranhas, afinal na Taller trabalhamos com Fluxo Unificado e não vendemos alocações fixas para este cliente. Então meu primeiro questionamento foi sobre os nomes que precisávamos escrever neste documento. Da mesma forma questionei o prazo que parecia bastante agressivo, entre outras coisas que não convém relatar aqui. Todas as minhas dúvidas foram respondidas da mesma maneira: isto é só uma formalidade pra gente poder começar, nada está escrito em pedra, e a gente vai revisando conforme o projeto avança. Outra coisa que pareceu muito com meu jeito de executar projetos então também concordei. Eu viria a me arrepender amargamente por isso.
Pior é que eu sabia, mas quando interagimos com o cliente através de uma pessoa agilista, não significa que a empresa terá uma relação ágil fora da gestão média. Nem vou entrar no mérito de pessoas que se posicionam neste mercado mas não têm real conhecimento dos métodos e no dia-a-dia operam com uma cabeça de gestão tradicional. O ponto é que, mesmo com uma pessoa bem capacitada, não necessariamente ela conseguiu o capital político necessário para que a empresa operasse desta forma ágil em seus contratos.
Mas afinal o que é que estava escrito em pedra?
Não levou muitas semanas para percebermos que o prazo não tinha a menor chance de ser atingido. As descobertas estavam se empilhando, muitas delas relacionadas a incompatibilidades técnicas e requisitos absurdos dos quais não se abriam mão. Você já viu um site institucional precisar de uma lista com ordenação aleatória?. E foi aí que começou o processo de petrificação do que estava escrito. Tudo, absolutamente tudo o que supostamente não estava escrito em pedra foi cobrado como se tivesse.
As pessoas que ficaram como responsáveis no dito documento tinham que estar disponíveis de imediato, inclusive para reuniões. Uma pessoa diferente puxando demanda deste projeto era a coisa mais estranha do mundo. Funcionalidades que o próprio cliente concordava serem inúteis eram inegociáveis. Falar em mexer no prazo então nem pensar, teve até gerente gritando comigo.
As consequências
No fim das contas, graças à inflexibilidade da empresa em fazer negócios, e ao suposto agilista que não conseguiu comunicar como eu e meu time seríamos cobrados, precisamos absorver trabalho que não conseguimos cobrar. Numa relação onde entregamos aproximadamente ¼ a mais do que foi comprado e pago, terminamos com prejuízo e um cliente muito insatisfeito. Esse ¼ vem de números que foram apresentados ao cliente porém não foram questionados ou analisados.
E foi assim que eu aprendi a nunca mais confiar no que a gestão média me promete, mesmo que haja um alto alinhamento entre nós. Ao invés disso, hoje eu procuro pelas coisas que podem estar “escritas em pedra” e trato elas como risco para o projeto. Alinho o entendimento de que isto é risco e de que o risco é alto de maneira totalmente transparente com o cliente. Isso resolve todos os problemas? Óbvio que não, mas na minha experiência melhorou a negociação destas coisas tão críticas como absorção de trabalho, horas extras, alterações no escopo e prazo.