Os métodos ágeis ajudam a matar o conteúdo de um projeto digital?

Leu o título e ficou intrigado? Vou responder na primeira linha: não. Os métodos ágeis não ajudam a matar o conteúdo de um projeto digital. Mas isso não significa que as coisas estejam indo muito bem.

Lembro como se fosse hoje da primeira coisa que publiquei na internet. Um site no finado Geocities, em 1998, trazia um compêndio de textos meus analisando o desenho animado Marsupilami. Eu tinha o conteúdo, eu tinha o material todo pronto e sabia exatamente o que eu queria e coloquei no ar com os vastos recursos que o serviço oferecia na época.

E o que mudou, 20 anos depois? Continuo trabalhando com conteúdo e vivi algumas experiências curiosas com o desenvolvimento de produtos para web. Tive a oportunidade de liderar times de criativos e de tecnologia e, em muitos casos, usamos as metodologias ágeis para fazer as entregas. Se eu tivesse que escolher entre Scrum e “cascata”, fico com o Scrum de olhos fechados. Ou melhor, com um olho fechado e o outro aberto para garantir que os redatores possam fazer seu trabalho direito.

A culpa é da metodologia? Não, mas o fluxo de trabalho da produção de conteúdo é complexa e, na maioria dos casos, os squads não entendem muito bem como funciona. Se o Product Owner não for uma pessoa de conteúdo, de fato, há uma grande chance das coisas darem errado.

Se eu tivesse que escolher entre Scrum e “cascata”, fico com o Scrum de olhos fechados. Ou melhor, com um olho fechado e o outro aberto para garantir que os redatores possam fazer seu trabalho direito.

Talvez isso não seja perceptível em projetos pequenos ou em desenvolvimento de softwares em que o conteúdo está restrito à redação de arquitetura, mas em projetos de grande porte, sobretudo quando estamos falando de redesign de conteúdo legado, a dor é grande demais.

Vamos aos pontos:

• Num projeto de redesign, o conteúdo precisa de um tipo de backlog só para ele, para usar uma terminologia comum para todos. É assim que começa o processo de auditoria em que avaliamos insumo por insumo, página por página, indicando o que precisa ser feito. Em 90% dos casos a preocupação do PO ou do Scrum Master é: “existe uma maneira de migrar automaticamente todos esses textos”?.
• Ok, resolvemos dar uma olhada nos textos antes de fazer a migração, mas temos um outro problema: o sprint é de 15 dias e o fluxo de trabalho e as entregas do time de TI e design são bem diferentes das entregas de conteúdo. Não existem atalhos para o conteúdo, não existem camadas, folha de estilos (até tem, mas não é dessa que estou falando!). Precisamos escrever palavra por palavra.
• Você já tentou contratar um bom redator? Difícil, né? Não são muitos por aí com quem podemos contar e isso é um problemão. A mão de obra escassa e cara (com razão!) pode fazer um projeto parar e se tem uma coisa que aprendi no Scrum é que o fim do sprint é sagrado. E muitas vezes o projeto vai para o ar com texto bruto, redigido por quem não tem a menor ideia daquilo que está fazendo.
• Esta tensão que existe entre o prazo de entrega e o tempo de produção gera um efeito devastador no conteúdo. Num projeto desenvolvido em 2016 para uma multinacional, precisávamos estruturar um FAQ. O tempo era curto. O correto, do ponto de vista de conteúdo, seria esperar a chegada dos insumos e assim termos uma ideia do volume de texto e de como poderíamos organizar esse texto para ajudar o usuário a se encontrar. Até pq, meu Deus, era um FAQ! Mas as forças dos prazos e a necessidade de antecipar o desenvolvimento e a codificação foram maiores e a página ficou pronta, bonitinha, com um texto aleatório. O time havia definido que a melhor forma de explicar as coisas para o usuário seria com texto corrido numa página e uma listinha de sugestões para outros pontos de dúvida no final. A real, no entanto, é que o FAQ estava quase todo baseado em instruções passo a passo para realização de tarefas na plataforma. O que o conteúdo indicava era proporcionar uma experiência diferente para o usuário, mas já era tarde demais. Aquilo e um Lorem Ipsum não estavam tão distantes.

Sei que, nesses 20 anos, evoluímos muito. O design centrado nas necessidades do usuário (e todo design, por definição, deveria estar centrado no usuário, inclusive) nos ajuda muito na concepção de produtos digitais com mensagens mais claras, com um discurso geral bem definido. Mas sinto que ainda temos muito o que caminhar em contextos de conteúdo mais complexo ou volumoso. Esses, sim, seguem negligenciados, inclusive nos métodos ágeis.