Zen e a Arte da Gestão de Software (ou da Manutenção de Motocicletas?)
Era 2014 quando li o livro do Robert Pirsig, Zen e a Arte da Manutenção de Motocicletas. É um livro filosófico, mas me transformou profissionalmente. Naquele momento, eu vivia um momento de saturação quanto aos métodos e abordagens de gestão na área de software. Depois de passar por vários, eu me perguntava: Qual era o certo? Até quando este seria o certo? E, depois, qual seria o próximo? Quando isso acaba?
O livro me inspirou. O que aprendi ali transformou a minha relação com o trabalho a ponto de eu modificar completamente minha linha de discurso, de treinamentos e de consultorias. Dessa mudança de perspectiva nasceu o Software Zen, mais especificamente o programa "Zen e a Arte da Gestão de Software".
O nome veio inspirado no livro, mas, na verdade, não me inspirei apenas no nome, mas principalmente de um pouco da filosofia descrita ali. Nesse artigo, eu falo um pouco dessa filosofia e de como ela pode ser aplicada no seu desenvolvimento pessoal enquanto líder ou gestor de negócios e projetos na área de desenvolvimento de software.
O livro se baseia em fatos reais e conta a história de uma viagem de motocicleta de 17 dias do autor, Robert, com seu filho Chris e com um casal de amigos John e Sylvia, que usam a viagem como uma espécie de válvula de escape para as pressões da civilização moderna. Durante a viagem, o autor faz várias reflexões sobre como ele e seu amigo John se relacionam de forma diferente com a tecnologia, em especial com suas motocicletas.
Tais reflexões são materializadas na forma de discussões filosóficas — as chautauquas — que vão tomando conta do livro e formando um corpo de ideias relacionadas com o que o autor vai chamar de “A Metafísica da Qualidade”.
Robert, o protagonista, e seu amigo, John, se relacionam cada um a sua forma com suas motocicletas. De um lado, John revela uma grande incapacidade e desinteresse para lidar com tecnologia em geral, e em especial, com sua própria moto. Robert, por outro lado, assume um posicionamento diferente. Ele se interessa, quer entender causa e consequência, prevenir, remediar de forma consciente os problemas, como se fossem seus, e não apenas do objeto.
Ao seguir por esse caminho, ele se une à tecnologia em uma relação artesanal como um único todo coeso e harmônico, e, dessa forma, zen.
John prefere tratar sua cara motocicleta como algo que deveria funcionar por si só. Ele a compra para não ter problema, para não ter que se relacionar com ela. Esse fenômeno revela uma espécie de dicotomia sujeito-objeto. Sujeito e objeto assumem posições de submissão conflituosa entre si. O objeto deveria estar ali para servir, para funcionar. Mas o desbalanceamento da dinâmica causa uma inversão na relação, e o sujeito passa a servir o objeto. Agora é ele, o sujeito, que faz tudo que é preciso para que ela, o objeto, funcione.
Veja o exemplo do empreendedor que, em nome da conquista de sua liberdade de agir, abre sua própria empresa. Na relação, a empresa é o objeto. O mecanismo que conecta o empreendedor, o sujeito, ao seu objetivo maior: liberdade. Dizemos que, neste ponto, a empresa serve ao empreendedor. Entretanto, depois de alguns meses, o empreendedor, em nome do sucesso da empresa, começa a inverter a relação inconscientemente. Ele trabalha ainda mais horas do que fazia antes; vê menos a família; deteriora sua saúde e assume muitas dívidas. A empresa agora precisa dá certo e, assim, ela o escraviza. A relação de submissão se inverte totalmente, e agora é o sujeito que serve ao objeto.
No início, John trata a moto como submissa a sua vontade: “eu paguei caro para não ter problema com isso”. Quando problemas ocorrem, ele fica frustrado e apenas manda para um mecânico resolver. Percebe-se uma clara falta de integração com o objeto que, sempre que "pode", reverte a relação de submissão, uma vez que não há viagem sem moto.
Como isso se dá nas empresas?
Repare no padrão: 1) paga-se caro por um “algo”; 2) Problemas surgem; 3) Emerge a frustração; 4) Contrata-se um especialista para resolver; 5) Recomeça-se o ciclo voltando para (1).
É o mesmo modelo que se usa hoje em muitas empresas que desenvolvem e sustentam produtos de software. Trata-se a gestão como um “algo” pela qual paguei e que, como tal, deveria simplesmente funcionar. Paguei por RUP, por CMMi, por MPS.BR, por Ágil, por SAFe. Deu problema?
— Manda para o próximo especialista!
Uma vez feito o compromisso com o método, inverte-se a relação. Os problemas reais são substituídos pelo novo problema criado: aplicar o método, fazer do jeito "certo", se submeter a ele. A meta passa a ser implantar o método e, agora, é o sujeito (a empresa) que serve ao objeto (o método).
Dessa forma, ao tentar implantar “algo” sem sucesso, é fácil externalizar a culpa. Afinal, "compramos" o objeto para que *ele* resolvesse o problema. O Russel Ackoff nos ajuda a entender esse comportamento com a seguinte ideia:
“Uma empresa é o resultado do que ela faz, não do que é feito a ela.” R. Ackoff
Uma alternativa: a dança do sujeito com o objeto
A alternativa é a segunda postura de relação trazida por Pirsig. Em contraste ao seu companheiro de viagem, o protagonista estabelece uma espécie de dança de auto-desenvolvimento com sua motocicleta. Cada problema traz uma oportunidade de crescimento. A postura é de interesse, de análise aprofundada do problema, e de design apropriado da solução. Os especialistas “na coisa”, quando precisam se envolver, não o fazem como meros recebedores do problema, mas como colaboradores.
Assim, a cada problema resolvido, o protagonista desenvolve a si mesmo, cresce, formando uma relação sujeito-objeto integrada em um único todo coeso e de propósito compartilhado. E, assim, o autor descreve o seu conceito de “Metafísica da Qualidade”: “A Qualidade é o evento que torna possível a inter-relação sujeito objeto. A Qualidade é a reação de um organismo ao seu objeto”. Eu não estou usando a moto para viajar, eu e a moto estamos viajando juntos.
Durante a sua jornada, uma empresa (o sujeito) e o seu método de trabalho (objeto) não deveriam estar dissociados em sua relação. O método é expressão da estrutura procedimental e da cultura da empresa. Ele é a resultante de uma sequência de saltos de auto-desenvolvimento gerados pelo design de soluções únicas para cada um dos problemas que a empresa vivencia. Sendo assim, é preciso fazer “Design do Método”, e não “Instalação do Método”.
De fato, em algum momento paramos de resolver problemas e passamos a comprar soluções. É aí que a confusão começa, pois a transação de compra transfere a responsabilidade para o vendedor (ou, se preferir, para o produto comprado). Só tem um detalhe, entretanto: a responsabilidade sobre o problema é daquele que tem o problema.
Um exemplo: O Modelo Spotify
O fenômeno Spotify demonstra essa realidade. A empresa realmente levou a sério essa abordagem. Desenhou uma forma de agir, de se organizar, enquanto desenvolvia e sustentava seus produtos. Usou Ágil, Lean, Kanban e muitas outras técnicas como repertório, não como receita. Cresceu enquanto resolvia problemas, um após o outro. Nada foi instalado. As práticas e estruturas simplesmente emergiram de problem-solving activities ou foram integradas de acordo com a necessidade de vencer os desafios que surgiam.
Com sua corriqueira sabedoria, Kent Beck explicou melhor o que eu quero dizer:
“A Spotify não implementou o modelo Spotify copiando a Spotify. Porque esse pessoal em outras empresas acha que pode implementar o modelo Spotify copiando o Spotify?” Kent Beck
Troque Spotify por Toyota e você terá exatamente a mesma ideia.
Para o protagonista do romance de Pirsig, realizar a manutenção da própria motocicleta (ou, em outras palavras, resolver seus próprios problemas) surge como uma forma de eliminar a separação sujeito-objeto, integrando-os como um todo coeso e harmônico. Trata-se de compreender o seu método de trabalho não como algo dissociado da própria empresa, mas como resultado de um longo processo de envolvimento com os problemas e de adaptação à realidade que você vive.
"Nós todos já passamos por esses momentos, ao fazermos algo que realmente queremos fazer. Tal envolvimento se produz, no limpa-trilhos da consciência, por uma ausência de qualquer senso de separação entre sujeito e objeto."
Robert Pirsig
Muito bem, mas o que isso tem a ver com o Software Zen?
Software Zen: Como escapar da transitoriedade dos métodos?
Em todas as empresas que visito para falar sobre algum método ou abordagem específica, eu sinto, lá no fundo, o olhar resignado dos colaboradores mais antigos que já viram tantos esforços de implantação de um método atrás do outro. Já passamos pela lista em parágrafos anteriores: RUP, CMM, MPS.BR, Scrum, Kanban, SAFe, etc.
Em 2014, eu estava exatamente nesse mesmo momento de saturação. A pergunta que eu queria responder podia finalmente ser formulada: Como escapar da transitoriedade dos métodos?
O Software Zen e a Arte da Gestão de Software é um programa de treinamento online que articula minha resposta para essa questão.
Nessa articulação, há uma atividade essencial: o design do método, da forma; e um objetivo, uma meta: a eficácia das decisões. Em resumo, o que o Software Zen desempacota para os alunos, é a ideia de que para sermos eficazes, precisamos escapar dos métodos. Isso de maneira nenhuma sugere que cada um saia por aí criando seu próprio Scrum ou seu próprio XP. Mas, sim, que cada líder, gestor, Scrum Master, Agile Coach e membro de equipe construa seu próprio repositório de práticas e influências de forma que essas ideias o guiem enquanto constrói o que precisa ser construído.
Isso nos leva ao grande ponto de partida do Software Zen: Acreditamos que melhores resultados em projetos de software vem da busca pela sabedoria para fazermos a coisa certa, sempre a coisa certa.
Como já dizia Peter Drucker, "eficácia é fazer a coisa certa". Assim, uma postura de busca pela eficácia precisa nos levar além das respostas aos porquês:
Por que trabalhar de forma iterativa? Por que administrar filas? Por que reduzir os ciclos de feedback? Por que limitar a quantidade de trabalho? Por que eficiência de fluxo, e não de recurso? Por que ter uma visão sistêmica? Por que se preocupar com um gate keeper? Por que medir lead time? Por que tangibilizar os seus resultados? Por que diminuir o tamanho dos lotes de trabalho? Por que colaborar?
Há muitos porquês a se responder antes de buscarmos "o como".
Mas é no "como" que nos encontramos com as ações concretas que nos levarão a melhores resultados. É no como que está o design do processo:
Como fazer o trabalho fluir? Como se coordenar taticamente? Como desenvolver o produto certo, do jeito certo? Como evitar os problemas de qualidade? Como se planejar? Como estabelecer uma cadência constante de entrega? Como manter as pessoas engajadas? Como visualizar seu sistema de trabalho? Como se relacionar com o seu cliente? Como medir e demonstrar os seus resultados?
É no meio de tantos "como's" e "porquês" que você vai encontrar:
- uma compreensão mais profunda do problema que enfrentamos: uma visão sistêmica
- um mapeamento mais apurado do terreno em que operamos: a fórmula da eficácia
- Um panorama estratégico para trilhar o caminho rumo às soluções que buscamos: gestão do trabalho em progresso, gestão de backlog, gestão colaborativa, gestão orientada a métricas, gestão de fluxo de entregáveis
- Um repertório de técnicas, práticas e ferramental para colocar tudo isso em ação
- O vislumbramento do processo necessário para fazer a transformação que precisa ser feita no seu projeto, na sua carreira, ou na sua empresa.
O Software Zen é diferente na medida que não ensina um método, um assunto, um tema. Ele conecta os assuntos, os métodos e os temas de forma a preparar o indivíduo para uma nova postura que dê significado às suas atividades de gestão e liderança na direção de uma relação de auto-desenvolvimento progressivo. Ele procura estabelecer um único todo coeso e harmônico entre você e o seu trabalho, para que você possa ser, a sua maneira, cada dia um pouco mais "zen".
O vídeo a seguir mostra que estamos no caminho certo:
Saiba mais sobre o maior evento online na área de gestão e liderança de software do país: Zen e a Arte da Gestão de Software
