A pesquisa é um sistema com problema de throughput

Quando olho para um grupo de pesquisa do jeito que olho para um sistema em produção, não vejo gente lenta. Vejo um pipeline com uma fila em cada passagem de bastão e ninguém medindo as filas. O pensamento é rápido. É tudo o que existe entre um pensamento e o próximo que consome os meses.

Desenhe o pipeline

Pegue qualquer estudo e liste as etapas: pergunta, desenho, aprovação, coleta, limpeza, análise, escrita, revisão interna, submissão, revisão externa, ajustes, publicação e, por fim, alguém ler aquilo e construir em cima. Agora anote ao lado de cada etapa quanto tempo o trabalho fica parado esperando e quanto tempo alguém está de fato trabalhando nele. Em todo laboratório com que conversei, a espera domina. A análise leva dias. Esperar acesso aos dados leva semanas. Escrever leva semanas. Esperar a revisão leva meses.

É o mesmo desenho que faço para um pipeline de deploy. A compilação leva quarenta segundos. O pull request espera três dias por revisão. Ninguém otimiza o compilador quando o gargalo é a fila de revisão, e mesmo assim na ciência a gente continua pedindo que o pesquisador pense mais rápido.

A lei de Little vale para laboratórios

Existe uma relação simples da teoria de filas: o número médio de coisas em andamento é igual à taxa de chegada multiplicada pelo tempo médio que cada coisa passa no sistema. Fixe a velocidade com que um laboratório consegue terminar as coisas, e cada projeto extra que você começa aumenta o tempo de todos os projetos. Laboratórios rodam com uma quantidade enorme de trabalho em andamento. Cinco estudos em estágios diferentes, cada um esperando alguma coisa, cada um entrando e saindo da cabeça de alguém. O resultado é que tudo atrasa e nada é abandonado.

A resposta de engenharia não é motivacional. É limitar o trabalho em andamento, tornar a espera visível e atacar a maior fila primeiro. Quando times de software fazem isso, o tempo de entrega cai sem ninguém trabalhar mais. Vi isso acontecer em dezenas de projetos. Não há motivo para essa física parar na porta do laboratório.

As passagens de bastão perdem informação

Throughput não é só tempo. Cada passagem de bastão num pipeline de pesquisa também é um canal com perda. Os dados brutos são limpos numa planilha que ninguém versionou. A análise mora num notebook que rodou uma vez num laptop que já foi trocado. A seção de métodos comprime seis meses de decisões em três parágrafos. Quando o resultado é publicado, o caminho da observação até a afirmação já foi reconstruído de memória pelo menos duas vezes.

Num sistema de software eu chamaria isso de falta de proveniência e trataria como defeito, porque é um. Torna a replicação cara, torna o reuso quase impossível e faz a próxima pessoa da fila começar do zero. Um pipeline que perde o estado intermediário tem problema de throughput mesmo quando parece ocupado.

Como é a correção

Não estou propondo transformar ciência em fábrica. A parte criativa, o pensar de verdade, deve continuar lenta, humana e sem gerência. O que não deveria continuar lento é tudo o que não é pensar: achar o trabalho anterior relevante, colocar um dataset em forma utilizável, rodar de novo uma análise com um parâmetro diferente, gerar uma figura que bate com os dados, saber qual versão de quê produziu qual número.

Esses são problemas de engenharia, e respondem a engenharia: interfaces estáveis, automação, versionamento, visibilidade de onde o trabalho está parado. O motivo de eu me importar com isso como arquiteto de sistemas é que uma pequena melhora de throughput se acumula. Um laboratório que termina estudos na metade do tempo não faz o dobro de ciência. Faz perguntas melhores, porque o custo de perguntar caiu.

Os cientistas com quem converso já sabem onde estão as filas. Só nunca tiveram alguém tratando aquilo como um sistema que merece ser projetado.