Quality Attribute Workshop — O Papel do Designer UX
Participar do treinamento de Quality Attribute Workshop (QAW) foi uma experiência enriquecedora para mim como designer de UX. Ao longo do workshop, pude mergulhar em uma abordagem estruturada para entender e priorizar atributos de qualidade em projetos, uma prática fundamental para criar produtos excepcionais. Além disso, o treinamento refrescou o meu conhecimento sobre arquitetura de software, algo que não imaginava que seria tão útil.
O que é QAW?
O QAW é uma metodologia que visa identificar, priorizar e validar os atributos de qualidade de um sistema de software. Esses atributos podem incluir desempenho, confiabilidade, usabilidade e outros fatores que impactam a experiência do usuário e a qualidade geral do produto. Durante o workshop, os participantes são guiados por facilitadores especializados através de exercícios práticos e discussões, com o objetivo de alcançar consenso sobre os atributos de qualidade mais importantes para o projeto em questão.
Entrevistas
Depois do workshop, decidi entrevistar colegas de diferentes áreas da empresa para entender como eles percebem o QAW e o papel do design UX nesse contexto. As entrevistas foram realizadas com Célia Regina Mazzetto (Gerente de desenvolvimento de software), Esther Manoela De Freitas (Gerente de desenvolvimento de software) e Renan Costa Alencar (Desenvolvedor de Software SR).
Que benefícios você espera ter na equipe do projeto ao aplicar o QAW?
Célia: Espero mais clareza sobre prioridade de implementação de requisitos não funcionais. Melhora na qualidade da aplicação desenvolvida e também maior satisfação do sponsor, tester, designer e desenvolvedor, devido ao alinhamento que acontece na sessão de QAW.
Esther: O QAW é um processo que vai ajudar o time como um todo a pensar antecipadamente em todos os requisitos e QAs (“quality attributes”, ou atributos de qualidade), principalmente os requisitos não funcionais. Por exemplo performance, resiliência. Pois eles vão servir de input para pensar na melhor arquitetura, na melhor forma de implementar.
Um dos benefícios que esperamos é fazer um software que tenha qualidade e responda adequadamente. Isso não só em relação aos requisitos funcionais, mas também aos requisitos que estão de uma certa forma escondidos ou obscuros para o usuário final, mas que vão fazer uma grande diferença entre usuário querer usar o produto ou não.
Renan: Eu sou muito adepto a processos — não pra engessar, não como uma forma de burocratizar as coisas — mas para ter uma visão 360° do projeto. E o QAW não inclui só a questão de requisitos funcionais, mas ele abraça também os requisitos não funcionais e outras perspectivas do projeto.
E geralmente a gente acaba só se preocupando com esses pontos, eu digo em particular nas minhas experiências dentro de projetos, quando esses requisitos não funcionais surgem ao longo do desenvolvimento. Digamos assim, ou não foram mapeados, ou não foi dada a devida importância a eles na hora certa. Aí quando chega num ciclo de teste, por exemplo, a gente acaba só se estressando.
Qual é sua impressão sobre a participação do time de design no processo?
Esther: Principalmente na parte de usabilidade, o designer pode trazer a impressão dele ou da literatura de como o usuário espera ser atendido pela solução.
Outra coisa também, por exemplo: um projeto que a gente vai ter que estar sempre atualizando o layout para acompanhar uma tendência. Nesse caso, é importante o desenvolvedor saber que ele tem que fazer algo que terá constante mudança visual. Então como ele faz uma arquitetura que permita que a parte visual seja mudada com frequência sem afetar o restante? Essa visão de usuário e essa visão de roadmap do projeto de vocês podem ajudar muito.
Renan: Acho crucial. Porque o time de design vai dar a visão do usuário final como um todo. Na minha visão, vocês têm muito o chapéu do usuário final, de trazer por exemplo “na vida real não vai fazer isso, na vida real o usuário vai fazer assim”, e não apenas a parte visual.
Por exemplo, se o usuário faz uma ação e demora muito tempo para responder. Primeiro é preciso entender se é por questão de performance. Mas é interessante para o usuário saber se é por conta da Internet, às vezes o usuário não tem Internet boa. Nesse caso, como podemos sinalizar para o usuário que algo está acontecendo? É importante trazer esse tipo de cenário para o processo.
Como você acha que os designers devem se preparar para discussões dentro do QAW?
Célia: O QAW é focado em funcionalidade, é muito importante pensar na usabilidade. É importante que todos que participem tenham uma boa visão sobre o produto a ser desenvolvido, tenham se preparado para a sessão de QAW, recebendo e lendo documento sobre o assunto para poderem discutir com igualdade de conhecimento sobre o produto e ajudando a decidir o que seria melhor para o mesmo, considerando seu ponto de vista.
Deve já ter pesquisado sobre o que será o produto, pesquisado outros produtos parecidos e usar suas experiências anteriores para sugerir o que acha que agregaria para o mesmo.
Esther: Conhecendo o sistema — isso se aplica não a só vocês mas a todos os envolvidos. Conhecer o que a aplicação tem que fazer, qual é o objetivo dela e o que se espera daquele sistema para ter uma contribuição ainda mais efetiva.
Para UX, acho também que é muito importante entender o que é um requisito funcional e não funcional. Até espero que mais requisitos não funcionais façam parte de outras entregas e processos de design, pois é algo muito útil para uma equipe de projeto.
Renan: Vocês não precisam, por exemplo, estudar sobre arquitetura de sistemas. Porque isso vai variar de projeto a projeto. Eu acho vocês precisam estar familiarizados com os termos que são utilizados no QAW. Vocês dominando como usar os artefatos que compõem o QAW. Eu acho que isso já é um ganho bem interessante.
Outro ponto discutido durante as entrevistas foi até onde o designer deve participar de discussões técnicas em um QAW. Um consenso definido foi que o entendimento mais profundo da parte de desenvolvimento, teste, entre outros da solução não é algo obrigatório para o designer.
A discussão do workshop envolve muitos termos de arquitetura de sistema, por exemplo, mas isso não é uma atribuição da equipe de design. O mais importante nesse workshop é justamente trazer o repertório de cada área de especialidade.
Fazer uma ponte na comunicação entre essas áreas é importante para ajudar a manter o mesmo nível de entendimento da discussão entre todos, mas a visão única da área de design é o que vai enriquecer o material para os passos seguintes a esse workshop.
Aprendi muito sobre importância de considerar os atributos de qualidade desde o início do processo de desenvolvimento de software. Antes de aplicar o QAW em projetos, muitas vezes a equipe foca apenas nos requisitos funcionais, deixando de lado aspectos cruciais como desempenho e segurança. Agora percebo como isso pode afetar drasticamente a experiência do usuário e a satisfação do cliente.
A presença do designer UX no QAW traz uma perspectiva única sobre como os atributos de qualidade impactam a experiência do usuário. Durante o workshop, percebi como o design pode influenciar não apenas a usabilidade, mas também aspectos como acessibilidade e satisfação do usuário. O designer UX desafia as suposições e ajuda a garantir que os atributos de qualidade sejam abordados de forma holística.
Agradeço muito a ajuda dos entrevistados e aos envolvidos no treinamento do QAW, realizado nesse ano no SiDi. Também a ajuda da Marcela Palmieri e Erika Mayumi Miyoshi com a revisão.
Referências: Quality Attribute Workshops (QAWs), Third Edition — por Mario R. Barbacci, Robert J. Ellison, Anthony J. Lattanze, Judith A. Stafford, Charles Weinstock, and William Wood — 2003. Quality Attribute Workshops (QAWs), Third Edition (cmu.edu)
Dê seu feedback sobre esse artigo aqui: Formulário de avaliação
