Como ócio influencia positivamente o seu projeto?

Vamos começar com uma pergunta bem simples: Já esteve em uma reunião, onde apresentam um projeto com prazo apertado e a complexidade só aumenta?

Essa semana passei por isso mais uma vez e vou te contar como lido com situações assim e como uso a meditação (não oriental) e o ócio para resolver desafios complexos.

Você é chamado para uma reunião extraordinária e seu chefe imediato começa a explicar essa nova iniciativa que a companhia precisa construir. A conversa se aprofunda em detalhes e, antes que você perceba, está imerso em um cenário caótico de incertezas e complexidade, a combinação certa para gerar ansiedade e inquietação. E qual será o prazo? — Você se pergunta — esse mesmo que você pensou! Um período apertado quando a empresa é razoável, e “pra ontem” no caso de alguma empresa brasileira qualquer; mas voltemos ao cenário mais realista, onde apesar de ser curto, ainda dá para respirar.

Te entregam um documento de cinco ou seis páginas detalhando os requisitos de maneira tosca (trago aqui o primeiro significado dessa palavra: feito sem apuro ou refinamento; grosseiro, rústico), é geralmente que acontece nos estágios iniciais da ideação de um projeto.

E agora?

90 minutos depois, você está com a cabeça cheia — lembra dessa sensação? Baixa energia e falta de coragem? — Bem, é normalmente a hora de levantar, ligar a máquina de espresso, moer o café e extrair a única bebida que eu conheço capaz de expelir essa fraqueza.

Já ouviu falar em cognitive load (esforço cognitivo)? É uma teoria que explica esse tipo de cansaço mental causado pela sobrecarga da nossa memória, atenção, raciocínio e criatividade na resolução de problemas (no exemplo da reunião extraordinária, o esforço foi para apreender todos os detalhes que foram apresentados).

Agora é a hora de se debruçar sobre o material inicial e começar a organizar as ideias. Deve existir mil maneiras diferentes de fazer isso, mas vou te contar como eu faço. Costumo desenhar o sistema pensando em clean architecture — do famoso uncle Bob — então o primeiro diagrama que faço é o de casos de uso que representa, de maneira superficial, todas as funcionalidade que os sistema vai expor e as ações que cada um dos atores podem realizar.

Esse primeiro trabalho pode levar uma tarde inteira para ficar aceitável e capturar todas as nuances daquele documento inicial que foi apresentado na reunião. Agora temos um problema, fazer o documento não é suficiente, você precisa apresentá-lo à equipe, certo? Por causa disso, você vai precisar de um processo de revisão e ajuste — é aquela história, sempre que criamos algo novo, temos mais uma coisa para nos preocupar. Há também um paralelo com o código que escrevemos: a cada nova peça de código que incluímos no repositório, adicionamos também mais um ponto de manutenção e risco de novos problemas.

Revisão e análise! Embora não pareça, revisar e analisar é, na verdade, meditar. Mas não no sentido oriental da palavra (budismo, hinduísmo). Um dia desses, eu estava lendo o "Opúsculo Sobre a Arte de Meditar" de Hugo de São Vitor, e salvei nas minhas anotações o seguinte conceito: "A meditação é a cogitação frequente, que investiga o modo, a causa e a razão de cada coisa". É isso que eu faço com os subprodutos daquela reunião: investigar as razões, as causas, o modo e a ideia de solução adequada para aquele contexto.

Na prática, a coisa acontece assim: reúno o material escrito da reunião, minhas próprias anotações e faço a releitura de tudo. Anoto ideias e dúvidas que apareçam durante esse processo e as compartilho com a equipe posteriormente. Esse processo é basicamente seu "dever de casa", não tem como contribuir com o time sem analisar o com o mínimo de profundidade o que fora discutido durante os encontros.

Eu gosto de fazer essa análise inicial com o iPad. Crio um mapa mental sem muito refinamento para ir clareando o entendimento. Deixa eu te mostrar um exemplo do que estou falando:

Em outro momento, posso falar especificamente sobre esse tema de anotações e mapas mentais. É um assunto que tenho muito interesse.

É difícil se desligar do trabalho — pelo menos quando este é primariamente intelectual. Não dá! Você fica ruminando aquele problema que ainda não tem solução clara na sua cabeça e você o carrega para a cozinha, para a sala, para o banho (esse aqui é especial, onde a ideia chora e o papel e a caneta não vêem). Comigo é assim, imagino que aconteça o mesmo com você, certo? Essa também é uma faceta da meditação a qual me refiro. É um processo criativo, não dá para forçar um resultado imediato, a não ser que o problema já tenha uma solução no repertório que você possui — nesse caso o esforço cognitivo é bem menor, ninguém precisa resolver o que já está resolvido.

Abrindo um parêntesis aqui: esse tipo de meditação que acontece fora do ambiente de trabalho (cozinha, sala, banho) também é trabalho. Esse tema dá muito pano pra manga quando suas horas são computadas por algum Hubstaff da vida (esses softwares de monitoramento de atividades e rastreamento de tempo). Quero te contar o que acho sobre isso em outro momento.

Já me desviei demais! Você deve estar se perguntando: o que você faz após os casos de uso? Bem, com a visão geral proporcionada por esse diagrama, eu já tenho insumos suficientes para pensar nas entidades e nos relacionamentos com mais segurança. A partir desse ponto, eu costumo fazer uma espécie de diagrama de componentes com algumas características do diagrama de classes — e podemos misturar essas coisas? Claro, principalmente em empresas menores (a grande maioria) utilizando scrum para gerenciar o projeto e onde ainda não há um processo de arquitetura e design de software bem estabelecidos (e documentados).

Com esse diagrama híbrido consigo ter uma visão suficientemente clara de todas as entidades, relacionamentos, dependências e sistemas externos (clientes e servidores) que fazem parte desse contexto delimitado — para usar um termo de Domain Driven Design (DDD), um assunto fantástico pra mim. Já posso imaginar os colegas de trabalho e amigos próximos se encolhendo após me ouvir falar desse assunto pela milésima vez! Eu sei o que vocês estão sentindo, pessoal.

Até agora temos os seguintes artefatos:

1. Documento inicial descrevendo os requisitos

2. Minhas anotações (mapa mental)

3. Diagrama de casos de uso

4. Diagrama de componentes (o híbrido que eu falei)

E daí? A essa altura você já está há dois ou três dias de onde tudo começou, estaria com sorte caso a reunião tivesse sido realizada numa quinta-feira. Pelo menos teria o fim de semana para lhe servir de período de ócio criativo e organizar as ideias em background.

"Caramba! Acabei de resolver o problema!". Aposto que você já falou isso antes, certo? Talvez mais vezes do que possa lembrar a essa altura. Como programador, tenho esses momentos de "eureca" algumas vezes por mês — deve ser comum em profissões que lidam diariamente com problemas novos e aprendizado constante. Não fui pesquisar cientificamente ainda, mas soluções automáticas assim são resultado do ócio, o tempo investido em realizar outras atividades que libertem um pouco a sua mente daquele desafio em questão. Claro, não é só o ócio, o período de análise (meditação) serviu de matéria prima.

Por que não saber disso está prejudicando a sua produtividade? É muito menos produtivo ficar dando murro em ponta de faca! Já estive nessa situação muitas vezes e se eu não prestar atenção, não é difícil repetir esse comportamento. Você começa a analisar o problema e não percebe que sua energia está baixando. Suas chances de resolver vão diminuindo (por causa do cansaço), mas você é resiliente e continua… já ouviu falar em lei dos rendimentos decrescentes? É isso que está acontecendo com você — sabe quando você já está há muito tempo analisando algo e o trabalho não rende? O problema é que você não lembra de fazer uma pausa, e continua se desgastando por mais uma hora ou duas.

Lembrar de fazer uma pausa vai tornar você mais produtivo!

Essa é a primeira de algumas cartas que estou produzindo para documentar a minha jornada como desenvolvedor de software. O que achou? Se puder me ajudar e me dizer sobre o que você gostaria que eu falasse, responda esse email com suas sugestões!

Até mais!

Almeida.