Comece simples, evolua e mantenha simples

Recentemente li um ótimo artigo da Louisa Acevedo aqui no forum em inglês (Build the Workflow You Can Learn From) e queria trazer essa reflexão, porque ela toca num erro que vejo muito em clientes de consultoria ou quem vem de outras ferramentas.

Muita gente começa a organizar o trabalho já querendo a estrutura empresarial completa, processos muito complexos, vários campos personalizados, etapas sendo confundidas com status, automações e relatórios para cenários que talvez nunca aconteçam. No fim, quase nada disso é usado de verdade.

A Louisa descreve exatamente essa armadilha. Segundo ela, o design de workflow costuma cair em dois extremos: ou criamos um remendo temporário feito só para a necessidade imediata, ou superconstruímos um sistema que tenta antecipar todos os cenários futuros possíveis. O primeiro não cresce com o trabalho, o segundo atrasa tudo porque você desenha regras e exceções antes de saber quais importam.

Um ponto que me chamou atenção: a primeira versão não precisa responder a todas as perguntas futuras. Ela precisa resolver o problema atual, criar estrutura suficiente para as pessoas usarem de forma consistente, e revelar o que não dava para aprender antes de lançar. Ou seja, o objetivo é criar um sistema que as pessoas realmente usem. Ferramenta que ninguém usa não faz milagre. Começar simples, e manter simples mesmo com a evolução do processo, ajuda na adoção pelo time e vira uma ponte para a produtividade, não uma barreira.

Gosto da estrutura do Asana, pois conseguimos começar simples. Na prática, isso significa:

  • Criar o básico que funciona
  • Dividir em seções úteis
  • Criar campos personalizados de forma cirúrgica, só o que de fato precisa
  • Ajustar automações quando fizer sentido

Alguns creators até falam de 6 ou mais departamentos que a empresa precisa ter na ferramenta de gestão, gerando ainda mais dificuldade e complexidade no seu fluxo de trabalho ou da equipe. Ok, pode ser que precise, mas vai escalando conforme a necessidade. Arrumar o caos não precisa ser mais complexo do que o próprio caos.

A Louisa propõe um ciclo simples: Solve (resolva a necessidade mais clara), Structure (crie consistência suficiente), Study (observe onde o trabalho trava, quais campos as pessoas ignoram, onde surgem “gambiarras”) e Strengthen (use o que aprendeu para simplificar ou expandir). E uma dica que quase todo mundo pula: agende a revisão já na criação do workflow, em duas semanas, um mês ou um ciclo do projeto. Sem isso, o “temporário” vira permanente.

No fim, raramente usamos um processo em toda a sua completude quando construímos ele inteiro de cara. Melhor começar enxuto e deixar o uso real mostrar o que a versão 2 precisa ter.

E você, quando monta um workflow novo na Asana, como decide o que entra na versão 1 e o que pode esperar?

Muito obrigada por trazer essa reflexão para a comunidade em português e por expandir a ideia com tanta clareza. Usei um tradutor para me ajudar a trazer esta resposta do inglês para o português, então espero que a mensagem chegue da forma que pretendo.

Gostei especialmente do ponto de que “arrumar o caos não precisa ser mais complexo do que o próprio caos.” Isso resume muito bem o risco de confundir estrutura com excesso.

Também concordo que o valor da primeira versão está menos em parecer completa e mais em criar algo que a equipe consiga realmente usar, observar e melhorar. É no uso real que conseguimos entender onde o trabalho trava, quais campos ajudam de verdade e quais partes do processo ainda precisam de mais clareza.

Fiquei muito feliz em ver o ciclo Solve, Structure, Study e Strengthen sendo aplicado dessa forma. Obrigada por continuar a conversa e torná-la acessível para mais pessoas da comunidade.

O seu tradutor fez um ótimo trabalho.

Obrigado pela sua contribuição, foi um motivador para esse tema para a comunidade Asana no Brasil.

Thank you.

Adoro esse tópico, @Pedro-Soares e @Louisa_Acevedo_C! Obrigada por trazê-lo para o nosso Fórum em português!

Concordo com tudo dito. Assim como muitos, eu também já caí nesses dois extremos: criando workflows ultra-complexos, meio “Dr. Estranho”, tentando prever todos os possíveis cenários futuros, sobrecarregando tudo; e criando gambiarras temporárias que funcionam bem… até não funcionarem mais.

Há um tempo escrevi sobre isso no Fórum em inglês: enquanto tentava enxugar um projeto que tinha ficado complexo demais e começado a dar problemas, me lembrei de um episódio de um desenho que eu assistia quando criança no Brasil. O desenho era uma série de origem alemã chamada As Histórias do Velho Urso (Janosch’s Storytime), e passava na TV Cultura nos anos 90. No episódio em questão, o personagem Schnuddel e seu cavalinho constroem uma casa que começa simples, mas eles vão acrescentando cômodos e mais cômodos, um para cada ideia, até que a casa fica grande demais e mal estruturada, e acaba desabando com o próprio peso. :sweat_smile:

Não sei se você vai se lembrar, mas aqui está o episódio:

Essa foi longe, :joy: .

Mas é uma excelente analogia, melhor começar simples e ir moldando as necessidades do que construir algo mega complexo que as vezes, até quem construiu, é o mesmo que não usa de tão complexo que ficou.

E @Vanessa_N eu tenho uma vaga lembrança do desenho, kkkkk.