Por Luciano Sousa (*)

A condução autónoma está a atravessar uma fase grande de alguma turbulência. O mercado ainda não se cristalizou e, por isso, é muito difícil transmitir às equipas quais são as prioridades corretas, e mesmo num modo de trabalho ágil, surge frustração porque o trabalho realizado parece não estar a traduzir-se em valor.

O cerne da questão é que, sem um resultado consolidado, especificamente para um projeto de engenharia, não existem objetivos palpáveis e, por isso, não há nada a alcançar dentro do método de planeamento normal que se aplica atualmente, ou seja: desenvolvimento de 3 meses, divididos em sprints de 2 semanas, com oportunidade para inovação no final como forma de deixar a imaginação fluir e servir como descontração para as equipas.

A metodologia Shape-up da Basecamp visa um modo de trabalho que reflete e lida com a incerteza do projeto, através da introdução de ferramentas e também de uma determinada mentalidade. É sobre esta metodologia que gostaria de debruçar o texto que se segue, numa primeira fase descrevendo a proposta geral do modo de trabalho e, em seguida, focar nos métodos que, acredito, são os mais adequados para o campo da condução autónoma.

Os principais pilares do Shape-Up:

  1. Modelação (shapping): processo de definir o que será feito antes do trabalho começar, mas sem entrar em demasiados detalhes. A modelação envolve colegas seniores que delineiam a solução o suficiente para dar uma direção geral, mas deixam espaço para os developers aplicarem a sua criatividade e competências técnicas. O objetivo é encontrar um equilíbrio entre ambiguidade e clareza.
  2. Apostas (betting): em vez do planeamento tradicional ou da atribuição de tarefas, o Shape-Up utiliza uma mesa de apostas onde as partes interessadas decidem quais os projetos em que se vão concentrar no próximo ciclo (a chamada “aposta”). Cada ciclo tem normalmente a duração de seis semanas. Isso permite que a equipa comprometa recursos num projeto que deseja, em vez de seguir estritamente um backlog
  3. Construção (building): durante a fase de construção, as equipas trabalham nas tarefas definidas na fase de modelação. Esta fase é caracterizada pela ausência de interrupções: não há reuniões diárias de atualização ou reuniões de progresso. É esperado que as equipas liderem a sua própria coordenação e a resolução de problemas, promovendo a autonomia e responsabilidade.
  4. Período de descontração (cool-down): após cada ciclo, há um período de relaxamento de uma ou duas semanas em que não são atribuídos novos projetos às equipas (semelhante ao sprint de inovação na metodologia Agile). Podem utilizar este tempo para explorar novas ideias, resolver problemas existentes ou refinar processos sem a pressão de prazos imediatos.

Com base na minha experiência pessoal no campo da condução autónoma, a taxa de inovação está sempre a aumentar, impulsionada pelo gigante da Inteligência Artificial. Podemos encarar este desenvolvimento exponencial como algo positivo, no sentido de que está na vanguarda da tecnologia, ou podemos vê-lo como prova de que o trabalho que está a ser realizado, no final, não servirá para nada: o tempo de desenvolvimento provavelmente será maior do que o tempo necessário para novos avanços surgirem e tornarem a solução irrelevante.

Para combater isso, proponho três formas baseadas no framework de desenvolvimento de produtos Shape-up, que são:

  1. Comunicação assíncrona, em formato escrito para forçar a introspeção.
  2. Apostar, para transmitir o facto de estarmos a visar metas móveis.
  3. Minimizar ou eliminar completamente as listas de pendências (backlogs).

Comunicação assíncrona

É costume em muitas culturas de desenvolvimento transmitir uma sensação de importância à discussão em tempo real. Contrariamente a isso, a comunicação assíncrona baseia-se principalmente num formato escrito. Numa perspetiva de product owner, é necessário criar uma narrativa para explicar a direção da equipa e o porquê de determinadas coisas terem mais prioridade em relação a outras. Um ótimo exercício de introspeção sobre a mensagem exata que está a ser transmitida para fora. Não é muito comum os programadores escreverem o que está a ser feito e porquê. Uma transição da palavra falada para um formato escrito permitiria que esta ferramenta de introspeção estivesse disponível para todos, ao mesmo tempo que pouparia muito tempo gasto em reuniões (por exemplo, cerca de 20% a 30% da duração é gasto a preparar o tópico principal; necessidades da estrutura social humana). Na minha visão, argumentaria que para realmente saber o que se pensa sobre um tópico é fundamental escrever sobre ela e depois analisar e compreender. Esta é uma mudança cultural profunda, que não é simples de implementar.

Apostar

Como líder de equipa, divido o trabalho diário em aspetos sociais e técnicos. Confio na experiência técnica dos programadores; que por sua vez confiam em mim para um plano que crie valor. A disposição e vontade de trabalhar em certos tópicos, que por vezes não são tão atrativos, diminui se esse plano não for confiável. Um “acordo de cavalheiros” é então necessário entre quem lidera e a equipa, para dizer que a organização das tarefas e a criação dos pacotes de trabalho devem ser o mais próximas possível da "verdadeira situação", a partir da perspetiva do momento. Para isso é fundamental ter uma atitude humilde perante a incerteza que enfrentamos neste campo e, portanto, apostar faz com que a perspetiva sobre o planeamento em si já signifique a natureza estocástica da nossa vida diária de trabalho. Na roleta, há sempre a hipótese de ganhar, e assim é com as tarefas que temos em mão.

Backlogs (pendentes)

O campo da condução autónoma é muito diferente de muitas outras áreas de TI. É altamente complexo: desde operações de veículos, hardware e software de sensores e computação, perceção e atuação, e ainda o relacionamento com clientes. A complexidade organizacional pode ser a maior culpada dos problemas técnicos. É preciso entender que, para um projeto complexo que deve lidar com diferentes timelines e prazos de entrega, haverá atrito nas interfaces entre os diversos domínios.

Esta é uma questão de natureza dinâmica, surgindo até mesmo em discussões simples ao longo de todo o projeto. Como em qualquer sistema de engenharia, o estado dinâmico (imagine um pêndulo a balançar) não descreve a granularidade do problema, também é necessário entender o estado estático (após oscilar, o pêndulo para e mantém a posição). É habitual que um grupo de trabalho olhe para frente, defina um backlog e o utilize como verdade. Se for observada incerteza, o backlog será utilizado e, aparentemente, a incerteza será reduzida. Este é o caminho principal para a criação de “valor”, cimentando ficticiamente a nossa posição com base no conhecimento atual do projeto. O importante é focar a atenção na ideia de não ter backlog, ou pelo menos, de fazer um esforço constante e direcionado para o reduzir, modificar e atualizar. No final das contas, excluí-lo completamente seria uma solução válida do ponto de vista do produto; tópicos importantes vão sempre reaparecer, mesmo que não sejam documentados. O produto pode mudar, a configuração da equipa pode mudar e, em geral, a direção do mercado pode mudar. O jogo deve ser jogado, o melhor que pudermos, com as cartas que foram dadas, e a busca por algo melhor é exatamente o que permite a clareza e a criação de valor. Estar em sintonia com o projeto e ajudar a conduzi-lo para um porto seguro.

Valor

Mencionei a palavra "Valor" várias vezes ao longo do artigo, e valeria a pena gastar algumas palavras exatamente sobre o que quero dizer com ela. "Valor" são as apostas realmente ganhas, aquelas que permitem o envolvimento com outras equipas, o que possibilita que as engrenagens girem. "Valor" não é um único pacote de trabalho, mas sim, o capacitação criada para as equipas a montante da sua liderança.

Conclusão

Devemos aceitar a natureza caótica de um mercado como este, devemos ser flexíveis e lutar pela cristalização de uma visão. Devemos lidar com esses paradoxos, incentivando o uso de ferramentas que permitam às equipas se superarem. O Basecamp é um ótimo exemplo da aplicação de uma metodologia complexa, que fornece não apenas software de desenvolvimento de produtos que pode ser aplicado a pequenas empresas, mas também a empresas muito grandes, atendendo às suas diferentes necessidades.

(*) Software engineer e Product Owner na Bosch