Na 72A, gostamos de manter pouca distância entre o problema e quem está trabalhando para resolvê-lo. Isso vale para a relação com o cliente, para as decisões técnicas e para a forma como organizamos a própria empresa.
Preferimos entender antes de construir, evitar repasses que não acrescentam nada e deixar claro por que uma decisão foi tomada. Um projeto não deveria avançar porque todos conseguiram estar na mesma reunião. Ele deveria avançar porque as pessoas envolvidas têm informação suficiente para fazer o próximo movimento.
O trabalho precisa deixar um histórico útil
Em software, muita coisa já deixa rastro naturalmente. O código está versionado, alterações ficam registradas, pipelines mostram builds e deploys e logs ajudam a investigar um problema em produção.
Mas as decisões mais importantes nem sempre estão no código. Uma implementação mostra o que foi construído, mas não necessariamente explica por que aquele caminho foi escolhido. Pode ter existido uma restrição do cliente, uma mudança de escopo ou uma alternativa descartada semanas antes.
Por isso tentamos guardar aquilo que realmente será útil. Numa modernização, pode ser o motivo para manter parte do sistema. Numa integração, os limites de responsabilidade entre as partes. Em infraestrutura, as restrições que pesaram numa escolha. Em um projeto com IA, as hipóteses testadas e os critérios usados para avaliar o resultado.
Não é documentação por documentação. É o suficiente para que o projeto continue compreensível ao longo do tempo.
Cada assunto pede um formato
Mensagem funciona bem para dúvidas rápidas, confirmações e pequenas coordenações. Há também momentos em que continuar escrevendo só atrasa a decisão. Uma questão técnica pode entrar num ciclo de respostas, ou uma dúvida de negócio pode precisar de quinze minutos de conversa para ficar clara.
Nesses casos, fazemos a chamada. Também não tratamos toda mensagem como urgente. Investigar um erro, entender uma base de código ou comparar alternativas de arquitetura exige tempo sem interrupções constantes. O critério é usar o formato que melhor ajuda a resolver o problema.
Menos distância entre o problema e quem resolve
Tentamos evitar estruturas em que uma informação precisa passar por várias pessoas antes de chegar a quem está realmente lidando com o problema. Se a discussão é técnica, alguém técnico pode participar. Se a questão é de negócio, precisamos entendê-la antes de transformá-la em uma lista de tarefas.
Isso encurta o caminho entre problema, decisão e execução. Cada passagem pode introduzir atraso ou perder uma nuance importante. Não significa colocar o cliente em toda discussão interna. Significa evitar intermediação quando ela não acrescenta valor.
Reuniões precisam ter uma função clara
Uma reunião de status perde valor quando serve apenas para alguém ler informações que poderiam estar disponíveis de outra forma. Preferimos usar esse tempo para discutir uma prioridade, uma escolha de escopo, um risco ou alguma decisão que realmente precise da participação do cliente.
A conversa continua existindo, mas com uma função mais útil.
Remote-first não resolve tudo
Há limites no modelo. Uma pesquisa publicada na Nature Human Behaviour, baseada em dados de 61.182 profissionais da Microsoft, encontrou redes de colaboração mais estáticas e mais isoladas entre grupos durante a migração para o trabalho remoto.
Por isso, não tratamos o presencial como algo a ser evitado. Há discussões que ficam melhores cara a cara, relações que precisam ser construídas e situações que pedem mais proximidade. A diferença é que o presencial entra quando melhora o trabalho, não porque sem ele o projeto deixa de andar.
O que o cliente ganha com isso
Remote-first só faz sentido para a 72A se melhorar a execução. Para o cliente, isso significa menos tempo gasto reconstruindo informação, menos camadas entre o problema e quem pode resolvê-lo, decisões com mais contexto e reuniões usadas para avançar o projeto em vez de apenas explicar o passado.
Também significa maior continuidade. O conhecimento não fica concentrado apenas em conversas ou na memória de uma pessoa. O projeto consegue evoluir sem depender de condições perfeitas para continuar.
Essas práticas fariam sentido mesmo se estivéssemos todos trabalhando na mesma sala. Para a 72A, remote-first não é uma bandeira sobre onde trabalhar. É parte da forma como escolhemos fazer engenharia.
Referências
Bai, J.; Brynjolfsson, E.; Jin, W.; Steffen, S.; Wan, C. Digital Resilience: How Work-From-Home Feasibility Affects Firm Performance. NBER Working Paper 28588, 2021.
Yang, L. et al. The effects of remote work on collaboration among information workers. Nature Human Behaviour, 2022.
GitLab. Remote communication strategies.