Da crise do software à crise de significado: a importância de aprender a compreender

“Sabemos tantas coisas que não compreendemos! Toda a sabedoria de fatos é, a rigor, incompreensível, e só pode justificar-se estando a serviço de uma teoria”. Ortega Y Gasset.

Assim como na vida, em nossos projetos estamos o tempo todo sendo tomados por fatos.

Informações sobre quem, quando, o quê e onde, inundam nossa realidade dando vida ao famoso epigrama do Edward Wilson:

“Nos afogamos em informação, enquanto estamos sedentos por sabedoria. O mundo daqui pra frente será liderado por aqueles que fazem ’síntese’, pessoas capazes de juntar a informação certa na hora certa, pensar criticamente, e fazer escolhas importantes sabiamente.”

Analistas de sistemas como eu, e talvez você, aprenderam a fazer ánalise na faculdade. Agora, por causa das novas circunstâncias de mundo que nos são apresentadas, de nós é exigida a capacidade de realizar um outro tipo de processo: ‘a síntese’.

Para entender isso melhor, veja, por exemplo, a diferença entre os conceitos de requisito e user story sob a perspectiva de análise e síntese.

Requisitos são obtidos por um processo de análise. Separamos o todo em partes quando fazemos o processo de elicitação. Essas partes são produzidas separadamente e depois reacopladas umas às outras para a formação do todo. A implementação de um requisito não é suficiente para dar sentido ao todo. É preciso esperar a sua junção a várias outras partes para que o produto se torne suficientemente significativo para o cliente.

Já uma user story, por sua vez, é criada por meio de um processo de síntese. Identificamos o comportamento esperado no todo da qual a user story faz parte e trabalhamos para preencher o gap entre o comportamento atual e o esperado desse todo. O sentido do todo, o seu significado, se amplia no exato momento da incorporação da nova user story à vida do cliente. O produto se torna gradativamente mais significativo para o cliente porque estamos em constante sintetização de novo significado a cada iteração de trabalho.

A síntese é, assim, um processo de ampliação de significado.

Há uma diferença brutal de significado entre “concluímos a implementação de 15 requisitos e estamos agora pari-passo com o cronograma do projeto” (análise, evolução do todo por meio da composição de suas partes) e “o cliente agora está estornando pagamentos com o nosso sistema” (síntese, evolução do todo por meio do seu desenvolvimento na forma de novos comportamentos e capacidades). Essa diferença vai aparecer, de um modo ou de outro, em praticamente tudo que estamos reaprendendo a fazer nessa transição da era industrial para a era da informação.

O pensamento analítico é o ramo favorito das ciências exatas, especialmente das engenharias, e o desenvolvimento de software foi ‘ciência exata’ por muito tempo. Entretanto, o século XXI nos impõe uma nova circunstância onde é a síntese dos fenômenos que impera. A chamada agora é para resolver problemas humanos, por humanos; o que nos insere em uma nova realidade: a da construção de significado.

Estamos descobrindo que, para construir software, é preciso não só construir o significado do problema que ele resolve mas, ao mesmo tempo, construir significado para aqueles e por aqueles que o constroem.

A crise de significado é o pano de fundo social invisível que aflige o ser humano do século XXI. Desenvolvedores de software participam desse fenômeno de uma forma toda especial que pretendo começar a arranhar nesse ensaio.

Software como engenharia

Saber sobre “quem, quando, o quê e onde” já foi o grande desafio da indústria de software. Foi a fase do controle, da engenharia. Para prever o futuro era preciso coletar o máximo de informação sobre o presente e congelá-la para que ela pudesse ser devidamente assinada, catalogada e armazenada. Como uma série de baldes de água que buscam chegar ao fogo, ela passava de mão em mão até alcançar o almejado final do ”processo”.

Essa foi a era do “software como engenharia”.

Na faculdade, “Engenharia de Software” é aquela matéria onde estudamos como estruturar o processo metodológico de produção do software (quem não se lembra de Pressman, Sommerville, etc?). Inusitadamente, hoje é comum chamarmos de “práticas de engenharia” aquilo que programadores fazem, ou seja, a parte que envolve o código do software e o que está em volta dele (testes automatizados, deploy, versionamento, etc). O que não está relacionado com isso acaba caindo no guarda-chuva das “práticas de gestão”. Mas não são essas mesmas práticas de gestão que hoje continuam sendo estudadas na disciplina de “Engenharia de Software” nas faculdades?

Seria confuso se não soubéssemos que, em nossa indústria, mercado e academia não se entendem. O próprio livro do Pressman hoje virou muito mais um grande catálogo de todo o tipo de prática, método e abordagem, do que uma estrutura conceitual coerente que faça sentido. Enfim, na busca por saber tudo, de coletar todos os fatos, os alunos acabam não sabendo nada — aquilo que é mais importante, o sentido, falta.

A verdade é que temos uma tara por essa tal de engenharia.

Meu projeto final na faculdade ilustra o quanto eu também não consegui ficar imune a isso. Intitulado “Engenharia de Requisitos”, meu trabalho foi merecedor de um “10 com louvor”. Eu não tinha consciência disso na época, mas foi um ótimo exemplo da ideia de fazer com muita eficiência o que não precisava ser feito. Tanto na escola, quanto na faculdade, muitas vezes a nota 10 reflete tão somente a sua capacidade de dizer o que o seu professor espera ouvir; e não a validade concreta do que está sendo dito. Eficiência versus eficácia também na vida escolar.

Mas eu acreditava naquilo. Compartilhava da premissa dos meus professores, e isso é suficiente, pois dado que você compartilhe as mesmas premissas, o que vem a seguir é mero esforço de coerência. Se as premissas não são compartilhadas, o zero é garantido, pois dali pra frente tudo se torna inválido.

Por falar em premissa…

Crise do software?

Nos anos 90 e 2000 a coisa mais comum em palestras, cursos, e livros que ofereciam soluções de gestão para projetos de software, era começar falando da famosa Crise do Software.

— “Estamos em crise. Não conseguimos entregar o que combinamos com nossos clientes. Se você analisar o Chaos Report verá que…”

A “Engenharia de Software” em sua forma mais acadêmica foi uma tentativa de resposta a essa crise. A premissa era que dado que não entregamos os projetos com o escopo necessário no prazo e orçamento combinados, então a causa é a falta de controle sobre os fatos. Era preciso ter exatidão sobre o quê, o quando e o quem. Era a exatidão requerida pela ciência para que ela pudesse fazer sua mágica.

Mas a Wikipedia define uma outra causa para a Crise do Software:

“The main cause is that improvements in computing power had outpaced the ability of programmers to effectively utilize those capabilities.”

Em bom português: a principal causa é o descompasso entre as melhorias alcançadas em termos de poder computacional e a habilidade dos programadores de efetivamente [se organizarem] para fazer uso dessa capacidade.

Como a capacidade computacional existente está e estará sempre a frente das nossas possibilidades de utilizá-la, estamos diante não de uma crise, mas de um problema permanente, ou, melhor, de uma descrição da realidade.

Enfim, olha só que coisa… A crise do software nunca foi uma crise! Era apenas a descrição de uma realidade que não conseguíamos enxergar.

Os conhecidos perennial problems não são resolvíveis pela ciência, para esses só a filosofia dá conta. Ela não tem a pretensão de resolvê-los, até porque perennial problems não tem solução (senão não seriam ‘perennial’). Mas a filosofia pode nos ajudar a lidar melhor com eles.

— Tá, mas o fato de não entregarmos o escopo necessário no prazo e orçamento combinados continua. É fato! — perguntaria você já desconfiado do meu argumento.

Fritaria sua cabeça se eu te dissesse que não é realmente isso o que precisamos fazer? Que ao fazer isso perseguimos o alvo errado? Eu te surpreenderia se te dissesse que quanto mais nos esforçamos para, do jeito certo, perseguir o alvo errado, pior fica?

O que fizemos no passado foi o mesmo que eu fiz no meu projeto final. Compactuamos com premissas inválidas. Tirar nota dez na formulação e aplicação de suas decorrências, só nos colocava mais longe do que precisava ser feito. É preciso compreender que o jogo contemporâneo mudou e que não se trata mais de entregar escopo no prazo.

Reconciliando-se com o passado

Hoje evito, sempre que posso, negar o passado. Ao invés disso, procuro me reconciliar com ele. Não é que o passado tenha sido um erro. Talvez ele apenas retrate a história de adaptação a uma circunstância pregressa que vivemos. Se eu não olhasse para o passado com o respeito que ele merece, eu não teria aprendido tanto com Peter Drucker, Russel Ackoff, Watts Humphrey, Barry Boehm, Fred Brooks, Tom Demarco e outros gigantes que levaram as discussões sobre gestão para um outro patamar.

Agora é a vez de Chris Argyris. Talvez um dos maiores pensadores na área de gestão organizacional, ele dedicou uma grande parte de seus estudos e pesquisas para entender os conflitos e as formas de resolver o problema da integração do indivíduo com a organização.

No momento em que escrevo esse texto, dois livros do Argyris estão na minha mesa: “Personalidade e Organização: o conflito entre o sistema e o indivíduo” e “A Integração Indivíduo-Organização”. Enquanto me debruço em todo esse material, fico cada vez mais convencido de que a construção de sentido mútuo é de suma importância para criar uma conexão saudável entre indivíduo e organização.

A crise do significado

“Por que você está aqui?”, deve saber responder a organização. “Por que eu estou lá?”, deve saber responder o indivíduo. As respostas a cada uma dessas perguntas não devem ser iguais, mas alinhadas. Segundo Argyris, essas respostas só se alinham se cada um souber “ceder um pouquinho” em nome de uma direção comum.

O desafio é estabelecer a teoria de significado que os amarra de modo que indivíduo e organização se harmonizem. Só assim é possível sobreviver ao mar de fatos que nos inunda no dia-a-dia.

Enquanto a indústria de software passava pela sua fase de engenharia, a teoria de significado que nos apresentavam nos colocava como peças de uma grande engrenagem. Se cada um fizesse a sua parte, no final tudo daria certo. Pois é, não foi bem assim.

Herdamos dessa era essa tara por fatos sem significado. O quê, quando e quem continuam sendo a base de tudo o que sabemos, ou de tudo o que procuramos saber. Mas o problema é que, como disse Gasset, sabemos tantas coisas que não compreendemos! E assim se apresenta a crise de significado tão bem expressada nas altas taxas de turnover nas nossas empresas.

Turnover representa a taxa de rotatividade dos colaboradores de uma empresa. Esse é o fato. Já o seu significado, esse que realmente importa pra nós, é o estado de confusão que pessoas e empresas se encontram com relação ao que querem e ao que precisam para prosseguir em dada direção.

Para entender a crise de significado, é hora de abrir o terceiro livro que está sobre minha mesa. Certamente um dos trabalhos filosóficos mais significativos da primeira metade do século XX.

A história que nos orienta

Em “Meditações do Quixote”, o filósofo espanhol Ortega Y Gasset defende que “há dentro de toda coisa a indicação de uma possível plenitude”, ou seja, por trás dos fatos há o que interessa mais sob a perspectiva humana: o seu significado.

Gasset assim coloca o que ele busca com sua obra:

“Dado um fato — um homem, um livro, um quadro, uma paisagem, um erro, uma dor -, levá-lo pelo caminho mais curto à plenitude do seu significado: colocar as matérias de toda espécie que a vida lança aos nossos pés, em sua ressaca perene, como restos imprestáveis de um naufrágio, numa tal ordem que neles o sol incida inumeráveis reverberações”.

No fundo, é isso que buscamos, o que está por trás dos fatos. O que significa “o projeto atrasou”, “a entrega não saiu”, “temos muitos bugs”, “o cliente não gostou”? O que significa “nossa última entrega foi há dois meses”? “o time está resistindo à mudança”? Qual a ordem por trás do caos de fatos que nos sobrecarregam?

Na crise de significado, a história que amarra os eventos do dia-a-dia é incapaz de assumir coerência, de se unir a nós como uma totalidade harmônica. Os fatos sem significado se tornam então alheios a nós. A cada momento, a história que nos orienta se apequena, perde valor, até que se torna a história do outro, do culpado.

Os fatos e eventos que ocorrem em nossos projetos são pontos que precisam ser conectados em uma rede de sentido que nos permita não só ver o todo, mas vê-lo de uma forma que possamos nos integrar a ele de forma construtiva.

Quando há sentido, diz Gasset, “há uma ampliação da individualidade que absorve outras coisas, que as funde conosco”. Em nome do significado, é preciso mais integração do que antagonismo, é preciso reconciliação.

É preciso se reconciliar com as circunstâncias dos nossos projetos, da nossa empresa, da nossa vida. Crescer com elas e a partir delas.

Aprender a compreender, e daí, evoluir.